idnits 2.17.00 (12 Aug 2021) /tmp/idnits3610/draft-wkumari-long-headers-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 -- The document date (February 4, 2013) is 3393 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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 template W. Kumari 3 Internet-Draft Google 4 Intended status: Informational J. Jaeggli 5 Expires: August 8, 2013 Zynga 6 R. Bonica 7 Juniper Networks 8 February 4, 2013 10 Operational Issues Associated With Long IPv6 Extension Header Chains 11 draft-wkumari-long-headers-00 13 Abstract 15 This document outlines a set of issues with the use of long IPv6 16 extension header chains. It considers their use in the context of 17 today's IPv6 Internet and potential interaction with forwarding 18 devices that require upper-layer headers. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 8, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Understanding the scale. . . . . . . . . . . . . . . . . . 4 57 2.2. Different types of networks. . . . . . . . . . . . . . . . 5 58 2.3. Large Edge Site Operators. . . . . . . . . . . . . . . . . 5 59 3. Need to see upper-layer to filter . . . . . . . . . . . . . . . 6 60 4. Recomendations . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 64 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 65 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 Many forwarding devices make forwarding decisions based upon 71 information that is drawn from both the IPv6 and transport 72 headers.When a software-based forwarding device encounters an IPv6 73 datagram that includes a long extension header chain, it parses the 74 header chain, acquires required information and makes its forwarding 75 decision. Typically, software-based forwarders are not required to 76 process a large number of packets per second. Therefore, they can 77 perform the above mentioned procedure within a specified time and 78 processing budget. 80 By contrast, ASIC-based forwarders are typically required to forward 81 many more packets per second. In order to fulfill this requirement, 82 the forwarder copies an arbitrarily chosen number of bytes for the 83 beginning of the packet to on-chip memory. The ASIC does this 84 because it can access on-chip memory much more quickly than it can 85 access off-chip memory. Having copied the beginning of the packet to 86 on-chip memory, the forwarder can make its forwarding decision very 87 quickly, because subsequent packet processing can all be achieved on- 88 chip. 90 The act of copying the beginning of a packet to on-chip memory 91 consumes both wall-time and processor cycles. The number of bytes 92 copied is directly proportional to the amount of wall-time and 93 processing cycles consumed. Therefore, the number of bytes copied to 94 on-chip memory must be chosen wisely. If a forwarder copies more 95 bytes than it needs, it wastes resources. If it copies too few 96 bytes, it cannot parse the extension header chain and make the 97 correct forwarding decision. 99 This memo describes problems that are caused by IPv6 packets 100 containing large extension header chains. Specifically, it describes 101 how ASIC-based forwarding devices may fail when both of the following 102 conditions are true: 104 o The forwarder is required to make a forwarding decision based upon 105 information that is drawn from both the IPv6 and transport layer 106 headers 107 o The forwarder encounters a packet in which the length of the IPv6 108 header plus the length of the extension header chain is greater 109 than the number of bytes that the ASIC copies to on-chip memory 110 This memo also presents recommendations, and is intended to spark 111 discussions. 113 2. Background 115 Router architectures have evolved over time, and routers have become 116 more specialized devices. Initially (and in some cases still), 117 routers were "software switched" - a packet would arrive at the 118 router and software running on a general purpose microprocessor would 119 look at the packet, make forwarding decisions, perform additional 120 packet processing (decrement TTL, recalculate checksum, perhaps 121 process source route options) and then send the packet towards the 122 destination. This approach began to run into scaling / performance 123 issues for "core" type routers. More and more of the forwarding 124 logic has moved to Application Specific Integrated Circuits (ASICs) 125 and Network Processors. Networks that need to shift a large amount 126 of traffic (for example, large ISPs, enterprises, and content 127 providers generally purchase these "core" style devices. 129 As the amount of traffic (and correspondingly interface speeds 130 increased), the buses between linecards and to the forwarding ASICs 131 have become a bottleneck. In order to scale to the required speeds, 132 router manufacturers began segmenting the incoming packet into a 133 number of "cells" and only sending the first cell to the forwarding 134 logic.. Once this decision is made, the forwarding ASIC notifies the 135 output interface, which then sucks all of the other cells across the 136 switch fabric, assembles them into the correct order and ships the 137 packet. While this is more complex than simply shipping the entire 138 packet to the forwarding logic, it dramatically decreases the amount 139 of very fast memory associated with the forwarding logic, it works in 140 general quite well with IPv4 packets and it was needed to allow 141 routers to scale to the current demands. 143 In IPv4 this first cell contains all of the information required to 144 make forwarding (and filtering!) decisions, but this is not 145 necessarily the case in IPv6. 147 Readers of this document are expected to be familiar with [RFC2460] 148 Section 4. 150 2.1. Understanding the scale. 152 In order to understand why designs like this have evolved, it is 153 useful to be able to get a rough idea of the sorts of scale we are 154 discussing. 156 A single 100Gbps Ethernet interface, filled with 64byte packets 157 receives approximately 148.8 million packets per second, and so has 158 approximerik ately 6.7 nanoseconds to forward the packet in order to 159 keep up with the input rate (for comparison, this is 26 clock cycles 160 on a 3.8Ghz CPU core). 162 A (current) large router contains multiple distributed packet 163 processing engines, and a single chassis might have an aggregate 164 switching capacity of around 4.5Tbps. 166 2.2. Different types of networks. 168 The classic view of the Internet is that there are a large number of 169 "edge" networks that connect to a "core" network, comprised of large 170 ISPs. The edge networks create (and consume) the data, the core 171 simply transits the traffic between the edge networks. Because the 172 core aggregates all of traffic from the edge networks it is made up 173 of huge, fast routers. Because the edge networks shift much less 174 traffic they use much smaller routers. While this makes a pretty 175 (and easily understood) picture, the reality is much more complex -- 176 and messier. 178 There exist a number of "edge" networks whose scale of traffic make 179 them look much more like, and employ technology associated, with 180 "core" networks - these are entities like video distribution 181 networks, "cloud providers", social networks, large enterprises and 182 similar. For the purpose of this document we will call these Large 183 Edge Sites. This is relevant to this document because these large 184 edge sites often have network requirements that differ from 185 traditional ISPs, and often wish to perform more filtering of 186 traffic. 188 2.3. Large Edge Site Operators. 190 Some properties common to large edge site operators. 192 o Run their own "backbone". 193 o Push or Sink significant amounts of traffic from peers or 194 providers. 195 o They lack customer routes, e.g. they are their own customer, not a 196 transit ISP in the traditional sense. 197 o Peer with a large number of ISPs and other LES / edges. 198 o Look sort of like an enterprise. Apply ingress policy on upsteam 199 edge or locations other than end systems. The principle is to 200 only allow in traffic that is expected (incoming connections are 201 by nature unsolicited) 202 o Filter out any traffic that does not conform to expectations. 203 This is as much an availability/performance/protocol requirement 204 (as we will see) as it is a security posture. 205 o The operator is not an Internet Service Provider in the 206 traditional sense; the customer is an application which in turn is 207 leveraged over the Internet. 209 Operator goals (in this order): 211 1. Keeping their (and their users) data secure. 212 2. Keeping the networks up and running. 213 3. Keeping the network performing well. 214 4. Architect the network to be scalable. 215 5. Costs 216 6. Standards compliance. 218 This should in no way be considered to mean that operators throw away 219 packets capriciously, but in a decision between security and 220 availability, and standards compliance, the former considerations may 221 trump the later. 223 3. Need to see upper-layer to filter 225 There is a school of thought that ISPs, content-providers and 226 enterprises should not be performing any sort of filtering in the 227 network and that the filtering is more appropriately performed at the 228 end hosts. Unfortinalty this solution, while clean and elegant, 229 simply doesn't work in the real world. Filtering unknown traffic at 230 the edge (and / or in the core) of the network is needed for a number 231 of reasons, some of which are discussed below (these are not really 232 germane to the draft, but discussing them here may help head off many 233 discussions). 235 o ISPs (and cloud providers) are routinely called upon to filter DoS 236 traffic aimed at their customers (for example to block multi-Gbps 237 DNS reflection attacks aimed at web servers, etc). At Large Edge 238 Sites this is often a large part of the "service" provided by the 239 network team. 240 o IPv6 stacks are still relatively immature and operators still have 241 concerns that stack or kernel vulnerabilities may still surface. 242 If this turns out to be the case, a means to protect the end nodes 243 is needed. 244 o In many enterprises the end systems are not sufficiently hardened 245 to be exposed on the public Internet. Even if there were no 246 remotely exploitable operating system vulnerabilities there is 247 significant risk that an employee may install vulnerable software, 248 accidentally share confidential files or folders publicly or start 249 offering (unauthorized) services. 250 o Content providers (and similar) need to be able to filter traffic 251 and only allow "expected" traffic into their networks. This is 252 needed both for DoS protection, but also to ensure that 253 development systems, databases, test systems, etc are not 254 accidentally exposed. 255 While it would be nice if all employees, system and database 256 administrators could be trusted to always ensure that only the 257 "correct" services were listening on ports, that all software was 258 always fully patches (and contained no vulnerabilities), that 259 confidential data was only shared with internal addressed and that 260 all credentials were strong and regularly changed, this simply does 261 not reflect reality. 263 All of these lead to the requirement that operators be able to filter 264 at Layer 3 and Layer 4, at line rate, in the network. Obviously, to 265 be able to filter at layers 3 and 4, the router needs to be able to 266 see the layer 3 and 4 information. Unfortunately, if the upper layer 267 header is not available in the first cell / segment of the larger 268 packet we may not be able to see it. This applies to cases where 269 extension headers pad the variable length portion of the header, 270 beyond the cell size or, the presumably rarer and probably 271 deliberately malicious case of initial fragments which do not contain 272 an upper layer header. 274 In one widely deployed router architecture, if there are any 275 extension headers between the IPv6 header and the upper-layer header, 276 the forwarding logic never sees the upper-layer header, and so is not 277 able to filter on it. This means that the operator has no visibility 278 into the packet contents, and so many operators choose to simply drop 279 all packets with any extension headers. 281 Network operators may filter traffic with extention header, because 282 of the lack of fixed extention header size, the complexity of 283 following header chains, and the inability of deployed routers to 284 look sufficently deep into packets to see the upper-layer header. 286 For this reason, appplications and IPv6 stacks should avoid the use 287 of extention headers whenever possaible, and applications should be 288 designed to deal with the posibility that packets containing 289 extention headers may not be delivered. 291 4. Recomendations 293 This document discourages the use of IPv6 Extension headers, and 294 advises the community that some operators currently filter ingress 295 packets that contain more than one extension header (and / or headers 296 that exceed a small number of bytes). 298 5. IANA Considerations 300 This document makes no requests of the IANA 302 6. Security Considerations 304 There are potential implications to the filtering or acceptances of 305 packets which cannot be processed according to the configuration of 306 the network operator. It is clear from the vantage point of the 307 authors that implementors and operators should be aware of 308 implications of relying on extension header chains or apply policies 309 that must necessarily discard packets which contain them. 311 7. Acknowledgements 313 The authors wish to thank Paul Hoffman, KK and Fernando Gont. 315 They also wish to thank folk for not getting all up in arms :-P 317 8. Normative References 319 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 320 (IPv6) Specification", RFC 2460, December 1998. 322 Appendix A. Changes / Author Notes. 324 [RFC Editor: Please remove this section before publication ] 326 o Initial submission. 328 Authors' Addresses 330 Warren Kumari 331 Google 332 1600 Amphitheatre Parkway 333 Mountain View, CA 94043 334 US 336 Email: warren@kumari.net 337 Joel Jaeggli 338 Zynga 339 675 East Middlefield 340 Mountain View, CA 341 USA 343 Email: jjaeggli@zynga.com 345 Ronald P Bonica 346 Juniper Networks 347 2251 Corporate Park Drive 348 Herndon, VA 349 USA 351 Email: internet-drafts@bonica.org