Recommendations on filtering of IPv6 packets containing IPv6 Extension Headers
draft-gont-opsec-ipv6-eh-filtering-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2014-07-04
Replaced by draft-ietf-opsec-ipv6-eh-filtering
Stream (None)
Intended RFC status (None)
Formats pdf htmlized (tools) 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)
opsec                                                            F. Gont
Internet-Draft                                    UTN-FRH / SI6 Networks
Intended status: Best Current Practice                            W. Liu
Expires: January 5, 2015                             Huawei Technologies
                                                               R. Bonica
                                                        Juniper Networks
                                                            July 4, 2014

 Recommendations on filtering of IPv6 packets containing IPv6 Extension
                                Headers
               draft-gont-opsec-ipv6-eh-filtering-00.txt

Abstract

   This document document provides advice on the filtering of IPv6
   packets based on the IPv6 Extension Headers and the IPv6 options they
   contain.  Additionally, it discusses the operational and
   interoperability implications of dropping packets based on the IPv6
   Extension Headers and IPv6 options they contain.

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 5, 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

Gont, et al.             Expires January 5, 2015                [Page 1]
Internet-Draft     Filtering of IPv6 packets with EHs          July 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology and Conventions Used in This Document . . . .   3
   2.  IPv6 Extension Headers  . . . . . . . . . . . . . . . . . . .   3
     2.1.  General Discussion  . . . . . . . . . . . . . . . . . . .   3
     2.2.  General Security Implications . . . . . . . . . . . . . .   3
     2.3.  Advice on the Handling of IPv6 Packets with Specific IPv6
           Extension Headers . . . . . . . . . . . . . . . . . . . .   3
   3.  IPv6 Options  . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.1.  General Discussion  . . . . . . . . . . . . . . . . . . .  10
     3.2.  General Security Implications of IPv6 Options . . . . . .  10
     3.3.  Advice on the Handling of Packets with Specific IPv6
           Options . . . . . . . . . . . . . . . . . . . . . . . . .  11
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  22
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  22
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

1.  Introduction

   This document document discusses the filtering of IPv6 packets based
   on the IPv6 Extension Headers and the IPv6 options they contain.
   Since various protocols may use IPv6 Extension Headers (possibly with
   IPv6 options), dropping packets based on the the IPv6 Extension
   Headers or IPv6 options they contain may have implications on the
   proper functioning of such protocols.  Thus, this document attempts
   to discuss the operational and interoperability implications of such
   dropping, and provide advice in this area.  Additionally, it outlines
   what an administrator should do in a typical enterprise environments.
   This document is similar in nature to [RFC7123], which addresses the
   same problem for the IPv4 case.

   Section 2 of this document discusses IPv6 extension headers and IPv6
   options, and provides advice in the area of filtering IPv6 packets
   that contain such IPv6 Extension Headers and/or options.

Gont, et al.             Expires January 5, 2015                [Page 2]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

1.1.  Terminology and Conventions Used in This Document

   The terms "fast path", "slow path", and associated relative terms
   ("faster path" and "slower path") are loosely defined as in Section 2
   of [RFC6398].

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

2.  IPv6 Extension Headers

2.1.  General Discussion

   IPv6 Extension Headers allow for the extension of the IPv6 [RFC2460]
   protocol.  Since both IPv6 Extension Headers and upper-layer
   protocols share the same namespace ("Next Header" registry/
   namespace), [RFC7045] identifies which of the currently assigned
   Internet Protocol numbers identify IPv6 Extension Headers vs. upper-
   layer protocols.  This document discusses the filtering of packets
   based on the IPv6 Extension Headers (as specified by [RFC7045]) they
   contain. .

      NOTE: [RFC7112] specifies that non-fragmented IPv6 datagrams and
      Pv6 First-Fragments, must contain the entire IPv6 header chain
      [RFC7112].  Therefore, intermediate systems can always enforce the
      filtering policies discussed in this document, or resort to simply
      dropping the offending packets when they fail to comply with the
      requirements in [RFC7112].

2.2.  General Security Implications

   Depending on the specific device architecture, IPv6 packets that
   contain IPv6 Extension Headers may require processing by the device's
   general-purpose CPU, and hence can be leveraged for the purpose of
   Denial of Service (DoS) attacks [Cisco-EH] [FW-Benchmark].

   Operators are urged to consider IPv6 Extension Header filtering and
   IPv6 options handling capabilities of different devices as they make
   deployment decisions in future.

