< draft-ietf-v6ops-ipv6-ehs-packet-drops-02.txt   draft-ietf-v6ops-ipv6-ehs-packet-drops-03.txt >
IPv6 Operations Working Group (v6ops) F. Gont IPv6 Operations Working Group (v6ops) F. Gont
Internet-Draft SI6 Networks Internet-Draft SI6 Networks
Intended status: Informational N. Hilliard Intended status: Informational N. Hilliard
Expires: June 8, 2021 INEX Expires: July 6, 2021 INEX
G. Doering G. Doering
SpaceNet AG SpaceNet AG
W. Kumari W. Kumari
Google Google
G. Huston G. Huston
APNIC APNIC
W. Liu W. Liu
Huawei Technologies Huawei Technologies
December 5, 2020 January 2, 2021
Operational Implications of IPv6 Packets with Extension Headers Operational Implications of IPv6 Packets with Extension Headers
draft-ietf-v6ops-ipv6-ehs-packet-drops-02 draft-ietf-v6ops-ipv6-ehs-packet-drops-03
Abstract Abstract
This document summarizes the operational implications of IPv6 This document summarizes the operational implications of IPv6
extension headers specified in the IPv6 protocol specification extension headers specified in the IPv6 protocol specification
(RFC8200), and attempts to analyze reasons why packets with IPv6 (RFC8200), and attempts to analyze reasons why packets with IPv6
extension headers are often dropped in the public Internet. extension headers are often dropped in the public Internet.
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 June 8, 2021. This Internet-Draft will expire on July 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 37 skipping to change at page 2, line 37
6.3. DDoS Management and Customer Requests for Filtering . . . 9 6.3. DDoS Management and Customer Requests for Filtering . . . 9
6.4. Network Intrusion Detection and Prevention . . . . . . . 10 6.4. Network Intrusion Detection and Prevention . . . . . . . 10
6.5. Firewalling . . . . . . . . . . . . . . . . . . . . . . . 10 6.5. Firewalling . . . . . . . . . . . . . . . . . . . . . . . 10
7. Operational Implications . . . . . . . . . . . . . . . . . . 11 7. Operational Implications . . . . . . . . . . . . . . . . . . 11
7.1. Inability to Find Layer-4 Information . . . . . . . . . . 11 7.1. Inability to Find Layer-4 Information . . . . . . . . . . 11
7.2. Route-Processor Protection . . . . . . . . . . . . . . . 11 7.2. Route-Processor Protection . . . . . . . . . . . . . . . 11
7.3. Inability to Perform Fine-grained Filtering . . . . . . . 12 7.3. Inability to Perform Fine-grained Filtering . . . . . . . 12
7.4. Security Concerns Associated with IPv6 Extension Headers 12 7.4. Security Concerns Associated with IPv6 Extension Headers 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
IPv6 Extension Headers (EHs) allow for the extension of the IPv6 IPv6 Extension Headers (EHs) allow for the extension of the IPv6
protocol, and provide support for core functionality such as IPv6 protocol, and provide support for core functionality such as IPv6
fragmentation. However, common implementation limitations suggest fragmentation. However, common implementation limitations suggest
that EHs present a challenge for IPv6 packet routing equipment and that EHs present a challenge for IPv6 packet routing equipment and
middle-boxes, and evidence exists that IPv6 packets with EHs are middle-boxes, and evidence exists that IPv6 packets with EHs are
intentionally dropped in the public Internet in some network intentionally dropped in the public Internet in some network
deployments. deployments.
The authors of this document have been involved in numerous
discussions about IPv6 extension headers (both within the IETF and in
other fora), and have noticed that the security and operational
implications associated with IPv6 EHs were unknown to the larger
audience participating in these discussions.
This document has the following goals: This document has the following goals:
o Raise awareness about the operational and security implications of o Raise awareness about the operational and security implications of
IPv6 Extension Headers specified in [RFC8200], and present reasons IPv6 Extension Headers specified in [RFC8200], and present reasons
why some networks resort to intentionally dropping packets why some networks resort to intentionally dropping packets
containing IPv6 Extension Headers. containing IPv6 Extension Headers.
o Highlight areas where current IPv6 support by networking devices o Highlight areas where current IPv6 support by networking devices
maybe sub-optimal, such that the aforementioned support is maybe sub-optimal, such that the aforementioned support is
improved. improved.
skipping to change at page 5, line 7 skipping to change at page 4, line 50
fixed length variable number of EHs & length fixed length variable number of EHs & length
<------------> <--------------------------------> <------------> <-------------------------------->
Figure 2: IPv6 Packet Structure Figure 2: IPv6 Packet Structure
This packet structure has the following implications: This packet structure has the following implications:
o [RFC8200] requires the entire IPv6 header chain to be contained in o [RFC8200] requires the entire IPv6 header chain to be contained in
the first fragment of a packet, therefore limiting the IPv6 the first fragment of a packet, therefore limiting the IPv6
extension header chain to the size of the Path-MTU. extension header chain to the size of the path MTU.
o Other than the Path-MTU constraints, there are no other limits to o Other than the path MTU constraints, there are no other limits to
the number of IPv6 EHs that may be present in a packet. the number of IPv6 EHs that may be present in a packet.
Therefore, there is no upper-limit regarding "how deep into the Therefore, there is no upper-limit regarding "how deep into the
IPv6 packet" the upper-layer may be found. IPv6 packet" the upper-layer may be found.
o The only way for a node to obtain the upper-layer protocol type or o The only way for a node to obtain the upper-layer protocol type or
find the upper-layer protocol header is to parse and process the find the upper-layer protocol header is to parse and process the
entire IPv6 header chain, in sequence, starting from the mandatory entire IPv6 header chain, in sequence, starting from the mandatory
IPv6 header, until the last header in the IPv6 header chain is IPv6 header, until the last header in the IPv6 header chain is
found. found.
4. Previous Work on IPv6 Extension Headers 4. Previous Work on IPv6 Extension Headers
Some of the operational implications of IPv6 Extension Headers have Some of the operational implications of IPv6 Extension Headers have
been discussed in IETF circles: been discussed at the IETF:
o [I-D.taylor-v6ops-fragdrop] discusses a rationale for which o [I-D.taylor-v6ops-fragdrop] discusses a rationale for which
operators drop IPv6 fragments. operators drop IPv6 fragments.
o [I-D.wkumari-long-headers] discusses possible issues arising from o [I-D.wkumari-long-headers] discusses possible issues arising from
"long" IPv6 header chains. "long" IPv6 header chains.
o [I-D.kampanakis-6man-ipv6-eh-parsing] describes how o [I-D.kampanakis-6man-ipv6-eh-parsing] describes how
inconsistencies in the way IPv6 packets with extension headers are inconsistencies in the way IPv6 packets with extension headers are
parsed by different implementations could result in evasion of parsed by different implementations could result in evasion of
skipping to change at page 6, line 48 skipping to change at page 6, line 46
process the Hop-by-Hop Options header are required to do so. process the Hop-by-Hop Options header are required to do so.
A number of studies have measured the extent to which packets A number of studies have measured the extent to which packets
employing IPv6 extension headers are dropped in the public Internet: employing IPv6 extension headers are dropped in the public Internet:
o [PMTUD-Blackholes] and [Linkova-Gont-IEPG90] presented some o [PMTUD-Blackholes] and [Linkova-Gont-IEPG90] presented some
preliminary measurements regarding the extent to which packet preliminary measurements regarding the extent to which packet
containing IPv6 EHs are dropped in the public Internet. containing IPv6 EHs are dropped in the public Internet.
o [RFC7872] presents more comprehensive results and documents the o [RFC7872] presents more comprehensive results and documents the
methodology for obtaining the presented results. methodology used to obtain these results.
o [Huston-2017] and [Huston-2020] measured packet drops resulting o [Huston-2017] and [Huston-2020] measured packet drops resulting
from IPv6 fragmentation when communicating with DNS servers. from IPv6 fragmentation when communicating with DNS servers.
5. Packet Forwarding Engine Constraints 5. Packet Forwarding Engine Constraints
Most contemporary routers use dedicated hardware (e.g. ASICs or Most contemporary routers use dedicated hardware (e.g. ASICs or
NPUs) to determine how to forward packets across their internal NPUs) to determine how to forward packets across their internal
fabrics (see [IEPG94-Scudder] and [APNIC-Scudder] for details). One fabrics (see [IEPG94-Scudder] and [APNIC-Scudder] for details). One
of the common methods of handling next-hop lookup is to send a small of the common methods of handling next-hop lookup is to send a small
skipping to change at page 7, line 39 skipping to change at page 7, line 39
not sent to the look-up engine, then the router will normally drop not sent to the look-up engine, then the router will normally drop
the packet. the packet.
NOTE: NOTE:
Section 6 discusses some of the reasons for which a contemporary Section 6 discusses some of the reasons for which a contemporary
router might need to access layer-4 information to make a router might need to access layer-4 information to make a
forwarding decision. forwarding decision.
Historically, some packet forwarding engines punted packets of this Historically, some packet forwarding engines punted packets of this
form to the control plane for more in-depth analysis, but this is form to the control plane for more in-depth analysis, but this is
unfeasible on most current router architectures as a result of the unfeasible on most contemporary router architectures as a result of
vast difference between the hardware forwarding capacity of the the vast difference between the hardware forwarding capacity of the
router and processing capacity of the control plane and the size of router and processing capacity of the control plane and the size of
the management link which connects the control plane to the the management link which connects the control plane to the
forwarding plane. forwarding plane.
If an IPv6 header chain is sufficiently long that it exceeds the If an IPv6 header chain is sufficiently long that it exceeds the
packet look-up capacity of the router, the router could resort to packet look-up capacity of the router, the router could resort to
dropping the packet, as a result of being unable to determine how the dropping the packet, as a result of being unable to determine how the
packet should be handled. packet should be handled.
5.1. Recirculation 5.1. Recirculation
skipping to change at page 8, line 46 skipping to change at page 8, line 46
In the case of ECMP (equal cost multi path) load sharing, the router In the case of ECMP (equal cost multi path) load sharing, the router
on the sending side of the link needs to make a decision regarding on the sending side of the link needs to make a decision regarding
which of the links to use for a given packet. Since round-robin which of the links to use for a given packet. Since round-robin
usage of the links is usually avoided to prevent packet reordering, usage of the links is usually avoided to prevent packet reordering,
forwarding engines need to use a mechanism that will consistently forwarding engines need to use a mechanism that will consistently
forward the same data streams down the same forwarding paths. Most forward the same data streams down the same forwarding paths. Most
forwarding engines achieve this by calculating a simple hash using an forwarding engines achieve this by calculating a simple hash using an
n-tuple gleaned from a combination of layer-2 through to layer-4 n-tuple gleaned from a combination of layer-2 through to layer-4
packet header information. This n-tuple will typically use the src/ packet header information. This n-tuple will typically use the src/
dst MAC address, src/dst IP address, and if possible further layer-4 dst MAC address, src/dst IP address, and if possible further layer-4
src/dst port information. Layer-4 port information can increase the src/dst port information.
entropy of the hash, and it is often thought desirable to use it if
available.
We note that in the IPv6 world, flows are expected to be identified In the IPv6 world, flows are expected to be identified by means of
by means of the IPv6 Flow Label [RFC6437]. Thus, ECMP and Hash-based the IPv6 Flow Label [RFC6437]. Thus, ECMP and Hash-based Load-
Load-Sharing would be possible without the need to process the entire Sharing should be possible without the need to process the entire
IPv6 header chain to obtain upper-layer information to identify IPv6 header chain to obtain upper-layer information to identify
flows. However, we note that for a long time many IPv6 flows. Historically, many IPv6 implementations failed to set the
implementations failed to set the Flow Label, and ECMP and Hash-based Flow Label, and ECMP / hash-based load-sharing devices also did not
Load-Sharing devices also did not employ the Flow Label for employ the Flow Label for performing their task. Clearly, widespread
performing their task. support of [RFC6437] would relieve middle-boxes from having to
process the entire IPv6 header chain, making Flow Label-based ECMP
Clearly, widespread support of [RFC6437] would relieve middle-boxes and Hash-based Load-Sharing [RFC6438] feasible.
from having to process the entire IPv6 header chain, making Flow
Label-based ECMP and Hash-based Load-Sharing [RFC6438] feasible.
While support of [RFC6437] is currently widespread for current While support of [RFC6437] is currently widespread for current
versions of all popular host implementations, there is still only versions of all popular host implementations, there is still only
marginal usage of the IPv6 Flow Label for ECMP and load balancing marginal usage of the IPv6 Flow Label for ECMP and load balancing
[Cunha-2020]. A contributing factor could be the issues that have [Cunha-2020]. A contributing factor could be the issues that have
been found in host implementations and middle-boxes [Jaeggli-2018]. been found in host implementations and middle-boxes [Jaeggli-2018].
6.2. Enforcing infrastructure ACLs 6.2. Enforcing infrastructure ACLs
Generally speaking, infrastructure ACLs (iACLs) drop unwanted packets Infrastructure ACLs (iACLs) drop unwanted packets destined to a
destined to parts of a provider's infrastructure, because they are network's infrastructure IP addresses. Typically, iACLs are deployed
not operationally needed and can be used for attacks of different because external direct access to a network's infrastructure
sorts against router control planes. Some traffic needs to be addresses is operationally unnecessary, and can be used for attacks
differentiated depending on layer-3 or layer-4 criteria to achieve a of different sorts against router control planes. To this end,
useful balance of protection and functionality, for example: traffic usually needs to be differentiated on the basis of layer-3 or
layer-4 criteria to achieve a useful balance of protection and
functionality. For example, an infrastructure may be configured with
the following policy:
o Permit some amount of ICMP echo (ping) traffic towards a router's o Permit some amount of ICMP echo (ping) traffic towards a router's
addresses for troubleshooting. addresses for troubleshooting.
o Permit BGP sessions on the shared network of an exchange point o Permit BGP sessions on the shared network of an exchange point
(potentially differentiating between the amount of packets/seconds (potentially differentiating between the amount of packets/seconds
permitted for established sessions and connection establishment), permitted for established sessions and connection establishment),
but do not permit other traffic from the same peer IP addresses. but do not permit other traffic from the same peer IP addresses.
6.3. DDoS Management and Customer Requests for Filtering 6.3. DDoS Management and Customer Requests for Filtering
The case of customer DDoS protection and edge-to-core customer The case of customer DDoS protection and edge-to-core customer
protection filters is similar in nature to the infrastructure ACL protection filters is similar in nature to the iACL protection.
protection. Similar to infrastructure ACL protection, layer-4 ACLs Similar to iACL protection, layer-4 ACLs generally need to be applied
generally need to be applied as close to the edge of the network as as close to the edge of the network as possible, even though the
possible, even though the intent is usually to protect the customer intent is usually to protect the customer edge rather than the
edge rather than the provider core. Application of layer-4 DDoS provider core. Application of layer-4 DDoS protection to a network
protection to a network edge is often automated using Flowspec edge is often automated using Flowspec [RFC5575].
[RFC5575].
For example, a web site that normally only handled traffic on TCP For example, a web site that normally only handled traffic on TCP
ports 80 and 443 could be subject to a volumetric DDoS attack using ports 80 and 443 could be subject to a volumetric DDoS attack using
NTP and DNS packets with randomised source IP address, thereby NTP and DNS packets with randomised source IP address, thereby
rendering traditional [RFC5635] source-based real-time black hole rendering traditional [RFC5635] source-based real-time black hole
mechanisms useless. In this situation, DDoS protection ACLs could be mechanisms useless. In this situation, DDoS protection ACLs could be
configured to block all UDP traffic at the network edge without configured to block all UDP traffic at the network edge without
impairing the web server functionality in any way. Thus, being able impairing the web server functionality in any way. Thus, being able
to block arbitrary protocols at the network edge can avoid DDoS- to block arbitrary protocols at the network edge can avoid DDoS-
related problems both in the provider network and on the customer related problems both in the provider network and on the customer
edge link. edge link.
6.4. Network Intrusion Detection and Prevention 6.4. Network Intrusion Detection and Prevention
Network Intrusion Detection Systems (NIDS) examine network traffic Network Intrusion Detection Systems (NIDS) examine network traffic
and try to identify traffic patterns that can be correlated to and try to identify traffic patterns that can be correlated to
network-based attacks. These systems generally inspect application- network-based attacks. These systems generally inspect application-
layer traffic (if possible), but at the bare minimum inspect layer-4 layer traffic (if possible), but at the bare minimum inspect layer-4
flows. When attack activity is inferred, the operator is signaled of flows. When attack activity is inferred, the operator is notified of
the potential intrusion attempt. the potential intrusion attempt.
Network Intrusion Prevention Systems (IPS) operate similarly to Network Intrusion Prevention Systems (IPS) operate similarly to
NIDS's, but they can also prevent intrusions by reacting to detected NIDS's, but they can also prevent intrusions by reacting to detected
attack attempts by e.g., triggering packet filtering policies at attack attempts by e.g., triggering packet filtering policies at
firewalls and other devices. firewalls and other devices.
Use of extension headers can result problematic for NIDS/IPS, since: Use of extension headers can be problematic for NIDS/IPS, since:
o Extension headers increase the complexity of resulting traffic, o Extension headers increase the complexity of resulting traffic,
and the associated work and system requirements to process it. and the associated work and system requirements to process it.
o Use of unknown extension headers can prevent an NIDS/IPS to o Use of unknown extension headers can prevent an NIDS/IPS from
process layer-4 information processing layer-4 information
o Use of IPv6 fragmentation requires a stateful fragment-reassembly o Use of IPv6 fragmentation requires a stateful fragment-reassembly
operation, even for decoy traffic employing forged source operation, even for decoy traffic employing forged source
addresses (see e.g. [nmap]). addresses (see e.g. [nmap]).
As a result, in order to increase the efficiency or effectiveness of As a result, in order to increase the efficiency or effectiveness of
these systems, packets employing IPv6 extension headers are often these systems, packets employing IPv6 extension headers are often
dropped at the network ingress point(s) of networks that deploy these dropped at the network ingress point(s) of networks that deploy these
systems. systems.
6.5. Firewalling 6.5. Firewalling
Firewalls enforce security policies by means of packet filtering. Firewalls enforce security policies by means of packet filtering.
These systems generally inspect layer-3 and layer-4 traffic, and can These systems usually inspect layer-3 and layer-4 traffic, but can
often also examine application-layer traffic flows. often also examine application-layer traffic flows.
As with NIDS/IPS (Section 6.4), use of IPv6 extension headers can As with NIDS/IPS (Section 6.4), use of IPv6 extension headers can
represent a challenge to network firewalls, since: represent a challenge to network firewalls, since:
o Extension headers increase the complexity of resulting traffic, o Extension headers increase the complexity of resulting traffic,
and the associated work and system requirements to process it (see and the associated work and system requirements to process it (see
e.g. [Zack-FW-Benchmark]). e.g. [Zack-FW-Benchmark]).
o Use of unknown extension headers can prevent firewalls to process o Use of unknown extension headers can prevent firewalls from
layer-4 information processing layer-4 information.
o Use of IPv6 fragmentation requires a stateful fragment-reassembly o Use of IPv6 fragmentation requires a stateful fragment-reassembly
operation, even for decoy traffic employing forged source operation, even for decoy traffic employing forged source
addresses (see e.g. [nmap]). addresses (see e.g. [nmap]).
Additionally, a common firewall filtering policy is the so-called Additionally, a common firewall filtering policy is the so-called
"default deny", where all traffic is blocked (by default), and only "default deny", where all traffic is blocked (by default), and only
expected traffic is added to an "allow/accept list". expected traffic is added to an "allow/accept list".
As a result, whether because of the challenges represented by As a result, whether because of the challenges represented by
extension headers or because the use of IPv6 extension headers has extension headers or because the use of IPv6 extension headers has
not been explicitly allowed, packets employing IPv6 extension headers not been explicitly allowed, packets employing IPv6 extension headers
are often dropped by network firewalls. are often dropped by network firewalls.
7. Operational Implications 7. Operational Implications
7.1. Inability to Find Layer-4 Information 7.1. Inability to Find Layer-4 Information
As discussed in Section 6, contemporary routers and middle-boxes that As discussed in Section 6, routers and middle-boxes that need to find
need to find the layer-4 header must process the entire IPv6 the layer-4 header must process the entire IPv6 extension header
extension header chain. When such devices are unable to obtain the chain. When such devices are unable to obtain the required
required information, the forwarding device has the option to drop information, the forwarding device has the option to drop the packet
the packet unconditionally, forward the packet unconditionally, or unconditionally, forward the packet unconditionally, or process the
process the packet outside the normal forwarding path. Forwarding packet outside the normal forwarding path. Forwarding packets
packets unconditionally will usually allow for the circumvention of unconditionally will usually allow for the circumvention of security
security controls (see e.g. Section 6.5), while processing packets controls (see e.g. Section 6.5), while processing packets outside of
outside of the normal forwarding path will usually open the door to the normal forwarding path will usually open the door to DoS attacks
DoS attacks (see e.g. Section 5). Thus, in these scenarios, devices (see e.g. Section 5). Thus, in these scenarios, devices often
often simply resort to dropping such packets unconditionally. simply resort to dropping such packets unconditionally.
7.2. Route-Processor Protection 7.2. Route-Processor Protection
Most contemporary routers have a fast hardware-assisted forwarding Most contemporary routers have a fast hardware-assisted forwarding
plane and a loosely coupled control plane, connected together with a plane and a loosely coupled control plane, connected together with a
link that has much less capacity than the forwarding plane could link that has much less capacity than the forwarding plane could
handle. Traffic differentiation cannot be done by the control plane handle. Traffic differentiation cannot be performed by the control
side, because this would overload the internal link connecting the plane, because this would overload the internal link connecting the
forwarding plane to the control plane. forwarding plane to the control plane.
The Hop-by-Hop Options header has been particularly challenging since The Hop-by-Hop Options header has been particularly challenging since
in most circumstances, the corresponding packet is punted to the in most circumstances, the corresponding packet is punted to the
control plane for processing. As a result, operators usually drop control plane for processing. As a result, operators usually drop
IPv6 packets containing this extension header. Please see [RFC6192] IPv6 packets containing this extension header. [RFC6192] provides
for advice regarding protection of the router control plane. advice regarding protection of a router's control plane.
7.3. Inability to Perform Fine-grained Filtering 7.3. Inability to Perform Fine-grained Filtering
Some router implementations do not have support for fine-grained Some router implementations do not have support for fine-grained
filtering of IPv6 extension headers. For example, an operator that filtering of IPv6 extension headers. For example, an operator that
wishes to drop packets containing Routing Header Type 0 (RHT0), may wishes to drop packets containing Routing Header Type 0 (RHT0), may
only be able to filter on the extension header type (Routing Header). only be able to filter on the extension header type (Routing Header).
This could result in an operator enforcing a more coarse filtering This could result in an operator enforcing a more coarse filtering
policy (e.g. "drop all packets containing a Routing Header" vs. "only policy (e.g. "drop all packets containing a Routing Header" vs. "only
drop packets that contain a Routing Header Type 0"). drop packets that contain a Routing Header Type 0").
skipping to change at page 12, line 32 skipping to change at page 12, line 30
o Evasion of security controls o Evasion of security controls
o DoS due to processing requirements o DoS due to processing requirements
o DoS due to implementation errors o DoS due to implementation errors
o Extension Header-specific issues o Extension Header-specific issues
Unlike IPv4 packets where the upper-layer protocol can be trivially Unlike IPv4 packets where the upper-layer protocol can be trivially
found by means of the "IHL" ("Internet Header Length") IPv4 header found by means of the "IHL" ("Internet Header Length") IPv4 header
field, the structure of IPv6 packets is more flexible and complex, field, the structure of IPv6 packets is more flexible and complex.
and can represent a challenge for devices that need to find this This can represent a challenge for devices that need to find this
information, since locating upper-layer protocol information requires information, since locating upper-layer protocol information requires
that all IPv6 extension headers be examined. This has presented that all IPv6 extension headers be examined. In turn, this presents
implementation difficulties, and some packet filtering mechanisms implementation difficulties, since some packet filtering mechanisms
that require upper-layer information (even if just the upper layer that require upper-layer information (even if just the upper layer
protocol type) can be trivially circumvented by inserting IPv6 protocol type) can be trivially circumvented by inserting IPv6
Extension Headers between the main IPv6 header and the upper layer Extension Headers between the main IPv6 header and the upper layer
protocol. [RFC7113] describes this issue for the RA-Guard case, but protocol. [RFC7113] describes this issue for the RA-Guard case, but
the same techniques could be employed to circumvent other IPv6 the same techniques could be employed to circumvent other IPv6
firewall and packet filtering mechanisms. Additionally, firewall and packet filtering mechanisms. Additionally,
implementation inconsistencies in packet forwarding engines can implementation inconsistencies in packet forwarding engines can
result in evasion of security controls result in evasion of security controls
[I-D.kampanakis-6man-ipv6-eh-parsing] [Atlasis2014] [BH-EU-2014]. [I-D.kampanakis-6man-ipv6-eh-parsing] [Atlasis2014] [BH-EU-2014].
Packets with attached IPv6 Extension Headers can impact performance Sometimes packets with IPv6 Extension Headers can impact throughput
on routers that forward them. Unless appropriate mitigations are put performance on routers and middleboxes. Unless appropriate
in place (e.g., packet dropping and/or rate-limiting), an attacker mitigations are put in place (e.g., packet dropping and/or rate-
could simply send a large amount of IPv6 traffic employing IPv6 limiting), an attacker could simply send a large amount of IPv6
Extension Headers with the purpose of performing a Denial of Service traffic employing IPv6 Extension Headers with the purpose of
(DoS) attack (see Section 7 for further details). performing a Denial of Service (DoS) attack (see Section 7 for
further details).
NOTE: NOTE:
In the most trivial case, a packet that includes a Hop-by-Hop In the most trivial case, a packet that includes a Hop-by-Hop
Options header might go through the slow forwarding path, and be Options header might go through the slow forwarding path, to be
processed by the router's CPU. Another possible case might be processed by the router's CPU. Alternatively, a router configured
where a router that has been configured to enforce an ACL based on to enforce an ACL based on upper-layer information (e.g., upper
upper-layer information (e.g., upper layer protocol or TCP layer protocol or TCP Destination Port) may need to process the
Destination Port), needs to process the entire IPv6 header chain entire IPv6 header chain in order to find the required
(in order to find the required information), causing the packet to information, thereby causing the packet to be processed in the
be processed in the slow path [Cisco-EH-Cons]. We note that, for slow path [Cisco-EH-Cons]. We note that, for obvious reasons, the
obvious reasons, the aforementioned performance issues can affect aforementioned performance issues can affect other devices such as
other devices such as firewalls, Network Intrusion Detection firewalls, Network Intrusion Detection Systems (NIDS), etc.
Systems (NIDS), etc. [Zack-FW-Benchmark]. The extent to which [Zack-FW-Benchmark]. The extent to which performance is affected
these devices are affected is typically implementation-dependent. on these devices is implementation-dependent.
IPv6 implementations, like all other software, tend to mature with IPv6 implementations, like all other software, tend to mature with
time and wide-scale deployment. While the IPv6 protocol itself has time and wide-scale deployment. While the IPv6 protocol itself has
existed for over 20 years, serious bugs related to IPv6 Extension existed for over 20 years, serious bugs related to IPv6 Extension
Header processing continue to be discovered (see e.g. [Cisco-Frag1], Header processing continue to be discovered (see e.g. [Cisco-Frag1],
[Cisco-Frag2], and [FreeBSD-SA]). Because there is currently little [Cisco-Frag2], and [FreeBSD-SA]). Because there is currently little
operational reliance on IPv6 Extension headers, the corresponding operational reliance on IPv6 Extension headers, the corresponding
code paths are rarely exercised, and there is the potential for bugs code paths are rarely exercised, and there is the potential for bugs
that still remain to be discovered in some implementations. that still remain to be discovered in some implementations.
 End of changes. 29 change blocks. 
88 lines changed or deleted 81 lines changed or added

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