From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7112.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc7112.txt (limited to 'doc/rfc/rfc7112.txt') diff --git a/doc/rfc/rfc7112.txt b/doc/rfc/rfc7112.txt new file mode 100644 index 0000000..cf4de23 --- /dev/null +++ b/doc/rfc/rfc7112.txt @@ -0,0 +1,451 @@ + + + + + + +Internet Engineering Task Force (IETF) F. Gont +Request for Comments: 7112 Huawei Technologies +Updates: 2460 V. Manral +Category: Standards Track Ionos Networks +ISSN: 2070-1721 R. Bonica + Juniper Networks + January 2014 + + + Implications of Oversized IPv6 Header Chains + +Abstract + + The IPv6 specification allows IPv6 Header Chains of an arbitrary + size. The specification also allows options that can, in turn, + extend each of the headers. In those scenarios in which the IPv6 + Header Chain or options are unusually long and packets are + fragmented, or scenarios in which the fragment size is very small, + the First Fragment of a packet may fail to include the entire IPv6 + Header Chain. This document discusses the interoperability and + security problems of such traffic, and updates RFC 2460 such that the + First Fragment of a packet is required to contain the entire IPv6 + Header Chain. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7112. + + + + + + + + + + + + + + +Gont, et al. Standards Track [Page 1] + +RFC 7112 Implications of Oversized Header Chains January 2014 + + +Copyright Notice + + Copyright (c) 2014 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 + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Requirements Language ...........................................3 + 3. Terminology .....................................................3 + 4. Motivation ......................................................4 + 5. Updates to RFC 2460 .............................................5 + 6. IANA Considerations .............................................5 + 7. Security Considerations .........................................6 + 8. Acknowledgements ................................................6 + 9. References ......................................................7 + 9.1. Normative References .......................................7 + 9.2. Informative References .....................................7 + +1. Introduction + + With IPv6, optional internet-layer information is carried in one or + more IPv6 Extension Headers [RFC2460]. Extension Headers are placed + between the IPv6 header and the Upper-Layer Header in a packet. The + term "Header Chain" refers collectively to the IPv6 header, Extension + Headers, and Upper-Layer Header occurring in a packet. In those + scenarios in which the IPv6 Header Chain is unusually long and + packets are fragmented, or scenarios in which the fragment size is + very small, the Header Chain may span multiple fragments. + + While IPv4 had a fixed maximum length for the set of all IPv4 options + present in a single IPv4 packet, IPv6 does not have any equivalent + maximum limit at present. This document updates the set of IPv6 + specifications to create an overall limit on the size of the + combination of IPv6 options and IPv6 Extension Headers that is + allowed in a single IPv6 packet. Namely, it updates RFC 2460 such + that the First Fragment of a fragmented datagram is required to + contain the entire IPv6 Header Chain. + + + +Gont, et al. Standards Track [Page 2] + +RFC 7112 Implications of Oversized Header Chains January 2014 + + + It should be noted that this requirement does not preclude the use of + large payloads but, instead, merely requires that all headers, + starting from the IPv6 base header and continuing up to the Upper- + Layer Header (e.g., TCP or the like) be present in the First + Fragment. + +2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Terminology + + For the purposes of this document, the terms Extension Header, IPv6 + Header Chain, First Fragment, and Upper-Layer Header are used as + follows: + + Extension Header: + + Extension Headers are defined in Section 4 of [RFC2460]. As a + result of [RFC7045], [IANA-PROTO] provides a list of assigned + Internet Protocol Numbers and designates which of those protocol + numbers also represent Extension Headers. + + First Fragment: + + An IPv6 fragment with Fragment Offset equal to 0. + + IPv6 Header Chain: + + The IPv6 Header Chain contains an initial IPv6 header, zero or + more IPv6 Extension Headers, and optionally, a single Upper-Layer + Header. If an Upper-Layer Header is present, it terminates the + header chain; otherwise, the "No Next Header" value (Next Header = + 59) terminates it. + + The first member of the IPv6 Header Chain is always an IPv6 + header. For a subsequent header to qualify as a member of the + header chain, it must be referenced by the "Next Header" field of + the previous member of the header chain. However, if a second + IPv6 header appears in the header chain, as is the case when IPv6 + is tunneled over IPv6, the second IPv6 header is considered to be + an Upper-Layer Header and terminates the header chain. Likewise, + if an Encapsulating Security Payload (ESP) header appears in the + header chain, it is considered to be an Upper-Layer Header, and it + terminates the header chain. + + + + +Gont, et al. Standards Track [Page 3] + +RFC 7112 Implications of Oversized Header Chains January 2014 + + + Upper-Layer Header: + + In the general case, the Upper-Layer Header is the first member of + the header chain that is neither an IPv6 header nor an IPv6 + Extension Header. However, if either an ESP header, or a second + IPv6 header occur in the header chain, they are considered to be + Upper-Layer Headers, and they terminate the header chain. + + Neither the upper-layer payload, nor any protocol data following + the upper-layer payload, is considered to be part of the IPv6 + Header Chain. In a simple example, if the Upper-Layer Header is a + TCP header, the TCP payload is not part of the IPv6 Header Chain. + In a more complex example, if the Upper-Layer Header is an ESP + header, neither the payload data, nor any of the fields that + follow the payload data in the ESP header are part of the IPv6 + Header Chain. + +4. Motivation + + Many forwarding devices implement stateless firewalls. A stateless + firewall enforces a forwarding policy on a packet-by-packet basis. + In order to enforce its forwarding policy, the stateless firewall may + need to glean information from both the IPv6 and upper-layer headers. + + For example, assume that a stateless firewall discards all traffic + received from an interface unless it is destined for a particular TCP + port on a particular IPv6 address. When this firewall is presented + with a fragmented packet that is destined for a different TCP port, + and the entire header chain is contained within the First Fragment, + the firewall discards the First Fragment and allows subsequent + fragments to pass. Because the First Fragment was discarded, the + packet cannot be reassembled at the destination. Insomuch as the + packet cannot be reassembled, the forwarding policy is enforced. + + However, when the firewall is presented with a fragmented packet and + the header chain spans multiple fragments, the First Fragment does + not contain enough information for the firewall to enforce its + forwarding policy. Lacking sufficient information, the stateless + firewall either forwards or discards that fragment. Regardless of + the action that it takes, it may fail to enforce its forwarding + policy. + + + + + + + + + + +Gont, et al. Standards Track [Page 4] + +RFC 7112 Implications of Oversized Header Chains January 2014 + + +5. Updates to RFC 2460 + + When a host fragments an IPv6 datagram, it MUST include the entire + IPv6 Header Chain in the First Fragment. + + A host that receives a First Fragment that does not satisfy the + above-stated requirement SHOULD discard the packet and SHOULD send an + ICMPv6 error message to the source address of the offending packet + (subject to the rules for ICMPv6 errors specified in [RFC4443]). + However, for backwards compatibility, implementations MAY include a + configuration option that allows such fragments to be accepted. + + Likewise, an intermediate system (e.g., router or firewall) that + receives an IPv6 First Fragment that does not satisfy the above- + stated requirement MAY discard that packet, and it MAY send an ICMPv6 + error message to the source address of the offending packet (subject + to the rules for ICMPv6 error messages specified in [RFC4443]). + Intermediate systems having this capability SHOULD support + configuration (e.g., enable/disable) of whether or not such packets + are dropped by the intermediate system. + + If a host or intermediate system discards a First Fragment because it + does not satisfy the above-stated requirement and sends an ICMPv6 + error message due to the discard, then the ICMPv6 error message MUST + be Type 4 ("Parameter Problem") and MUST use Code 3 ("First Fragment + has incomplete IPv6 Header Chain"). The Pointer field contained by + the ICMPv6 Parameter Problem message MUST be set to zero. The format + for the ICMPv6 error message is the same regardless of whether a host + or intermediate system originates it. + + As a result of the above-mentioned requirement, a packet's header + chain length cannot exceed the Path MTU associated with its + destination. Hosts discover the Path MTU using procedures such as + those defined in [RFC1981] and [RFC4821]. Hosts that do not discover + the Path MTU MUST limit the IPv6 Header Chain length to 1280 bytes. + Limiting the IPv6 Header Chain length to 1280 bytes ensures that the + header chain length does not exceed the IPv6 minimum MTU [RFC2460]. + +6. IANA Considerations + + IANA has added the following "Type 4 - Parameter Problem" message to + the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" + registry: + + CODE NAME/DESCRIPTION + 3 IPv6 First Fragment has incomplete IPv6 Header Chain + + + + + +Gont, et al. Standards Track [Page 5] + +RFC 7112 Implications of Oversized Header Chains January 2014 + + +7. Security Considerations + + No new security exposures or issues are raised by this document. + This document describes how undesirably fragmented packets can be + leveraged to evade stateless packet filtering. Having made that + observation, this document updates [RFC2460] so that undesirably + fragmented packets are forbidden. Therefore, a security + vulnerability is removed. + + This specification allows nodes that drop the aforementioned packets + to signal such packet drops with ICMPv6 "Parameter Problem, IPv6 + First Fragment has incomplete IPv6 header chain" (Type 4, Code 3) + error messages. + + As with all ICMPv6 error/diagnostic messages, deploying Source + Address Forgery Prevention filters helps reduce the chances of an + attacker successfully performing a reflection attack by sending + forged illegal packets with the victim's/target's IPv6 address as the + IPv6 source address of the illegal packet [RFC2827] [RFC3704]. + + A firewall that performs stateless deep packet inspection (i.e., + examines application payload content) might still be unable to + correctly process fragmented packets, even if the IPv6 Header Chain + is not fragmented. + +8. Acknowledgements + + The authors would like to thank Ran Atkinson for contributing text + and ideas that were incorporated into this document. + + The authors would like to thank (in alphabetical order) Ran Atkinson, + Fred Baker, Stewart Bryant, Brian Carpenter, Benoit Claise, Dominik + Elsbroek, Wes George, Mike Heard, Bill Jouris, Suresh Krishnan, Dave + Thaler, Ole Troan, Eric Vyncke, and Peter Yee, for providing valuable + comments on earlier versions of this document. + + + + + + + + + + + + + + + + +Gont, et al. Standards Track [Page 6] + +RFC 7112 Implications of Oversized Header Chains January 2014 + + +9. References + +9.1. Normative References + + [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery + for IP version 6", RFC 1981, August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control + Message Protocol (ICMPv6) for the Internet Protocol + Version 6 (IPv6) Specification", RFC 4443, March 2006. + + [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU + Discovery", RFC 4821, March 2007. + + [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing + of IPv6 Extension Headers", RFC 7045, December 2013. + +9.2. Informative References + + [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP Source + Address Spoofing", BCP 38, RFC 2827, May 2000. + + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed + Networks", BCP 84, RFC 3704, March 2004. + + [IANA-PROTO] + Internet Assigned Numbers Authority, "Protocol Numbers", + . + + + + + + + + + + + + + + + + +Gont, et al. Standards Track [Page 7] + +RFC 7112 Implications of Oversized Header Chains January 2014 + + +Authors' Addresses + + Fernando Gont + Huawei Technologies + Evaristo Carriego 2644 + Haedo, Provincia de Buenos Aires 1706 + Argentina + + Phone: +54 11 4650 8472 + EMail: fgont@si6networks.com + + + Vishwas Manral + Ionos Networks + Sunnyvale, CA 94089 + US + + Phone: 408-447-1497 + EMail: vishwas@ionosnetworks.com + + + Ronald P. Bonica + Juniper Networks + 2251 Corporate Park Drive + Herndon, VA 20171 + US + + Phone: 571 250 5819 + EMail: rbonica@juniper.net + + + + + + + + + + + + + + + + + + + + + + +Gont, et al. Standards Track [Page 8] + -- cgit v1.2.3