RFC 3756

IPv6 Neighbor Discovery (ND) Trust Models and Threats

📅 published May 2004, from ietf

RFC 3756: IPv6 Neighbor Discovery (ND) Trust Models and Threats 💖

okay bestie, this one is a whole vibe 🎀 it's all about who you trust on your local link and how things can go sideways ✨

Here's the title block, all the facts up front 💅

  • Series: Network Working Group 🌸
  • RFC number: 3756
  • Title: IPv6 Neighbor Discovery (ND) Trust Models and Threats
  • Authors: P. Nikander, Ed. (Ericsson Research Nomadic Lab), J. Kempf (DoCoMo USA Labs), and E. Nordmark (Sun Microsystems Laboratories) 🫶
  • Category: Informational
  • Date: May 2004
  • Obsoletes/Updates: the header has no Obsoletes or Updates lines, so this RFC doesn't obsolete or update any other RFC 🦋

Status of this Memo 🧚

okay so the vibe here is that this memo is for information only 🌈 it's Informational, so it provides information for the Internet community and it does not specify an Internet standard of any kind. no cap, anyone can share it, because distribution is unlimited 💜

the legal bit, verbatim so nobody can say I changed it 🙈

Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract 🌸

ngl this is the TL;DR and it's giving 🔥 the existing IETF standards say IPv6 Neighbor Discovery (ND) and Address Autoconfiguration may be protected with IPsec Authentication Header (AH). BUT the current specs only really let you do security with manual keying, because automatic key management has practical problems 😭 this document specifies three different trust models and talks about the threats that matter for IPv6 Neighbor Discovery. the goal 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 🎀

okay so the IPv6 Neighbor Discovery (ND) RFC 2461 [2] and Address Autoconfiguration RFC 2462 [3] mechanisms are what nodes in an IPv6 network use to learn the local topology 🦋 that includes the IP to MAC address mappings for the local nodes, the IP and MAC addresses of the routers on the local network, and the routing prefixes served by those local routers. the current specs suggest that IPsec AH RFC 2402 [1] may be used to secure these mechanisms, but they don't say how 🙈 and it looks like using current AH mechanisms is a mess because of key management problems [8] 😭

to fix this, the Secure Neighbor Discovery (SEND) working group was chartered in Fall 2002 💅 their goal is to define protocol support for securing IPv6 Neighbor Discovery without requiring excessive manual keying ✨

so this document is all about defining the types of networks where Secure IPv6 Neighbor Discovery mechanisms are expected to work, plus the threats the security protocol(s) must address 🫶 to do that, it first defines three different trust models, roughly matching secured corporate intranets, public wireless access networks, and pure ad hoc networks 🌈 then it discusses a bunch of threats through the lens of those trust models. the threat catalog is aimed to be exhaustive, but ngl some threats are probably still missing, so ideas for new threats to consider are solicited 💜

1.1. Remarks 🍓

the SEND WG charter limits the working group's scope to securing Neighbor Discovery functions 🌸 the charter also 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, these aspects were mentioned as things that may help evaluate the eventual solutions:

  • Zero configuration
  • Interaction with access control solutions
  • Scalability
  • Efficiency

but the main evaluation criteria are the trust models and threat lists 🔥 in other words, solutions are mainly judged on how well they secure networks against the identified threats, and only secondarily on configuration, access control, scalability, and efficiency 💅

