The IETF met in Vancouver at the end of July 2024. There was, as usual, a lot of work in the area of inter-domain routing at IETF 120.
There is the long-standing Inter-Domain Routing (IDR) Working Group, looking at the specification of the BGP protocol and its refinements for particular deployment scenarios such as 5G networks, or certain service quality assurance, such as link bandwidth signalling and other service metrics. The work on segment routing over IPv6 (SRv6) continues, with more focus on operations and experience these days. The Source Address Validation (SAVNET) Working Group allows the network to detect the use of spoofed source addresses by end hosts.
SIDROPS is an operations Working Group with an intended focus on the operations of the RPKI-based secure BGP framework. However, it also has a strong element of further protocol development in its current work. The Locator/ID Separation Protocol (LISP) Working Group continue to meet, although its role appears to be more of a cloud overlay rendezvous framework than an extension of the capabilities of the routing system. The Global Routing Operations Working Group (GROW) appears to have largely focused on the development of the BGP Monitoring Protocol (BMP) these days. It seems to me that a lot of this is working with fine-grained details of routing behaviours in specific scenarios. There were a few routing-related topics at IETF 120 that caught my attention.
BGP over QUIC
I know there are mixed opinions about QUIC, but for me, QUIC is the transport protocol for today’s Internet. It’s a significant improvement over TCP in terms of service flexibility, integration with TLS, and elimination of single-stream head-of-line blocking. QUIC is more useful than being restricted to HTTP/3 web transport, and the implementation of DNS over QUIC illustrates its utility in scenarios that were within the scope of UDP.
BGP has a particular set of requirements for its transport protocol. It is a long-held protocol, so it needs to be protected against various injection attacks that attempt TCP sequence number guessing. If encryption is used, then it needs the ability to perform dynamic re-keying. This requires internal segmentation of the data stream both into protocol data units and into separate logical data streams.
BGP over QUIC is a significant improvement over BGP over TCP. The ‘shared fate’ of multiplexing multiple logical information flows (BGP channels) in a single TCP flow for each protocol family can be managed by mapping each channel to a separate QUIC stream. This helps avoid head-of-line blocking and improves overall performance when multiplexing these flows into a single transport session. QUIC also avoids much of the implicit complexity in using multiple TCP sessions (draft-ietf-idr-bgpmultisession). QUIC provides transport security with built-in encryption and authentication and the ability to perform session rekeying.
If the IDR can swiftly push through this proposal for QUIC as an option for BGP transport, with an associated profile for mapping BGP channels to QUIC streams, a profile for session key agility and a TLS 1.3 profile, then we might see a more resilient inter-domain routing environment.
SIDROPS — a BCP for publication servers
Then there is the ongoing saga of securing the inter-domain routing space. This long-standing effort (spanning more than fifteen years in its current incarnation) has been largely kept apart from the work on the BGP protocol, and the resultant distancing of the framework of managing the security credentials of the objects being propagated by the routing protocol from the operation of the routing protocol has been an on-going challenge in trying to create a stable and robust outcome. If authenticity and security requirements had been folded into the design of an inter-domain routing framework from the start then it’s highly unlikely that we would ever have landed up in this bifurcated framework we are using today.
Rather than having the BGP speaker attach its credentials to the BGP protocol object being propagated and use BGP itself to pass these credentials to all those BGP speakers who receive a copy of the object, the SIDR architecture uses a separate framework for the publication and distribution of these credentials. This implies that prefix and AS holders need to submit the RPKI material (certificates, ROAs and AS adjacency attestations) to a publication server, and all BGP speakers who wish to validate BGP protocol objects need to constantly poll all of these publication servers to maintain a local up-to-date cache of all RPKI credentials to apply to receive routing updates.
An operational best practice statement (BCP) is being prepared to describe the operation of an RPKI publication server (publication-server-bcp). The issue here is that while BGP itself is a distributed protocol with no central points of control, the RPKI framework with its separate credential publication and distribution model creates these centralized points of control using a small set of RPKI publication services. The document recommends that subordinate certificate issuers use the publication services provided by their RPKI certificate issuer. This document also recommends the use of a Content Delivery Network to serve the RPKI content over the RRDP protocol, which can mitigate some of these issues of centralized function through the implicit anycast nature of the CDN.
Another fundamental issue here is the lack of a common timer definition for this system. How long should a publisher wait until it can be assured that the RPKI credentials have been published and all RPKI BGP speakers have loaded a copy of these credentials into their local cache? The lack of such timing definitions appears to have prompted an escalation where the relying parties are motivated to poll to detect changes more frequently, which places further load on the publication servers.
Of course, all of this would just go away completely if we used BGP to propagate the secure routing credentials, and stapled the reason why the update is authentic to the update itself!
SIDROPS — AS-PATH protection
There are two parts to the task of securing route objects in BGP: Origination and path propagation. Origination involves authenticating the IP address prefix of the route object and validating the authority granted by the address prefix holder to a network operator (via its Autonomous System number (ASN)) to originate a route to this address prefix. Path propagation involves authenticating the AS-PATH in a routing update to ensure it accurately represents the propagation of this route object through the inter-domain routing space.
Protecting route origination alone is not enough. An attacker can forge a new AS-PATH and simply attach a valid origination to this fake AS-PATH. Without effective AS-PATH protection, the entire SIDR effort is little more than an extremely high overhead routing leak detector for a particular class of routing leaks.
There has been broad agreement on how to secure origination for the past twenty years or more, and the SIDR Route Origination Authorization (ROA) is a digitally signed object that conveys the prefix holder’s permission for a network to originate a route to these addresses.
The same has not been the case on how to secure the AS-PATH (propagation). The high processing overheads of using multi-layered interlocking digital signatures, associated with the specification of the sBGP protocol of the 1990s, motivated Cisco to propose to the IETF a ‘lightweight’ alternative in secure origin BGP (soBGP).
This alternative approach avoided multi-layered digital signatures and replaced them with a collection of pairwise AS adjacency attestations. The result of validating soBGP’s adjacency attestations with respect to a received update indicated that it was feasible for the update to have been propagated according to the AS-PATH. However, there was no higher level of assurance that the update had actually been propagated in this manner.
This difference between soBGP’s path plausibility outcome and sBGP’s path validation outcome caused the IETF to come to an impasse. In response, the IESG set up a Working Group to discuss the requirements of a secure routing framework (the RPSEC Working Group). The same impasse situation repeated itself, in that the requirements for origination were easily defined but there was no visible consensus as to how to handle the requirements for AS-PATH validation.
The unresolved issue was passed along to the SIDR Working Group. The SIDR Working Group eventually produced a sBGP-like specification, BGPSEC, which defined AS-PATH validation using interlocked multi-layer digital signatures, along the original lines of sBGP. However, the issues associated with the partial adoption of BGPSEC, and the high processing overheads associated with such multi-layered interlocked digital signatures (as was foreshadowed in the analysis of sBGP) have meant that BGPSEC has not been deployed and is highly unlikely ever to do so. Attention has returned to the path plausibility approach used by pairwise AS adjacency attestations used by soBGP.
This time around, the concept has been repackaged as an AS Provider Authorization (ASPA), where an AS lists all of its upstream providers in a single attestation. The changes from the earlier soBGP model are the introduction of routing policy in the form of a ‘provider’ and the use of single-sided attestation. An AS could attest to being a provider over any other AS and would not necessarily need the agreement of the listed AS to act in that capacity. This approach has its problems in that partial use of these objects by ASes makes the path verification unusually complex. This implicit blending of routing policy with routing topology is not a clear fit, and the use of single-sided adjacency attestations increases the potential for rogue ASPA objects to perform a route hijack with false provider attestations.
These specifications have been in the Working Group for the past five years, and we are up to version 18. Perhaps it would’ve been easier to stick with the original AS adjacency attestation from soBGP.
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.