idnits 2.17.1 draft-ietf-6man-deprecate-atomfrag-generation-05.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-6man-RFC2460bis]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 20, 2016) is 3019 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2923' is defined on line 361, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-13) exists of draft-ietf-6man-rfc2460bis-02 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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 SI6 Networks / UTN-FRH 4 Intended status: Informational W. Liu 5 Expires: July 23, 2016 Huawei Technologies 6 T. Anderson 7 Redpill Linpro 8 January 20, 2016 10 Generation of IPv6 Atomic Fragments Considered Harmful 11 draft-ietf-6man-deprecate-atomfrag-generation-05 13 Abstract 15 RFC2460 requires that when a host receives an ICMPv6 "Packet Too Big" 16 message reporting an MTU smaller than 1280 bytes, the host includes a 17 Fragment Header in all subsequent packets sent to that destination, 18 without reducing the assumed Path-MTU. The simplicity with which 19 ICMPv6 "Packet Too Big" messages can be forged means that an attacker 20 can leverage this functionality (the generation of IPv6 atomic 21 fragments) to trigger the use of fragmentation for any arbitrary IPv6 22 flow, and subsequently perform any fragmentation-based attack. This 23 document discusses the security implications of the generation of 24 IPv6 atomic fragments and a number of interoperability issues 25 associated with IPv6 atomic fragments, and concludes that the 26 aforementioned functionality is undesirable, thus documenting the 27 motivation for removing this functionality in the revision of the 28 core IPv6 protocol specification [I-D.ietf-6man-rfc2460bis]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 23, 2016. 47 Copyright Notice 49 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Security Implications of the Generation of IPv6 Atomic 67 Fragments . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 4. Additional Considerations . . . . . . . . . . . . . . . . . . 5 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 74 8.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Appendix A. Small Survey of OSes that Fail to Produce IPv6 76 Atomic Fragments . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 [RFC2460] specifies the IPv6 fragmentation mechanism, which allows 82 IPv6 packets to be fragmented into smaller pieces such that they can 83 fit in the Path-MTU to the intended destination(s). 85 Section 5 of [RFC2460] states that, when a host receives an ICMPv6 86 "Packet Too Big" message [RFC4443] advertising an MTU smaller than 87 1280 bytes (the minimum IPv6 MTU), the host is not required to reduce 88 the assumed Path-MTU, but must simply include a Fragment Header in 89 all subsequent packets sent to that destination. The resulting 90 packets will thus *not* be actually fragmented into several pieces, 91 but rather just include a Fragment Header with both the "Fragment 92 Offset" and the "M" flag set to 0 (i.e., "atomic fragments" 93 [RFC6946]). [RFC6946] requires that these atomic fragments be 94 essentially processed by the destination host as non-fragmented 95 traffic (since there are not really any fragments to be reassembled). 96 The goal of these atomic fragments is simply to convey an appropriate 97 Identification value to be employed by IPv6/IPv4 translators for the 98 resulting IPv4 fragments. 100 While atomic fragments might seem rather benign, there are scenarios 101 in which the generation of IPv6 atomic fragments can be leveraged for 102 performing a number of attacks against the corresponding IPv6 flows. 103 Since there are concrete security implications arising from the 104 generation of IPv6 atomic fragments, and there is no real gain in 105 generating IPv6 atomic fragments (as opposed to e.g. having IPv6/IPv4 106 translators generate a Fragment Identification value themselves), we 107 conclude that this functionality is undesirable. 109 Section 3 briefly discusses the security implications of the 110 generation of IPv6 atomic fragments, and describes a specific Denial 111 of Service (DoS) attack vector that leverages the widespread 112 filtering of IPv6 fragments in the public Internet. Section 4 113 provides additional considerations regarding the usefulness of 114 generating IPv6 atomic fragments. 116 2. Terminology 118 IPv6 atomic fragments: 119 IPv6 packets that contain a Fragment Header with the Fragment 120 Offset set to 0 and the M flag set to 0 (as defined by [RFC6946]). 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 3. Security Implications of the Generation of IPv6 Atomic Fragments 128 The security implications of IP fragmentation have been discussed at 129 length in [RFC6274] and [I-D.ietf-6man-predictable-fragment-id]. An 130 attacker can leverage the generation of IPv6 atomic fragments to 131 trigger the use of fragmentation in an arbitrary IPv6 flow and 132 subsequently perform any fragmentation-based attack against legacy 133 IPv6 nodes that do not implement [RFC6946]. 135 Unfortunately, even nodes that already implement [RFC6946] can be 136 subject to DoS attacks as a result of the generation of IPv6 atomic 137 fragments. Let us assume that Host A is communicating with Server B, 138 and that, as a result of the widespread dropping of IPv6 packets that 139 contain extension headers (including fragmentation) 140 [I-D.ietf-v6ops-ipv6-ehs-in-real-world], some intermediate node 141 filters fragments between Host A and Server B. If an attacker sends 142 a forged ICMPv6 "Packet Too Big" (PTB) error message to server B, 143 reporting an MTU smaller than 1280, this will trigger the generation 144 of IPv6 atomic fragments from that moment on (as required by 145 [RFC2460]). When server B starts sending IPv6 atomic fragments (in 146 response to the received ICMPv6 PTB), these packets will be dropped, 147 since we previously noted that IPv6 packets with extension headers 148 were being dropped between Host A and Server B. Thus, this situation 149 will result in a Denial of Service (DoS) scenario. 151 Another possible scenario is that in which two BGP peers are 152 employing IPv6 transport, and they implement Access Control Lists 153 (ACLs) to drop IPv6 fragments (to avoid control-plane attacks). If 154 the aforementioned BGP peers drop IPv6 fragments but still honor 155 received ICMPv6 Packet Too Big error messages, an attacker could 156 easily attack the peering session by simply sending an ICMPv6 PTB 157 message with a reported MTU smaller than 1280 bytes. Once the attack 158 packet has been sent, it will be the aforementioned routers 159 themselves the ones dropping their own traffic. 161 The aforementioned attack vector is exacerbated by the following 162 factors: 164 o The attacker does not need to forge the IPv6 Source Address of his 165 attack packets. Hence, deployment of simple BCP38 filters will 166 not help as a counter-measure. 168 o Only the IPv6 addresses of the IPv6 packet embedded in the ICMPv6 169 payload needs to be forged. While one could envision filtering 170 devices enforcing BCP38-style filters on the ICMPv6 payload, the 171 use of extension headers (by the attacker) could make this 172 difficult, if at all possible. 174 o Many implementations fail to perform validation checks on the 175 received ICMPv6 error messages, as recommended in Section 5.2 of 176 [RFC4443] and documented in [RFC5927]. It should be noted that in 177 some cases, such as when an ICMPv6 error message has (supposedly) 178 been elicited by a connection-less transport protocol (or some 179 other connection-less protocol being encapsulated in IPv6), it may 180 be virtually impossible to perform validation checks on the 181 received ICMPv6 error message. And, because of IPv6 extension 182 headers, the ICMPv6 payload might not even contain any useful 183 information on which to perform validation checks. 185 o Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big" 186 error messages, the Destination Cache [RFC4861] is usually updated 187 to reflect that any subsequent packets to such destination should 188 include a Fragment Header. This means that a single ICMPv6 189 "Packet Too Big" error message might affect multiple communication 190 instances (e.g., TCP connections) with such destination. 192 o As noted in Section 4, SIIT [RFC6145] (including derivative 193 protocols such as Stateful NAT64 [RFC6146]) is the only technology 194 which currently makes use of atomic fragments. Unfortunately, an 195 IPv6 node cannot easily limit its exposure to the aforementioned 196 attack vector by only generating IPv6 atomic fragments towards 197 IPv4 destinations behind a stateless translator. This is due to 198 the fact that Section 3.3 of [RFC6052] encourages operators to use 199 a Network-Specific Prefix (NSP) that maps the IPv4 address space 200 into IPv6. When an NSP is being used, IPv6 addresses representing 201 IPv4 nodes (reached through a stateless translator) are 202 indistinguishable from native IPv6 addresses. 204 4. Additional Considerations 206 Besides the security assessment provided in Section 3, it is 207 interesting to evaluate the pros and cons of having an IPv6-to-IPv4 208 translating router rely on the generation of IPv6 atomic fragments. 210 Relying on the generation of IPv6 atomic fragments implies a reliance 211 on: 213 1. ICMPv6 packets arriving from the translator to the IPv6 node 215 2. The ability of the nodes receiving ICMPv6 PTB messages reporting 216 an MTU smaller than 1280 bytes to actually produce atomic 217 fragments 219 3. Support for IPv6 fragmentation on the IPv6 side of the translator 221 4. The ability of the translator implementation to access the 222 information conveyed by the IPv6 Fragment Header 224 Unfortunately, 226 1. There exists a fair share of evidence of ICMPv6 Packet Too Big 227 messages being dropped on the public Internet (for instance, that 228 is one of the reasons for which PLPMTUD [RFC4821] was produced). 229 Therefore, relying on such messages being successfully delivered 230 will affect the robustness of the protocol that relies on them. 232 2. A number of IPv6 implementations have been known to fail to 233 generate IPv6 atomic fragments in response to ICMPv6 PTB messages 234 reporting an MTU smaller than 1280 bytes (see Appendix A for a 235 small survey). Additionally, the results included in Section 6 236 of [RFC6145] note that 57% of the tested web servers failed to 237 produce IPv6 atomic fragments in response to ICMPv6 PTB messages 238 reporting an MTU smaller than 1280 bytes. Thus, any protocol 239 relying on IPv6 atomic fragment generation for proper functioning 240 will have interoperability problems with the aforementioned IPv6 241 stacks. 243 3. IPv6 atomic fragment generation represents a case in which 244 fragmented traffic is produced where otherwise it would not be 245 needed. Since there is widespread filtering of IPv6 fragments in 246 the public Internet [I-D.ietf-v6ops-ipv6-ehs-in-real-world], this 247 would mean that the (unnecessary) use of IPv6 fragmentation might 248 result, unnecessarily, in a Denial of Service situation even in 249 legitimate cases. 251 4. The packet-handling API at the node where the translator is 252 running may obscure fragmentation-related information. In such 253 scenarios, the information conveyed by the Fragment Header may be 254 unavailable to the translator. [JOOL] discusses a sample 255 framework (Linux Netfilter) that hinders access to the 256 information conveyed in IPv6 atomic fragments. 258 We note that SIIT essentially employs the Fragment Header of IPv6 259 atomic fragments to signal the translator how to set the DF bit of 260 IPv4 datagrams (the DF bit is cleared when the IPv6 packet contains a 261 Fragment Header, and is otherwise set to 1 when the IPv6 packet does 262 not contain an IPv6 Fragment Header). Additionally, the translator 263 will employ the low-order 16-bits of the IPv6 Fragment Identification 264 for setting the IPv4 Fragment Identification. At least in theory, 265 this is expected to reduce the IPv4 Identification collision rate in 266 the following specific scenario: 268 1. An IPv6 node communicates with an IPv4 node (through SIIT) 270 2. The IPv4 node is located behind an IPv4 link with an MTU smaller 271 than 1260 bytes 273 3. ECMP routing [RFC2992] with more than one translator is employed 274 for e.g., redundancy purposes 276 In such a scenario, if each translator were to select the IPv4 277 Identification on its own (rather than selecting the IPv4 278 Identification from the low-order 16-bits of the Fragment 279 Identification of IPv6 atomic fragments), this could possibly lead to 280 IPv4 Identification collisions. However, since a number of 281 implementations set the IPv6 Fragment Identification according to the 282 output of a Pseudo-Random Number Generator (PRNG) (see Appendix B of 283 [I-D.ietf-6man-predictable-fragment-id]) and the translator only 284 employs the low-order 16-bits of such value, it is very unlikely that 285 relying on the Fragment Identification of the IPv6 atomic fragment 286 will result in a reduced IPv4 Identification collision rate (when 287 compared to the case where the translator selects each IPv4 288 Identification on its own). 290 Finally, we note that [RFC6145] is currently the only "consumer" of 291 IPv6 atomic fragments, and it correctly and diligently notes (in 292 Section 6) the possible interoperability problems of relying on IPv6 293 atomic fragments, proposing as a workaround that leads to more robust 294 behavior and simplified code. 296 5. IANA Considerations 298 There are no IANA registries within this document. The RFC-Editor 299 can remove this section before publication of this document as an 300 RFC. 302 6. Security Considerations 304 This document briefly discusses the security implications of the 305 generation of IPv6 atomic fragments, and describes a specific Denial 306 of Service (DoS) attack vector that leverages the widespread 307 filtering of IPv6 fragments in the public Internet. It concludes 308 that the generation of IPv6 atomic fragments is an undesirable 309 feature, and documents the motivation for removing this functionality 310 from [I-D.ietf-6man-rfc2460bis]. 312 7. Acknowledgements 314 The authors would like to thank (in alphabetical order) Congxiao Bao, 315 Bob Briscoe, Brian Carpenter, Tatuya Jinmei, Bob Hinden, Alberto 316 Leiva, Xing Li, Jeroen Massar, Erik Nordmark, Qiong Sun, Ole Troan, 317 and Tina Tsou, for providing valuable comments on earlier versions of 318 this document. 320 Fernando Gont would like to thank Jan Zorz / Go6 Lab 321 , and Jared Mauch / NTT America, for providing 322 access to systems and networks that were employed to produce some of 323 tests that resulted in the publication of this document. 324 Additionally, he would like to thank SixXS 325 for providing IPv6 connectivity. 327 8. References 329 8.1. Normative References 331 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 332 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 333 December 1998, . 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, 337 DOI 10.17487/RFC2119, March 1997, 338 . 340 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 341 Control Message Protocol (ICMPv6) for the Internet 342 Protocol Version 6 (IPv6) Specification", RFC 4443, 343 DOI 10.17487/RFC4443, March 2006, 344 . 346 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 347 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 348 . 350 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 351 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 352 DOI 10.17487/RFC4861, September 2007, 353 . 355 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 356 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 357 . 359 8.2. Informative References 361 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 362 RFC 2923, DOI 10.17487/RFC2923, September 2000, 363 . 365 [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path 366 Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, 367 . 369 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 370 DOI 10.17487/RFC5927, July 2010, 371 . 373 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 374 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 375 DOI 10.17487/RFC6052, October 2010, 376 . 378 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 379 NAT64: Network Address and Protocol Translation from IPv6 380 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 381 April 2011, . 383 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 384 Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, 385 . 387 [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", 388 RFC 6946, DOI 10.17487/RFC6946, May 2013, 389 . 391 [I-D.ietf-6man-predictable-fragment-id] 392 Gont, F., "Security Implications of Predictable Fragment 393 Identification Values", draft-ietf-6man-predictable- 394 fragment-id-10 (work in progress), October 2015. 396 [I-D.ietf-v6ops-ipv6-ehs-in-real-world] 397 Gont, F., Linkova, J., Chown, T., and S. LIU, 398 "Observations on the Dropping of Packets with IPv6 399 Extension Headers in the Real World", draft-ietf-v6ops- 400 ipv6-ehs-in-real-world-02 (work in progress), December 401 2015. 403 [I-D.ietf-6man-rfc2460bis] 404 Deering, S. and B. Hinden, "Internet Protocol, Version 6 405 (IPv6) Specification", draft-ietf-6man-rfc2460bis-02 (work 406 in progress), December 2015. 408 [Morbitzer] 409 Morbitzer, M., "TCP Idle Scans in IPv6", Master's Thesis. 410 Thesis number: 670. Department of Computing Science, 411 Radboud University Nijmegen. August 2013, 412 . 415 [JOOL] Leiva Popper, A., "nf_defrag_ipv4 and nf_defrag_ipv6", 416 April 2015, . 419 Appendix A. Small Survey of OSes that Fail to Produce IPv6 Atomic 420 Fragments 422 [This section will probably be removed from this document before it 423 is published as an RFC]. 425 This section includes a non-exhaustive list of operating systems that 426 *fail* to produce IPv6 atomic fragments. It is based on the results 427 published in [RFC6946] and [Morbitzer]. It is simply meant as a 428 datapoint regarding the extent to which IPv6 implementations can be 429 relied upon to generate IPv6 atomic fragments. 431 The following Operating Systems fail to generate IPv6 atomic 432 fragments in response to ICMPv6 PTB messages that report an MTU 433 smaller than 1280 bytes: 435 o FreeBSD 8.0 437 o Linux kernel 2.6.32 439 o Linux kernel 3.2 441 o Linux kernel current 443 o Mac OS X 10.6.7 445 o NetBSD 5.1 447 Authors' Addresses 449 Fernando Gont 450 SI6 Networks / UTN-FRH 451 Evaristo Carriego 2644 452 Haedo, Provincia de Buenos Aires 1706 453 Argentina 455 Phone: +54 11 4650 8472 456 Email: fgont@si6networks.com 457 URI: http://www.si6networks.com 459 Will(Shucheng) Liu 460 Huawei Technologies 461 Bantian, Longgang District 462 Shenzhen 518129 463 P.R. China 465 Email: liushucheng@huawei.com 467 Tore Anderson 468 Redpill Linpro 469 Vitaminveien 1A 470 Oslo 0485 471 Norway 473 Phone: +47 959 31 212 474 Email: tore@redpill-linpro.com 475 URI: http://www.redpill-linpro.com