idnits 2.17.1 draft-ietf-6man-ipv6-atomic-fragments-00.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 (February 1, 2012) is 4468 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) February 1, 2012 5 Intended status: Standards Track 6 Expires: August 4, 2012 8 Processing of IPv6 "atomic" fragments 9 draft-ietf-6man-ipv6-atomic-fragments-00 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 August 4, 2012. 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 Appendix B. Changes from previous versions of the document 73 (to be removed by the RFC Editor before 74 publication of this document as a RFC . . . . . . . . 13 75 B.1. Changes from draft-gont-6man-ipv6-atomic-fragments-00 . . 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 bit set to 0. 101 While these packets are really "atomic fragments" (they can be 102 processed by the IPv6 module and handed to the upper-layer protocol 103 without waiting for any other fragments), many IPv6 implementations 104 process them as regular fragments. Namely, they try to perform IPv6 105 fragment reassembly with the "atomic fragment" and any other 106 fragments already queued with the same set {IPv6 Source Address, IPv6 107 Destination Address, Fragment Identification}. For example, in the 108 case of IPv6 implementations that have been updated to support 109 [RFC5722], if a fragment with the same {IPv6 Source Address, IPv6 110 Destination Address, Fragment Identification} is already queued for 111 reassembly at a host when an "atomic fragment" is received with the 112 same set {IPv6 Source Address, IPv6 Destination Address, Fragment 113 Identification}, and both fragments overlap, all the fragments will 114 be silently discarded. 116 Processing of IPv6 "atomic fragments" as regular fragmented packets 117 clearly provides an unnecessary vector to perform fragmentation-based 118 attacks against non-fragmented traffic (i.e., IPv6 datagrams that are 119 not really split into multiple pieces, but that just include a 120 Fragment Header). 122 IPv6 fragmentation attacks have been discussed in great detail in 123 [PREDICTABLE-ID] and [CPNI-IPv6], and [RFC5722] describes a specific 124 firewall-circumvention attack that could be performed by leveraging 125 overlapping fragments. The possible IPv6 fragmentation-based attacks 126 are, in most cases, "ports" of the IPv4 fragmentation attacks 127 discussed in [RFC6274]. 129 Section 2 describes the generation of IPv6 "atomic fragments", and 130 how they can be remotely "triggered" by a remote attacker. Section 3 131 formally updates [RFC2460] and [RFC5722] such that the aforementioned 132 attack vector is eliminated. 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [RFC2119]. 138 2. Generation of IPv6 'atomic fragments' 140 Section 5 of [RFC2460] states: 142 In response to an IPv6 packet that is sent to an IPv4 destination 143 (i.e., a packet that undergoes translation from IPv6 to IPv4), the 144 originating IPv6 node may receive an ICMP Packet Too Big message 145 reporting a Next-Hop MTU less than 1280. In that case, the IPv6 146 node is not required to reduce the size of subsequent packets to 147 less than 1280, but must include a Fragment header in those 148 packets so that the IPv6-to-IPv4 translating router can obtain a 149 suitable Identification value to use in resulting IPv4 fragments. 150 Note that this means the payload may have to be reduced to 1232 151 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment 152 header), and smaller still if additional extension headers are 153 used. 155 This means that any ICMPv6 "Packet Too Big" message advertising a 156 "Next-Hop MTU" smaller than 1280 could trigger the generation of the 157 so-called "atomic fragments" (i.e., IPv6 datagrams that include a 158 Fragment Header, but that are composed of a single fragment, with 159 both the "Fragment Offset" and the "M" fields of the Fragment Header 160 set to 0). This can be leveraged to perform a variety of 161 fragmentation-based attacks [PREDICTABLE-ID] [CPNI-IPv6]. 163 From a security standpoint, this situation is exacerbated by the 164 following factors: 166 Many implementations fail to perform validation checks on the 167 received ICMPv6 error messages, as recommended in Section 5.2 of 168 [RFC4443] and [RFC5927]. 170 In some cases, such as when an ICMPv6 error message has 171 (supposedly) been elicited by a connection-less transport protocol 172 (or some other connection-less protocol being encapsulated in 173 IPv6), it may be virtually impossible to perform validation checks 174 on the received ICMPv6 error messages. 176 Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big" 177 error messages, the Destinations Cache is usually updated to 178 reflect that any subsequent packets to such destination should 179 include a Fragment Header. This means that a single ICMPv6 180 "Packet Too Big" error message might affect multiple communication 181 instances (e.g., TCP connections) with such destination. 183 Some implementations employ predictable Fragment Identification 184 values, thus greatly improving the chances of an attacker of 185 successfully performing fragmentation-based attacks 186 [PREDICTABLE-ID]. 188 3. Updating RFC 2460 and RFC 5722 190 This document updates [RFC2460] and [RFC5722] as follows: 192 A host that receives an IPv6 packet which includes a Fragment 193 Header with the "Fragment Offset" equal to 0 and the "M" bit equal 194 to 0 MUST process such packet in isolation from any other packets/ 195 fragments, even if such packets/fragments contain the same set 196 {IPV6 Source Address, IPv6 Destination Address, Fragment 197 Identification}. That is, the Fragment Header of "atomic 198 fragments" should be removed by the receiving host, and the 199 resulting packet should be processed as a non-fragmented IPv6 200 datagram. Additionally, any fragments already queued with the 201 same set {IPV6 Source Address, IPv6 Destination Address, Fragment 202 Identification} should not be discarded upon receipt of the 203 "colliding" IPv6 atomic fragment, since IPv6 atomic fragments do 204 not really interfere with "normal" fragmented traffic. 206 4. IANA Considerations 208 There are no IANA registries within this document. The RFC-Editor 209 can remove this section before publication of this document as an 210 RFC. 212 5. Security Considerations 214 This document describes how an attacker can exploit ICMPv6 "Packet 215 Too Big" error messages to cause further IPv6 packets to include a 216 Fragment Header, such that he can perform any fragmentation-based 217 attack against otherwise non-fragmented traffic. This document 218 updates [RFC2460] and [RFC5722], such that the aforementioned attack 219 vector is completely eliminated. 221 6. Acknowledgements 223 The author would like to thank (in alphabetical order) Tore Anderson, 224 Ran Atkinson, Remi Despres, Timothy Hartrick, Steinar Haug, Philip 225 Homburg, Simon Perreault, Florian Weimer, and Bjoern A. Zeeb, for 226 providing valuable comments on earlier versions of this document. 227 Additionally, the author would like to thank Alexander Bluhm, who 228 implemented this specification for OpenBSD. 230 This document is based on the technical report "Security Assessment 231 of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by 232 Fernando Gont on behalf of the UK Centre for the Protection of 233 National Infrastructure (CPNI). 235 Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for 236 their continued support. 238 7. References 240 7.1. Normative References 242 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 243 (IPv6) Specification", RFC 2460, December 1998. 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, March 1997. 248 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 249 Message Protocol (ICMPv6) for the Internet Protocol 250 Version 6 (IPv6) Specification", RFC 4443, March 2006. 252 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 253 RFC 5722, December 2009. 255 7.2. Informative References 257 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 259 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 260 Version 4", RFC 6274, July 2011. 262 [CPNI-IPv6] 263 Gont, F., "Security Assessment of the Internet Protocol 264 version 6 (IPv6)", UK Centre for the Protection of 265 National Infrastructure, (available on request). 267 [PREDICTABLE-ID] 268 Gont, F., "Security Implications of Predictable Fragment 269 Identification Values", Work in Progress, December 2011, < 270 http://tools.ietf.org/html/ 271 draft-gont-6man-predictable-fragment-id>. 273 Appendix A. Survey of processing of IPv6 atomic fragments by different 274 operating systems 276 This section includes a survey of the support of IPv6 atomic 277 fragments in popular operating systems. 279 +-------------------+----------------------+------------------------+ 280 | Operating System | Processes atomic | Implements this | 281 | | fragments | specification | 282 +-------------------+----------------------+------------------------+ 283 | FreeBSD 8.0 | No | No | 284 +-------------------+----------------------+------------------------+ 285 | FreeBSD 8.2 | Yes | No | 286 +-------------------+----------------------+------------------------+ 287 | FreeBSD 9.0 | Yes | No | 288 +-------------------+----------------------+------------------------+ 289 | Linux 3.0.0-15 | Yes | Yes | 290 +-------------------+----------------------+------------------------+ 291 | NetBSD 5.1 | No | No | 292 +-------------------+----------------------+------------------------+ 293 | OpenBSD-current | Yes | Yes | 294 +-------------------+----------------------+------------------------+ 295 | Solaris 11 | Yes | Yes | 296 +-------------------+----------------------+------------------------+ 297 | Windows 7 Home | Yes | No | 298 | Premium | | | 299 +-------------------+----------------------+------------------------+ 301 Table 1: Processing of IPv6 atomic fragments by different OSes 303 Appendix B. Changes from previous versions of the document (to be 304 removed by the RFC Editor before publication of this 305 document as a RFC 307 B.1. Changes from draft-gont-6man-ipv6-atomic-fragments-00 309 o Miscellaneous editorial changes 311 o Clarified Section 3. 313 o Incorporates a survey of support of IPv6 "atomic fragments" in 314 different OSes in Appendix A. 316 o Draft resubmitted as draft-ietf. 318 Author's Address 320 Fernando Gont 321 UK CPNI 323 Email: fgont@si6networks.com 324 URI: http://www.cpni.gov.uk