opsec F. Gont Internet-Draft UTN-FRH / SI6 Networks Intended status: Informational W. Liu Expires: January 9, 2017 Huawei Technologies R. Bonica Juniper Networks July 8, 2016 Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers draft-ietf-opsec-ipv6-eh-filtering-01 Abstract It is common operator practice to mitigate security risks by enforcing appropriate packet filtering. This document analyzes both the general security implications of IPv6 Extension Headers and the specific security implications of each Extension Header and Option type, and 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 discarding 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 9, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Gont, et al. Expires January 9, 2017 [Page 1] Internet-Draft Filtering of IPv6 packets with EHs July 2016 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 2. Terminology and Conventions Used in This Document . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 3. IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . 5 3.1. General Discussion . . . . . . . . . . . . . . . . . . . 5 3.2. General Security Implications . . . . . . . . . . . . . . 5 3.3. Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . . 6 3.4. Advice on the Handling of Packets with Unknown IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . . 14 4. IPv6 Options . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. General Discussion . . . . . . . . . . . . . . . . . . . 15 4.2. General Security Implications of IPv6 Options . . . . . . 15 4.3. Advice on the Handling of Packets with Specific IPv6 Options . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4. Advice on the handling of Packets with Unknown IPv6 Options . . . . . . . . . . . . . . . . . . . . . . . . . 26 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . 27 8.2. Informative References . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction Recent studies (see e.g. [RFC7872]) suggest that there is widespread filtering of IPv6 packets that contain IPv6 Extension Headers (EHs). While some operators "officially" filter packets that contain IPv6 EHs, it is possible that some of the measured packet drops be the result of improper configuration defaults, or inappropriate advice in this area. Gont, et al. Expires January 9, 2017 [Page 2] Internet-Draft Filtering of IPv6 packets with EHs July 2016 This document analyzes both the general security implications of IPv6 EHs and the specific security implications of each EH and Option type, and provides advice on the filtering of IPv6 packets based on the IPv6 EHs and the IPv6 options they contain. Since various protocols may use IPv6 EHs (possibly with IPv6 options), discarding packets based on the IPv6 EHs or IPv6 options they contain may have implications on the proper functioning of such protocols. Thus, this document also attempts to discuss the operational and interoperability implications of such filtering policies. This document is similar in nature to [RFC7126], which addresses the same problem for the IPv4 case. However, in IPv6, the problem space is compounded by the fact that IPv6 specifies a number of IPv6 EHs, and a number of IPv6 options which may be valid only when included in specific EH types. This document completes and complements the considerations for protecting the control plane from packets containing IP options that can be found in [RFC6192]. Section 2 of this document specifies the terminology and conventions employed throughout this document. Section 3 of this document discusses IPv6 EHs and provides advice in the area of filtering IPv6 packets that contain such IPv6 EHs. Section 4 of this document discusses IPv6 options and provides advice in the area of filtering IPv6 packets that contain such options. 2. Terminology and Conventions Used in This Document 2.1. Terminology 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 terms "permit" (allow the traffic), "drop" (drop with no notification to sender), and "reject" (drop with appropriate notification to sender) are employed as defined in [RFC3871]. Throughout this document we also employ the term "discard" as a generic term to indicate the act of discarding a packet, irrespective of whether the sender is notified of such drops, and irrespective of whether the specific filtering action is logged. 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]. Gont, et al. Expires January 9, 2017 [Page 3] Internet-Draft Filtering of IPv6 packets with EHs July 2016 2.2. Conventions This document assumes that nodes comply with the requirements in [RFC7045]. Namely (from [RFC7045]), o If a forwarding node discards a packet containing a standard IPv6 EH, it MUST be the result of a configurable policy and not just the result of a failure to recognise such a header. o The discard policy for each standard type of EH MUST be individually configurable. o The default configuration SHOULD allow all standard IPv6 EHs. The advice provided in this document is only meant to guide an operator in configuring forwarding devices, and is *not* to be interpreted as advice regarding default configuration settings for network devices. That is, this document provides advice with respect to operational configurations, but does not change the implementation defaults required by [RFC7045]. We note that the advice provided in this document is *not* meant to be employed by transit routers for transit traffic, since such devices should not enforce this type of filtering policy on traffic not directed to them. We recommend that configuration options are made available to govern the processing of each IPv6 EH type and each IPv6 option type. Such configuration options may include the following possible settings: o Permit this IPv6 EH or IPv6 Option type o Discard (and log) packets containing this IPv6 EH or option type o Reject (and log) packets containing this IPv6 EH or option type (where the packet drop is signaled with an ICMPv6 error message) o Rate-limit traffic containing this IPv6 EH or option type o Ignore this IPv6 EH or option type (as if it was not present) and forward the packet. We note that if a packet carries forwarding information (e.g., in an IPv6 Routing Header) this might be an inappropriate or undesirable action. We note that special care needs to be taken when devices log packet drops/rejects. Devices should count the number of packets dropped/ rejected, but the logging of drop/reject events should be limited so as to not overburden device resources. Gont, et al. Expires January 9, 2017 [Page 4] Internet-Draft Filtering of IPv6 packets with EHs July 2016 Finally, we note that when discarding packets, it is generally desirable that the sender be signaled of the packet drop, since this is of use for trouble-shooting purposes. However, throughout this document (when recommending that packets be discarded) we generically refer to the action as "discard" without specifying whether the sender is signaled of the packet drop. 3. IPv6 Extension Headers 3.1. General Discussion IPv6 [RFC2460] EHs allow for the extension of the IPv6 protocol. Since both IPv6 EHs and upper-layer protocols share the same namespace ("Next Header" registry/namespace), [RFC7045] identifies which of the currently assigned Internet Protocol numbers identify IPv6 EHs vs. upper-layer protocols. This document discusses the filtering of packets based on the IPv6 EHs (as specified by [RFC7045]) they contain. NOTE: [RFC7112] specifies that non-fragmented IPv6 datagrams and IPv6 First-Fragments MUST contain the entire IPv6 header chain [RFC7112]. Therefore, intermediate systems can enforce the filtering policies discussed in this document, or resort to simply discarding the offending packets when they fail to comply with the requirements in [RFC7112]. We note that, in order to implement filtering rules on the fast path, it may be necessary for the filtering device to limit the depth into the packet that can be inspected before giving up. In circumstances where there is such a limitation, it is recommended that implementations discard packets if, when trying to determine whether to discard or permit a packet, the aforementioned limit is encountered. 3.2. General Security Implications Depending on the specific device architecture, IPv6 packets that contain IPv6 EHs may cause the corresponding packets to be processed on the slow path, and hence may be leveraged for the purpose of Denial of Service (DoS) attacks [I-D.gont-v6ops-ipv6-ehs-packet-drops] [Cisco-EH] [FW-Benchmark]. Operators are urged to consider IPv6 EH filtering and IPv6 options handling capabilities of different devices as they make deployment decisions in future. Gont, et al. Expires January 9, 2017 [Page 5] Internet-Draft Filtering of IPv6 packets with EHs July 2016 3.3. Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers 3.3.1. IPv6 Hop-by-Hop Options (Protocol Number=0) 3.3.1.1. Uses The Hop-by-Hop Options header is used to carry optional information that should be examined by every node along a packet's delivery path. 3.3.1.2. Specification This EH is specified in [RFC2460], and its processing rules have been updated by [RFC7045]. At the time of this writing, the following options have been specified for the Hop-by-Hop Options EH: o Type 0x00: Pad1 [RFC2460] o Type 0x01: PadN [RFC2460] o Type 0x05: Router Alert [RFC2711] o Type 0x07: CALIPSO [RFC5570] o Type 0x08: SMF_DPD [RFC6621] o Type 0x26: Quick-Start [RFC4782] o Type 0x4D: (Deprecated) o Type 0x63: RPL Option [RFC6553] o Type 0x6D: MPL Option [RFC7731] o Type 0x8A: Endpoint Identification (Deprecated) [draft-ietf-nimrod-eid] o Type 0xC2: Jumbo Payload [RFC2675] o Type 0xEE: IPv6 DFF Header [RFC6971] o Type 0x1E: RFC3692-style Experiment [RFC4727] o Type 0x3E: RFC3692-style Experiment [RFC4727] o Type 0x5E: RFC3692-style Experiment [RFC4727] o Type 0x7E: RFC3692-style Experiment [RFC4727] Gont, et al. Expires January 9, 2017 [Page 6] Internet-Draft Filtering of IPv6 packets with EHs July 2016 o Type 0x9E: RFC3692-style Experiment [RFC4727] o Type 0xBE: RFC3692-style Experiment [RFC4727] o Type 0xDE: RFC3692-style Experiment [RFC4727] o Type 0xFE: RFC3692-style Experiment [RFC4727] 3.3.1.3. Specific Security Implications Since this EH is required to be processed by all intermediate-systems en route, it can be leveraged to perform Denial of Service attacks against the network infrastructure. NOTE: Ongoing work essentially aims at requiring the Hop-by-Hop Option EH to be processed only in cases where the intermmediate node is making use of any functionality provided by such header (see [I-D.ietf-6man-hbh-header-handling]). However, the deployed base is likely to reflect the traditional behavior for a while, and hence the potential security problems of this EH are still of concern. 3.3.1.4. Operational and Interoperability Impact if Blocked Discarding packets containing a Hop-by-Hop Options EH would break any of the protocols that rely on it for proper functioning. For example, it would break RSVP [RFC2205] and multicast deployments, and would cause IPv6 jumbograms to be discarded. 3.3.1.5. Advice The recommended configuration for the processing of these packets depends on the features and capabilities of the underlying platform. On platforms that allow forwarding of packets with HBH Options on the fast path, we recommend that packets with a HBH Options EH be forwarded as normal (for instance, [RFC7045] allows for implementations to ignore the HBH Options EH when forwarding packets). Otherwise, on platforms in which processing of packets with a IPv6 HBH Options EH is carried out in the slow path, and an option is provided to rate-limit these packets, we recommend that this option be selected. Finally, when packets containing a HBH Options EH are processed in the slow-path, and the underlying platform does not have any mitigation options available for attacks based on these packets, we recommend that such platforms discard packets containing IPv6 HBH Options EHs. Finally, we note that, for obvious reasons, RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] routers must not discard packets based on the presence of an IPv6 Hop-by-Hop Options EH. Gont, et al. Expires January 9, 2017 [Page 7] Internet-Draft Filtering of IPv6 packets with EHs July 2016 3.3.2. Routing Header for IPv6 (Protocol Number=43) 3.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. 3.3.2.2. Specification This EH 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) 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 3.3.2.3. Specific Security Implications The security implications of RHT0 have been discussed in detail in [Biondi2007] and [RFC5095]. 3.3.2.4. Operational and Interoperability Impact if Blocked Blocking packets containing a RHT0 or RTH1 has no operational implications. However, blocking packets employing other routing header types will break the protocols that rely on them. Gont, et al. Expires January 9, 2017 [Page 8] Internet-Draft Filtering of IPv6 packets with EHs July 2016 3.3.2.5. Advice Intermediate systems should discard packets containing a RHT0 or RHT1. RHT2 and RHT3 should be permitted, as required by [RFC7045]. Other routing header types should be discarded. 3.3.3. Fragment Header for IPv6 (Protocol Number=44) 3.3.3.1. Uses This EH provides the fragmentation functionality for IPv6. 3.3.3.2. Specification This EH is specified in [RFC2460]. 3.3.3.3. Specific Security Implications The security implications of the Fragment Header range from Denial of Service attacks (e.g. based on flooding a target with IPv6 fragments) to information leakage attacks [RFC7739]. 3.3.3.4. Operational and Interoperability Impact if Blocked Blocking packets that contain a Fragment Header will break any protocol that may rely on fragmentation (e.g., the DNS [RFC1034]). 3.3.3.5. Advice Intermediate systems should permit packets that contain a Fragment Header. 3.3.4. Encapsulating Security Payload (Protocol Number=50) 3.3.4.1. Uses This EH is employed for the IPsec suite [RFC4303]. 3.3.4.2. Specification This EH is specified in [RFC4303]. 3.3.4.3. Specific Security Implications Besides the general implications of IPv6 EHs, this EH 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 9, 2017 [Page 9] Internet-Draft Filtering of IPv6 packets with EHs July 2016 3.3.4.4. Operational and Interoperability Impact if Blocked Discarding packets that employ this EH would break IPsec deployments. 3.3.4.5. Advice Intermediate systems should permit packets containing the Encapsulating Security Payload EH. 3.3.5. Authentication Header (Number=51) 3.3.5.1. Uses The Authentication Header can be employed for provide authentication services in IPv4 and IPv6. 3.3.5.2. Specification This EH is specified in [RFC4302]. 3.3.5.3. Specific Security Implications Besides the general implications of IPv6 EHs, this EH could be employed to potentially perform a DoS attack at the destination system by wasting CPU resources in validating the contents of the packet. 3.3.5.4. Operational and Interoperability Impact if Blocked Discarding packets that employ this EH would break IPsec deployments. 3.3.5.5. Advice Intermediate systems should permit packets containing an Authentication Header. 3.3.6. Destination Options for IPv6 (Protocol Number=60) 3.3.6.1. Uses The Destination Options header is used to carry optional information that needs be examined only by a packet's destination node(s). 3.3.6.2. Specification This EH is specified in [RFC2460]. At the time of this writing, the following options have been specified for this EH: Gont, et al. Expires January 9, 2017 [Page 10] Internet-Draft Filtering of IPv6 packets with EHs July 2016 o Type 0x00: Pad1 [RFC2460] o Type 0x01: PadN [RFC2460] o Type 0x04: Tunnel Encapsulation Limit [RFC2473] o Type 0x4D: (Deprecated) o Type 0xC9: Home Address [RFC6275] o Type 0x8A: Endpoint Identification (Deprecated) [draft-ietf-nimrod-eid] o Type 0x8B: ILNP Nonce [RFC6744] o Type 0x8C: Line-Identification Option [RFC6788] o Type 0x1E: RFC3692-style Experiment [RFC4727] o Type 0x3E: RFC3692-style Experiment [RFC4727] o Type 0x5E: RFC3692-style Experiment [RFC4727] o Type 0x7E: RFC3692-style Experiment [RFC4727] o Type 0x9E: RFC3692-style Experiment [RFC4727] o Type 0xBE: RFC3692-style Experiment [RFC4727] o Type 0xDE: RFC3692-style Experiment [RFC4727] o Type 0xFE: RFC3692-style Experiment [RFC4727] 3.3.6.3. Specific Security Implications No security implications are known, other than the general implications of IPv6 EHs. For a discussion of possible security implications of specific options specified for the DO header, please see the Section 4.3. 3.3.6.4. Operational and Interoperability Impact if Blocked Discarding packets that contain a Destination Options header would break protocols that rely on this EH type for conveying information, including protocols such as ILNP [RFC6740] and Mobile IPv6 [RFC6275], and IPv6 tunnels that employ the Tunnel Encapsulation Limit option. Gont, et al. Expires January 9, 2017 [Page 11] Internet-Draft Filtering of IPv6 packets with EHs July 2016 3.3.6.5. Advice Intermediate systems should permit packets that contain a Destination Options Header. 3.3.7. Mobility Header (Number=135) 3.3.7.1. Uses The Mobility Header is an EH used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings in Mobile IPv6. 3.3.7.2. Specification This EH is specified in [RFC6275]. 3.3.7.3. Specific Security Implications A thorough security assessment of the security implications of the Mobility Header and related mechanisms can be found in Section 15 of [RFC6275]. 3.3.7.4. Operational and Interoperability Impact if Blocked Discarding packets containing this EH would break Mobile IPv6. 3.3.7.5. Advice Intermediate systems should permit packets containing this EH. 3.3.8. Host Identity Protocol (Protocol Number=139) 3.3.8.1. Uses This EH 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. 3.3.8.2. Specification This EH is specified in [RFC5201]. Gont, et al. Expires January 9, 2017 [Page 12] Internet-Draft Filtering of IPv6 packets with EHs July 2016 3.3.8.3. Specific Security Implications The security implications of the HIP header are discussed in detail in Section 8 of [RFC6275]. 3.3.8.4. Operational and Interoperability Impact if Blocked Discarding packets that contain the Host Identity Protocol would break HIP deployments. 3.3.8.5. Advice Intermediate systems should permit packets that contain a Host Identity Protocol EH. 3.3.9. Shim6 Protocol (Protocol Number=140) 3.3.9.1. Uses This EH is employed by the Shim6 [RFC5533] Protocol. 3.3.9.2. Specification This EH is specified in [RFC5533]. 3.3.9.3. Specific Security Implications The specific security implications are discussed in detail in Section 16 of [RFC5533]. 3.3.9.4. Operational and Interoperability Impact if Blocked Discarding packets that contain this EH will break Shim6. 3.3.9.5. Advice Intermediate systems should permit packets containing this EH. 3.3.10. Use for experimentation and testing (Protocol Numbers=253 and 254) 3.3.10.1. Uses These IPv6 EHs are employed for performing RFC3692-Style experiments (see [RFC3692] for details). Gont, et al. Expires January 9, 2017 [Page 13] Internet-Draft Filtering of IPv6 packets with EHs July 2016 3.3.10.2. Specification These EHs are specified in [RFC3692] and [RFC4727]. 3.3.10.3. Specific Security Implications The security implications of these EHs will depend on their specific use. 3.3.10.4. Operational and Interoperability Impact if Blocked For obvious reasons, discarding packets that contain these EHs limits the ability to perform legitimate experiments across IPv6 routers. 3.3.10.5. Advice Intermediate systems should discard packets containing these EHs. Only in specific scenarios in which RFC3692-Style experiments are to be performed should these EHs be permitted. 3.4. Advice on the Handling of Packets with Unknown IPv6 Extension Headers We refer to IPv6 EHs that have not been assigned an Internet Protocol Number by IANA (and marked as such) in [IANA-PROTOCOLS] as "unknown IPv6 extension headers" ("unknown IPv6 EHs"). 3.4.1. Uses New IPv6 EHs may be specified as part of future extensions to the IPv6 protocol. Since IPv6 EHs and Upper-layer protocols employ the same namespace, it is impossible to tell whether an unknown "Internet Protocol Number" is being employed for an IPv6 EH or an Upper-Layer protocol. 3.4.2. Specification The processing of unknown IPv6 EHs is specified in [RFC2460] and [RFC7045]. 3.4.3. Specific Security Implications For obvious reasons, it is impossible to determine specific security implications of unknown IPv6 EHs. However, from security standpoint, a device should discard IPv6 extension headers for which the security implications cannot be determined. We note that this policy is allowed by [RFC7045]. Gont, et al. Expires January 9, 2017 [Page 14] Internet-Draft Filtering of IPv6 packets with EHs July 2016 3.4.4. Operational and Interoperability Impact if Blocked As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the deployment of new IPv6 EHs and transport protocols. The corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored such that filtering rules are updated as new IPv6 EHs are standardized. We note that since IPv6 EHs and upper-layer protocols share the same numbering space, discarding unknown IPv6 EHs may result in packets encapsulating unknown upper-layer protocols being discarded. 3.4.5. Advice Intermediate systems should discard packets containing unknown IPv6 EHs. 4. IPv6 Options 4.1. General Discussion The following subsections describe specific security implications of different IPv6 options, and provide advice regarding filtering packets that contain such options. 4.2. General Security Implications of IPv6 Options The general security implications of IPv6 options are closely related to those discussed in Section 3.2 for IPv6 EHs. Essentially, packets that contain IPv6 options might need to be processed by an IPv6 router's general-purpose CPU,and hence could present 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]). 4.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 summary of the security implications of each of such options, a discussion of possible interoperability implications if packets containing such options are discarded, and specific advice regarding whether packets containing these options should be permitted. Gont, et al. Expires January 9, 2017 [Page 15] Internet-Draft Filtering of IPv6 packets with EHs July 2016 4.3.1. Pad1 (Type=0x00) 4.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. 4.3.1.2. Specification This option is specified in [RFC2460]. 4.3.1.3. Specific Security Implications None. 4.3.1.4. Operational and Interoperability Impact if Blocked Discarding packets that contain this option would potentially break any protocol that relies on IPv6 EHs. 4.3.1.5. Advice Intermediate systems should not discard packets based on the presence of this option. 4.3.2. PadN (Type=0x01) 4.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. 4.3.2.2. Specification This option is specified in [RFC2460]. 4.3.2.3. Specific Security Implications Because of the possible size of this option, it could be leveraged as a large-bandwidth covert channel. 4.3.2.4. Operational and Interoperability Impact if Blocked Discarding packets that contain this option would potentially break any protocol that relies on IPv6 EHs. Gont, et al. Expires January 9, 2017 [Page 16] Internet-Draft Filtering of IPv6 packets with EHs July 2016 4.3.2.5. Advice Intermediate systems should not discard IPv6 packets based on the presence of this option. 4.3.3. Jumbo Payload (Type=0XC2) 4.3.3.1. Uses The Jumbo payload option provides the means of specifying payloads larger than 65535 bytes. 4.3.3.2. Specification This option is specified in [RFC2675]. 4.3.3.3. Specific Security Implications There are no specific issues arising from this option, except for improper validity checks of the option and associated packet lengths. 4.3.3.4. Operational and Interoperability Impact if Blocked Discarding packets based on the presence of this option will cause IPv6 jumbograms to be discarded. 4.3.3.5. Advice Intermediate systems should discard packets that contain this option. An operator should permit this option only in specific scenarios in which support for IPv6 jumbograms is desired. 4.3.4. RPL Option (Type=0x63) 4.3.4.1. Uses The RPL Option provides a mechanism to include routing information with each datagram that an RPL router forwards. 4.3.4.2. Specification This option is specified in [RFC6553]. 4.3.4.3. Specific Security Implications Those described in [RFC6553]. Gont, et al. Expires January 9, 2017 [Page 17] Internet-Draft Filtering of IPv6 packets with EHs July 2016 4.3.4.4. Operational and Interoperability Impact if Blocked This option is meant to be employed within an RPL instance. As a result, discarding packets based on the presence of this option (e.g. at an ISP) will not result in interoperability implications. 4.3.4.5. Advice Non-RPL routers should discard packets that contain an RPL option. 4.3.5. Tunnel Encapsulation Limit (Type=0x04) 4.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. 4.3.5.2. Specification This option is specified in [RFC2473]. 4.3.5.3. Specific Security Implications Those described in [RFC2473]. 4.3.5.4. Operational and Interoperability Impact if Blocked Discarding packets based on the presence of this option could result in tunnel traffic being discarded. 4.3.5.5. Advice Intermediate systems should not discard packets based on the presence of this option. 4.3.6. Router Alert (Type=0x05) 4.3.6.1. Uses The Router Alert option [RFC2711] is typically employed for the RSVP protocol [RFC2205] and the MLD protocol [RFC2710]. 4.3.6.2. Specification This option is specified in [RFC2711]. Gont, et al. Expires January 9, 2017 [Page 18] Internet-Draft Filtering of IPv6 packets with EHs July 2016 4.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. 4.3.6.4. Operational and Interoperability Impact if Blocked Discarding packets that contain this option would break RSVP and multicast deployments. 4.3.6.5. Advice Intermediate systems should discard packets that contain this option. Only in specific environments where support for RSVP, multicast routing, or similar protocols is desired, should this option be permitted. 4.3.7. Quick-Start (Type=0x26) 4.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]. 4.3.7.2. Specification This option is specified in [RFC4782], on the "Experimental" track. 4.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, 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. 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 4.2) would apply. Gont, et al. Expires January 9, 2017 [Page 19] Internet-Draft Filtering of IPv6 packets with EHs July 2016 4.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]. 4.3.7.5. Advice Intermediate systems should not discard IPv6 packets based on the presence of this option. 4.3.8. CALIPSO (Type=0x07) 4.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. 4.3.8.2. Specification This option is specified in [RFC5570]. 4.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. 4.3.8.4. Operational and Interoperability Impact if Blocked If packets with this option are discarded or if the option is stripped from the packet during transmission from source to destination, then the packet itself is likely to be discarded 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. Gont, et al. Expires January 9, 2017 [Page 20] Internet-Draft Filtering of IPv6 packets with EHs July 2016 4.3.8.5. Advice Intermediate systems that do not operate in Multi-Level Secure (MLS) networking environments should discard packets that contain this option. 4.3.9. SMF_DPD (Type=0x08) 4.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. 4.3.9.2. Specification This option is specified in [RFC6621]. 4.3.9.3. Specific Security Implications TBD. 4.3.9.4. Operational and Interoperability Impact if Blocked TBD. 4.3.9.5. Advice TBD. 4.3.10. Home Address (Type=0xC9) 4.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. 4.3.10.2. Specification This option is specified in [RFC6275]. 4.3.10.3. Specific Security Implications No (known) additional security implications than those described in [RFC6275]. Gont, et al. Expires January 9, 2017 [Page 21] Internet-Draft Filtering of IPv6 packets with EHs July 2016 4.3.10.4. Operational and Interoperability Impact if Blocked Discarding IPv6 packets based on the presence of this option will break Mobile IPv6. 4.3.10.5. Advice Intermediate systems should not discard IPv6 packets based on the presence of this option. 4.3.11. Endpoint Identification (Type=0x8A) 4.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. 4.3.11.2. Specification This option is specified in [NIMROD-DOC]. 4.3.11.3. Specific Security Implications TBD. 4.3.11.4. Operational and Interoperability Impact if Blocked None. 4.3.11.5. Advice Intermediate systems should discard packets that contain this option. 4.3.12. ILNP Nonce (Type=0x8B) 4.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. Gont, et al. Expires January 9, 2017 [Page 22] Internet-Draft Filtering of IPv6 packets with EHs July 2016 4.3.12.2. Specification This option is specified in [RFC6744]. 4.3.12.3. Specific Security Implications Those described in [RFC6744]. 4.3.12.4. Operational and Interoperability Impact if Blocked Discarding packets that contain this option will break INLPv6 deployments. 4.3.12.5. Advice Intermediate systems should not discard packets based on the presence of this option. 4.3.13. Line-Identification Option (Type=0x8C) 4.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. 4.3.13.2. Specification This option is specified in [RFC6788]. 4.3.13.3. Specific Security Implications Those described in [RFC6788]. 4.3.13.4. Operational and Interoperability Impact if Blocked Since this option is meant to be employed in Router Solicitation messages, discarding packets based on the presence of this option at intermediate systems will result in no interoperability implications. 4.3.13.5. Advice Intermediate devices should discard packets that contain this option. Gont, et al. Expires January 9, 2017 [Page 23] Internet-Draft Filtering of IPv6 packets with EHs July 2016 4.3.14. Deprecated (Type=0x4D) 4.3.14.1. Uses No information has been found about this option type. 4.3.14.2. Specification No information has been found about this option type. 4.3.14.3. Specific Security Implications No information has been found about this option type, and hence it has been impossible to perform the corresponding security assessment. 4.3.14.4. Operational and Interoperability Impact if Blocked Unknown. 4.3.14.5. Advice Intermediate systems should discard packets that contain this option. 4.3.15. MPL Option (Type=0x6D) 4.3.15.1. Uses This option is used with the Multicast Protocol for Low power and Lossy Networks (MPL), that provides IPv6 multicast forwarding in constrained networks. 4.3.15.2. Specification This option is specified in [RFC7731], and is meant to be included only in Hop-by-Hop Option headers. 4.3.15.3. Specific Security Implications Those described in [RFC7731]. 4.3.15.4. Operational and Interoperability Impact if Blocked TBD. Gont, et al. Expires January 9, 2017 [Page 24] Internet-Draft Filtering of IPv6 packets with EHs July 2016 4.3.15.5. Advice TBD. 4.3.16. IP_DFF (Type=0xEE) 4.3.16.1. Uses This option is employed with the (Experimental) Depth-First Forwarding (DFF) in Unreliable Networks. 4.3.16.2. Specification This option is specified in [RFC6971]. 4.3.16.3. Specific Security Implications Those specified in [RFC6971]. 4.3.16.4. Operational and Interoperability Impact if Blocked TBD. 4.3.16.5. Advice TBD. 4.3.17. RFC3692-style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 0xBE, 0xDE, 0xFE) 4.3.17.1. Uses These options can be employed for performing RFC3692-style experiments. It is only appropriate to use these values in explicitly configured experiments; they must not be shipped as defaults in implementations. 4.3.17.2. Specification Specified in RFC 4727 [RFC4727] in the context of RFC3692-style experiments. 4.3.17.3. Specific Security Implications The specific security implications will depend on the specific use of these options. Gont, et al. Expires January 9, 2017 [Page 25] Internet-Draft Filtering of IPv6 packets with EHs July 2016 4.3.17.4. Operational and Interoperability Impact if Blocked For obvious reasons, discarding packets that contain these options limits the ability to perform legitimate experiments across IPv6 routers. 4.3.17.5. Advice Intermediate systems should discard packets that contain these options. Only in specific environments where RFC3692-style experiments are meant to be performed should these options be permitted. 4.4. Advice on the handling of Packets with Unknown IPv6 Options We refer to IPv6 options that have not been assigned an IPv6 option type in the corresponding registry ([IANA-IPV6-PARAM]) as "unknown IPv6 options". 4.4.1. Uses New IPv6 options may be specified as part of future protocol work. 4.4.2. Specification The processing of unknown IPv6 options is specified in [RFC2460]. 4.4.3. Specific Security Implications For obvious reasons, it is impossible to determine specific security implications of unknown IPv6 options. 4.4.4. Operational and Interoperability Impact if Blocked Discarding unknown IPv6 options may slow down the deployment of new IPv6 options. As noted in [draft-gont-6man-ipv6-opt-transmit], the corresponding IANA registry ([IANA-IPV6-PARAM] should be monitored such that IPv6 option filtering rules are updated as new IPv6 options are standardized. 4.4.5. Advice Enterprise intermediate systems that process the contents of IPv6 EHs should discard packets that contain unknown options. Other intermediate systems that process the contents of IPv6 EHs should permit packets that contain unknown options. Gont, et al. Expires January 9, 2017 [Page 26] Internet-Draft Filtering of IPv6 packets with EHs July 2016 5. IANA Considerations This document has no actions for IANA. 6. Security Considerations This document provides advice on the filtering of IPv6 packets that contain IPv6 EHs (and possibly IPv6 options). Discarding such packets can help to mitigate the security issues that arise from the use of different IPv6 EHs and options. 7. Acknowledgements The authors of this document would like to thank (in alphabetical order) Mikael Abrahamsson, Brian Carpenter, Mike Heard, Jen Linkova, Carlos Pignataro, Donald Smith, and Gunter Van De Velde, for providing valuable comments on earlier versions of this document. This document borrows some text an analysis from [RFC7126], authored by Fernando Gont, Randall Atkinson, and Carlos Pignataro. 8. References 8.1. Normative References [draft-gont-6man-ipv6-opt-transmit] Gont, F., Liu, W., and R. Bonica, "Transmission and Processing of IPv6 Options", IETF Internet Draft, work in progress, August 2014. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . Gont, et al. Expires January 9, 2017 [Page 27] Internet-Draft Filtering of IPv6 packets with EHs July 2016 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, . [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, DOI 10.17487/RFC2675, August 1999, . [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999, . [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, DOI 10.17487/RFC2711, October 1999, . [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, 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, DOI 10.17487/RFC4304, December 2005, . [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, DOI 10.17487/RFC4727, November 2006, . [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, January 2007, . Gont, et al. Expires January 9, 2017 [Page 28] Internet-Draft Filtering of IPv6 packets with EHs July 2016 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007, . [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, DOI 10.17487/RFC5201, April 2008, . [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, June 2009, . [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, DOI 10.17487/RFC5570, July 2009, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 2011, . [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . [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, DOI 10.17487/RFC6553, 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, DOI 10.17487/RFC6554, March 2012, . Gont, et al. Expires January 9, 2017 [Page 29] Internet-Draft Filtering of IPv6 packets with EHs July 2016 [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", RFC 6621, DOI 10.17487/RFC6621, May 2012, . [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, DOI 10.17487/RFC6740, November 2012, . [RFC6744] Atkinson, RJ. and SN. Bhatti, "IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)", RFC 6744, DOI 10.17487/RFC6744, November 2012, . [RFC6788] Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E. Nordmark, "The Line-Identification Option", RFC 6788, DOI 10.17487/RFC6788, November 2012, . [RFC6971] Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S. Cespedes, "Depth-First Forwarding (DFF) in Unreliable Networks", RFC 6971, DOI 10.17487/RFC6971, June 2013, . [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, December 2013, . [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains", RFC 7112, DOI 10.17487/RFC7112, January 2014, . [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, February 2016, . 8.2. Informative References [Biondi2007] Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", CanSecWest 2007 Security Conference, 2007, . Gont, et al. Expires January 9, 2017 [Page 30] Internet-Draft Filtering of IPv6 packets with EHs July 2016 [Cisco-EH] Cisco Systems, , "IPv6 Extension Headers Review and Considerations", Whitepaper. October 2006, . [draft-ietf-nimrod-eid] Lynn, C., "Endpoint Identifier Destination Option", IETF Internet Draft, draft-ietf-nimrod-eid-00.txt, November 1995. [FW-Benchmark] Zack, E., "Firewall Security Assessment and Benchmarking IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1, Berlin, Germany. June 30, 2013, . [I-D.gont-v6ops-ipv6-ehs-packet-drops] Gont, F., Hilliard, N., Doering, G., (Will), S., and W. Kumari, "Operational Implications of IPv6 Packets with Extension Headers", draft-gont-v6ops-ipv6-ehs-packet- drops-03 (work in progress), March 2016. [I-D.ietf-6man-hbh-header-handling] Baker, F. and R. Bonica, "IPv6 Hop-by-Hop Options Extension Header", draft-ietf-6man-hbh-header-handling-03 (work in progress), March 2016. [IANA-IPV6-PARAM] Internet Assigned Numbers Authority, "Internet Protocol Version 6 (IPv6) Parameters", December 2013, . [IANA-PROTOCOLS] Internet Assigned Numbers Authority, "Protocol Numbers", 2014, . [NIMROD-DOC] Nimrod Documentation Page, , "http://ana-3.lcs.mit.edu/~jnc/nimrod/". Gont, et al. Expires January 9, 2017 [Page 31] Internet-Draft Filtering of IPv6 packets with EHs July 2016 [RFC3871] Jones, G., Ed., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September 2004, . [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, March 2011, . [RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations on Filtering of IPv4 Packets Containing IPv4 Options", BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, . [RFC7739] Gont, F., "Security Implications of Predictable Fragment Identification Values", RFC 7739, DOI 10.17487/RFC7739, February 2016, . [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, . 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(Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: liushucheng@huawei.com Gont, et al. Expires January 9, 2017 [Page 32] Internet-Draft Filtering of IPv6 packets with EHs July 2016 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 9, 2017 [Page 33]