idnits 2.17.1 draft-ietf-send-psreq-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 16 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 43: '...ation mechanisms MAY be protected with...' RFC 2119 keyword, line 88: '... The current specifications suggest that IPsec AH RFC2402 [2] MAY be...' RFC 2119 keyword, line 261: '..., the link layer MAY take care of the ...' RFC 2119 keyword, line 262: '... authentication protocol MAY allow the...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 23, 2003) is 7765 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 752, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 764, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 772, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2284 (ref. '1') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2402 (ref. '2') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2461 (ref. '3') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '4') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2472 (ref. '5') (Obsoleted by RFC 5072, RFC 5172) -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-02) exists of draft-arkko-icmpv6-ike-effects-01 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-02) exists of draft-arkko-manual-icmpv6-sas-01 -- Possible downref: Normative reference to a draft: ref. '11' Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Neighborhood Discovery P. Nikander (editor) 3 Working Group Ericsson Research Nomadic Lab 4 Internet-Draft J. Kempf 5 Expires: July 24, 2003 DoCoMo USA Labs 6 E. Nordmark 7 Sun Microsystems Laboratories 8 January 23, 2003 10 IPv6 Neighbor Discovery trust models and threats 11 draft-ietf-send-psreq-01 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 24, 2003. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 The existing IETF standards specify that IPv6 Neighbor Discovery and 43 Address Autoconfiguration mechanisms MAY be protected with IPsec AH. 44 However, the current specifications limit the security solutions to 45 manual keying due to practical problems faced with automatic key 46 management. This document specifies three different trust models and 47 discusses the threats pertinent to IPv6 Neighbor Discovery. The 48 purpose of this discussion is to define the requirements for Securing 49 IPv6 Neighbor Discovery. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Previous Work . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Trust models . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.1 Corporate Intranet Model . . . . . . . . . . . . . . . . . . 5 57 3.2 Public Wireless Network with an Operator . . . . . . . . . . 6 58 3.3 Ad Hoc Network . . . . . . . . . . . . . . . . . . . . . . . 7 59 4. Threats on a (Public) Multi-Access Link . . . . . . . . . . 8 60 4.1 Non router/routing related threats . . . . . . . . . . . . . 8 61 4.1.1 Neighbor Solicitation/Advertisement Spoofing . . . . . . . . 8 62 4.1.2 Neighbor Unreachability Detection (NUD) failure . . . . . . 9 63 4.1.3 Duplicate Address Detection DoS Attack . . . . . . . . . . . 10 64 4.2 Router/routing involving threats . . . . . . . . . . . . . . 10 65 4.2.1 Malicious Last Hop Router . . . . . . . . . . . . . . . . . 10 66 4.2.2 Good Router Goes Bad . . . . . . . . . . . . . . . . . . . . 11 67 4.2.3 Spoofed Redirect Message . . . . . . . . . . . . . . . . . . 11 68 4.2.4 Bogus On-Link Prefix . . . . . . . . . . . . . . . . . . . . 12 69 4.2.5 Bogus Address Configuration Prefix . . . . . . . . . . . . . 13 70 4.2.6 Parameter Spoofing . . . . . . . . . . . . . . . . . . . . . 14 71 4.3 Remotely exploitable attacks . . . . . . . . . . . . . . . . 15 72 4.3.1 Neighbor Discovery DoS Attack . . . . . . . . . . . . . . . 15 73 4.4 Summary of the attacks . . . . . . . . . . . . . . . . . . . 15 74 5. Security Considerations . . . . . . . . . . . . . . . . . . 18 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 76 References . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 78 A. Changes between versions . . . . . . . . . . . . . . . . . . 22 79 Intellectual Property and Copyright Statements . . . . . . . 23 81 1. Introduction 83 The IPv6 Neighbor Discovery RFC2461 [3] and Address Autoconfiguration 84 RFC2462 [4] mechanisms are used by nodes in an IPv6 network to learn 85 the local topology, including the IP to MAC address mappings for the 86 local nodes, the IP and MAC addresses of the routers present in the 87 local network, and the routing prefixes served by the local routers. 88 The current specifications suggest that IPsec AH RFC2402 [2] MAY be 89 used to secure the mechanisms, but does not specify how. It appears 90 that using current AH mechanisms is problematic due to key management 91 problems [10]. 93 To solve the problem, the Secure Neighbor Discovery (SEND) working 94 group was chartered in fall 2002. The goal of the working group is 95 to define protocol support for securing IPv6 Neighbor Discovery 96 without requiring excessive manual keying. 98 The purpose of this document is to define the types of networks the 99 Secure IPv6 Neighbor Discovery mechanisms are expected to work, and 100 the threats that the security protocol(s) must address. To fulfill 101 this purpose, this document first defines three different trust 102 models, roughly corresponding to secured corporate intranets, public 103 wireless access networks, and pure ad hoc networks. After that, a 104 number of threats is are discussed in the light of these trust 105 models. The threat catalog is aimed to be exhaustive, but it is 106 likely that some threats are still missing. Thus, ideas for new 107 threats to consider are solicited. 109 This document occasionally discusses solution proposals, such as CGA 110 [9] and ABK [8]. However, the discussion is solely for illustrative 111 purposes. It is meant to give the readers a more concrete idea of 112 some possible solutions. It does NOT indicate any preference on 113 solutions on the behalf of the authors or the working group. 115 It should be noted that the term "trust" is used here in a rather 116 non-technical and loose manner. The most appropriate interpretation 117 is to consider it as an expression of an organizational or collective 118 belief, i.e., an expression of commonly shared beliefs about the 119 future behavior of the other involved parties. Conversely, the term 120 "trust relationship" denotes a mutual a priori relationship between 121 the involved organizations or parties where the parties believe that 122 the other parties will behave correctly even in the future. A trust 123 relationship makes it possible to configure authentication and 124 authorization information between the parties, while the lack of such 125 a relationship makes it impossible to pre-configure such information. 127 2. Previous Work 129 The RFCs that specify the IPv6 Neighbor Discovery and Address 130 Autoconfiguration protocols [3][4] contain the required discussion of 131 security in a Security Considerations section. Some of the threats 132 identified in this document were raised in the original RFCs. The 133 recommended remedy was to secure the involved packets with an IPsec 134 AH [2] header. However, that solution is not always possible due to 135 key management problems. For example, a host attempting to gain 136 access to a Public Access network may or may not have the required 137 IPsec security associations set up with the network. In a roaming 138 (but not necessarily mobile) situation, where a user is currently 139 accessing the network through a service provider different from the 140 home provider, it is not likely that the host will have been 141 preconfigured with the proper mutual trust relationship for the 142 foreign provider's network, allowing it to directly authenticate the 143 network and get itself authenticated. 145 As of today, any IPsec security association between the host and the 146 last hop routers or other hosts on the link would need to be 147 completely manually preconfigured, since the Neighbor Discovery and 148 Address Autoconfiguration protocols deal to some extent with how a 149 host obtains initial access to a link. Thus, if a security 150 association is required for initial access and the host does not have 151 that association, there is currently no standard way that the host 152 can dynamically configure itself with that association, even if it 153 has the necessary minimum prerequisite keying material. This 154 situation could induce administration hardships when events such as 155 re-keying occur. 157 In addition, Neighbor Discovery and Address Autoconfiguration use a 158 few fixed multicast addresses plus a range of 4 billion "solicited 159 node" multicast addresses. A naive application of pre-configured SAs 160 would require pre-configuring an unmanageable number of SAs on each 161 host and router just in case a given solicited node multicast address 162 is used. Preconfigured SAs are impractical for securing such a large 163 potential address range. 165 3. Trust models 167 When considering various security solutions for the IPv6 Neighbor 168 Discovery (ND) [3], it is important to keep in mind the underlying 169 trust models. The trust models defined in this section are used 170 later in this document, when discussing specific threats. 172 In the following, the RFC2461/RFC2662 mechanisms are loosely divided 173 into two categories: Neighbor Discovery (ND) and Router Discovery 174 (RD). The former denotes operations that do not primarily involve 175 routers while the operations in the latter category do. 177 Three different trust models are specified: 179 1. A model where all authenticated nodes trust each other to behave 180 correctly at the IP layer and not to send any ND or RD messages 181 that contain false information. This model is thought to 182 represent a situation where the nodes are under a single 183 administration and form a closed or semi-closed group. A 184 corporate intranet is a good example. 186 2. A model where there is a router trusted by the other nodes in the 187 network to be a legitimate router that faithfully routes packets 188 between the local network and any connected external networks. 189 Furthermore, the router is trusted to behave correctly at the IP 190 layer and not to send any ND or RD messages that contain false 191 information. 193 This model is thought to represent a public network run by an 194 operator. The clients pay to the operator, have its credentials, 195 and trust it to provide the IP forwarding service. The clients 196 do not trust each other to behave correctly; any other client 197 node must be considered able to send falsified ND and RD 198 messages. 200 3. A model where the nodes do not directly trust each other at the 201 IP layer. This model is considered suitable for e.g., ad hoc 202 networks. 204 Note that even though the nodes are assumed to trust each other in 205 the first trust model (corporate intranet), it is still desirable to 206 limit the extent of damage a node is able to inflict to the local 207 network if it becomes compromised. 209 3.1 Corporate Intranet Model 211 In a corporate intranet or other network where all nodes are under 212 one administrative domain, the nodes may be considered to be reliable 213 at the IP layer. Thus, once a node has been accepted to be a member 214 of the network, it is assumed to behave in a trustworthy manner. 216 Under this model, if the network is physically secured or if the link 217 layer is cryptographically secured to the extend needed, no other 218 protection is needed for IPv6 ND, as long as none of the nodes become 219 compromised. For example, a wired LAN with 802.1x access control or 220 a WLAN with 802.11i RNS/EAS may be considered secure enough, 221 requiring no further protection under this trust model. 223 On the other hand, if the network is not physically secured and the 224 link layer does not have cryptographic protection, or if the 225 cryptographic protection is not secure enough (e.g., just 802.1x and 226 not 802.11i in a WLAN), the nodes in the network may be vulnerable to 227 some or all of the threats outlined in Section 4. In such case some 228 protection is desirable to secure ND. Providing such protection 229 falls within the main initial focus of the SEND working group. 231 Furthermore, even under this model it is desirable to limit the 232 amount of potential damage in the case a node becomes compromised. 233 For example, it might still be acceptable that a compromised node is 234 able to launch a denial-of-service attack, but it is undesirable if 235 it is able to hijack existing connections or establish 236 man-in-the-middle attacks on new connections. 238 As mentioned in Section 2, one possibility to secure ND would be to 239 use IPsec AH with symmetric shared keys, known by all trusted nodes 240 and by no outsiders. However, none of the currently standardized 241 automatic key distribution mechanisms work right out-of-the-box. For 242 further details, see [10]. Furthermore, using a shared key would not 243 protect against a compromised node. 245 3.2 Public Wireless Network with an Operator 247 A scenario where an operator runs a public wireless (or wireline) 248 network, e.g., a WLAN in a hotel, air port, or cafe, has a different 249 trust model. Here the nodes may be assumed to trust the operator to 250 provide the IP forwarding service in a trustworthy manner, and not to 251 disrupt or misdirect the clients' traffic. However, the clients do 252 not usually trust each other. Typically the router (or routers) fall 253 under one administrative domain, and the client nodes each fall under 254 its own administrative domain. 256 It is assumed that under this scenario the operator authenticates all 257 the client nodes, or at least requires authorization in the form of a 258 payment. At the same time, the clients must be able to authenticate 259 the router and make sure that it belongs to the trusted operator. 260 Depending on the link layer authentication protocol and its 261 deployment, the link layer MAY take care of the mutual 262 authentication. The link layer authentication protocol MAY allow the 263 client nodes and the access router to create a security association. 264 Notice that there exists authentication protocols, e.g., variants of 265 EAP, that do not create secure keying material and/or do not allow 266 the client to authenticate the network. 268 In this scenario, cryptographically securing the link layer does not 269 necessarily block all the threats outlined in Section 4; see the 270 individual threat descriptions. Specifically, even in 802.11i RNS/ 271 EAP the broadcast and multicast keys are shared between all nodes. 272 Even if the underlying link layer is aware of all the nodes' link 273 layer addresses, and is able to check that no source addresses were 274 falsified, there may still be vulnerabilities. 276 There seems to be two ways to bring in security into this scenario. 277 One is to enforce strong security between the clients and the access 278 router, and make the access router aware of the IP layer protocol 279 details. That is, the router would check ICMPv6 packet contents, and 280 filter packets that contain information which does not match the 281 network topology. The other way is to add cryptographic protection 282 to the ICMPv6 packets carrying ND messages. 284 3.3 Ad Hoc Network 286 In an ad hoc network, or any network without a trusted operator, none 287 of the nodes trust each other. In a generic case, the other nodes 288 are met for the first time, and there are no guarantees that the 289 other nodes would behave correctly at the IP layer. They must be 290 considered prone to send falsified ND and RD messages. 292 Since there are no a priori trust relationships, the nodes cannot 293 rely on traditional authentication. However, it is still possible to 294 use self-identifying mechanisms, such as Cryptographically Generated 295 Addresses (CGA) [9]. These allow the nodes to ensure that they are 296 talking to the same nodes (as before) at all times, and that each of 297 the nodes indeed have generated their IP address themselves and not 298 "stolen" someone else's address. It may also be possible to learn 299 the identities of any routers using various kinds of heuristics, such 300 as testing the node's ability to convey cryptographically protected 301 traffic towards a known and trusted node somewhere in the Internet. 302 Methods like these seem to mitigate (but not completely block) some 303 of the attacks outlined in the next section. 305 4. Threats on a (Public) Multi-Access Link 307 In this section we discuss threats against the current IPv6 Neighbor 308 Discovery mechanisms, when used in multi-access links. The threats 309 are discussed in the light of the trust models defined in the 310 previous section. 312 There are two general types of threats: 314 1. Redirect attacks in which a malicious node redirects packets away 315 from the last hop router or other legitimate receiver to another 316 node on the link. 318 2. Denial of Service (DoS) attacks, in which a malicious node 319 prevents communication between the node under attack and all 320 other nodes, or a specific destination address. 322 A redirect attack can be used for DoS purposes by having the node to 323 which the packets were redirected drop the packets, either completely 324 or by selectively forwarding some of them and not others. 326 The subsections below identify specific threats for IPv6 network 327 access. The threat descriptions are organized in three subsections. 328 We first consider threats that do not involve routers or routing 329 information, and only after then those that do. Finally, we consider 330 threats that are remotely exploitable. All threats are discussed in 331 the light of the trust models. 333 4.1 Non router/routing related threats 335 In this section we discuss attacks against "pure" Neighbor Discovery 336 functions, i.e., Neighbor Discovery (ND), Neighbor Unreachability 337 Detection (NUD), and Duplicate Address Detection (DAD) in Address 338 Autoconfiguration. 340 4.1.1 Neighbor Solicitation/Advertisement Spoofing 342 Nodes on the link use Neighbor Solicitation and Advertisement 343 messages to created bindings between IP addresses and MAC addresses. 345 An attacking node can cause packets for legitimate nodes, both hosts 346 and routers, to be sent to some other link-layer address. This can 347 be done by either sending a Neighbor Solicitation with a different 348 source link-layer address option, or sending a Neighbor Advertisement 349 with a different target link-layer address option. The IP address 350 could additionally be the subnet router anycast address, allowing the 351 attacker to capture traffic to that address. 353 The attacks succeed because the Neighbor Cache entry with the new 354 link-layer address overwrites the old. If the spoofed link-layer 355 address is a valid one, as long as the attacker responds to the 356 unicast Neighbor Solicitation messages sent as part of the Neighbor 357 Unreachability Detection, packets will continue to be redirected. 358 This is a redirect/DoS attack. 360 This mechanism can be used for a DoS attack by specifying an unused 361 link-layer address, however, the attack is of limited duration since 362 after 30-50 seconds (with default timer values) the Neighbor 363 Unreachability Detection mechanism will discard the bad link-layer 364 address and multicast anew to discover the link-layer address. As a 365 consequence, the attacker will need to keep responding with 366 fabricated link layer addresses if it wants to maintain the attack 367 beyond the timeout. 369 This threat involves Neighbor Solicitation and Neighbor 370 Advertisement. 372 This attack is not a concern if access to the link is restricted to 373 trusted nodes; if a trusted node is compromised, the other nodes are 374 exposed to this threat. In the case just the operator is trusted, 375 the nodes may rely on the operator to certify the address bindings 376 for other local nodes. In the ad hoc network case, and optionally in 377 the other two cases, the nodes may use self certifying techniques 378 (e.g. CGA) to authorize address bindings. 380 4.1.2 Neighbor Unreachability Detection (NUD) failure 382 Nodes on the link monitor the reachability of local destinations and 383 routers with the Neighbor Unreachability Detection procedure [3]. 384 Normally the nodes rely on upper-layer information to determine 385 whether peer nodes are still reachable. However, if there is a 386 sufficiently long delay on upper-layer traffic, or if the node stops 387 receiving replies from a peer node, the NUD procedure is invoked. 388 The node first waits for a small random delay, and then sends a 389 targeted NS to the peer node. If the peer is still reachable, it 390 will reply with a NA. However, if the soliciting node receives no 391 reply, it tries a few more times, eventually deleting the neighbor 392 cache entry. If needed, this triggers the standard address 393 resolution protocol. No higher level traffic can proceed if this 394 procedure flushes out neighbor cache entries after determining 395 (perhaps incorrectly) that the peer is not reachable. 397 A malicious node may keep sending fabricated NAs in response to NUD 398 NS messages. Unless the NA messages are cryptographically protected, 399 the attacker may be able to extend the attack for a long time using 400 this technique. The actual consequences depend on why the node 401 become unreachable for the first place, and how the target node would 402 behave if it knew that the node has become unreachable. This is a 403 DoS attack. 405 This threat involves Neighbor Solicitation/Advertisement. 407 This attack is not a concern if access to the link is restricted to 408 trusted nodes; if a trusted node is compromised, the other nodes are 409 exposed to this DoS threat. Under the two other trust models, a 410 solution requires that the node performing NUD is able to make a 411 distinction between genuine and fabricated NA responses. 413 4.1.3 Duplicate Address Detection DoS Attack 415 In networks where the entering hosts obtain their addresses using 416 stateless address autoconfiguration [4], an attacking node could 417 launch a DoS attack by responding to every duplicate address 418 detection attempt made by an entering host. If the attacker claims 419 the address, then the host will never be able to obtain an address. 420 This threat was identified in RF2462 [4]. This is a DoS attack. 422 This threat involves Neighbor Solicitation/Advertisement. 424 This attack is not a concern if access to the link is restricted to 425 trusted nodes; if a trusted node is compromised, the other nodes 426 become exposed to this DoS threat. Under the two other trust models, 427 a solution requires that the node performing DAD is able to verify 428 whether the sender of the NA response is authorized to use the given 429 IP address or not. In the trusted operator case, the operator may 430 act as an authorizer, keeping track of allocated addresses and making 431 sure that no node may allocated more than a few (hundreds of) 432 addresses. In the ad hoc network case one has to structure the 433 addresses in such a way that self authorization is possible. CGA [9] 434 provides one possible way to achieve that. 436 4.2 Router/routing involving threats 438 In this section we consider threats pertinent to router discovery or 439 other router assisted/related mechanisms. 441 4.2.1 Malicious Last Hop Router 443 This threat was identified in [6] but was classified as a general 444 IPv6 threat and not specific to Mobile IPv6. It is also identified 445 in RFC2461 [3]. This threat is a redirect/DoS attack. 447 An attacking node on the same subnet as a host attempting to discover 448 a legitimate last hop router could masquerade as an IPv6 last hop 449 router by multicasting legitimate-looking IPv6 Router Advertisements 450 or unicasting Router Advertisements in response to multicast Router 451 Advertisement Solicitations from the entering host. If the entering 452 host selects the attacker as its default router, the attacker has the 453 opportunity to siphon off traffic from the host, or mount a 454 man-in-the-middle attack. The attacker could ensure that the 455 entering host selected itself as the default router by multicasting 456 periodic Router Advertisements for the real last hop router having a 457 lifetime of zero. This may spoof the entering host into believing 458 that the real access router is not willing to take any traffic. Once 459 accepted as a legitimate router, the attacker could send Redirect 460 messages to hosts, then disappear, thus covering its tracks. 462 This threat is partially mitigated in RFC2462; in Section 5.5.3 of 463 RFC2462 it is required that if the advertised prefix lifetime is less 464 than 2 hours and less than the stored lifetime, the stored lifetime 465 is not reduced unless the packet was authenticated. However, the 466 default router selection procedure, as defined in Section 6.3.6. of 467 RFC2461, does not contain such a rule. 469 This threat involves Router Advertisement and Router Advertisement 470 Solicitation. 472 This attack is not a concern if access to the link is restricted to 473 trusted nodes; if a trusted node is compromised, the other nodes are 474 exposed to this threat. However, the threat can be partially 475 mitigated through a number of means, for example, by configuring the 476 nodes to prefer existing routers over new ones. 478 In the case of a trusted operator, there must be a means for the 479 nodes to make a distinction between trustworthy routers, run by the 480 operator, and other nodes. There are currently no widely accepted 481 solutions for the ad hoc network case, and the issue remains as a 482 research question. 484 4.2.2 Good Router Goes Bad 486 In this attack, a router that previously was trusted is compromised. 487 The attacks available are the same as those discussed in Section 488 4.2.1. This is a redirect/DoS attack. 490 There are currently no known solutions for any of the presented three 491 trust models. On the other hand, on a multi-router link one could 492 imagine a solution involving revocation of router rights. The 493 situation remains as a research question. 495 4.2.3 Spoofed Redirect Message 496 The Redirect message can be used to send packets for a given 497 destination to any link-layer address on the link. The attacker uses 498 the link-local address of the current first-hop router in order to 499 send a Redirect message to a legitimate host. Since the host 500 identifies the message by the link-local address as coming from its 501 first hop router, it accepts the Redirect. As long as the attacker 502 responds to Neighbor Unreachability Detection probes to the link- 503 layer address, the Redirect will remain in effect. This is a 504 redirect/DoS attack. 506 This threat involves Redirect. 508 This attack is not a concern if access to the link is restricted to 509 trusted nodes; if a trusted node is compromised, the other nodes are 510 exposed to this threat. In the case of a trusted operator, there 511 must be a means for the nodes to make a distinction between 512 trustworthy routers, run by the operator, and other nodes. There are 513 currently no widely accepted solutions for the ad hoc network case, 514 and the issue remains as a research question. 516 4.2.4 Bogus On-Link Prefix 518 An attacking node can send a Router Advertisement message specifying 519 that some prefix of arbitrary length is on-link. If a sending host 520 thinks the prefix is on-link, it will never send a packet for that 521 prefix to the router. Instead, the host will try to perform address 522 resolution by sending Neighbor Solicitations, but the Neighbor 523 Solicitations will not result in a response, denying service to the 524 attacked host. This is a DoS attack. 526 The attacker can use an arbitrary lifetime on the bogus prefix 527 advertisement. If the lifetime is infinity, the sending host will be 528 denied service until it loses the state in its prefix list e.g., by 529 rebooting, or the same prefix is advertised with a zero lifetime. 530 The attack could also be perpetrated selectively for packets destined 531 to a particular prefix by using 128 bit prefixes, i.e. full 532 addresses. 534 This attack can be extended into a redirect attack if the tacker 535 replies to the Neighbor Solicitations with spoofed Neighbor 536 Advertisements, thereby luring the nodes on the link to send the 537 traffic to it or to some other node. 539 This threat involves Router Advertisement. The extended attack 540 combines the attack defined in Section 4.1.1 and in this section, and 541 involves Neighbor Solicitation, Neighbor Advertisement, and Router 542 Advertisement. 544 This attack is not a concern if access to the link is restricted to 545 trusted nodes; if a trusted node is compromised, the other nodes are 546 exposed to this threat. In the case of a trusted operator, there 547 must be a means for the nodes to make a distinction between 548 trustworthy routers, run by the operator, and other nodes. There are 549 currently no known solutions for the ad hoc network case, and the 550 issue remains as a research question. 552 4.2.5 Bogus Address Configuration Prefix 554 An attacking node can send a Router Advertisement message specifying 555 an invalid subnet prefix to be used by a host for address 556 autoconfiguration. A host executing the address autoconfiguration 557 algorithm uses the advertised prefix to construct an address [4], 558 even though that address is not valid for the subnet. As a result, 559 return packets never reach the host because the host's source address 560 is invalid. This is a DoS attack. 562 This attack has the potential to propagate beyond the immediate 563 attacked host if the attacked host performs a dynamic update to the 564 DNS based on the bogus constructed address. DNS update causes the 565 bogus address to be added to the host's AAAA record in the DNS. 566 Should this occur, applications performing name resolution through 567 the DNS obtain the bogus address and an attempt to contact the host 568 fails. However, well-written applications will fall back and try the 569 other IP address in the AAAA RRset, which may be correct. 571 A distributed attacker can make the attack more severe by creating a 572 falsified reverse DNS entry that matches with the dynamic DNS entry 573 created by the target. Consider an attacker who has legitimate 574 access to a prefix , and a target who has an interface 575 ID . The attacker creates a reverse DNS entry for 576 :, pointing to the real domain name of the 577 target, e.g. "secure.target.com". Next the attacker advertises the 578 prefix at the target's link. The target will create an 579 address :, and update its DNS entry so that 580 "secure.target.com" points to :. 582 At this point "secure.target.com" points to 583 :, and : points to 584 "secure.target.com". This threat is mitigated by the fact that the 585 attacker can be traced since the owner of the is 586 available at the registries. 588 There is also a related possibility of advertising the a target 589 prefix as an autoconfiguration prefix on a busy link, and then have 590 all nodes on this link try to communicate to the external world with 591 this address. If the local router doesn't have ingress filtering on, 592 then the target link will get all the replies for those initial 593 communication attempts. 595 This threat involves Router Advertisement. The extended attack 596 scenarios involve the DNS, too. 598 This attack is not a concern if access to the link is restricted to 599 trusted nodes; if a trusted node is compromised the other nodes are 600 exposed to this threat. In the case of a trusted operator, there 601 must be a means for the nodes to make a distinction between 602 trustworthy routers, run by the operator, and other nodes. There are 603 currently no known solutions for the ad hoc network case, and the 604 issue remains as a research question. 606 4.2.6 Parameter Spoofing 608 IPv6 Router Advertisements contain a few parameters used by hosts 609 when they send packets and to tell hosts whether or not they should 610 perform stateful address configuration [3]. An attacking node could 611 send out a valid-seeming Router Advertisement that duplicates the 612 Router Advertisement from the legitimate default router, except the 613 included parameters are designed to disrupt legitimate traffic. This 614 is a DoS attack. 616 Specific attacks include: 618 1. The attacker includes a Current Hop Limit of one or another small 619 number which the attacker knows will cause legitimate packets to 620 be dropped before they reach their destination. 622 2. The attacker implements a bogus DHCPv6 server or relay and the 623 'M' and/or 'O' flag is set, indicating that stateful address 624 configuration and/or stateful configuration of other parameters 625 should be done. The attacker is then in a position to answer the 626 stateful configuration queries of a legitimate host with its own 627 bogus replies. 629 This threat involves Router Advertisements. 631 This attack is not a concern if access to the link is restricted to 632 trusted nodes; if a trusted node is compromised the other nodes are 633 exposed to this treat. In the case of a trusted operator, there must 634 be a means for the nodes to make a distinction between trustworthy 635 routers, run by the operator, and other nodes. There are currently 636 no known solutions for the ad hoc network case, and the issue remains 637 as a research question. 639 4.3 Remotely exploitable attacks 641 4.3.1 Neighbor Discovery DoS Attack 643 In this attack, the attacking node begins fabricating addresses with 644 the subnet prefix and continuously sending packets to them. The last 645 hop router is obligated to resolve these addresses by sending 646 neighbor solicitation packets. A legitimate host attempting to enter 647 the network may not be able to obtain Neighbor Discovery service from 648 the last hop router as it will be already busy with sending other 649 solicitations. This DoS attack is different from the others in that 650 the attacker may be off-link. The resource being attacked in this 651 case is the conceptual neighbor cache, which will be filled with 652 attempts to resolve IPv6 addresses having a valid prefix but invalid 653 suffix. This is a DoS attack. 655 This threat involves Neighbor Solicitation. 657 This attack does not directly involve the trust models presented. 658 However, if access to the link is restricted to registered nodes, and 659 the access router keeps track of nodes that have registered for 660 access on the link, the attack may be trivially plugged. However, no 661 such mechanisms are currently standardized. 663 In a way, this problem is fairly similar to the TCP SYN flooding 664 problem. Rate limitating Neighbor Solicitations, restricting the 665 amount of state reserved for unresolved soliciations, and clever 666 cache management may be applied. 668 It should be noted that both hosts and routers need to worry about 669 this problem. The router case was discussed above. Hosts are also 670 vulnerable since the neighbor discovery process can potentially be 671 abused by an application that is tricked into sending packets to 672 arbitrary on-link destinations. 674 It is an open question whether the SEND WG should address this threat 675 or not. 677 4.4 Summary of the attacks 679 Columns: 681 N/R Neighbor Discovery (ND) or Router Discovery (RD) attack 683 R/D Redirect/DoS (Redir) or just DoS attack 684 Msgs Messages involved in the attack: NA, NS, RA, RS, Redir 686 1 Present in trust model 1 (corporate intranet) 688 2 Present in trust model 2 (public operator run network) 690 3 Present in trust model 3 (ad hoc network) 692 Symbols in trust model columns: 694 - The threat is not present or not a concern 696 + The threat is present and at least one solution is known 698 R The threat is present but solving it is a research problem 700 +-------+----------------------------+-----+-------+-------+---+---+---+ 701 | Sec | Attack name | N/R | R/D | Msgs | 1 | 2 | 3 | 702 +-------+----------------------------+-----+-------+-------+---+---+---+ 703 | 4.1.1 | NS/NA spoofing | ND | Redir | NA NS | + | + | + | 704 | 4.1.2 | NUD failure | ND | DoS | NA NS | - | + | + | 705 | 4.1.3 | DAD DoS | ND | DoS | NA NS | - | + | + | 706 +-------+----------------------------+-----+-------+-------+---+---+---+ 707 | 4.2.1 | Malicious router | RD | Redir | RA RS | + | + | R | 708 | 4.2.2 | Good router goes bad | RD | Redir | RA RS | R | R | R | 709 | 4.2.3 | Spoofed redirect | RD | Redir | Redir | + | + | R | 710 | 4.2.4 | Bogus on-link prefix | RD | DoS | RA | - | + | R | 1) 711 | 4.2.5 | Bogus address config prefix| RD | DoS | RA | - | + | R | 2) 712 | 4.2.6 | Parameter spoofing | RD | DoS | RA | - | + | R | 713 +-------+----------------------------+-----+-------+-------+---+---+---+ 714 | 4.3.1 | Remote ND DoS | ND | DoS | NS | + | + | + | 715 +------------------------------------+-----+-------+-------+---+---+---+ 717 Figure 1 719 1. Note that the extended attack defined in Section 4.2.4 combines 720 sending a bogus on-link prefix and performing NS/NA spoofing as 721 per Section 4.1.1 Thus, if the NA/NS exchange is secured, the 722 ability to use Section 4.2.4 for redirect is most probably 723 blocked, too. 725 2. The bogus DNS registration resulting from blindly registering the 726 new address via DynDNS is not considered an ND security issue 727 here. However, it should be noted as a possible vulnerability in 728 implementations. 730 For a slightly different approach, see also Section 7 in [11]. 732 Especially the table in Section 7.7 of [11] is very good. 734 5. Security Considerations 736 This document discusses security threats to network access in IPv6. 737 As such, it is concerned entirely with security. 739 6. Acknowledgements 741 Thanks to Alper Yegin of DoCoMo Communications Laboratories USA for 742 identifying the Neighbor Discovery DOS attack. We would also like to 743 thank Tuomas Aura and Michael Roe of Microsoft Research Cambridge as 744 well as Jari Arkko and Vesa-Matti Mantyla of Ericsson Research 745 Nomadiclab for discussing some of the threats with us. 747 Thanks to Alper E. Yegin, Pekka Savola and Bill Sommerfeld for their 748 constructive comments. 750 References 752 [1] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication 753 Protocol (EAP)", RFC 2284, March 1998. 755 [2] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 756 November 1998. 758 [3] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 759 for IP Version 6 (IPv6)", RFC 2461, December 1998. 761 [4] Thomson, S. and T. Narten, "IPv6 Stateless Address 762 Autoconfiguration", RFC 2462, December 1998. 764 [5] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 765 December 1998. 767 [6] "Threat Models introduced by Mobile IPv6 and Requirements for 768 Security in Mobile IPv6", 769 draft-ietf-mobileip-mipv6-scrty-reqts-02 (work in progress), 770 November 2001. 772 [7] Droms, R., "Dynamic Host Configuration Protocol for IPv6 773 (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), 774 November 2002. 776 [8] Kempf, J., "Securing IPv6 Neighbor Discovery Using Address 777 Based Keys (ABKs)", draft-kempf-secure-nd-01 (work in 778 progress), June 2002. 780 [9] Roe, M., "Authentication of Mobile IPv6 Binding Updates and 781 Acknowledgments", draft-roe-mobileip-updateauth-02 (work in 782 progress), March 2002. 784 [10] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies", 785 draft-arkko-icmpv6-ike-effects-01 (work in progress), June 786 2002. 788 [11] Arkko, J., "Manual SA Configuration for IPv6 Link Local 789 Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress), 790 June 2002. 792 Authors' Addresses 794 Pekka Nikander (editor) 795 Ericsson Research Nomadic Lab 796 JORVAS FIN-02420 797 FINLAND 799 Phone: +358 9 299 1 800 EMail: pekka.nikander@nomadiclab.com 802 James Kempf 803 DoCoMo USA Labs 804 181 Metro Drive, Suite 300 805 San Jose, CA 95110 806 USA 808 Phone: +1 408 451 4711 809 EMail: kempf@docomolabs-usa.com 811 Erik Nordmark 812 Sun Microsystems Laboratories 813 29, Chemin du Vieux Chene 814 Meylan 38240 815 France 817 Phone: +33 4 76 18 88 03 818 EMail: erik.nordmark@sun.com 820 Appendix A. Changes between versions 822 (To be removed before publication.) 824 -00 to -01 826 Added text to Section 4.2.4 to explained the combined NS/NA 827 spoofing + Bogus On-Link Prefix attack (suggested by Pekka 828 Savola). 830 Added text to Section 4.2.5 to describe how it can be extended to 831 include a valid reverse DNS mapping (suggested by Pekka Savola). 833 Added text to Section 4.2.5 to consider its potential flooding 834 effects (suggested by Jari Arkko). 836 Added text through the document to trust model 1, considering what 837 happens if a previously trusted node becomes compromised 838 (suggested by Pekka Savola and Bill Sommerfeld). 840 Changed the summary table in Section 4.4 so that the redirect 841 threats should be considered even in the corporate intranet case. 843 Added qualifying text to all occasions where a node is said to 844 trust another node, and even to some cases where a node is said 845 not to trust another node. 847 Added footnotes 1) and 2) to Figure 1 849 Added more discussion to threat Section 4.3.1 noting that it is 850 similar to TCP SYN flooding, and that also hosts need to worry 851 about it. 853 Converted to xml2rfc. 855 Intellectual Property Statement 857 The IETF takes no position regarding the validity or scope of any 858 intellectual property or other rights that might be claimed to 859 pertain to the implementation or use of the technology described in 860 this document or the extent to which any license under such rights 861 might or might not be available; neither does it represent that it 862 has made any effort to identify any such rights. Information on the 863 IETF's procedures with respect to rights in standards-track and 864 standards-related documentation can be found in BCP-11. Copies of 865 claims of rights made available for publication and any assurances of 866 licenses to be made available, or the result of an attempt made to 867 obtain a general license or permission for the use of such 868 proprietary rights by implementors or users of this specification can 869 be obtained from the IETF Secretariat. 871 The IETF invites any interested party to bring to its attention any 872 copyrights, patents or patent applications, or other proprietary 873 rights which may cover technology that may be required to practice 874 this standard. Please address the information to the IETF Executive 875 Director. 877 Full Copyright Statement 879 Copyright (C) The Internet Society (2003). All Rights Reserved. 881 This document and translations of it may be copied and furnished to 882 others, and derivative works that comment on or otherwise explain it 883 or assist in its implementation may be prepared, copied, published 884 and distributed, in whole or in part, without restriction of any 885 kind, provided that the above copyright notice and this paragraph are 886 included on all such copies and derivative works. However, this 887 document itself may not be modified in any way, such as by removing 888 the copyright notice or references to the Internet Society or other 889 Internet organizations, except as needed for the purpose of 890 developing Internet standards in which case the procedures for 891 copyrights defined in the Internet Standards process must be 892 followed, or as required to translate it into languages other than 893 English. 895 The limited permissions granted above are perpetual and will not be 896 revoked by the Internet Society or its successors or assignees. 898 This document and the information contained herein is provided on an 899 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 900 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 901 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 902 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 903 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 905 Acknowledgement 907 Funding for the RFC Editor function is currently provided by the 908 Internet Society.