draft-ietf-6man-deprecate-atomfrag-generation-00.txt   draft-ietf-6man-deprecate-atomfrag-generation-01.txt 
IPv6 maintenance Working Group (6man) F. Gont IPv6 maintenance Working Group (6man) F. Gont
Internet-Draft SI6 Networks / UTN-FRH Internet-Draft SI6 Networks / UTN-FRH
Updates: 2460, 6145 (if approved) W. Liu Updates: 2460, 6145 (if approved) W. Liu
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: May 15, 2015 T. Anderson Expires: October 29, 2015 T. Anderson
Redpill Linpro Redpill Linpro
November 11, 2014 April 27, 2015
Deprecating the Generation of IPv6 Atomic Fragments Deprecating the Generation of IPv6 Atomic Fragments
draft-ietf-6man-deprecate-atomfrag-generation-00 draft-ietf-6man-deprecate-atomfrag-generation-01
Abstract Abstract
The core IPv6 specification requires that when a host receives an The core IPv6 specification requires that when a host receives an
ICMPv6 "Packet Too Big" message reporting a "Next-Hop MTU" smaller ICMPv6 "Packet Too Big" message reporting a "Next-Hop MTU" smaller
than 1280, the host includes a Fragment Header in all subsequent than 1280, the host includes a Fragment Header in all subsequent
packets sent to that destination, without reducing the assumed Path- packets sent to that destination, without reducing the assumed Path-
MTU. The simplicity with which ICMPv6 "Packet Too Big" messages can MTU. The simplicity with which ICMPv6 "Packet Too Big" messages can
be forged, coupled with the widespread filtering of IPv6 fragments, be forged, coupled with the widespread filtering of IPv6 fragments,
results in an attack vector that can be leveraged for Denial of results in an attack vector that can be leveraged for Denial of
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 15, 2015. This Internet-Draft will expire on October 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 50 skipping to change at page 4, line 50
headers, the ICMPv6 payload might not even contain any useful headers, the ICMPv6 payload might not even contain any useful
information on which to perform validation checks. information on which to perform validation checks.
o Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big" o Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big"
error messages, the Destination Cache [RFC4861] is usually updated error messages, the Destination Cache [RFC4861] is usually updated
to reflect that any subsequent packets to such destination should to reflect that any subsequent packets to such destination should
include a Fragment Header. This means that a single ICMPv6 include a Fragment Header. This means that a single ICMPv6
"Packet Too Big" error message might affect multiple communication "Packet Too Big" error message might affect multiple communication
instances (e.g., TCP connections) with such destination. instances (e.g., TCP connections) with such destination.
o As noted in Section 4, SIIT [RFC6145] is the only technology which o As noted in Section 4, SIIT [RFC6145] (including derivative
currently makes use of atomic fragments. Unfortunately, an IPv6 protocols such as Stateful NAT64 [RFC6146]) is the only technology
node cannot easily limit its exposure to the aforementioned attack which currently makes use of atomic fragments. Unfortunately, an
vector by only generating IPv6 atomic fragments towards IPv4 IPv6 node cannot easily limit its exposure to the aforementioned
destinations behind a stateless translator. This is due to the attack vector by only generating IPv6 atomic fragments towards
fact that Section 3.3 of RFC6052 [RFC6052] encourages operators to IPv4 destinations behind a stateless translator. This is due to
use a Network-Specific Prefix (NSP) that maps the IPv4 address the fact that Section 3.3 of RFC6052 [RFC6052] encourages
space into IPv6. When an NSP is being used, IPv6 addresses operators to use a Network-Specific Prefix (NSP) that maps the
representing IPv4 nodes (reached through a stateless translator) IPv4 address space into IPv6. When an NSP is being used, IPv6
are indistinguishable from native IPv6 addresses. addresses representing IPv4 nodes (reached through a stateless
translator) are indistinguishable from native IPv6 addresses.
4. Additional Considerations 4. Additional Considerations
Besides the security assessment provided in Section 3, it is Besides the security assessment provided in Section 3, it is
interesting to evaluate the pros and cons of having an IPv6-to-IPv4 interesting to evaluate the pros and cons of having an IPv6-to-IPv4
translating router rely on the generation of IPv6 atomic fragments. translating router rely on the generation of IPv6 atomic fragments.
Relying on the generation of IPv6 atomic fragments implies a reliance Relying on the generation of IPv6 atomic fragments implies a reliance
on: on:
skipping to change at page 12, line 32 skipping to change at page 12, line 32
function. function.
---------------- cut here -------------- cut here ---------------- ---------------- cut here -------------- cut here ----------------
is formally replaced with: is formally replaced with:
---------------- cut here -------------- cut here ---------------- ---------------- cut here -------------- cut here ----------------
Identification: Set according to a Fragment Identification Identification: Set according to a Fragment Identification
generator at the translator. generator at the translator.
Flags: The More Fragments flag is set to zero. The Don't Fragment Flags: The More Fragments flag is set to zero. The Don't Fragment
(DF) flag is set as follows: If the packet size is less than or (DF) flag is set as follows: If the size of the translated IPv4
equal to 1260 bytes, it is set to zero; otherwise, it is set to packet is less than or equal to 1260 bytes, it is set to zero;
one. otherwise, it is set to one.
---------------- cut here -------------- cut here ---------------- ---------------- cut here -------------- cut here ----------------
The following text from Section 5.1.1 ("IPv6 Fragment Processing") of The following text from Section 5.1.1 ("IPv6 Fragment Processing") of
[RFC6145]: [RFC6145]:
---------------- cut here -------------- cut here ---------------- ---------------- cut here -------------- cut here ----------------
If a translated packet with DF set to 1 will be larger than the MTU If a translated packet with DF set to 1 will be larger than the MTU
of the next-hop interface, then the translator MUST drop the packet of the next-hop interface, then the translator MUST drop the packet
and send the ICMPv6 Packet Too Big (Type 2, Code 0) error message to and send the ICMPv6 Packet Too Big (Type 2, Code 0) error message to
the IPv6 host with an adjusted MTU in the ICMPv6 message. the IPv6 host with an adjusted MTU in the ICMPv6 message.
skipping to change at page 15, line 7 skipping to change at page 15, line 7
This document describes a Denial of Service (DoS) attack vector that This document describes a Denial of Service (DoS) attack vector that
leverages the widespread filtering of IPv6 fragments in the public leverages the widespread filtering of IPv6 fragments in the public
Internet by means of ICMPv6 PTB error messages. Additionally, it Internet by means of ICMPv6 PTB error messages. Additionally, it
formally updates [RFC2460] such that this attack vector is formally updates [RFC2460] such that this attack vector is
eliminated, and also formally updated [RFC6145] such that it does not eliminated, and also formally updated [RFC6145] such that it does not
rely on IPv6 atomic fragments. rely on IPv6 atomic fragments.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank (in alphabetical order) Bob Briscoe, The authors would like to thank (in alphabetical order) Alberto
Brian Carpenter, Tatuya Jinmei, Jeroen Massar, and Erik Nordmark, for Leiva, Bob Briscoe, Brian Carpenter, Tatuya Jinmei, Jeroen Massar,
providing valuable comments on earlier versions of this document. and Erik Nordmark, for providing valuable comments on earlier
versions of this document.
Fernando Gont would like to thank Jan Zorz and Go6 Lab Fernando Gont would like to thank Jan Zorz and Go6 Lab
<http://go6lab.si/> for providing access to systems and networks that <http://go6lab.si/> for providing access to systems and networks that
were employed to produce some of tests that resulted in the were employed to produce some of tests that resulted in the
publication of this document. Additionally, he would like to thank publication of this document. Additionally, he would like to thank
SixXS <https://www.sixxs.net> for providing IPv6 connectivity. SixXS <https://www.sixxs.net> for providing IPv6 connectivity.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 16, line 9 skipping to change at page 16, line 9
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path
Algorithm", RFC 2992, November 2000. Algorithm", RFC 2992, November 2000.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC
6946, May 2013. 6946, May 2013.
[I-D.ietf-6man-predictable-fragment-id] [I-D.ietf-6man-predictable-fragment-id]
Gont, F., "Security Implications of Predictable Fragment Gont, F., "Security Implications of Predictable Fragment
Identification Values", draft-ietf-6man-predictable- Identification Values", draft-ietf-6man-predictable-
fragment-id-01 (work in progress), April 2014. fragment-id-05 (work in progress), April 2015.
[I-D.gont-v6ops-ipv6-ehs-in-real-world] [I-D.gont-v6ops-ipv6-ehs-in-real-world]
Gont, F., Linkova, J., Chown, T., and W. Will, "IPv6 Gont, F., Linkova, J., Chown, T., and W. Will,
Extension Headers in the Real World", draft-gont-v6ops- "Observations on IPv6 EH Filtering in the Real World",
ipv6-ehs-in-real-world-01 (work in progress), September draft-gont-v6ops-ipv6-ehs-in-real-world-02 (work in
2014. progress), March 2015.
[Morbitzer] [Morbitzer]
Morbitzer, M., "TCP Idle Scans in IPv6", Master's Thesis. Morbitzer, M., "TCP Idle Scans in IPv6", Master's Thesis.
Thesis number: 670. Department of Computing Science, Thesis number: 670. Department of Computing Science,
Radboud University Nijmegen. August 2013, Radboud University Nijmegen. August 2013,
<https://www.ru.nl/publish/pages/578936/ <https://www.ru.nl/publish/pages/578936/
m_morbitzer_masterthesis.pdf>. m_morbitzer_masterthesis.pdf>.
Appendix A. Small Survey of OSes that Fail to Produce IPv6 Atomic Appendix A. Small Survey of OSes that Fail to Produce IPv6 Atomic
Fragments Fragments
skipping to change at page 17, line 28 skipping to change at page 17, line 31
Huawei Technologies Huawei Technologies
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 Shenzhen 518129
P.R. China P.R. China
Email: liushucheng@huawei.com Email: liushucheng@huawei.com
Tore Anderson Tore Anderson
Redpill Linpro Redpill Linpro
Vitaminveien 1A Vitaminveien 1A
NO-0485 Oslo Oslo 0485
NORWAY Norway
Phone: +47 959 31 212 Phone: +47 959 31 212
Email: tore@redpill-linpro.com Email: tore@redpill-linpro.com
URI: http://www.redpill-linpro.com
 End of changes. 13 change blocks. 
28 lines changed or deleted 34 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/