idnits 2.17.1 draft-ietf-6man-ipv6-atomic-fragments-01.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 (August 10, 2012) is 4274 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 UK CPNI 4 Updates: 2460, 5722 (if approved) August 10, 2012 5 Intended status: Standards Track 6 Expires: February 11, 2013 8 Processing of IPv6 "atomic" fragments 9 draft-ietf-6man-ipv6-atomic-fragments-01 11 Abstract 13 The IPv6 specification allows packets to contain a Fragment Header 14 without the packet being actually fragmented into multiple pieces. 15 Such packets typically result from hosts that have received an ICMPv6 16 "Packet Too Big" error message that advertises a "Next-Hop MTU" 17 smaller than 1280 bytes, and are currently processed by some 18 implementations as "fragmented traffic". Thus, by forging ICMPv6 19 "Packet Too Big" error messages an attacker can cause hosts to employ 20 "atomic fragments", and then launch any fragmentation-based attacks 21 against such traffic. This document discusses the generation of the 22 aforementioned "atomic fragments", the corresponding security 23 implications, and formally updates RFC 2460 and RFC 5722 such that 24 fragmentation-based attack vectors against traffic employing "atomic 25 fragments" are completely eliminated. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on February 11, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Generation of IPv6 'atomic fragments' . . . . . . . . . . . . 5 63 3. Updating RFC 2460 and RFC 5722 . . . . . . . . . . . . . . . . 7 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 70 Appendix A. Survey of processing of IPv6 atomic fragments by 71 different operating systems . . . . . . . . . . . . . 12 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 [RFC2460] specifies the IPv6 fragmentation mechanism, which allows 77 IPv6 packets to be fragmented into smaller pieces such that they fit 78 in the Path-MTU to the intended destination(s). [RFC2460] allowed 79 fragments to overlap, thus leading to ambiguity in the result of the 80 reassembly process, which could be leveraged by attackers to bypass 81 firewall rules and/or evade Network Intrusion Detection Systems 82 (NIDS) [RFC5722]. 84 [RFC5722] forbid overlapping fragments, specifying that when 85 overlapping fragments are detected, all the fragments corresponding 86 to that packet must be silently discarded. 88 As specified in Section 5 of [RFC2460], when a host receives an 89 ICMPv6 "Packet Too Big" message advertising a "Next-Hop MTU" smaller 90 than 1280 (the minimum IPv6 MTU), it is not required to reduce the 91 assumed Path-MTU, but must simply include a Fragment Header in all 92 subsequent packets sent to that destination. The resulting packets 93 will thus *not* be actually fragmented into several pieces, but just 94 include a Fragment Header with both the "Fragment Offset" and the "M" 95 bit set to 0. 97 While these packets are really "atomic fragments" (they can be 98 processed by the IPv6 module and handed to the upper-layer protocol 99 without waiting for any other fragments), many IPv6 implementations 100 process them as regular fragments. Namely, they try to perform IPv6 101 fragment reassembly with the "atomic fragment" and any other 102 fragments already queued with the same set {IPv6 Source Address, IPv6 103 Destination Address, Fragment Identification}. For example, in the 104 case of IPv6 implementations that have been updated to support 105 [RFC5722], if a fragment with the same {IPv6 Source Address, IPv6 106 Destination Address, Fragment Identification} is already queued for 107 reassembly at a host when an "atomic fragment" is received with the 108 same set {IPv6 Source Address, IPv6 Destination Address, Fragment 109 Identification}, and both fragments overlap, all the fragments will 110 be silently discarded. 112 Processing of IPv6 "atomic fragments" as regular fragmented packets 113 clearly provides an unnecessary vector to perform fragmentation-based 114 attacks against non-fragmented traffic (i.e., IPv6 datagrams that are 115 not really split into multiple pieces, but that just include a 116 Fragment Header). 118 IPv6 fragmentation attacks have been discussed in great detail in 119 [PREDICTABLE-ID] and [CPNI-IPv6], and [RFC5722] describes a specific 120 firewall-circumvention attack that could be performed by leveraging 121 overlapping fragments. The possible IPv6 fragmentation-based attacks 122 are, in most cases, "ports" of the IPv4 fragmentation attacks 123 discussed in [RFC6274]. 125 Section 2 describes the generation of IPv6 "atomic fragments", and 126 how they can be remotely "triggered" by a remote attacker. Section 3 127 formally updates [RFC2460] and [RFC5722] such that the aforementioned 128 attack vector is eliminated. 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119]. 134 2. Generation of IPv6 'atomic fragments' 136 Section 5 of [RFC2460] states: 138 In response to an IPv6 packet that is sent to an IPv4 destination 139 (i.e., a packet that undergoes translation from IPv6 to IPv4), the 140 originating IPv6 node may receive an ICMP Packet Too Big message 141 reporting a Next-Hop MTU less than 1280. In that case, the IPv6 142 node is not required to reduce the size of subsequent packets to 143 less than 1280, but must include a Fragment header in those 144 packets so that the IPv6-to-IPv4 translating router can obtain a 145 suitable Identification value to use in resulting IPv4 fragments. 146 Note that this means the payload may have to be reduced to 1232 147 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment 148 header), and smaller still if additional extension headers are 149 used. 151 This means that any ICMPv6 "Packet Too Big" message advertising a 152 "Next-Hop MTU" smaller than 1280 could trigger the generation of the 153 so-called "atomic fragments" (i.e., IPv6 datagrams that include a 154 Fragment Header, but that are composed of a single fragment, with 155 both the "Fragment Offset" and the "M" fields of the Fragment Header 156 set to 0). This can be leveraged to perform a variety of 157 fragmentation-based attacks [PREDICTABLE-ID] [CPNI-IPv6]. 159 From a security standpoint, this situation is exacerbated by the 160 following factors: 162 Many implementations fail to perform validation checks on the 163 received ICMPv6 error messages, as recommended in Section 5.2 of 164 [RFC4443] and [RFC5927]. 166 In some cases, such as when an ICMPv6 error message has 167 (supposedly) been elicited by a connection-less transport protocol 168 (or some other connection-less protocol being encapsulated in 169 IPv6), it may be virtually impossible to perform validation checks 170 on the received ICMPv6 error messages. 172 Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big" 173 error messages, the Destinations Cache is usually updated to 174 reflect that any subsequent packets to such destination should 175 include a Fragment Header. This means that a single ICMPv6 176 "Packet Too Big" error message might affect multiple communication 177 instances (e.g., TCP connections) with such destination. 179 Some implementations employ predictable Fragment Identification 180 values, thus greatly improving the chances of an attacker of 181 successfully performing fragmentation-based attacks 182 [PREDICTABLE-ID]. 184 3. Updating RFC 2460 and RFC 5722 186 This document updates [RFC2460] and [RFC5722] as follows: 188 A host that receives an IPv6 packet which includes a Fragment 189 Header with the "Fragment Offset" equal to 0 and the "M" bit equal 190 to 0 MUST process such packet in isolation from any other packets/ 191 fragments, even if such packets/fragments contain the same set 192 {IPV6 Source Address, IPv6 Destination Address, Fragment 193 Identification}. That is, the Fragment Header of "atomic 194 fragments" should be removed by the receiving host, and the 195 resulting packet should be processed as a non-fragmented IPv6 196 datagram. Additionally, any fragments already queued with the 197 same set {IPV6 Source Address, IPv6 Destination Address, Fragment 198 Identification} should not be discarded upon receipt of the 199 "colliding" IPv6 atomic fragment, since IPv6 atomic fragments do 200 not really interfere with "normal" fragmented traffic. 202 4. IANA Considerations 204 There are no IANA registries within this document. The RFC-Editor 205 can remove this section before publication of this document as an 206 RFC. 208 5. Security Considerations 210 This document describes how an attacker can exploit ICMPv6 "Packet 211 Too Big" error messages to cause further IPv6 packets to include a 212 Fragment Header, such that he can perform any fragmentation-based 213 attack against otherwise non-fragmented traffic. This document 214 updates [RFC2460] and [RFC5722], such that the aforementioned attack 215 vector is completely eliminated. 217 6. Acknowledgements 219 The author would like to thank (in alphabetical order) Tore Anderson, 220 Ran Atkinson, Remi Despres, Timothy Hartrick, Steinar Haug, Philip 221 Homburg, Simon Perreault, Florian Weimer, and Bjoern A. Zeeb, for 222 providing valuable comments on earlier versions of this document. 223 Additionally, the author would like to thank Alexander Bluhm, who 224 implemented this specification for OpenBSD. 226 This document is based on the technical report "Security Assessment 227 of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by 228 Fernando Gont on behalf of the UK Centre for the Protection of 229 National Infrastructure (CPNI). 231 Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for 232 their continued support. 234 7. References 236 7.1. Normative References 238 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 239 (IPv6) Specification", RFC 2460, December 1998. 241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 242 Requirement Levels", BCP 14, RFC 2119, March 1997. 244 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 245 Message Protocol (ICMPv6) for the Internet Protocol 246 Version 6 (IPv6) Specification", RFC 4443, March 2006. 248 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 249 RFC 5722, December 2009. 251 7.2. Informative References 253 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 255 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 256 Version 4", RFC 6274, July 2011. 258 [CPNI-IPv6] 259 Gont, F., "Security Assessment of the Internet Protocol 260 version 6 (IPv6)", UK Centre for the Protection of 261 National Infrastructure, (available on request). 263 [PREDICTABLE-ID] 264 Gont, F., "Security Implications of Predictable Fragment 265 Identification Values", Work in Progress, December 2011, < 266 http://tools.ietf.org/html/ 267 draft-gont-6man-predictable-fragment-id>. 269 Appendix A. Survey of processing of IPv6 atomic fragments by different 270 operating systems 272 This section includes a survey of the support of IPv6 atomic 273 fragments in popular operating systems. 275 +---------------------+---------------------+-----------------------+ 276 | Operating System | Processes atomic | Implements this | 277 | | fragments | specification | 278 +---------------------+---------------------+-----------------------+ 279 | FreeBSD 8.0 | No | No | 280 +---------------------+---------------------+-----------------------+ 281 | FreeBSD 8.2 | Yes | No | 282 +---------------------+---------------------+-----------------------+ 283 | FreeBSD 9.0 | Yes | No | 284 +---------------------+---------------------+-----------------------+ 285 | Linux 3.0.0-15 | Yes | Yes | 286 +---------------------+---------------------+-----------------------+ 287 | NetBSD 5.1 | No | No | 288 +---------------------+---------------------+-----------------------+ 289 | OpenBSD-current | Yes | Yes | 290 +---------------------+---------------------+-----------------------+ 291 | Solaris 11 | Yes | Yes | 292 +---------------------+---------------------+-----------------------+ 293 | Windows XP SP2 | Yes | No | 294 +---------------------+---------------------+-----------------------+ 295 | Windows Vista | Yes | No | 296 | (Build 6000) | | | 297 +---------------------+---------------------+-----------------------+ 298 | Windows 7 Home | Yes | No | 299 | Premium | | | 300 +---------------------+---------------------+-----------------------+ 302 Table 1: Processing of IPv6 atomic fragments by different OSes 304 Author's Address 306 Fernando Gont 307 UK CPNI 309 Email: fgont@si6networks.com 310 URI: http://www.cpni.gov.uk