This document specifies a mechanism that can be implemented in layer-2 devices to mitigate attack vectors based on Neighbor Discovery messages. It is meant to complement other mechanisms implemented in layer-2 devices such as Router Advertisement Guard (RA-Guard) and DHCPv6-Shield, with the goal of achieving a comprehensive IPv6 First Hop Security solution. This document is motivated by the desire to achieve feature parity with IPv4 with respect to First Hop Security mechanisms.
b0bd48d4dfcf7fc338169df812038a282998457c61b3f8cfb9294a669b43f80a
Operations Security Working Group F. Gont
(opsec) SI6 Networks / UTN-FRH
Internet-Draft June 5, 2012
Intended status: BCP
Expires: December 7, 2012
Neighbor Discovery Shield (ND-Shield): Protecting against Neighbor
Discovery Attacks
draft-gont-opsec-ipv6-nd-shield-00
Abstract
This document specifies a mechanism that can be implemented in
layer-2 devices to mitigate attack vectors based on Neighbor
Discovery messages. It is meant to complement other mechanisms
implemented in layer-2 devices such as Router Advertisement Guard
(RA-Guard) and DHCPv6-Shield, with the goal of achieving a
comprehensive IPv6 First Hop Security solution. This document is
motivated by the desire to achieve feature parity with IPv4 with
respect to First Hop Security mechanisms.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
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 December 7, 2012.
Copyright Notice
Copyright (c) 2012 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
Gont Expires December 7, 2012 [Page 1]
Internet-Draft Neighbor Discovery Shield June 2012
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. DISCLAIMER . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Mitigating attacks based on the Neighbor Discovery Protocol . 6
3.1. Neighbor Discovery Cache Poisoning attacks . . . . . . . . 6
3.2. Routing Denial of Service (DoS) attacks . . . . . . . . . 6
3.3. Redirect Attacks . . . . . . . . . . . . . . . . . . . . . 6
4. Importance of Deploying ND-Shield along with RA-Guard and
DHCPv6-Shield . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Neighbor Discovery Shield (ND-Shield) Specification . . . . . 8
5.1. Filtering Router Solicitation Messages . . . . . . . . . . 8
5.2. Filtering Neighbor Solicitation Messages . . . . . . . . . 10
5.3. Filtering Neighbor Advertisement Messages . . . . . . . . 12
5.4. Filtering ICMPv6 Redirect messages . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Assessment tools . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
Gont Expires December 7, 2012 [Page 2]
Internet-Draft Neighbor Discovery Shield June 2012
1. DISCLAIMER
This documents is heavily based on
[I-D.ietf-v6ops-ra-guard-implementation] which, at the time of this
writing, is going through IETF LC. Future revisions of this document
will addresses any issues raised for
[I-D.ietf-v6ops-ra-guard-implementation] which apply to this
document.
Some meta-issues that require input are:
o The current version of this document specifies the filtering of
different Neighbor Discovery messages in different sections.
While this approach results in better-scoped rules, it might not
lead to a straightforward implementation.
* Should we coalesce all filtering rules in a single section?
(and if anything, clarify how each message is processed in an
appendix).
* Even if we don't proceed that way, should similar text (e.g.
all the discussion right after the filtering rules, in each of
the sections) be coalesced in a single 'general' section? --
This might help reduce lots of duplicated text, make the
document shorter, etc.
Gont Expires December 7, 2012 [Page 3]
Internet-Draft Neighbor Discovery Shield June 2012
2. Introduction
First hop security techniques are well-known and widely implemented
and deployed in the IPv4 world. For example, a number of
implementations exist that allow a layer-2 device to block forged ARP
reply packets that would otherwise poison the ARP cache of the victim
[ARP-VULN]. Additionally, a number of implementations allow a
layer-2 device to limit the number of link-layer Source Addresses
that can be concurrently "in use" at any point in time on a specific
layer-2 port, or the number of IP addresses that can be concurrently
in use on a specific layer-2 port. Therefore, it is desirable that
the same mitigation techniques be available in the IPv6 world, such
that those networks currently employing these techniques can enforce
the same /policies for the IPv6 protocols.
This document specifies "Neighbor Discovery Shield (ND-Shield)", a
mechanism that can be employed by layer-2 devices to mitigate attacks
based on the Neighbor Discovery Protocol. Specifically, this
mechanism allows the filtering of malicious Router Solicitation,
Neighbor Solicitation, Neighbor Advertisement, and ICMPv6 Redirect
messages at a layer-2 device.
Filtering of Router Advertisement messages is part of Router
Advertisement Guard (RA-Guard) [RFC6104] [RFC6105]
[I-D.ietf-v6ops-ra-guard-implementation], and hence is not
specified in this document. In the same way, filtering of DHCPv6
packets is part of DHCPv6-Shield [I-D.gont-opsec-dhcpv6-shield],
and hence is not specified in this document.
The basic concept behind ND-Shield is that a layer-2 device can
filter Neighbor Solicitation, Neighbor Advertisement, and Redirect
messages, according to a number of different criteria, such as
whether the Target Address or the Source Link-Layer address fields of
the corresponding message are considered legitimate, or whether the
corresponding ICMPv6 type/code message is to be allowed on a specific
layer-2 port.
Section 3 discusses the type of attacks that ND-Shield is expected to
mitigate. Section 4 discusses the importance of deploying ND-Shield
in those networks currently employing RA-Guard and/or DHCPv6-Shield.
Section 5 specifies the Neighbor Discovery Guard (ND-Guard)
mechanism; that is, the filtering rules to be enforced on the local
layer-2 device such that attacks based on Router Solicitation,
Neighbor Solicitation, Neighbor Advertisement, and Redirect messages
are mitigated.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Gont Expires December 7, 2012 [Page 4]
Internet-Draft Neighbor Discovery Shield June 2012
document are to be interpreted as described in RFC 2119 [RFC2119].
Gont Expires December 7, 2012 [Page 5]
Internet-Draft Neighbor Discovery Shield June 2012
3. Mitigating attacks based on the Neighbor Discovery Protocol
This section provides a brief summary of the types of attacks that
ND-Shield is expected to mitigate.
3.1. Neighbor Discovery Cache Poisoning attacks
An attacker could cause a victim node to include an illegitimate
entry in the Neighbor Cache, by sending a Neighbor Solicitation or
Router Solicitation with a forged Source Link-Layer Address option or
a Neighbor Advertisement or REdirect message with a forged Target
Link-Layer address option. This attack could be exploited for Denial
of Service (DoS) or Man In The Middle (MITM) purposes.
3.2. Routing Denial of Service (DoS) attacks
An attacker could cause a victim node to disable its first-hop router
by sending a forged Neighor Advertisement with the 'R' flag clear.
3.3. Redirect Attacks
An attacker could cause a victim node to send its packets to a
different (and possibly malicious) "first hop router" by sending
forged Redirect messages. This attack could be exploited for Denial
of Service (DoS) or Man In The Middle (MITM) purposes.
Gont Expires December 7, 2012 [Page 6]
Internet-Draft Neighbor Discovery Shield June 2012
4. Importance of Deploying ND-Shield along with RA-Guard and DHCPv6-
Shield
RA-Guard [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation] can
mitigate attack vectors based on ICMPv6 Router Advertisement messages
by blocking Router Advertisement messages received on "unauthorized"
layer-2 ports. Thus, RA-Guard can mitigate attacks where a malicious
node tries to convey illegitimate network configuration information
to the victim nodes. In a similar way, DHCPv6-Shield
[I-D.gont-opsec-dhcpv6-shield] can mitigate attack vectors based on
forged DHCPv6 messages, where the attacker tries to convey
illegitimate network configuration information to the victim nodes.
However, even if Router Advertisement and DHCPv6 messages are
policed, an attacker could still e.g. divert traffic meant to the
legitimate router to a node he controls by sending forged Neighbor
Advertisement messages that illegitimately map the first-hop router's
IPv6 address to a the link-layer address of an attacker-controlled
node or by sending forged Redirect messages that cause a per-host
specific route to be created at the victim node.
Therefore, deployment of ND-Shield in scenarios where RA-Guard and/or
DHCPv6-Shield are already deployed is highly recommended.
Gont Expires December 7, 2012 [Page 7]
Internet-Draft Neighbor Discovery Shield June 2012
5. Neighbor Discovery Shield (ND-Shield) Specification
The following subsections specify the filtering rules MUST be
implemented as part of an "ND-Shield" implementation.
5.1. Filtering Router Solicitation Messages
1. If the Hop Limit is not 255, pass the packet.
Section 6.1.1 of [RFC4861] requires nodes to discard Router
Solicitation messages if their Hop Limit is not 255.
2. Try to identify whether the packet is an ICMPv6 Router
Solicitation message, by parsing the IPv6 header chain. When
doing so, enforce a limit on the maximum number of Extension
Headers that is allowed for each packet, and if such limit is hit
before the upper-layer protocol is identified, drop the packet.
[RFC6564] specifies a uniform format for IPv6 Extension
Header, thus meaning that an IPv6 node should be able to parse
an IPv6 header chain even if it contains Extension Headers
that are not currently supported by that node.
3. If ND-Shield is unable to identify whether the packet is an
ICMPv6 Router Solicitation message or not (i.e., the packet is a
first-fragment, and the necessary information is missing), drop
the packet.
Note: This rule should only be applied to non-fragmented IPv6
datagrams and IPv6 fragments with a Fragment Offset of 0 (non-
first fragments can be safely passed, since they will never
reassemble into a complete datagram if they are part of a
Router Solicitation message of which the first fragment was
dropped).
4. If the packet is identified to be an ICMPv6 Router Solicitation
message, then proceed as follows:
1. If the Source Address is the loopback address (::1) or a
multicast address, drop the packet.
Such addresses are invalid for Router Solicitation
messages, and dropping these illegitimate packets here
simplifies the nest filtering rules.
2. If the Source Address is a unicast address which is not known
to be in use at any of the layer-2 ports, record the Source
Address as being in use on the received port, and pass the
Gont Expires December 7, 2012 [Page 8]
Internet-Draft Neighbor Discovery Shield June 2012
packet as usual.
3. If the Source Address is a unicast address which is known to
be in use on a layer-2 port other than the one on which the
packet was received, drop the received packet.
5. In all other cases, pass the packet as usual.
Note: For the purpose of enforcing the ND-Shield filtering policy,
an ESP header [RFC4303] should be considered to be an "upper-layer
protocol" (that is, it should be considered the last header in the
IPv6 header chain). This means that packets employing ESP would
be passed by the ND-Shield device to the intended destination. If
the destination host does not have a security association with the
sender of the aforementioned IPv6 packet, the packet would be
dropped. Otherwise, if the packet is considered valid by the
IPsec implementation at the receiving host and encapsulates a
Router Solicitation message, it is up to the receiving host what
to do with such packet.
If a packet is dropped due to this filtering policy, then the packet
drop event SHOULD be logged. The logging mechanism SHOULD include a
drop counter dedicated to ND-Shield packet drops.
In order to protect current end-node IPv6 implementations, Rule #4
has been defined as a default rule to drop packets that cannot be
positively identified as not being Router Solicitation (RS) messages
(possibly because the packet contains fragments that do not contain
the entire IPv6 header chain). This means that, at least in theory,
ND-Shield could result in false-positive blocking of some legitimate
non-RS packets that could not be positively identified as being
non-RS. In order to reduce the likelihood of false positives, Rule
#1 requires that packets that would not pass the required validation
checks for RS messages (Section 6.1.1 of [RFC4861]) be passed without
further inspection. In any case, as noted in
[I-D.gont-6man-oversized-header-chain], IPv6 packets that fail to
include the entire IPv6 header chain are anyway unlikely to survive
in real networks. Whilst currently legitimate from a specifications
standpoint, they are virtually impossible to police with state-less
filters and firewalls, and are hence likely to be blocked by such
filters and firewalls.
This filtering policy assumes that host implementations require the
Hop Limit of Neighbor Discovery messages to be 255, and discard those
packets otherwise.
The aforementioned filtering rules implicitly handle the case of
fragmented packets: if the ND-Shield device fails to identify the
Gont Expires December 7, 2012 [Page 9]
Internet-Draft Neighbor Discovery Shield June 2012
upper-layer protocol as a result of the use of fragmentation, the
corresponding packets would be dropped.
Finally, we note that IPv6 implementations that allow overlapping
fragments (i.e. that do not comply with [RFC5722]) might still be
subject of RS-based attacks. However, a recent assessment of IPv6
implementations [SI6-FRAG] with respect to their fragment reassembly
policy seems to indicate that most current implementations comply
with [RFC5722].
5.2. Filtering Neighbor Solicitation Messages
1. If the Hop Limit is not 255, pass the packet.
Section 7.1.1 of [RFC4861] requires nodes to discard Neighbor
Solicitation messages if their Hop Limit is not 255.
2. Try to identify whether the packet is an ICMPv6 Neighbor
Solicitation message, by parsing the IPv6 header chain. When
doing so, enforce a limit on the maximum number of Extension
Headers that is allowed for each packet, and if such limit is hit
before the upper-layer protocol is identified, drop the packet.
[RFC6564] specifies a uniform format for IPv6 Extension
Header, thus meaning that an IPv6 node should be able to parse
an IPv6 header chain even if it contains Extension Headers
that are not currently supported by that node.
3. If ND-Shield is unable to identify whether the packet is an
ICMPv6 Neighbor Solicitation message or not (i.e., the packet is
a first-fragment, and the necessary information is missing), drop
the packet.
Note: This rule should only be applied to non-fragmented IPv6
datagrams and IPv6 fragments with a Fragment Offset of 0 (non-
first fragments can be safely passed, since they will never
reassemble into a complete datagram if they are part of a
Neighbor Solicitation message of which the first fragment was
dropped).
4. If the packet is identified to be an ICMPv6 Neighbor Solicitation
message, then proceed as follows:
1. If the Source Address is the unspecified address, and the
Destination Address is not a solicited-node multicast address
or the packet contains source link-layer address option, drop
the packet.
Gont Expires December 7, 2012 [Page 10]
Internet-Draft Neighbor Discovery Shield June 2012
2. If the Source Address is a unicast address which is not known
to be in use at any of the layer-2 ports, record the Source
Address as being in use on the received port, and pass the
packet as usual.
3. If the Source Address is a unicast address which is known to
be in use on a layer-2 port other than the one on which the
packet was received, drop the received packet.
5. In all other cases, pass the packet as usual.
Note: For the purpose of enforcing the ND-Shield filtering policy,
an ESP header [RFC4303] should be considered to be an "upper-layer
protocol" (that is, it should be considered the last header in the
IPv6 header chain). This means that packets employing ESP would
be passed by the ND-Shield device to the intended destination. If
the destination host does not have a security association with the
sender of the aforementioned IPv6 packet, the packet would be
dropped. Otherwise, if the packet is considered valid by the
IPsec implementation at the receiving host and encapsulates a
Router Advertisement message, it is up to the receiving host what
to do with such packet.
If a packet is dropped due to this filtering policy, then the packet
drop event SHOULD be logged. The logging mechanism SHOULD include a
drop counter dedicated to ND-Shield packet drops.
In order to protect current end-node IPv6 implementations, Rule #4
has been defined as a default rule to drop packets that cannot be
positively identified as not being Neighbor Solicitation (NS)
messages (possibly because the packet contains fragments that do not
contain the entire IPv6 header chain). This means that, at least in
theory, ND-Shield could result in false-positive blocking of some
legitimate non-NS packets that could not be positively identified as
being non-NS. In order to reduce the likelihood of false positives,
Rule #1 requires that packets that would not pass the required
validation checks for NS messages (Section 7.1.1 of [RFC4861]) be
passed without further inspection. In any case, as noted in
[I-D.gont-6man-oversized-header-chain], IPv6 packets that fail to
include the entire IPv6 header chain are anyway unlikely to survive
in real networks. Whilst currently legitimate from a specifications
standpoint, they are virtually impossible to police with state-less
filters and firewalls, and are hence likely to be blocked by such
filters and firewalls.
This filtering policy assumes that host implementations require the
Hop Limit of Neighbor Discovery messages to be 255, and discard those
packets otherwise.
Gont Expires December 7, 2012 [Page 11]
Internet-Draft Neighbor Discovery Shield June 2012
The aforementioned filtering rules implicitly handle the case of
fragmented packets: if the ND-Shield device fails to identify the
upper-layer protocol as a result of the use of fragmentation, the
corresponding packets would be dropped.
Finally, we note that IPv6 implementations that allow overlapping
fragments (i.e. that do not comply with [RFC5722]) might still be
subject of NS-based attacks. However, a recent assessment of IPv6
implementations [SI6-FRAG] with respect to their fragment reassembly
policy seems to indicate that most current implementations comply
with [RFC5722].
5.3. Filtering Neighbor Advertisement Messages
1. If the Hop Limit is not 255, pass the packet.
Section 7.1.2 of [RFC4861] requires nodes to discard Neighbor
Advertisement messages if their Hop Limit is not 255.
2. Try to identify whether the packet is an ICMPv6 Neighbor
Advertisement message, by parsing the IPv6 header chain. When
doing so, enforce a limit on the maximum number of Extension
Headers that is allowed for each packet, and if such limit is hit
before the upper-layer protocol is identified, drop the packet.
[RFC6564] specifies a uniform format for IPv6 Extension
Header, thus meaning that an IPv6 node should be able to parse
an IPv6 header chain even if it contains Extension Headers
that are not currently supported by that node.
3. If ND-Shield is unable to identify whether the packet is an
ICMPv6 Neighbor Advertisement message or not (i.e., the packet is
a first-fragment, and the necessary information is missing), drop
the packet.
Note: This rule should only be applied to non-fragmented IPv6
datagrams and IPv6 fragments with a Fragment Offset of 0 (non-
first fragments can be safely passed, since they will never
reassemble into a complete datagram if they are part of a
Neighbor Advertisement which, according to the information it
conveys and the port where it was received, should not
allowed).
4. If the packet is identified to be an ICMPv6 Neighbor
Advertisement message, then proceed as follows:
1. If the Target Address is the unspecified address (::), the
loopback address (::1), or a multicast address, drop the
Gont Expires December 7, 2012 [Page 12]
Internet-Draft Neighbor Discovery Shield June 2012
packet.
2. If the Target Address is a unicast address not known to be in
use at any of the layer-2 ports, record the Target Address as
being in use on the received port, and pass the packet as
usual.
3. If the Target Address is a unicast address known to be in use
on a layer-2 port other than the one on which the packet was
received, drop the received packet.
5. In all other cases, pass the packet as usual.
Note: For the purpose of enforcing the ND-Shield filtering policy,
an ESP header [RFC4303] should be considered to be an "upper-layer
protocol" (that is, it should be considered the last header in the
IPv6 header chain). This means that packets employing ESP would
be passed by the ND-Shield device to the intended destination. If
the destination host does not have a security association with the
sender of the aforementioned IPv6 packet, the packet would be
dropped. Otherwise, if the packet is considered valid by the
IPsec implementation at the receiving host and encapsulates a
Neighbor Advertisement message, it is up to the receiving host
what to do with such packet.
If a packet is dropped due to this filtering policy, then the packet
drop event SHOULD be logged. The logging mechanism SHOULD include a
drop counter dedicated to ND-Shield packet drops.
In order to protect current end-node IPv6 implementations, Rule #1
has been defined as a default rule to drop packets that cannot be
positively identified as not being Neighbor Advertisement (NA)
messages (possibly because the packet contains fragments that do not
contain the entire IPv6 header chain). This means that, at least in
theory, ND-Shield could result in false-positive blocking of some
legitimate non-NA packets that could not be positively identified as
being non-NA. In order to reduce the likelihood of false positives,
Rule #1 requires that packets that would not pass the required
validation checks for NA messages (Section 7.1.2 of [RFC4861]) be
passed without further inspection. In any case, as noted in
[I-D.gont-6man-oversized-header-chain], IPv6 packets that fail to
include the entire IPv6 header chain are anyway unlikely to survive
in real networks. Whilst currently legitimate from a specifications
standpoint, they are virtually impossible to police with state-less
filters and firewalls, and are hence likely to be blocked by such
filters and firewalls.
This filtering policy assumes that host implementations require the
Gont Expires December 7, 2012 [Page 13]
Internet-Draft Neighbor Discovery Shield June 2012
Hop Limit of Neighbor Discovery messages to be 255, and discard those
packets otherwise.
The aforementioned filtering rules implicitly handle the case of
fragmented packets: if the ND-Shield device fails to identify the
upper-layer protocol as a result of the use of fragmentation, the
corresponding packets would be dropped.
Finally, we note that IPv6 implementations that allow overlapping
fragments (i.e. that do not comply with [RFC5722]) might still be
subject of NA-based attacks. However, a recent assessment of IPv6
implementations [SI6-FRAG] with respect to their fragment reassembly
policy seems to indicate that most current implementations comply
with [RFC5722].
5.4. Filtering ICMPv6 Redirect messages
This section specifies the filtering rules for ICMPv6 Redirect
messages that must be implemented as part of an "ND-Shield"
implementation. The aforementioned rules should be enforced on all
layer-2 ports EXCEPT those that have been configured for router use.
NOTE: If ND-Shield is implemented along RA-Guard, the
aforementioned configuration information will be readily
available. That is, the filtering rules specified in this section
should be enforced on all layer-2 ports except those that have
been configured for router use.
1. If the IPv6 Source Address of the packet is not a link-local
address (fe80::/10), pass the packet.
Section 8.1 of [RFC4861] requires nodes to discard ICMPv6
Redirect messages if their IPv6 Source Address is not a link-
local address.
2. If the Hop Limit is not 255, pass the packet.
Section 8.1 of [RFC4861] requires nodes to discard ICMPv6
Redirect messages if their Hop Limit is not 255.
3. Try to identify whether the packet is an ICMPv6 Redirect message,
by parsing the IPv6 header chain. When doing so, enforce a limit
on the maximum number of Extension Headers that is allowed for
each packet, and if such limit is hit before the upper-layer
protocol is identified, drop the packet.
Gont Expires December 7, 2012 [Page 14]
Internet-Draft Neighbor Discovery Shield June 2012
[RFC6564] specifies a uniform format for IPv6 Extension
Header, thus meaning that an IPv6 node should be able to parse
an IPv6 header chain even if it contains Extension Headers
that are not currently supported by that node.
4. If ND-Shield is unable to identify whether the packet is an
ICMPv6 Redirect message or not (i.e., the packet is a first-
fragment, and the necessary information is missing), drop the
packet.
Note: This rule should only be applied to non-fragmented IPv6
datagrams and IPv6 fragments with a Fragment Offset of 0 (non-
first fragments can be safely passed, since they will never
reassemble into a complete datagram if they are part of a
ICMPv6 Redirect message received on a port where such packets
are not allowed).
5. If the packet is identified to be an ICMPv6 Redirect message,
drop the packet.
6. In all other cases, pass the packet as usual.
Note: For the purpose of enforcing the ND-Shield filtering policy,
an ESP header [RFC4303] should be considered to be an "upper-layer
protocol" (that is, it should be considered the last header in the
IPv6 header chain). This means that packets employing ESP would
be passed by the ND-Shield device to the intended destination. If
the destination host does not have a security association with the
sender of the aforementioned IPv6 packet, the packet would be
dropped. Otherwise, if the packet is considered valid by the
IPsec implementation at the receiving host and encapsulates a
ICMPv6 Redirect message, it is up to the receiving host what to do
with such packet.
If a packet is dropped due to this filtering policy, then the packet
drop event SHOULD be logged. The logging mechanism SHOULD include a
drop counter dedicated to ND-Shield packet drops.
In order to protect current end-node IPv6 implementations, Rule #4
has been defined as a default rule to drop packets that cannot be
positively identified as not being ICMPv6 Redirect messages (possibly
because the packet contains fragments that do not contain the entire
IPv6 header chain). This means that, at least in theory, ND-Shield
could result in false-positive blocking of some legitimate non-
Redirect packets that could not be positively identified as being
non-Redirect. In order to reduce the likelihood of false positives,
Rule #1 and Rule #2 require that packets that would not pass the
required validation checks for Redirect messages (Section 8.1 of
Gont Expires December 7, 2012 [Page 15]
Internet-Draft Neighbor Discovery Shield June 2012
[RFC4861]) be passed without further inspection. In any case, as
noted in [I-D.gont-6man-oversized-header-chain], IPv6 packets that
fail to include the entire IPv6 header chain are anyway unlikely to
survive in real networks. Whilst currently legitimate from a
specifications standpoint, they are virtually impossible to police
with state-less filters and firewalls, and are hence likely to be
blocked by such filters and firewalls.
This filtering policy assumes that host implementations require that
the IPv6 Source Address of ICMPv6 Redirect messages be a link-local
address, and that they discard the packet if this check fails, as
required by the current IETF specifications [RFC4861]. Additionally,
it assumes that hosts require the Hop Limit of Neighbor Discovery
messages to be 255, and discard those packets otherwise.
The aforementioned filtering rules implicitly handle the case of
fragmented packets: if the ND-Shield device fails to identify the
upper-layer protocol as a result of the use of fragmentation, the
corresponding packets would be dropped.
Finally, we note that IPv6 implementations that allow overlapping
fragments (i.e. that do not comply with [RFC5722]) might still be
subject of Redirect-based attacks. However, a recent assessment of
IPv6 implementations [SI6-FRAG] with respect to their fragment
reassembly policy seems to indicate that most current implementations
comply with [RFC5722].
Gont Expires December 7, 2012 [Page 16]
Internet-Draft Neighbor Discovery Shield June 2012
6. Security Considerations
This document specifies ND-Shield, an operational mitigation for
attack vectors based on Router Solicitation, Neighbor Solicitation,
Neighbor Advertisement, and Redirect messages.
We note that if an attacker sends a fragmented Neighbor Discovery
packets that are deemed as 'inappropriate' by the ND-Shield device,
the first-fragment would be dropped, and the rest of the fragments
would be passed. This means that the victim node would tie memory
buffers for the aforementioned fragments, which would never
reassemble into a complete datagram. If a large number of such
packets were sent by an attacker, and the victim node failed to
implement proper resource management for the fragment reassembly
buffer, this could lead to a Denial of Service (DoS). However, this
does not really introduce a new attack vector, since an attacker
could always perform the same attack by sending forged fragmented
datagrams in which at least one of the fragments is missing.
[CPNI-IPv6] discusses some resource management strategies that could
be implemented for the fragment reassembly buffer.
Finally, we note that the most effective and efficient mitigation for
these attacks would be to prohibit the use of IPv6 fragmentation with
all Neighbor Discovery messages (as proposed by
[I-D.gont-6man-nd-extension-headers]), such that the ND-Shield
functionality is easier to implement. However, since such mitigation
would require an update to existing implementations, it cannot be
relied upon in the short or near term.
Gont Expires December 7, 2012 [Page 17]
Internet-Draft Neighbor Discovery Shield June 2012
7. Acknowledgements
The author would like to thank Ran Atkinson, Karl Auer, Robert
Downie, Washam Fan, David Farmer, Marc Heuse, Nick Hilliard, Ray
Hunter, Joel Jaeggli, Simon Perreault, Arturo Servin, Gunter van de
Velde, James Woodyatt, and Bjoern A. Zeeb, who provided valuable
comments on the document "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)"
[I-D.ietf-v6ops-ra-guard-implementation], on which this document is
heavily based.
Gont Expires December 7, 2012 [Page 18]
Internet-Draft Neighbor Discovery Shield June 2012
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
RFC 5722, December 2009.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, April 2012.
8.2. Informative References
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
Problem Statement", RFC 6104, February 2011.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
February 2011.
[I-D.gont-opsec-dhcpv6-shield]
Gont, F., "DHCPv6-Shield: Protecting Against Rogue DHCPv6
Servers", draft-gont-opsec-dhcpv6-shield-00 (work in
progress), May 2012.
[I-D.ietf-v6ops-ra-guard-implementation]
Gont, F., "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)",
draft-ietf-v6ops-ra-guard-implementation-04 (work in
progress), May 2012.
[I-D.gont-6man-oversized-header-chain]
Gont, F. and V. Manral, "Security and Interoperability
Implications of Oversized IPv6 Header Chains",
draft-gont-6man-oversized-header-chain-01 (work in
progress), April 2012.
[I-D.gont-6man-nd-extension-headers]
Gont Expires December 7, 2012 [Page 19]
Internet-Draft Neighbor Discovery Shield June 2012
Gont, F., "Security Implications of the Use of IPv6
Extension Headers with IPv6 Neighbor Discovery",
draft-gont-6man-nd-extension-headers-02 (work in
progress), January 2012.
[SI6-FRAG]
SI6 Networks, "IPv6 NIDS evasion and improvements in IPv6
fragmentation/reassembly", 2012, <http://
blog.si6networks.com/2012/02/
ipv6-nids-evasion-and-improvements-in.html>.
[CPNI-IPv6]
Gont, F., "Security Assessment of the Internet Protocol
version 6 (IPv6)", UK Centre for the Protection of
National Infrastructure, (available on request).
[ARP-VULN]
Bekeey, M., "ARP Vulnerabilities: Indefensible Local
Network Attacks?", Black Hat Briefings '01, 2001, <http:/
/www.blackhat.com/presentations/bh-usa-01/MikeBeekey/
bh-usa-01-Mike-Beekey.ppt>.
[NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor",
<http://ndpmon.sourceforge.net/>.
[rafixd] "rafixd", <http://www.kame.net/dev/cvsweb2.cgi/kame/kame/
kame/rafixd/>.
[ramond] "ramond", <http://ramond.sourceforge.net/>.
[THC-IPV6]
"The Hacker's Choice IPv6 Attack Toolkit",
<http://www.thc.org/thc-ipv6/>.
Gont Expires December 7, 2012 [Page 20]
Internet-Draft Neighbor Discovery Shield June 2012
Appendix A. Assessment tools
UK CPNI (http://www.cpni.gov.uk) has produced assessment tools (which
have not yet been made publicly available) to assess IPv6
implementations with respect to the issues described in this
document. If you think that you would benefit from these tools, we
might be able to provide a copy of the tools (please contact Fernando
Gont at fernando@gont.com.ar).
[THC-IPV6] is a publicly-available set of tools that implements some
(if not all) of the techniques described in this document.
Gont Expires December 7, 2012 [Page 21]
Internet-Draft Neighbor Discovery Shield June 2012
Author's Address
Fernando Gont
SI6 Networks / UTN-FRH
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com
Gont Expires December 7, 2012 [Page 22]
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed