RFC 8021

Generation of IPv6 Atomic Fragments Considered Harmful

📅 published January 2017, from ietf

RFC 8021: Generation of IPv6 Atomic Fragments Considered Harmful 💅

okay so this one is from January 2017, and it's marked Informational 🎀 which means it's published for information, not as a standards-track spec. The main authors are F. Gont (SI6 Networks / UTN-FRH), W. Liu (Huawei Technologies), and T. Anderson (Redpill Linpro). It's in the ISSN 2070-1721 series. Its title block doesn't list anything it obsoletes or updates, so it's standing on its own 🦋

Abstract

okay bestie, the abstract is the TL;DR 🌸 It talks about the security risks of generating IPv6 atomic fragments, plus a bunch of interoperability headaches that come with them. The verdict is that this functionality is undesirable ✨ So the doc explains why it should be removed from an upcoming revision of the core IPv6 spec, which is [RFC2460].

Status of This Memo

ngl this section is the legal-ish boilerplate, but it's important 💜 This document is not an Internet Standards Track spec. It's just published for info 🧚

It's still an IETF product 👑 It reflects the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for that 🙈

For current status, errata, or to send feedback, go to http://www.rfc-editor.org/info/rfc8021 🔗

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the publication date. Please actually read those, because they lay out your rights and restrictions 🫶 Any Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 💖

Table of Contents

1. Introduction ....................................................2
2. Security Implications of the Generation of IPv6 Atomic
   Fragments .......................................................3
3. Additional Considerations .......................................5
4. Conclusions .....................................................8
5. Security Considerations .........................................8
6. References ......................................................9
   6.1. Normative References .......................................9
   6.2. Informative References ....................................10
Acknowledgements ..................................................12
Authors' Addresses ................................................12

1. Introduction ✨

okay so [RFC2460] is where the IPv6 fragmentation mechanism lives 🦋 It lets IPv6 packets get split into smaller pieces so they fit within the Path MTU to the intended destination(s). Iconic, right?

Now here's the drama 🙈 A legacy IPv4/IPv6 translator running the Stateless IP/ICMP Translation Algorithm [RFC6145] can legitimately send ICMPv6 "Packet Too Big" (PTB) error messages [RFC4443] advertising an MTU smaller than 1280, which is the minimum IPv6 MTU. Section 5 of [RFC2460] says that when a host gets one of these, it's not required to reduce its assumed Path MTU. It just has to include a Fragment Header in all subsequent packets to that destination 💅

So those packets don't actually get split into pieces. They become "atomic" fragments [RFC6946], meaning they just carry a Fragment Header where the Fragment Offset and the M flag are both set to 0 🎀 [RFC6946] says these atomic fragments should basically be processed by the destination host(s) as non-fragmented traffic, since there's nothing real to reassemble 💀 The whole point is just to pass along an appropriate Identification value for the translators to use on the resulting IPv4 fragments. That's it. That's the whole purpose 😭

Atomic fragments might seem harmless, but they can be used to attack the related IPv6 flows 🔥 And since there's zero real gain from generating them (translators could just come up with an IPv4 Identification value themselves), the authors conclude this functionality is undesirable 🙅‍♀️

Section 2 covers the security implications and a specific Denial-of-Service (DoS) attack that takes advantage of IPv6 fragments being widely dropped on the public Internet 🌸 Section 3 gets into whether generating atomic fragments is actually useful at all 🧚

2. Security Implications of the Generation of IPv6 Atomic Fragments 🔥

okay, the security side of IP fragmentation has been covered at length in [RFC6274] and [RFC7739], so go read those too 📚 The key issue is that an attacker can use atomic fragment generation to trigger fragmentation in an arbitrary IPv6 flow, even when the packets didn't need fragmenting at all 😤 Then they can run any fragmentation-based attack against legacy IPv6 nodes that don't implement [RFC6946]. Basically, fragmenting when it's not needed opens the door to fragmentation attacks for no reason. Not slay 🙅‍♀️

