draft-ietf-opsec-ipv6-eh-filtering-01.txt   draft-ietf-opsec-ipv6-eh-filtering-02.txt 
opsec F. Gont opsec F. Gont
Internet-Draft UTN-FRH / SI6 Networks Internet-Draft UTN-FRH / SI6 Networks
Intended status: Informational W. Liu Intended status: Informational W. Liu
Expires: January 9, 2017 Huawei Technologies Expires: May 4, 2017 Huawei Technologies
R. Bonica R. Bonica
Juniper Networks Juniper Networks
July 8, 2016 October 31, 2016
Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension
Headers Headers
draft-ietf-opsec-ipv6-eh-filtering-01 draft-ietf-opsec-ipv6-eh-filtering-02
Abstract Abstract
It is common operator practice to mitigate security risks by It is common operator practice to mitigate security risks by
enforcing appropriate packet filtering. This document analyzes both enforcing appropriate packet filtering. This document analyzes both
the general security implications of IPv6 Extension Headers and the the general security implications of IPv6 Extension Headers and the
specific security implications of each Extension Header and Option specific security implications of each Extension Header and Option
type, and provides advice on the filtering of IPv6 packets based on type. Additionally, it discusses the operational and
the IPv6 Extension Headers and the IPv6 options they contain. interoperability implications of discarding packets based on the IPv6
Additionally, it discusses the operational and interoperability Extension Headers and IPv6 options they contain. Finally, it
implications of discarding packets based on the IPv6 Extension provides advice on the filtering of such IPv6 packets at transit
Headers and IPv6 options they contain. routers, for those cases in which such filtering is deemed as
necessary.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2017. This Internet-Draft will expire on May 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions Used in This Document . . . . . . 3 2. Terminology and Conventions Used in This Document . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
3. IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . 5 3. IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . 5
3.1. General Discussion . . . . . . . . . . . . . . . . . . . 5 3.1. General Discussion . . . . . . . . . . . . . . . . . . . 5
3.2. General Security Implications . . . . . . . . . . . . . . 5 3.2. General Security Implications . . . . . . . . . . . . . . 6
3.3. Advice on the Handling of IPv6 Packets with Specific IPv6 3.3. Summary of Advice on the Handling of IPv6 Packets with
Extension Headers . . . . . . . . . . . . . . . . . . . . 6 Specific IPv6 Extension Headers . . . . . . . . . . . . . 6
3.4. Advice on the Handling of Packets with Unknown IPv6 3.4. Advice on the Handling of IPv6 Packets with Specific IPv6
Extension Headers . . . . . . . . . . . . . . . . . . . . 14 Extension Headers . . . . . . . . . . . . . . . . . . . . 7
4. IPv6 Options . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5. Advice on the Handling of Packets with Unknown IPv6
4.1. General Discussion . . . . . . . . . . . . . . . . . . . 15 Extension Headers . . . . . . . . . . . . . . . . . . . . 16
4.2. General Security Implications of IPv6 Options . . . . . . 15 4. IPv6 Options . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. General Discussion . . . . . . . . . . . . . . . . . . . 17
4.2. General Security Implications of IPv6 Options . . . . . . 17
4.3. Advice on the Handling of Packets with Specific IPv6 4.3. Advice on the Handling of Packets with Specific IPv6
Options . . . . . . . . . . . . . . . . . . . . . . . . . 15 Options . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4. Advice on the handling of Packets with Unknown IPv6 4.4. Advice on the handling of Packets with Unknown IPv6
Options . . . . . . . . . . . . . . . . . . . . . . . . . 26 Options . . . . . . . . . . . . . . . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . 30 8.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
Recent studies (see e.g. [RFC7872]) suggest that there is widespread Recent studies (see e.g. [RFC7872]) suggest that there is widespread
filtering of IPv6 packets that contain IPv6 Extension Headers (EHs). dropping of IPv6 packets that contain IPv6 Extension Headers (EHs).
While some operators "officially" filter packets that contain IPv6 In some cases, such packet drops occur at transit routers. While
EHs, it is possible that some of the measured packet drops be the some operators "officially" drop packets that contain IPv6 EHs, it is
result of improper configuration defaults, or inappropriate advice in possible that some of the measured packet drops be the result of
this area. improper configuration defaults, or inappropriate advice in this
area.
This document analyzes both the general security implications of IPv6 This document analyzes both the general security implications of IPv6
EHs and the specific security implications of each EH and Option EHs and the specific security implications of each EH and Option
type, and provides advice on the filtering of IPv6 packets based on type, and provides advice on the filtering of IPv6 packets based on
the IPv6 EHs and the IPv6 options they contain. Since various the IPv6 EHs and the IPv6 options they contain. Since various
protocols may use IPv6 EHs (possibly with IPv6 options), discarding protocols may use IPv6 EHs (possibly with IPv6 options), discarding
packets based on the IPv6 EHs or IPv6 options they contain may have packets based on the IPv6 EHs or IPv6 options they contain may have
implications on the proper functioning of such protocols. Thus, this implications on the proper functioning of such protocols. Thus, this
document also attempts to discuss the operational and document also attempts to discuss the operational and
interoperability implications of such filtering policies. This interoperability implications of such filtering policies.
document is similar in nature to [RFC7126], which addresses the same
problem for the IPv4 case. However, in IPv6, the problem space is The filtering policy typically depends on where in the network such
compounded by the fact that IPv6 specifies a number of IPv6 EHs, and policy is enforced: when the policy is enforced in a transit network,
a number of IPv6 options which may be valid only when included in the policy typically follows a "black-list" approach, where only
packets with clear negative implications are dropped. On the other
hand, when the policy is enforced closer to the destination systems,
the policy typically follows a "white-list" approach, where only
traffic that is expected to be received is allowed. The advice in
this document is aimed only at transit routers that may need to
enforce a filtering policy based on the EHs and IPv6 options a packet
may contain, following a "black-list" approach, and hence is likely
to be much more permissive that a filtering policy to be employed
e.g. at the edge of an enterprise network. The advice in this
document is meant to improve the current situation of the dropping of
packets with IPv6 EHs in the Internet [RFC7872].
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. specific EH types.
This document completes and complements the considerations for This document completes and complements the considerations for
protecting the control plane from packets containing IP options that protecting the control plane from packets containing IP options that
can be found in [RFC6192]. can be found in [RFC6192].
Section 2 of this document specifies the terminology and conventions Section 2 of this document specifies the terminology and conventions
employed throughout this document. Section 3 of this document employed throughout this document. Section 3 of this document
discusses IPv6 EHs and provides advice in the area of filtering IPv6 discusses IPv6 EHs and provides advice in the area of filtering IPv6
packets that contain such IPv6 EHs. Section 4 of this document packets that contain such IPv6 EHs. Section 4 of this document
skipping to change at page 4, line 24 skipping to change at page 4, line 44
o The discard policy for each standard type of EH MUST be o The discard policy for each standard type of EH MUST be
individually configurable. individually configurable.
o The default configuration SHOULD allow all standard IPv6 EHs. o The default configuration SHOULD allow all standard IPv6 EHs.
The advice provided in this document is only meant to guide an The advice provided in this document is only meant to guide an
operator in configuring forwarding devices, and is *not* to be operator in configuring forwarding devices, and is *not* to be
interpreted as advice regarding default configuration settings for interpreted as advice regarding default configuration settings for
network devices. That is, this document provides advice with respect network devices. That is, this document provides advice with respect
to operational configurations, but does not change the implementation to operational configurations, but does not change the implementation
defaults required by [RFC7045]. We note that the advice provided in defaults required by [RFC7045].
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 We recommend that configuration options are made available to govern
the processing of each IPv6 EH type and each IPv6 option type. Such the processing of each IPv6 EH type and each IPv6 option type. Such
configuration options may include the following possible settings: configuration options may include the following possible settings:
o Permit this IPv6 EH or IPv6 Option type o Permit this IPv6 EH or IPv6 Option type
o Discard (and log) packets containing this IPv6 EH or 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 o Reject (and log) packets containing this IPv6 EH or option type
(where the packet drop is signaled with an ICMPv6 error message) (where the packet drop is signaled with an ICMPv6 error message)
o Rate-limit traffic containing this IPv6 EH or option type 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 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 forward the packet. We note that if a packet carries forwarding
information (e.g., in an IPv6 Routing Header) this might be an information (e.g., in an IPv6 Routing Header) this might be an
inappropriate or undesirable action. inappropriate or undesirable action.
skipping to change at page 5, line 39 skipping to change at page 6, line 7
requirements in [RFC7112]. We note that, in order to implement requirements in [RFC7112]. We note that, in order to implement
filtering rules on the fast path, it may be necessary for the filtering rules on the fast path, it may be necessary for the
filtering device to limit the depth into the packet that can be filtering device to limit the depth into the packet that can be
inspected before giving up. In circumstances where there is such inspected before giving up. In circumstances where there is such
a limitation, it is recommended that implementations discard a limitation, it is recommended that implementations discard
packets if, when trying to determine whether to discard or permit packets if, when trying to determine whether to discard or permit
a packet, the aforementioned limit is encountered. a packet, the aforementioned limit is encountered.
3.2. General Security Implications 3.2. General Security Implications
Depending on the specific device architecture, IPv6 packets that In some specific device architectures, IPv6 packets that contain IPv6
contain IPv6 EHs may cause the corresponding packets to be processed EHs may cause the corresponding packets to be processed on the slow
on the slow path, and hence may be leveraged for the purpose of path, and hence may be leveraged for the purpose of Denial of Service
Denial of Service (DoS) attacks (DoS) attacks [I-D.gont-v6ops-ipv6-ehs-packet-drops] [Cisco-EH]
[I-D.gont-v6ops-ipv6-ehs-packet-drops] [Cisco-EH] [FW-Benchmark]. [FW-Benchmark].
Operators are urged to consider IPv6 EH filtering and IPv6 options Operators are urged to consider IPv6 EH filtering and IPv6 options
handling capabilities of different devices as they make deployment handling capabilities of different devices as they make deployment
decisions in future. decisions in future.
3.3. Advice on the Handling of IPv6 Packets with Specific IPv6 3.3. Summary of Advice on the Handling of IPv6 Packets with Specific
IPv6 Extension Headers
This section summarizes the advice provided in Section 3.4, providing
references to the specific sections in which a detailed analysis can
be found.
+----------------------------+---------------------+----------------+
| EH type | Filtering policy | Reference |
+----------------------------+---------------------+----------------+
| IPv6 Hop-by-Hop Options | Drop or Ignore | Section 3.4.1 |
| (Proto=0) | | |
+----------------------------+---------------------+----------------+
| Routing Header for IPv6 | Drop only RTH0, | Section 3.4.2 |
| (Proto=43) | Permit other RH | |
| | Types | |
+----------------------------+---------------------+----------------+
| Fragment Header for IPv6 | Permit | Section 3.4.3 |
| (Proto=44) | | |
+----------------------------+---------------------+----------------+
| Encapsulating Security | Permit | Section 3.4.4 |
| Payload (Proto=50) | | |
+----------------------------+---------------------+----------------+
| Authentication Header | Permit | Section 3.4.5 |
| (Proto=51) | | |
+----------------------------+---------------------+----------------+
| Destination Options for | Permit | Section 3.4.6 |
| IPv6 (Proto=60) | | |
+----------------------------+---------------------+----------------+
| Mobility Header | Permit | Section 3.4.7 |
| (Proto=135) | | |
+----------------------------+---------------------+----------------+
| Host Identity Protocol | Permit | Section 3.4.8 |
| (Proto=139) | | |
+----------------------------+---------------------+----------------+
| Shim6 Protocol (Proto=140) | Permit | Section 3.4.9 |
+----------------------------+---------------------+----------------+
| Use for experimentation | Drop | Section 3.4.10 |
| and testing (Proto=253 and | | |
| 254) | | |
+----------------------------+---------------------+----------------+
Table 1: Summary of Advice on the Handling of IPv6 Packets with
Specific IPv6 Extension Headers
3.4. Advice on the Handling of IPv6 Packets with Specific IPv6
Extension Headers Extension Headers
3.3.1. IPv6 Hop-by-Hop Options (Protocol Number=0) 3.4.1. IPv6 Hop-by-Hop Options (Protocol Number=0)
3.3.1.1. Uses 3.4.1.1. Uses
The Hop-by-Hop Options header is used to carry optional information 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. that should be examined by every node along a packet's delivery path.
3.3.1.2. Specification 3.4.1.2. Specification
This EH is specified in [RFC2460], and its processing rules have been This EH is specified in [RFC2460], and its processing rules have been
updated by [RFC7045]. At the time of this writing, the following updated by [RFC7045]. At the time of this writing, the following
options have been specified for the Hop-by-Hop Options EH: options have been specified for the Hop-by-Hop Options EH:
o Type 0x00: Pad1 [RFC2460] o Type 0x00: Pad1 [RFC2460]
o Type 0x01: PadN [RFC2460] o Type 0x01: PadN [RFC2460]
o Type 0x05: Router Alert [RFC2711] o Type 0x05: Router Alert [RFC2711]
skipping to change at page 7, line 4 skipping to change at page 8, line 43
o Type 0xEE: IPv6 DFF Header [RFC6971] o Type 0xEE: IPv6 DFF Header [RFC6971]
o Type 0x1E: RFC3692-style Experiment [RFC4727] o Type 0x1E: RFC3692-style Experiment [RFC4727]
o Type 0x3E: RFC3692-style Experiment [RFC4727] o Type 0x3E: RFC3692-style Experiment [RFC4727]
o Type 0x5E: RFC3692-style Experiment [RFC4727] o Type 0x5E: RFC3692-style Experiment [RFC4727]
o Type 0x7E: RFC3692-style Experiment [RFC4727] o Type 0x7E: RFC3692-style Experiment [RFC4727]
o Type 0x9E: RFC3692-style Experiment [RFC4727] o Type 0x9E: RFC3692-style Experiment [RFC4727]
o Type 0xBE: RFC3692-style Experiment [RFC4727] o Type 0xBE: RFC3692-style Experiment [RFC4727]
o Type 0xDE: RFC3692-style Experiment [RFC4727] o Type 0xDE: RFC3692-style Experiment [RFC4727]
o Type 0xFE: RFC3692-style Experiment [RFC4727] o Type 0xFE: RFC3692-style Experiment [RFC4727]
3.3.1.3. Specific Security Implications 3.4.1.3. Specific Security Implications
Since this EH is required to be processed by all intermediate-systems Since this EH is required to be processed by all intermediate-systems
en route, it can be leveraged to perform Denial of Service attacks en route, it can be leveraged to perform Denial of Service attacks
against the network infrastructure. against the network infrastructure.
NOTE: Ongoing work essentially aims at requiring the Hop-by-Hop NOTE: Ongoing work essentially aims at requiring the Hop-by-Hop
Option EH to be processed only in cases where the intermmediate node Option EH to be processed only in cases where the intermediate node
is making use of any functionality provided by such header (see is making use of any functionality provided by such header (see
[I-D.ietf-6man-hbh-header-handling]). However, the deployed base is [I-D.ietf-6man-hbh-header-handling]). However, the deployed base is
likely to reflect the traditional behavior for a while, and hence the likely to reflect the traditional behavior for a while, and hence the
potential security problems of this EH are still of concern. potential security problems of this EH are still of concern.
3.3.1.4. Operational and Interoperability Impact if Blocked 3.4.1.4. Operational and Interoperability Impact if Blocked
Discarding packets containing a Hop-by-Hop Options EH would break any Discarding packets containing a Hop-by-Hop Options EH would break any
of the protocols that rely on it for proper functioning. For of the protocols that rely on it for proper functioning. For
example, it would break RSVP [RFC2205] and multicast deployments, and example, it would break RSVP [RFC2205] and multicast deployments, and
would cause IPv6 jumbograms to be discarded. would cause IPv6 jumbograms to be discarded.
3.3.1.5. Advice 3.4.1.5. Advice
The recommended configuration for the processing of these packets The recommended configuration for the processing of these packets
depends on the features and capabilities of the underlying platform. depends on the features and capabilities of the underlying platform.
On platforms that allow forwarding of packets with HBH Options on the On platforms that allow forwarding of packets with HBH Options on the
fast path, we recommend that packets with a HBH Options EH be fast path, we recommend that packets with a HBH Options EH be
forwarded as normal (for instance, [RFC7045] allows for forwarded as normal (for instance, [RFC7045] allows for
implementations to ignore the HBH Options EH when forwarding implementations to ignore the HBH Options EH when forwarding
packets). Otherwise, on platforms in which processing of packets packets). Otherwise, on platforms in which processing of packets
with a IPv6 HBH Options EH is carried out in the slow path, and an 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 option is provided to rate-limit these packets, we recommend that
this option be selected. Finally, when packets containing a HBH this option be selected. Finally, when packets containing a HBH
Options EH are processed in the slow-path, and the underlying Options EH are processed in the slow-path, and the underlying
platform does not have any mitigation options available for attacks platform does not have any mitigation options available for attacks
based on these packets, we recommend that such platforms discard based on these packets, we recommend that such platforms discard
packets containing IPv6 HBH Options EHs. packets containing IPv6 HBH Options EHs.
Finally, we note that, for obvious reasons, RPL (Routing Protocol for Finally, we note that, for obvious reasons, RPL (Routing Protocol for
Low-Power and Lossy Networks) [RFC6550] routers must not discard Low-Power and Lossy Networks) [RFC6550] routers must not discard
packets based on the presence of an IPv6 Hop-by-Hop Options EH. packets based on the presence of an IPv6 Hop-by-Hop Options EH.
3.3.2. Routing Header for IPv6 (Protocol Number=43) 3.4.2. Routing Header for IPv6 (Protocol Number=43)
3.3.2.1. Uses 3.4.2.1. Uses
The Routing header is used by an IPv6 source to list one or more 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 intermediate nodes to be "visited" on the way to a packet's
destination. destination.
3.3.2.2. Specification 3.4.2.2. Specification
This EH is specified in [RFC2460]. [RFC2460] originally specified This EH is specified in [RFC2460]. [RFC2460] originally specified
the Routing Header Type 0, which has been later obsoleted by the Routing Header Type 0, which has been later obsoleted by
[RFC5095]. [RFC5095].
At the time of this writing, the following Routing Types have been At the time of this writing, the following Routing Types have been
specified: specified:
o Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095] o Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095]
skipping to change at page 8, line 38 skipping to change at page 10, line 30
o Type 3: RPL Source Route Header [RFC6554] o Type 3: RPL Source Route Header [RFC6554]
o Types 4-252: Unassigned o Types 4-252: Unassigned
o Type 253: RFC3692-style Experiment 1 [RFC4727] o Type 253: RFC3692-style Experiment 1 [RFC4727]
o Type 254: RFC3692-style Experiment 2 [RFC4727] o Type 254: RFC3692-style Experiment 2 [RFC4727]
o Type 255: Reserved o Type 255: Reserved
3.3.2.3. Specific Security Implications 3.4.2.3. Specific Security Implications
The security implications of RHT0 have been discussed in detail in The security implications of RHT0 have been discussed in detail in
[Biondi2007] and [RFC5095]. [Biondi2007] and [RFC5095].
3.3.2.4. Operational and Interoperability Impact if Blocked 3.4.2.4. Operational and Interoperability Impact if Blocked
Blocking packets containing a RHT0 or RTH1 has no operational Blocking packets containing a RHT0 or RTH1 has no operational
implications. However, blocking packets employing other routing implications. However, blocking packets employing other routing
header types will break the protocols that rely on them. header types will break the protocols that rely on them.
3.3.2.5. Advice 3.4.2.5. Advice
Intermediate systems should discard packets containing a RHT0 or Intermediate systems should discard packets containing a RHT0 or
RHT1. RHT2 and RHT3 should be permitted, as required by [RFC7045]. RHT1. RHT2 and RHT3 should be permitted, as required by [RFC7045].
Other routing header types should be discarded. Other routing header types should be discarded.
3.3.3. Fragment Header for IPv6 (Protocol Number=44) 3.4.3. Fragment Header for IPv6 (Protocol Number=44)
3.4.3.1. Uses
3.3.3.1. Uses
This EH provides the fragmentation functionality for IPv6. This EH provides the fragmentation functionality for IPv6.
3.3.3.2. Specification 3.4.3.2. Specification
This EH is specified in [RFC2460]. This EH is specified in [RFC2460].
3.3.3.3. Specific Security Implications 3.4.3.3. Specific Security Implications
The security implications of the Fragment Header range from Denial of The security implications of the Fragment Header range from Denial of
Service attacks (e.g. based on flooding a target with IPv6 fragments) Service attacks (e.g. based on flooding a target with IPv6 fragments)
to information leakage attacks [RFC7739]. to information leakage attacks [RFC7739].
3.3.3.4. Operational and Interoperability Impact if Blocked 3.4.3.4. Operational and Interoperability Impact if Blocked
Blocking packets that contain a Fragment Header will break any Blocking packets that contain a Fragment Header will break any
protocol that may rely on fragmentation (e.g., the DNS [RFC1034]). protocol that may rely on fragmentation (e.g., the DNS [RFC1034]).
3.3.3.5. Advice 3.4.3.5. Advice
Intermediate systems should permit packets that contain a Fragment Intermediate systems should permit packets that contain a Fragment
Header. Header.
3.3.4. Encapsulating Security Payload (Protocol Number=50) 3.4.4. Encapsulating Security Payload (Protocol Number=50)
3.3.4.1. Uses 3.4.4.1. Uses
This EH is employed for the IPsec suite [RFC4303]. This EH is employed for the IPsec suite [RFC4303].
3.3.4.2. Specification 3.4.4.2. Specification
This EH is specified in [RFC4303]. This EH is specified in [RFC4303].
3.3.4.3. Specific Security Implications 3.4.4.3. Specific Security Implications
Besides the general implications of IPv6 EHs, this EH could be Besides the general implications of IPv6 EHs, this EH could be
employed to potentially perform a DoS attack at the destination employed to potentially perform a DoS attack at the destination
system by wasting CPU resources in validating the contents of the system by wasting CPU resources in validating the contents of the
packet. packet.
3.3.4.4. Operational and Interoperability Impact if Blocked 3.4.4.4. Operational and Interoperability Impact if Blocked
Discarding packets that employ this EH would break IPsec deployments. Discarding packets that employ this EH would break IPsec deployments.
3.3.4.5. Advice 3.4.4.5. Advice
Intermediate systems should permit packets containing the Intermediate systems should permit packets containing the
Encapsulating Security Payload EH. Encapsulating Security Payload EH.
3.3.5. Authentication Header (Number=51) 3.4.5. Authentication Header (Protocol Number=51)
3.3.5.1. Uses 3.4.5.1. Uses
The Authentication Header can be employed for provide authentication The Authentication Header can be employed for provide authentication
services in IPv4 and IPv6. services in IPv4 and IPv6.
3.3.5.2. Specification 3.4.5.2. Specification
This EH is specified in [RFC4302]. This EH is specified in [RFC4302].
3.3.5.3. Specific Security Implications 3.4.5.3. Specific Security Implications
Besides the general implications of IPv6 EHs, this EH could be Besides the general implications of IPv6 EHs, this EH could be
employed to potentially perform a DoS attack at the destination employed to potentially perform a DoS attack at the destination
system by wasting CPU resources in validating the contents of the system by wasting CPU resources in validating the contents of the
packet. packet.
3.3.5.4. Operational and Interoperability Impact if Blocked 3.4.5.4. Operational and Interoperability Impact if Blocked
Discarding packets that employ this EH would break IPsec deployments. Discarding packets that employ this EH would break IPsec deployments.
3.3.5.5. Advice 3.4.5.5. Advice
Intermediate systems should permit packets containing an Intermediate systems should permit packets containing an
Authentication Header. Authentication Header.
3.3.6. Destination Options for IPv6 (Protocol Number=60) 3.4.6. Destination Options for IPv6 (Protocol Number=60)
3.3.6.1. Uses 3.4.6.1. Uses
The Destination Options header is used to carry optional information The Destination Options header is used to carry optional information
that needs be examined only by a packet's destination node(s). that needs be examined only by a packet's destination node(s).
3.3.6.2. Specification 3.4.6.2. Specification
This EH is specified in [RFC2460]. At the time of this writing, the This EH is specified in [RFC2460]. At the time of this writing, the
following options have been specified for this EH: following options have been specified for this EH:
o Type 0x00: Pad1 [RFC2460] o Type 0x00: Pad1 [RFC2460]
o Type 0x01: PadN [RFC2460] o Type 0x01: PadN [RFC2460]
o Type 0x04: Tunnel Encapsulation Limit [RFC2473] o Type 0x04: Tunnel Encapsulation Limit [RFC2473]
o Type 0x4D: (Deprecated) o Type 0x4D: (Deprecated)
o Type 0xC9: Home Address [RFC6275] o Type 0xC9: Home Address [RFC6275]
o Type 0x8A: Endpoint Identification (Deprecated) o Type 0x8A: Endpoint Identification (Deprecated)
[draft-ietf-nimrod-eid] [draft-ietf-nimrod-eid]
o Type 0x8B: ILNP Nonce [RFC6744] o Type 0x8B: ILNP Nonce [RFC6744]
skipping to change at page 11, line 38 skipping to change at page 13, line 33
o Type 0x7E: RFC3692-style Experiment [RFC4727] o Type 0x7E: RFC3692-style Experiment [RFC4727]
o Type 0x9E: RFC3692-style Experiment [RFC4727] o Type 0x9E: RFC3692-style Experiment [RFC4727]
o Type 0xBE: RFC3692-style Experiment [RFC4727] o Type 0xBE: RFC3692-style Experiment [RFC4727]
o Type 0xDE: RFC3692-style Experiment [RFC4727] o Type 0xDE: RFC3692-style Experiment [RFC4727]
o Type 0xFE: RFC3692-style Experiment [RFC4727] o Type 0xFE: RFC3692-style Experiment [RFC4727]
3.3.6.3. Specific Security Implications 3.4.6.3. Specific Security Implications
No security implications are known, other than the general No security implications are known, other than the general
implications of IPv6 EHs. For a discussion of possible security implications of IPv6 EHs. For a discussion of possible security
implications of specific options specified for the DO header, please implications of specific options specified for the DO header, please
see the Section 4.3. see the Section 4.3.
3.3.6.4. Operational and Interoperability Impact if Blocked 3.4.6.4. Operational and Interoperability Impact if Blocked
Discarding packets that contain a Destination Options header would Discarding packets that contain a Destination Options header would
break protocols that rely on this EH type for conveying information, break protocols that rely on this EH type for conveying information,
including protocols such as ILNP [RFC6740] and Mobile IPv6 [RFC6275], including protocols such as ILNP [RFC6740] and Mobile IPv6 [RFC6275],
and IPv6 tunnels that employ the Tunnel Encapsulation Limit option. and IPv6 tunnels that employ the Tunnel Encapsulation Limit option.
3.3.6.5. Advice 3.4.6.5. Advice
Intermediate systems should permit packets that contain a Destination Intermediate systems should permit packets that contain a Destination
Options Header. Options Header.
3.3.7. Mobility Header (Number=135) 3.4.7. Mobility Header (Protocol Number=135)
3.3.7.1. Uses 3.4.7.1. Uses
The Mobility Header is an EH used by mobile nodes, correspondent The Mobility Header is an EH used by mobile nodes, correspondent
nodes, and home agents in all messaging related to the creation and nodes, and home agents in all messaging related to the creation and
management of bindings in Mobile IPv6. management of bindings in Mobile IPv6.
3.3.7.2. Specification 3.4.7.2. Specification
This EH is specified in [RFC6275]. This EH is specified in [RFC6275].
3.3.7.3. Specific Security Implications 3.4.7.3. Specific Security Implications
A thorough security assessment of the security implications of the A thorough security assessment of the security implications of the
Mobility Header and related mechanisms can be found in Section 15 of Mobility Header and related mechanisms can be found in Section 15 of
[RFC6275]. [RFC6275].
3.3.7.4. Operational and Interoperability Impact if Blocked 3.4.7.4. Operational and Interoperability Impact if Blocked
Discarding packets containing this EH would break Mobile IPv6. Discarding packets containing this EH would break Mobile IPv6.
3.3.7.5. Advice 3.4.7.5. Advice
Intermediate systems should permit packets containing this EH. Intermediate systems should permit packets containing this EH.
3.3.8. Host Identity Protocol (Protocol Number=139) 3.4.8. Host Identity Protocol (Protocol Number=139)
3.3.8.1. Uses 3.4.8.1. Uses
This EH is employed with the Host Identity Protocol (HIP), an This EH is employed with the Host Identity Protocol (HIP), an
experimental protocol that allows consenting hosts to securely experimental protocol that allows consenting hosts to securely
establish and maintain shared IP-layer state, allowing separation of establish and maintain shared IP-layer state, allowing separation of
the identifier and locator roles of IP addresses, thereby enabling the identifier and locator roles of IP addresses, thereby enabling
continuity of communications across IP address changes. continuity of communications across IP address changes.
3.3.8.2. Specification 3.4.8.2. Specification
This EH is specified in [RFC5201]. This EH is specified in [RFC5201].
3.3.8.3. Specific Security Implications 3.4.8.3. Specific Security Implications
The security implications of the HIP header are discussed in detail The security implications of the HIP header are discussed in detail
in Section 8 of [RFC6275]. in Section 8 of [RFC6275].
3.3.8.4. Operational and Interoperability Impact if Blocked 3.4.8.4. Operational and Interoperability Impact if Blocked
Discarding packets that contain the Host Identity Protocol would Discarding packets that contain the Host Identity Protocol would
break HIP deployments. break HIP deployments.
3.3.8.5. Advice 3.4.8.5. Advice
Intermediate systems should permit packets that contain a Host Intermediate systems should permit packets that contain a Host
Identity Protocol EH. Identity Protocol EH.
3.3.9. Shim6 Protocol (Protocol Number=140) 3.4.9. Shim6 Protocol (Protocol Number=140)
3.3.9.1. Uses 3.4.9.1. Uses
This EH is employed by the Shim6 [RFC5533] Protocol. This EH is employed by the Shim6 [RFC5533] Protocol.
3.3.9.2. Specification 3.4.9.2. Specification
This EH is specified in [RFC5533]. This EH is specified in [RFC5533].
3.3.9.3. Specific Security Implications 3.4.9.3. Specific Security Implications
The specific security implications are discussed in detail in The specific security implications are discussed in detail in
Section 16 of [RFC5533]. Section 16 of [RFC5533].
3.3.9.4. Operational and Interoperability Impact if Blocked 3.4.9.4. Operational and Interoperability Impact if Blocked
Discarding packets that contain this EH will break Shim6. Discarding packets that contain this EH will break Shim6.
3.3.9.5. Advice 3.4.9.5. Advice
Intermediate systems should permit packets containing this EH. Intermediate systems should permit packets containing this EH.
3.3.10. Use for experimentation and testing (Protocol Numbers=253 and 3.4.10. Use for experimentation and testing (Protocol Numbers=253 and
254) 254)
3.3.10.1. Uses 3.4.10.1. Uses
These IPv6 EHs are employed for performing RFC3692-Style experiments These IPv6 EHs are employed for performing RFC3692-Style experiments
(see [RFC3692] for details). (see [RFC3692] for details).
3.3.10.2. Specification 3.4.10.2. Specification
These EHs are specified in [RFC3692] and [RFC4727]. These EHs are specified in [RFC3692] and [RFC4727].
3.3.10.3. Specific Security Implications 3.4.10.3. Specific Security Implications
The security implications of these EHs will depend on their specific The security implications of these EHs will depend on their specific
use. use.
3.3.10.4. Operational and Interoperability Impact if Blocked 3.4.10.4. Operational and Interoperability Impact if Blocked
For obvious reasons, discarding packets that contain these EHs limits For obvious reasons, discarding packets that contain these EHs limits
the ability to perform legitimate experiments across IPv6 routers. the ability to perform legitimate experiments across IPv6 routers.
3.3.10.5. Advice 3.4.10.5. Advice
Intermediate systems should discard packets containing these EHs. Intermediate systems should discard packets containing these EHs.
Only in specific scenarios in which RFC3692-Style experiments are to Only in specific scenarios in which RFC3692-Style experiments are to
be performed should these EHs be permitted. be performed should these EHs be permitted.
3.4. Advice on the Handling of Packets with Unknown IPv6 Extension 3.5. Advice on the Handling of Packets with Unknown IPv6 Extension
Headers Headers
We refer to IPv6 EHs that have not been assigned an Internet Protocol 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 Number by IANA (and marked as such) in [IANA-PROTOCOLS] as "unknown
IPv6 extension headers" ("unknown IPv6 EHs"). IPv6 extension headers" ("unknown IPv6 EHs").
3.4.1. Uses 3.5.1. Uses
New IPv6 EHs may be specified as part of future extensions to the New IPv6 EHs may be specified as part of future extensions to the
IPv6 protocol. IPv6 protocol.
Since IPv6 EHs and Upper-layer protocols employ the same namespace, Since IPv6 EHs and Upper-layer protocols employ the same namespace,
it is impossible to tell whether an unknown "Internet Protocol it is impossible to tell whether an unknown "Internet Protocol
Number" is being employed for an IPv6 EH or an Upper-Layer protocol. Number" is being employed for an IPv6 EH or an Upper-Layer protocol.
3.4.2. Specification 3.5.2. Specification
The processing of unknown IPv6 EHs is specified in [RFC2460] and The processing of unknown IPv6 EHs is specified in [RFC2460] and
[RFC7045]. [RFC7045].
3.4.3. Specific Security Implications 3.5.3. Specific Security Implications
For obvious reasons, it is impossible to determine specific security For obvious reasons, it is impossible to determine specific security
implications of unknown IPv6 EHs. However, from security standpoint, implications of unknown IPv6 EHs. However, from security standpoint,
a device should discard IPv6 extension headers for which the security a device should discard IPv6 extension headers for which the security
implications cannot be determined. We note that this policy is implications cannot be determined. We note that this policy is
allowed by [RFC7045]. allowed by [RFC7045].
3.4.4. Operational and Interoperability Impact if Blocked 3.5.4. Operational and Interoperability Impact if Blocked
As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the
deployment of new IPv6 EHs and transport protocols. The deployment of new IPv6 EHs and transport protocols. The
corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored
such that filtering rules are updated as new IPv6 EHs are such that filtering rules are updated as new IPv6 EHs are
standardized. standardized.
We note that since IPv6 EHs and upper-layer protocols share the same We note that since IPv6 EHs and upper-layer protocols share the same
numbering space, discarding unknown IPv6 EHs may result in packets numbering space, discarding unknown IPv6 EHs may result in packets
encapsulating unknown upper-layer protocols being discarded. encapsulating unknown upper-layer protocols being discarded.
3.4.5. Advice 3.5.5. Advice
Intermediate systems should discard packets containing unknown IPv6 Intermediate systems should discard packets containing unknown IPv6
EHs. EHs.
4. IPv6 Options 4. IPv6 Options
4.1. General Discussion 4.1. General Discussion
The following subsections describe specific security implications of The following subsections describe specific security implications of
different IPv6 options, and provide advice regarding filtering different IPv6 options, and provide advice regarding filtering
skipping to change at page 22, line 29 skipping to change at page 24, line 29
The Endpoint Identification option was meant to be used with the The Endpoint Identification option was meant to be used with the
Nimrod routing architecture [NIMROD-DOC], but has never seen Nimrod routing architecture [NIMROD-DOC], but has never seen
widespread deployment. widespread deployment.
4.3.11.2. Specification 4.3.11.2. Specification
This option is specified in [NIMROD-DOC]. This option is specified in [NIMROD-DOC].
4.3.11.3. Specific Security Implications 4.3.11.3. Specific Security Implications
TBD. Undetermined.
4.3.11.4. Operational and Interoperability Impact if Blocked 4.3.11.4. Operational and Interoperability Impact if Blocked
None. None.
4.3.11.5. Advice 4.3.11.5. Advice
Intermediate systems should discard packets that contain this option. Intermediate systems should discard packets that contain this option.
4.3.12. ILNP Nonce (Type=0x8B) 4.3.12. ILNP Nonce (Type=0x8B)
skipping to change at page 27, line 12 skipping to change at page 29, line 12
intermediate systems that process the contents of IPv6 EHs should intermediate systems that process the contents of IPv6 EHs should
permit packets that contain unknown options. permit packets that contain unknown options.
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
6. Security Considerations 6. Security Considerations
This document provides advice on the filtering of IPv6 packets that This document provides advice on the filtering of IPv6 packets that
contain IPv6 EHs (and possibly IPv6 options). Discarding such contain IPv6 EHs (and possibly IPv6 options) at IPv6 transit routers.
packets can help to mitigate the security issues that arise from the It is meant to improve the current situation of widespread dropping
use of different IPv6 EHs and options. of such IPv6 packets in those cases where the drops result from
improper configuration defaults, or inappropriate advice in this
area.
7. Acknowledgements 7. Acknowledgements
The authors of this document would like to thank (in alphabetical The authors of this document would like to thank (in alphabetical
order) Mikael Abrahamsson, Brian Carpenter, Mike Heard, Jen Linkova, order) Mikael Abrahamsson, Brian Carpenter, Mike Heard, Jen Linkova,
Carlos Pignataro, Donald Smith, and Gunter Van De Velde, for Carlos Pignataro, Donald Smith, Gunter Van De Velde, and Erick
providing valuable comments on earlier versions of this document. Vyncke, for providing valuable comments on earlier versions of this
document.
This document borrows some text an analysis from [RFC7126], authored This document borrows some text an analysis from [RFC7126], authored
by Fernando Gont, Randall Atkinson, and Carlos Pignataro. by Fernando Gont, Randall Atkinson, and Carlos Pignataro.
8. References 8. References
8.1. Normative References 8.1. Normative References
[draft-gont-6man-ipv6-opt-transmit] [draft-gont-6man-ipv6-opt-transmit]
Gont, F., Liu, W., and R. Bonica, "Transmission and Gont, F., Liu, W., and R. Bonica, "Transmission and
 End of changes. 86 change blocks. 
124 lines changed or deleted 187 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/