Summary

  • RFC 8212 leaves EBGP transport establishment intact but makes received routes ineligible without explicit import policy and prevents routes entering Adj-RIB-Out without explicit export policy.
  • Import and export are separate local grants for every enabled address family. An explicit permit all can satisfy policy presence, so default reject prevents omission rather than malicious or careless authorization.
  • Clean installs, upgraded nodes and insecure-mode exceptions can differ. Safe rollout identifies the effective default and applied policy version, then proves pre/post-policy route sets, remote receipt, FIB next hops and packet delivery.

Consider an illustrative midnight replacement of an older border router. TCP 179 connects, OPEN capabilities are exchanged and the FSM reaches Established. The operator sees increasing message counters and assumes routing is active. FRRouting instead displays (Policy) for the missing direction. IPv4 receives no usable route. IPv6, inherited from a different configuration profile, advertises a narrow aggregate. One device is alive in both families but authorized in only one.

The old operational instinct calls this a broken session. RFC 8212 calls it a missing grant. That distinction matters because the fastest apparent repair—disable the requirement globally or attach permit all—can turn a bounded outage into an unbounded propagation event.

Transport adjacency creates no routing mandate

RFC 4271 separates the BGP finite-state machine from the routing information bases. A speaker can establish a session and exchange KEEPALIVEs before any route becomes eligible for selection or advertisement. RFC 8212 updates the later decision and dissemination stages, not the handshake.

For import, information may arrive in Adj-RIB-In, but without an explicit Import Policy it must not be eligible for the Decision Process. A packet capture or pre-policy table can therefore show UPDATEs while Loc-RIB remains empty. “The peer sent nothing” and “the local system authorized nothing” are different claims.

For export, a local route can exist in Loc-RIB and FIB while never entering Adj-RIB-Out for that external neighbour. Without explicit Export Policy, the speaker does not advertise it. Healthy local forwarding does not prove external reachability.

This is the authority boundary. The peer may offer routes, but cannot make the receiver use them. The local system may own routes, but cannot infer permission to expose them merely from an external connection. Each direction requires its own local act.

Two gates, multiplied by address families

Import and export are not a single bilateral switch. An operator can deliberately accept a default route while advertising only customer prefixes, accept nothing while sending a maintenance aggregate, or permit IPv6 before IPv4. Every enabled family has its own policy attachment and resulting route set.

That multiplicity explains asymmetric failures. A missing IPv4 import policy can produce zero local IPv4 routes while IPv4 export works. A missing IPv6 export policy can leave learned IPv6 routes usable locally while the neighbour sees no return advertisement. A summary badge that says only Established compresses away the information needed to diagnose either case.

Inventory must therefore name peer, VRF, local and remote AS, AFI/SAFI, direction and attachment point. “Policy configured on neighbour” is too vague. A peer group can supply one direction while an address-family override removes another. A generated configuration can contain the object but fail to attach it to the active instance.

Minimum Initial Specification appears here as refusal rather than permission. The common standard says only that absence must not become propagation. It does not dictate which prefixes, origins, paths, communities or business relationships each operator should authorize. Those future decisions stay local.

Explicit does not mean safe

RFC 8212 fixes an omission hazard. It cannot judge policy quality. A deliberately configured permit all is explicit. BIRD documents that blanket all and none remain valid explicit choices even while external BGP requires import and export policies.

That is not a loophole in the standard; it is the necessary boundary between protocol safety and operator authority. An operator may need an all-accept policy in a controlled lab, a route server design or a temporary migration. The same statement on an Internet transit edge may be catastrophic. Syntax cannot know the contract.

Named filters also create false comfort. A route-map may reference an empty prefix set, a stale IRR build, the wrong community namespace or a previous policy version. It may be attached to the peer group but shadowed by a per-neighbour override. Presence is only the first gate.

The proof must record resolved policy content and hash, not just its name. For import, compare pre-policy input with post-policy eligible routes and selection reasons. For export, compare pre-export candidates with post-policy Adj-RIB-Out and what the receiver actually observed. A zero result is legitimate only when its cause is known: absent policy, explicit deny, or no route matching a valid grant.

Defaults can split during migration

