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

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Authors Warren Kumari  , Joel Jaeggli  , Ron Bonica 
Last updated 2013-07-03
Stream (None)
Formats plain text pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
6MAN                                                           W. Kumari
Internet-Draft                                                    Google
Intended status: Best Current Practice                        J. Jaeggli
Expires: January 05, 2014                                          Zynga
                                                               R. Bonica
                                                        Juniper Networks
                                                           July 04, 2013

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

Abstract

   This document explains why IPv6 header chain length affects the cost
   of ASIC-based packet forwarding.  It also explains why some network
   service providers discard packets with exceptionally long header
   chains.  Finally, it identifies a reasonable header chain length.
   While a network service provider can enforce any filtering policy
   that supports its security model, a network service provider should
   not discard IPv6 packets based solely upon header chain length if the
   header chain is not longer than the value specified herein.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 January 05, 2014.

Copyright Notice

Kumari, et al.          Expires January 05, 2014                [Page 1]
Internet-Draft               long-v6-headers                   July 2013

   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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Termnology  . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Need to see upper-layer to filter . . . . . . . . . . . . . .   5
   4.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Appendix A.  Changes / Author Notes.  . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   In order to make a forwarding decision, the forwarding device may
   require information from both the IPv6 header and an upper layer
   header.  When a software-based forwarder encounters an IPv6 datagram
   that includes a long header chain, it parses the header chain,
   acquires the 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 their processing budget.

   By contrast, ASIC-based forwarders are engineered to forward many
   more packets per second.  In order to fulfill this requirement, the
   forwarder copies a fixed number of bytes from 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.
   Once the beginning of the packet has been transferred to on-chip
   memory, subsequent processing and forwarding decisions can be made
   very quickly.

Kumari, et al.          Expires January 05, 2014                [Page 2]
Internet-Draft               long-v6-headers                   July 2013

   The act of copying bytes from the beginning of a packet to on-chip
   memory consumes both wall-time and processor cycles.  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,
   significantly increasing cost and decreasing maximum performance.  If
   it copies too few bytes, it cannot parse the header chain and make a
   correct forwarding decision.

   As currently specified in [RFC2460], the IPv6 header chain can exceed
   64 kilobytes.  However, packets with header chains exceeding 128
   bytes are rarely observed on the Internet.  Therefore, most ASIC-
   based forwarders copy a relatively small number of bytes from the
   beginning of the packet into on-chip memory.

   This document explains why IPv6 header chain length affects the cost
   of ASIC-based packet forwarding.  It also explains why some network
   service providers discard packets with exceptionally long header
   chains.  Finally, it identifies a reasonable header chain length.
   While a network service provider can enforce any filtering policy
   that supports its security model, a network service provider SHOULD
   NOT discard IPv6 packets based upon header chain length if the header
   chain is not longer than the value specified herein.

1.1.  Termnology

   For the purposes of this document, the terms Extension Header, Header
   Chain and Upper-layer Header are used as follows:

   Extension Header :

      Extension Headers are defined in Section 4 of [RFC2460].
      Currently, six extension header types are defined.  [RFC2460]
      defines the hop-by-hop, routing, fragment and destination options
      extension header types.  [RFC4302] defines the authentication
      header (AH) type and [RFC4303] defines the encapsulating security
      payload (ESP) header type.

   Header Chain :

      The initial portion of an IPv6 datagram containing headers.  The
      first member of the header chain is always an IPv6 header.  For a
      subsequent header to qualify as a member of the header chain, it
      must be referenced by the "Next Header" field of the previous
      member of the header chain.  The header chain can include IPv6
      headers, IPv6 extension headers and an upper-layer header.  If the
      header chain includes two IPv6 headers, as is the case when IPv6
      is tunneled over IPv6, the second IPv6 header terminates the
      header chain.  Any headers following the second IPv6 headers are

