Last week, RFC 8021, entitled “Generation of IPv6 Atomic Fragments Considered Harmful” was published. Essentially, this RFC suggests that the infamous IPv6 atomic fragments are a bad idea and should not be supported. Besides, it describes an attack vector that, with a single packet, could DoS communications between two systems for about 10 minutes. This vector is the result of the confluence of different issues related to: IPv6 atomic fragments, widespread dropping of IPv6 packets with extension headers, and validation of ICMPv6 error messages.
What are IPv6 atomic fragments?
IPv6 (similarly to IPv4) employs a mechanism called Path-MTU Discovery, that allows IPv6 hosts to discover the maximum packet size that can be used for a given destination. Given that RFC 2460 mandates that the minimum IPv6 MTU be 1280 bytes, hosts would never need to reduce the size of their packets further than to 1280 bytes. But, since IPv6-to-IPv4 translators might be connecting the IPv6 world to the IPv4 world, hosts might receive ICMPv6 PTB packets advertising an MTU smaller than 1280 bytes.
In this respect, RFC 2460 states that, upon receipt of such an error message, a host need not reduce the size of the packets it sends further than 1280 bytes, but should simply include a fragment header in all subsequent packets sent to such destination. Thus, these packets would not really be fragmented into multiple fragments, but would just include a fragment header with (Fragment Offset=0, MF=0)
These packets were supposed to help translators in selecting a proper IPv6 fragment identification value. But please see the analysis in RFC 8021.
IPv6 atomic fragments have been problematic for a number of reasons:
- Many implementations were processing atomic fragments as normal fragmented traffic, allowing attackers to perform DoS attacks by sending forged IPv6 fragments that would cause the reassembly process to fail. This was eventually fixed by RFC 6946.
- Many implementations were (and some still are!) employing predictable IPv6 fragment identification values, allowing a number of different attacks. This has been documented in RFC 7739, but the specifications were never formally updated to require unpredictable fragment identifiers.
- Atomic fragments are the only case in which the use of extension headers can be actually triggered by a third party (including an attacker).
Dropping of IPv6 Packets with Extension Headers
As documented in RFC 7872, entitled “Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World”, there is widespread dropping of IPv6 packets containing extension headers in the public Internet.Besides, it is not unusual for e.g. BGP routers to drop IPv6 fragments targeted at them to protect the control plane.
A discussion of this topic can be found here.
Validation of ICMPv6 Error Messages
ICMP(v4) error messages were well-known as a DoS attack vector (remember the IRC nukes from the ’90s?). Still, as late as 2005, a large number of implementations were not performing any validity checks on such messages. While many/most IPv4 implementations were eventually patched, the IETF specifications were never formally updated to mitigate ICMP-based attacks. The only effort at the IETF to mitigate this problem, RFC 5927, took six years to be published (2004-2010), and never formally updated any specifications because of opposition within the TCPM WG of the IETF — the document was simply published as an Informational RFC.
The latest revision of the ICMPv6 specification (RFC 4443), briefly commented on the topic, but never changed the state of affairs in this respect.
Thus, many ICMPv6 implementations (as ICMP implementations of the ’90s), simply fail to perform any validity checks on the received ICMPv6 error messages — many don’t even check if the received ICMPv6 error message corresponds to an ongoing session.
Putting the Pieces Together
Based on the analysis above, we have the following pieces:
- Packets with IPv6 extension headers widely dropped
- Possibility to trigger the use of extension headers (fragmentation) with ICMPv6 PTB packets
- Implementations not performing any validity checks on received ICMPv6 PTB packets
As a result, it should be obvious what the attack is all about.
What is worse, many of the “mitigations” that might be in place to protect from attacks will not even work against this attack. For example,
- Network ingress filtering (BCP 38) will not mitigate the attack, since the source address of ICMPv6 PTB messages need not be forged
- Things like the TCP MD5 option protect the application data stream, but have no effect on ICMPv6 error messages
- Many firewall implementations do not allow ICMPv6 PTB messages to be filtered based on the MTU value that they advertise
Reproducing the Attack
The icmp6 tool of the SI6 Network’s IPv6 Toolkit can be readily employed to reproduce this attack. A simple way to reproduce this attack is to target the communication between our connection with a web server. Let us assume that our host’s IPv6 address is 2001:db8:2::100 and a web site is being served by 2001:db8:1::1. We could test the attack vector with the following steps:
- Test the communication with the server, e.g. by using telnet, as follows:
$ telnet 2001:db8:1:1 80
This connection attempt should succeed. - Launch the attack by employing the icmp6 tool of the SI6 Networks’ IPv6 Toolkit as follows:
# icmp6 –icmp6-packet-too-big -d 2001:db8:1::1 –peer-addr 2001:db8:2::100 –mtu 1000 -o 80 -v3 - Test communication with the web server, as in the first step. This new connection attempt should now timeout.
Many implementations do not even check that the ICMPv6 PTB message refers to an ongoing session (e.g., TCP connection). In such cases, it is not even needed to specify the TCP port numbers involved.