2.3.  Advice on the Handling of IPv6 Packets with Specific IPv6
      Extension Headers

Gont, et al.             Expires January 5, 2015                [Page 3]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

2.3.1.  IPv6 Hop-by-Hop Option (Number=0)

2.3.1.1.  Uses

   The Hop-by-Hop Options header is used to carry optional information
   that must be examined by every node along a packet's delivery path.
   At the time of this writing, the folloing options have been specified
   for the Hop-by-Hop OPtions extension header:

   o  Router Alert [RFC2711]

   o  Jumbo Payload [RFC2675]

   o  RPL Option [RFC6553]

   o  SMF_DPD [RFC6621]

   o  MPL Option [I-D.ietf-roll-trickle-mcast]

   o  IPv6 DFF Header [RFC6971]

2.3.1.2.  Specification

   This Extension Header is specified in [RFC2460].

2.3.1.3.  Specific Security Implications

   Since this Extension Header must me processed by all intermediate-
   systems en route, it can be leveraged to perform Denial of Service
   attacks against the network infrastructure.

2.3.1.4.  Operational and Interoperability Impact if Blocked

   Dropping of packets containing a Hop-by-Hop Option extension header
   would break RSVP and multicast deployments.  Additionally, it would
   cause IPv6 jumbograms to be dropped.

2.3.1.5.  Advice

   Intermediate systems should, by default, drop packets containing a
   IPv6 Hop-by-Hop Option Extension Header.  For obvious reasons, RPL
   routers must not drop packets based on the presence of an IPv6 Hop-
   by-Hop Option Extension Header.

   Those intermediate systems processing the contents of this extension
   header should drop packets that contain more than one instance of the
   Router Alert option (see [RFC2711].

Gont, et al.             Expires January 5, 2015                [Page 4]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

2.3.2.  Routing Header for IPv6 (Number=43)

2.3.2.1.  Uses

   The Routing header is used by an IPv6 source to list one or more
   intermediate nodes to be "visited" on the way to a packet's
   destination.

2.3.2.2.  Specification

   This Extension Header is specified in [RFC2460].  [RFC2460]
   originally specified the Routing Header Type 0, which has been later
   obsoleted by [RFC5095].

   At the time of this writing, the following Routing Types have been
   specified:

   o  Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095]

   o  Type 1: Nimrod (DEPRECATED 2009-05-06)

   o  Type 2: Type 2 Routing Header [RFC6275]

   o  Type 3: RPL Source Route Header [RFC6554]

   o  Types 4-252: Unassigned

   o  Type 253: RFC3692-style Experiment 1 [RFC4727]

   o  Type 254: RFC3692-style Experiment 2 [RFC4727]

   o  Type 255: Reserved

2.3.2.3.  Specific Security Implications

   The security implications of RHT0 have been discussed in detail in
   [Biondi2007] and [RFC5095].

2.3.2.4.  Operational and Interoperability Impact if Blocked

   Blocking packets containing a RHT0 has no operational implications.

2.3.2.5.  Advice

   Drop packets containing a RHT0.

Gont, et al.             Expires January 5, 2015                [Page 5]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

2.3.3.  Fragment Header for IPv6 (Number=44)

2.3.3.1.  Uses

   This Extension Header provides the fragmentation functionality for
   IPv6.

2.3.3.2.  Specification

   This Extension Header is specified in [RFC2460].

2.3.3.3.  Specific Security Implications

   The security implications of the Fragment Header range from Denial of
   Service attacks (based on blooding a target with IPv6 fragments) to
   information leakage attacks [I-D.ietf-6man-predictable-fragment-id].

2.3.3.4.  Operational and Interoperability Impact if Blocked

   Blocking packets that contain a Fragment Header would break any
   protocols that might rely on fragmentation (e.g., the DNS).

2.3.3.5.  Advice

   Intemmediate systems should, by default, pass packets that contain a
   Fragment Header.

2.3.4.  Encapsulating Security Payload (Number=50)

2.3.4.1.  Uses

   This extension Header is employed for the IPsec suite [RFC4303].

