Summary

  • Revision 30 of the IDR working-group draft makes BGP session protection and central origin authorisation explicit, while keeping IPsec negotiation, replay handling and tunnel establishment outside BGP.
  • Operators therefore need evidence that distinguishes protected delivery from authorised origin, local admission and observed execution; an authenticated UPDATE alone cannot serve as the whole tunnel record.

The sealed envelope and the open decision

Imagine a sealed envelope arriving at a policy desk. The seal can establish which courier handed it over and whether the envelope was altered in transit. It does not establish that the sender was entitled to request the action inside, that the request satisfies the recipient’s rules, or that anyone carried it out successfully.

That distinction is easy to state and surprisingly easy to erase in an automated network. Once an authenticated BGP session, a route reflector, an SD-WAN controller and an IPsec subsystem are placed behind one operational dashboard, their separate decisions can appear as a single green event. “Route received” begins to stand in for “tunnel approved.” “Tunnel configured” drifts toward “traffic protected.” A session-level assurance is promoted into an end-to-end conclusion it was never designed to prove.

The current IDR work on SD-WAN edge and underlay tunnel discovery offers a useful opportunity to make the boundary visible. Revision 30, dated 1 September 2026, is an active working-group Internet-Draft with intended status Proposed Standard. It describes BGP distribution of discovery information in a controlled environment under common administrative authority. It does not collapse all stages of tunnel governance into BGP. On the contrary, the revision is unusually useful because it marks where BGP’s responsibility ends.

What revision 30 actually protects

The draft requires BGP sessions that carry the SD-WAN information to provide peer authentication, integrity and confidentiality. It leaves the concrete protection mechanism to the deployment. Those properties matter. They can prevent an unauthenticated party from casually injecting control information into a session, expose tampering, and keep sensitive tunnel parameters from passive observation.

Yet those are transport and peer properties. They answer questions about the channel and its counterparty. They do not automatically answer whether the peer was authorised to originate a particular Node ID, endpoint, colour or cryptographic proposal at that moment.

Revision 30 addresses that second question separately. It describes the route reflector or controller as a central policy and authorisation point. Before reflecting SD-WAN Hybrid Tunnel information, that system must verify that the BGP speaker is permitted to originate it. The wording matters because it prevents “authenticated peer” from becoming a synonym for “authorised claim.” A legitimate participant can still speak outside its assigned scope. Credentials identify a speaker; policy limits what that speaker may assert.

This separation is the first governance invariant: session authentication and origin authorisation are related controls, not interchangeable evidence.

A route can be valid while a tunnel is impossible

The next boundary lies between the BGP advertisement and the IPsec machinery that may consume it. The draft carries parameters useful to IPsec, but BGP does not negotiate those parameters, determine whether the two ends can use them, establish a Security Association or maintain one. Those tasks remain with IPsec and local policy.

This creates a state that operations must be able to describe honestly: a BGP advertisement may be well formed and legitimately originated, yet no tunnel can be admitted. The receiving edge may reject a transform, lack an eligible endpoint, find the colour inconsistent with local intent, or select another Security Association. The draft is explicit that inability to use advertised IPsec parameters does not, by itself, make the BGP advertisement malformed.

That is not a defect. It is sound layering. But sound layering produces an evidence obligation. If a route record says “accepted” while the IPsec subsystem says “no compatible proposal,” neither record is wrong. The operational mistake is to ask only one of them.

The same care applies to the rekey counter. Within BGP it is opaque. It is not a routing metric, a freshness proof or a replay detector. Nonce generation, storage, comparison and replay response remain outside BGP. Any audit view that converts the counter into a universal “freshness” light would manufacture assurance not granted by the protocol text.

Five proofs, not one success flag

A defensible operating model keeps five proofs separate.

First is transport proof: the authenticated peer, the protected session, its security mechanism and the time the bytes arrived. This supports attribution to a session, not blanket entitlement.

Second is origin-authorisation proof: the policy under which the controller or route reflector decided that this speaker could originate these SD-WAN attributes for this scope. The important evidence is not merely “allowed,” but the policy version, matched rule, relevant Node ID or endpoint scope, and decision time.

Third is advertisement-validity proof: whether the NLRI and TLVs were syntactically sound and mutually consistent. Known Node IDs, reachable and authorised endpoints, and matching SD-WAN Color are among the operational checks described by the draft. Passing those checks establishes acceptability of the information, not construction of a tunnel.

Fourth is local-admission proof: what the receiving edge’s IPsec and local policy did with the information. This layer records compatibility, the selected proposal or Security Association, the applicable local rule and the reason for rejection or choice.

Fifth is execution and outcome proof: whether the SA and tunnel were established, whether liveness held, and whether the intended data plane used the path. This is where configuration becomes observed operation.

