RFC 6946

Processing of IPv6 "Atomic" Fragments

📅 published May 2013, from ietf

Hiii bestie 🎀✨ okay so this is RFC 6946, "Processing of IPv6 "Atomic" Fragments," and it's a total main character of the IPv6 world 👑

Quick title-block tea ☕ It's by F. Gont from Huawei Technologies (the IETF's own author, iconic 🫶). It's dated May 2013, it's a Standards Track document (so this is real spec energy, not vibes 💅), and it updates RFC 2460 and RFC 5722. Nothing gets obsoleted here 🙈 Its ISSN is 2070-1721 in case you need to look it up 🌸

Abstract ✨

okay so IPv6 lets packets carry a Fragment Header even when they aren't actually split into pieces. we call these "atomic fragments" 🦋 Hosts usually send them after getting an ICMPv6 "Packet Too Big" error that says the Next-Hop MTU is smaller than 1280 bytes. The problem is that some implementations treat them like normal fragmented traffic and try to "reassemble" them with other queued fragments that supposedly belong to the same original packet 😭

So an attacker can forge ICMPv6 "Packet Too Big" messages to make hosts start using atomic fragments, and then go wild with fragmentation-based attacks on that traffic 💀 This doc talks about how these atomic fragments get generated and what the security fallout is. It also formally updates RFC 2460 and RFC 5722 so that IPv6 atomic fragments get processed independently of any other fragments. That completely kills this attack vector 🔥

Status of This Memo 🌈

This is an Internet Standards Track document 💜

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741 📚

For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6946 🎀

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 👀 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License ⭐

Table of Contents 🧚

1. Introduction ....................................................2
2. Terminology .....................................................4
3. Generation of IPv6 Atomic Fragments .............................4
4. Updating RFC 2460 and RFC 5722 ..................................5
5. Security Considerations .........................................6
6. Acknowledgements ................................................6
7. References ......................................................7
   7.1. Normative References .......................................7
   7.2. Informative References .....................................7
Appendix A. Survey of Processing of IPv6 Atomic Fragments by
            Different Operating Systems ............................8

1. Introduction 🍓

okay so [RFC2460] is the spec for IPv6 fragmentation. It lets IPv6 packets get split into smaller pieces so they fit within the Path-MTU to the intended destination(s) ✨ The catch is that [RFC2460] allows fragments to overlap, which makes the reassembly result ambiguous. Attackers can use that to slip past firewall rules and/or dodge Network Intrusion Detection Systems (NIDS) [RFC5722] 😤

[RFC5722] fixes this by forbidding overlapping fragments. If overlapping fragments are detected, all the fragments for that packet must be silently discarded 🙅‍♀️

Now here's the sus part. As specified in Section 5 of [RFC2460], when a host gets an ICMPv6 "Packet Too Big" message advertising a "Next-Hop MTU" smaller than 1280 (the minimum IPv6 MTU), it is not required to reduce its assumed Path-MTU. What it must do is include a Fragment Header in all subsequent packets sent to that destination 🧐 Those packets won't actually be fragmented into several pieces. They just carry a Fragment Header with both the "Fragment Offset" and the "M" flag set to 0. (We call these "atomic fragments," remember 🦋) IPv6/IPv4 translators use the Fragment Identification info in the Fragment Header to pick a suitable Fragment Identification value for the resulting IPv4 fragments 💅

Here's the tea ☕ Atomic fragments are really atomic. The IPv6 module can process them and hand them to the upper-layer protocol without waiting for any other fragments. But lots of IPv6 implementations process them as regular fragments anyway 😭 They try to reassemble the atomic fragment with any other fragments already queued with the same set {IPv6 Source Address, IPv6 Destination Address, Fragment Identification}. For example, say an implementation has been updated for [RFC5722]. If a fragment with the same {IPv6 Source Address, IPv6 Destination Address, Fragment Identification} is already queued at a host, and an atomic fragment with that same set arrives, and the two overlap, then all the fragments get silently discarded 💀

Treating IPv6 atomic fragments like regular fragmented packets is an unnecessary attack vector against non-fragmented traffic. That means IPv6 datagrams that aren't really split up but just carry a Fragment Header 🙄

IPv6 fragmentation attacks are covered in great detail in [PREDICTABLE-ID] and [CPNI-IPv6]. [RFC5722] describes a specific firewall-circumvention attack that uses overlapping fragments. Most of the possible IPv6 fragmentation-based attacks are basically "ports" of the IPv4 fragmentation attacks discussed in [RFC6274] 🧚

So here's the roadmap ✨ Section 3 describes how IPv6 atomic fragments get generated and how a remote attacker can "trigger" them remotely. Section 4 formally updates [RFC2460] and [RFC5722] so this attack vector is gone 🎀 Appendix A is a survey of how different versions of a bunch of popular IPv6 implementations generate and process atomic fragments 🌸

2. Terminology 💜

IPv6 atomic fragments: IPv6 packets that contain a Fragment Header with the Fragment Offset set to 0 and the M flag set to 0.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📖

3. Generation of IPv6 Atomic Fragments 🦋

okay so Section 5 of [RFC2460] says this:

"In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used."

