summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7112.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7112.txt')
-rw-r--r--doc/rfc/rfc7112.txt451
1 files changed, 451 insertions, 0 deletions
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",
+ <http://www.iana.org/assignments/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]
+