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