Now the plot twist 🙈 Even nodes that do implement [RFC6946] can still get DoS'd because of atomic fragments. Picture this: Host A is talking to Host B, and because IPv6 packets with extension headers (including fragmentation) are widely dropped [RFC7872], some middle node filters fragments between Host B and Host A. Now an attacker sends a forged ICMPv6 PTB error to Host B, reporting an MTU under 1280. From then on, Host B generates atomic fragments (as [RFC2460] requires). Those get dropped, because the path was already dropping extension-header packets. Result: a DoS 💀

Another scenario is two BGP peers running IPv6 transport that use Access Control Lists (ACLs) to drop IPv6 fragments to protect the control plane 🫶 If they drop fragments but still honor received ICMPv6 PTB errors, an attacker can just send a PTB message reporting an MTU smaller than 1280 bytes and wreck the peering session. Once that happens, the routers end up dropping their own traffic. Lowkey iconic in the worst way 😭

This attack vector gets worse because of a few things:

  • The attacker doesn't need to forge the IPv6 Source Address of their attack packets. So simple BCP 38 [BCP38] filters don't help as a countermeasure 🙅‍♀️
  • Only the IPv6 addresses in the IPv6 packet embedded in the ICMPv6 payload need to be forged. Filtering devices could try enforcing BCP 38-style filters on that embedded payload, but the attacker's extension headers could make that hard, if not impossible 🌈
  • Lots of implementations don't do the validation checks on received ICMPv6 error messages that Section 5.2 of [RFC4443] recommends and [RFC5927] documents 🙈 In some cases, like when the error supposedly came from a connectionless transport protocol (or some other connectionless protocol encapsulated in IPv6), validating the ICMPv6 error may be virtually impossible. And because of extension headers, the ICMPv6 payload might not even contain anything useful to validate against 😵‍💫
  • When a PTB error like this arrives, the Destination Cache [RFC4861] is usually updated so that any later packets to that destination include a Fragment Header. So one PTB error can affect multiple communication instances (for example, TCP connections) to that destination 🦋
  • As Section 3 notes, SIIT (the Stateless IP/ICMP Translation Algorithm) [RFC6145], including derived protocols like Stateful NAT64 (Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers) [RFC6146], was the only technology using atomic fragments. The catch is that an IPv6 node can't easily limit its exposure by generating atomic fragments only toward IPv4 destinations behind a stateless translator 😩 That's because Section 3.3 of [RFC6052] encourages operators to use a Network-Specific Prefix (NSP) that maps the IPv4 address space into IPv6. When an NSP is in use, IPv6 addresses representing IPv4 nodes (reached through a stateless translator) look exactly like native IPv6 addresses 👀

Part 1 ends here, bestie. More parts are coming 💖

3. Additional Considerations 💅

Okay so, besides the security assessment in Section 2, it's lowkey so interesting to weigh the pros and cons of having an IPv6-to-IPv4 translating router rely on the generation of IPv6 atomic fragments 🧚

Relying on the generation of IPv6 atomic fragments means relying on:

  1. ICMPv6 packets arriving from the translator to the destination IPv6 node
  2. The ability of the nodes receiving ICMPv6 PTB messages reporting an MTU smaller than 1280 bytes to actually produce atomic fragments
  3. Support for IPv6 fragmentation on the IPv6 side of the translator
  4. The ability of the translator implementation to access the information conveyed by the Fragment Header
  5. The value extracted from the low-order 16 bits of the IPv6 fragment header Identification field resulting in an appropriate IPv4 Identification value