IMPORTANT. this document occasionally discusses solution proposals, like Cryptographically Generated Addresses (CGA) [7] and Address Based Keys (ABK) [6]. but that discussion is solely for illustrative purposes 🧚 the goal is to give 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's worth knowing that the word "trust" is used here in a rather non-technical way 🦋 the most appropriate reading is an organizational or collective belief, meaning commonly shared beliefs about how the other involved parties will behave in the future 💜 a "trust relationship," on the other hand, is a mutual a priori relationship between the involved organizations or parties, where each side believes the other will keep behaving correctly even in the future 🌈 a trust relationship makes it possible to configure authentication and authorization information between the parties, while the lack of one makes it impossible to pre-configure that 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 in this document were already raised in those original RFCs 🎀 the recommended fix was to secure the packets with an IPsec AH [1] header. but honestly that recommendation oversimplifies things, because it leaves AH key management for future work 😭 for example, a host trying to get access to a Public Access network may or may not have the required IPsec security associations set up with that network 🙈 and in a roaming (but not necessarily mobile) situation, where a user is connecting through a service provider that isn't their home provider, the host probably won't have been preconfigured with the proper mutual trust relationship for the foreign provider's network. so it can't 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 🔥 that's because Neighbor Discovery and Address Autoconfiguration deal, to some extent, with how a host gets initial access to a link 🦋 so if a security association is required for initial access and the host doesn't have it, there's currently no standard way for the host to dynamically configure itself with that association, even if it has the necessary minimum prerequisite keying material 😩 this could cause administration headaches when things like re-keying happen 🍓

also, Neighbor Discovery and Address Autoconfiguration use a few fixed multicast addresses plus a range of 16 million "solicited node" multicast addresses 🌈 a naive use of pre-configured SAs would mean pre-configuring an unmanageable number of SAs on each host and router, just in case a given solicited node multicast address gets used. so pre-configured SAs are impractical for securing such a large potential address range 💀

3. Trust Models 💜

when you're looking at security solutions for IPv6 Neighbor Discovery (ND) [2], it's super important to keep the underlying trust models in mind ✨ the trust models defined in this section get used later on, when discussing specific threats 🎀

in what follows, the RFC 2461/RFC 2462 mechanisms are loosely split into two categories: Neighbor Discovery (ND) and Router Discovery (RD) 🌸 the former covers operations that don't 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 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 😭

  1. 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's still desirable to limit the extent of damage a node can inflict on the local network if it becomes compromised 🔥

3.1. Corporate Intranet Model 🏢💖

okay so picture a corporate intranet, or any network where every single node is under the same administrative domain 🧚. In that setup the nodes may be considered reliable at the IP layer. Once a node has been accepted as a member of the network, it's assumed to behave in a trustworthy manner. main character trust energy 💅

Under this model, if the network is physically secured, or 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) and AES encryption, may be considered secure enough and requires no further protection under this trust model ✨. ND security would still add protection depth even under this model (see below), though. And ngl, 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 has no cryptographic protection, or the cryptographic protection isn't secure enough (e.g., just 802.1x and not 802.11i in a WLAN), the nodes may be vulnerable to some or all of the threats outlined in Section 4 💀. In that case some protection is desirable to secure ND. Providing that protection is the main initial focus of the SEND working group 🌸.

It's also desirable to limit the amount of potential damage if a node becomes compromised. For example, it might still be acceptable for a compromised node to launch a denial-of-service attack. It is undesirable, though, if it can hijack existing connections or establish man-in-the-middle attacks on new connections 😭.

As mentioned in Section 2, one way 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]. Using a shared key also wouldn't protect against a compromised node, so that's a no-go 🙅‍♀️.

More specifically, the currently used key agreement protocol, IKE, suffers from a chicken-and-egg problem [8] 🥚🐔. You need an IP address to run IKE, IKE is needed to establish IPsec SAs, and IPsec SAs are required to configure an IP address. It's giving circular logic. Plus, there doesn't seem to be any easy and efficient way to secure ND with symmetric key cryptography. The required number of security associations would be very large [9] 😵‍💫.

So as an example, one possible approach to get around this limitation is to use public key cryptography and 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 totally 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 don't usually trust each other 👀. Typically the router (or routers) fall under one administrative domain, and each client node falls under its own administrative domain.

It is assumed that in 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 it belongs to the trusted operator. Depending on the link-layer authentication protocol and how it's deployed, 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 some authentication protocols, e.g., particular EAP methods, don't create secure keying material and/or don't allow the client to authenticate the network. Yikes 😬.

