idnits 2.17.1 draft-ietf-6man-ipv6-atomic-fragments-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2460, updated by this document, for RFC5378 checks: 1997-07-30) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 29, 2012) is 4129 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-03) exists of draft-gont-6man-predictable-fragment-id-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 maintenance Working Group (6man) F. Gont 3 Internet-Draft Huawei Technologies 4 Updates: 2460, 5722 (if approved) December 29, 2012 5 Intended status: Standards Track 6 Expires: July 2, 2013 8 Processing of IPv6 "atomic" fragments 9 draft-ietf-6man-ipv6-atomic-fragments-03 11 Abstract 13 The IPv6 specification allows packets to contain a Fragment Header 14 without the packet being actually fragmented into multiple pieces (we 15 refer to these packets as "atomic fragments"). Such packets 16 typically result from hosts that have received an ICMPv6 "Packet Too 17 Big" error message that advertises a "Next-Hop MTU" smaller than 1280 18 bytes, and are currently processed by some implementations as 19 "fragmented traffic". Thus, by forging ICMPv6 "Packet Too Big" error 20 messages an attacker can cause hosts to employ "atomic fragments", 21 and then launch any fragmentation-based attacks against such traffic. 22 This document discusses the generation of the aforementioned "atomic 23 fragments", the corresponding security implications, and formally 24 updates RFC 2460 and RFC 5722 such that fragmentation-based attack 25 vectors against traffic employing "atomic fragments" are completely 26 eliminated. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 2, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Generation of IPv6 'atomic fragments' . . . . . . . . . . . . 6 65 4. Updating RFC 2460 and RFC 5722 . . . . . . . . . . . . . . . . 8 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 72 Appendix A. Survey of processing of IPv6 atomic fragments by 73 different operating systems . . . . . . . . . . . . . 13 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 [RFC2460] specifies the IPv6 fragmentation mechanism, which allows 79 IPv6 packets to be fragmented into smaller pieces such that they fit 80 in the Path-MTU to the intended destination(s). [RFC2460] allowed 81 fragments to overlap, thus leading to ambiguity in the result of the 82 reassembly process, which could be leveraged by attackers to bypass 83 firewall rules and/or evade Network Intrusion Detection Systems 84 (NIDS) [RFC5722]. 86 [RFC5722] forbid overlapping fragments, specifying that when 87 overlapping fragments are detected, all the fragments corresponding 88 to that packet must be silently discarded. 90 As specified in Section 5 of [RFC2460], when a host receives an 91 ICMPv6 "Packet Too Big" message advertising a "Next-Hop MTU" smaller 92 than 1280 (the minimum IPv6 MTU), it is not required to reduce the 93 assumed Path-MTU, but must simply include a Fragment Header in all 94 subsequent packets sent to that destination. The resulting packets 95 will thus *not* be actually fragmented into several pieces, but just 96 include a Fragment Header with both the "Fragment Offset" and the "M" 97 bit set to 0 (we refer to these packets as "atomic fragments"). 98 IPv6/IPv4 translators employ the Fragment Identification information 99 found in the Fragment Header to select an appropriate Fragment 100 Identification value for the resulting IPv4 fragments. 102 While these packets are really "atomic fragments" (they can be 103 processed by the IPv6 module and handed to the upper-layer protocol 104 without waiting for any other fragments), many IPv6 implementations 105 process them as regular fragments. Namely, they try to perform IPv6 106 fragment reassembly with the "atomic fragment" and any other 107 fragments already queued with the same set {IPv6 Source Address, IPv6 108 Destination Address, Fragment Identification}. For example, in the 109 case of IPv6 implementations that have been updated to support 110 [RFC5722], if a fragment with the same {IPv6 Source Address, IPv6 111 Destination Address, Fragment Identification} is already queued for 112 reassembly at a host when an "atomic fragment" is received with the 113 same set {IPv6 Source Address, IPv6 Destination Address, Fragment 114 Identification}, and both fragments overlap, all the fragments will 115 be silently discarded. 117 Processing of IPv6 "atomic fragments" as regular fragmented packets 118 clearly provides an unnecessary vector to perform fragmentation-based 119 attacks against non-fragmented traffic (i.e., IPv6 datagrams that are 120 not really split into multiple pieces, but that just include a 121 Fragment Header). 123 IPv6 fragmentation attacks have been discussed in great detail in 125 [I-D.gont-6man-predictable-fragment-id] and [CPNI-IPv6], and 126 [RFC5722] describes a specific firewall-circumvention attack that 127 could be performed by leveraging overlapping fragments. The possible 128 IPv6 fragmentation-based attacks are, in most cases, "ports" of the 129 IPv4 fragmentation attacks discussed in [RFC6274]. 131 Section 3 describes the generation of IPv6 "atomic fragments", and 132 how they can be remotely "triggered" by a remote attacker. Section 4 133 formally updates [RFC2460] and [RFC5722] such that the aforementioned 134 attack vector is eliminated. Appendix A contains a survey of the 135 generation and processing of IPv6 atomic fragments in different 136 versions of a number of popular IPv6 implementations. 138 2. Terminology 140 IPv6 atomic fragments 141 IPv6 packets that contain a Fragment Header with the Fragment 142 Offset set to 0 and the M bit set to 0. 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 3. Generation of IPv6 'atomic fragments' 150 Section 5 of [RFC2460] states: 152 In response to an IPv6 packet that is sent to an IPv4 destination 153 (i.e., a packet that undergoes translation from IPv6 to IPv4), the 154 originating IPv6 node may receive an ICMP Packet Too Big message 155 reporting a Next-Hop MTU less than 1280. In that case, the IPv6 156 node is not required to reduce the size of subsequent packets to 157 less than 1280, but must include a Fragment header in those 158 packets so that the IPv6-to-IPv4 translating router can obtain a 159 suitable Identification value to use in resulting IPv4 fragments. 160 Note that this means the payload may have to be reduced to 1232 161 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment 162 header), and smaller still if additional extension headers are 163 used. 165 This means that any ICMPv6 "Packet Too Big" message advertising a 166 "Next-Hop MTU" smaller than 1280 could trigger the generation of the 167 so-called "atomic fragments" (i.e., IPv6 datagrams that include a 168 Fragment Header, but that are composed of a single fragment, with 169 both the "Fragment Offset" and the "M" fields of the Fragment Header 170 set to 0). This can be leveraged to perform a variety of 171 fragmentation-based attacks [I-D.gont-6man-predictable-fragment-id] 172 [CPNI-IPv6]. 174 From a security standpoint, this situation is exacerbated by the 175 following factors: 177 o Many implementations fail to perform validation checks on the 178 received ICMPv6 error messages, as recommended in Section 5.2 of 179 [RFC4443] and [RFC5927]. It should be noted that in some cases, 180 such as when an ICMPv6 error message has (supposedly) been 181 elicited by a connection-less transport protocol (or some other 182 connection-less protocol being encapsulated in IPv6), it may be 183 virtually impossible to perform validation checks on the received 184 ICMPv6 error messages. 186 o Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big" 187 error messages, the Destinations Cache is usually updated to 188 reflect that any subsequent packets to such destination should 189 include a Fragment Header. This means that a single ICMPv6 190 "Packet Too Big" error message might affect multiple communication 191 instances (e.g., TCP connections) with such destination. 193 o Some implementations employ predictable Fragment Identification 194 values, thus greatly improving the chances of an attacker of 195 successfully performing fragmentation-based attacks 197 [I-D.gont-6man-predictable-fragment-id]. 199 4. Updating RFC 2460 and RFC 5722 201 Section 4.5 of [RFC2460] and Section 4 of [RFC5722] are updated as 202 follows: 204 A host that receives an IPv6 packet which includes a Fragment 205 Header with the "Fragment Offset" equal to 0 and the "M" bit equal 206 to 0 MUST process such packet in isolation from any other packets/ 207 fragments, even if such packets/fragments contain the same set 208 {IPv6 Source Address, IPv6 Destination Address, Fragment 209 Identification}. A received "atomic fragments" should be 210 "reassembled" from the contents of that sole fragment. 212 The Unfragmentable Part of the reassembled packet consists of 213 all headers up to, but not including, the Fragment header of 214 the received atomic fragment. 216 The Next Header field of the last header of the Unfragmentable 217 Part of the reassembled packet is obtained from the Next Header 218 field of the Fragment header of the received atomic fragment. 220 The Payload Length of the reassembled packet is obtained by 221 substracting the length of the Fragment Header (that is, 8) 222 from the Payload Length of the received atomic fragment. 224 Additionally, if any fragments with the same set {IPV6 Source 225 Address, IPv6 Destination Address, Fragment Identification} are 226 present in the fragment reassembly queue when the atomic fragment 227 is received, such fragments MUST NOT be discarded upon receipt of 228 the "colliding" IPv6 atomic fragment, since IPv6 atomic fragments 229 MUST NOT interfere with "normal" fragmented traffic. 231 5. IANA Considerations 233 There are no IANA registries within this document. The RFC-Editor 234 can remove this section before publication of this document as an 235 RFC. 237 6. Security Considerations 239 This document describes how an attacker can exploit ICMPv6 "Packet 240 Too Big" error messages to cause further IPv6 packets to include a 241 Fragment Header, such that he can perform any fragmentation-based 242 attack against otherwise non-fragmented traffic. This document 243 updates [RFC2460] and [RFC5722], such that the aforementioned attack 244 vector is completely eliminated. 246 7. Acknowledgements 248 The author would like to thank (in alphabetical order) Tore Anderson, 249 Ran Atkinson, Remi Despres, Brian Haberman, Timothy Hartrick, Steinar 250 Haug, Philip Homburg, Simon Perreault, Florian Weimer, and Bjoern A. 251 Zeeb, for providing valuable comments on earlier versions of this 252 document. Additionally, the author would like to thank Alexander 253 Bluhm, who implemented this specification for OpenBSD. 255 This document is based on the technical report "Security Assessment 256 of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by 257 Fernando Gont on behalf of the UK Centre for the Protection of 258 National Infrastructure (CPNI). 260 Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for 261 their continued support. 263 8. References 265 8.1. Normative References 267 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 268 (IPv6) Specification", RFC 2460, December 1998. 270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", BCP 14, RFC 2119, March 1997. 273 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 274 Message Protocol (ICMPv6) for the Internet Protocol 275 Version 6 (IPv6) Specification", RFC 4443, March 2006. 277 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 278 RFC 5722, December 2009. 280 8.2. Informative References 282 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 284 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 285 Version 4", RFC 6274, July 2011. 287 [CPNI-IPv6] 288 Gont, F., "Security Assessment of the Internet Protocol 289 version 6 (IPv6)", UK Centre for the Protection of 290 National Infrastructure, (available on request). 292 [I-D.gont-6man-predictable-fragment-id] 293 Gont, F., "Security Implications of Predictable Fragment 294 Identification Values", 295 draft-gont-6man-predictable-fragment-id-02 (work in 296 progress), March 2012. 298 Appendix A. Survey of processing of IPv6 atomic fragments by different 299 operating systems 301 This section includes a survey of the support of IPv6 atomic 302 fragments in popular operating systems, as tested in October 30, 303 2012. 305 +---------------------+---------------------+-----------------------+ 306 | Operating System | Generates atomic | Implements this | 307 | | fragments | specification | 308 +---------------------+---------------------+-----------------------+ 309 | FreeBSD 8.0 | No | No | 310 +---------------------+---------------------+-----------------------+ 311 | FreeBSD 8.2 | Yes | No | 312 +---------------------+---------------------+-----------------------+ 313 | FreeBSD 9.0 | Yes | No | 314 +---------------------+---------------------+-----------------------+ 315 | Linux 3.0.0-15 | Yes | Yes | 316 +---------------------+---------------------+-----------------------+ 317 | NetBSD 5.1 | No | No | 318 +---------------------+---------------------+-----------------------+ 319 | NetBSD-current | No | Yes | 320 +---------------------+---------------------+-----------------------+ 321 | OpenBSD-current | Yes | Yes | 322 +---------------------+---------------------+-----------------------+ 323 | Solaris 11 | Yes | Yes | 324 +---------------------+---------------------+-----------------------+ 325 | Windows XP SP2 | Yes | No | 326 +---------------------+---------------------+-----------------------+ 327 | Windows Vista | Yes | No | 328 | (Build 6000) | | | 329 +---------------------+---------------------+-----------------------+ 330 | Windows 7 Home | Yes | No | 331 | Premium | | | 332 +---------------------+---------------------+-----------------------+ 334 Table 1: Processing of IPv6 atomic fragments by different OSes 336 In the table above, "generates atomic fragments" notes whether an 337 implementation generates atomic fragments in response to receved 338 ICMPv6 Packet Too Big error messages that advertise a MTU smaller 339 than 1280 bytes. 341 Author's Address 343 Fernando Gont 344 Huawei Technologies 345 Evaristo Carriego 2644 346 Haedo, Provincia de Buenos Aires 1706 347 Argentina 349 Phone: +54 11 4650 8472 350 Email: fgont@si6networks.com