Unfortunately, 😭

  1. There's a fair share of evidence of ICMPv6 PTB error messages being dropped on the public Internet (for instance, that's one of the reasons Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] was produced). So relying on those messages being successfully delivered will affect the robustness of any protocol that depends on them. 🥺
  2. A number of IPv6 implementations have been known to fail to generate IPv6 atomic fragments in response to ICMPv6 PTB messages reporting an MTU smaller than 1280 bytes. On top of that, the results in Section 6 of [RFC6145] note that 57% of the tested web servers failed to produce IPv6 atomic fragments in response to ICMPv6 PTB messages reporting an MTU smaller than 1280 bytes. So any protocol relying on IPv6 atomic fragment generation for proper functioning will have interoperability problems with those IPv6 stacks. 💀
  3. IPv6 atomic fragment generation is a case where fragmented traffic is produced when it otherwise wouldn't be needed. Since there's widespread dropping of IPv6 fragments in the public Internet [RFC7872], this means the (unnecessary) use of IPv6 fragmentation might unnecessarily end up in a DoS situation even in legitimate cases. 🚨
  4. The packet-handling API at the node where the translator is running may obscure fragmentation-related information. In those scenarios, the information conveyed by the Fragment Header may be unavailable to the translator. [JOOL] discusses a sample framework (Linux Netfilter) that hinders access to the information conveyed in IPv6 fragments. 🙈
  5. While [RFC2460] requires that the IPv6 fragment header Identification field of a fragmented packet be different from that of any other fragmented packet sent recently with the same Source Address and Destination Address, there's no requirement on the low-order 16 bits of that value. So there's no guarantee that IPv4 fragment Identification collisions will be avoided or reduced by using the low-order 16 bits of the IPv6 fragment header Identification field of a packet sent by a source host. Plus, collisions might occur where two distinct IPv6 Destination Addresses are translated into the same IPv4 address, so Identification values that were meant to be unique in the context of IPv6 can end up colliding once they're used in translated IPv4. 🌀

We note that SIIT basically uses the Fragment Header of IPv6 atomic fragments to tell the translator how to set the Don't Fragment (DF) bit of IPv4 datagrams. The DF bit is cleared when the IPv6 packet contains a Fragment Header, and it's otherwise set to 1 when the IPv6 packet doesn't contain one. Additionally, the translator will use the low-order 16 bits of the IPv6 fragment header Identification field to set the IPv4 Identification. At least in theory, this is expected to reduce the IPv4 Identification collision rate in the following specific scenario: 🦋

  1. An IPv6 node communicates with an IPv4 node (through SIIT).
  2. The IPv4 node is located behind an IPv4 link with an MTU smaller than 1260 bytes. An IPv4 Path MTU of 1260 corresponds to an IPv6 Path MTU of 1280, because an optionless IPv4 header is 20 bytes shorter than the IPv6 header.
  3. ECMP routing [RFC2992] with more than one translator is employed, for example, for redundancy purposes.

In that scenario, if each translator selected the IPv4 Identification on its own (rather than taking it from the low-order 16 bits of the fragment Identification of IPv6 atomic fragments), this could possibly lead to IPv4 Identification collisions. However, as noted above, the value extracted from the low-order 16 bits of the IPv6 fragment header Identification field might not result in an appropriate IPv4 Identification. For example, a number of implementations set the IPv6 fragment header Identification field according to the output of a Pseudorandom Number Generator (PRNG) (see Appendix B of [RFC7739]). So if the translator only uses the low-order 16 bits of such a value, it's very unlikely that relying on the fragment Identification of the IPv6 atomic fragment will reduce the IPv4 Identification collision rate (compared to the case where the translator selects each IPv4 Identification on its own). 🤷‍♀️ Also, because the IPv4 Identification field is so small, it's virtually impossible to guarantee uniqueness of the IPv4 Identification values without artificially limiting the data rate of fragmented traffic [RFC6864] [RFC4963].

[RFC6145] was the only "consumer" of IPv6 atomic fragments, and it correctly and diligently noted (in its Section 6) the possible interoperability problems of relying on IPv6 atomic fragments. It even proposed a workaround that led to more robust behavior and simplified code. 👑 [RFC6145] has since been obsoleted by [RFC7915], so SIIT doesn't rely on IPv6 atomic fragments anymore. ✨

4. Conclusions 🎀

Taking all of the above into account, we recommend that IPv6 atomic fragments be deprecated. 🫶

