idnits 2.17.1 draft-ietf-6man-ipv6-atomic-fragments-04.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 (March 21, 2013) is 4048 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) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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) March 21, 2013 5 Intended status: Standards Track 6 Expires: September 22, 2013 8 Processing of IPv6 "atomic" fragments 9 draft-ietf-6man-ipv6-atomic-fragments-04 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 are 16 typically sent by hosts that have received an ICMPv6 "Packet Too Big" 17 error message that advertises a "Next-Hop MTU" smaller than 1280 18 bytes, and are currently processed by some implementations as normal 19 "fragmented traffic" (i.e., they are "reassembled" with any other 20 queued fragments that supposedly correspond to the same original 21 packet). Thus, an attacker can cause hosts to employ "atomic 22 fragments" by forging ICMPv6 "Packet Too Big" error messages, and 23 then launch any fragmentation-based attacks against such traffic. 24 This document discusses the generation of the aforementioned "atomic 25 fragments" and the corresponding security implications. 26 Additionally, this document formally updates RFC 2460 and RFC 5722 27 such that IPv6 atomic fragments are processed independently of any 28 other fragments, thus completely eliminating the aforementioned 29 attack vector. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 22, 2013. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Generation of IPv6 'atomic fragments' . . . . . . . . . . . . 6 67 4. Updating RFC 2460 and RFC 5722 . . . . . . . . . . . . . . . . 8 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 74 Appendix A. Survey of processing of IPv6 atomic fragments by 75 different operating systems . . . . . . . . . . . . . 13 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 [RFC2460] specifies the IPv6 fragmentation mechanism, which allows 81 IPv6 packets to be fragmented into smaller pieces such that they fit 82 in the Path-MTU to the intended destination(s). [RFC2460] allowed 83 fragments to overlap, thus leading to ambiguity in the result of the 84 reassembly process, which could be leveraged by attackers to bypass 85 firewall rules and/or evade Network Intrusion Detection Systems 86 (NIDS) [RFC5722]. 88 [RFC5722] forbid overlapping fragments, specifying that when 89 overlapping fragments are detected, all the fragments corresponding 90 to that packet must be silently discarded. 92 As specified in Section 5 of [RFC2460], when a host receives an 93 ICMPv6 "Packet Too Big" message advertising a "Next-Hop MTU" smaller 94 than 1280 (the minimum IPv6 MTU), it is not required to reduce the 95 assumed Path-MTU, but must simply include a Fragment Header in all 96 subsequent packets sent to that destination. The resulting packets 97 will thus *not* be actually fragmented into several pieces, but just 98 include a Fragment Header with both the "Fragment Offset" and the "M" 99 flag set to 0 (we refer to these packets as "atomic fragments"). 100 IPv6/IPv4 translators employ the Fragment Identification information 101 found in the Fragment Header to select an appropriate Fragment 102 Identification value for the resulting IPv4 fragments. 104 While these packets are really "atomic fragments" (they can be 105 processed by the IPv6 module and handed to the upper-layer protocol 106 without waiting for any other fragments), many IPv6 implementations 107 process them as regular fragments. Namely, they try to perform IPv6 108 fragment reassembly with the "atomic fragment" and any other 109 fragments already queued with the same set {IPv6 Source Address, IPv6 110 Destination Address, Fragment Identification}. For example, in the 111 case of IPv6 implementations that have been updated to support 112 [RFC5722], if a fragment with the same {IPv6 Source Address, IPv6 113 Destination Address, Fragment Identification} is already queued for 114 reassembly at a host when an "atomic fragment" is received with the 115 same set {IPv6 Source Address, IPv6 Destination Address, Fragment 116 Identification}, and both fragments overlap, all the fragments will 117 be silently discarded. 119 Processing of IPv6 "atomic fragments" as regular fragmented packets 120 clearly provides an unnecessary vector to perform fragmentation-based 121 attacks against non-fragmented traffic (i.e., IPv6 datagrams that are 122 not really split into multiple pieces, but that just include a 123 Fragment Header). 125 IPv6 fragmentation attacks have been discussed in great detail in 127 [I-D.gont-6man-predictable-fragment-id] and [CPNI-IPv6], and 128 [RFC5722] describes a specific firewall-circumvention attack that 129 could be performed by leveraging overlapping fragments. The possible 130 IPv6 fragmentation-based attacks are, in most cases, "ports" of the 131 IPv4 fragmentation attacks discussed in [RFC6274]. 133 Section 3 describes the generation of IPv6 "atomic fragments", and 134 how they can be remotely "triggered" by a remote attacker. Section 4 135 formally updates [RFC2460] and [RFC5722] such that the aforementioned 136 attack vector is eliminated. Appendix A contains a survey of the 137 generation and processing of IPv6 atomic fragments in different 138 versions of a number of popular IPv6 implementations. 140 2. Terminology 142 IPv6 atomic fragments 143 IPv6 packets that contain a Fragment Header with the Fragment 144 Offset set to 0 and the M flag set to 0. 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119 [RFC2119]. 150 3. Generation of IPv6 'atomic fragments' 152 Section 5 of [RFC2460] states: 154 In response to an IPv6 packet that is sent to an IPv4 destination 155 (i.e., a packet that undergoes translation from IPv6 to IPv4), the 156 originating IPv6 node may receive an ICMP Packet Too Big message 157 reporting a Next-Hop MTU less than 1280. In that case, the IPv6 158 node is not required to reduce the size of subsequent packets to 159 less than 1280, but must include a Fragment header in those 160 packets so that the IPv6-to-IPv4 translating router can obtain a 161 suitable Identification value to use in resulting IPv4 fragments. 162 Note that this means the payload may have to be reduced to 1232 163 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment 164 header), and smaller still if additional extension headers are 165 used. 167 This means that any ICMPv6 "Packet Too Big" message advertising a 168 "Next-Hop MTU" smaller than 1280 could trigger the generation of the 169 so-called "atomic fragments" (i.e., IPv6 datagrams that include a 170 Fragment Header, but that are composed of a single fragment, with 171 both the "Fragment Offset" and the "M" fields of the Fragment Header 172 set to 0). This can be leveraged to perform a variety of 173 fragmentation-based attacks [I-D.gont-6man-predictable-fragment-id] 174 [CPNI-IPv6]. 176 For example, an attacker could forge IPv6 fragments with an 177 appropriate {IPv6 Source Address, IPv6 Destination Address, 178 Fragment Identification} tuple, such that these malicious 179 fragments are incorrectly "reassembled" by the destination host 180 together with some of the legitimate fragments of the original 181 packet, thus leading to packet drops (and a potential Denial of 182 Service). 184 From a security standpoint, this situation is exacerbated by the 185 following factors: 187 o Many implementations fail to perform validation checks on the 188 received ICMPv6 error messages, as recommended in Section 5.2 of 189 [RFC4443] and documented in [RFC5927]. It should be noted that in 190 some cases, such as when an ICMPv6 error message has (supposedly) 191 been elicited by a connection-less transport protocol (or some 192 other connection-less protocol being encapsulated in IPv6), it may 193 be virtually impossible to perform validation checks on the 194 received ICMPv6 error messages. 196 o Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big" 197 error messages, the Destination Cache [RFC4861] is usually updated 198 to reflect that any subsequent packets to such destination should 199 include a Fragment Header. This means that a single ICMPv6 200 "Packet Too Big" error message might affect multiple communication 201 instances (e.g., TCP connections) with such destination. 203 o Some implementations employ predictable Fragment Identification 204 values, thus greatly improving the chances of an attacker of 205 successfully performing fragmentation-based attacks 206 [I-D.gont-6man-predictable-fragment-id]. 208 4. Updating RFC 2460 and RFC 5722 210 Section 4.5 of [RFC2460] and Section 4 of [RFC5722] are updated as 211 follows: 213 A host that receives an IPv6 packet which includes a Fragment 214 Header with the "Fragment Offset" equal to 0 and the "M" flag 215 equal to 0 MUST process such packet in isolation from any other 216 packets/fragments, even if such packets/fragments contain the same 217 set {IPv6 Source Address, IPv6 Destination Address, Fragment 218 Identification}. A received "atomic fragments" should be 219 "reassembled" from the contents of that sole fragment. 221 The Unfragmentable Part of the reassembled packet consists of 222 all headers up to, but not including, the Fragment header of 223 the received atomic fragment. 225 The Next Header field of the last header of the Unfragmentable 226 Part of the reassembled packet is obtained from the Next Header 227 field of the Fragment header of the received atomic fragment. 229 The Payload Length of the reassembled packet is obtained by 230 subtracting the length of the Fragment Header (that is, 8) from 231 the Payload Length of the received atomic fragment. 233 Additionally, if any fragments with the same set {IPv6 Source 234 Address, IPv6 Destination Address, Fragment Identification} are 235 present in the fragment reassembly queue when the atomic fragment 236 is received, such fragments MUST NOT be discarded upon receipt of 237 the "colliding" IPv6 atomic fragment, since IPv6 atomic fragments 238 MUST NOT interfere with "normal" fragmented traffic. 240 5. IANA Considerations 242 There are no IANA registries within this document. The RFC-Editor 243 can remove this section before publication of this document as an 244 RFC. 246 6. Security Considerations 248 This document describes how the traditional processing of IPv6 atomic 249 fragments enables the exploitation of fragmentation-based attacks 250 (such as those described in [I-D.gont-6man-predictable-fragment-id] 251 and [CPNI-IPv6]). This document formally updates [RFC2460] and 252 [RFC5722], such that IPv6 atomic fragments are processed 253 independently of any other fragments, thus completely eliminating the 254 aforementioned attack vector. 256 7. Acknowledgements 258 The author would like to thank (in alphabetical order) Tore Anderson, 259 Ran Atkinson, Remi Despres, Stephen Farrell, Brian Haberman, Timothy 260 Hartrick, Steinar Haug, Philip Homburg, Simon Josefsson, Simon 261 Perreault, Sean Turner, Florian Weimer, and Bjoern A. Zeeb, for 262 providing valuable comments on earlier versions of this document. 263 Additionally, the author would like to thank Alexander Bluhm, who 264 implemented this specification for OpenBSD. 266 This document is based on the technical report "Security Assessment 267 of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by 268 Fernando Gont on behalf of the UK Centre for the Protection of 269 National Infrastructure (CPNI). 271 Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for 272 their continued support. 274 8. References 276 8.1. Normative References 278 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 279 (IPv6) Specification", RFC 2460, December 1998. 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, March 1997. 284 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 285 Message Protocol (ICMPv6) for the Internet Protocol 286 Version 6 (IPv6) Specification", RFC 4443, March 2006. 288 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 289 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 290 September 2007. 292 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 293 RFC 5722, December 2009. 295 8.2. Informative References 297 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 299 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 300 Version 4", RFC 6274, July 2011. 302 [CPNI-IPv6] 303 Gont, F., "Security Assessment of the Internet Protocol 304 version 6 (IPv6)", UK Centre for the Protection of 305 National Infrastructure, (available on request). 307 [I-D.gont-6man-predictable-fragment-id] 308 Gont, F., "Security Implications of Predictable Fragment 309 Identification Values", 310 draft-gont-6man-predictable-fragment-id-03 (work in 311 progress), January 2013. 313 Appendix A. Survey of processing of IPv6 atomic fragments by different 314 operating systems 316 This section includes a survey of the support of IPv6 atomic 317 fragments in popular operating systems, as tested in October 30, 318 2012. 320 +---------------------+---------------------+-----------------------+ 321 | Operating System | Generates atomic | Implements this | 322 | | fragments | specification | 323 +---------------------+---------------------+-----------------------+ 324 | FreeBSD 8.0 | No | No | 325 +---------------------+---------------------+-----------------------+ 326 | FreeBSD 8.2 | Yes | No | 327 +---------------------+---------------------+-----------------------+ 328 | FreeBSD 9.0 | Yes | No | 329 +---------------------+---------------------+-----------------------+ 330 | Linux 3.0.0-15 | Yes | Yes | 331 +---------------------+---------------------+-----------------------+ 332 | NetBSD 5.1 | No | No | 333 +---------------------+---------------------+-----------------------+ 334 | NetBSD-current | No | Yes | 335 +---------------------+---------------------+-----------------------+ 336 | OpenBSD-current | Yes | Yes | 337 +---------------------+---------------------+-----------------------+ 338 | Solaris 11 | Yes | Yes | 339 +---------------------+---------------------+-----------------------+ 340 | Windows XP SP2 | Yes | No | 341 +---------------------+---------------------+-----------------------+ 342 | Windows Vista | Yes | No | 343 | (Build 6000) | | | 344 +---------------------+---------------------+-----------------------+ 345 | Windows 7 Home | Yes | No | 346 | Premium | | | 347 +---------------------+---------------------+-----------------------+ 349 Table 1: Processing of IPv6 atomic fragments by different OSes 351 In the table above, "generates atomic fragments" notes whether an 352 implementation generates atomic fragments in response to received 353 ICMPv6 Packet Too Big error messages that advertise a MTU smaller 354 than 1280 bytes. 356 Author's Address 358 Fernando Gont 359 Huawei Technologies 360 Evaristo Carriego 2644 361 Haedo, Provincia de Buenos Aires 1706 362 Argentina 364 Phone: +54 11 4650 8472 365 Email: fgont@si6networks.com