idnits 2.17.00 (12 Aug 2021) /tmp/idnits3671/draft-wkumari-long-headers-01.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 -- The document date (July 04, 2013) is 3243 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN W. Kumari 3 Internet-Draft Google 4 Intended status: Best Current Practice J. Jaeggli 5 Expires: January 05, 2014 Zynga 6 R. Bonica 7 Juniper Networks 8 July 04, 2013 10 Operational Issues Associated With Long IPv6 Extension Header Chains 11 draft-wkumari-long-headers-01 13 Abstract 15 This document explains why IPv6 header chain length affects the cost 16 of ASIC-based packet forwarding. It also explains why some network 17 service providers discard packets with exceptionally long header 18 chains. Finally, it identifies a reasonable header chain length. 19 While a network service provider can enforce any filtering policy 20 that supports its security model, a network service provider should 21 not discard IPv6 packets based solely upon header chain length if the 22 header chain is not longer than the value specified herein. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 05, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Termnology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Need to see upper-layer to filter . . . . . . . . . . . . . . 5 67 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 72 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 In order to make a forwarding decision, the forwarding device may 78 require information from both the IPv6 header and an upper layer 79 header. When a software-based forwarder encounters an IPv6 datagram 80 that includes a long header chain, it parses the header chain, 81 acquires the required information and makes its forwarding decision. 82 Typically, software-based forwarders are not required to process a 83 large number of packets per second. Therefore, they can perform the 84 above mentioned procedure within their processing budget. 86 By contrast, ASIC-based forwarders are engineered to forward many 87 more packets per second. In order to fulfill this requirement, the 88 forwarder copies a fixed number of bytes from the beginning of the 89 packet to on-chip memory. The ASIC does this because it can access 90 on-chip memory much more quickly than it can access off-chip memory. 91 Once the beginning of the packet has been transferred to on-chip 92 memory, subsequent processing and forwarding decisions can be made 93 very quickly. 95 The act of copying bytes from the beginning of a packet to on-chip 96 memory consumes both wall-time and processor cycles. Therefore, the 97 number of bytes copied to on-chip memory must be chosen wisely. If a 98 forwarder copies more bytes than it needs, it wastes resources, 99 significantly increasing cost and decreasing maximum performance. If 100 it copies too few bytes, it cannot parse the header chain and make a 101 correct forwarding decision. 103 As currently specified in [RFC2460], the IPv6 header chain can exceed 104 64 kilobytes. However, packets with header chains exceeding 128 105 bytes are rarely observed on the Internet. Therefore, most ASIC- 106 based forwarders copy a relatively small number of bytes from the 107 beginning of the packet into on-chip memory. 109 This document explains why IPv6 header chain length affects the cost 110 of ASIC-based packet forwarding. It also explains why some network 111 service providers discard packets with exceptionally long header 112 chains. Finally, it identifies a reasonable header chain length. 113 While a network service provider can enforce any filtering policy 114 that supports its security model, a network service provider SHOULD 115 NOT discard IPv6 packets based upon header chain length if the header 116 chain is not longer than the value specified herein. 118 1.1. Termnology 120 For the purposes of this document, the terms Extension Header, Header 121 Chain and Upper-layer Header are used as follows: 123 Extension Header : 125 Extension Headers are defined in Section 4 of [RFC2460]. 126 Currently, six extension header types are defined. [RFC2460] 127 defines the hop-by-hop, routing, fragment and destination options 128 extension header types. [RFC4302] defines the authentication 129 header (AH) type and [RFC4303] defines the encapsulating security 130 payload (ESP) header type. 132 Header Chain : 134 The initial portion of an IPv6 datagram containing headers. The 135 first member of the header chain is always an IPv6 header. For a 136 subsequent header to qualify as a member of the header chain, it 137 must be referenced by the "Next Header" field of the previous 138 member of the header chain. The header chain can include IPv6 139 headers, IPv6 extension headers and an upper-layer header. If the 140 header chain includes two IPv6 headers, as is the case when IPv6 141 is tunneled over IPv6, the second IPv6 header terminates the 142 header chain. Any headers following the second IPv6 headers are 143 not members of the header chain. Likewise, if the header chain 144 includes an ESP header, the ESP header terminates the header 145 chain. Only the first 8 bytes of the ESP header contribute to the 146 header chain length. Any headers following ESP header are not 147 members of the header chain. 149 Upper-layer Header : 151 In the general case, the upper-layer header is the first member of 152 the header chain that is neither an IPv6 header nor an IPv6 153 extension header. Typically, the upper-layer header represents a 154 transport protocol (e.g., TCP, UDP, SCTP). However, it can 155 represent a non-transport layer protocol. For example, when IPv4 156 is tunneled over IPv6, the upper-layer header is an IPv4 header. 157 If the header chain includes two IPv6 headers, as is the case when 158 IPv6 is tunneled over IPv6, the second IPv6 header is considered 159 to be the upper-layer header and terminates the header chain. 161 For the purposes of this document, when the upper-layer protocol 162 is ICMPv6, the first 32 bits of the ICMPv6 message (i.e., the 163 type, code fields and checksum fields) are considered to be the 164 ICMPv6 header. 166 The upper-layer payload is not part of the upper-layer header and 167 therefore, is not part of the IPv6 header chain. For example, if 168 the upper-layer protocol is TCP, the TCP payload is not part of 169 the TCP header or the IPv6 header chain. 171 2. Background 173 When IPv6 was first conceived, forwarding was largely performed in 174 software running on general-purpose processors. Due to the required 175 performance, parsing a long header chain was not an issue. 177 In the years between the conception of IPv6 and publication of this 178 documentation, the Internet evolved as follows: 180 o Throughput requirements increased dramatically, requiring the 181 deployment of ASIC-based forwarders in both core and edge networks 183 o New network types emerged, including very large enterprises, 184 social networks, data centers and "clouds". Like core networks, 185 these network require very high throughput. Like edge networks, 186 these networks require "high-touch" edge services, which require 187 the forwarder to access the entire header chain 189 o Requirements for "high-touch" service, which require the forwarder 190 to access the entire header chain, increased in networks of all 191 kinds 193 During those years, IPv4 [RFC0791] was the most commonly deployed 194 protocol on the Internet. ASIC-based forwarders could meet the 195 requirements of the evolving Internet because ASICs could predict the 196 number of bytes that needed to be copied into on-chip memory in order 197 to make a forwarding decision. 199 Today, as IPv6 is being deployed, ASIC-forwarders cannot safely 200 predict the size of the header chain. This leads to complexity and 201 vulnerability in handling extension headers. For this reason, many 202 network operators filter all IPv6 packets containing extension 203 headers. 205 3. Need to see upper-layer to filter 207 There is a school of thought that ISPs, content-providers and 208 enterprises should not be performing any sort of filtering in the 209 network and that the filtering is more appropriately performed at the 210 end hosts. Unfortunately this solution, while clean and elegant, 211 simply doesn't work in the real world. Filtering unknown traffic at 212 the edge (and / or in the core) of the network is needed for a number 213 of reasons, some of which are discussed below. 215 o ISPs (and cloud providers) are routinely called upon to filter DoS 216 traffic aimed at their customers (for example to block multi-Gbps 217 DNS reflection attacks aimed at web servers, etc). At Large Edge 218 Sites this is often a large part of the "service" provided by the 219 network team. 221 o IPv6 stacks are still relatively immature and operators still have 222 concerns that stack or kernel vulnerabilities may still surface. 223 If this turns out to be the case, a means to protect the end nodes 224 is needed. 226 o In many enterprises the end systems are not sufficiently hardened 227 to be exposed on the public Internet. Even if there were no 228 remotely exploitable operating system vulnerabilities there is 229 significant risk that an employee may install vulnerable software, 230 accidentally share confidential files or folders publicly or start 231 offering (unauthorized) services. 233 o Content providers (and similar) need to be able to filter traffic 234 and only allow "expected" traffic into their networks. This is 235 needed both for DoS protection, but also to ensure that 236 development systems, databases, test systems, etc are not 237 accidentally exposed. 239 o While it would be nice if all employees, system and database 240 administrators could be trusted to always ensure that only the 241 "correct" services were listening on ports, that all software was 242 always fully patches (and contained no vulnerabilities), that 243 confidential data was only shared with internal addressed and that 244 all credentials were strong and regularly changed, this simply 245 does not reflect reality. 247 All of these lead to the requirement that operators be able to filter 248 at Layer 3 and Layer 4, at line rate, in the network. Obviously, to 249 be able to filter at layers 3 and 4, the router needs to be able to 250 see the layer 3 and 4 information. Unfortunately, if the size of 251 extension header chain varies between 0 and 64 kilobytes, extension 252 headers cannot be processed efficiently in ASICs. 254 Because many implementation do not process IPv6 extension headers 255 well, many operators filter all IPv6 packets that include them. 257 4. Recommendations 259 An ISP SHOULD NOT discard IPv6 packets based solely upon header chain 260 length if the header chain contains 128 bytes or fewer. However, it 261 is common practice ISPs to filter IPv6 packets with long extension 262 header chains. This document offers no recommendation regarding the 263 maximum extension header chain length that an ISP should forward. 265 See Section 1.1 for a formal definition of the header chain. 267 5. IANA Considerations 269 This document makes no requests of the IANA 271 6. Security Considerations 273 There are potential implications to the filtering or acceptances of 274 packets which cannot be processed according to the configuration of 275 the network operator. It is clear from the vantage point of the 276 authors that implementors and operators should be aware of 277 implications of relying on extension header chains or apply policies 278 that must necessarily discard packets which contain them. 280 7. Acknowledgements 282 The authors wish to thank Paul Hoffman, KK and Fernando Gont. 284 8. Normative References 286 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 287 1981. 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997. 292 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 293 (IPv6) Specification", RFC 2460, December 1998. 295 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 296 2005. 298 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 299 4303, December 2005. 301 Appendix A. Changes / Author Notes. 303 [RFC Editor: Please remove this section before publication ] 305 Template to -00 307 o Initial submission. 309 -00 to -01 311 o Added maximum header chain recommendation. 313 o Rewrite the forwarding description. 315 Authors' Addresses 317 Warren Kumari 318 Google 319 1600 Amphitheatre Parkway 320 Mountain View, CA 94043 321 US 323 Email: warren@kumari.net 324 Joel Jaeggli 325 Zynga 326 675 East Middlefield 327 Mountain View, CA 328 USA 330 Email: jjaeggli@zynga.com 332 Ronald P Bonica 333 Juniper Networks 334 2251 Corporate Park Drive 335 Herndon, VA 336 USA 338 Email: rbonica@juniper.net