In this scenario, cryptographically securing the link layer does not necessarily block all the threats outlined in Section 4. See the individual threat descriptions for the details 📝. 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 knew all the nodes' link-layer addresses and could check that no source addresses were falsified, there would still be vulnerabilities 🫠.

One should also note that link-layer security and IP topology don't necessarily match. For example, the wireless access point may not be visible at the IP layer at all. In that case, cryptographic security at the link layer doesn't provide any security with regard to IP Neighbor Discovery 🙃.

There seem to be at least two ways to bring 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. In other words, the router would check ICMPv6 packet contents and filter out packets that contain information which doesn't match the network topology 🚧. The other possibly acceptable way is to add cryptographic protection to the ICMPv6 packets that carry 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 the generic case, the nodes meet each other for the first time, and there are no guarantees that the other nodes will behave correctly at the IP layer. They must be considered suspicious of sending falsified ND and RD messages 🚨.

Since there are no a priori trust relationships, the nodes can't rely on traditional authentication. Traditional authentication protocols depend on some existing relationship between the parties. That relationship may be direct or indirect. The indirect case relies on one or more trusted third parties, which creates a chain of trust relationships between the parties 🔗.

In the generic ad hoc network case, there are no trusted third parties, and the parties don't trust each other directly either. So the traditional way of first authenticating and then authorizing users (to use their addresses) just doesn't work 😤.

It's still possible to use self-identifying mechanisms, such as Cryptographically Generated Addresses (CGA) [7] 🪪. These allow the nodes to make sure they're talking to the same nodes (as before) at all times, and that each node really did generate its own IP address and didn't "steal" someone else's 🕵️‍♀️. It may also be possible to learn the identities of any routers using various kinds of heuristics, such as testing a 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 🛡️.

In this section we talk about threats against the current IPv6 Neighbor Discovery mechanisms when they're used on multi-access links 📡. The threats are discussed in 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 too. The node the packets were redirected to can drop them, either completely or by selectively forwarding some and not others 🗑️.

The subsections below identify specific threats for IPv6 network access 🎀. The threat descriptions are organized into three subsections. First we consider threats that don't involve routers or routing information. Next we consider threats that do involve routers or routing information. Finally, we consider replay attacks and threats that can be exploited remotely 🧚‍♀️. All threats are discussed in light of the trust models.

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 ✨

okay so nodes on the link use Neighbor Solicitation and Advertisement messages to create bindings between IP addresses and MAC addresses 🔗💖. There are two situations where a node creates neighbor cache entries when it gets 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, that's a collision, and the node must cease to solicit for the said address 🙈.

Solicitation messages only create or modify state in these specific moments. State is usually modified whenever a node receives a solicited-for advertisement message 🦋.

An attacking node can cause packets meant for legitimate nodes, both hosts and routers, to get sent to some other link-layer address 😭. It can do this by sending a Neighbor Solicitation with a different source link-layer address option, or by sending a Neighbor Advertisement with a different target link-layer address option.

These attacks work because the Neighbor Cache entry with the new link-layer address overwrites the old one 💀. If the spoofed link-layer address is a valid one, then as long as the attacker keeps responding to the unicast Neighbor Solicitation messages sent as part of the Neighbor Unreachability Detection, packets will keep getting redirected. This is a redirect/DoS attack 🔥.

This mechanism can be used for a DoS attack by specifying an unused link-layer address. Still, this DoS attack only lasts a limited time, 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 🕰️. So the attacker will need to keep responding with fabricated link-layer addresses if it wants to keep the attack going past the timeout.

The threat in this subsection involves Neighbor Solicitation and Neighbor Advertisement messages 💜.

This attack isn't a concern if access to the link is restricted to trusted nodes. But if a trusted node gets 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 a 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 correctly represent 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 🔐.

