diff options
Diffstat (limited to 'doc/rfc/rfc3756.txt')
| -rw-r--r-- | doc/rfc/rfc3756.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc3756.txt b/doc/rfc/rfc3756.txt new file mode 100644 index 0000000..d6acb2a --- /dev/null +++ b/doc/rfc/rfc3756.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group P. Nikander, Ed. +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 + + + +Nikander, et al. Informational [Page 1] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + + 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. + + + + + + + + +Nikander, et al. Informational [Page 2] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + +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. + + + + + + +Nikander, et al. Informational [Page 3] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + +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. + + + + + + + +Nikander, et al. Informational [Page 4] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + + 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 + + + +Nikander, et al. Informational [Page 5] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + + 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 + + + +Nikander, et al. Informational [Page 6] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + + 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. + + + + +Nikander, et al. Informational [Page 7] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + + 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. + + + +Nikander, et al. Informational [Page 8] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + + 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. + + + +Nikander, et al. Informational [Page 9] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + + 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. + + 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 + + + + +Nikander, et al. Informational [Page 10] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + + 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. + + + + +Nikander, et al. Informational [Page 11] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + + 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. + + + +Nikander, et al. Informational [Page 12] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + + 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. + + + + + + + + +Nikander, et al. Informational [Page 13] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + +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 + + + + +Nikander, et al. Informational [Page 14] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + + 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 + + + +Nikander, et al. Informational [Page 15] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + + 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 + + + + +Nikander, et al. Informational [Page 16] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + + 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 + + + + +Nikander, et al. Informational [Page 17] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + + 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. + + + +Nikander, et al. Informational [Page 18] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + +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. + + + + + + + + + + + + + + + +Nikander, et al. Informational [Page 19] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + + +-------+----------------------+-----+-------+-------+---+---+---+ + | 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 + vulnerability in implementations. + + For a slightly different approach, see also Section 7 in [9]. + Especially the table in Section 7.7 of [9] is very good. + +5. Security Considerations + + This document discusses security threats to network access in IPv6. + As such, it is concerned entirely with security. + + + + + + + +Nikander, et al. Informational [Page 20] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + +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 of 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. + + + + + +Nikander, et al. Informational [Page 21] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + +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 + + + + + + + + + + + + + + + + + + + + + + +Nikander, et al. Informational [Page 22] + +RFC 3756 IPv6 ND Trust Models and Threats May 2004 + + +Full Copyright Statement + + 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 and 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. + + + + + + + + + +Nikander, et al. Informational [Page 23] + |