Operational Issues Associated With Long IPv6 Extension Header Chains
draft-wkumari-long-headers-00

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]