Also, 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 figure out whether peer nodes are still reachable. But if there's a sufficiently long delay on upper-layer traffic, or if the node stops receiving replies from a peer node, the NUD procedure gets 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 gets no reply, it tries a few more times, and eventually deletes 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 became unreachable in the first place, and how the target node would behave if it knew that the node had become unreachable. This is a DoS attack 💥.

The threat in this subsection involves Neighbor Solicitation/Advertisement messages 💅.

This attack isn't a concern if access to the link is restricted to trusted nodes. But if a trusted node gets 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 tell the difference between genuine and fabricated NA responses 🕵️‍♀️.

4.1.3. Duplicate Address Detection DoS Attack 🎀

In networks where entering hosts get 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 get an address. The attacker can claim the address in two ways. It can either reply with an NS, pretending it's performing DAD too, or it can reply with an NA, pretending it has already taken the address into use 🎭. This threat was identified in RFC 2462 [3]. The issue may also show up when other types of address configuration are used, i.e., whenever DAD is invoked before actually configuring the suggested address. This is a DoS attack 🙃.

The threat in this subsection involves Neighbor Solicitation/Advertisement messages 🌈.

This attack isn't a concern if access to the link is restricted to trusted nodes. But if a trusted node gets 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's 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 🧚. So 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 look at threats relevant 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, not one specific to Mobile IPv6. It's also identified in RFC 2461 [2]. This threat is a redirect/DoS attack 🔀.

An attacking node on the same subnet as a host trying to discover a legitimate last hop router could pretend to be an IPv6 last hop router. It can do this by multicasting legitimate-looking IPv6 Router Advertisements, or by 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 gets the chance to siphon off traffic from the host, or mount a man-in-the-middle attack 😈. The attacker could make sure the entering host picks itself as the default router by multicasting periodic Router Advertisements for the real last hop router with a lifetime of zero. This may trick the entering host into believing that the real access router isn't willing to take any traffic. Once accepted as a legitimate router, the attacker could send Redirect messages to hosts, then disappear, 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, doesn't contain such a rule 🥺.

The threat in this subsection involves Router Advertisement and Router Advertisement Solicitation messages 💖.

This attack isn't a concern if access to the link is restricted to trusted nodes. But if a trusted node gets compromised, the other nodes are exposed to this threat 😰. However, the threat can be partially mitigated in a number of ways, for example by configuring the nodes to prefer existing routers over new ones. Note that this approach doesn't necessarily stop someone from introducing new routers into the network, depending on the details of the implementation. At minimum, it just makes the existing nodes prefer the existing routers over the new ones 🛡️.

In the case of a trusted operator, there must be a means for the nodes to tell apart trustworthy routers, run by the operator, from other nodes 🔍. There are currently no widely accepted solutions for the ad hoc network case, so the issue remains a research question 🧪.

4.2.2. Default router is 'killed' 💀

In this attack, an attacker 'kills' the default router(s), which makes the nodes on the link assume that all nodes are local 😱. Section 5.2 of RFC 2461 [2] says that "[if] the Default Router List is empty, the sender assumes that the destination is on-link." So if the attacker can make a node believe 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 an attacker can 'kill' the default router(s). One is to launch a classic DoS attack against the router so it no longer appears responsive. Another 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 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 isn't a concern if access to the link is restricted to trusted nodes. But if a trusted node gets 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 tell apart trustworthy routers, run by the operator, from 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 a research question 🌷.

Thanks to Alain Durand for identifying this threat 🫶✨.

4.2.3. Good Router Goes Bad 💔

Okay so this one is giving betrayal arc 😭. A router that used to be trusted gets compromised. The attacks available are the exact same ones from Section 4.2.1, so it's a redirect/DoS attack 🙈. Lowkey scary because the router was trusted.

There are currently no known solutions for any of the three trust models we covered 💀. On a multi-router link, you could imagine a fix where router rights get revoked 👑, but that's still a research question. Not solved yet, bestie 🧚.

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 ✨. Here's the sneaky part: the attacker uses the link-local address of the current first-hop router, then sends a Redirect message to a legitimate host. The host sees the link-local address and thinks "oh, that's my first hop router, I trust it" and accepts the Redirect 😤.

