Summary

  • The IESG approved guidance on 22 June 2026 saying operators must not carry RPKI-derived validation states in BGP path attributes across EBGP administrative boundaries. Revision 12 is now in the RFC Editor queue.
  • The reason is both evidentiary and operational. A validation state is computed from a local RPKI view and is not authenticated when copied into a BGP attribute; changing that attribute can also force large numbers of otherwise unchanged routes to be re-advertised.

One outage, two clocks

The opening sequence comes from the approved document, not a reported outage. Its example places AS65536 behind AS65537. Both annotate routes with validation-state communities. Both refresh from one central RPKI-to-Router service on a 300-second cycle.

AS65536 refreshes one second before the service goes down. AS65537 is due one second after it. The provider therefore loses validated payload information first. Its routes change from Valid to NotFound, its communities change, and it sends updates down its customer cone. AS65536 receives and propagates that work.

Roughly 300 seconds later, AS65536 reaches its own expiry point. Its communities now change too, producing another update wave from the same underlying failure. A cache can postpone the sequence. If the outage outlasts the cache lifetime, it cannot remove the split.

The example exposes a hidden coupling. The event occurred in a validation dependency, but the work was charged to the routing system. Reachability did not need to change. The origin AS did not need to change. A locally derived label changed, and that label had been allowed to travel.

“Valid” is a result, not a portable certificate

RFC 6811 defines the familiar states NotFound, Valid and Invalid. A BGP speaker obtains processed RPKI data from a local cache, compares a route’s prefix and origin with locally stored Validated ROA Payloads, and assigns the result. The RFC explicitly calls the state a local property or attribute of the route.

That adjective carries the architecture. The result depends on which signed objects the relying party has fetched, what it has successfully validated, when its cache was refreshed, whether its RTR session is healthy and which local policy acts on the result. Another network can have a different, equally current view for a period of time.

Putting Valid in a community does not attach the VRPs, refresh time, trust-anchor state, cache health or decision rule that produced it. The receiver gets the verdict after its chain of custody has been stripped away.

The approved draft adds a harder limitation: ordinary BGP path attributes sent across EBGP are not signed. A third party can add or alter a purported validation state. The receiving network therefore cannot infer authenticity merely because the state arrived with the route. At most it has learned something about what the sender may have believed at some earlier moment.

This is not an argument against sharing every operational signal. It is a test of whether the signal carries enough evidence and authority for the use a receiver may make of it. Here it does not.

The earlier standard already kept the signal inside

RFC 8097 defined an Origin Validation State Extended Community so one router could pass a computed state to other IBGP speakers inside an autonomous system. The attribute is non-transitive. By default, an implementation must discard it when received from an EBGP peer and should not send it to EBGP peers.

The RFC allows configuration for cases such as two adjacent ASes controlled by one administration. That exception identifies the real boundary: the trust and control domain, not the numeric fact that a session uses EBGP.

The new guidance broadens the operational rule beyond that one community. It covers operator-specific communities, standard communities, large communities and any present or future path attribute whose change causes updates to cross an administrative boundary. It also applies to other RPKI-derived mechanisms, including ASPA or BGPsec validation states, if operators try to export their local results in the same way.

Inside one administration, an implementation constraint may still require a state attribute between speakers. The document permits that use but makes removal at the external edge mandatory. An internal convenience cannot quietly acquire external scope.

The update bill can be large

The draft gives two measures of scale, both with explicit time limits. A February 2024 study using RIPE NCC’s Routing Information Service found that 8% to 10% of observed BGP UPDATE messages carried publicly known communities reporting NotFound or Valid. It also observed chains of updates for about an hour after a ROA object was created or removed.

For a mid-2026 illustration, the draft uses a combined IPv4 and IPv6 table of roughly 1.3 million prefixes, about 65% covered by ROAs. If an RPKI cache failure changes those states and an operator exports them, more than 850,000 routes may need to be sent again.

Those numbers are not permanent global constants. They show the order of the coupling. A change in one signed object should cause affected routers to recompute local policy. It should not require unrelated external neighbors to ingest route replacements merely because a validation annotation changed.

The amplification can also be adversarial. An attacker able to issue and withdraw signed objects for its own prefixes can create repeated state changes. A party re-advertising NLRI can alter unsigned attributes directly. If validation state is made part of externally visible path identity, those changes become a route-churn lever.

The neighbor gains little authority from the label

The draft’s benefit test is blunt. A network that validates and enforces RPKI origin policy should not import an Invalid route, so it should not export that route to customers. The externally visible set should already reflect the sender’s decision.

A receiving network that needs RPKI assurance should validate against its own current evidence. The sender’s Valid label cannot replace that work because it is neither signed nor accompanied by the state needed to reproduce the decision. The label exposes internal mechanics without creating a reliable external control.

This distinction follows a thin coordination principle. Shared mechanisms should preserve the minimum global invariant—in this case, interoperable route exchange and locally verifiable origin evidence. They should not inflate a local conclusion into a portable permission. Documentation may describe a result; it does not acquire authority simply by crossing a boundary.

Keep the evidence with the decision

The approved guidance gives operators a clean separation. Fetch and validate RPKI material locally. Use the resulting state in local routing policy. If internal speakers require a state-bearing attribute, contain it within the administration. At every external edge, remove it before advertising NLRI.

That separation also produces better failure accounting. A stale or failed RPKI cache is a validation-dependency incident. A changed local decision is a policy event. A real route withdrawal is a reachability event. Treating all three as reasons to rewrite exported path attributes collapses different facts into the same global mechanism.

The route can still be announced. The receiver can still validate it. What should not travel is the fiction that one router’s answer carries the evidence, timing and authority of every network that receives it.

Sources