Internet DRAFT - draft-gont-opsec-ipv6-nd-security
draft-gont-opsec-ipv6-nd-security
Network Working Group F. Gont
Internet-Draft SI6 Networks / UTN-FRH
Intended status: Informational R. Bonica
Expires: April 25, 2014 Juniper Networks
W. Liu
Huawei Technologies
October 22, 2013
Security Assessment of Neighbor Discovery (ND) for IPv6
draft-gont-opsec-ipv6-nd-security-02
Abstract
Neighbor Discovery is one of the core protocols of the IPv6 suite,
and provides in IPv6 similar functions to those provided in the IPv4
protocol suite by the Address Resolution Protocol (ARP) and the
Internet Control Message Protocol (ICMP). Its increased flexibility
implies a somewhat increased complexity, which has resulted in a
number of bugs and vulnerabilities found in popular implementations.
This document provides guidance in the implementation of Neighbor
Discovery, and documents issues that have affected popular
implementations, in the hopes that the same issues do not repeat in
other implementations.
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 April 25, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Gont, et al. Expires April 25, 2014 [Page 1]
Internet-Draft ND Security Assessment October 2013
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. DISCLAIMER . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Neighbor Discovery messages . . . . . . . . . . . . . . . . . 6
3.1. Router Solicitation message . . . . . . . . . . . . . . . 6
3.2. Router Advertisement . . . . . . . . . . . . . . . . . . . 7
3.3. Neighbor Solicitation message . . . . . . . . . . . . . . 11
3.4. Neighbor Advertisement message . . . . . . . . . . . . . . 12
3.5. Redirect message . . . . . . . . . . . . . . . . . . . . . 15
3.6. Neighbor Discovery Options . . . . . . . . . . . . . . . . 18
3.6.1. General issues with Neighbor Discovery options . . . . 19
3.6.2. Source Link-Layer Address Option . . . . . . . . . . . 20
3.6.3. Target Link-Layer Address Option . . . . . . . . . . . 22
3.6.4. Prefix Information . . . . . . . . . . . . . . . . . . 23
3.6.5. Redirected Header Option . . . . . . . . . . . . . . . 26
3.6.6. MTU Option . . . . . . . . . . . . . . . . . . . . . . 27
3.6.7. Route Information Option . . . . . . . . . . . . . . . 28
3.6.8. Recursive DNS Server Option . . . . . . . . . . . . . 31
3.6.9. DNS Search List . . . . . . . . . . . . . . . . . . . 33
4. Router and Prefix Discovery . . . . . . . . . . . . . . . . . 34
4.1. Router Specification . . . . . . . . . . . . . . . . . . . 34
4.2. Host Specification . . . . . . . . . . . . . . . . . . . . 34
5. Address Resolution . . . . . . . . . . . . . . . . . . . . . . 36
5.1. Interface initialization . . . . . . . . . . . . . . . . . 38
5.2. Receipt of Neighbor Solicitation messages . . . . . . . . 39
6. Vulnerability analysis . . . . . . . . . . . . . . . . . . . . 40
6.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 40
6.1.1. Neighbor Cache poisoning . . . . . . . . . . . . . . . 41
6.1.2. Tampering with Duplicate Address Detection (DAD) . . . 41
6.1.3. Tampering with Neighbor Unreachability Detection
(NUD) . . . . . . . . . . . . . . . . . . . . . . . . 42
6.1.4. Rogue Router . . . . . . . . . . . . . . . . . . . . . 43
6.1.5. Parameter spoofing . . . . . . . . . . . . . . . . . . 43
6.1.6. Bogus on-link prefixes . . . . . . . . . . . . . . . . 44
6.1.7. Bogus address configuration prefixes . . . . . . . . . 45
6.1.8. Disabling routers . . . . . . . . . . . . . . . . . . 45
Gont, et al. Expires April 25, 2014 [Page 2]
Internet-Draft ND Security Assessment October 2013
6.1.9. Tampering with 'on-link determination' . . . . . . . . 46
6.1.10. Introducing forwarding loops at routers . . . . . . . 48
6.1.11. Tampering with a Neighbor Discovery implementation . . 49
6.1.12. Tampering with a Neighbor Discovery router
implementation from a remote site . . . . . . . . . . 51
6.2. Performance degrading . . . . . . . . . . . . . . . . . . 52
6.2.1. Parameter spoofing . . . . . . . . . . . . . . . . . . 52
6.3. Traffic hijacking . . . . . . . . . . . . . . . . . . . . 52
6.3.1. Neighbor Cache poisoning . . . . . . . . . . . . . . . 52
6.3.2. Rogue Router . . . . . . . . . . . . . . . . . . . . . 53
6.3.3. Bogus on-link prefixes . . . . . . . . . . . . . . . . 53
6.3.4. Tampering with 'on-link determination' . . . . . . . . 54
6.4. Miscellaneous security issues . . . . . . . . . . . . . . 54
6.4.1. Detecting Sniffing Hosts . . . . . . . . . . . . . . . 54
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
8. Security Considerations . . . . . . . . . . . . . . . . . . . 56
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
10.1. Normative References . . . . . . . . . . . . . . . . . . . 58
10.2. Informative References . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
Gont, et al. Expires April 25, 2014 [Page 3]
Internet-Draft ND Security Assessment October 2013
1. DISCLAIMER
This is WORK IN PROGRESS. Some of the recommendations might possibly
change. For instance, some (NOT all) of the proposed "sanity checks"
help reduce vulnerability to some attacks at the expense of e.g.
reduced responsiveness. Further discussion might find some of such
checks to be inadequate or inappropriate. On the other hand, some of
mitigations discussed in this document have been incorporated into
popular Neighbor Discovery (ND) implementations.
Gont, et al. Expires April 25, 2014 [Page 4]
Internet-Draft ND Security Assessment October 2013
2. Introduction
Neighbor Discovery is used by nodes on the same link to discover each
other's presence, to determine each other's link-layer addresses, to
find routers, and to maintain reachability information about the
paths to active neighbors [RFC4861].
Neighbor Discovery is specified by [RFC4861]. [RFC3122] specifies
extensions to Neighbor Discovery for Inverse Discovery. [RFC4389]
specifies Neighbor Discovery proxies. [RFC3756] describes trust
models and threats for Neighbor Discovery. [RFC3971] specifies a
secure version of Neighbor Discovery named 'SEcure Neighbor Discovery
(SEND)'.
Neighbor Discovery was originally specified by [RFC2461], which was
later obsoleted by [RFC4861]. [RFC4943] clarifies the rationale for
the removal of the 'on-link assumption' from [RFC4861].
Section 3 of this document provides an analysis of each of the
Neighbor Discovery messages, along with a discussion of the Neighbor
Discovery options that have been specified at the time of this
writing. Section 4 discusses the security implications of Router and
Prefix Discovery. Section 5 describes the security implications of
Address Resolution. Section 6 contains a vulnerability analysis of
Neighbor Discovery.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Gont, et al. Expires April 25, 2014 [Page 5]
Internet-Draft ND Security Assessment October 2013
3. Neighbor Discovery messages
The following subsections discuss a number of validation checks that
should be performed on Neighbor Discovery messages.
3.1. Router Solicitation message
The following figure illustrates the syntax of Router Solicitation
messages:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 1: ICMPv6 Router Solicitation message format
As can be inferred from syntax of Router Solicitation messages, any
legitimate Router Solicitation message must have a length (as derived
from the IPv6 length) that is 8 octets or more. If the packet does
not pass this check, it should be silently dropped.
The Source Address of an IPv6 packet encapsulating a Router
Solicitation message is set to the value of one of the addresses
assigned to the sending interface, or to the unspecified address (::)
if no address has been assigned to that interface. Nodes should
discard Router Solicitation messages that have a multicast address in
the Source Address field.
The Destination Address of an IPv6 packet encapsulating a Router
Solicitation message is set to the all-routers multicast address.
A unicast address could possibly be used for the Destination
Address for debugging purposes.
If a unicast address is used for the Destination Address, the
receiving system should ensure that it is a link-local address. If
the packet does not pass this check, it should be silently dropped.
Gont, et al. Expires April 25, 2014 [Page 6]
Internet-Draft ND Security Assessment October 2013
While this is not explicitly required in [RFC4861] this provides
an additional counter-measure (other than the validation of the
Hop Limit) for non-local malicious nodes willing to make use of
Router Solicitation messages for reconnaissance purposes.
As of this writing, the following options are valid in a Router
Solicitation message:
o Source link-layer address
Any other options should be silently ignored.
If a 'source link-layer address' option is included, the following
sanity checks should be performed:
o The Source Address of the packet must not the unspecified address
(::) or the "loopback" addresses (::1)
o The advertised link-layer address must not a broadcast or
multicast address
3.2. Router Advertisement
The following figure illustrates the syntax of Router Advertisement
messages.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H|Prf|Resvd| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 2: ICMPv6 Router Advertisement message format
The Source Address of an IPv6 packet encapsulating a Router
Advertisement message is set to a link-local address assigned to the
interface from which the message is sent. Nodes should discard
Router Advertisements whose Source Address is not a link-local
address.
Gont, et al. Expires April 25, 2014 [Page 7]
Internet-Draft ND Security Assessment October 2013
The Destination Address of an IPv6 packet encapsulating a Router
Advertisement message is set to the Source Address of the system that
elicited the Router Advertisement message (unless this was the
unspecified address), or in the case of unsolicited Router
Advertisements, to the all-nodes multicast address. Nodes receiving
a Router Advertisement should ensure that if the Destination Address
is a unicast address, it is a link-local address. Otherwise, the
Router Advertisement message should be silently dropped.
While this is not explicitly required in [RFC4861] this provides
another mitigation for non-local malicious nodes willing to make
use of Router Solicitation messages for reconnaissance purposes.
The Cur Hop Limit field specifies the default value that should be
placed in the Hop Count field of outgoing IPv6 packets. As stated in
[RFC4861] a value of 0 means unspecified (by this router). If the
Cur Hop Limit field is larger than 0, nodes should sanitize the
received Cur Hop Limit value as follows:
SanitizedCH = max(Cur Hop Limit, MIN_HOP_LIMIT)
where the sanitized Cur Hop Limit (SanitizedCH) is set to the maximum
of the Cur Hop Limit and the variable MIN_HOP_LIMIT. MIN_HOP_LIMIT
should default to 64, and should be configurable by the system
administrator.
If the received Cur Hop Limit were not sanitized, an attacker could
perform a Denial-of-Service (DoS) attack against the local network by
forging a Router Advertisement message that includes a very small Cur
Hop Limit value. As a result, nodes honouring the Router
Advertisement would set the Hop Limit of outgoing packets to such
small value, and as a result those packets would be dropped by some
intervening router.
For example, if an attacker were to forge a Router Advertisement that
contains a Cur Hop Limit of 1, the victim nodes could communicate
only with nodes on the same network link, as their packets would be
dropped by the first-hop router.
XXXX The Prf field is specified in [RFC4191] and is used to specify a
'preference' value for the router sending the Router Advertisement.
The Router Lifetime field is a 16-bit unsigned integer that specifies
the lifetime associated with the default router in units of seconds.
A Router Lifetime of 0 indicates that the router is not a default
router and must not appear in the default router list. The sending
rules in Section 6 of [RFC4861] limit the Router Lifetime to 9000
seconds. However, nodes are expected to handle any value.
Gont, et al. Expires April 25, 2014 [Page 8]
Internet-Draft ND Security Assessment October 2013
An attacker could exploit the Router Lifetime field to perform DoS
attacks or performance-degrading attacks. For example, an
attacker could forge Router Advertisement messages that include a
very small Router Lifetime. This would have a two-fold effect on
the network. Firstly, once the advertised router expires as a
'default' router, the corresponding nodes might face a Denial of
Service, as a result of having no default routers. Secondly, a
small Router Lifetime value could lead to increased traffic in the
network, and increased processing time in the affected nodes (as a
result of the additional Router Solicitation/Advertisement
exchanges needed to re-configure the routing table of each node).
If the Router Lifetime is different from 0, it should be sanitized as
follows:
SanitizedRL = min( max(Router Lifetime, MIN_ROUTER_LIFETIME),
MAX_ROUTER_LIFETIME)
where lower and upper limits are enforced on the advertised Router
Lifetime. The lower limit is specified by the variable
MIN_ROUTER_LIFETIME, and should default to 1800 seconds. The upper
limit is specified by MAX_ROUTER_LIFETIME, and should default to 9000
seconds.
The value '1800 seconds' results from the recommended default value
(AdvDefaultLifetime) for setting the Router Lifetime, which instead
results from the expression '3 * MaxRtrAdvInterval' (where
MaxRtrAdvInterval defaults to 600 seconds). The value '9000 seconds'
results from the required upper limit for setting the Router Lifetime
field (AdvDefaultLifetime).
The Router Lifetime should not be sanitized when it is equal to 0, as
a value of 0 indicates that the corresponding router should not be
used as a default router (i.e., it is only advertising prefixes).
When a router is in the Default routers list, and a Router
Advertisement is received with a Router Lifetime of 0, a node might
choose to keep the router in the Default routers list (as allowed by
the current local Router Lifetime value). This might allow nodes to
be resilient to Router Advertisements that incorrectly or maliciously
advertise a Router Lifetime of 0, at the expense of loss of
responsiveness in scenarios in which a router explicitly advertises
it wants to be removed from the Default routers list (such a scenario
is described in Section 6.2.5 of [RFC4861].
The Reachable Time field is a 32-bit unsigned integer that specifies
the amount of time, in milliseconds, that a node assumes a neighbor
is reachable after having received a reachability confirmation. A
Gont, et al. Expires April 25, 2014 [Page 9]
Internet-Draft ND Security Assessment October 2013
value of zero means 'unspecified by this router'. If Reachable Time
is different from 0, it should be sanitized as follows:
SanitizedRT = max( min( Reachable Time, MAX_REACHABLE_TIME),
MIN_REACHABLE_TIME)
where MAX_REACHABLE_TIME and MIN_REACHABLE_TIME impose upper and
lower limits, respectively, to the received Reachable Time value. We
propose a MAX_REACHABLE_TIME of 3,600,000 (one hour) and a
MIN_REACHABLE_TIME of 20,000.
The upper limit of 3,600,000 is specified in Section 6.2.1 of
[RFC4861] (AdvReachableTime router variable). The lower limit has
been selected such that the minimum local ReachableTime (that would
result from MIN_RANDOM_FACTOR * SanitizedRT) is not smaller than 10
seconds.
The Retrans Timer is a 32-bit unsigned integer that specifies the
amount of time, in milliseconds between retransmitted Neighbor
Solicitation messages. A value of zero means 'unspecified by this
router'. If Retrans Timer is different from 0, it should be
sanitized as follows:
SanitizedRXT = max( min( Retrans Timer, MAX_RETRANS_TIME),
MIN_RETRANS_TIME)
We propose a MAX_RETRANS_TIME of 60,000 and a MIN_RETRANS_TIME of
1,000.
At the time of this writing, the options that may be legitimately
included in Router Advertisements are:
o Source link-layer address
o MTU
o Prefix information
o Route Information
o Recursive DNS Server
o DNS Search List
Other options should be silently ignored.
The Source link-layer address option specifies the link-layer address
of the interface from which the Router Advertisement is sent. It is
Gont, et al. Expires April 25, 2014 [Page 10]
Internet-Draft ND Security Assessment October 2013
only used on link layers that have addresses. Nodes should ignore
the source link-layer address option in Router Advertisements
received on link layers that do not have addresses.
Section 3.6 of this document discusses the security implications of
all the Neighbor Discovery options.
3.3. Neighbor Solicitation message
The following figure illustrates the format of Neighbor Solicitation
messages:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 3: ICMPv6 Neighbor Solicitation message format
The Source Address of an IPv6 packet encapsulating a Neighbor
Solicitation message is set to an address assigned to the interface
from which the message is sent, or to the unspecified address (::).
The Destination Address of an IPv6 packet encapsulating a Neighbor
Solicitation message is set to the solicited-node multicast address
corresponding to the target address, or to the target address.
The ICMPv6 packet length (as derived from the IPv6 Payload Length)
must be greater than or equal to 24. If the packet does not pass
this check, it should be silently dropped.
The Target Address is the IPv6 address of the target of the
solicitation. The Target Address must pass the following checks:
Gont, et al. Expires April 25, 2014 [Page 11]
Internet-Draft ND Security Assessment October 2013
1. It must not be a multicast address (as required in Section 4.3 of
[RFC4861])
2. It must not be the unspecified address (::)
3. It must not be the loopback address (::1)
The Target Address must also meet any of the following criteria:
1. It is a valid unicast or anycast address assigned to the
receiving interface
2. It is a unicast or anycast address for which the node is offering
proxy service
3. It is a 'tentative' address on which 'Duplicate Address
Detection' (DAD) is being performed (in which case the Neighbor
Solicitation message should be processed according to [RFC4862])
At the time of this writing, the options that may be legitimately
included in Neighbor Solicitations are:
o Source link-layer address
According to Section 4.3 of [RFC4861], the source link-layer address
option must not be included when the Source Address is the
unspecified address (::). A node receiving a Neighbor Solicitation
that includes a source link-layer address and that has the
unspecified address (::) as the Source Address should silently drop
the corresponding packet.
According to Section 4.3 of [RFC4861], on link layers that have
addresses (and provided that the Source Address is not the
unspecified address), Neighbor Solicitations sent to multicast
addresses must include the source link-layer address option. A node
receiving a Neighbor Solicitation sent to a multicast address that
does not include a source link-layer option should be silently
dropped.
3.4. Neighbor Advertisement message
A node sends Neighbor Advertisements in response to Neighbor
Solicitations and sends unsolicited Neighbor Advertisements in order
to (unreliably) propagate new information quickly [RFC4861].
The following figure illustrates the syntax of Neighbor Advertisement
messages:
Gont, et al. Expires April 25, 2014 [Page 12]
Internet-Draft ND Security Assessment October 2013
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|S|O| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: ICMPv6 Neighbor Advertisement message format
The Source Address of an IPv6 packet encapsulating a Neighbor
Advertisement message is set to a link-local address assigned to the
interface from which the message is sent. Nodes should discard
Neighbor Advertisements that do not have a link-local address in the
Source Address field.
The Destination Address of an IPv6 packet encapsulating a Neighbor
Advertisement message is set to the Source Address of the Neighbor
Solicitation that elicited the Neighbor Advertisement message
(provided the Source Address of the Neighbor Solicitation was a
unicast address). If the Source Address of the Neighbor Solicitation
was the unspecified address, the Neighbor Advertisement is sent to
the all-nodes multicast address. Finally, unsolicited Neighbor
Advertisements are sent to the all-nodes multicast address
The Hop Limit of an IPv6 packet encapsulating a Neighbor
Advertisement message must be set to 255 by the sending node. A node
receiving a Neighbor Advertisement message should perform the
following check:
The ICMPv6 packet length (as derived from the IPv6 Payload Length)
must be greater than or equal to 24. If the packet does not pass
this check, it should be silently dropped.
The R flag is the Router flag, and is used by Neighbor Unreachability
Detection (NUD). When set, it indicates that the sender is a router.
An attacker could forge a Neighbor Advertisement message with the
Router flag cleared to cause the receiving node to remove the
Gont, et al. Expires April 25, 2014 [Page 13]
Internet-Draft ND Security Assessment October 2013
impersonated Router from the Default router list.
The S bit is the Solicited flag. When set it indicates that the
Neighbor Advertisement is sent in response to a Neighbor Solicitation
sent from the Destination Address. The S flag is used as
reachability confirmation for Network Unreachability Detection (NUD).
As stated in Section 4.4 of [RFC4861], it must not be set in
multicast advertisements or in unsolicited unicast advertisements.
A node that receives a Neighbor Advertisement message that has the
S-bit set and was sent to a multicast address should silently discard
the received message. Additionally, a node that receives an
unsolicited Neighbor Advertisement message (i.e., there was not a
pending Neighbor Solicitation for the Target Address) with the S-bit
set that was sent to a unicast address should silently drop the
received message.
The O bit is the Override flag. When set, it indicates that this
Neighbor Advertisement should override an existing cache entry and
update the cached link-layer address. When the O bit is not set, the
advertisement will not update a cached link-layer address, but will
update a Neighbor Cache entry that does not include a link-layer
address.
The O bit should be set in all solicited advertisements, except those
for anycast addresses. A node that receives an unsolicited Neighbor
Advertisement message with the O bit set should silently drop the
received message. However, we note that it is virtually impossible
to enforce this requirement for Neighbor Advertisement messages for
anycast addresses that have the O bit set, as anycast addresses are
syntactically indistinguishable from normal unicast addresses.
For solicited Neighbor Advertisements, the Target Address is set to
the Target Address of the Neighbor Solicitation message that elicited
the advertisement. For unsolicited Neighbor Advertisements, the
Target Address is set to the address whose link-layer address has
changed.
The Target Address must pass the following checks:
1. It must not be a multicast address (as required in Section 4.4 of
[RFC4861]
2. It must not be the unspecified address (::)
3. It must not be the loopback address (::1)
As of this writing, the following options are allowed in Neighbor
Gont, et al. Expires April 25, 2014 [Page 14]
Internet-Draft ND Security Assessment October 2013
Advertisement messages:
o Target link-layer address
Other options present in a Neighbor Advertisement should be ignored.
The target link-layer address specifies the link-layer address of the
target of the Neighbor Advertisement. According to Section 4.4 of
[RFC4861], this option must be included in Neighbor Advertisements
when they are sent in response to neighbor solicitations sent to
multicast addresses (provided the link layer has addresses). A node
that receives a Neighbor Advertisement message in response to a
solicitation sent to a multicast address, without a target link-layer
address should silently drop the received message (provided that the
corresponding link layer has addresses).
Section 3.6.3 contains further validation checks that should be
performed on target link-layer address options.
3.5. Redirect message
Routers send Redirect packets to inform a host of a better first-hop
node on the path to a destination, or to inform a host that the
destination node is in fact a neighbor (i.e., it is attached to the
same link).
The following figure illustrates the syntax of the Redirect message:
Gont, et al. Expires April 25, 2014 [Page 15]
Internet-Draft ND Security Assessment October 2013
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: ICMPv6 Redirect message format
The Source Address of the IPv6 header is set to the link-local
address assigned to the interface from which the Redirect message is
sent. A node that receives a Redirect message should verify that the
Source Address of the IPv6 header is a link-local address. If the
packet does not pass this check, the Redirect message should be
silently dropped. The Source Address of a Redirect message must
correspond to the IPv6 address of the current first-hop router for
the specified ICMPv6 Destination Address (i.e., the IPv6 address
specified in the Destination Address field of the ICMPv6 Redirect
message). If the packet does not pass this check, it should be
silently dropped.
The Destination Address of the IPv6 header is set to the Source
Address of the packet that triggered the Redirect.
The Target Address specifies an IPv6 address that is a better first
hop to use for the IPv6 address specified in the Destination Address
field of the ICMPv6 header. If the Redirect message is meant to
indicate that a destination is in fact a neighbor (i.e., it is
attached to the same link), the Target Address is set to the same
Gont, et al. Expires April 25, 2014 [Page 16]
Internet-Draft ND Security Assessment October 2013
value as the Destination Address field of the ICMPv6 header.
When the Redirect indicates a first-hop router, the Target Address
must be a link-local address (that of the aforementioned 'better
first-hop router'). A node that receives a Redirect message in which
the Target Address and the Destination Address are different should
verify that the Target Address is a link-local address. If the
Redirect message does not pass this check, it should be silently
dropped.
Additionally, the following checks should be performed on the ICMPv6
Target Address and the ICMPv6 Destination Address:
1. They must not contain a multicast address
2. They must not contain the unspecified address (::)
3. They must not contain the loopback address (::1)
If a Redirect message does not pass this check, it should be dropped.
As of this writing, the following options are legitimate for the
Redirect message:
o Target link-layer address
o Redirected header
[RFC4861] specifies that the target-link layer address should be
included (if known) in Redirect messages, and that it must be
included for NBMA links that rely on the presence of the Target link-
layer address option to determine the link-layer address of
neighbors.
As explained in Section 8.3 of [RFC4861], if a Redirect message
contains a Target link-layer address option, the node processing the
redirect will create or update the Neighbor Cache entry for the
target. As a result, an attacker could exploit ICMPv6 Redirect
messages not only to maliciously update the Destination Cache of the
victim node, but also (or alternatively) to maliciously update its
Neighbor Cache.
The Redirected header option allows the sender of the Redirect
message to include a portion of the packet that triggered the
Redirect message. The Redirected header option is discussed in
Section 3.6.5.
Gont, et al. Expires April 25, 2014 [Page 17]
Internet-Draft ND Security Assessment October 2013
3.6. Neighbor Discovery Options
Neighbor Discovery messages can include a number of options. Such
options have the following general syntax:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Neighbor Discovery option format
The Type field is an 8-bit identifier of the type of option. As of
this writing, the following options have been specified:
+------+---------------------------+----------------------------+
| Type | Meaning | Summary |
+------+---------------------------+----------------------------+
| 1 | Source link-layer address | Discussed in Section 3.6.2 |
+------+---------------------------+----------------------------+
| 2 | Target link-layer address | Discussed in Section 3.6.3 |
+------+---------------------------+----------------------------+
| 3 | Prefix information | Discussed in Section 3.6.4 |
+------+---------------------------+----------------------------+
| 4 | Redirected header | Discussed in Section 3.6.5 |
+------+---------------------------+----------------------------+
| 5 | MTU | Discussed in Section 3.6.6 |
+------+---------------------------+----------------------------+
| 24 | Route Information | Discussed in Section 3.6.7 |
+------+---------------------------+----------------------------+
| 25 | Recursive DNS Server | Discussed in Section 3.6.8 |
+------+---------------------------+----------------------------+
| 31 | DNS Search List | Discussed in Section 3.6.9 |
+------+---------------------------+----------------------------+
Table 1: Neighbor Discovery options
The Length field specifies the length of the option in units of 8
octets. As stated in 4.6 of [RFC4861] a Length of 0 is invalid.
Nodes must silently discard Neighbor Discovery packets that contain
an option with a Length of 0.
Gont, et al. Expires April 25, 2014 [Page 18]
Internet-Draft ND Security Assessment October 2013
3.6.1. General issues with Neighbor Discovery options
The following subsections discuss security issues that apply to all
Neighbor Discovery options.
The proposed checks should be performed in addition to any option-
specific checks proposed in the next sections.
Processing requirements
Processing of Neighbor Discovery options consumes CPU resources at
the processing node. While the Hop Limit check of the IPv6 header
encapsulating a Neighbor Discovery message limits potential attackers
to those attached to the same link as the target node, there's still
the potential of an on-link system overwhelming a node by sending it
packets with a surprisingly large number of Neighbor Discovery
options.
To reduce the impact of these packets on the system performance, a
few counter-measures could be implemented:
o Rate-limit the number of Neighbor Discovery packets that are
processed by the system.
o Enforce a limit on the maximum number of options to be accepted in
any Neighbor Discovery message.
The first check avoids a large number of Neighbor Discovery packets
to overwhelm the system in question. The second check avoids packets
with multiple Neighbor Discovery options to affect the performance of
the system.
Most implementations fail to rate-limit ND packets, and hence have
been found vulnerable to the aforementioned issue (see e.g.
[CVE-2011-2391]).
Option Length
The Length field specifies the length of the option in units of 8
octets. As stated in 4.6 of [RFC4861] a Length of 0 is invalid.
Nodes must silently discard Neighbor Discovery packets that contain
an option with a Length of 0. This check prevents, among other
things, loops in option processing that may arise from incorrect
option lengths.
Additionally, while the Length byte of a Neighbor Discovery option
allows for an option length of up to 2040 octets (255 * 8 octets),
there is a limit on legitimate option length imposed by the syntax of
Gont, et al. Expires April 25, 2014 [Page 19]
Internet-Draft ND Security Assessment October 2013
the IPv6 header.
For all Neighbor Discovery options, the following check should be
enforced:
option-offset + Length * 8 - MIN_IPV6_HEADER <= Payload Length
Where
option-offset is the offset of the first byte of the option within
the IPv6 packet (with the first octet of the IPv6 header having an
'offset' of 0). Length is the Length field of the Neighbor Discovery
option being processed. MIN_IPV6_HEADER is the size of the fixed
IPv6 header. That is, 40 octets. Payload Length is the header field
from the IPv6 header encapsulating the Neighbor Discovery message.
If a Neighbor Discovery option does not pass this check, the
corresponding Neighbor Discovery message should be silently dropped.
The aforementioned check is meant to detect forged option-length
values that might make an option illegitimately exceed the actual
length of the IPv6 packet encapsulating the Neighbor Discovery
message.
3.6.2. Source Link-Layer Address Option
The Source link-layer address option contains the link-layer address
of the sender of the packet. It is used by Neighbor Solicitation,
Router Solicitation, and Router Advertisement messages.
The following figure illustrates the syntax of the source link-layer
address:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: ND Source link-layer address option
The Type field is set to 1. The Length field specifies the length of
the option (including the Type and Length octets) in units of 8
octets. A node that receives an ICMPv6 message with this option
should verify that the Length field is valid for the underlying link
layer. For example, for IEEE 802 addresses the Length field must be
1 [RFC2464]. If the packet does not pass this check, it should be
Gont, et al. Expires April 25, 2014 [Page 20]
Internet-Draft ND Security Assessment October 2013
silently dropped.
The Link-Layer Address field contains the link-layer address. The
length, contents, and format of this field varies from one link layer
to another, and is specified in specific documents that describes how
IPv6 operates over different link layers.
A number of validation checks should be performed on the Link-Layer
Address. In the case of IEEE 802 addresses, it should not contain a
broadcast or multicast address. If the option does not pass this
check, the Neighbor Discovery message carrying the option should be
discarded.
Additionally, nodes should not allow the source link-layer address to
contain one of the receiving node's link-layer addresses. If the
option does not pass this check, the Neighbor Discovery message
carrying the option should be discarded.
The source link-layer address option could be exploited for the
purpose of 'Neighbor Cache poisoning', that is, to cause traffic
meant for a specific IPv6 address to be illegitimately directed to
the node whose link-layer address is specified by the Link-Layer
Address field.
This is similar to the ARP cache poisoning attacks in IPv4.
A possible counter-measure for Neighbor Cache poisoning attacks would
be to override the link-layer address stored in the Neighbor Cache
only after Neighbor Unreachability Detection (NUD) finds the neighbor
to be unreachable and the corresponding entry is removed. This is
clearly a trade-off between responsiveness and resiliency.
In some network scenarios it may be possible and desirable to
configure static Neighbor Cache entries, such that Neighbor Discovery
need not be performed for the corresponding IPv6 addresses.
Some implementations have been found to inadvertently override static
entries when they receive source link-layer address options or target
link-layer address options in Neighbor Discovery messages
[Hogg-Vyncke] [Lecigne-Neville-Neil].
If source link-layer address options were allowed to contain
broadcast (e.g., the IEEE 802 'ff:ff:ff:ff:ff:ff' address) or
multicast (e.g., the IEEE 802 '33:33:00:00:00:01' address) addresses,
traffic directed to the corresponding IPv6 address would be sent to
the broadcast or multicast address specified in the source link-layer
option. This could have multiple implications:
Gont, et al. Expires April 25, 2014 [Page 21]
Internet-Draft ND Security Assessment October 2013
It would have a negative impact on the performance of the nodes
attached to the network and on the network itself, as packets sent to
these addresses would need to be delivered to multiple nodes (and
processed by them) unnecessarily.
An attacker could capture network traffic sent to the corresponding
IPv6 address, as the corresponding packets would be delivered to all
(in the case of broadcast) or multiple (in the case of multicast)
nodes.
Packets could result in forwarding loops at routers, as a router
forwarding a packet to the corresponding address would receive itself
a copy of the forwarded packet, thus resulting in a forwarding loop.
The loop would end only when the Hop Limit is eventually decremented
to 0. If multiple routers are present on the same link, the problem
is further exacerbated. Section 6.1.10 of this document contains
further analysis of this vulnerability.
[Lecigne-Neville-Neil] reports that at least some versions of FreeBSD
are vulnerable to these issues.
3.6.3. Target Link-Layer Address Option
The Target link-layer address option contains the link-layer address
of the Target of the packet. It is used by Neighbor Advertisement
and Redirect messages.
The following figure illustrates the syntax of the Target link-layer
address:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: ND Target link-layer address option format
The Type field is set to 2. The Length field specifies the length of
the option (including the Type and Length octets) in units of 8
octets. A node that receives an ICMPv6 message with this option
should verify that the Length field is valid for the underlying link-
layer. For example, for IEEE 802 addresses the Length field must be
1 [RFC2464]. If the packet does not pass this check, it should be
silently dropped.
The Link-Layer Address field contains the link-layer address. The
Gont, et al. Expires April 25, 2014 [Page 22]
Internet-Draft ND Security Assessment October 2013
length, contents, and format of this field varies from one link layer
to another, and is specified in specific documents that describes how
IPv6 operates over different link layers.
The target link-layer address has the same security implications as
the source link-layer address. Therefore, the same considerations
apply, and the same validation checks should be performed as for the
source link-layer address (see Section 3.6.2).
3.6.4. Prefix Information
The Prefix Information option is used by routers to provide hosts
with on-link prefixes and prefixes for Address Auto-configuration.
It may only appear in Router Advertisement messages and should be
silently ignored in any other messages [RFC4861].
The following figure illustrates the syntax of the Prefix Information
option:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: ND Prefix Information option format
The Type field is set to 3. The Length field is set to 4 by the
sender. A node processing a Prefix Information option should verify
that the Length field is 4. If the option does not pass this check,
the option should be ignored.
The Prefix Length is an 8-bit unsigned integer that specifies the
Gont, et al. Expires April 25, 2014 [Page 23]
Internet-Draft ND Security Assessment October 2013
prefix length, that is, the number of leading bits in the Prefix
field that are valid.
The following sanity check should be applied on the Prefix Length
field:
Prefix Length >= 32
If the Prefix Length field does not pass this checks, the Prefix
Information option should be discarded.
The L bit is a 1-bit flag that, when set, states that the prefix can
be used for on-link determination. The A bit is a 1-bit autonomous
address-configuration flag that indicates whether this prefix can be
used for autonomous address configuration. The R flag is specified
by [RFC6275], and indicates that the Prefix field contains a complete
IPv6 address assigned to the sending router. The Reserved1 field is
a 6-bit unused field that is set to zero by the sender and must be
ignored by the receiver.
The Valid Lifetime field is a 32-bit unsigned integer that specifies
the amount of time (in seconds) this prefix can be used for on-link
determination (with a value of 0xffffffff representing 'infinity').
We recommend hosts to sanitize the Valid Lifetime as follows:
SanitizedVL = max(Valid Lifetime, MIN_VALID_LIFETIME)
Where SanitizedVL is the sanitized 'Valid Lifetime', and
MIN_VALID_LIFETIME is set to 1800 (seconds).
The value of 1800 seconds for MIN_VALID_LIFETIME has been selected to
coincide with the lower limit enforced on the Router Lifetime
(MIN_ROUTER_LIFETIME).
The Preferred Lifetime is a 32-bit unsigned integer that specifies
the length of time (in seconds) that addresses generated from this
prefix via stateless address auto-configuration (SLAAC) should remain
'preferred' (with a value of 0xffffffff representing 'infinity').
As noted in [RFC4861] the Preferred Lifetime must be smaller than or
equal to the Valid Lifetime to avoid preferring addresses that are no
longer valid. Therefore, a node processing a Prefix Information
option should perform the following check:
Preferred Lifetime <= Valid Lifetime
If the option does not pass this check, it should be silently
ignored.
Gont, et al. Expires April 25, 2014 [Page 24]
Internet-Draft ND Security Assessment October 2013
The Reserved2 is a 32-bit unused field that is set to zero by the
sender and must be ignored by the receiver.
The Prefix field contains an IPv6 address or a prefix of an IPv6
address.
The Prefix Length contains the number of leading bits in the prefix
that are to be considered valid. The remaining bits in the Prefix
field are set to zero by the sender and must be ignored by the
receiver.
As stated in Section 4.6.2 of [RFC4861], routers should not send a
Prefix Information option for the link-local prefix. Therefore, a
node should verify that the Prefix does not contain the link-local
prefix. If the option does not pass this check, it should be
silently dropped.
Additionally, a node should verify that the Prefix does not contain a
multicast IPv6 prefix. If the option does not pass this check, it
should be silently dropped.
An attacker could exploit the Prefix information option to perform a
Denial-of-Service attack, by sending a large number of Router
Advertisements with the Prefix Information options that have the A
bit set, therefore advising the receiving systems to configure an
IPv6 address with each of these prefixes. If an implementation does
not enforce a limit on the number of addresses they configure in
response to Router Advertisements, the aforementioned attack might
result in buffer overflows or kernel memory exhaustion.
[CVE-2010-4669] is one vulnerability report about the
aforementioned issue.
We recommend hosts to default to a maximum number of configured
addresses (for each interface) of 16.
This limits is already being enforced by a number of implementations,
such as OpenBSD 4.2.
On the other hand, Windows XP SP2 and FreeBSD 9.0 fail to enforce
limits on the maximum number of configured addresses, and therefore
are vulnerable to a Denial of Service attack.
Even if hosts do enforce a limit on the number of IPv6 addresses
configured, an attacker might try to cause victim hosts to ignore
legitimate prefixes previously advertised for address configuration
by legitimate routers. Hereby we recommend hosts to not discard
previously configured addresses if new prefixes for address auto-
Gont, et al. Expires April 25, 2014 [Page 25]
Internet-Draft ND Security Assessment October 2013
configuration are advertised and the limit for the maximum number of
configured addresses (per interface) has been reached. When such
limit is hit, the newly advertised prefixes for address auto-
configuration should be ignored.
Section 3.6.4 describes how an attacker could exploit the Prefix
Information option for the purpose of traffic hijacking.
3.6.5. Redirected Header Option
The Redirected Header option is used in Redirect messages to convey
all or part of the packet that is being redirected. It must be
silently ignored for all other messages.
The following figure illustrates the syntax of the Redirected Header
option:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IP header + data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: ND Redirected Header option format
The Type field is 4. The Length field specifies the option size
(including the Type and Length fields) in units of 8 octets.
Assuming the Redirected Header option will contain at least the
mandatory fields of the option (8 bytes), the fixed IPv6 header (40
bytes), and the first 8 bytes of the transport protocol header, the
following validation check should be performed:
Length >= 7
If the option does not pass this check, the corresponding Redirect
Message should be silently ignored.
As the option is meant to contain as much of the Redirected packet
without exceeding the minimum IPv6 MTU, and the minimum IPv6 MTU is
1280 octets, this is a sensible requirement to enforce.
Gont, et al. Expires April 25, 2014 [Page 26]
Internet-Draft ND Security Assessment October 2013
3.6.6. MTU Option
The MTU option is used in Router Advertisement messages to ensure
that all nodes on a link use the same MTU value in those scenarios in
which heterogeneous technologies are bridged together. This option
must be silently ignored for other Neighbor Discovery messages.
The following figure illustrates the syntax of the MTU option:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: ND MTU option format
The Type field identifies the kind of option and is set to 5. This
option has a fixed Length that is 1. Therefore, the following sanity
check should be performed:
Length == 1
If the option does not pass this check it, should be ignored.
The Reserved field is a 16-bit unused field that is set to 0 by the
sender and should be ignored by the receiver.
The MTU field is a 32-bit unsigned integer that specifies the MTU
value that should be used for this link. [RFC2460] specifies that
the minimum IPv6 MTU is 1280 octets. Therefore, a node processing a
MTU option should perform the following check:
MTU >= MINIMUM_IPV6_MTU
where MINIMUM_IPV6_MTU is a variable that should be set to 1280.
If the option does not pass this check, it should be silently
ignored.
It has been reported that some link layers do not support a minimum
MTU of 1280 bytes. Therefore, implementations should provide the
means to change the default value of the MINIMUM_IPV6_MTU variable.
Additionally, the advertised MTU should not exceed the maximum MTU
Gont, et al. Expires April 25, 2014 [Page 27]
Internet-Draft ND Security Assessment October 2013
specified in the link-type-specific document (e.g., [RFC2464] for
Ethernet networks). Therefore, a node processing a MTU option should
perform the following check:
MTU <= MAX_LINK_MTU
where MAX_LINK_MTU is a variable that should be set according to the
maximum link MTU specified in the link-type-specific document (e.g.,
[RFC2464] for Ethernet).
If the option does not pass this check, it should be silently
ignored.
The MTU option could be potentially exploited by an attacker to
perform a Denial-of-Service (DoS) or a performance-degrading attack
against the systems in a local network. In order to perform this
attack, an attacker would forge a Router Advertisement that includes
an MTU option with a very small (possibly zero) value. The impact of
this attack would be the same as the 'Blind performance-degrading
attack' described in Section 15.7 of [CPNI-TCP].
3.6.7. Route Information Option
The Route Information option is used to convey more-specific routes
in Router Advertisement messages. The following figure illustrates
the syntax of the Router Information option:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |Resvd|Prf|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (Variable Length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: ND Route Information option format
The Type field identifies the type of option and is set to 24. The
Length field contains the length of the option (including the Type
and Length fields) in units of 8 octets. The following sanity checks
should be performed on these Length field:
(Length >=1) && (Length <=3)
Gont, et al. Expires April 25, 2014 [Page 28]
Internet-Draft ND Security Assessment October 2013
If the option does not pass this check, it should be ignored.
An option Length of 1 octet allows the specification of prefixes with
a length of 0 (i.e., /0), while an option Length of 3 allows the
specification of prefixes of up to 128 bits (i.e., /128).
The Prefix Length field indicates the number of leading bits in the
Prefix field that are valid. The Length field and the Prefix Length
field are closely related, as the Length field constrains the
possible values of the Prefix Length field.
The following sanity check should be enforced on the Prefix Length
field:
Prefix Length <= (Length - 1) * 64
If the option does not pass this check, it should be ignored.
Both of the Rsvd fields are set to zero by the sender of the message,
and should be ignored by the receiver. The Prf field specifies the
'Preference' of this route. As specified by RFC 4191, if the Prf
field contains the value of '10' ('Reserved'), the option should be
ignored.
The Route Lifetime field specifies the length of time, in seconds,
that the prefix is valid for route determination. While not required
by RFC 4191, we recommend hosts to perform the following sanity check
on the Route Lifetime field:
SanitizedRL = min( max(Route Lifetime, MIN_ROUTE_LIFETIME),
MAX_ROUTE_LIFETIME)
Where MIN_ROUTE_LIFETIME is set to 1800 seconds and
MAX_ROUTE_LIFETIME is set to 9000 seconds.
These values have been selected according to the upper and lower
limits described in Section 3.2 ('Router Advertisement') of this
document for the Router Lifetime field of Router Advertisements.
The Prefix field contains the actual IPv6 prefix that, together with
the Prefix Length field, identifies the route. A number of sanity
checks should be enforced on the Prefix field. For example, the
Prefix should neither contain a link-local unicast prefix (e.g.,
fe80::/10, fe80::/64, etc.) nor a link-local multicast prefix (e.g.,
ff02::0/64).
The Route information option has a number of security implications.
Firstly, an attacker could forge Router Advertisements with a higher
Gont, et al. Expires April 25, 2014 [Page 29]
Internet-Draft ND Security Assessment October 2013
'preference' value (Prf), thus overriding the existing default
routers at the attacked system. Secondly, an attacker could exploit
this option to implant more specific routes to a victim prefix at the
attacked system, thus overriding the existing routes for that victim
prefix. Thirdly, an attacker could cause an existing route to a
victim prefix to be removed from the routing table of the attacked
host, by forging a Route Information option that contains a Route
Lifetime of 0 (or some other small value). Fourthly, if an
implementation does not enforce limits on the size of the Destination
Cache, an attacker could possibly exhaust the kernel memory or CPU
cycles of that system by forging a large number of Route Information
options (possibly in many different Router Advertisements), such that
the attacked system consumes its kernel memory and/or its CPU time to
install those routes (see e.g. [CVE-2012-notyet]).
A general mitigation for the security implications of Router
Advertisements that can be applied when the protocols are deployed is
to restrict which ports of a managed switch can send Router
Advertisement messages. That is, Router Advertisements received on
all other ports of the switch would be discarded. This mechanism is
commonly-known as Router Advertisement Guard (RA-Guard) [RFC6104]
[RFC6105] [I-D.ietf-v6ops-ra-guard-implementation].
We recommend hosts to not simply discard a default router entry when
a Router Preference with a higher Prf value is received. In
particular, default routers that are known to be working should not
be discarded when such Router Advertisements are received.
This means that the higher-priority router would override the
existing default router, but the latter would still be kept in the
"default routers list", such that if the newly-learned router is
found to be non-working, the existing (lower-priority) router
could still be employed).
We recommend hosts to enforce a lower limit Prefix Length in the
Route Information options. This would prevent an attacker from
overriding the default routers by including, e.g., one Route
Information option for the prefix ::/1 and one Route Information
option for the prefix 8000::/1. We recommend hosts to enforce a
minimum Prefix Length of 32. Hosts may also enforce an upper limit
on the Prefix Length, such that an attacker cannot easily redirect
traffic to specific site. A possible upper limit for the Prefix
Length would be 64. As discussed earlier in this Section, the Route
Lifetime value should be sanitized, and a route entry should not
simply be discarded when a Route Information option with a Route
Lifetime of 0 is received.
Finally, hosts should enforce a limit on the maximum number of
Gont, et al. Expires April 25, 2014 [Page 30]
Internet-Draft ND Security Assessment October 2013
entries in the Destination Cache.
3.6.8. Recursive DNS Server Option
The Recursive DNS Server (RDNSS) option provides a mechanism for
routers to advertise the IPv6 addresses of one or more Recursive DNS
Servers. This option is specified in [RFC6106]. The following
figure illustrates the syntax of the RDNSS options:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Addresses of IPv6 Recursive DNS Servers :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: ND Recursive DNS Server option format
The Type field identifies must be 25. The Length field specifies the
length of the option (including the Type and Length fields) in units
of 8 octets. The following sanity checks should be performed on the
Length field:
Length >= 3
If the option does not pass this check, it should be ignored.
This sanity check requires a RDNSS option to contain the IPv6 address
of at least one Recursive DNS Server.
Additionally, the following sanity check should be performed:
(Length -1) % 2 == 0
If the option does not pass this check, it should be silently
ignored.
As an IPv6 address consists of 16 bytes, each IPv6 address that is
included in the option should increment the minimum option length by
2.
The Reserved field is set to zero by the sender, and must be ignored
Gont, et al. Expires April 25, 2014 [Page 31]
Internet-Draft ND Security Assessment October 2013
by the receiver. The Lifetime field specifies the maximum time in
seconds that a node may use the IPv6 addresses included in the option
for name resolution, with a value of 0 indicating that they can no
longer be used. As specified in [RFC6106], the following sanity
checks should be performed on the Lifetime field:
Lifetime >= 1800
Lifetime <= 3600
[RFC6106] specifies these sanity checks as MaxRtrAdvInterval <=
Lifetime <= 2*MaxRtrAdvInterval.
If the Lifetime field does not pass this check, the option should be
ignored.
Failure to enforce a lower limit on the Lifetime value could allow an
attacker to 'disable' a Recursive DNS Server at a target system, by
forging a Router Advertisement with a RDNSS option that includes the
IPv6 address of such DNS Server, and a Lifetime of 0 (or some other
small value). This would cause the receiving system to remove such
RDNSS address from the list of Recursive DNS Servers. However, it
should be noted that this represents a trade-off of responsiveness
vs. resiliency.
Sanity checks should be performed on the IPv6 addresses that are
included in the RDNSS option. For example, nodes should check that
the IPv6 addresses included in the RDNSS option are not multicast
addresses. If any of the addresses in the RDNSS option does not pass
this check, it should be silently dropped.
Nodes should enforce a limit on the number of IPv6 addresses they
include in the local list of Recursive DNS Servers. An arbitrary
limit could be to allow a maximum of 16 IPv6 addresses in the list of
Recursive DNS Servers.
The value 16 is somewhat arbitrary. It has been chosen to be the
same as the limit on the maximum number of default routes that many
systems (such as OpenBSD 4.2) already enforce.
Failure to enforce limits on the maximum number of Recursive DNS
Servers could probably allow an attacker to exhaust the system memory
by crafting multiple Router Advertisements that advertise a large
number of IPv6 addresses in RDNSS options.
It should also be clear that if an attacker is able to advertise a
malicious Recursive DNS Server to victim nodes, he could perform a
Gont, et al. Expires April 25, 2014 [Page 32]
Internet-Draft ND Security Assessment October 2013
variety of attacks against the victim nodes (DoS, Man-in-the-Middle.
Etc.).
3.6.9. DNS Search List
The Recursive DNS Server (RDNSS) option provides a mechanism for
routers to advertise the IPv6 addresses of one or more Recursive DNS
Servers. This option is specified in [RFC6106]. The following
figure illustrates the syntax of the RDNSS options:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Domain Names of DNS Search List :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: V
XXX (PLACEHOLDER): Need to complete the security assessment of this
option.
Gont, et al. Expires April 25, 2014 [Page 33]
Internet-Draft ND Security Assessment October 2013
4. Router and Prefix Discovery
4.1. Router Specification
Section 6.2 of [RFC4861] contains the Router specification for Router
and Prefix Discovery.
Section 6.2.6 ('Processing Router Solicitations') of [RFC4861] states
that if a router receives a Router Solicitation message, and 'the
router already has a Neighbor Cache entry for the solicitation's
sender, the solicitation contains a Source Link-Layer Address option,
and the received link-layer address differs from that already in the
cache, then the link-layer address SHOULD be updated in the
appropriate Neighbor Cache entry'. As a result, an attacker might
forge a Router solicitation message with a forged source link-layer
address, thus causing all traffic meant from the attacked router to
the (forged) Source Address of the Router Advertisement to be sent to
the link-layer address advertised in the forged source link-layer
address option.
Section 6.2.6 of [RFC4861] further states that 'Whether or not a
Source Link-Layer Address option is provided, if a Neighbor Cache
entry for the solicitation's sender exists (or is created) the
entry's IsRouter flag MUST be set to FALSE'. As a result, in a
network scenario in which there are two routers ('A' and 'B') on the
same link, and an attacker is directly attached to that link, an
attacker could send a Router Solicitation to one of the routers
(Router A) forging the Source Address to be that of the other router
(Router B). As a result, the target router (Router A) would set the
IsRouter flag of the Neighbor Cache entry corresponding to the IPv6
address of Router B (the forged Source Address of the Router
Solicitation message) to FALSE, and as a result, Router B would be
eliminated from the Default router list of Router A.
One interesting aspect about this attack is that while some devices
might be filtering e.g. Router Advertisements, they might not be
filtering Router Solicitation messages, and thus this attack might
still be effective.
4.2. Host Specification
Section 6.3.4 of [RFC4861] states that when a Router Advertisement is
received that communicates information for a specific parameter
(e.g., link MTU) that differs from information received in previous
Router Advertisements, the most recently received information is
considered authoritative.
While this requirement guarantees that the relevant information can
Gont, et al. Expires April 25, 2014 [Page 34]
Internet-Draft ND Security Assessment October 2013
be updated in a timely fashion, it also guarantees that an attacker
connected to the local link always has the chance to maliciously
override the values of parameters previously learned from Router
Advertisements.
Section 6.3.4 of [RFC4861] states that 'to limit the storage needed
for the Default Router List, a host MAY choose not to store all of
the router addresses discovered via advertisements'. Here we
strongly advise hosts to enforce a limit on the maximum number of
entries in the Default Router List. A possible (somewhat arbitrary)
limit for the maximum number of entries in the Default Router list
would be 16.
Section 6.3.4 of [RFC4861] states that 'If the received Cur Hop Limit
value is non-zero, the host SHOULD set its CurHopLimit variable to
the received value'. Here we strongly advise that the received Cur
Hop Limit is sanitized as described in Section 3.2 of this document.
Section 6.3.4 of [RFC4861] states that 'The RetransTimer variable
SHOULD be copied from the Retrans Timer field, if the received value
is non-zero'. Here we strongly advise that the received Retrans
Timer is sanitized as described in Section 3.2 of this document.
Honouring very small Retrans Timer values could lead the system to
flood the network with Neighbor Advertisements.
With respect to the processing of received MTU options, Section 6.3.4
of [RFC4861] correctly states that the received option should be
honoured as long as the received value is within the expected limits.
Section 3.6.6 of this document discusses a number of checks that
should be performed on received MTU options.
Section 6.3.4 of [RFC4861] states that 'The only way to cancel a
previous on-link indication is to advertise that prefix with the
L-bit set and the Lifetime set to zero'. This means that if an
attacker forges a Router Advertisement that advertises a 'victim'
prefix as being on-link, such prefix will usually be considered 'on-
link' for the advertised Lifetime period of time ('forever' if
Lifetime was set to 0xffffffff).
Gont, et al. Expires April 25, 2014 [Page 35]
Internet-Draft ND Security Assessment October 2013
5. Address Resolution
In the case of broadcast link-layer technologies, in order for a
system to transfer an IPv6 datagram, it must first map an IPv6
address to the corresponding link-layer address via Neighbor
Solicitation/Advertisement messages.
While this operation is being performed, the packets that require
such a mapping would need to be kept in memory. This may happen both
in the case of hosts and in the case of routers.
The possible implementation approach of keeping those datagrams in
memory while the mapping operation is being performed is mentioned in
Section 5.2 of [RFC4861].
This situation might be exploited by an attacker to perform a Denial-
of-Service (DoS) attack against an IPv6 router, by sending a large
number of packets to a non-existent node that would supposedly be a
neighbor to the attacked router. While trying to map the
corresponding IPv6 address into a link-layer address, the attacked
router would keep in memory all the packets that would depend on that
address resolution operation in order to be forwarded to the intended
destination. At the point in which the mapping function times out,
the node would typically drop all the packets that were queued
waiting for that address resolution operation to complete.
Depending on the timeout value for the mapping function this
situation might result in the attacked router running out of memory,
with the consequence that incoming legitimate packets would have to
be dropped, or that legitimate packets already stored in the router's
memory buffers might need to be dropped. Both of these situations
would lead either to a complete Denial of Service or to a degradation
of the network service.
A number of countermeasures are warranted for this vulnerability:
Firstly, nodes should enforce a limit on the maximum number of
packets that are queued for the same destination address while the
corresponding address resolution operation is being performed.
Additionally, nodes should enforce a limit on the aggregate number of
packets that are queued waiting for address resolution operations to
complete.
At the point the mapping function times out, all the packets destined
to the address that timed out should be discarded. In addition, a
'negative cache entry' might be kept in the module performing the
matching function, so that for some amount of time the mapping
function would return an error when the IPv6 module requests
Gont, et al. Expires April 25, 2014 [Page 36]
Internet-Draft ND Security Assessment October 2013
resolution of some IPv6 address for which the mapping has recently
failed (i.e., timed out).
A proactive mitigation for this vulnerability would be that when a
packet is received that requires an address resolution operation
before the packet can be forwarded, the packet is dropped and the
router is then engaged in the address resolution operation.
This is a common implementation strategy for IPv4 routers. In IPv4,
it is common that when a packet is received that requires an ARP
request to be performed (before the packet can be forwarded), the
packet is dropped and the router is then engaged in the ARP
procedure.
While similar issues exist in IPv4 networks, this problem is
exacerbated in IPv6, as IPv6 subnets are typically much larger than
their IPv4 counterparts. Therefore, an attacker could send a large
number of packets, each destined to different IPv6 addresses
corresponding to non-existent 'neighbor nodes' of the attacked
router. In the event that the router implementation drops packets
only when the address resolution operation times out, the DoS
condition might persist, whereas it would have probably disappeared
if all the malicious packets had been destined to the same IPv6
address.
That is, if all the attack packets had been destined to the same IPv6
address, the timeout of the address resolution operation for that
IPv6 address could have resulted in all the attack packets to be
dropped.
An attacker could also potentially perform a Denial-of-Service attack
against a router by exhausting the number of entries in the Neighbor
cache and/or the Destination cache. In order to perform this attack,
an attacker would send a large number of packets, each destined to
different IPv6 addresses corresponding to non-existent 'neighbor
nodes' of the attacked router. Each of these attack packets would
trigger an address-resolution operation at the attacked router. If
the target router does not enforce any limits on the maximum number
of entries in the Neighbor cache, this attack could result in a
buffer overflow at the attacked router. On the other hand, if the
router does enforce limits on the maximum number of entries in the
neighbor cache, the packets sent by the attacker could result in the
attacked router hitting the aforementioned limit, probably preventing
legitimate entries to be added to the Neighbor cache, resulting in a
Denial of Service to the corresponding nodes.
This situation has been experienced in production networks probably
as a result of reconnaissance activity by attackers. That is, this
Gont, et al. Expires April 25, 2014 [Page 37]
Internet-Draft ND Security Assessment October 2013
situation could not only indicate a deliberate Denial-of-Service
attack against a router, but could also be side-effect of network
reconnaissance (i.e., 'scanning') activities.
A number of mitigations are warranted for this vulnerability:
o Nodes should enforce a limit on the number of entries in the
Neighbor cache.
o Nodes should implement an algorithm to reclaim Neighbor Cache
entries when the limit on the number of entries is reached.
o Nodes should enforce a limit on the number of entries in the
Neighbor Cache that have a reachability state of 'INCOMPLETE'.
This limit should be much stricter than the general limit on the
number of entries in the Neighbor Cache.
o Nodes should enforce a limit on the number of entries in the
Destination cache.
o Nodes should implement an algorithm to reclaim Destination Cache
entries when the limit on the maximum number of entries is
reached.
Section 5.3 of [RFC4861] states that for the purpose of eliminating
unused entries (i.e., garbage-collection) in the Neighbor cache, any
Least Recently Used (LRU)-based policy that only reclaims entries
that have not been used in some time should be adequate. Such LRU-
based policy should also be enforced to reclaim entries in the
Neighbor cache or the Destination Cache when the limit on the maximum
number of entries is hit for the Neighbor cache or the Destination
cache, respectively.
5.1. Interface initialization
As explained in Section 7.2.1 of [RFC4861], when a multicast-capable
interface is enabled, the node must join the all-nodes multicast
group on that interface, and the solicited-node multicast address
corresponding to each of the addresses assigned to an interface. As
discussed in the same section, nodes join and leave the solicited-
node groups as the assigned addresses change over time.
As the solicited-node multicast address for a number of assigned
addresses might be the same, nodes should ensure that a solicited-
node multicast group is not left until all the addresses
corresponding to that solicited-node group have been removed.
An implementation that incorrectly leaves a solicited-node multicast
Gont, et al. Expires April 25, 2014 [Page 38]
Internet-Draft ND Security Assessment October 2013
group while there are addresses corresponding to that multicast group
still in use might be subject of a Denial-of-Service attack (from a
malicious node attached to the same link as the victim).
In order to perform such an attack, an attacker would first send an
unsolicited Router Advertisement, announcing a prefix such that the
victim node configures an address whose solicited-node multicast
group is the same as some legitimately-configured address. The
advertised prefix would have a Lifetime value that would cause the
address to be removed in the short term. If the Neighbor Discovery
implementation of the victim system does not ensure that a solicited-
node multicast group is left only when the last address corresponding
to that solicited-node multicast group is removed, the victim might
incorrectly leave the aforementioned solicited-node multicast group.
As a result, the victim system would be unable to respond to Neighbor
Solicitation messages for the target address, and therefore the
aforementioned address would become unreachable.
5.2. Receipt of Neighbor Solicitation messages
As stated in Section 7.2.3, if a Neighbor Solicitation is received
and an entry already exists in the Neighbor Cache for the IPv6 Source
Address of the solicitation with a cached link-layer address that is
different from the one in the received Source Link-Layer option, the
cached address should be replaced by the received address (and the
entry's reachability state must be set to STALE).
If an entry does not exist for the corresponding Target Address, a
new entry is added to the Neighbor Cache, and its reachability state
is set to STALE.
While this allows for improved responsiveness in the event the link-
layer address corresponding to an IPv6 address changes, it also means
that an attacker could easily override the mapping from IPv6 address
to link-layer address.
An attacker attached to the same link as the victim system could
craft a Neighbor Solicitation message with a forged IPv6 Source
Address, and send it to the victim system, thus illegitimately
causing the victim to update its Neighbor Cache. The attacker could
then send a Neighbor Advertisement with the Solicited flag set, thus
causing the reachability state of the neighbor cache entry to be set
to REACHABLE.
As a result, the attacker could cause traffic meant from the victim
to the forged IPv6 address to be directed to any local system (i.e.,
attached to the same network link).
Gont, et al. Expires April 25, 2014 [Page 39]
Internet-Draft ND Security Assessment October 2013
6. Vulnerability analysis
This section summarizes the security implications that arise from the
Neighbor Discovery mechanisms in IPv6. The following vulnerabilities
have been identified:
o Denial of Service: communication is prevented between legitimate
nodes
o Performance-degrading: the performance of communication between
legitimate nodes is reduced
o Traffic hijacking: traffic is illegitimately redirected to a node
operated by an attacker
[RFC3756] provides a good security assessment of the Neighbor
Discovery mechanisms. The following subs-sections summarize the
results in [RFC3756], and also identify new vulnerabilities and
specific attack vectors not present in that document.
Some of the vulnerabilities discussed in the following sub-sections
involve an attacker sending Router Advertisement messages. [RFC6104]
analyzes the problem of Rogue IPv6 Router Advertisements, and discuss
a number of possible solutions. [RFC6105] discusses a specific
solution to this problem based on layer-2 filtering, known as 'RA-
Guard'. However, as discussed in
[I-D.ietf-v6ops-ra-guard-implementation], some popular RA-Guard
implementations can be easily circumvented by leveraging IPv6
extension headers.
[SI6-Toolkit] is a complete complete IPv6 toolkit that can be
employed to exploit all the vulnerabilities discussed in the
following subsections. [THC-IPv6] includes 'proof of concept' tools
of some of the vulnerabilities discussed in the following
subsections. [vanHauser2006] is a presentation about this tool set.
[Beck2007b] analyzes the use of Neighbor Discovery for Operating
System detection. However, the results seem to indicate that
Neighbor Discovery is not an attractive means for Operating System
detection when compared to other techniques such as those described
in [CPNI-TCP]. Therefore, the 'information leakage' resulting from
Neighbor Discovery, while possible, is not included in the threat
analysis present in the following subsections.
6.1. Denial of Service
Gont, et al. Expires April 25, 2014 [Page 40]
Internet-Draft ND Security Assessment October 2013
6.1.1. Neighbor Cache poisoning
Router Solicitation, Router Advertisement, Neighbor Solicitation and
Neighbor Advertisement messages can be exploited to maliciously
poison the Neighbor Cache of a victim node such that an IPv6 address
maps into a non-existent link-layer address. As a result, traffic
meant to the victim address would be 'black-holed' as a result of
sending it to a non-existent link-layer address.
In the case of Router Solicitation, Router Advertisement, and
Neighbor Solicitation messages, a source link-layer address would be
employed. In the case of Neighbor Advertisement messages, a target
link-layer address would be used instead.
In order for an attacker to successfully perform this attack, he
would need to be attached to the same network link to which the
target node is attached, or control a node attached to that network
link (e.g., compromise such a node). However, it could be possible
that as a result of tunnelling mechanisms, an attacker could perform
these attacks remotely.
This attack could be mitigated by not overwriting the link-layer
address of an existing Neighbor Cache entry when a source link-layer
address option or a target link-layer address option is received.
The mapping of IPv6 address to link-layer address would be updated
only if Neighbor Unreachability Detection (NUD) first removes the
corresponding Neighbor Cache entry, and then a Neighbor Discovery
message updates the mapping.
Furthermore, some monitoring tools exist that detect some possible
exploitation of Neighbor Discovery and Neighbor Advertisement
messages. NDPMon [NDPMon] is an example of such a monitoring tool
(which is similar to the IPv4 arpwatch tool [arpwatch]). [Beck2007]
is a paper about the aforementioned tool.
6.1.2. Tampering with Duplicate Address Detection (DAD)
The Duplicate Address Detection (DAD) mechanism is used to ensure
that a node does configure for itself an address that is already in
use.
An attacker could simply listen to Neighbor Solicitations sent as
part of the DAD mechanism, and respond with crafted Neighbor
Advertisements, thus causing the victim node to consider the address
to be already in use, and thus preventing it from configuring the
address for future use.
Additionally, an attacker could respond to Neighbor Solicitations
Gont, et al. Expires April 25, 2014 [Page 41]
Internet-Draft ND Security Assessment October 2013
sent as part of the DAD mechanism with a Neighbor Solicitation for
the same IPv6 address. The legitimate node performing DAD would
consider this a collision and would cease to solicit that address
(and possibly select and perform DAD for some alternative address).
In order for an attacker to successfully perform this attack, he
would need to be attached to the same network link on which the
attack is to be launched, or control a node attached to that network
link (e.g., compromise such a node).
Layer-2 switches could filter Neighbor Advertisement messages based
on previous knowledge of the link-layer addresses recently in use at
each port.
6.1.3. Tampering with Neighbor Unreachability Detection (NUD)
The Neighbor Unreachability Detection (NUD) mechanism is used to
detect unreachable neighbors and cause the corresponding entries in
the Neighbor Cache to be eliminated. When an unreachable neighbor is
detected and the corresponding Neighbor Cache entry is removed, a
node has the chance to e.g., perform next-hop determination.
In order for a neighbor to be considered reachable, NUD uses
reachability indications from upper-layer protocols. In the absence
of reachability indications from an upper layer (e.g., from TCP's
Acknowledgements), NUD employs solicited unicast Neighbor
Solicitations to confirm the reachability of a Neighbor.
An attacker could snoop traffic and respond to the solicited Neighbor
Solicitation messages being used for the purpose of NUD, thus
preventing victim nodes from detecting that the impersonated node is
unreachable. As a result, those 'victim' nodes would continue
sending packets to the unreachable node, instead of e.g., performing
first-hop determination to find an alternative working router.
In order for an attacker to successfully perform this attack, he
would need to be attached to the same network link on which the
attack is to be launched, or control a node attached to that network
link (e.g., compromise such a node).
Nodes could require the link-layer source address of solicited
Neighbor Advertisements being employed for NUD to be the same as that
stored in the Neighbor Cache entry for which NUD is being performed.
With this requirement in place, layer-2 switches could filter
Neighbor Advertisement messages according to their source link-layer
address, based on previous knowledge of the link-layer addresses
recently in use at each port.
Gont, et al. Expires April 25, 2014 [Page 42]
Internet-Draft ND Security Assessment October 2013
It should be noted that this recommendation should not be enforced in
more complex networks in which VRRP [RFC5798] or custom redundancy
protocols are employed.
This would mitigate the tampering with NUD that employs Neighbor
Advertisement messages. However, it should be noted that an attacker
might still tamper with NUD by forging upper-layer packets such as
TCP Acknowledgements.
6.1.4. Rogue Router
An attacker could either send unsolicited Router Advertisements
and/or illegitimately respond to Router Solicitations, advertising a
non-existent system as a default router.
As a result, hosts honouring the aforementioned Router Advertisements
would use the advertised rogue router as a default router, and as a
result their packets would be black-holed.
In order for an attacker to successfully perform this attack, he
would need to be attached to the same network link on which the
attack is to be launched, or control a node attached to that network
link (e.g., compromise such a node). As described in [RFC3756], this
vulnerability could be mitigated by preferring existing routers over
new ones.
Additionally, layer-2 switches could possibly allow Router
Advertisements messages to be sent only from specific ports.
[RFC6104] analyzes the problem of Rogue IPv6 Router Advertisements,
and discusses a number of possible solutions. [RFC6105] discusses a
specific solution to this problem based on layer-2 filtering, known
as 'RA-Guard'. However, as discussed in
[I-D.ietf-v6ops-ra-guard-implementation], some popular RA-Guard
implementations can be easily circumvented by leveraging IPv6
extension headers. [CVE-2011-2395] is a vulnerability advisory about
this issue.
[SI6-Toolkit] is a complete complete IPv6 toolkit that can be
employed to circumvent the aforementioned RA-Guard
implementations.
6.1.5. Parameter spoofing
An attacker could either send unsolicited Router Advertisements
and/or illegitimately respond to Router Solicitations, advertising a
legitimate default router, but malicious network parameters.
Gont, et al. Expires April 25, 2014 [Page 43]
Internet-Draft ND Security Assessment October 2013
For example, an attacker could advertise a very small Cur Hop Limit
value, thus causing packets to be discarded before reaching their
intended destination.
An attacker could also advertise an incorrect link MTU (either very
small or very large) possibly preventing packets from being sent on
the corresponding link and/or causing pathological behaviour at the
victim nodes.
Finally, an attacker could either send unsolicited Router
Advertisements and/or illegitimately respond to Router Solicitations,
sending Router Advertisements with the M and/or the O bits set, thus
possibly causing the victim nodes to engage in managed address
configuration when such service is not present (e.g., there is no
DHCP server) or when the attacker operates a malicious DHCP server.
In the former scenario, address configuration would fail, as a result
of the non-existing DHCP server. In the latter scenario, an attacker
could operate a malicious DHCP server to override IPv6's stateless
configuration.
In order for an attacker to successfully perform this attack, he
would need to be attached to the same network link on which the
attack is to be launched, or control a node attached to that network
link (e.g., compromise such a node).
As with other attacks based on Router Advertisement messages, they
could be mitigated if Layer-2 switches allow Router Advertisements
messages to be sent only from specific ports.
6.1.6. Bogus on-link prefixes
An attacker could either send unsolicited Router Advertisements
and/or illegitimately respond to Router Solicitations, advertising
bogus prefixes for on-link determination.
As a result, nodes belonging to the aforementioned prefixes would be
considered on-link, and packets destined to them would not be relayed
to a first-hop router. As a result, the victim nodes (i.e., those
receiving the crafted Router Advertisements) would perform Neighbor
Discovery for the intended destination, and when ND failed, the
packets would be discarded.
In order for an attacker to successfully perform this attack, he
would need to be attached to the same network-link on which the
attack is to be launched, or control a node attached to that network
link (e.g., compromise such a node).
Gont, et al. Expires April 25, 2014 [Page 44]
Internet-Draft ND Security Assessment October 2013
As mentioned in [RFC3756] host implementations could mitigate the
impact of this attack by requiring the advertised prefixes to be at
least /64s.
This would prevent an attacker from affecting a much larger portion
of the IPv6 address space by e.g. sending a Router Advertisement that
advertises the prefix ::/0 to be 'on-link'.
As with other attacks based on Router Advertisement messages, they
could be mitigated if Layer-2 switches allow Router Advertisements
messages to be sent only from specific ports.
6.1.7. Bogus address configuration prefixes
An attacker could either send unsolicited Router Advertisements
and/or illegitimately respond to Router Solicitations, illegitimately
advertising IPv6 prefixes for stateless address auto-configuration
(SLAAC). This prefixes could either be bogon prefixes or prefixes
owned by a remote site. An attacker could cause victim systems to
configure IPv6 addresses using prefixes that would cause the
resulting traffic to be black-holed.
This would cause the receiving nodes to configure their addresses
with those bogus prefixes, and as a result, the resulting traffic
would possibly be filtered by the network (e.g., if network egress-
filtering is in place). Even if the outgoing packets were not
filtered, these victim systems would not receive the return traffic,
as the return traffic would either be filtered (in the case of bogon
prefixes) or delivered to the legitimate destination (in the case of
prefixes owned by some other party).
In order for an attacker to successfully perform this attack, he
would need to be attached to the same network-link on which the
attack is to be launched, or control a node attached to that network
link (e.g., compromise such a node).
As with other attacks based on Router Advertisement messages, they
could be mitigated if Layer-2 switches allow Router Advertisements
messages to be sent only from specific ports.
6.1.8. Disabling routers
An attacker could send crafted Router Advertisements, Neighbor
Advertisements, or Router Solicitations to cause the receiving nodes
to remove the impersonated router from the router list.
In current implementations, if there are no default routers, a packet
destined to an off-link node will elicit an ICMPv6 Destination
Gont, et al. Expires April 25, 2014 [Page 45]
Internet-Draft ND Security Assessment October 2013
Unreachable error message. In the case of legacy implementations
compliant with [RFC2461], if there are no default routers, the
Destination Address would be assumed to be 'on-link', and the victim
would perform Neighbor Discovery for the destination address in the
hope of delivering the packet on the local link.
In the case of the Router Advertisements vector, an attacker would
send unsolicited Router Advertisements with a Preferred Lifetime
equal to 0 or to some other small value, thus causing the receiving
nodes to remove the impersonated router from the default router list.
Alternatively, an attacker could send forged Neighbor Advertisements
(either solicited or unsolicited) with the Router flag set to 0, thus
causing the impersonated router to be removed from the default router
list.
Receiving nodes would assume the impersonated router has ceased to be
a router and has changed to functioning only as a host.
As a third option, an attacker could send a forged Router
Solicitation message to a router on the local network link, to cause
the victim to remove the impersonated router from the router list.
This attack vector is discussed in more detail in Section 4.1.
In order for an attacker to successfully perform this attack, he
would need to be attached to the same network link on which the
attack is to be launched, or control a node attached to that network
link (e.g., compromise such a node).
Some IPv6 networks employ the 'RA-Guard' mechanism specified in
[RFC6105] as the first line of defence against RA-based attack
vectors. However, However, as discussed in
[I-D.ietf-v6ops-ra-guard-implementation], some popular RA-Guard
implementations can be easily circumvented by leveraging IPv6
extension headers. [CVE-2011-2395] is a vulnerability advisory about
this issue.
[SI6-Toolkit] is a complete complete IPv6 toolkit that can be
employed to circumvent the aforementioned RA-Guard
implementations.
The rest of the attack vectors discussed in this section could
possibly be mitigated with a more advanced Layer-2 filtering.
6.1.9. Tampering with 'on-link determination'
Section 2.1 of [RFC4861] states that a node considers an address to
be on-link if:
Gont, et al. Expires April 25, 2014 [Page 46]
Internet-Draft ND Security Assessment October 2013
o it is covered by one of the link's prefixes (e.g., as indicated by
the on-link flag in the Prefix Information option), or
o a neighbouring router specifies the address as the target of a
Redirect message, or
o a Neighbor Advertisement message is received for the (target)
address, or
o any Neighbor Discovery message is received from the address.
As a result, some implementations create a Destination Cache entry
for the Source Address of a Neighbor Discovery message (or for the
Target Address of a Neighbor Advertisement message) when such a
message is received, and mark the aforementioned address as 'on-
link'.
This means in all traffic meant to the forged address will be
delivered to the node identified in the corresponding Neighbor Cache
entry (as the node will be considered to be on-link). If the
corresponding Neighbor Cache entry maps the forged address into a
non-existent or malicious node, all traffic can be black-holed, thus
leading to a DoS scenario.
[RFC5942] updates [RFC4861], removing the third and fourth bullets in
the above list. This means that receipt of ND messages must not
result in the Source Address of the ND message or the Target Address
of a Neighbor Advertisement message to be considered on-link (e.g.,
by modifying the Prefix List or by marking the corresponding
Destination Cache entry as 'on-link').
[CVE-2008-2476] and [US-CERT2008] are vulnerability advisories
about this issue.
Some IPv6 networks employ the 'RA-Guard' mechanism specified in
[RFC6105] as the first line of defence against RA-based attack
vectors. However, as discussed in
[I-D.ietf-v6ops-ra-guard-implementation], some popular RA-Guard
implementations can be easily circumvented by leveraging IPv6
extension headers. [CVE-2011-2395] is a vulnerability advisory about
this issue.
[SI6-Toolkit] is a complete complete IPv6 toolkit that can be
employed to circumvent the aforementioned RA-Guard
implementations.
[I-D.ietf-6man-nd-extension-headers] updates [RFC3971] and [RFC4861],
deprecating the use of fragmentation with Neighbor Discovery, such
Gont, et al. Expires April 25, 2014 [Page 47]
Internet-Draft ND Security Assessment October 2013
that layer-2 filtering and Neighbor Discovery monitoring become
feasible.
6.1.10. Introducing forwarding loops at routers
As discussed in Section 3.6.2 of this document, if broadcast or
multicast addresses were allowed in source link-layer address options
or in target link-layer address options, traffic directed to a victim
IPv6 address would be sent to such broadcast or multicast IPv6
address.
Consider the following network scenario:
+----------+ +--------+ +----------+
| Router A | | Host C | | Router B |
+----------+ +--------+ +----------+
|| || ||
=================================================
||
||
+----------+
| Attacker |
+----------+
Figure 15: Example network scenario for forwarding loop
An attacker could poison the neighbor cache of Router A and the
neighbor cache of Router B, such that the IPv6 address of Host C maps
to the Ethernet broadcast address (ff:ff:ff:ff:ff:ff). Afterwards,
he could send a packet to the Ethernet broadcast address (ff:ff:ff:
ff:ff:ff), with an IPv6 Destination Address equal to the IPv6 address
of Host C. Upon receiving the packet, both Router A and Router C
would decrement the Hop Limit of the packet, and would resend it to
the Ethernet broadcast address. As a result, both Router A and
Router B would now receive two copies of the same packet (one sent by
Router A, and another sent by Router B). This would result in a
'chain reaction' that would only disappear when the Hop Limit of each
of the packets is decremented to 0. The total number of packets, for
a general scenario in which multiple routers are present on the link
and are subject of the aforementioned neighbor cache poisoning
attack, and the attacker sends the initial attack packet with an
arbitrary Hop Limit (possibly 255 to get the maximum amplification
factor) is:
Gont, et al. Expires April 25, 2014 [Page 48]
Internet-Draft ND Security Assessment October 2013
HopLimit-1
---
\ x
Packets = / Routers
---
x=0
Figure 16: Maximum amplification factor
This equation does not take into account neither the possible ICMPv6
Redirect messages that each of the Routers could send, nor the
possible ICMPv6 'time exceeded in transit' error messages that each
of the routers could possibly send to the Source Address of the
packet when each of the 'copies' of the original packet is discarded
as a result of their Hop Limit being decremented to 0.
As discussed in Section 3.6.2 of this document, neither broadcast nor
multicast addresses should be allowed in source link-layer address
and target link-layer address options. An additional mitigation
would be for routers to not forward IPv6 packets on the same
interface if the link-layer destination address of the packet was a
broadcast or multicast address.
It is also possible to introduce a forwarding loop at a router by
poisoning its neighbor cache such that a victim IPv6 address
(considered to be on-link) maps to one of the attacked router's link-
layer addresses. An attacker could poison the neighbor cache of the
target router as described, and then send a packet to the attacked
router with the IPv6 Destination Address set to the victim address.
Upon receipt of the packet, the router would decrement the Hop Limit,
and 'forward' the packet to its own link-layer address. This would
result in a loop, with the target router processing the packet 'Hop
Limit' times (where 'Hop Limit' is the value used for the Hop Limit
field of the original packet).
6.1.11. Tampering with a Neighbor Discovery implementation
The Neighbor Discovery specification describes conceptual data
structures such as the Neighbor Cache and the Destination Cache,
which grow as a result of each entry that is created. Additionally,
there are other structures such as the list of configured IPv6
addresses, the list of Recursive DNS Servers, etc., that also grow
for each entry that is created in them.
As discussed throughout Section 5 of this document, an implementation
should enforce limits on the maximum number of entries in these
structures. Failure in enforcing such limits could result in buffer
overflows or memory exhaustion.
Gont, et al. Expires April 25, 2014 [Page 49]
Internet-Draft ND Security Assessment October 2013
FreeBSD 9.0 and NetBSD 5.1 fail to enforce limits on the number of
entries in the IPv6 routing table, on the number of entries in the
Neighbor Cache, on the number of entries in the Default Router
List, and on the number of configured IPv6 addresses. Therefore
they are vulnerable to multiple Denial of Service attacks.
Many versions of Windows that support IPv6 fail to enforce limits
on the number of entries in the IPv6 routing table, on the maximum
number of configured addresses, and on the number of entries in
the Neighbor Cache. Therefore, these structures could be
exploited for performing a Denial of Service attack. [Win-Update]
describes an update has been made available for Windows 7 and
Windows Server 2008 R2 to limit the number of configured addresses
and the number of routing table entries on a per-interface basis.
Linux 2.6.38-10 does enforce a limit on the number of entries in
the Default router list. However, this limit itself could be
leveraged for performing a Denial of Service attack, by causing
the Default router list to become full of malicious/spurious
entries before a legitimate entry can be added. As a result, the
system would be unable to configure a legitimate default router,
even if a legitimate Router Advertisement is received at some
point later.
An attacker attached to the same network link as the target node can
stress most of these data structures by sending a large number of the
appropriate Neighbor Discovery options (e.g., RDNSS or Prefix
Information options in Router Advertisement messages, etc.) as has
been shown by e.g. [CVE-2010-4669].
Other structures (such as the Neighbor Cache or the Destination
Cache) can be stressed by sending packets with forged addresses to
the target node. For example, an attacker could send any packets
that would elicit a response from the destination system with forged
IPv6 Source Address that is assumed to be 'on-link' by the target
system. In order for the target node to respond to those packets, it
would have to create the necessary entries in the Destination Cache
and in the Neighbor Cache. If the target implementation does not
enforce limits on the maximum number of entries in each of those data
structures, the attack may result in buffer overflows or kernel
system memory exhaustion.
It is interesting to note that this attack vector could also be
exploited by an attacker located in a remote site, unless ingress
and/or egress filtering are in place.
Gont, et al. Expires April 25, 2014 [Page 50]
Internet-Draft ND Security Assessment October 2013
[NISCC2006b] discusses ingress and egress filtering.
6.1.12. Tampering with a Neighbor Discovery router implementation from
a remote site
A remote attacker could potentially perform a Denial-of-Service (DoS)
attack against a router by sending packets to different IPv6
addresses considered on-link at one of the network links to which the
target router is attached. Each of these packets would engage the
target router in neighbor discovery for each of those addresses,
probably preventing the router from performing neighbor discovery for
legitimate packets aimed at existing nodes.
This problem would be exacerbated if an implementation queues in
memory those packets that are destined to an IPv6 address for which
address resolution is being performed. See Section 5 of this
document for a thorough description of this issue.
One important difference between this attack vector and the ones
described in the previous subsections is that in order for an
attacker to successfully perform this attack, he does not need to be
attached to the same network link to which the target router is
attached.
A possible mitigation for this attack would be to enforce a limit on
the maximum number of entries in the Neighbor Cache that are in the
'INCOMPLETE' state. This limit should be stricter than the overall
limit on the maximum number of entries in the Neighbor Cache.
A Neighbor Cache entry is in the 'INCOMPLETE' state if a Neighbor
Advertisement message has never been received for the corresponding
IPv6 address since the entry was created.
It should be noted that this is an implementation issue rather than a
protocol-based vulnerability. However, a number of implementations
have been found to be vulnerable to this attack.
It is also worth noting that this attack does not require an attacker
to forge the IPv6 Source Address of the 'malicious' packets.
Therefore, mechanisms such as 'ingress filtering' do not provide any
mitigation for this attack.
Section 6.1.11 describes another attack vector for stressing the
Neighbor Cache (and the Destination cache) of both host and router
implementations.
Gont, et al. Expires April 25, 2014 [Page 51]
Internet-Draft ND Security Assessment October 2013
6.2. Performance degrading
6.2.1. Parameter spoofing
An attacker could either send unsolicited Router Advertisements
and/or illegitimately respond to Router Solicitations, advertising a
legitimate default router, but malicious network parameters.
An attacker could also advertise a small link MTU causing the victim
nodes to enforce such a small MTU for the corresponding network link.
This would increase the overhead (headers/data ratio), and possibly
result in a packet-rate increase (if the same throughput is to be
maintained). Additionally, this might also require the use of IPv6
fragmentation when data are to be transferred across this network
link. This is a moderate version of the Denial-of-Service (DoS)
attack discussed in Section 6.1.5 of this document.
In order for an attacker to successfully perform this attack, he
would need to be attached to the same network link on which the
attack is to be launched, or control a node attached to that network
link (e.g., compromise such a node).
Some IPv6 networks employ the 'RA-Guard' mechanism specified in
[RFC6105] as the first line of defence against RA-based attack
vectors. However, as discussed in
[I-D.ietf-v6ops-ra-guard-implementation], some popular RA-Guard
implementations can be easily circumvented by leveraging IPv6
extension headers. [CVE-2011-2395] is a vulnerability advisory about
this issue.
[SI6-Toolkit] is a complete complete IPv6 toolkit that can be
employed to circumvent the aforementioned RA-Guard
implementations.
6.3. Traffic hijacking
6.3.1. Neighbor Cache poisoning
Neighbor Solicitation and Neighbor Advertisement messages can be
exploited to maliciously poison the Neighbor Cache of a target node
such that an IPv6 address maps into the link-layer address of a
malicious node operated by an attacker. As a result, once the
victim's Neighbor Cache is poisoned, the attacker would receive all
traffic aimed at the victim node.
This is similar to the Denial-of-Service (DoS) attack described in
Section 6.1.1 of this document, with the only difference being that
in this case traffic would be directed to a node operated by the
Gont, et al. Expires April 25, 2014 [Page 52]
Internet-Draft ND Security Assessment October 2013
attacker, rather than to a non-existent node.
In order for an attacker to successfully perform this attack, he
would need to be attached to the same network link on which the
attack is to be launched, or control a node attached to that network
link (e.g., compromise such a node).
An attacker could also poison the Neighbor Cache of a target node
mapping a victim IPv6 address to a multicast or broadcast link-layer
address, such that he can receive a copy of those packets sent by the
attacked node to the victim node. This specific attack vector is
thoroughly discussed in Section 3.6.2 of this document.
The same mitigation techniques as described in Section 6.1.1 of this
document apply to this attack-vector.
6.3.2. Rogue Router
An attacker could either send unsolicited Router Advertisements
and/or illegitimately respond to Router Solicitations, advertising
his own node as a default router.
This is similar to the Denial-of-Service (DoS) attack described in
Section 6.1.4, with the only difference that in this case traffic
would be directed to a node operated by the attacker, rather than to
a non-existing node.
In order for an attacker to successfully perform this attack, he
would need to be attached to the same network link on which the
attack is to be launched, or control a node attached to that network
link (e.g., compromise such a node).
The same mitigation techniques as described in Section 6.1.4 apply to
this attack vector.
6.3.3. Bogus on-link prefixes
An attacker could either send unsolicited Router Advertisements
and/or illegitimately respond to Router Solicitations, advertising
bogus prefixes for on-link determination.
As a result, nodes belonging to the aforementioned prefixes would be
considered on-link, and packets destined to them would not be relayed
to a first-hop router, but would instead be delivered on the local
link. The victim nodes (i.e., those receiving the crafted Router
Advertisements) would perform Neighbor Discovery for the intended
destination, and the attacker could then respond with Neighbor
Advertisements that advertise the link-layer address of his node, so
Gont, et al. Expires April 25, 2014 [Page 53]
Internet-Draft ND Security Assessment October 2013
that packets are finally delivered to his malicious node.
In order for an attacker to successfully perform this attack, he
would need to be attached to the same network link on which the
attack is to be launched, or control a node attached to that network
link (e.g., compromise such a node).
The same mitigation techniques as described in Section 6.1.6 apply to
this attack vector.
6.3.4. Tampering with 'on-link determination'
This attack is similar to the Denial-of-Service (DoS) attack
described in Section 6.1.10, with the only difference that for the
purpose of traffic-hijacking, an attacker would make sure that the
cached link-layer address of the Neighbor Cache entry corresponding
to the victim address (the Source Address of the forged Neighbor
Discovery message or the forged Target Address of the forged Neighbor
Advertisement message) corresponds to the link-layer address of a
node operated by the attacker.
As discussed in Section 6.1.9, [RFC5942] updates [RFC4861], such that
this attack vector is eliminated. The same mitigations discussed in
Section 6.1.9 of this document apply to mitigate this vulnerability.
[CVE-2008-2476] and [US-CERT2008] are vulnerability advisories
about this issue.
6.4. Miscellaneous security issues
6.4.1. Detecting Sniffing Hosts
If a system reacts differently depending on whether the network
interface is in promiscuous mode, this can be leveraged by an
attacker that is on-link to infer whether the target node is in
promiscuous mode. Such a security issue has been found on many
operating systems, where a packet with a multicast MAC address that
is not being listened on by that target will be processed only if the
receiving node is in promiscuous mode (i.e., "sniffing" the network).
This test can be performed with any packet type, e.g. Neighbor
Solicitation or Echo Request.
[CVE-2010-4562] is one vulnerability advisory about such an issue.
Gont, et al. Expires April 25, 2014 [Page 54]
Internet-Draft ND Security Assessment October 2013
7. IANA Considerations
This document has no actions for IANA.
Gont, et al. Expires April 25, 2014 [Page 55]
Internet-Draft ND Security Assessment October 2013
8. Security Considerations
This entire document is about security vulnerabilities that have been
found popular Neighbor Discovery implementations, and other potential
security issues that might be affecting existing implementations.
This document not only discusses the aforementioned issues, but also
provides implementation guidance such that these issues can be
eliminated from the affected implementations and completely avoided
or mitigated in any new Neighbor Discovery implementations.
The ultimate goal of this document is to help improve the overall
maturity of Neighbor Discovery implementations, and to raise
awareness about current security issues that might affect IPv6
networks.
Gont, et al. Expires April 25, 2014 [Page 56]
Internet-Draft ND Security Assessment October 2013
9. Acknowledgements
Marc Heuse contributed text, edits, comments, and new vulnerabilities
that were incorporated into this document.
The author would like to thank George Kargiotakis, who provided
valuable comments on earlier versions of this document.
This document is based on the technical report "Security Assessment
of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by
Fernando Gont on behalf of the UK Centre for the Protection of
National Infrastructure (CPNI). The author would like to thank (in
alphabetical order) Ran Atkinson, Fred Baker, Brian Carpenter, Roque
Gagliano, Guillermo Gont, Alfred Hoenes, Qing Li, Neil Long, and
Pekka Savola, for providing valuable feedback on earlier versions of
such document. Additionally, the author would like to thank (in
alphabetical order) Ran Atkinson, Brian Carpenter, Joel M. Halpern,
Robert Hinden, Pekka Savola, Fred Templin, and Ole Troan, who
generously answered a number of questions when authoring the
aforementioned document.
Gont, et al. Expires April 25, 2014 [Page 57]
Internet-Draft ND Security Assessment October 2013
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for
Inverse Discovery Specification", RFC 3122, June 2001.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor
Discovery On-Link Assumption Considered Harmful",
RFC 4943, September 2007.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010.
[RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP)
Gont, et al. Expires April 25, 2014 [Page 58]
Internet-Draft ND Security Assessment October 2013
Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
[RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet
Model: The Relationship between Links and Subnet
Prefixes", RFC 5942, July 2010.
[I-D.ietf-6man-nd-extension-headers]
Gont, F., "Security Implications of IPv6 Fragmentation
with IPv6 Neighbor Discovery",
draft-ietf-6man-nd-extension-headers-05 (work in
progress), June 2013.
10.2. Informative References
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[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.ietf-v6ops-ra-guard-implementation]
Gont, F., "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)",
draft-ietf-v6ops-ra-guard-implementation-07 (work in
progress), November 2012.
[CPNI-IPv6]
Gont, F., "Security Assessment of the Internet Protocol
version 6 (IPv6)", UK Centre for the Protection of
National Infrastructure, (available on request).
[CPNI-TCP]
CPNI, "Security Assessment of the Transmission Control
Protocol (TCP)", 2009, <http://www.gont.com.ar/papers/
tn-03-09-security-assessment-TCP.pdf>.
[Hogg-Vyncke]
Hogg, S. and E. Vyncke, "IPv6 Security", Cisco Press; 1
edition, 2008.
[Lecigne-Neville-Neil]
Lecigne, C. and G. Neville-Neil, "Walking through FreeBSD
IPv6 stack", 2006, <http://clem1.be/gimme/ipv6sec.pdf>.
Gont, et al. Expires April 25, 2014 [Page 59]
Internet-Draft ND Security Assessment October 2013
[Beck2007]
Beck, F., Cholez, T., Festor, O., and I. Chrisment,
"Monitoring the Neighbor Discovery Protocol", The Second
International Workshop on IPv6 Today - Technology and
Deployment - IPv6TD 2007, <http://hal.inria.fr/docs/00/15/
35/58/PDF/IPv6TD07_beck.pdf>.
[Beck2007b]
Beck, F., Festor, O., and I. Chrisment, "IPv6 Neighbor
Discovery Protocol based OS fingerprinting", INRIA
Rapport Technique No 0345, 2007, <http://
hal.archives-ouvertes.fr/docs/00/18/48/51/PDF/
RT-0345.pdf>.
[NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor",
<http://ndpmon.sourceforge.net/>.
[arpwatch]
LBNL/NRG, "arpwatch tool", 2006, <http://ee.lbl.gov/>.
[NISCC2006b]
NISCC, "NISCC Technical Note 01/2006: Egress and Ingress
Filtering", 2006, <http://www.niscc.gov.uk/niscc/docs/
re-20060420-00294.pdf?lang=en>.
[vanHauser2006]
vanHauser, "Attacking the IPv6 Protocol Suite", EuSecWest
2006 Conference,
<http://www.eusecwest.com/esw06/esw06-vanhauser.pdf>.
[SI6-Toolkit]
"SI6 Networks' IPv6 toolkit",
<http://www.si6networks.com/tools/ipv6toolkit>.
[THC-IPv6]
"The Hacker's Choice IPv6 Attack Toolkit",
<http://www.thc.org/thc-ipv6/>.
[CVE-2012-notyet]
CVE, "CVE-2012-notyet - entry is upcoming ... to be
filled", 2012.
[CVE-2011-2391]
CVE, "CVE-2011-2391 - IPv6 Neighbor Discovery Protocol
(NDP) implementations do not limit the rate of Neighbor
Discovery messages processed", 2011.
[CVE-2008-2476]
Gont, et al. Expires April 25, 2014 [Page 60]
Internet-Draft ND Security Assessment October 2013
CVE, "CVE-2008-2476 - IPv6 Neighbor Discovery Protocol
(NDP) implementations do not validate the origin of
Neighbor Discovery messages", 2008.
[CVE-2010-4669]
CVE, "CVE-2010-4669 - Neighbor Discovery (ND) protocol
implementation in the IPv6 stack in Microsoft Windows
allows attackers to cause a denial of service (CPU
consumption and system hang) by sending many Router
Advertisement (RA) messages with different source
addresses", 2010.
[CVE-2011-2395]
CVE, "CVE-2011-2395 - Neighbor Discovery (ND) protocol
implementation in Cisco IOS on unspecified switches allows
attackers to bypass the Router Advertisement Guarding
functionality via a fragmented IPv6 packets", 2011.
[CVE-2010-4562]
CVE, "CVE-2010-4562 - Microsoft Windows, when using IPv6,
allows remote attackers to determine whether a host is
sniffing the network by sending an ICMPv6 Echo Request to
a multicast address and determining whether an Echo Reply
is sent", 2010.
[US-CERT2008]
US-CERT, "US-CERT Vulnerability Note VU#472363: IPv6
implementations insecurely update Forwarding Information
Base", 2008.
[Win-Update]
Microsoft, "An IPv6 readiness update is available for
Windows 7 and for Windows Server 2008 R2", 2012.
Gont, et al. Expires April 25, 2014 [Page 61]
Internet-Draft ND Security Assessment October 2013
Authors' Addresses
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
Ronald P. Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, VA 20171
US
Phone: 571 250 5819
Email: rbonica@juniper.net
Will Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: liushucheng@huawei.com
Gont, et al. Expires April 25, 2014 [Page 62]