And it doesn't stop there. As long as the attacker keeps responding to Neighbor Unreachability Detection probes at its link-layer address, the Redirect stays in effect forever 💅. Redirect/DoS attack, obviously.

The threat in this subsection involves Redirect messages 🦋.

This attack isn't a concern if access to the link is restricted to trusted nodes. But if a trusted node gets compromised, the other nodes are exposed to this threat 😬. With a trusted operator, there must be a means for nodes to tell trustworthy routers (the ones run by the operator) apart from other nodes 🫶. In the ad hoc network case, there are currently no widely accepted solutions, so this one is still a research question 🔍.

An attacking node can send a Router Advertisement message saying some prefix of arbitrary length is on-link 🙃. If a sending host believes the prefix is on-link, it will never send packets for that prefix to the router. Instead, it tries to do address resolution by sending Neighbor Solicitations, but those never get a response. Result: the attacked host gets denied service 💀. DoS attack.

The attacker can pick any lifetime for the bogus prefix advertisement 🌀. If the lifetime is infinity, the host stays denied service until it loses the state in its prefix list, for example by rebooting, or until the same prefix is advertised with a zero lifetime. The attacker can also target selectively: by using 128-bit prefixes (basically full addresses), they can attack packets destined for one particular address only 🎯.

On top of that, the attack can flood the node's routing table 🌊. The node can't tell legit on-link prefixes from bogus ones when deciding which to keep and which to drop. Every finite system eventually has to reach a point where newly received prefixes get dropped instead of accepted, so there's a limit no matter what 🧱.

This attack can turn into a redirect attack too. If the attacker answers the Neighbor Solicitations with spoofed Neighbor Advertisements, it lures nodes on the link into sending their traffic to it, or to some other node 🪤.

This threat involves Router Advertisement messages. The extended attack combines the attack from Section 4.1.1 with this section, so it involves Neighbor Solicitation, Neighbor Advertisement, and Router Advertisement messages 🧩.

Again, this isn't a concern if access to the link is restricted to trusted nodes. If a trusted node is compromised, the other nodes are exposed 😩. With a trusted operator, there must be a means for nodes to distinguish trustworthy operator-run routers from other nodes. For the ad hoc network case, there are currently no known solutions, so it remains a research question 📚.

As an example, one possible way to limit the damage is to require that advertised on-link prefixes be /64s. Otherwise it's super easy to advertise something short like 0/0, and then this attack is very easy 🥺.

4.2.6. Bogus Address Configuration Prefix 🏷️

An attacking node can send a Router Advertisement message with an invalid subnet prefix for a host to use in address autoconfiguration 😵. A host running the address autoconfiguration algorithm builds an address from the advertised prefix [3], even though that address isn't valid for the subnet. So return packets never reach the host, because its source address is invalid. DoS attack, periodt 💀.

This can spread beyond the attacked host. If the host does a dynamic update to the DNS based on the bogus constructed address, the DNS update [4] adds that bogus address to the host's address record 📝. After that, applications resolving the name through DNS get the bogus address, and contacting the host fails. The good news is that well-written applications fall back and try the other addresses registered in DNS, which might be correct 🙌.

A distributed attacker can make it worse by creating a falsified reverse DNS entry that matches the dynamic DNS entry the target creates 😈. Picture this: the attacker has legit access to a prefix <ATTACK_PRFX>, and the target has an interface ID <TARGET_IID>. The attacker makes a reverse DNS entry for <ATTACK_PRFX>:<TARGET_IID>, pointing to the target's real domain name, like "secure.target.com". Then the attacker advertises the <ATTACK_PRFX> prefix on the target's link. The target creates the address <ATTACK_PRFX>:<TARGET_IID> and updates its DNS so that "secure.target.com" points to <ATTACK_PRFX>:<TARGET_IID> 😱.

