Guidance to Avoid Carrying RPKI Validation States in Transitive BGP Path Attributes

The Resource Public Key Infrastructure (RPKI) allows for validating received routes, e.g., for their Route Origin Validation (ROV) state. Some operators and vendors suggest to use distinct BGP Communities to annotate received routes with their validations state. The claim is that this practice is useful, as validation state can be signalled, e.g., to iBGP speakers, without requirering each iBGP speaker to perform their own route origin validation. However, annotating a route with a transitive attribute means that a BGP update message has to be send to each neighbor if such an attribute changes. This means that when, for example, Route Origin Authorizations are issued, revoked, or RPKI-To-Router sessions are terminated, a BGP UPDATE message will be sent for a route that was previously annotated with a BGP Community. Furthermore, given that BGP Communities are a transitive attribute, this BGP UPDATE will have to propagate through the whole default free zone (DFZ). Hence, this document provides guidance to avoid carrying Resource Public Key Infrastructure (RPKI) derived Validation States in Transitive Border Gateway Protocol (BGP) Path Attributes . Specifically, Operators are SHOULD NOT group BGP routes by their Prefix Origin Validation state into distinct BGP Communities . Not using BGP Communities to signal RPKI validation state prevent needless BGP UPDATE messages from being flooded through the global Internet routing system.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

This document discusses signalling of RPKI validation state to BGP neighbors using transitive BGP attributes. At the time of writing, this pertains to the use of BGP Communities to signal RPKI ROV using ROAs. Note that this includes all operator specific BGP Communities to signal validation state, as well as any current or future documented well-known BGP Communities marking validation state, as, e.g., described for extended BGP Communities in . However, beyond that, this document also applies to all current and future transitive BGP attributes that may be implicitly or explicitly used to signal validation state to neighbors. Similarly, it applies to all future validation mechanics of RPKI, e.g., ASPA and any other future validation mechanic build upon the RPKI.

This section outlines the risks of signalling RPKI Validation State using BGP Communities. While the current description is specific to BGP communities, the observations hold similar for all transitive attributes that may be added to a route. Furthermore, we will present data on the measured current impact of BGP Communities being used to signal RPKI Validation state.

Here, we describe examples for how a large amount of RPKI ROV changes may occur in a short time, leading to a large amount of BGP Updates being send.

Large-Scale ROA issuance should be a comparatively rare event for individual networks. However, several cases exist where issuance by individual operators or (malicious) coordinated issuance of ROAs by multiple operators may lead to a high churn triggering a continuous flow of BGP Update messages caused by operators using transitive BGP attributes to signal RPKI validation state. Specifically:

When one large operator newly starts issuing ROAs for their netblocks, possibly by issuing one ROA with a long maxLength covering a large number of prefixes. This may also occur when incorrectly migrating to minimally covering ROAs , i.e., when the previous ROA is first revoked (see ) and the new ROAs are only issued after this revocation has been propagated, e.g., due to an operational error or bug in the issuance pipeline used by the operator.
When multiple smaller operators coordinate to issue new ROAs at the same time.
When a CA has been unavailable or unable to publish for some time, but then publishes all updates at once, or--as unlikely as it is--if a key-rollover encounters issues.

Large-Scale ROA revocation should be a comparatively rare event for individual networks. However, several cases exist where revocations by individual operators or (malicious) coordinated revocation of ROAs by multiple operators may lead to a high churn triggering a continuous flow of BGP Update messages caused by operators using transitive BGP attributes to signal RPKI validation state. Specifically:

When one large operator revokes all ROAs for their netblocks at once, for example, when migrating to minimally covering ROAs , or when revoking one ROA with a long maxLength covering a large number of prefixes.
When multiple smaller operators coordinate to revoke ROAs at the same time.
When a CA becomes unavailable or unable to publish for some time, e.g., due to the CA expiring (, , , ).

Similar to the issuance/revocation of routes, the validation pipeline of an operator may encounter issues. For example, any of the following events may lead to RTR services used by an operator no longer providing validation state to routers, leading to routes changing from VALID to UNKNOWN:

The RTR service may have to be taken offline due to local issues (, , ), or, even worse, a misconfiguration may lead to the service flapping, e.g., when the system runs out of memory after a few minutes of communicating validation state to routers.
Validation state may seemingly lapse due to issues with time syncronization if, e.g., the clock of the validator diverts significantly, starting to consider CA's certificates invalid.
Multiple operators use one central RTR service hosted by an external party, or depend on a similar validator, which becomes unavailable, e.g., due to maintenance or an outage, and local instances are not able to handle loss of this external service without changing validation state, i.e., do not serve from cache.

