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 |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Fernando Gont , Will (Shucheng) LIU , Ron Bonica | ||
| Last updated | 2014-07-04 | ||
| Replaced by | draft-ietf-opsec-ipv6-eh-filtering, draft-ietf-opsec-ipv6-eh-filtering, RFC 9288 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gont-opsec-ipv6-eh-filtering-00
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]