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 o0f 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 of a focus on operations and experience these days. The Source Address Validation (SAVNET) working group to allow 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, through it also has a strong element of further protocol development in its current work. LISP (Locator/ID Separation Protocol) 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 GROW working group appears to have largely focussed 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 that 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 on 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. 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 through mapping each channel to a separate QUIC stream. This helps avoid head-of-line blocking and improve 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 build-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 interdomain routing framework from the start then its 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 in order to maintain a local up-to-date cache of all RPKI credentials to apply to received routing updates.
A BCP (operational best practice statement) is being prepared to describe the operation of a 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 centralised 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 the some of these issue of centralised function through the implicit anycast nature of the CDN.
Another fundamental issue here is the lack of 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 had 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 (authenticating the IP address prefix of the route object, and validating the authority that the address prefix holder has granted to a network operator (via its Autonomous System number) to originate a route to this address prefix, and path propagation (authentication of the AS Path in a routing update as being an accurate representation of 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 Attestation (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 1990’s, motivated Cisco to propose to the IETF a “light weight” alternative in soBGP (secure origin BGP). This alternative approach avoided multi-layered digital signatures and replaced them with a collection of pairwise AS adjacency attestations. The result of validation of soBGP’s adjacency attestations with respect to a received update was that it was feasible that the update had been propagated as per the AS Path, but there was no stricter level of assurance that the update had in fact done so. 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 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)has meant that BGPSEC has not been deployed and is highkly unlikely ever to do so. Attention has returned to path plausibility approach used by pair-wise AS adjacency attestations used by soBGP.
This time around the concept has been repackaged as an AS Provider Authorisation (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 can attest any other AS as its provider and does 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.
