This is part of a personal commentary on the meetings at the July 2023 meeting of the Internet Engineering Task Force (IETF 117). If you want to know what was presented and the comments at the mic see the IETF 117 meeting archive.
The Internet Engineering and Planning Group (IEPG) meets for a couple of hours before each IETF meeting. It’s a somewhat eclectic collection of presentations, with some vague common threads of relevance to Internet operations. Here’s a summary of my impressions from these IEPG session presentations for IETF 117.
IPv6 Hop-by-Hop extension headers — again!
The saga over the level of support for IPv6 extension headers in the public Internet continues, but at the same time, the level of interest in the topic is gently waning, to the obvious relief of some!
The initial findings from 2015, reported (in RFC 7872) that the observed packet drop probability for IPv6 packets with extension headers was measured at rates between 11% and 55% of cases. For the subset of cases where the fragmentation extension header was used, the drop rate was measured between 28% and 55%.
The general observation was not of much consequence, since little in the public network had a high level of dependence on the availability of various IPv6 extension headers, but the consequences of a drop in fragmentation headers were of greater import.
Even there, the consequence is of little importance in most cases, except for UDP and other datagram protocols. Any robust TCP implementations using IPv6 should take received ICMP6 Packet Too Big signals into account and adjust their outbound Maximum Segment Size (MSS) value to avoid sending fragmented IPv6 packets. However, UDP can’t do this.
What uses UDP transport? Well, the DNS for one, and QUIC for another. QUIC circumvents the fragmentation issue by imposing an upper bound on 1,200 octets on packets, circumventing the problem. What’s left is the DNS.
The solution here is also to simply avoid using large DNS packets, and the purpose of DNS Flag Day 2020 was to change DNS server behaviour so as not to send large DNS packets that may require fragmentation. It appears to have been more tractable to change the application behaviour that had been encountering IPv6 packet fragmentation than it was to clean out the IPv6 paths that blocked the forwarding of fragmented packets!
The story with the network treatment of other forms of extension headers, notably Destination Headers (DST) and Hop-by-Hop headers (HBH) is similar, but without any transport protocol measures to mitigate the issue. Headers of 64 bytes in length or less appear to have an overall success rate of delivery in the public Internet of around 70% of IPv6 users, which is not exactly brilliant, but not that bad either. On the other hand, the story with HBH extension headers has proved to be a measurement challenge.
What we’ve found in examining this behaviour in more detail is that many network service providers simply drop IPv6 HBH packets. Why would they do this? The issue here is that all IPv6 packets with HBH settings need to be passed to the router’s processor in every router that processes such a packet.
Read: A further update on IPv6 extension headers
In the context of the public Internet, this exposes the routing environment to a Denial of Service (DoS) attack where a high-volume packet flow with HBH headers has the capacity to dominate the router’s packet processing queue thereby denying this processing capability to other packets and risks saturating the router’s processing capability.
Furthermore, the entire purpose of the HBH header provides a tool for one network to influence, or even override, the default forwarding and routing policies of another. Most network operators would see this as a less-than-desirable capability to pass on to edge-connected hosts.
Given that we’ve been unable to find a compelling use case for HBH packets in the public IPv6 Internet, then allowing routers to process such packets represents a risk without any clearly identified benefit. Little wonder that most networks in the public Internet take the prudent course of action and drop such packets.
The overall conclusion is that all extension headers in IPv6 in the public Internet are just not sufficiently broadly supported to be useful, including fragmentation. Prudent advice is to simply stay away from this IPv6 feature, if at all possible.
RPKI
These days, IEPG meetings appear to include a mandatory session on IPv6 extension headers and a second presentation on some aspect of inter-domain routing, normally in the area of securing BGP. This IETF 117 IEPG session heard one individual’s perspective on the status and future prospects of the deployment of a secure routing framework. Such presentations have ranged from the deeply pessimistic to the wildly optimistic, as was the case with this presentation from Job Snijders. This topic has a rich history going back to the start of inter-domain routing and the faltering progress over the decades has been variously attributed to a lack of focus and effort, or to the intractably complex nature of the problem in the first place, or some combination of the two!
It’s a complex problem with many facets, including the operation of a credential scheme to allow public keys to be associated with the holder of the instruments of routing, IP addresses and Autonomous System Numbers (ASNs), the generation of authorities that convey permissions to originate routes into the inter-domain routing space and attestations that relate to inter-domain adjacencies that allow AS-PATH attributes of a route to be audited in some manner, and then an overall protocol validation framework that attempts to create a protocol correctness model.
It’s been thirty years in the making so far, and Job’s optimistic estimate is a further twenty years! A more pessimistic estimate tends towards the prediction that this work will be abandoned at some point. (I’d like to say that the likely outcome is somewhere in the middle, but I find myself somewhat pessimistic on this particular topic, so personally I’m leaning to the ‘not going to happen this way’ side!)
Much of the effort has been devoted to building and operating the infrastructure of prefix origination credentials, the so-called Route Origination Authorizations (ROAs). It’s a mixed story here. Many network operators have now published ROAs and the total count of such credentials has reached some 40% of the total prefix object count, which is an encouraging situation.
Getting networks to filter BGP route updates and remove updates where the ROA credentials flag these routes as invalid is still a work in progress. Only some 25% of Internet users are located behind such filtering networks, which indicates that much is still to be done. Of course, origination without some form of AS-PATH protection provides little in the way of protection against deliberate attack, and the work on AS-PATH protection is still a developing story with little to report in terms of deployed outcomes.
The original effort, a comprehensive framework of linked signatures that is formed as an update propagates across the inter-AS space, termed BGPSec, has not been deployed in any meaningful way, and the overheads associated with that approach tend to indicate that this picture is not going to change in the foreseeable future.
An alternative approach using AS adjacency attestations filter by customer/provider relationships, is yet to come out of the IETF standards mill, and even so — the somewhat reduced level of assurance on AS-PATH correctness is what caused the 20-year-old predecessor soBGP model to founder. This time around, the level of assurance that folk will pick this up and run with it is even lower!
So, what are we chasing down here? Is the problem one of malicious orchestrated interference and routing chaos at a disturbing scale and frequency? Not so far. The dominant form of routing anomalies is simple route leaks. Instances of inadvertent operator configuration error cause the local BGP configuration to advertise reachability in unintended ways.
One argument goes along the line that if reducing the incidence of route leaks is the only outcome of this work then that’s a good thing! An opposing view is that if we have to go to these extraordinary lengths to achieve what a decent BGP audit framework could do at a much lower cost, then we have got this all wrong! (Perhaps we could invoke the mighty power of generative prediction models and apply ChatGPT to BGP!)
The entire area of securing routing suffers from the defender’s dilemma. A defender must defend everything, while the attacker need only concentrate their efforts on one point. Much of the model of BGP assumes that the actors who play BGP are all trustable, and attacks are ‘outsiders’ who generate synthetic information to revert the operation of BGP.
As Job described in a recent case, the attacker needs only to shift their locus of attack into one of impersonation and assume not only the identity of a ‘legitimate’ network but also assume control of all or part of the victim’s network infrastructure. At this point, the attacker is operating part of the network of the intended victim.
There is much in this space which is uncertain and even more that is only dimly understood. The continual stream of route leaks illustrates the observation that even without the overlay of security mechanisms the environment is sufficiently complex such that network operators just get it wrong from time to time.
The desire to apply engineering solutions to this space is irresistible, but at the same time, it can be quite unwise. Adding more steps and more interdependencies into an already complex distributed framework that experiences a volume of lapses caused by these operational complexities often just adds to the brittleness of the framework and does not do much at all to improve the overall robustness of the resultant system.
My takeaway from this is that securing the inter-domain routing system is one of those endless quests, alongside the quest for the fountain of youth and the holy grail! However, this is not necessarily bleak news. This lack of a secured routing system has been with us from the outset, and we have accommodated it.
We’ve learned not to trust the answer if all we’ve done is send an IP packet to the ‘right’ IP destination address. That’s why we use HTTPS everywhere these days. If the remote part of a conversation can demonstrate that they have control of the name of the party we want to communicate with, and we encrypt the session, then the massive risks of an invisible ‘passing off’ attack are mitigated.
Today it does not matter how our encrypted packets reach their intended destination, as this aspect of path control of the communication is largely out of our control. What matters is that we are communicating securely with the intended destination by virtue of their name, not by their address. This means that routing attacks are, in essence, just one more vulnerability in the highly populated world of denial-of-service attack vectors, and countering the entire class of such denial-of-service threats is a truly Sisyphean task!
BMP
As we’ve just observed the inter-domain routing space is deceptively complex. Observing what is going on in the routing environment, even at the level of an individual BGP speaker can be extremely valuable. For many years we relied on implementation-specific ‘peepholes’ that allowed a network operator to generate a feed of BGP events, or customization of a BGP implementation to report on its internal state. The IETF got around to standardizing a BGP observation data feed, the BGP Monitoring Protocol (BMP) in RFC 7854.
This tool has been highly valuable, in that it not only provides a feed of the BGP protocol transactions, but can provide a feed of the current state of the BGP speakers and its data structures. This presentation was a report on the implementation of improvements to the BMP implementation in the open source FRRouting (FRR) BGP implementation.
In many ways this is not only the bread and butter of the IETF, but its entire reason for its existence. The standards produced by the IETF are intended to provide sufficient guidance to implementors to produce running code based on the specification, and also ensure that the code cleanly interoperates with other implementations of the same standard. Reports on such efforts to build code from the specification are a necessary and important aspect of the IETF’s efforts.
Tweaking BGP
BGP is a member of a class of distributed peer flooding protocols, where the ultimate objective is to ensure that every member of the set of protocol speakers receives a copy of the protocol information irrespective of where the information was first injected into the set. Perhaps, if this was all we wanted, BGP would be a whole lot easier. But we have a penchant for the adornment of technologies, and BGP is no exception.
In this case, we are talking about the intentionally limited flooding of BGP path attributes and the ‘misbehaviour’ of BGP when it treats the attribute as a flooded attribute and pushes it well beyond its intended scope. This can cause an AS-PATH attribute to be interpreted in the wrong context, such as black holes of misdirected packets.
One strategy to mitigate these sorts of issues can be explicit permit lists. Rather than simply propagate all unknown path attributes, lists of permitted path attributes by attribute type code may be propagated through the network. This list may become bloated, and inconsistent use may still lead to unintended consequences. Another possibility is to associate the feature with one or more listed ASNs.
It’s probably easy to bemoan the fact that we’ve got to this point in the adornment of BGP, but at the same time we need to recognize that BGP occupies a relatively unique role in the infrastructure of the Internet. It’s one of the few universally available signalling protocols that we have. We’ve got to here simply because there is no viable alternative!
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.