2.3.4.2.  Specification

   This extension header is specified in [RFC4303].

2.3.4.3.  Specific Security Implications

   Besides the general implications of IPv6 Extension Headers, this
   extension header could be employed to potentially perform a DoS
   attack at the destination system by wasting CPU resources in
   validating the contents of the packet.

Gont, et al.             Expires January 5, 2015                [Page 6]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

2.3.4.4.  Operational and Interoperability Impact if Blocked

   Dropping packets that employ this extension header would break IPsec
   deployments.

2.3.4.5.  Advice

   Intemmediate systems should pass packets containing the Encapsulating
   Security Payload extensio header.

2.3.5.  Authentication Header (Number=51)

2.3.5.1.  Uses

   The Authentication Header can be employed for provide authentication
   services in IPv4 and IPv6. .

2.3.5.2.  Specification

   This Extension Header is specified in [RFC4302].

2.3.5.3.  Specific Security Implications

   This header could be employed for performing a CPU-consumption attack
   at the target system.

2.3.5.4.  Operational and Interoperability Impact if Blocked

   Traffic employing the Authentication Header would be dropped.

2.3.5.5.  Advice

   Intermediary systems should not drop packets containing an
   Authentication Header.

2.3.6.  Destination Options for IPv6 (Number=60)

2.3.6.1.  Uses

   The Destination Options header is used to carry optional information
   that need be examined only by a packet's destination node(s).

2.3.6.2.  Specification

   This Extension Header is specified in [RFC2460].  At the time of this
   writing, no options have been specified for this extension header.

Gont, et al.             Expires January 5, 2015                [Page 7]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

2.3.6.3.  Specific Security Implications

   No security implications are known, other than the general
   implications of IPv6 extension headers.

2.3.6.4.  Operational and Interoperability Impact if Blocked

   None.

2.3.6.5.  Advice

   Pass packets that contain the Destination Options Header.

2.3.7.  Mobility Header (Number=135)

2.3.7.1.  Uses

   The Mobility Header is an extension header used by mobile nodes,
   correspondent nodes, and home agents in all messaging related to the
   creation and management of bindings in Mobile IPv6.

2.3.7.2.  Specification

   This Extension Header is specified in [RFC6275].

2.3.7.3.  Specific Security Implications

   TBD.

2.3.7.4.  Operational and Interoperability Impact if Blocked

   Dropping packets containing this extension header would break Mobile
   IPv6.

2.3.7.5.  Advice

   Pass packets containing this extension header.

2.3.8.  Host Identity Protocol (Number=139)

2.3.8.1.  Uses

   This extension header is employed with the Host Identity Protocol
   (HIP), an experimental protocol that allows consenting hosts to
   securely establish and maintain shared IP-layer state, allowing
   separation of the identifier and locator roles of IP addresses,
   thereby enabling continuity of communications across IP address
   changes.

Gont, et al.             Expires January 5, 2015                [Page 8]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

2.3.8.2.  Specification

   This extension Header is specified in [RFC5201].

2.3.8.3.  Specific Security Implications

   TBD.

2.3.8.4.  Operational and Interoperability Impact if Blocked

   Dropping packets that contain the Host Identity Protocol would break
   HIP deployments.

2.3.8.5.  Advice

   Pass packets that contain a Host Identity Protocol extension header.

2.3.9.  Shim6 Protocol (Number=140)

2.3.9.1.  Uses

   This extension header is employed by the Shim6 Protocol.

2.3.9.2.  Specification

   This Extension Header is specified in [RFC5533].

2.3.9.3.  Specific Security Implications

   TBD.

2.3.9.4.  Operational and Interoperability Impact if Blocked

   Dropping packets that contain this extension header would break
   Shim6.

2.3.9.5.  Advice

   Pass packets containing this extension header.

2.3.10.  Use for experimentation and testing (Numbers=253 and 254)

2.3.10.1.  Uses

   .

Gont, et al.             Expires January 5, 2015                [Page 9]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

2.3.10.2.  Specification

   This Extension Header is specified in [RFC3692] and [RFC4727].

2.3.10.3.  Specific Security Implications

   None.

2.3.10.4.  Operational and Interoperability Impact if Blocked

   .

