[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

IPv6 Maintenance Working Group                             P. Kampanakis
Internet-Draft                                             Cisco Systems
Intended status: Informational                            August 5, 2014
Expires: February 6, 2015


      Implementation Guidelines for parsing IPv6 Extension Headers
                 draft-kampanakis-6man-ipv6-eh-parsing-01

Abstract

   IPv6 is widely used on the internet today and is expected to be
   deployed more as more devices (i.e. home automation) get inter-
   connected.  The IPv6 header format allows for the use of Extension
   Headers (EH).  EHs could be chained together with very few existing
   guidelines by the IPv6 protocol on how devices should parse them,
   which open room for security concerns and inconsistencies.  This
   document presents guidelines for parsing IPv6 EHs with a goal of
   providing a common and consistent parsing methodology for IPv6
   implementers among the industry.

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 February 6, 2015.

Copyright Notice

   Copyright (c) 2014 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



Kampanakis              Expires February 6, 2015                [Page 1]


Internet-Draft         IPv6 EH parsing guidelines            August 2014


   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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Parsing EH chains . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Parsing malformed EHs . . . . . . . . . . . . . . . . . . . . . 5
   5.  Other guidelines  . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   9.  Normative References  . . . . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8

































Kampanakis              Expires February 6, 2015                [Page 2]


Internet-Draft         IPv6 EH parsing guidelines            August 2014


1.  Introduction

   As defined in [RFC2460], the IPv6 protocol was designed to have a
   constant header length and allows for the use of IPv6 Extension
   Headers (EH) which could be used to carry routing or other
   information for intermediary or end-devices.  For example,
   Destination Option (DestOpt) EH are used by Mobile IPv6 end-hosts and
   Hop-by-Hop (HbH) EHs are used by intermediate routing devices.
   Multiple EHs can also be stacked together in an IPv6 header.

   Because of the various possible combinations of EHs in an IPv6
   packet, it is not clear to implementers how headers should be
   evaluated and parsed by intermediary and end-devices.  [RFC2460]
   describes some IPv6 EH recommendations of the order and allowed
   occurrences of headers, but it does not provide other guidance on how
   EHs should be parsed.  Experience has shown that, based on the
   receiving device vendor and operating system (OS), there can be
   inconsistencies in he receiver's behaviour when EHs are chained
   together in an IPv6 packet.  This document presents how EHs in an
   IPv6 packet should by parsed in order to provide a consistent
   standard behaviour for IPv6 enabled intermediary (i.e. routers) or
   end-devices.


2.  Terminology

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


3.  Parsing EH chains

   [RFC2460] defined various IPv6 EHs and other documents defined new
   EHs for various applications.  Even though it includes some
   guidelines, [RFC2460] does not provide strong recommendations on the
   exact restrictions and order of EH headers present in an IPv6 Header.
   Thus, it is can be challenging for vendors of intermediate or end-
   devices to consistently parse and distinguish between which EH chains
   in an IPv6 Header are legitimate or not.

   Since [RFC2460] does not limit the maximum EH chain size, [RFC7112]
   presents the implications of oversized IPv6 Header chains and how
   these should be fragmented and parsed by intermediate devices and
   hosts.  Also, it defines the maximum allowed size of a EH chain.

   Guideline 1: intermediate devices that process IPv6 header chains in
   order to enforce policies SHOULD be able to parse the IPv6 Header at



Kampanakis              Expires February 6, 2015                [Page 3]


Internet-Draft         IPv6 EH parsing guidelines            August 2014


   least up to the maximum header processing length supported by the
   device hardware acceleration in order to enforce policies or packet
   legitimacy.  When intermediate devices are configured to match
   certain EHs, the EH SHOULD be matched regardless of its position in
   the EH chain unless the header is malformed and dropped according to
   guidelines in this document.  If multiple EHs of the same type exist
   in the EH chain, all SHOULD be parsed by the intermediate device
   until matched in order to enforce the matching policy.  When an EH
   chain exceeds the hardware acceleration processing limit the packets
   MAY be software processed in order to enforce policies.  To protect
   against Denial of Service Denial of Service (DoS), intermediate
   devices MAY provide rate-limiting mechanisms that limit resources
   consumed by software processed packets.  Intermediate devices that
   are not enforcing policies based by matching IPv6 EHs, might not
   parse EH chains other than HbH when present ([RFC7045]).

   Guideline 2: From Section 5 of [RFC7112], when parsing an EH chain,

   o  a host MUST drop non-initial fragments that include parts of an
      IPv6 EH chain and initial fragments whose last EH Next Header
      field is not an Upper Layer (UL) protocol (i.e.  TCP) or the No
      Next Header.  The host SHOULD send an ICMPv6 error message when
      dropping the fragment.

   o  an intermediate device that processes IPv6 header chains in order
      to enforce policies MAY drop (if not configured to allow) non-
      initial fragments that include parts of an IPv6 EH chain or an
      initial fragment whose last EH Next Header field is not an Upper
      Layer (UL) protocol (i.e.  TCP) or the No Next Header.

   Section 4 of [RFC2460] defines that the HbH EH can only occur once in
   an IPv6 Header chain and has to be be the first header.

   Guideline 3: Thus, when parsing an EH chain,

   o  an end-host MUST discard packets that have an HbH EH that is not
      first in the chain.

   o  an intermediate device that processes IPv6 header chains in order
      to enforce policies MUST discard packets that have an HbH EH that
      is not first in the chain (Section 2.2 of [RFC7045]).  If the
      device is not parsing the EH chain, it might not discard the
      packets.

   Guideline 4: According to Section 4.1 of [RFC2460], when an end-host
   or an intermediate system that does not inspect IPv6 header chains in
   order to enforce policies processes an IPv6 packet with multiple
   DestOpt EHs,



Kampanakis              Expires February 6, 2015                [Page 4]


Internet-Draft         IPv6 EH parsing guidelines            August 2014


   o  if there is no RH EH in the packet, then the final destination
      host alone SHOULD process all the DestOpt EHs in the packet.

   o  if there is a RH in the packet

      *  if the node is the final destination, then it SHOULD process
         all the DestOpt EHs in the packet.

      *  if the node is one of the destinations in the RH, it SHOULD
         only process the DestOpt EHs in the chain that are before the
         RH EH.

   In general, intermediate devices that process IPv6 header chains in
   order to enforce policies should follow Section 2 of [RFC7045] in
   order to transmit IPv6 packets with EHs.

   Note about EH order: [RFC2460] mentions

      Each extension header should occur at most once, except for the
      Destination Options header which should occur at most twice (once
      before a Routing header and once before the upper-layer header).

   But, later it says

     IPv6 nodes must accept and attempt to process extension headers in
     any order and occurring any number of times in the same packet,
     except for the Hop-by-Hop Options header which is restricted to
     appear immediately after an IPv6 header only.  Nonetheless, it is
     strongly advised that sources of IPv6 packets adhere to the above
     recommended order until and unless subsequent specifications revise
     that recommendation.

   Thus, there is no other specific EH order end-hosts or intermediate
   devices can enforce following current specifications.


4.  Parsing malformed EHs

   IPv6 EHs that are malformed MUST be efficiently dropped.  Malformed
   EHs could contain incorrect Hdr Ext Len or Opt Data Len fields.

   Guideline 5: When parsing an EH chain, a host or an intermediate
   device that processes IPv6 header chains in order to enforce policies
   MUST discard packets that contain EHs with inaccurate Hdr Ext Len. To
   ensure that, while parsing the chain, each EH Hdr Ext Len SHOULD be
   used to determine the next EH in the chain.  If the data of the last
   EH or the UL Header plus its data does not align with the original
   IPv6 Header Payload Length the packet MUST be dropped unless another



Kampanakis              Expires February 6, 2015                [Page 5]


Internet-Draft         IPv6 EH parsing guidelines            August 2014


   policy step already discarded it.

   Especially for DestOpt and HbH EHs, they can carry a variable number
   of type-length-value (TLV) encoded Options.  Each option contains an
   Opt Data Len field for the data length in the option.  Malformed
   packets with Options that contain inaccurate length MUST be dropped
   by hosts and intermediate devices that are parsing these Options
   unless another policy step discarded the packet.

   Guideline 6: When parsing EH Options, the Opt Data Len field points
   to the end of the Option parsed.  If the Opt Data Len of the last
   Option in the EH does not align with the Hdr Ext Len of the EH that
   contains the Option, the packet MUST be discarded.  The guidelines
   for actions based on the Option Type value described in Section 4.2
   of [RFC2460] MUST still be followed.  A host or intermediate device
   that is not parsing the Option ([RFC7112]) SHOULD NOT discard the
   packet.

   The following algorithm shows how an end-host or intermediary device
   that enforces policies (ACLs, stateful inspection and firewalling) by
   matching on IPv6 EHs could be implementing Guideline 6 and 7:

      while (IPv6 EH chain not parsed) {
          [TODO: write pseudocode]
      }


5.  Other guidelines

   Guideline 7: Unknown EHs Since IPv6 Extension Headers and upper-layer
   protocols share the same namespace (the "Assigned Internet Protocol
   Numbers" registry/namespace), it is impossible to tell whether an
   unrecognized Next Header value refers to an IPv6 Extension Header to
   to an unrecognized upper-layer protocol, [RFC6564] not withstanding.
   Thus, when parsing an IPv6 header chain:

   o  As defined in Section 4 of [RFC2460], end-hosts should discard
      packets with unknown EH types and send an ICMP Parameter Problem
      message to the source of the packet, with an ICMP Code value of 1
      ("unrecognized Next Header type encountered") and the ICMP Pointer
      field containing the offset of the unrecognized value within the
      original packet.

   o  Intermediate devices that process IPv6 header chains in order to
      enforce policies MUST NOT attempt to continue parsing an IPv6
      header chain after encountering an unrecognized Next Header value.
      Per Section 2.1 of [RFC7045]) such systems MUST be configurable to
      allow such packets, but the default configuration MAY drop such



Kampanakis              Expires February 6, 2015                [Page 6]


Internet-Draft         IPv6 EH parsing guidelines            August 2014


      packets.

   Guideline 8: End-hosts or intermediate systems that do not process
   IPv6 header chains in order to enforce policies MUST process an RH in
   an IPv6 packet only when the node's address is the same as the
   packet's IPv6 Destination Address (Section 4.4 of [RFC2460]).

   Guideline 9: Unknown RH

   o  End-hosts that receive packets with a RH with an unrecognised
      Routing Type value MUST ignore the RH if Segments Left is zero.
      If Segments Left is non-zero, the host MUST drop the packet and
      send an ICMP Parameter Problem (Section 4.4 of [RFC2460]).

   o  Intermediate devices that process IPv6 header chains in order to
      enforce policies SHOULD forward (unless configured to drop)
      standardised and undeprecated RH (Section 2.1 of [RFC7045]).

   Guideline 10: Intermediate or end-devices performing re-assembly MUST
   silently discard overlapping IPv6 fragments (Section 4 of [RFC5722]).
   More info on errors and the corresponding messages to be generated by
   a host or intermediate device performing re-assembly can be found in
   Section 4.5 of [RFC2460].

   Guideline 11: As defined in [RFC6946], "atomic" IPv6 fragments SHOULD
   be "re-assembled" from the contents of that sole fragment.  End-hosts
   and intermediary devices performing re-assembly SHOULD conform to
   [RFC6946].


6.  Security Considerations

   No new security exposures or issues are raised by this document.
   This document describes how IPv6 EHs should be parsed by intermediate
   and end-devices in a consistent manner.  Guidelines presented in this
   document also leverage recommendations described in [RFC2460],
   [RFC6946], [RFC5722], [RFC7112] and [RFC7045].

   Implementers following a common document for parsing and matching
   IPv6 EHs can ensure that no network policies are bypassed due to
   inconsistent processing of IPv6 EHs.


7.  Updates

   version -00: Initial submission.

   version -01 updates:



Kampanakis              Expires February 6, 2015                [Page 7]


Internet-Draft         IPv6 EH parsing guidelines            August 2014


   (1)  Addressed comment about MAY NOT being ambiguous language.

   (2)  Addressed Mike's comment about wording in various sections and
        guilines 4, 7 and 8.


8.  Acknowledgements


9.  Normative References

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

   [RFC5722]  Krishnan, S., "Handling of Overlapping IPv6 Fragments",
              RFC 5722, December 2009.

   [RFC6564]  Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
              M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
              RFC 6564, April 2012.

   [RFC6946]  Gont, F., "Processing of IPv6 "Atomic" Fragments",
              RFC 6946, May 2013.

   [RFC7045]  Carpenter, B. and S. Jiang, "Transmission and Processing
              of IPv6 Extension Headers", RFC 7045, December 2013.

   [RFC7112]  Gont, F., Manral, V., and R. Bonica, "Implications of
              Oversized IPv6 Header Chains", RFC 7112, January 2014.


Author's Address

   Panos Kampanakis
   Cisco Systems
   170 West Tasman Dr.
   San Jose, CA  95134
   US

   Email: pkampana@cisco.com








Kampanakis              Expires February 6, 2015                [Page 8]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/