In particular:

  • IPv4/IPv6 translators should be updated to not generate ICMPv6 PTB error messages containing an MTU value smaller than the minimum IPv6 MTU of 1280 bytes. This will ensure that current IPv6 nodes will never have a legitimate need to start generating IPv6 atomic fragments. 🌸
  • The recommendation in the previous bullet ensures that there are no longer any valid reasons for ICMPv6 PTB error messages reporting an MTU value smaller than the minimum IPv6 MTU (1280 bytes). IPv6 nodes should therefore be updated to ignore ICMPv6 PTB error messages reporting an MTU smaller than 1280 bytes as invalid. 🍓

We note that these recommendations have been incorporated in [IPv6-PMTUD], [IPv6-Spec], and [RFC7915]. 💖

5. Security Considerations 🔥

This document briefly discusses the security implications of generating IPv6 atomic fragments, and it describes one specific DoS attack vector that leverages the widespread dropping of IPv6 fragments in the public Internet. It's a serious one, bestie. ⚠️ It concludes that generating IPv6 atomic fragments is an undesirable feature, and it documents the motivation for removing this functionality from [IPv6-Spec]. 🌈

6. References 📚

6.1. Normative References

[RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
           (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
           December 1998, <http://www.rfc-editor.org/info/rfc2460>.

[BCP38]    Ferguson, P. and D. Senie, "Network Ingress Filtering:
           Defeating Denial of Service Attacks which employ IP Source
           Address Spoofing", BCP 38, RFC 2827, May 2000,
           <http://www.rfc-editor.org/info/rfc2827>.

[RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
           Control Message Protocol (ICMPv6) for the Internet
           Protocol Version 6 (IPv6) Specification", RFC 4443,
           DOI 10.17487/RFC4443, March 2006,
           <http://www.rfc-editor.org/info/rfc4443>.

[RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
           Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
           <http://www.rfc-editor.org/info/rfc4821>.

[RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
           "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
           DOI 10.17487/RFC4861, September 2007,
           <http://www.rfc-editor.org/info/rfc4861>.

[RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
           Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
           <http://www.rfc-editor.org/info/rfc6145>.

[RFC7915]  Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
           "IP/ICMP Translation Algorithm", RFC 7915,
           DOI 10.17487/RFC7915, June 2016,
           <http://www.rfc-editor.org/info/rfc7915>.

[RFC6864]  Touch, J., "Updated Specification of the IPv4 ID Field",
           RFC 6864, DOI 10.17487/RFC6864, February 2013,
           <http://www.rfc-editor.org/info/rfc6864>.

6.2. Informative References 📚✨

okay bestie, these are the extra reading 🧚 the bibliography that gives you the full backstory 💅

Acknowledgements 🫶

The authors would like to thank (in alphabetical order) Congxiao Bao, Bob Briscoe, Carlos Jesus Bernardos Cano, Brian Carpenter, Bob Hinden, Tatuya Jinmei, Alberto Leiva Popper, Ted Lemon, Xing Li, Jeroen Massar, Erik Nordmark, Qiong Sun, Joe Touch, Ole Troan, Tina Tsou, and Bernie Volz for providing valuable comments on earlier versions of this document. The whole group chat is iconic 👑

Fernando Gont would like to thank Jan Zorz / Go6 Lab <http://go6lab.si/>, and Jared Mauch / NTT America, for providing access to systems and networks that were employed to produce some of the tests that resulted in the publication of this document. Additionally, he would like to thank Ivan Arce, Guillermo Gont, and Diego Armando Maradona for their inspiration. 💜⭐

Authors' Addresses 💌

Fernando Gont
SI6 Networks / UTN-FRH
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires  1706
Argentina

Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI:   http://www.si6networks.com


Will (Shucheng) Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen  518129
China

Email: liushucheng@huawei.com


Tore Anderson
Redpill Linpro
Vitaminveien 1A
Oslo  0485
Norway

Phone: +47 959 31 212
Email: tore@redpill-linpro.com
URI:   http://www.redpill-linpro.com

And that's the whole RFC, bestie! 🌈✨ Go show your friends how the fragments work, periodt 💅🎀

📦 where this page comes from