2.3.10.5.  Advice

   Routers, security gateways, and firewalls SHOULD have configuration
   knobs for IP packets that contain this extension header to select
   between "ignore & forward" and "drop & log".  Otherwise, no
   legitimate experiment using these options will be able to traverse
   any IP router.

   The aforementioned configuration knob SHOULD default to "drop & log".

   Special care needs to be taken in the case of "drop & log".  Devices
   SHOULD count the number of packets dropped, but the logging of drop
   events SHOULD be limited so as to not overburden device resources.

3.  IPv6 Options

3.1.  General Discussion

   The following subsections describe specific security implications of
   different IPv6 options, and provide advice regarding filtering
   packets that contain such options.

3.2.  General Security Implications of IPv6 Options

   The general security implications of IPv6 options are closely related
   to those discussed in Section 2.2.  Essentially, packets that contain
   IPv6 options might need to be processed by IPv6 router's general-
   purpose CPU can be a DDoS risk to that router's general-purpose CPU
   (and thus to the router itself).  For some architectures, a possible
   mitigation would be to rate-limit the packets that are to be
   processed by the general-purpose CPU (see e.g.  [Cisco-EH]).

Gont, et al.             Expires January 5, 2015               [Page 10]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

3.3.  Advice on the Handling of Packets with Specific IPv6 Options

   The following subsections contain a description of each of the IPv6
   options that have so far been specified, a discussion of possible
   interoperability implications if packets containing such options are
   dropped, and specific advice on whether to drop packets containing
   these options in a typical enterprise firewall.

3.3.1.  Pad1 (Type=0x00)

3.3.1.1.  Uses

   This option is used when necessary to align subsequent options and to
   pad out the containing header to a multiple of 8 octets in length.

3.3.1.2.  Specification

   This option is specified in [RFC2460].

3.3.1.3.  Specific Security Implications

   None.

3.3.1.4.  Operational and Interoperability Impact if Blocked

   Dropping packets that contain this option would potentially break any
   protocol that relies on IPv6 extension headers.

3.3.1.5.  Advice

   Do not drop packets based on the presence of this option.

3.3.2.  PadN (Type=0x01)

3.3.2.1.  Uses

   This option is used when necessary to align subsequent options and to
   pad out the containing header to a multiple of 8 octets in length.

3.3.2.2.  Specification

   This option is specified in [RFC2460].

3.3.2.3.  Specific Security Implications

   Because of the possible size of this option, it could be leveraged as
   a large-bandwidth covert channel.

Gont, et al.             Expires January 5, 2015               [Page 11]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

3.3.2.4.  Operational and Interoperability Impact if Blocked

   Dropping packets that contain this option would potentially break any
   protocol that relies on IPv6 extension headers.

3.3.2.5.  Advice

   Do not drop packets based on the presence of this option.

3.3.3.  Jumbo Payload (Type=0XC2)

3.3.3.1.  Uses

   The Jumbo payload option provides the means of specifying payloads
   larger than 65535 bytes.

3.3.3.2.  Specification

   This option is specified in [RFC2675].

3.3.3.3.  Specific Security Implications

   TBD.

3.3.3.4.  Operational and Interoperability Impact if Blocked

   Dropping packets based on the presence would this option would cause
   IPv6 jumbograms to be dropped.

3.3.3.5.  Advice

   By default, intermediate systems should drop packets that contain
   this option.  This policy could be overiden in specific environments
   where support for IPv6 jumbograms is desired.

3.3.4.  RPL Option (Type=0x63)

3.3.4.1.  Uses

   The RPL Option provides a mechanism to include routing information
   with each datagram that an RPL router forwards.

3.3.4.2.  Specification

   This option is specified in [RFC6553].

Gont, et al.             Expires January 5, 2015               [Page 12]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

3.3.4.3.  Specific Security Implications

   TBD.

3.3.4.4.  Operational and Interoperability Impact if Blocked

   This options is meant to be employed within an RPL instance.  As a
   result, dropping packets based on the presence of this option at e.g.
   an ISP does will not result in operational implications.

3.3.4.5.  Advice

   Non-RPL routers should drop packets that contain an RPL option.

3.3.5.  Tunnel Encapsulation Limit (Type=0x04)

3.3.5.1.  Uses

   The Tunnel Encapsulation Limit option can be employed to specify how
   many further levels of nesting the packet is permitted to undergo.