Now "secure.target.com" points to <ATTACK_PRFX>:<TARGET_IID>, and <ATTACK_PRFX>:<TARGET_IID> points back to "secure.target.com" 🔁. This threat is mitigated by the fact that the attacker can be traced, since the owner of <ATTACK_PRFX> is available in the registries 🕵️‍♀️.

There's also a related possibility. An attacker can advertise a target prefix as an autoconfiguration prefix on a busy link, so all the nodes on that link try to talk to the outside world using this address 📣. If the local router doesn't have ingress filtering on, the target link may get a huge number of replies to those first communication attempts 📬.

The basic threat here involves Router Advertisement messages. The extended attack scenarios involve the DNS too 🌐.

Once more, this isn't 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 😮‍💨. With a trusted operator, there must be a means for nodes to tell trustworthy operator-run routers apart from other nodes. For the ad hoc network case, there are currently no known solutions, so it's still a research question 🧪.

4.2.7. Parameter Spoofing 🎛️

IPv6 Router Advertisements carry a few parameters that hosts use when they send packets, and they also tell hosts whether they should do stateful address configuration [2]. An attacking node could send a valid-seeming Router Advertisement that copies the one from the legit default router, except the parameters are designed to wreck legitimate traffic 💥. DoS attack, obviously.

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 runs a bogus DHCPv6 server or relay and sets the 'M' and/or 'O' flag, which says stateful address configuration and/or stateful configuration of other parameters should be done. Now the attacker can answer a legit host's stateful configuration queries with its own bogus replies 🎣.

The threat in this subsection involves Router Advertisement messages 🦋.

Important note: securing DHCP alone does NOT fix this problem, and there are two reasons 🙅‍♀️. First, the attacker may stop the node from using DHCP in the first place. Second, depending on the node's local configuration, the attacker may trick the node into using a less trusted DHCP server. (That second one is a variant of the so-called "bidding down" or "down grading" attacks 📉.)

As an example, one possible way to mitigate this threat is to ignore very small hop limits. Nodes could implement a configurable minimum hop limit and ignore attempts to set it below that limit 🛡️.

This attack isn't 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 😤. With a trusted operator, there must be a means for nodes to tell trustworthy operator-run routers apart from other nodes. For the ad hoc network case, there are currently no known solutions, so 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 😬. Even if they're cryptographically protected so their contents can't be forged, an attacker can still capture valid messages and replay them later. So no matter what mechanism you pick to secure the messages, that mechanism must be protected against replay attacks too 🔐.

The good news: it's pretty easy to defeat most replay attacks 🙌. In request-reply exchanges, like Solicitation-Advertisement, the request can include a nonce that must also appear in the reply. That way, old replies aren't valid, since they don't contain the right nonce 🎟️. For stand-alone messages, like unsolicited Advertisements or Redirect messages, you can protect them with timestamps or counters ⏱️. In practice, roughly synchronized clocks and timestamps seem to work well, because recipients can keep track of the difference between the clocks of different nodes and make sure every new message is newer than the last one they saw ✨.

### 4.3.2. Neighbor Discovery DoS Attack 💀

okay so in this one, the attacker just starts making up addresses that have the real subnet prefix, then keeps firing packets at them 😭 the last hop router is basically obligated to try resolving every single one by sending neighbor solicitation packets. so a legit host trying to join the network might not get Neighbor Discovery service from that router, because it's already buried under all the other solicitations 🫠

this one hits different from the others bc the attacker can be off-link 👀 the thing getting attacked is the conceptual neighbor cache, which gets stuffed with attempts to resolve IPv6 addresses that have a valid prefix but a made-up suffix. it's a DoS attack, full stop 💅

the threat in this subsection involves Neighbor Solicitation messages 🌸

this attack doesn't directly involve the trust models we covered. BUT if access to the link is restricted to registered nodes, and the access router keeps track of which nodes registered for access on the link, the attack may be trivially plugged 🦋 the catch is that no such mechanisms are currently standardized, so 🥲