RFC 8212 explicitly allows an implementation to offer a deviation option. Appendix A.1, titled "N+1 N+2" Release Strategy, gives non-normative transition guidance: first introduce an insecure-mode control and warnings, then change the default for new installations. An installation upgraded through the earlier release may keep permissive behavior while a clean installation rejects by default.

The same software version and similar neighbour stanza can therefore produce opposite outcomes. One node imports everything because migration state preserved the old default; another imports nothing because it began life after the default changed. Copying visible configuration does not copy hidden provenance.

FRRouting exposes ebgp-requires-policy, a command to disable it and (Policy) indicators when filters are missing. BIRD 3.3.0 requires explicit policies for external BGP. These are valuable operational surfaces, not universal guarantees. The deployed release, startup history, generated configuration and effective runtime value remain evidence.

An insecure-mode exception must be governed like any other authority grant: owner, reason, affected peers and families, exact route set, expiry and removal test. A migration escape without expiry becomes invisible architecture.

Activating policy changes state, not just configuration

Adding a filter does not automatically prove that all prior UPDATEs were re-evaluated. Implementations may retain a pre-policy import table, request Route Refresh, replay stored data or require a session reset. RFC 2918 lets a receiver ask the peer to resend its current export, but the request depends on negotiated capability and current remote policy.

The activation path belongs in the change plan. If import policy becomes valid, operators should know whether routes appeared from stored Adj-RIB-In, a refresh exchange or a reconnect. They should predict counts and attributes before the event.

Export activation can be more dangerous. Thousands of existing Loc-RIB routes may become eligible at once. The policy engine must compute the exact Adj-RIB-Out delta, and the neighbour must confirm the expected set. Applying import and export together hides which grant caused reachability or leakage.

Stage the directions separately. Begin with explicit deny in both directions, activate a tiny import canary, then a tiny export canary. Observe each transition. Broaden only after the route-set diff matches the authorized contract.

Default reject is a foundation, not a complete security system

RFC 7454 describes prefix, AS-path and community filters tailored to relationships. RFC 7908 classifies route leaks that violate propagation assumptions. RFC 9234 adds BGP Roles and OTC to make some relationship state machine-readable. RPKI origin validation can test whether an origin AS is authorized for a prefix.

None of these substitutes for explicit policy. Origin-valid routes can still be unwanted. OTC does not define every customer prefix. Maximum-prefix limits the size of state after a counting boundary but does not decide which route deserves admission. Default reject merely ensures that missing configuration does not silently become permission.

The second-order benefit is organizational. An empty default forces someone to name the grant and own it. The third-order risk is ceremonial compliance: teams create universal allow policies so that deployment dashboards turn green, then stop reasoning about the actual relationship.

Running-code primacy prevents that slide. The configured statement is intent. The compiled policy and attachment show executable input. Pre/post-policy RIBs show control-plane effect. Remote observation shows boundary crossing. FIB and packets show operational reachability.

A canary starts with nothing and predicts every route

Create a low-blast-radius peer or isolated family. Establish the session with no import or export policy. Prove the expected baseline: OPEN and KEEPALIVE succeed, pre-policy receipt may exist, no route is eligible, and Adj-RIB-Out is empty.

Attach explicit deny policies first. Counts should remain zero, but runtime now shows an intentional zero grant rather than default absence. Capture policy identity and activation path.

Permit one sentinel prefix inbound. Predict its received attributes, post-import representation, selection and FIB next hop. Confirm packets only if the test claims forwarding. Then permit one sentinel prefix outbound and verify exact Adj-RIB-Out encoding plus receiver observation.

Repeat per enabled AFI/SAFI and direction. Include a deliberately nonmatching route, invalid-origin comparison, relationship attribute and prefix-length boundary so that the policy's negative space is also proven.

Rollback detaches the narrow grant, verifies withdrawals and returns to the known empty default. Disabling RFC 8212 globally is not rollback; it expands authority to every missing-policy peer.

An Established session with zero routes is not necessarily incomplete infrastructure. It can be a precise statement: transport exists, but routing authority has not yet been granted. The safest system makes that statement visible, reversible and testable—and demands stronger evidence before silence becomes reachability.