3.3.5.2.  Specification

   This option is specified in [RFC2473].

3.3.5.3.  Specific Security Implications

   TBD.

3.3.5.4.  Operational and Interoperability Impact if Blocked

   Filtering packets based on the presence of this option could result
   in tunnel traffic being dropped.

3.3.5.5.  Advice

   Intermediate systems should not drop packets based on the presence of
   this option.

   Since this option is meant to be included in the Destination Options
   Header, an intermediate system should drop packets that employ this
   option in any other extension header type.

3.3.6.  Router Alert (Type=0x05)

Gont, et al.             Expires January 5, 2015               [Page 13]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

3.3.6.1.  Uses

   Router Alert option [RFC2711], which is typically employed for the
   RSVP protocol [RFC2205] and the MLD protocol [RFC2710].

3.3.6.2.  Specification

   This option is specified in [RFC2711].

3.3.6.3.  Specific Security Implications

   Since this option causes the contents of the packet to be inspected
   by the handling device, this option could be leveraged for performing
   DoS attacks.

3.3.6.4.  Operational and Interoperability Impact if Blocked

   Dropping packets that contain this option would break RSVP and
   multicast deployments.

3.3.6.5.  Advice

   Intermediate systems should, by default, drop packets that contain
   this option.

3.3.7.  Quick-Start (Type=0x26)

3.3.7.1.  Uses

   This IP Option is used in the specification of Quick-Start for TCP
   and IP, which is an experimental mechanism that allows transport
   protocols, in cooperation with routers, to determine an allowed
   sending rate at the start and, at times, in the middle of a data
   transfer (e.g., after an idle period) [RFC4782].

3.3.7.2.  Specification

   This option is specified in [RFC4782], on the "Experimental" track.

3.3.7.3.  Specific Security Implications

   Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two
   kinds of attacks:

   o  attacks to increase the routers' processing and state load, and,

Gont, et al.             Expires January 5, 2015               [Page 14]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

   o  attacks with bogus Quick-Start Requests to temporarily tie up
      available Quick-Start bandwidth, preventing routers from approving
      Quick-Start Requests from other connections.

3.3.7.4.  Operational and Interoperability Impact if Blocked

   The Quick-Start functionality would be disabled, and additional
   delays in TCP's connection establishment (for example) could be
   introduced.  (Please see Section 4.7.2 of [RFC4782].)  We note,
   however, that Quick-Start has been proposed as a mechanism that could
   be of use in controlled environments, and not as a mechanism that
   would be intended or appropriate for ubiquitous deployment in the
   global Internet [RFC4782].

3.3.7.5.  Advice

   A given router, security gateway, or firewall system has no way of
   knowing a priori whether this option is valid in its operational
   environment.  Therefore, routers, security gateways, and firewalls
   SHOULD, by default, ignore the Quick-Start option.  Additionally,
   routers, security gateways, and firewalls SHOULD have a configuration
   setting that governs their reaction in the presence of packets
   containing the Quick-Start option.  This configuration setting SHOULD
   allow to honor and process the option, ignore the option, or drop
   packets containing this option.  The default configuration is to
   ignore the Quick-Start option.

      We note that if routers in a given environment do not implement
      and enable the Quick-Start mechanism, only the general security
      implications of IP options (discussed in Section 3.2) would apply.

3.3.8.  CALIPSO (Type=0x07)

3.3.8.1.  Uses

   This option is used for encoding explicit packet Sensitivity Labels
   on IPv6 packets.  It is intended for use only within Multi-Level
   Secure (MLS) networking environments that are both trusted and
   trustworthy.

3.3.8.2.  Specification

   This option is specified in [RFC5570].

Gont, et al.             Expires January 5, 2015               [Page 15]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

3.3.8.3.  Specific Security Implications

   Presence of this option in a packet does not by itself create any
   specific new threat.  Packets with this option ought not normally be
   seen on the global public Internet.

