Summary

  • A BGP route policy can be correct before and after an update yet unsafe during it. On an immediate-execution interface, a permissive rule may activate before its rejecting conditions exist, or a deleted filter may remain absent when a later command fails.
  • Revision 03 links this transition risk to rule order, control-plane work, atomic replacement, idempotent deployment and ruleset-generation failure. A commit acknowledgement is not enough; operators need evidence of the effective policy and resulting routes across the whole change.

The change ticket contained the right four rules. The pre-change router had the right four rules. The post-change router had the right four rules. Between those two snapshots, one rule was gone, and a route that should have been rejected had a path through.

Nothing in the final configuration revealed the opening.

That is the operational contribution of revision 03 of Current Options for Securing Global Routing. Posted on 2 October 2026, the text is an active GROW working-group Internet-Draft in the IETF stream, with intended Informational status and an expiry of 5 April 2027. It is not an RFC, final IETF consensus, Best Current Practice, a product-conformance result or evidence that a named network leaked a route. The document calls itself a contemporary, non-exhaustive and non-authoritative repository. It does not claim that any technique is timeless or sufficient.

Its most useful idea is smaller than a new routing-security mechanism. Security depends on how configuration becomes effective, not only on what the final policy says.

The command sequence is part of the policy

Some router interfaces let an operator stage a collection of changes and apply them as one transaction. Others execute each command immediately. Those models can receive identical intended configurations and expose different network behaviour.

The draft illustrates the difference with a route-map update. An operator creates a new rule, sets action permit, and then adds a large community. On an immediate-execution system, the permit is already active after the second command. If the new rule sits before the rule that rejects routes learned from upstreams, the unfinished rule can accept everything and leak upstream routes to peers.

The important fact is not that the operator typed the commands in the wrong order. The interface made each partial construction an effective policy. A configuration review performed before the change and a state dump taken after it can both pass while missing the only state that mattered.

This is an authority problem as much as an automation problem. The desired-policy file expresses what the controller intends. The router's effective policy decides which routes it is willing to advertise or accept. During an in-place update, those can diverge. The operational authority belongs to the effective state, even when the desired state is more carefully reviewed.

Reordering creates a real interval

The draft makes the transition concrete with an export policy that rejects upstream-learned prefixes, bogons and RPKI-invalid NLRI, then accepts everything remaining. The operator wants only to swap the positions of the bogon and RPKI-invalid rules.

On a non-atomic system, that apparently harmless reorder can become four operations: delete the old bogon rule; add the RPKI rule at the vacated position; delete the old RPKI rule; add the bogon rule in its new position. Between the first and second steps, a bogon route can pass. If the process stops after deletion, the intermediate state does not remain brief. It becomes the running policy.

“The window should be negligible” is not a receipt. The draft explicitly notes that a constrained or loaded control plane can extend the interval. A management timeout may describe the client giving up, not the router rolling back. A successful retry may repeat commands against a state that already changed.

The recommended mitigation is to ask whether the platform applies changes atomically. Where it does not, operators should consider building a complete new ruleset, switching the neighbour's reference to that complete object, and deleting the old set only after activation. That design narrows the risky operation from many edits to one reference change.

Even then, “switched” needs evidence. Platforms differ in transaction, commit, activation and rollback semantics. NETCONF candidate and running datastores show how a protocol can expose staged configuration and commit operations; they do not prove that every router or every policy subsystem applies route effects atomically. NMDA's distinction between intended and operational state reinforces the question: what was actually effective, and when?

Rule order is also a resource budget

The sequence of predicates changes more than meaning. It changes how much work the control plane performs before it reaches the same final decision.

Revision 03 gives a hypothetical peer that sends one million IPv4 NLRI although only 60 belong in its permitted cone. A poor order first adds two communities, checks private AS numbers, bogons and RPKI invalidity, and only then rejects routes outside the neighbour's cone. The example totals 5,986,500 operations. Moving the high-selectivity cone check first reduces the total to 1,000,300.

Those numbers are examples in the draft, not benchmark results for a named product. The structural lesson is still useful. Work spent decorating or deeply checking a route that a cheap early predicate will reject is avoidable load. The draft suggests considering scalar operations before tree lookups, list lookups and regular expressions, while warning that actual costs depend on implementation.

This matters to transaction safety. An inefficient ruleset can burden the same control plane that must complete the update. Multiple neighbours can amplify the input. The more slowly commands become effective, the longer an unsafe intermediate state can survive. Rule order therefore has three roles: policy semantics, computational cost and the duration of transition risk.

Idempotency does not mean atomicity

The draft recommends generating prefix filters on dedicated systems and deploying a policy only when it changed. That is valuable idempotency: unchanged inputs should not create recurring router work.

It is not atomicity. A deployment can be perfectly idempotent—repeating it reaches the same final ruleset—while every first application walks through unsafe intermediate states. It is not content validation either. An unchanged but wrong generated policy can be skipped efficiently.

The evidence chain needs distinct digests and receipts: source data used by the generator, desired policy, generated device policy, pre-change effective policy, staged validation, activation response, post-change effective policy and observed route delta. A single pipeline status called “deployed” hides which of those facts was established.

Failure policy is a routing decision

Generation itself can fail. Revision 03 advises checking for obviously surprising output: a ruleset that suddenly becomes much larger, much smaller or empty. It leaves each administrator to choose a fallback.

Accepting all routes can break routing security. Rejecting all routes can shift too much traffic toward upstreams and cause greater harm. Reusing the previous ruleset can keep the network stable while wrongly accepting or rejecting prefixes that changed. None is a neutral software default.

The fallback should therefore be decided by neighbour class and consequence before the failure. A customer edge, peer, upstream and route-server session need not share the same answer. The decision should name the tolerated staleness, traffic consequence, escalation owner and evidence required to return to generated policy.

RFC 8212's default reject for eBGP sessions without policy remains an important floor. It does not establish how a present policy changes into another present policy. RPKI origin validation, BGP Roles and OTC can supply valuable predicates. They do not make the operation that installs those predicates transactional.