Kumari, et al.          Expires January 05, 2014                [Page 3]
Internet-Draft               long-v6-headers                   July 2013

      not members of the header chain.  Likewise, if the header chain
      includes an ESP header, the ESP header terminates the header
      chain.  Only the first 8 bytes of the ESP header contribute to the
      header chain length.  Any headers following ESP header are not
      members of the header chain.

   Upper-layer Header :

      In the general case, the upper-layer header is the first member of
      the header chain that is neither an IPv6 header nor an IPv6
      extension header.  Typically, the upper-layer header represents a
      transport protocol (e.g., TCP, UDP, SCTP).  However, it can
      represent a non-transport layer protocol.  For example, when IPv4
      is tunneled over IPv6, the upper-layer header is an IPv4 header.
      If the header chain includes two IPv6 headers, as is the case when
      IPv6 is tunneled over IPv6, the second IPv6 header is considered
      to be the upper-layer header and terminates the header chain.

      For the purposes of this document, when the upper-layer protocol
      is ICMPv6, the first 32 bits of the ICMPv6 message (i.e., the
      type, code fields and checksum fields) are considered to be the
      ICMPv6 header.

      The upper-layer payload is not part of the upper-layer header and
      therefore, is not part of the IPv6 header chain.  For example, if
      the upper-layer protocol is TCP, the TCP payload is not part of
      the TCP header or the IPv6 header chain.

2.  Background

   When IPv6 was first conceived, forwarding was largely performed in
   software running on general-purpose processors.  Due to the required
   performance, parsing a long header chain was not an issue.

   In the years between the conception of IPv6 and publication of this
   documentation, the Internet evolved as follows:

   o  Throughput requirements increased dramatically, requiring the
      deployment of ASIC-based forwarders in both core and edge networks

   o  New network types emerged, including very large enterprises,
      social networks, data centers and "clouds".  Like core networks,
      these network require very high throughput.  Like edge networks,
      these networks require "high-touch" edge services, which require
      the forwarder to access the entire header chain

Kumari, et al.          Expires January 05, 2014                [Page 4]
Internet-Draft               long-v6-headers                   July 2013

   o  Requirements for "high-touch" service, which require the forwarder
      to access the entire header chain, increased in networks of all
      kinds

   During those years, IPv4 [RFC0791] was the most commonly deployed
   protocol on the Internet.  ASIC-based forwarders could meet the
   requirements of the evolving Internet because ASICs could predict the
   number of bytes that needed to be copied into on-chip memory in order
   to make a forwarding decision.

   Today, as IPv6 is being deployed, ASIC-forwarders cannot safely
   predict the size of the header chain.  This leads to complexity and
   vulnerability in handling extension headers.  For this reason, many
   network operators filter all IPv6 packets containing extension
   headers.

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.  Unfortunately 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.

   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.

Kumari, et al.          Expires January 05, 2014                [Page 5]
Internet-Draft               long-v6-headers                   July 2013

   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.

   o  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
      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 size of
   extension header chain varies between 0 and 64 kilobytes, extension
   headers cannot be processed efficiently in ASICs.

   Because many implementation do not process IPv6 extension headers
   well, many operators filter all IPv6 packets that include them.

4.  Recommendations

   An ISP SHOULD NOT discard IPv6 packets based solely upon header chain
   length if the header chain contains 128 bytes or fewer.  However, it
   is common practice ISPs to filter IPv6 packets with long extension
   header chains.  This document offers no recommendation regarding the
   maximum extension header chain length that an ISP should forward.

   See Section 1.1 for a formal definition of the header chain.

5.  IANA Considerations

   This document makes no requests of the IANA

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.

Kumari, et al.          Expires January 05, 2014                [Page 6]
Internet-Draft               long-v6-headers                   July 2013

7.  Acknowledgements

   The authors wish to thank Paul Hoffman, KK and Fernando Gont.

8.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, December
              2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
              4303, December 2005.

Appendix A.  Changes / Author Notes.

   [RFC Editor: Please remove this section before publication ]

   Template to -00

   o  Initial submission.

   -00 to -01

   o  Added maximum header chain recommendation.

   o  Rewrite the forwarding description.

Authors' Addresses

   Warren Kumari
   Google
   1600 Amphitheatre Parkway
   Mountain View, CA  94043
   US

   Email: warren@kumari.net

Kumari, et al.          Expires January 05, 2014                [Page 7]
Internet-Draft               long-v6-headers                   July 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: rbonica@juniper.net

Kumari, et al.          Expires January 05, 2014                [Page 8]