3.3.8.4.  Operational and Interoperability Impact if Blocked

   If packets with this option are blocked or if the option is stripped
   from the packet during transmission from source to destination, then
   the packet itself is likely to be dropped by the receiver because it
   is not properly labeled.  In some cases, the receiver might receive
   the packet but associate an incorrect sensitivity label with the
   received data from the packet whose CALIPSO was stripped by an
   intermediate router or firewall.  Associating an incorrect
   sensitivity label can cause the received information either to be
   handled as more sensitive than it really is ("upgrading") or as less
   sensitive than it really is ("downgrading"), either of which is
   problematic.

3.3.8.5.  Advice

   A given IP router, security gateway, or firewall has no way to know a
   priori what environment it has been deployed into.  Even closed IP
   deployments generally use exactly the same commercial routers,
   security gateways, and firewalls that are used in the public
   Internet.

   Since operational problems result in environments where this option
   is needed if either the option is dropped or IPv6 packets containing
   this option are dropped, but no harm results if the option is carried
   in environments where it is not needed, the default configuration
   SHOULD NOT (a) modify or remove this IPv6 option or (b) drop an IPv6
   packet because the IPv6 packet contains this option.

   A given IPv6 router, security gateway, or firewall MAY be configured
   to drop this option or to drop IP packets containing this option in
   an environment known to not use this option.

   For auditing reasons, routers, security gateways, and firewalls
   SHOULD be capable of logging the numbers of packets containing the
   CALIPSO on a per-interface basis.  Also, routers, security gateways,
   and firewalls SHOULD be capable of dropping packets based on the
   CALIPSO presence as well as the CALIPSO values.

Gont, et al.             Expires January 5, 2015               [Page 16]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

3.3.9.  SMF_DPD (Type=0x08)

3.3.9.1.  Uses

   This option is employed in the (experimental) Simplified Multicast
   Forwarding (SMF) for unique packet identification for IPv6 I-DPD, and
   as a mechanism to guarantee non-collision of hash values for
   different packets when H-DPD is used.  .

3.3.9.2.  Specification

   This option is specified in [RFC6621].

3.3.9.3.  Specific Security Implications

   TBD.

3.3.9.4.  Operational and Interoperability Impact if Blocked

   TBD.

3.3.9.5.  Advice

   TBD.

3.3.10.  Home Address (Type=0xC9)

3.3.10.1.  Uses

   The Home Address option is used by a Mobile IPv6 node while away from
   home, to inform the recipient of the mobile node's home address.

3.3.10.2.  Specification

   This option is specified in [RFC6275].

3.3.10.3.  Specific Security Implications

   TBD.

3.3.10.4.  Operational and Interoperability Impact if Blocked

   TBD.

Gont, et al.             Expires January 5, 2015               [Page 17]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

3.3.10.5.  Advice

   TBD.

3.3.11.  Endpoint Identification (Type=0x8A)

3.3.11.1.  Uses

   The Endpoint Identification option was meant to be used with the
   Nimrod routing architecture [NIMROD-DOC], but has never seen
   widespread deployment.

3.3.11.2.  Specification

   This option is specified in [NIMROD-DOC].

3.3.11.3.  Specific Security Implications

   TBD.

3.3.11.4.  Operational and Interoperability Impact if Blocked

   None.

3.3.11.5.  Advice

   An intermediate system should drop packets that contain this option.

3.3.12.  ILNP Nonce (Type=0x8B)

3.3.12.1.  Uses

   This option is employed by Identifier-Locator Network Protocol for
   IPv6 (ILNPv6) for providing protection against off-path attacks for
   packets when ILNPv6 is in use, and as a signal during initial
   network-layer session creation that ILNPv6 is proposed for use with
   this network-layer session, rather than classic IPv6.

3.3.12.2.  Specification

   This option is specified in [RFC6744].

3.3.12.3.  Specific Security Implications

   TBD.

Gont, et al.             Expires January 5, 2015               [Page 18]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

3.3.12.4.  Operational and Interoperability Impact if Blocked

   TBD.

3.3.12.5.  Advice

   TBD.

3.3.13.  Line-Identification Option (Type=0x8C)

3.3.13.1.  Uses

   This option is used by an Edge Router to identify the subscriber
   premises in scenarios where several subscriber premises may be
   logically connected to the same interface of an Edge Router.

3.3.13.2.  Specification

   This option is specified in [RFC6788].

3.3.13.3.  Specific Security Implications

   TBD.