ngl this problem is pretty similar to the TCP SYN flooding problem 🧚 some things that may be applied are rate limiting Neighbor Solicitations, restricting how much state gets reserved for unresolved solicitations, and clever cache management ✨

also both hosts AND routers need to worry about this 🫶 we already talked about the router case above. hosts are vulnerable too, because the neighbor discovery process can get abused by an application that's tricked into sending packets to arbitrary on-link destinations. not me being dramatic, it's literally a thing 😤

4.4. Summary of the attacks 🍓

here's the big cheat sheet, bestie 🎀

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 the 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.

Quick note: the plus sign '+' does not mean there's a ready-to-go, standardized solution 🙅‍♀️ if those existed, this document would be unnecessary lol. it just means the authors think the problem has been solved in principle, and there's a publication describing some approach, or a solution could be made by straightforwardly applying known research and/or engineering results 💖

and then R means the authors aren't aware of any publication describing a solution, and can't think of any simple, easy extension of known research and/or engineering results that would fix it 😭

+-------+----------------------+-----+-------+-------+---+---+---+
| 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

Footnotes, because the table needs context 🧐

  1. It is possible to protect the Router Advertisements, which closes one variant of this attack. However, closing the other variant (overloading the router) doesn't seem plausible within the scope of this working group 🫠
  2. Note that the extended attack in Section 4.2.5 combines sending a bogus on-link prefix AND performing NS/NA spoofing as per Section 4.1.1. so 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 that comes from blindly registering the new address via DNS update [4] is not considered an ND security issue here. it should still be noted as a possible vulnerability in implementations 👀

For a slightly different approach, see also Section 7 in [9]. Honestly the table in Section 7.7 of [9] is so good, go read it 🌈

5. Security Considerations 🔥

This document discusses security threats to network access in IPv6. As such, it is concerned entirely with security. no notes, it's giving serious security energy 🔒💜

6. Acknowledgements 🫶

Thanks to Alper Yegin of DoCoMo Communications Laboratories USA for identifying the Neighbor Discovery DoS attack 🙌 We would also like to thank Tuomas Aura and Michael Roe of Microsoft Research Cambridge, as well as Jari Arkko and Vesa-Matti Mantyla of Ericsson Research Nomadiclab, for discussing some of the threats with us 💖

Thanks to Alper Yegin, Pekka Savola, Bill Sommerfeld, Vijay Devaparalli, Dave Thaler, and Alain Durand for their constructive comments ✨

Thanks to Craig Metz for his numerous very good comments 🥹 and especially for more material on implementations that refuse to accept ND overrides, for the bogus on-link prefix threat, and for reminding us about replay attacks 🧚

7. Informative References 📚

  • [1] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
  • [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
  • [3] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
  • [4] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
  • [5] Mankin, A., "Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6", Work in Progress.
  • [6] Kempf, J., Gentry, C. and A. Silverberg, "Securing IPv6 Neighbor Discovery Using Address Based Keys (ABKs)", Work in Progress, June 2002.
  • [7] Roe, M., "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", Work in Progress, March 2002.
  • [8] Arkko, J., "Effects of ICMPv6 on IKE", Work in Progress, March 2003.
  • [9] Arkko, J., "Manual Configuration of Security Associations for IPv6 Neighbor Discovery", Work in Progress, March 2003.

Authors' Addresses 🎀

Pekka Nikander (editor)
Ericsson Research Nomadic Lab
JORVAS  FIN-02420
FINLAND

Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com


James Kempf
DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA  95110
USA

Phone: +1 408 451 4711
EMail: kempf@docomolabs-usa.com


Erik Nordmark
Sun Microsystems
17 Network Circle
Menlo Park, CA 94043
USA

Phone: +1 650 786 2921
EMail: erik.nordmark@sun.com

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🧠

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. Nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💜

Funding for the RFC Editor function is currently provided by the Internet Society. ✨🌈

📦 where this page comes from