Request for Comments: 3756 Ericsson Research Nomadic Lab
Category: Informational J. Kempf
DoCoMo USA Labs
E. Nordmark
Sun Microsystems Laboratories
May 2004
IPv6 Neighbor Discovery (ND) Trust Models and Threats
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The existing IETF standards specify that IPv6 Neighbor Discovery (ND)
and Address Autoconfiguration mechanisms may be protected with IPsec
Authentication Header (AH). However, the current specifications
limit the security solutions to manual keying due to practical
problems faced with automatic key management. This document
specifies three different trust models and discusses the threats
pertinent to IPv6 Neighbor Discovery. The purpose of this discussion
is to define the requirements for Securing IPv6 Neighbor Discovery.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Remarks . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Previous Work. . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Trust Models . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Corporate Intranet Model. . . . . . . . . . . . . . . . . 5
3.2. Public Wireless Network with an Operator. . . . . . . . . 6
3.3. Ad Hoc Network. . . . . . . . . . . . . . . . . . . . . . 7
4. Threats on a (Public) Multi-Access Link. . . . . . . . . . . . 8
4.1. Non router/routing related threats. . . . . . . . . . . . 9
4.1.1. Neighbor Solicitation/Advertisement Spoofing . . . 9
4.1.2. Neighbor Unreachability Detection (NUD) failure. . 10
4.1.3. Duplicate Address Detection DoS Attack . . . . . . 11
4.2. Router/routing involving threats. . . . . . . . . . . . . 12
4.2.1. Malicious Last Hop Router. . . . . . . . . . . . . 12
4.2.2. Default router is ’killed’ . . . . . . . . . . . . 13
4.2.3. Good Router Goes Bad . . . . . . . . . . . . . . . 14
4.2.4. Spoofed Redirect Message . . . . . . . . . . . . . 14
4.2.5. Bogus On-Link Prefix . . . . . . . . . . . . . . . 14
4.2.6. Bogus Address Configuration Prefix . . . . . . . . 15
4.2.7. Parameter Spoofing . . . . . . . . . . . . . . . . 16
4.3. Replay attacks and remotely exploitable attacks . . . . . 17
4.3.1. Replay attacks . . . . . . . . . . . . . . . . . . 17
4.3.2. Neighbor Discovery DoS Attack. . . . . . . . . . . 18
4.4. Summary of the attacks. . . . . . . . . . . . . . . . . . 19
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 20
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
7. Informative References . . . . . . . . . . . . . . . . . . . . 21
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
The IPv6 Neighbor Discovery (ND) RFC 2461 [2] and Address
Autoconfiguration RFC 2462 [3] mechanisms are used by nodes in an
IPv6 network to learn the local topology, including the IP to MAC
address mappings for the local nodes, the IP and MAC addresses of the
routers present in the local network, and the routing prefixes served
by the local routers. The current specifications suggest that IPsec
AH RFC 2402 [1] may be used to secure the mechanisms, but does not
specify how. It appears that using current AH mechanisms is
problematic due to key management problems [8].
To solve the problem, the Secure Neighbor Discovery (SEND) working
group was chartered in Fall 2002. The goal of the working group is
to define protocol support for securing IPv6 Neighbor Discovery
without requiring excessive manual keying.
The purpose of this document is to define the types of networks in
which the Secure IPv6 Neighbor Discovery mechanisms are expected to
work, and the threats that the security protocol(s) must address. To
fulfill this purpose, this document first defines three different
trust models, roughly corresponding to secured corporate intranets,
public wireless access networks, and pure ad hoc networks. After
that, a number of threats are discussed in the light of these trust
models. The threat catalog is aimed to be exhaustive, but it is
likely that some threats are still missing. Thus, ideas for new
threats to consider are solicited.
1.1. Remarks
Note that the SEND WG charter limits the scope of the working group
to secure Neighbor Discovery functions. Furthermore, the charter
explicitly mentions zero configuration as a fundamental goal behind
Neighbor Discovery. Network access authentication and access control
are outside the scope of this work.
During the discussions while preparing this document, the following
aspects that may help to evaluate the eventual solutions were
mentioned.
Zero configuration
Interaction with access control solutions
Scalability
Efficiency
However, the main evaluation criteria are formed by the trust models
and threat lists. In other words, the solutions are primarily
evaluated by seeing how well they secure the networks against the
identified threats, and only secondarily from the configuration,
access control, scalability, and efficiently point of view.
IMPORTANT. This document occasionally discusses solution proposals,
such as Cryptographically Generated Addresses (CGA) [7] and Address
Based Keys (ABK) [6]. However, such discussion is solely for
illustrative purposes. Its purpose is to give the readers a more
concrete idea of *some* possible solutions. Such discussion does NOT
indicate any preference on solutions on the behalf of the authors or
the working group.
It should be noted that the term "trust" is used in this document in
a rather non-technical manner. The most appropriate interpretation
is to consider it as an expression of an organizational or collective
belief, i.e., an expression of commonly shared beliefs about the
future behavior of the other involved parties. Conversely, the term
"trust relationship" denotes a mutual a priori relationship between
the involved organizations or parties where the parties believe that
the other parties will behave correctly even in the future. A trust
relationship makes it possible to configure authentication and
authorization information between the parties, while the lack of such
a relationship makes it impossible to pre-configure such information.
2. Previous Work
The RFCs that specify the IPv6 Neighbor Discovery and Address
Autoconfiguration protocols [2] [3] contain the required discussion
of security in a Security Considerations section. Some of the
threats identified in this document were raised in the original RFCs.
The recommended remedy was to secure the involved packets with an
IPsec AH [1] header. However, that recommendation oversimplifies the
problem by leaving the AH key management for future work. For
example, a host attempting to gain access to a Public Access network
may or may not have the required IPsec security associations set up
with the network. In a roaming (but not necessarily mobile)
situation, where a user is currently accessing the network through a
service provider different from the home provider, it is not likely
that the host will have been preconfigured with the proper mutual
trust relationship for the foreign provider’s network, allowing it to
directly authenticate the network and get itself authenticated.
As of today, any IPsec security association between the host and the
last hop routers or other hosts on the link would need to be
completely manually preconfigured, since the Neighbor Discovery and
Address Autoconfiguration protocols deal to some extent with how a
host obtains initial access to a link. Thus, if a security
association is required for initial access and the host does not have
that association, there is currently no standard way that the host
can dynamically configure itself with that association, even if it
has the necessary minimum prerequisite keying material. This
situation could induce administration hardships when events such as
re-keying occur.
In addition, Neighbor Discovery and Address Autoconfiguration use a
few fixed multicast addresses plus a range of 16 million "solicited
node" multicast addresses. A naive application of pre-configured SAs
would require pre-configuring an unmanageable number of SAs on each
host and router just in case a given solicited node multicast address
is used. Preconfigured SAs are impractical for securing such a large
potential address range.
3. Trust Models
When considering various security solutions for the IPv6 Neighbor
Discovery (ND) [2], it is important to keep in mind the underlying
trust models. The trust models defined in this section are used
later in this document, when discussing specific threats.
In the following, the RFC 2461/RFC 2462 mechanisms are loosely
divided into two categories: Neighbor Discovery (ND) and Router
Discovery (RD). The former denotes operations that do not primarily
involve routers while the operations in the latter category do.
Three different trust models are specified:
1. A model where all authenticated nodes trust each other to behave
correctly at the IP layer and not to send any ND or RD messages
that contain false information. This model is thought to
represent a situation where the nodes are under a single
administration and form a closed or semi-closed group. A
corporate intranet is a good example.
2. A model where there is a router trusted by the other nodes in the
network to be a legitimate router that faithfully routes packets
between the local network and any connected external networks.
Furthermore, the router is trusted to behave correctly at the IP
layer and not to send any ND or RD messages that contain false
information.
This model is thought to represent a public network run by an
operator. The clients pay to the operator, have its credentials,
and trust it to provide the IP forwarding service. The clients
do not trust each other to behave correctly; any other client
node must be considered able to send falsified ND and RD
messages.
3. A model where the nodes do not directly trust each other at the
IP layer. This model is considered suitable for e.g., ad hoc
networks.
Note that even though the nodes are assumed to trust each other in
the first trust model (corporate intranet), it is still desirable to
limit the extent of damage a node is able to inflict to the local
network if it becomes compromised.
3.1. Corporate Intranet Model
In a corporate intranet or other network where all nodes are under
one administrative domain, the nodes may be considered to be reliable
at the IP layer. Thus, once a node has been accepted to be a member
of the network, it is assumed to behave in a trustworthy manner.
Under this model, if the network is physically secured or if the link
layer is cryptographically secured to the extent needed, no other
protection is needed for IPv6 ND, as long as none of the nodes become
compromised. For example, a wired LAN with 802.1x access control or
a WLAN with 802.11i Robust Security Network (RSN) with AES encryption
may be considered secure enough, requiring no further protection
under this trust model. On the other hand, ND security would add
protection depth even under this model (see below). Furthermore, one
should not overestimate the level of security any L2 mechanism is
able to provide.
If the network is not physically secured and the link layer does not
have cryptographic protection, or if the cryptographic protection is
not secure enough (e.g., just 802.1x and not 802.11i in a WLAN), the
nodes in the network may be vulnerable to some or all of the threats
outlined in Section 4. In such a case some protection is desirable
to secure ND. Providing such protection falls within the main
initial focus of the SEND working group.
Furthermore, it is desirable to limit the amount of potential damage
in the case a node becomes compromised. For example, it might still
be acceptable that a compromised node is able to launch a denial-of-
service attack, but it is undesirable if it is able to hijack
existing connections or establish man-in-the-middle attacks on new
connections.
As mentioned in Section 2, one possibility to secure ND would be to
use IPsec AH with symmetric shared keys, known by all trusted nodes
and by no outsiders. However, none of the currently standardized
automatic key distribution mechanisms work right out-of-the-box. For
further details, see [8]. Furthermore, using a shared key would not
protect against a compromised node.
More specifically, the currently used key agreement protocol, IKE,
suffers from a chicken-and-egg problem [8]: one needs an IP address
to run IKE, IKE is needed to establish IPsec SAs, and IPsec SAs are
required to configure an IP address. Furthermore, there does not
seem to be any easy and efficient ways of securing ND with symmetric
key cryptography. The required number of security associations would
be very large [9].
As an example, one possible approach to overcome this limitation is
to use public key cryptography, and to secure ND packets directly
with public key signatures.
3.2. Public Wireless Network with an Operator
A scenario where an operator runs a public wireless (or wireline)
network, e.g., a WLAN in a hotel, airport, or cafe, has a different
trust model. Here the nodes may be assumed to trust the operator to
provide the IP forwarding service in a trustworthy manner, and not to
disrupt or misdirect the clients’ traffic. However, the clients do
not usually trust each other. Typically the router (or routers) fall
under one administrative domain, and the client nodes each fall under
their own administrative domain.
It is assumed that under this scenario the operator authenticates all
the client nodes, or at least requires authorization in the form of a
payment. At the same time, the clients must be able to authenticate
the router and make sure that it belongs to the trusted operator.
Depending on the link-layer authentication protocol and its
deployment, the link layer may take care of the mutual
authentication. The link-layer authentication protocol may allow the
client nodes and the access router to create a security association.
Note that there exist authentication protocols, e.g., particular EAP
methods, that do not create secure keying material and/or do not
allow the client to authenticate the network.
In this scenario, cryptographically securing the link layer does not
necessarily block all the threats outlined in Section 4; see the
individual threat descriptions. Specifically, even in 802.11i RSN
with AES encryption the broadcast and multicast keys are shared
between all nodes. Even if the underlying link layer was aware of
all the nodes’ link-layer addresses, and were able to check that no
source addresses were falsified, there would still be
vulnerabilities.
One should also note that link-layer security and IP topology do not
necessarily match. For example, the wireless access point may not be
visible at the IP layer at all. In such a case cryptographic
security at the link layer does not provide any security with regard
to IP Neighbor Discovery.
There seems to be at least two ways to bring in security into this
scenario. One possibility seems to be to enforce strong security
between the clients and the access router, and make the access router
aware of the IP and link-layer protocol details. That is, the router
would check ICMPv6 packet contents, and filter packets that contain
information which does not match the network topology. The other
possibly acceptable way is to add cryptographic protection to the
ICMPv6 packets carrying ND messages.
3.3. Ad Hoc Network
In an ad hoc network, or any network without a trusted operator, none
of the nodes trust each other. In a generic case, the nodes meet
each other for the first time, and there are no guarantees that the
other nodes would behave correctly at the IP layer. They must be
considered suspicious to send falsified ND and RD messages.
Since there are no a priori trust relationships, the nodes cannot
rely on traditional authentication. That is, the traditional
authentication protocols rely on some existing relationship between
the parties. The relationship may be direct or indirect. The
indirect case relies on one or more trusted third parties, thereby
creating a chain of trust relationships between the parties.
In the generic ad hoc network case, there are no trusted third
parties, nor do the parties trust each other directly. Thus, the
traditional means of first authenticating and then authorizing the
users (to use their addresses) do not work.
It is still possible to use self-identifying mechanisms, such as
Cryptographically Generated Addresses (CGA) [7]. These allow the
nodes to ensure that they are talking to the same nodes (as before)
at all times, and that each of the nodes indeed have generated their
IP address themselves and not "stolen" someone else’s address. It
may also be possible to learn the identities of any routers using
various kinds of heuristics, such as testing the node’s ability to
convey cryptographically protected traffic towards a known and
trusted node somewhere in the Internet. Methods like these seem to
mitigate (but not completely block) some of the attacks outlined in
the next section.
4. Threats on a (Public) Multi-Access Link
In this section we discuss threats against the current IPv6 Neighbor
Discovery mechanisms, when used in multi-access links. The threats
are discussed in the light of the trust models defined in the
previous section.
There are three general types of threats:
1. Redirect attacks in which a malicious node redirects packets away
from the last hop router or other legitimate receiver to another
node on the link.
2. Denial-of-Service (DoS) attacks, in which a malicious node
prevents communication between the node under attack and all
other nodes, or a specific destination address.
3. Flooding Denial-of-Service (DoS) attacks, in which a malicious
node redirects other hosts’ traffic to a victim node, and thereby
creates a flood of bogus traffic at the victim host.
A redirect attack can be used for DoS purposes by having the node to
which the packets were redirected drop the packets, either completely
or by selectively forwarding some of them and not others.
The subsections below identify specific threats for IPv6 network
access. The threat descriptions are organized in three subsections.
We first consider threats that do not involve routers or routing
information. We next consider threats that do involve routers or
routing information. Finally, we consider replay attacks and threats
that are remotely exploitable. All threats are discussed in the
light of the trust models.
4.1. Non router/routing related threats
In this section we discuss attacks against "pure" Neighbor Discovery
functions, i.e., Neighbor Discovery (ND), Neighbor Unreachability
Detection (NUD), and Duplicate Address Detection (DAD) in Address
Autoconfiguration.
4.1.1. Neighbor Solicitation/Advertisement Spoofing
Nodes on the link use Neighbor Solicitation and Advertisement
messages to create bindings between IP addresses and MAC addresses.
More specifically, there are two cases when a node creates neighbor
cache entries upon receiving Solicitations:
1. A node receives a Neighbor Solicitation that contains a node’s
address. The node can use that to populate its neighbor cache.
This is basically a performance optimization, and a SHOULD in the
base documents.
2. During Duplicate Address Detection (DAD), if a node receives a
Neighbor Solicitation for the same address it is soliciting for,
the situation is considered a collision, and the node must cease
to solicit for the said address.
In contrast to solicitation messages that create or modify state only
in these specific occasions, state is usually modified whenever a
node receives a solicited-for advertisement message.
An attacking node can cause packets for legitimate nodes, both hosts
and routers, to be sent to some other link-layer address. This can
be done by either sending a Neighbor Solicitation with a different
source link-layer address option, or sending a Neighbor Advertisement
with a different target link-layer address option.
The attacks succeed because the Neighbor Cache entry with the new
link-layer address overwrites the old. If the spoofed link-layer
address is a valid one, as long as the attacker responds to the
unicast Neighbor Solicitation messages sent as part of the Neighbor
Unreachability Detection, packets will continue to be redirected.
This is a redirect/DoS attack.
This mechanism can be used for a DoS attack by specifying an unused
link-layer address; however, this DoS attack is of limited duration
since after 30-50 seconds (with default timer values) the Neighbor
Unreachability Detection mechanism will discard the bad link-layer
address and multicast anew to discover the link-layer address. As a
consequence, the attacker will need to keep responding with
fabricated link-layer addresses if it wants to maintain the attack
beyond the timeout.
The threat discussed in this subsection involves Neighbor
Solicitation and Neighbor Advertisement messages.
This attack is not a concern if access to the link is restricted to
trusted nodes; if a trusted node is compromised, the other nodes are
exposed to this threat. In the case where just the operator is
trusted, the nodes may rely on the operator to certify the address
bindings for other local nodes. From the security point of view, the
router may act as a trusted proxy for the other nodes. This assumes
that the router can be trusted to represent correctly the other nodes
on the link. In the ad hoc network case, and optionally in the other
two cases, the nodes may use self certifying techniques (e.g., CGA)
to authorize address bindings.