3.3.13.4.  Operational and Interoperability Impact if Blocked

   Since this options is meant to be employed in Router Solicitation
   messages, dropping packets based on the presence of this option at
   intermediate systems will result in no interoperability implications.

3.3.13.5.  Advice

   Intermediate devices should drop packets that contain this option.

3.3.14.  Deprecated (Type=0x4D)

3.3.14.1.  Uses

   TBD.

3.3.14.2.  Specification

   TB.

Gont, et al.             Expires January 5, 2015               [Page 19]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

3.3.14.3.  Specific Security Implications

   TBD.

3.3.14.4.  Operational and Interoperability Impact if Blocked

   TBD.

3.3.14.5.  Advice

   TBD.

3.3.15.  MPL Option (Type=0x6D)

3.3.15.1.  Uses

   This option is specified in [I-D.ietf-roll-trickle-mcast], and is
   meant to be included only in Hop-by-Hop Option headers..

3.3.15.2.  Specification

   This option is specified in [I-D.ietf-roll-trickle-mcast].

3.3.15.3.  Specific Security Implications

   TBD.

3.3.15.4.  Operational and Interoperability Impact if Blocked

   TBD.

3.3.15.5.  Advice

   TBD.

3.3.16.  IP_DFF (Type=0xEE)

3.3.16.1.  Uses

   This options is employed with the (Experimental) Depth-First
   Forwarding (DFF) in Unreliable Networks.

3.3.16.2.  Specification

   This option is specified in [RFC6971].

Gont, et al.             Expires January 5, 2015               [Page 20]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

3.3.16.3.  Specific Security Implications

   TBD.

3.3.16.4.  Operational and Interoperability Impact if Blocked

   TBD.

3.3.16.5.  Advice

   TBD.

3.3.17.  RFC3692-style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E,
         0xBE, 0xDE, 0xFE)

3.3.17.1.  Uses

   It is only appropriate to use these values in explicitly configured
   experiments; they MUST NOT be shipped as defaults in implementations.

3.3.17.2.  Specification

   Specified in RFC 4727 [RFC4727] in the context of RFC3692-style
   experiments.

3.3.17.3.  Specific Security Implications

   No specific security issues are known for this IPv4 option.

3.3.17.4.  Operational and Interoperability Impact if Blocked

   None.

3.3.17.5.  Advice

   Routers, security gateways, and firewalls SHOULD have configuration
   knobs for IPv6 packets that contain RFC3692-style Experiment options
   to select between "ignore & forward" and "drop & log".  Otherwise, no
   legitimate experiment using these options will be able to traverse
   any IP router.

   Special care needs to be taken in the case of "drop & log".  Devices
   SHOULD count the number of packets dropped, but the logging of drop
   events SHOULD be limited so as to not overburden device resources.

   The aforementioned configuration knob SHOULD default to "drop & log".

Gont, et al.             Expires January 5, 2015               [Page 21]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

4.  IANA Considerations

   This document has no actions for IANA.

5.  Security Considerations

   This document provides advice on the filtering of IPv6 packets that
   contain IPv6 Extension Headers (and possibly IPv6 options).  Dropping
   such packets can help to mitigate the security issues that arise from
   the use of different IPv6 Extension Headers and options.

6.  Acknowledgements

   This document borrows some text an analysis from [RFC7126], authored
   by Fernando Gont, Randall Atkinson, and Carlos Pignataro.

7.  References

7.1.  Normative References

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

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

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

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, December 1998.

   [RFC2675]  Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
              RFC 2675, August 1999.

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710, October
              1999.

   [RFC2711]  Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
              RFC 2711, October 1999.

   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
              Considered Useful", BCP 82, RFC 3692, January 2004.

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

