idnits 2.17.1 draft-ietf-6man-oversized-header-chain-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2460, updated by this document, for RFC5378 checks: 1997-07-30) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 29, 2012) is 4316 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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 Updates: 2460 (if approved) V. Manral 5 Intended status: Standards Track Hewlett-Packard Corp. 6 Expires: December 31, 2012 June 29, 2012 8 Security and Interoperability Implications of Oversized IPv6 Header 9 Chains 10 draft-ietf-6man-oversized-header-chain-00 12 Abstract 14 The IPv6 specification allows IPv6 header chains of an arbitrary 15 size. The specification also allows options which can in turn extend 16 each of the headers. In those scenarios in which the IPv6 header 17 chain or options are unusually long and packets are fragmented, or 18 scenarios in which the fragment size is very small, the first 19 fragment of a packet may fail to include the entire IPv6 header 20 chain. This document discusses the interoperability and security 21 problems of such traffic, and updates RFC 2460 such that the first 22 fragment of a packet is required to contain the entire IPv6 header 23 chain. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 31, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Interoperability Implications of Oversized IPv6 Header 61 Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Forwarding Implications of Oversized IPv6 Header Chains . . . 5 63 4. Security Implications of Oversized IPv6 Header Chains . . . . 6 64 5. Updating RFC 2460 . . . . . . . . . . . . . . . . . . . . . . 7 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 [RFC2460] allows for an IPv6 header chain of an arbitrary size. It 76 also allows the headers themselves to have options, which can change 77 the size of the headers. In those scenarios in which the IPv6 header 78 chain is unusually long and packets are fragmented, or scenarios in 79 which the fragment size is very small, the first fragment of a packet 80 may fail to include the entire IPv6 header chain. This document 81 discusses the interoperability and security problems of such traffic, 82 and updates RFC 2460 such that the first fragment of a fragmented 83 datagram is required to contain the entire IPv6 header chain. 85 It should be noted that this requirement does not preclude the use of 86 e.g. IPv6 jumbo payloads but instead merely requires that all 87 *headers*, starting from IPv6 base header and continuing up to the 88 upper layer header (e.g. TCP or the like) be present in the first 89 fragment. 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119]. 95 2. Interoperability Implications of Oversized IPv6 Header Chains 97 Some transition technologies, such as NAT64 [RFC6146], may need to 98 have access to the entire IPv6 header chain in order to associate an 99 incoming IPv6 packet with an ongoing "session". 101 For instance, Section 3.4 of [RFC6146] states that "The NAT64 MAY 102 require that the UDP, TCP, or ICMP header be completely contained 103 within the fragment that contains fragment offset equal to zero". 105 Failure to include the entire IPv6 header chain in the first-fragment 106 may cause the translation function to fail, with the corresponding 107 packets being dropped. 109 3. Forwarding Implications of Oversized IPv6 Header Chains 111 A lot of the switches and Routers in the internet do hardware based 112 forwarding. To be able to achieve a level of throughput, there is a 113 fixed maximum number of clock cycles dedicated to each packet. 114 However with the use of unlimited options and header interleaving, 115 larger packets with a lot of interleaving have to be forwarded to the 116 software. It is for this reason that the maximum size of valid 117 packets with interleaved headers needs to be limited. 119 4. Security Implications of Oversized IPv6 Header Chains 121 Most firewalls enforce they filtering policy based on the following 122 parameters: 124 o Source IP address 126 o Destination IP address 128 o Protocol type 130 o Source port number 132 o Destination port number 134 Some firewalls reassemble fragmented packets before applying a 135 filtering policy, and thus always have the aforementioned information 136 available when deciding whether to allow or block a packet. However, 137 other stateless firewalls (generally prevalent on small/ home office 138 equipment) do not reassemble fragmented traffic, and hence have to 139 enforce their filtering policy based on the information contained in 140 the received fragment, as opposed to the information contained in the 141 reassembled datagram. 143 When presented with fragmented traffic, many of such firewalls 144 typically enforce their policy only on the first fragment of a 145 packet, based on the assumption that if the first fragment is 146 dropped, reassembly of the corresponding datagram will fail, and thus 147 such datagram will be effectively blocked. However, if the first 148 fragment fails to include the entire IPv6 header chain, they may have 149 no option other than "blindly" allowing or blocking the corresponding 150 fragment. If they blindly allow the packet, then the firewall can be 151 easily circumvented by intentionally sending fragmented packets that 152 fail to include the entire IPv6 header chain in the first fragment. 153 On the other hand, first-fragments that fail to include the entire 154 IPv6 header chain have never been formally deprecated and thus, in 155 theory, might be legitimately generated. 157 5. Updating RFC 2460 159 If a packet is fragmented, the first fragment of the packet (i.e., 160 that with a Fragment Offset of 0) MUST contain the entire IPv6 header 161 chain. 163 6. IANA Considerations 165 There are no IANA registries within this document. The RFC-Editor 166 can remove this section before publication of this document as an 167 RFC. 169 7. Security Considerations 171 This document describes the interoperability and security 172 implications of IPv6 packets or first-fragments that fail to include 173 the entire IPv6 header chain. The security implications include the 174 possibility of an attacker evading network security controls such as 175 firewalls and Network Intrusion Detection Systems (NIDS) [CPNI-IPv6]. 177 This document updates RFC 2460 such that those packets are forbidden, 178 thus preventing the aforementioned issues. 180 8. Acknowledgements 182 The authors would like to thank (in alphabetical order) Ran Atkinson 183 and Dave Thaler for providing valuable comments on earlier versions 184 of this document. 186 9. References 188 9.1. Normative References 190 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 191 Requirement Levels", BCP 14, RFC 2119, March 1997. 193 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 194 (IPv6) Specification", RFC 2460, December 1998. 196 9.2. Informative References 198 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 199 NAT64: Network Address and Protocol Translation from IPv6 200 Clients to IPv4 Servers", RFC 6146, April 2011. 202 [CPNI-IPv6] 203 Gont, F., "Security Assessment of the Internet Protocol 204 version 6 (IPv6)", UK Centre for the Protection of 205 National Infrastructure, (available on request). 207 Authors' Addresses 209 Fernando Gont 210 SI6 Networks / UTN-FRH 211 Evaristo Carriego 2644 212 Haedo, Provincia de Buenos Aires 1706 213 Argentina 215 Phone: +54 11 4650 8472 216 Email: fgont@si6networks.com 217 URI: http://www.si6networks.com 219 Vishwas Manral 220 Hewlett-Packard Corp. 221 191111 Pruneridge Ave. 222 Cupertino, CA 95014 223 US 225 Phone: 408-447-1497 226 Email: vishwas.manral@hp.com 227 URI: