A trio of 'net experts argues that a key IPv6 protocol needs fixing to get rid of a fragmentation attack vector against routers in large-scale core networks.
The vector, called “atomic fragments” has long been regarded with suspicion by IPv6 security wonks. Here, for example, is a Black Hat 2012 presentation illustrating the threat.
Now, prolific Internet Engineering Task Force (IETF) contributor Fernando Gont has helped write RFC 8021, that formally places the feature on the “considered harmful” list.
That's more serious than it sounds: "considered harmful” is code for “get rid of this as soon as possible!"
Fixing this bug is therefore important because a vulnerability in a protocol flows on to any product that implements the protocol – and that would mean vendors at the heart of the Internet, like Cisco, Juniper, Ericsson, Huawei et al - have to deal with it.
While systems using recent BSD and Linux kernels are immune, the point of the RFC is to get rid of the atomic fragment risk at the protocol level.
An atomic fragment is designed into the IPv6 fragmentation mechanism. As RFC 6496 explains them: “when a host receives an ICMPv6 'Packet Too Big' message advertising a 'Next-Hop MTU' smaller than 1280 (the minimum IPv6 MTU), it is not required to reduce the assumed Path-MTU, but must simply include a Fragment Header in all subsequent packets sent to that destination. The resulting packets will thus not actually be fragmented into several pieces but will just include a Fragment Header with both the 'Fragment Offset' and the 'M' flag set to 0 (we refer to these packets as 'atomic fragments').”
The problem is these atomic fragments present a denial-of-service (DoS) vector.
From RFC 8021: “If an attacker sends a forged ICMPv6 PTB [packet too big] error message to Host B, reporting an MTU smaller than 1280, this will trigger the generation of IPv6 atomic fragments from that moment on (as required by [RFC2460]). When Host B starts sending IPv6 atomic fragments (in response to the received ICMPv6 PTB error message), these packets will be dropped, since we previously noted that IPv6 packets with extension headers were being dropped between Host B and Host A. Thus, this situation will result in a DoS scenario.”
Co-author of the new RFC, Fernando Gont of SI6 Networks, explained to The Register that his RFC is the result of long debate in the IPv6 security community.
“This attack vector is essentially based on two different pieces of work: the generation of atomic fragments (i.e., how to trigger fragmentation at a target system), and the filtering of IPv6 fragments (i.e., what actually gets the packets dropped, causing a DoS.”