template W. Kumari Internet-Draft Google Intended status: Informational J. Jaeggli Expires: August 8, 2013 Zynga R. Bonica Juniper Networks February 4, 2013 Operational Issues Associated With Long IPv6 Extension Header Chains draft-wkumari-long-headers-00 Abstract This document outlines a set of issues with the use of long IPv6 extension header chains. It considers their use in the context of today's IPv6 Internet and potential interaction with forwarding devices that require upper-layer headers. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 8, 2013. Copyright Notice Copyright (c) 2013 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 Kumari, et al. Expires August 8, 2013 [Page 1] Internet-Draft long-v6-headers February 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Understanding the scale. . . . . . . . . . . . . . . . . . 4 2.2. Different types of networks. . . . . . . . . . . . . . . . 5 2.3. Large Edge Site Operators. . . . . . . . . . . . . . . . . 5 3. Need to see upper-layer to filter . . . . . . . . . . . . . . . 6 4. Recomendations . . . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Kumari, et al. Expires August 8, 2013 [Page 2] Internet-Draft long-v6-headers February 2013 1. Introduction Many forwarding devices make forwarding decisions based upon information that is drawn from both the IPv6 and transport headers.When a software-based forwarding device encounters an IPv6 datagram that includes a long extension header chain, it parses the header chain, acquires required information and makes its forwarding decision. Typically, software-based forwarders are not required to process a large number of packets per second. Therefore, they can perform the above mentioned procedure within a specified time and processing budget. By contrast, ASIC-based forwarders are typically required to forward many more packets per second. In order to fulfill this requirement, the forwarder copies an arbitrarily chosen number of bytes for the beginning of the packet to on-chip memory. The ASIC does this because it can access on-chip memory much more quickly than it can access off-chip memory. Having copied the beginning of the packet to on-chip memory, the forwarder can make its forwarding decision very quickly, because subsequent packet processing can all be achieved on- chip. The act of copying the beginning of a packet to on-chip memory consumes both wall-time and processor cycles. The number of bytes copied is directly proportional to the amount of wall-time and processing cycles consumed. Therefore, the number of bytes copied to on-chip memory must be chosen wisely. If a forwarder copies more bytes than it needs, it wastes resources. If it copies too few bytes, it cannot parse the extension header chain and make the correct forwarding decision. This memo describes problems that are caused by IPv6 packets containing large extension header chains. Specifically, it describes how ASIC-based forwarding devices may fail when both of the following conditions are true: o The forwarder is required to make a forwarding decision based upon information that is drawn from both the IPv6 and transport layer headers o The forwarder encounters a packet in which the length of the IPv6 header plus the length of the extension header chain is greater than the number of bytes that the ASIC copies to on-chip memory This memo also presents recommendations, and is intended to spark discussions. Kumari, et al. Expires August 8, 2013 [Page 3] Internet-Draft long-v6-headers February 2013 2. Background Router architectures have evolved over time, and routers have become more specialized devices. Initially (and in some cases still), routers were "software switched" - a packet would arrive at the router and software running on a general purpose microprocessor would look at the packet, make forwarding decisions, perform additional packet processing (decrement TTL, recalculate checksum, perhaps process source route options) and then send the packet towards the destination. This approach began to run into scaling / performance issues for "core" type routers. More and more of the forwarding logic has moved to Application Specific Integrated Circuits (ASICs) and Network Processors. Networks that need to shift a large amount of traffic (for example, large ISPs, enterprises, and content providers generally purchase these "core" style devices. As the amount of traffic (and correspondingly interface speeds increased), the buses between linecards and to the forwarding ASICs have become a bottleneck. In order to scale to the required speeds, router manufacturers began segmenting the incoming packet into a number of "cells" and only sending the first cell to the forwarding logic.. Once this decision is made, the forwarding ASIC notifies the output interface, which then sucks all of the other cells across the switch fabric, assembles them into the correct order and ships the packet. While this is more complex than simply shipping the entire packet to the forwarding logic, it dramatically decreases the amount of very fast memory associated with the forwarding logic, it works in general quite well with IPv4 packets and it was needed to allow routers to scale to the current demands. In IPv4 this first cell contains all of the information required to make forwarding (and filtering!) decisions, but this is not necessarily the case in IPv6. Readers of this document are expected to be familiar with [RFC2460] Section 4. 2.1. Understanding the scale. In order to understand why designs like this have evolved, it is useful to be able to get a rough idea of the sorts of scale we are discussing. A single 100Gbps Ethernet interface, filled with 64byte packets receives approximately 148.8 million packets per second, and so has approximerik ately 6.7 nanoseconds to forward the packet in order to keep up with the input rate (for comparison, this is 26 clock cycles on a 3.8Ghz CPU core). Kumari, et al. Expires August 8, 2013 [Page 4] Internet-Draft long-v6-headers February 2013 A (current) large router contains multiple distributed packet processing engines, and a single chassis might have an aggregate switching capacity of around 4.5Tbps. 2.2. Different types of networks. The classic view of the Internet is that there are a large number of "edge" networks that connect to a "core" network, comprised of large ISPs. The edge networks create (and consume) the data, the core simply transits the traffic between the edge networks. Because the core aggregates all of traffic from the edge networks it is made up of huge, fast routers. Because the edge networks shift much less traffic they use much smaller routers. While this makes a pretty (and easily understood) picture, the reality is much more complex -- and messier. There exist a number of "edge" networks whose scale of traffic make them look much more like, and employ technology associated, with "core" networks - these are entities like video distribution networks, "cloud providers", social networks, large enterprises and similar. For the purpose of this document we will call these Large Edge Sites. This is relevant to this document because these large edge sites often have network requirements that differ from traditional ISPs, and often wish to perform more filtering of traffic. 2.3. Large Edge Site Operators. Some properties common to large edge site operators. o Run their own "backbone". o Push or Sink significant amounts of traffic from peers or providers. o They lack customer routes, e.g. they are their own customer, not a transit ISP in the traditional sense. o Peer with a large number of ISPs and other LES / edges. o Look sort of like an enterprise. Apply ingress policy on upsteam edge or locations other than end systems. The principle is to only allow in traffic that is expected (incoming connections are by nature unsolicited) o Filter out any traffic that does not conform to expectations. This is as much an availability/performance/protocol requirement (as we will see) as it is a security posture. o The operator is not an Internet Service Provider in the traditional sense; the customer is an application which in turn is leveraged over the Internet. Operator goals (in this order): Kumari, et al. Expires August 8, 2013 [Page 5] Internet-Draft long-v6-headers February 2013 1. Keeping their (and their users) data secure. 2. Keeping the networks up and running. 3. Keeping the network performing well. 4. Architect the network to be scalable. 5. Costs 6. Standards compliance. This should in no way be considered to mean that operators throw away packets capriciously, but in a decision between security and availability, and standards compliance, the former considerations may trump the later. 3. Need to see upper-layer to filter There is a school of thought that ISPs, content-providers and enterprises should not be performing any sort of filtering in the network and that the filtering is more appropriately performed at the end hosts. Unfortinalty this solution, while clean and elegant, simply doesn't work in the real world. Filtering unknown traffic at the edge (and / or in the core) of the network is needed for a number of reasons, some of which are discussed below (these are not really germane to the draft, but discussing them here may help head off many discussions). o ISPs (and cloud providers) are routinely called upon to filter DoS traffic aimed at their customers (for example to block multi-Gbps DNS reflection attacks aimed at web servers, etc). At Large Edge Sites this is often a large part of the "service" provided by the network team. o IPv6 stacks are still relatively immature and operators still have concerns that stack or kernel vulnerabilities may still surface. If this turns out to be the case, a means to protect the end nodes is needed. o In many enterprises the end systems are not sufficiently hardened to be exposed on the public Internet. Even if there were no remotely exploitable operating system vulnerabilities there is significant risk that an employee may install vulnerable software, accidentally share confidential files or folders publicly or start offering (unauthorized) services. o Content providers (and similar) need to be able to filter traffic and only allow "expected" traffic into their networks. This is needed both for DoS protection, but also to ensure that development systems, databases, test systems, etc are not accidentally exposed. While it would be nice if all employees, system and database administrators could be trusted to always ensure that only the "correct" services were listening on ports, that all software was Kumari, et al. Expires August 8, 2013 [Page 6] Internet-Draft long-v6-headers February 2013 always fully patches (and contained no vulnerabilities), that confidential data was only shared with internal addressed and that all credentials were strong and regularly changed, this simply does not reflect reality. All of these lead to the requirement that operators be able to filter at Layer 3 and Layer 4, at line rate, in the network. Obviously, to be able to filter at layers 3 and 4, the router needs to be able to see the layer 3 and 4 information. Unfortunately, if the upper layer header is not available in the first cell / segment of the larger packet we may not be able to see it. This applies to cases where extension headers pad the variable length portion of the header, beyond the cell size or, the presumably rarer and probably deliberately malicious case of initial fragments which do not contain an upper layer header. In one widely deployed router architecture, if there are any extension headers between the IPv6 header and the upper-layer header, the forwarding logic never sees the upper-layer header, and so is not able to filter on it. This means that the operator has no visibility into the packet contents, and so many operators choose to simply drop all packets with any extension headers. Network operators may filter traffic with extention header, because of the lack of fixed extention header size, the complexity of following header chains, and the inability of deployed routers to look sufficently deep into packets to see the upper-layer header. For this reason, appplications and IPv6 stacks should avoid the use of extention headers whenever possaible, and applications should be designed to deal with the posibility that packets containing extention headers may not be delivered. 4. Recomendations This document discourages the use of IPv6 Extension headers, and advises the community that some operators currently filter ingress packets that contain more than one extension header (and / or headers that exceed a small number of bytes). 5. IANA Considerations This document makes no requests of the IANA Kumari, et al. Expires August 8, 2013 [Page 7] Internet-Draft long-v6-headers February 2013 6. Security Considerations There are potential implications to the filtering or acceptances of packets which cannot be processed according to the configuration of the network operator. It is clear from the vantage point of the authors that implementors and operators should be aware of implications of relying on extension header chains or apply policies that must necessarily discard packets which contain them. 7. Acknowledgements The authors wish to thank Paul Hoffman, KK and Fernando Gont. They also wish to thank folk for not getting all up in arms :-P 8. Normative References [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. Appendix A. Changes / Author Notes. [RFC Editor: Please remove this section before publication ] o Initial submission. Authors' Addresses Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 US Email: warren@kumari.net Kumari, et al. Expires August 8, 2013 [Page 8] Internet-Draft long-v6-headers February 2013 Joel Jaeggli Zynga 675 East Middlefield Mountain View, CA USA Email: jjaeggli@zynga.com Ronald P Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA USA Email: internet-drafts@bonica.org Kumari, et al. Expires August 8, 2013 [Page 9]