The above non-exhaustive listing suggests that issues in general operations, CA operations, and RPKI cache implementations simply are unavoidable. Hence, Operators MUST plan and design accordingly.

Following an RPKI service affecting outage, and considering roughly half the global Internet routing table nowadays is covered by RPKI ROAs , any Autonomous System in which the local routing policy sets a BGP Community based on the ROV-Valid validation state, would need to send BGP UPDATE messages for roughly half the global Internet routing table if the validation state changes to ROV-NotFound. The same, reversed case, would be true for every new ROA created by the address space holders, whereas a new BGP update would be generated, as the validation state would change to ROV-Valid. As the global Internet routing table currently contains close to 1,000,000 prefixes , such convergence events represent a significant burden. See for an elaboration on this phenomenon. Furthermore, adding additional attributes to routes increases their size and memory consumption in the RIB of BGP routers. Given the continuous growth of the global routing table, operators should be--in general--conservative regarding the additional information they add to routes.

The aforementioned issues that may lead to changes in validation state for a large number of routes are not confined to singular UPDATE events. Instead, given that routers' view of the RPKI with RTR is only eventually consistent, update messages may cascade, i.e., one change in validation state may actually trigger multiple subsequent BGP UPDATE storms. If, for example, AS65536 is a downstream of AS65537 (both annotating validation state with BGP Communities), and a major CA fails, but AS65537 has their validator's cache updated before AS65536, AS65536 will first receive updates for all formerly valid routes learned from AS65537 when validation state changes there, and propagate these down its cone. Then, when the cache of AS65536 is updated as well, the community of AS65536 will again change for these routes, while also being propagated down the cone again.

In February 2024, a data-gathering initiative reported that between 8% and 10% of BGP updates seen on the Routing Information Service - RIS, contained well-known communities from large ISPs signalling either ROV-NotFound or ROV-Valid BGP Validation states. The study also demonstrated that the creation or removal of a ROA object triggered a chain of updates in a period of circa 1 hour following the change. Such a high percentage of unneeded BGP updates constitutes a considerable level of noise, impacting the capacity of the global routing system while generating load on router CPUs and occupying more RAM than necessary. Keeping this information inside the realms of the single autonomous system would help reduce the burden on the rest of the global routing platform, reducing workload and noise.

RTR has been developped to communicate validation information to routers. BGP Attributes are not signed, and provide no assurance against third parties adding them, apart from BGP communities--ideally--being filtered at a networks edge. So, even in iBGP scenarios, their benefit in comparison to using RTR on all BGP speakers is limited. For eBGP, given they are not signed, they provide even less information to other parties except introspection into an ASes internal validation mechanics. Crucially, they provide no actionable information for BGP neighbors. If an AS validates and enforces based on RPKI, INVALID routes should never be imported and, hence, never be send to neighbors. Hence, the argument that adding validation state to communities enables, e.g., downstreams to filter RPKI INVALID routes is mute, as the only routes a downstream should see are UNKNOWN and VALID. Furthermore, in any case, the operators SHOULD run their own validation infrastructure and not rely on centralized services or attributes communicated by their neighbors. Everything else circumvents the purpose of RPKI.

As outlined in , signalling validation state with transitive attributes carries significant risks for the stability of the global routing ecosystem. Not signalling validation state, hence, has tangible benefits, specifically:

Reduction of memory consumption on customer/peer facing PE routers (less BGP communities == less memory pressure).
No effect on the age of a BGP route when a ROA or ASPA is issued or revoked.
Avoids having to resend, e.g., more than 500,000 BGP routes towards BGP neighbors (for the own cone to peers and upstreams, for the full table towards customers) if the RPKI cache crashes and RTR sessions are terminated, or if flaps in validation are caused by other events.

Hence, operators SHOULD NOT signal RPKI validation state using transitive BGP attributes.

The use of transitive attributes to signal RPKI validation state may enable attackers to cause notable route churn by issuing and widthdrawing, e.g., ROAs for their prefixes. DFZ routers may not be equiped to handle churn in all directions at global scale, especially if said churn cascades or repeats periodically. To prevent this, operators SHOULD NOT signal validation state to neighbors. Furthermore, validation state signaling SHOULD NOT be accepted from a neighbor AS. Instead, the validation state of a received announcement has only local scope due to issues such as scope of trust and RPKI synchrony.

None.

The authors would like to thank ... and ... for their helpful review of this document.