Additionally, some implementations log an error and refuse to accept
ND overwrites, instead requiring the old entry to time out first.
4.1.2. Neighbor Unreachability Detection (NUD) failure
Nodes on the link monitor the reachability of local destinations and
routers with the Neighbor Unreachability Detection procedure [2].
Normally the nodes rely on upper-layer information to determine
whether peer nodes are still reachable. However, if there is a
sufficiently long delay on upper-layer traffic, or if the node stops
receiving replies from a peer node, the NUD procedure is invoked.
The node sends a targeted NS to the peer node. If the peer is still
reachable, it will reply with a NA. However, if the soliciting node
receives no reply, it tries a few more times, eventually deleting the
neighbor cache entry. If needed, this triggers the standard address
resolution protocol to learn the new MAC address. No higher level
traffic can proceed if this procedure flushes out neighbor cache
entries after determining (perhaps incorrectly) that the peer is not
reachable.
A malicious node may keep sending fabricated NAs in response to NUD
NS messages. Unless the NA messages are somehow protected, the
attacker may be able to extend the attack for a long time using this
technique. The actual consequences depend on why the node become
unreachable for the first place, and how the target node would behave
if it knew that the node has become unreachable. This is a DoS
attack.
The threat discussed in this subsection involves Neighbor
Solicitation/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 DoS threat. Under the two other trust models, a
solution requires that the node performing NUD is able to make a
distinction between genuine and fabricated NA responses.
4.1.3. Duplicate Address Detection DoS Attack
In networks where the entering hosts obtain their addresses using
stateless address autoconfiguration [3], an attacking node could
launch a DoS attack by responding to every duplicate address
detection attempt made by an entering host. If the attacker claims
the address, then the host will never be able to obtain an address.
The attacker can claim the address in two ways: it can either reply
with an NS, simulating that it is performing DAD, too, or it can
reply with an NA, simulating that it has already taken the address
into use. This threat was identified in RFC 2462 [3]. The issue may
also be present when other types of address configuration is used,
i.e., whenever DAD is invoked prior to actually configuring the
suggested address. This is a DoS attack.
The threat discussed in this subsection involves Neighbor
Solicitation/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
become exposed to this DoS threat. Under the two other trust models,
a solution requires that the node performing DAD is able to verify
whether the sender of the NA response is authorized to use the given
IP address or not. In the trusted operator case, the operator may
act as an authorizer, keeping track of allocated addresses and making
sure that no node has allocated more than a few (hundreds of)
addresses. On the other hand, it may be detrimental to adopt such a
practice, since there may be situations where it is desirable for one
node to have a large number of addresses, e.g., creating a separate
address per TCP connection, or when running an ND proxy. Thus, it
may be inappropriate to suggest that ISPs could control how many
addresses a legitimate host can have; the discussion above must be
considered only as examples, as stated in the beginning of this
document.
In the ad hoc network case one may want to structure the addresses in
such a way that self authorization is possible.
4.2. Router/routing involving threats
In this section we consider threats pertinent to router discovery or
other router assisted/related mechanisms.
4.2.1. Malicious Last Hop Router
This threat was identified in [5] but was classified as a general
IPv6 threat and not specific to Mobile IPv6. It is also identified
in RFC 2461 [2]. This threat is a redirect/DoS attack.
An attacking node on the same subnet as a host attempting to discover
a legitimate last hop router could masquerade as an IPv6 last hop
router by multicasting legitimate-looking IPv6 Router Advertisements
or unicasting Router Advertisements in response to multicast Router
Advertisement Solicitations from the entering host. If the entering
host selects the attacker as its default router, the attacker has the
opportunity to siphon off traffic from the host, or mount a man-in-
the-middle attack. The attacker could ensure that the entering host
selected itself as the default router by multicasting periodic Router
Advertisements for the real last hop router having a lifetime of
zero. This may spoof the entering host into believing that the real
access router is not willing to take any traffic. Once accepted as a
legitimate router, the attacker could send Redirect messages to
hosts, then disappear, thus covering its tracks.
This threat is partially mitigated in RFC 2462; in Section 5.5.3 of
RFC 2462 it is required that if the advertised prefix lifetime is
less than 2 hours and less than the stored lifetime, the stored
lifetime is not reduced unless the packet was authenticated.
However, the default router selection procedure, as defined in
Section 6.3.6. of RFC 2461, does not contain such a rule.
The threat discussed in this subsection involves Router Advertisement
and Router Advertisement Solicitation 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. However, the threat can be partially
mitigated through a number of means, for example, by configuring the
nodes to prefer existing routers over new ones. Note that this
approach does not necessarily prevent one from introducing new
routers into the network, depending on the details of implementation.
At minimum, it just makes the existing nodes to prefer the existing
routers over the new ones.
In the case of a trusted operator, there must be a means for the
nodes to make a distinction between trustworthy routers, run by the
operator, and other nodes. There are currently no widely accepted
solutions for the ad hoc network case, and the issue remains as a
research question.
4.2.2. Default router is ’killed’
In this attack, an attacker ’kills’ the default router(s), thereby
making the nodes on the link to assume that all nodes are local. In
Section 5.2 of RFC 2461 [2] it is stated that "[if] the Default
Router List is empty, the sender assumes that the destination is on-
link." Thus, if the attacker is able to make a node to believe that
there are no default routers on the link, the node will try to send
the packets directly, using Neighbor Discovery. After that the
attacker can use NS/NA spoofing even against off-link destinations.
There are a few identified ways how an attacker can ’kill’ the
default router(s). One is to launch a classic DoS attack against the
router so that it does not appear responsive any more. The other is
to send a spoofed Router Advertisement with a zero Router Lifetime
(see Section 6.3.4 of RFC 2461 [2]). However, see also the
discussion in Section 4.2.1, above.
This attack is mainly a DoS attack, but it could also be used to
redirect traffic to the next better router, which may be the
attacker.
The threat discussed in this subsection involves Router Advertisement
messages. One variant of this threat may be possible by overloading
the router, without using any ND/RD 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 of a trusted operator, there
must be a means for the nodes to make a distinction between
trustworthy routers, run by the operator, and other nodes. That
protects against spoofed Router Advertisements, but it does not
protect against router overloading. There are currently no widely
accepted solutions for the ad hoc network case, and the issue remains
as a research question.
Thanks to Alain Durand for identifying this threat.
4.2.3. Good Router Goes Bad
In this attack, a router that previously was trusted is compromised.
The attacks available are the same as those discussed in Section
4.2.1. This is a redirect/DoS attack.
There are currently no known solutions for any of the presented three
trust models. On the other hand, on a multi-router link one could
imagine a solution involving revocation of router rights. The
situation remains as a research question.
4.2.4. Spoofed Redirect Message
The Redirect message can be used to send packets for a given
destination to any link-layer address on the link. The attacker uses
the link-local address of the current first-hop router in order to
send a Redirect message to a legitimate host. Since the host
identifies the message by the link-local address as coming from its
first hop router, it accepts the Redirect. As long as the attacker
responds to Neighbor Unreachability Detection probes to the link-
layer address, the Redirect will remain in effect. This is a
redirect/DoS attack.
The threat discussed in this subsection involves Redirect 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 of a trusted operator, there
must be a means for the nodes to make a distinction between
trustworthy routers, run by the operator, and other nodes. There are
currently no widely accepted solutions for the ad hoc network case,
and the issue remains as a research question.
4.2.5. Bogus On-Link Prefix
An attacking node can send a Router Advertisement message specifying
that some prefix of arbitrary length is on-link. If a sending host
thinks the prefix is on-link, it will never send a packet for that
prefix to the router. Instead, the host will try to perform address
resolution by sending Neighbor Solicitations, but the Neighbor
Solicitations will not result in a response, denying service to the
attacked host. This is a DoS attack.
The attacker can use an arbitrary lifetime on the bogus prefix
advertisement. If the lifetime is infinity, the sending host will be
denied service until it loses the state in its prefix list e.g., by
rebooting, or after the same prefix is advertised with a zero
lifetime. The attack could also be perpetrated selectively for
packets destined to a particular prefix by using 128 bit prefixes,
i.e., full addresses.
Additionally, the attack may cause a denial-of-service by flooding
the routing table of the node. The node would not be able to
differentiate between legitimate on-link prefixes and bogus ones when
making decisions as to which ones are kept and which are dropped.
Inherently, any finite system must have some point at which new
received prefixes must be dropped rather than accepted.
This attack can be extended into a redirect attack if the attacker
replies to the Neighbor Solicitations with spoofed Neighbor
Advertisements, thereby luring the nodes on the link to send the
traffic to it or to some other node.
This threat involves Router Advertisement message. The extended
attack combines the attack defined in Section 4.1.1 and in this
section, and involves Neighbor Solicitation, Neighbor Advertisement,
and Router 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 of a trusted operator, there
must be a means for the nodes to make a distinction between
trustworthy routers, run by the operator, and other nodes. There are
currently no known solutions for the ad hoc network case, and the
issue remains as a research question.
As an example, one possible approach to limiting the damage of this
attack is to require advertised on-link prefixes be /64s (otherwise
it’s easy to advertise something short like 0/0 and this attack is
very easy).
4.2.6. Bogus Address Configuration Prefix
An attacking node can send a Router Advertisement message specifying
an invalid subnet prefix to be used by a host for address
autoconfiguration. A host executing the address autoconfiguration
algorithm uses the advertised prefix to construct an address [3],
even though that address is not valid for the subnet. As a result,
return packets never reach the host because the host’s source address
is invalid. This is a DoS attack.
This attack has the potential to propagate beyond the immediate
attacked host if the attacked host performs a dynamic update to the
DNS based on the bogus constructed address. DNS update [4] causes
the bogus address to be added to the host’s address record in the
DNS. Should this occur, applications performing name resolution
through the DNS obtain the bogus address and an attempt to contact
the host fails. However, well-written applications will fall back
and try the other addresses registered in DNS, which may be correct.
A distributed attacker can make the attack more severe by creating a
falsified reverse DNS entry that matches with the dynamic DNS entry
created by the target. Consider an attacker who has legitimate
access to a prefix <ATTACK_PRFX>, and a target who has an interface
ID <TARGET_IID>. The attacker creates a reverse DNS entry for
<ATTACK_PRFX>:<TARGET_IID>, pointing to the real domain name of the
target, e.g., "secure.target.com". Next the attacker advertises the
<ATTACK_PRFX> prefix at the target’s link. The target will create an
address <ATTACK_PRFX>:<TARGET_IID>, and update its DNS entry so that
"secure.target.com" points to <ATTACK_PRFX>:<TARGET_IID>.
At this point "secure.target.com" points to
<ATTACK_PRFX>:<TARGET_IID>, and <ATTACK_PRFX>:<TARGET_IID> points to
"secure.target.com". This threat is mitigated by the fact that the
attacker can be traced since the owner of the <ATTACK_PRFX> is
available at the registries.
There is also a related possibility of advertising a target prefix as
an autoconfiguration prefix on a busy link, and then have all nodes
on this link try to communicate to the external world with this
address. If the local router doesn’t have ingress filtering on, then
the target link may get a large number of replies for those initial
communication attempts.
The basic threat discussed in this subsection involves Router
Advertisement messages. The extended attack scenarios involve the
DNS, too.
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 of a trusted operator, there
must be a means for the nodes to make a distinction between
trustworthy routers, run by the operator, and other nodes. There are
currently no known solutions for the ad hoc network case, and the
issue remains as a research question.
4.2.7. Parameter Spoofing
IPv6 Router Advertisements contain a few parameters used by hosts
when they send packets and to tell hosts whether or not they should
perform stateful address configuration [2]. An attacking node could
send out a valid-seeming Router Advertisement that duplicates the
Router Advertisement from the legitimate default router, except the
included parameters are designed to disrupt legitimate traffic. This
is a DoS attack.
Specific attacks include:
1. The attacker includes a Current Hop Limit of one or another small
number which the attacker knows will cause legitimate packets to
be dropped before they reach their destination.
2. The attacker implements a bogus DHCPv6 server or relay and the
’M’ and/or ’O’ flag is set, indicating that stateful address
configuration and/or stateful configuration of other parameters
should be done. The attacker is then in a position to answer the
stateful configuration queries of a legitimate host with its own
bogus replies.
The threat discussed in this subsection involves Router Advertisement
messages.
Note that securing DHCP alone does not resolve this problem. There
are two reasons for this. First, the attacker may prevent the node
from using DHCP in the first place. Second, depending on the node’s
local configuration, the attacker may spoof the node to use a less
trusted DHCP server. (The latter is a variant of the so called
"bidding down" or "down grading" attacks.)
As an example, one possible approach to mitigate this threat is to
ignore very small hop limits. The nodes could implement a
configurable minimum hop limit, and ignore attempts to set it below
said limit.
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 treat. In the case of a trusted operator, there must
be a means for the nodes to make a distinction between trustworthy
routers, run by the operator, and other nodes. There are currently
no known solutions for the ad hoc network case, and the issue remains
a research question.
4.3. Replay attacks and remotely exploitable attacks
4.3.1. Replay attacks
All Neighbor Discovery and Router Discovery messages are prone to
replay attacks. That is, even if they were cryptographically
protected so that their contents cannot be forged, an attacker would
be able to capture valid messages and replay them later. Thus,
independent on what mechanism is selected to secure the messages,
that mechanism must be protected against replay attacks.
Fortunately it is fairly easy to defeat most replay attacks. In
request-reply exchanges, such as Solicitation-Advertisement, the
request may contain a nonce that must appear also in the reply.
Thus, old replies are not valid since they do not contain the right
nonce. Correspondingly, stand-alone messages, such as unsolicited
Advertisements or Redirect messages, may be protected with timestamps
or counters. In practise, roughly synchronized clocks and timestamps
seem to work well, since the recipients may keep track of the
difference between the clocks of different nodes, and make sure that
all new messages are newer than the last seen message.
4.3.2. Neighbor Discovery DoS Attack
In this attack, the attacking node begins fabricating addresses with
the subnet prefix and continuously sending packets to them. The last
hop router is obligated to resolve these addresses by sending
neighbor solicitation packets. A legitimate host attempting to enter
the network may not be able to obtain Neighbor Discovery service from
the last hop router as it will be already busy with sending other
solicitations. This DoS attack is different from the others in that
the attacker may be off-link. The resource being attacked in this
case is the conceptual neighbor cache, which will be filled with
attempts to resolve IPv6 addresses having a valid prefix but invalid
suffix. This is a DoS attack.
The threat discussed in this subsection involves Neighbor
Solicitation messages.
This attack does not directly involve the trust models presented.
However, if access to the link is restricted to registered nodes, and
the access router keeps track of nodes that have registered for
access on the link, the attack may be trivially plugged. However, no
such mechanisms are currently standardized.
In a way, this problem is fairly similar to the TCP SYN flooding
problem. For example, rate limiting Neighbor Solicitations,
restricting the amount of state reserved for unresolved
solicitations, and clever cache management may be applied.
It should be noted that both hosts and routers need to worry about
this problem. The router case was discussed above. Hosts are also
vulnerable since the neighbor discovery process can potentially be
abused by an application that is tricked into sending packets to
arbitrary on-link destinations.
4.4. Summary of the attacks
Columns:
N/R Neighbor Discovery (ND) or Router Discovery (RD) attack
R/D Redirect/DoS (Redir) or just DoS attack
Msgs Messages involved in the attack: NA, NS, RA, RS, Redir
1 Present in trust model 1 (corporate intranet)
2 Present in trust model 2 (public operator run network)
3 Present in trust model 3 (ad hoc network)
Symbols in trust model columns:
- The threat is not present or not a concern.
+ The threat is present and at least one solution is known.
R The threat is present but solving it is a research problem.
Note that the plus sign ’+’ in the table does not mean that there is
a ready-to-be-applied, standardized solution. If solutions existed,
this document would be unnecessary. Instead, it denotes that in the
authors’ opinion the problem has been solved in principle, and there
exists a publication that describes some approach to solve the
problem, or a solution may be produced by straightforward application
of known research and/or engineering results.
In the other hand, and ’R’ indicates that the authors’ are not aware
of any publication describing a solution to the problem, and cannot
at the time of writing think about any simple and easy extension of
known research and/or engineering results to solve the problem.
+-------+----------------------+-----+-------+-------+---+---+---+
| Sec | Attack name | N/R | R/D | Msgs | 1 | 2 | 3 |
+-------+----------------------+-----+-------+-------+---+---+---+
| 4.1.1 | NS/NA spoofing | ND | Redir | NA NS | + | + | + |
| 4.1.2 | NUD failure | ND | DoS | NA NS | - | + | + |
| 4.1.3 | DAD DoS | ND | DoS | NA NS | - | + | + |
+-------+----------------------+-----+-------+-------+---+---+---+
| 4.2.1 | Malicious router | RD | Redir | RA RS | + | + | R |
| 4.2.2 | Default router killed| RD | Redir | RA |+/R|+/R| R | 1)
| 4.2.3 | Good router goes bad | RD | Redir | RA RS | R | R | R |
| 4.2.4 | Spoofed redirect | RD | Redir | Redir | + | + | R |
| 4.2.5 | Bogus on-link prefix | RD | DoS | RA | - | + | R | 2)
| 4.2.6 | Bogus address config | RD | DoS | RA | - | + | R | 3)
| 4.2.7 | Parameter spoofing | RD | DoS | RA | - | + | R |
+-------+----------------------+-----+-------+-------+---+---+---+
| 4.3.1 | Replay attacks | All | Redir | All | + | + | + |
| 4.3.2 | Remote ND DoS | ND | DoS | NS | + | + | + |
+------------------------------+-----+-------+-------+---+---+---+
Figure 1
1. It is possible to protect the Router Advertisements, thereby
closing one variant of this attack. However, closing the other
variant (overloading the router) does not seem to be plausible
within the scope of this working group.
2. Note that the extended attack defined in Section 4.2.5 combines
sending a bogus on-link prefix and performing NS/NA spoofing as
per Section 4.1.1. Thus, if the NA/NS exchange is secured, the
ability to use Section 4.2.5 for redirect is most probably
blocked, too.
3. The bogus DNS registration resulting from blindly registering the
new address via DNS update [4] is not considered an ND security
issue here. However, it should be noted as a possible