So basically, any ICMPv6 "Packet Too Big" message advertising a "Next-Hop MTU" smaller than 1280 could trigger the generation of these so-called "atomic fragments" 🌈 (IPv6 datagrams with a Fragment Header that are made of a single fragment, with both the "Fragment Offset" and the "M" fields set to 0.) This can be used to run a bunch of fragmentation-based attacks [PREDICTABLE-ID] [CPNI-IPv6] 😈

For example, an attacker could forge IPv6 fragments with a matching {IPv6 Source Address, IPv6 Destination Address, Fragment Identification} tuple. Those malicious fragments then get incorrectly "reassembled" by the destination host together with some legit fragments of the original packet. Result: packet drops and a potential denial of service 🥀

From a security standpoint, things get worse because of these factors:

  • Lots of implementations don't validate received ICMPv6 error messages the way Section 5.2 of [RFC4443] recommends, which is documented in [RFC5927] 🙈 It's worth noting that sometimes, like when an ICMPv6 error message supposedly came from a connectionless transport protocol (or some other connectionless protocol encapsulated in IPv6), validation may be basically impossible.
  • When one of those ICMPv6 "Packet Too Big" error messages arrives, the Destination Cache [RFC4861] is usually updated to say that subsequent packets to that destination should include a Fragment Header. So a single ICMPv6 "Packet Too Big" message could affect multiple communication instances (e.g., TCP connections) with that IPv6 destination address 😱
  • Some implementations use predictable Fragment Identification values, which hugely boosts an attacker's odds of pulling off fragmentation-based attacks [PREDICTABLE-ID] 🎯

(part 1 of 2 ends here, more to come 🦋💖)

5. Security Considerations 🔥

okay bestie, this section is the reason the whole doc exists 😭 so the vibe is: traditional processing of IPv6 atomic fragments lets people pull off fragmentation-based attacks (the kind described in [PREDICTABLE-ID] and [CPNI-IPv6]) 💀 this document formally updates [RFC2460] and [RFC5722] so that IPv6 atomic fragments get processed independently of any other fragments ✨ and that completely wipes out that attack vector 🫶

6. Acknowledgements 🎀

the author wants to thank (in alphabetical order) Tore Anderson, Ran Atkinson, Remi Despres, Stephen Farrell, Brian Haberman, Timothy Hartrick, Steinar Haug, Philip Homburg, Simon Josefsson, Simon Perreault, Sean Turner, Florian Weimer, and Bjoern A. Zeeb 🌸 for giving super valuable comments on earlier versions of this doc 💖 and also Alexander Bluhm, who implemented this spec for OpenBSD 👑

this document is based on the technical report "Security Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6], written by Fernando Gont on behalf of the UK Centre for the Protection of National Infrastructure (CPNI) 🦋

and finally, the author wants to thank Nelida Garcia and Guillermo Gont for their love and support 🥹🫶

7. References 📚

7.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
  • [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
  • [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
  • [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009.

7.2. Informative References

  • [CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request).
  • [PREDICTABLE-ID] Gont, F., "Security Implications of Predictable Fragment Identification Values", Work in Progress, March 2013.
  • [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
  • [RFC6274] Gont, F., "Security Assessment of the Internet Protocol Version 4", RFC 6274, July 2011.

Appendix A. Survey of Processing of IPv6 Atomic Fragments by Different Operating Systems 🧚

this section has a survey of how popular operating systems handle IPv6 atomic fragments, as tested on October 30, 2012 💅

+---------------------+---------------------+-----------------------+
|   Operating System  |   Generates atomic  |    Implements this    |
|                     |      fragments      |     specification     |
+---------------------+---------------------+-----------------------+
|     FreeBSD 8.0     |          No         |           No          |
+---------------------+---------------------+-----------------------+
|     FreeBSD 8.2     |         Yes         |           No          |
+---------------------+---------------------+-----------------------+
|     FreeBSD 9.0     |         Yes         |           No          |
+---------------------+---------------------+-----------------------+
|    Linux 3.0.0-15   |         Yes         |          Yes          |
+---------------------+---------------------+-----------------------+
|      NetBSD 5.1     |          No         |           No          |
+---------------------+---------------------+-----------------------+
|    NetBSD-current   |          No         |          Yes          |
+---------------------+---------------------+-----------------------+
|   OpenBSD-current   |         Yes         |          Yes          |
+---------------------+---------------------+-----------------------+
|      Solaris 11     |         Yes         |          Yes          |
+---------------------+---------------------+-----------------------+
|    Windows XP SP2   |         Yes         |           No          |
+---------------------+---------------------+-----------------------+
|    Windows Vista    |         Yes         |           No          |
|     (Build 6000)    |                     |                       |
+---------------------+---------------------+-----------------------+
|    Windows 7 Home   |         Yes         |           No          |
|       Premium       |                     |                       |
+---------------------+---------------------+-----------------------+

      Table 1: Processing of IPv6 Atomic Fragments by Different OSes

in the table above, "generates atomic fragments" notes whether an implementation generates atomic fragments in response to received ICMPv6 "Packet Too Big" error messages that advertise an MTU smaller than 1280 bytes 🫧

Author's Address 🌈

Fernando Gont Huawei Technologies Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina

Phone: +54 11 4650 8472 EMail: fgont@si6networks.com

📦 where this page comes from