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