The 126th meeting of the Internet Engineering Task Force (IETF) was held in Vienna at the end of July 2026. It’s a busy week with many meetings and conversations. Here are some notes from Border Gateway Protocol (BGP)-related sessions that I found interesting.
The BGP ORIGIN attribute
It might be worth a very quick refresher on BGP path selection before looking at this topic. It’s commonly believed that when selecting between a number of routes for the same address prefix, a BGP speaker will select the route with the shortest Autonomous System (AS) path. Yes, that can be the case, but the selection process is a little more involved than just this single comparison.
When BGP sees two or more routes to the same destination address prefix, it needs to select the ‘best’ route. For the sake of consistency of the network, it’s essential that all BGP speakers use the same route selection algorithm, which is:
- Highest local preference
- Locally originated routes
- Shortest AS_PATH
- Lowest BGP ORIGIN type: Prefer Interior Gateway Protocol (IGP) over Exterior Gateway Protocol (EGP), and prefer EGP over Incomplete
- Lowest multi-exit discriminator
- eBGP over iBGP
- Lowest IGP metric to reach the BGP next hop
- Oldest eBGP path
- Lowest router ID
BGP ORIGIN is a mandatory, well-known path attribute that describes how a prefix was imported into the BGP realm, and supposedly relates to the trustworthiness of the route’s starting point. The ORIGIN code can be one of three values:
- ‘i’ (or IGP) indicating that the source BGP speaker has a local ‘network’ directive that asserts a local origination to BGP.
- ‘e’ (or EGP) indicating that the route was learned from an EGP session. As EGP is an archaic routing protocol, this code should not be seen at all these days!
- ‘?’ (or Incomplete) indicating that the route was redistributed into BGP from an interior routing protocol or a static route.
In theory, this BGP ORIGIN attribute is set when the route is first passed into BGP and preserved when the route is propagated across the BGP routing realm. As RFC 4271 directs, this attribute should not be changed by any other BGP speaker.
But it is.
And this behaviour is readily observed by pulling the advertised routes from the various route collectors, and looking for discrepancies in the ORIGIN attribute between the advertisements for the same prefix from different peers.
Another indication that BGP ORIGIN attributes are being rewritten is the use of the EGP value, as EGP is an archaic protocol that is not used today. It is a reasonable assumption that all observed instances of the EGP BGP ORIGIN value are instances of manipulation of this attribute field. The measurements of historical BGP data show that this practice started in 2023 and has been used since then.
Why are we seeing this unanticipated form of this path attribute? One quote from the presentation is pertinent here:
“…we have routers distributed across multiple countries, and one of the main metrics for prefixes learnt by Autonomous System Border Routers (ASBRs) is the distance to the next-hop. The ORIGIN attribute is evaluated before the next-hop distance. What we did was rewrite the ORIGIN for routes learnt from other peers to EGP, so that routes from more distant routers would not be preferred…”
This attribute is apparently being used as a mechanism to influence path selection. AS path length comparisons are coarse and sometimes messy. Using the ORIGIN attribute allows a different and potentially slightly more subtle means of route selection.
However, a presentation on this topic at RIPE 91, October 2025, considered an interesting scenario: ‘What if every provider rewrote the BGP origin attribute to IGP?’ Any marginal benefit in influencing traffic paths by using this option would be effectively negated, and the option would be implicitly deprecated!
It appears to be one of those protocol settings that is acceptable to use, as long as only I use it!
Slides: BGP ORIGIN in Practice, Carlos Martinez-Cagnazzo/Celsa Sanchez, IEPG Session
ASPAs
The effort to add some security framework as a BGP overlay has been going on for many years. Indeed, it’s now getting on to a couple of decades. Any hopes for a quick, simple solution died many years ago!
The original work on this security framework concentrated on the origination of the routing in BGP. Many BGP route attributes are not ‘end-to-end’ propagated attributes, and the concept of ‘protection’ for such attributes is challenging to define. However, the AS_PATH attribute is vulnerable to manipulation. The basic vulnerability here is that BGP routes with manipulated AS paths can still be propagated through the routing fabric if the originating AS in the synthetic route matches a valid Route Origination Authorization (ROA).
Network operators have used AS path manipulation for decades to achieve traffic engineering outcomes. A very common practice is ‘AS prepending’, where an AS adds its own value to the AS path multiple times. 601,814 routes use AS prepending, out of a total of 2,242,392 AS paths in the route set assembled by RouteViews.
Here’s an example lifted from a local BGP table:
Prefix: 1.0.128.0/17
AS Path: 131072 4777 38040 23969 i
131072 4608 6939 38040 38040 38040 38040 23969 iHere, AS38040 is expressing a preference that others use a transit path via AS4777 over one that uses AS6939, so it has added its AS to the AS path an additional three times on the less preferred path.
How can we ‘protect’ the AS_PATH attribute, while still allowing some operational flexibility of expressing traffic engineering preference in the path attribute? While it’s not a formal part of the definition of the BGP protocol, it is generally the case that the AS path is a record of the propagation of a route through the inter-AS space. We can use this property to get each AS to use a key that is bound to that AS to sign a partial AS path as it is propagated in an eBGP session.
One way to do this is to load keys into routers and use a path attribute, where each eBGP speaker signs an object that binds the existing AS path to the next AS that is to receive this update. The exact mechanisms, such as signing the path or signing a hash of the path, are less important than the observation that this mechanism is only effective in cases of comprehensive deployment.
If this path signed attribute is passed to a BGP speaker that does not support such an attribute, then the object is discarded, and the AS path signature set is lost. This mechanism is used in the BGPsec protocol, and breaks down in cases of partial deployment. This was a factor in limiting the traction that this protocol gained.
An alternative is to generate signed pairwise AS interconnections. This was first proposed in the earlier soBGP work from the early 2000s.
A good description of soBGP can be found in the Internet Protocol Journal Vol 6, Number 3, September 2003.
An AS path could be compared against these pairwise connections, and an implausible AS path was one where the AS path had an AS adjacency that was not listed in the first’s AS neighbours. This approach accommodates partial deployment on the assumption that an AS lists all its adjacent neighbours if it lists any. It is challenging to construct a synthetic AS path that misrepresents that AS’s adjacencies if the AS has published a signed attestation of all its adjacencies.
The issue here is that while this provides some protection against misrepresentation in inter-AS topology, it does not protect inter-AS forwarding policies. For example, a ‘customer’ network could advertise the routes learned from one connected ‘provider’ network to another connected ‘provider’ network. This is acceptable in terms of inter-AS topology, but is a route leak in terms of routing policy.
With Autonomous System Provider Authorization (ASPA), each AS lists only its upstream provider ASes. In a comprehensive deployment scenario, all inter-AS adjacencies would be listed, except for peer adjacencies. A consistent application of policy would see — at most — one peer relationship in any AS path, and that would be only at the ‘peak’ if it occurs at all. This approach can also provide a reasonable level of protection of the path, as well as some level of assurance that the path represents a plausible sequence of routing policies.
But in the ASPA model with partial deployment, the question is whether a ‘missing’ AS relation is a peer relationship, or an AS that has no providers, or an AS that is not listing its providers.
To distinguish between the latter cases, there is the use of AS0. An AS lists AS0 in its providers to indicate:
- That it has no AS provider because it’s a transit-free network (Tier 1).
- It’s a transparent route server, or a route collector, or even an AS that is not used in the routing system.
In a scenario of partial deployment, how robust is this mechanism? Most importantly, would it mark as ‘not valid’ an AS path that would be valid if a complete collection of AS relationships were available?
The ASPA draft may be almost ten years old, but paradoxically it’s early days for ASPA deployment. Current implemented support for ASPAs in routers relies on a small set of open BGP daemon implementations that have included ASPA functionality, rather than conventional router vendor code. The number of ASPA objects being generated in the Resource Public Key Infrastructure (RPKI) repositories is in the low thousands at present, though this may change as the concept gains traction in the BGP operations community.
There is a meta-comment about ASPA deployment that may be relevant here. In a massive distributed system, complexity is a huge drag on the path to widespread adoption. We support huge scale by constraining systems to operate in simple and deterministic ways.
Complexity and ambiguity are a huge problem in a partial deployment scenario for ASPAs. In the scenario of universal deployment, the interpretation of ASPAs in classifying the plausibility of AS paths might well be simple, but along the way to this ideal scenario through the murky world of partial deployment, there is a large open space that is filled by complexity and ambiguity.
Despite confident assurances from proponents that all this will be quickly resolved and we should just adopt this technology and move on, I can’t help but recollect that we heard these same confident assurances in the past when the technology has simply failed to gain traction in the operational network.
However, I may well be premature in assigning ASPA to the bucket of failed technologies already. This ASPA specification in the IETF has been simmering for ten years now, and it has had 27 iterations, but it’s still an Internet Draft. Over the years we’ve trained the industry to regard IETF draft specifications as immature. If you invest time and effort in implementing a draft, you risk finding your effort stranded if the draft moves on to other places or is abandoned. It’s feasible that other industry actors are simply waiting for a stable RFC on ASPAs before moving to provide support in operational routing environments.
There are other approaches to AS path plausibility being explored, and one of them, PAVA, was also presented at this IETF meeting.
Slides: Observations on ASPA in the Wild, Tim Bruijnzeels, IEPG Session
PAVA — AS path validation
It’s been cynically observed that whatever problem that you are attempting to solve, the best solution is to put it into the DNS. Most of the time this is a joke, but there are times when this is good advice. PAVA looks like being one of these!
One of the major sources of trauma in the design of routing security is the objective of the RPKI system to flood all of the security credentials about all the route objects to all of the networks all of the time.
Previous efforts at securing BGP in the early 2000s used the BGP protocol itself (sBGP and soBGP) to flood this data. However, when the SIDR Working Group was chartered in the IETF, one of the constraints was that the BGP protocol itself was not to be altered. That meant that the concept of using BGP itself to perform credential flooding was out of bounds. Attention was diverted to setting up a parallel system to flood credential data, complete with multiple publication points where these credentials may be found, and a client-side synchronization protocol that allowed a client to synchronize its local cache with the current state of every publication point.
This many-to-many synchronization task is not easy. We first tried to use rsync, then we turned to rrdp, a delta protocol over HTTPS, and the latest proposal is the Erik Synchronization protocol that uses Merkle trees. It seems that each time we try, we run into scaling problems sooner or later.
It may be time to think more seriously about just loading AS path data into the DNS.
The essential idea with PAVA is to split the AS path into triplets, with a couplet at either end. For example, a 4-AS path of (2497, 4826, 2764, 38803) can be decomposed into the sets [2497, 4826], [2497, 4826, 2764], [4826, 2764, 38803] and [2764, 38803].
There are just three different kinds of AS relationships that are plausible in terms of inter-AS policies, as shown in Figure 3.
Plausible AS path sequences are zero or more ‘up’ types, followed by zero or one ‘summit’ types and then zero or more ‘down’ types.
And that’s the essence of the idea.
Each AS populates a DNS zone with the pairs of its adjacent neighbouring ASes. Using the above example, AS4826 has two adjacencies, AS2497 and AS2764, where AS2947 is a customer, and AS2764 is a provider. This could be represented in the DNS as 2947.2764.4826.PAVA TXT "up" and 2764.2947.4826.PAVA TXT "down".
Authenticity could be provided by DNSSEC validation, using a key value for the AS4826 zone that is the public key of the AS4826 certificate in the RPKI repository. If the name 4826.PAVA is set up as a DNAME to 4826.APNIC.RPKI, and if we were to DNSSEC-sign that zone with a public key that is the APNIC RPKI Trust Anchor (TA), then DNSSEC validation is isomorphic to RPKI validation, which is convenient.
There is some further thought required as to how to represent an IP address prefix in this framework, but it’s possible, as the address representations used in the service ipasn.net suggests.
It would certainly be an interesting development to map both RPKI ROAs and AS paths into this DNS-based framework. It would alleviate the requirement to maintain this comprehensive cache of all the security credentials about all of the route objects, and all AS paths for all networks all of the time, and replace it with DNS queries (and DNS caches, of course).
Slides: PAVA: PAth VAlidation, Maxence Fléchier, GROW Working Group
ASRAs
I was intrigued to see the proposal in the SIDROP Working Group to add Autonomous System Relationship Authorization (ASRA) to the set of RPKI attestations, allowing an AS to list its peers and customers. In other words, the collection of ASes listed in the union of an ASes ASPA objects and ASRA objects is the complete set of an ASes adjacent neighbours in the routing space.
Fair enough, but surely this is getting a bit odd! Why not head back to the original soBGP model, and allow an AS to list all its adjacencies, and tag each adjacency if it is a provider, peer, or customer to this AS?
What’s frustrating about this ASRA work is that this same approach was proposed in response to the original ASPA proposal, such that inter-AS routing policy was a qualification to a base object that described inter-AS topology, included in the RPKI framework in a manner like soBGP. Clearly, this response to the original ASPA proposal managed to get nowhere at the time!
The strength of the ASRA approach is that it can mitigate some of the issues with partial adoption of ASPAs. The weakness is that it’s a pity we did not take a cleaner uplift of the AS connectivity object from soBGP. This incremental retrofitting of the original concept into ASPAs and ASRAs is just messy.
More generally, I can’t help but note that the entire SIDR effort is heading into the same space as all large committee-driven projects — it’s messy! The overriding concern is whether a sustained volume of random incremental adornment applied to the SIDR model will undermine the technology to the point where it becomes non-functional!
SIDROPS is supposedly a Working Group in the operations area working on issues with the deployment and operation of the RPKI-related technology. Instead, the protocol development work has continued, and even accelerated, in this Working Group without a framework and oversight of a protocol development area in the IETF. The Working Group meetings are a melange of all kinds of random contributions, and there is no thematic direction being advocated by either the Working Group chairs or the Operational Area Directors. It’s being subjected to random incrementalism!
BGP has survived for over thirty years without a substantial security framework, and more than survived, it has thrived. The efforts to provide a framework to curb route leaks and possibly resist efforts to inject false information are floundering badly amid a patchwork of piecemeal contributions. I guess we will be calling on BGP to continue to operate in its historical manner, while taking another decade or two as we try and work out where and why the SIDR framework got itself into such a confused state!
Slides: Update on Autonomous System Relationship Authorization (ASRA), Kotikalapudi Sriram, SIDROPS Working Group
IETF 126
The IETF does a really good job of collecting the presentation material and the video and audio records of all the Working Group sessions throughout the week. View them online now.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.