Collapsing these proofs saves columns in a dashboard but destroys the ability to answer a failure. If the only durable event is “BGP update accepted,” a later investigator cannot distinguish a controller policy error, a valid but incompatible proposal, a failed SA negotiation and a tunnel that came up but never carried the intended traffic.

The admission receipt

Operators can close that gap without inventing a new BGP message. The useful artefact is an operator-local admission and execution receipt, built from events that the participating systems already know.

For each tunnel decision, the receipt should bind the authenticated session peer and receiving node; the route-reflector or controller policy version, rule and scope; the authorised origin; a fingerprint of the advertised attributes; syntax and consistency results; the local IPsec compatibility decision; the chosen SA or action; establishment success or failure; observed data-plane health; and the accountable operational owner. It should also carry expiry, revocation and supersession state so that an old approval cannot silently survive a changed policy.

The receipt is not a second routing protocol and should not be sent as a new claim of global truth. It is a local evidence object. Its job is to preserve causality across components: this protected session delivered this claim; this policy authorised this origin; this receiver admitted or rejected it for these reasons; this execution followed; this outcome was observed.

That modest framing avoids two opposite errors. One is to demand that BGP prove the entire tunnel lifecycle. The other is to accept fragmented logs as sufficient merely because every component emitted something. Evidence becomes useful only when the records share identifiers, clocks, policy versions and a defined owner.

The route reflector as a governance boundary

Calling the route reflector or controller a central authorisation point gives it institutional weight. It is not simply a convenient distribution fan-out. It determines which participant may cause which information to reach the rest of the controlled domain.

Centrality creates leverage and concentration. A precise rule can stop an out-of-scope origin before it propagates. A stale or overly broad rule can distribute a mistake efficiently. Revision 30 explicitly excludes controller compromise from its threat coverage, which is another reason not to turn “the controller reflected it” into conclusive evidence. A receipt cannot prevent compromise, but it can preserve which policy and entitlement were exercised and make later revocation bounded.

The design question is therefore not whether to trust the controller in the abstract. It is how to make each exercise of delegated authority inspectable. Policy identity should be immutable enough for later reconstruction. Entitlements should be scoped to the smallest practical set of origins and attributes. Emergency exceptions should expire. A reflected update should remain traceable to the authorisation decision that released it.

Failure should retain its layer

Operational systems often simplify failure into a single red condition. Here that would be costly. A rejected origin, malformed TLV, incompatible IPsec proposal, failed negotiation, failed liveness check and unused data-plane path require different owners and different remedies.

The receipt should retain the layer at which progress stopped. It should not turn local incompatibility into an accusation against the BGP speaker, or a BGP parsing failure into an IPsec incident. Nor should a successful SA be taken as proof that application traffic followed the intended route. Precise failure classes reduce unnecessary escalation and expose where automation is repeatedly compensating for policy ambiguity.

This is also why the record needs negative decisions. Successful tunnels are easy to observe because they generate traffic. Rejections disappear unless explicitly preserved. Yet a sequence of correct rejections may reveal a drifting controller policy, inconsistent cryptographic baselines or a rollout order that is operationally unsafe.

Evidence proportionate to automation

The stronger the automation, the more important it is to preserve intermediate decisions. Manual change processes once left tickets, conversations and maintenance windows that accidentally documented causality. Automated discovery and negotiation remove delay, but they can also remove the narrative of why a path exists.

Evidence need not become a permanent copy of every packet or attribute. A bounded receipt can use fingerprints for the advertised set, references to immutable policy versions, concise decision codes and retention appropriate to the risk. Sensitive cryptographic material should not be copied into an audit object. The design goal is reconstructability, not indiscriminate collection.

The principle is simple: every time automation crosses from information to authority, or from authority to execution, it should leave a durable join. Protected transport is one such join. Controller authorisation is another. Local admission and data-plane confirmation are others. None should impersonate the rest.

A disciplined reading of the draft

Revision 30 is stronger precisely because it states these boundaries more clearly than revision 29. It reinforces protected BGP sessions, the common-administration setting, central origin authorisation, the distinction between carrying IPsec parameters and operating IPsec, the external treatment of replay, local-policy choice and explicit exclusions.

Those changes should not be inflated into claims about deployment or maturity. An Internet-Draft remains work in progress. The document does not show that operators have implemented a receipt, that a particular vendor has failed to do so, or that the proposed mechanism is universally preferable. The governance lesson is narrower and more durable: a security property belongs to the layer that establishes it.

An authenticated BGP UPDATE can be excellent evidence of protected delivery by a known peer. It becomes evidence of tunnel admission only when it is joined to the authorisation, validation, local-policy and execution decisions that actually admitted the tunnel. Until that chain exists, the update is the sealed envelope—not the signed record that the requested act was permitted and completed.

Sources