At both the corporate and Internet network infrastructure levels, IP-based routing decisions are performed on the destination address of IP packets by following global routing tables’ content and associated policies.
Both the IPv4 and IPv6 protocols provide the option for a packet emitter to force the routing path followed by its packets. This ability for users to inflect the routing implemented by operators is known as source routing.
When a packet from a source to a target follows a natural path (in blue in picture on following page), the inclusion of a source routing extension in this packet with the address(es) of intermediary router(s) (waypoint in the picture) modifies the routing path (in red in the picture). In other words, the packet is routed from the source to the waypoint and then from the waypoint to the target. Including more intermediary routers not only gives more control on the forced path but also provides more discovery capabilities.
For decades, the benefits and drawbacks of this capability have been discussed. During that time, the IPv4 Loose and Strict Source Routing options (LSSR and SSR) and the IPv6 Type 0 Routing Header extension (RH0 ) have been implemented in IP stacks. However, IPv4 network administrators have gotten into the habit of preventing the processing of source routing options on routers, which has resulted in the default disabling of source routing in most IPv4 devices.
As more IPv6 testing and deployment gets conducted, the more serious negative security impacts associated with the Type 0 Routing Header are becoming better understood. As a result, the IETF has begun taking action to deprecate the mechanism in the IPv6 specification. This overview of the process provides a good illustration of how the IETF works and what makes it such a unique standardisation body; that is, following a rough consensus, a draft providing a pragmatic response to a security problem has been published.
Threats
There are a number of potential consequences associated with the ability of a user to select the path followed by its packets in the routing infrastructure, ranging from network discovery to denial-of-service (DoS) attacks. Some are described in IPv6 Type 0 Routing Header Security (PDF), but more can be found in a document titled “Deprecation of Type 0 Routing Headers in IPv6,” which is a work in progress (available on www.ietf. org). The most significant consequence-the one that led to the deprecation of the mechanism in the IPv6 protocol-is a DoS attack, which is described briefly later.
Under IPv4, the source routing mechanism is implemented as an option that synthetically carries a list of the waypoint addresses through which the packet will travel. The size of the list is inherently limited by the maximum size of IPv4 options (40 bytes), which leaves room for, at most, nine addresses.
Under IPv6, source routing is implemented as an extension header, which is found between the IPv6 header and the upper-layer payload. As with IPv4, it is seen mainly as a list of waypoint addresses that the packet will visit on its path to its final destination. Unlike IPv4, the number of addresses in IPv6 is limited only by the maximum size of the packet. On paths with a Maximum Transmission Unit (MTU) of 1,500 bytes, one can inject packets containing up to 90 waypoints. This is a renewed version of the old IPv4 source routing threat, but perhaps doped on steroïds: the amplification effect is indeed 10 times worse.
When a packet that includes a routing header arrives at the destination found in the destination field of the IPv6 header, the node inspects the routing header and, by default, forwards the packet to the next waypoint. This behaviour was true for most routers as well as for some host operating systems, at least until a few months ago.
Since no filtering or limitations are typically implemented with regard to that behaviour, some specific lists of addresses in the RH0 extensions can lead the packet to oscillate between two selected routers (used as waypoints), creating an amplification attack on the path between the two targets. An attacker with a 2 Mbit/s upload link can saturate a 100 Mbit/s link.
What happened?
During a presentation at the CanSecWest 2007 Security Conference in April 2007, a number of threats with regard to the IPv6 Type 0 Routing Header extension were described, including the negative impacts on Internet infrastructure elements. That information probably filled the gap between what attendees were hearing at the conference and the numerous theoretical warnings that had been proclaimed by researchers in the IPv6 community.
In light of the recent momentum gained by IPv6, the presentation generated a lot of publicity, resulting in a number of articles being published on SecurityFocus (“Experts Scramble to Quash IPv6 Flaw,” by Robert Lemos, 9 May 2007), on Dark Reading (“Five Security Flaws in IPv6,” by Kelly Jackson Higgins, 8 May 2007), on eWeek (“IPv6 Headers Problem Revealed,” by Lisa Vaas, 4 May 2007), and on Techworld (“IETF Moves against IPv6 Threat,” by Matthew Broersma, 14 May 2007), among others. The publicity also led to Security Advisories for major end hosts and router operating systems. Most of the advisories blamed the IPv6 specification and not the implementation.
Soon after the event, the Open Source community took measures to deactivate default processing of the mechanism, including Linux 2.6 kernel (after 2.6.20.9) and most flavours of BSD. After a time, Apple patched its kernel for preventing RH0 processing (10.4.10 security update). As of this writing, Cisco and Juniper have not yet altered the defaults on their products.
Presenters at the CanSecWest 2007 Security Conference also warned against a practical threat directed toward anycast architectures, such as the F instances of the IPv6 root name servers. As a result, the operators of the F root server (the Internet Systems Consortium) took immediate action by dropping, without further processing, all packets that include an RH0 extension. The information has also been relayed to operators of other root name servers.
IETF Response
On 23 April 2007, two days after the CanSecWest Security Conference, the issue appeared on the IETF dns-ops and ipv6-ops working group mailing lists. A few hours later, it was being discussed on the IETF IPv6 working group mailing list ([email protected]).
On 25 April 2007, IPv6 WG chairs Robert Hinden and Brian Haberman officially raised the issue to the IPv6 WG.
In parallel with those discussions, two drafts were quickly assembled for review by the IPv6 working group. The first one, by Joe Abley, advocated for deprecation of the mechanism. The second one, by Pekka Savola and Georges Neville-Niel, proposed that a disable-by-default behaviour be implemented.
With the working group widely in favour of deprecation, on 14 May 2007 the IPv6 WG requested that the two drafts be combined.
At the time of this writing, the draft is a work in progress.
Conclusion
The consensus reached by the IETF regarding the deprecation of the RH0 mechanism from the IPv6 specification comes as a welcome, albeit late, conclusion to the source routing threat. The positive aspects of this decision are most notably:
- Early discovery and subsequent remediation, which prevented potential exploitation against production networks;
- Limited impact with regard to current implementations’ changes for deactivation or removal; and
- A gain in terms of future stack implementation through reduced complexity, size, and development time requirements.
It is also expected that future proposals for source-routing-related mechanisms (through a new type of Routing Header) will be followed with great care within the IETF.
Special thanks to Merike Kaeo and Joe Abley for thier contributions to this article.