Gont, et al.             Expires January 5, 2015               [Page 22]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

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

   [RFC4304]  Kent, S., "Extended Sequence Number (ESN) Addendum to
              IPsec Domain of Interpretation (DOI) for Internet Security
              Association and Key Management Protocol (ISAKMP)", RFC
              4304, December 2005.

   [RFC4727]  Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
              ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.

   [RFC4782]  Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
              Start for TCP and IP", RFC 4782, January 2007.

   [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
              of Type 0 Routing Headers in IPv6", RFC 5095, December
              2007.

   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
              "Host Identity Protocol", RFC 5201, April 2008.

   [RFC5533]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", RFC 5533, June 2009.

   [RFC5570]  StJohns, M., Atkinson, R., and G. Thomas, "Common
              Architecture Label IPv6 Security Option (CALIPSO)", RFC
              5570, July 2009.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

   [RFC6398]  Le Faucheur, F., "IP Router Alert Considerations and
              Usage", BCP 168, RFC 6398, October 2011.

   [RFC6553]  Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
              Power and Lossy Networks (RPL) Option for Carrying RPL
              Information in Data-Plane Datagrams", RFC 6553, March
              2012.

   [RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
              Routing Header for Source Routes with the Routing Protocol
              for Low-Power and Lossy Networks (RPL)", RFC 6554, March
              2012.

   [RFC6621]  Macker, J., "Simplified Multicast Forwarding", RFC 6621,
              May 2012.

Gont, et al.             Expires January 5, 2015               [Page 23]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

   [RFC6744]  Atkinson,, RJ., "IPv6 Nonce Destination Option for the
              Identifier-Locator Network Protocol for IPv6 (ILNPv6)",
              RFC 6744, November 2012.

   [RFC6788]  Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E.
              Nordmark, "The Line-Identification Option", RFC 6788,
              November 2012.

   [RFC6971]  Herberg, U., Cardenas, A., Iwao, T., Dow, M., and S.
              Cespedes, "Depth-First Forwarding (DFF) in Unreliable
              Networks", RFC 6971, June 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.

   [RFC7123]  Gont, F. and W. Liu, "Security Implications of IPv6 on
              IPv4 Networks", RFC 7123, February 2014.

7.2.  Informative References

   [Biondi2007]
              Biondi, P. and A. Ebalard, "IPv6 Routing Header Security",
              CanSecWest 2007 Security Conference, 2007,
              <http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>.

   [Cisco-EH]
              Cisco Systems, , "IPv6 Extension Headers Review and
              Considerations", Whitepaper. October 2006,
              <http://www.cisco.com/en/US/technologies/tk648/tk872/
              technologies_white_paper0900aecd8054d37d.pdf>.

   [FW-Benchmark]
              Zack, E., "Firewall Security Assessment and Benchmarking
              IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1,
              Berlin, Germany. June 30, 2013,
              <http://www.ipv6hackers.org/meetings/ipv6-hackers-1/zack-
              ipv6hackers1-firewall-security-assessment-and-
              benchmarking.pdf>.

   [I-D.ietf-6man-predictable-fragment-id]
              Gont, F., "Security Implications of Predictable Fragment
              Identification Values", draft-ietf-6man-predictable-
              fragment-id-01 (work in progress), April 2014.

Gont, et al.             Expires January 5, 2015               [Page 24]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

   [I-D.ietf-roll-trickle-mcast]
              Hui, J. and R. Kelsey, "Multicast Protocol for Low power
              and Lossy Networks (MPL)", draft-ietf-roll-trickle-
              mcast-09 (work in progress), April 2014.

   [IANA-IPV6]
              Internet Assigned Numbers Authority, "Internet Protocol
              Version 6 (IPv6) Parameters", December 2013,
              <http://www.iana.org/assignments/ipv6-parameters/
              ipv6-parameters.xhtml>.

   [NIMROD-DOC]
              Nimrod Documentation Page, ,
              "http://ana-3.lcs.mit.edu/~jnc/nimrod/", .

   [RFC7126]  Gont, F., Atkinson, R., and C. Pignataro, "Recommendations
              on Filtering of IPv4 Packets Containing IPv4 Options", BCP
              186, RFC 7126, February 2014.

Authors' Addresses

   Fernando Gont
   UTN-FRH / SI6 Networks
   Evaristo Carriego 2644
   Haedo, Provincia de Buenos Aires  1706
   Argentina

   Phone: +54 11 4650 8472
   Email: fgont@si6networks.com
   URI:   http://www.si6networks.com

   Will Liu
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: liushucheng@huawei.com

Gont, et al.             Expires January 5, 2015               [Page 25]
Internet-Draft     Filtering of IPv6 packets with EHs          July 2014

   Ronald P. Bonica
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, VA  20171
   US

   Phone: 571 250 5819
   Email: rbonica@juniper.net

Gont, et al.             Expires January 5, 2015               [Page 26]