idnits 2.17.1 draft-ietf-send-psreq-00.txt: -(628): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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 22 instances of too long lines in the document, the longest one being 4 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 31: '...ation mechanisms MAY be protected with...' RFC 2119 keyword, line 78: '... [RFC2402] MAY be used to secure the mechanisms, but does not...' RFC 2119 keyword, line 217: '...t, the link layer MAY take care of the...' RFC 2119 keyword, line 218: '...link layer authentication protocol MAY...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (October 17, 2002) is 7855 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: 'EAP' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'RFC2472' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'DHCPv6' is defined on line 653, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2284 (ref. 'EAP') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2472 (Obsoleted by RFC 5072, RFC 5172) == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-20 == Outdated reference: A later version (-01) exists of draft-kempf-secure-nd-00 -- Possible downref: Normative reference to a draft: ref. 'ABK' -- Possible downref: Normative reference to a draft: ref. 'CGA' -- Possible downref: Non-RFC (?) normative reference: ref. 'IKE-ND' Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SEND Working Group P. Nikander (editor) 2 Internet Draft October 17, 2002 3 draft-ietf-send-psreq-00.txt 4 Expires: April 17, 2002 6 IPv6 Neighbor Discovery trust models and threats 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The existing IETF standards specify that IPv6 Neighbor Discovery 31 and Address Autoconfiguration mechanisms MAY be protected with 32 IPsec AH. However, the current specifications limit the security 33 solutions to manual keying due to practical problems faced with 34 automatic key management. This document specifies three different 35 trust models and discusses the threats pertient to IPv6 Neighbor 36 Discovery. The purpose of this discussion is to define the 37 requirements for Securing IPv6 Neigbor Discovery. 39 draft-ietf-send-psreq-00.txt P. Nikander (editor) 41 Table of Contents 43 1.0 Introduction 44 2.0 Previous Work 45 3.0 Trust models 46 3.1 Corporate Intranet Model 47 3.2 Public Wireless Network with an Operator 48 3.3 Ad Hoc Network 49 4.0 Threats on a (Public) Multi-Access Link 50 4.1 Non router/routing related threats 51 4.1.1 Neighbor Solicitation/Advertisement Spoofing 52 4.1.2 Neighbor Unreachability Detection (NUD) failure 53 4.1.3 Duplicate Address Detection DoS Attack 54 4.2 Router/routing involving threats 55 4.2.1 Malicious Last Hop Router 56 4.2.2 Good Router Goes Bad 57 4.2.3 Spoofed Redirect Message 58 4.2.4 Bogus On-Link Prefix 59 4.2.5 Bogus Address Configuration Prefix 60 4.2.6 Parameter Spoofing 61 4.3 Remotely exploitable attacks 62 4.3.1 Neighbor Discovery DoS Attack 63 4.4 Summary of the attacks 64 5.0 Security Considerations 65 6.0 Acknowledgements 66 7.0 References 67 8.0 Authors' Addresses 68 9.0 Copyright Statement 70 1.0 Introduction 72 The IPv6 Neighbor Discovery [RFC2461] and Address Autoconfiguration 73 [RFC2462] mechanisms are used by nodes in an IPv6 network to learn 74 the local topology, including the IP to MAC address mappings for 75 the local nodes, the IP and MAC addresses of the routers present in 76 the local network, and the routing prefixes served by the local 77 routers. The current specifications suggest that IPsec AH 78 [RFC2402] MAY be used to secure the mechanisms, but does not 79 specify how. It appears that using current AH mechanisms is 80 problematic due to key management problems [IKE-ND]. 82 To solve the problem, the Secure Neighbor Discovery (SEND) working 83 group was chartered in fall 2002. The goal of the working group is 84 to define protocol support for securing IPv6 Neighbor Discovery 85 without requiring excessive manual keying. 87 The purpose of this document is to define the types of networks the 88 Secure IPv6 Neighbor Discovery mechanisms are expected to work, and 89 the threats that the security protocol(s) must address. To fulfil 90 this purpose, this document first defines three different trust 91 models, roughly corresponding to secured corporate intranets, 92 public wireless access networks, and pure ad hoc netwroks. After 93 that, a number of threats is are discussed in the light of these 94 trust models. The threat catalog is aimed to be exhaustive, but it 95 draft-ietf-send-psreq-00.txt P. Nikander (editor) 97 is likely that some threats are still missing. Thus, ideas for new 98 threats to consider are solicited. 100 This document occasionally discusses solution proposals, such as 101 CGA [CGA] and ABK [ABK]. However, the discussion is solely for 102 illustrative purposes. It is meant to give the readers a more 103 concrete idea of some possible solutions. It does NOT indicate any 104 preference on solutions on the behalf of the authors or the working 105 group. 107 2.0 Previous Work 109 The RFCs that specify the IPv6 Neighbor Discovery and Address 110 Autoconfiguration protocols [RFC2461] [RFC2462] contain the 111 required discussion of security in a Security Considerations 112 section. Some of the threats identified in this document were 113 raised in the original RFCs. The recommended remedy was to secure 114 the involved packets with an IPsec AH header [RFC2402]. However, 115 thas solution is not always possible due to key management 116 problems. For example, a host attempting to gain access to a 117 Public Access network may or may not have the required IPsec 118 security associations set up with the network. In a roaming (but 119 not necessarily mobile) situation, where a user is currently 120 accessing the network through a service provider different from the 121 home provider, it is not likely that the host will have been 122 preconfigured with the proper mutual trust relationship for the 123 foreign provider's network. 125 As of today, any IPsec security association between the host and 126 the last hop routers or other hosts on the link would need to be 127 completely manually preconfigured, since the Neighbor Discovery and 128 Address Autoconfiguration protocols deal to some extent with how a 129 host obtains initial access to a link. Thus, if a security 130 association is required for initial access and the host does not 131 have that association, there is currently no standard way that the 132 host can dynamically configure itself with that association, even 133 if it has the necessary minimum prerequisite keying material. This 134 situation could induce administration hardships when events such as 135 re-keying occur. 137 In addition, Neighbor Discovery and Address Autoconfiguration use a 138 few fixed multicast addresses plus a range of 4 billion "solicited 139 node" multicast addresses. A naive application of pre-configured 140 SAs would require pre-configuring an unmanagable number of SAs on 141 each host and router just in case a given solicited node multicast 142 address is used. Preconfigured SAs are impractical for securing such 143 a large potential address range. 145 3.0 Trust models 147 When considering various security solutions for the IPv6 Neighbor 148 Discovery (ND) [RFC2461], it is important to keep in mind the 149 underlying trust models. The trust models defined in this section 150 are used later in this document, when discussing specific threats. 152 draft-ietf-send-psreq-00.txt P. Nikander (editor) 154 Three different trust models are specified: 156 1. A model where all authenticated nodes trust each other. 157 This model is thought to represent a situation where the nodes 158 are under a single administration and form a closed or 159 semi-closed group. A corporate intranet is a good example. 161 2. A model where there is a router trusted by the other 162 nodes in the network. This model is thought to represent 163 a public network run by an operator. The clients pay to 164 the operator, have its credentials, and trust it to provide 165 the service. The clients do not trust each other. 167 3. A model where the nodes do not directly trust each other 168 at the IP layer. This model is considered suitable for 169 e.g., ad hoc networks. 171 3.1 Corporate Intranet Model 173 In a corporate intranet or other network where all nodes are under 174 one administrative domain, the nodes may be considered to be 175 reliable at the IP layer. Thus, once a node has been accepted to 176 be a member of the network, it is assumed to behave in a 177 trustworthy manner. 179 Under this model, if the network is physically secured or if the 180 link layer is cryptographically secured to the extend needed, no 181 other protection is needed for IPv6 ND. For example, a wired LAN 182 with 802.1x access control or a WLAN with 802.11i RNS/EAS may be 183 considered secure enough, requiring no further protection under 184 this trust model. 186 On the other hand, if the network is not physically secured and the 187 link layer does not have cryptographic protection, or if the 188 cryptographic protection is not secure enough (e.g., just 802.1x 189 and not 802.11i in a WLAN), the nodes in the network may be 190 vulnerable to some or all of the threats outlined in Section 4.0. 191 In such case some protection is desirable to secure ND. Providing 192 such protection falls within the main initial focus of the SEND 193 working group. 195 As mentioned in Section 2.0, one possiblity would be to use IPsec 196 AH with symmetric shared keys, known by all trusted nodes and by no 197 outsiders. However, none of the currently standardised automatic 198 key distribution mechanisms work right out-of-the-box. For further 199 details, see [IKE-ND]. 201 3.2 Public Wireless Network with an Operator 203 A scenario where an operator runs a public wireless (or wireline) 204 network, e.g., a WLAN in a hotel, air port, or cafe, has a different 205 trust model. Here the nodes may be assumed to trust the operator. 206 However, they do not usually trust each other. Typically the 207 router (or routers) fall under one administrative domain, and the 208 client nodes each fall under its own administrative domain. 210 draft-ietf-send-psreq-00.txt P. Nikander (editor) 212 It is assumed that under this scenario the operator authenticates 213 all the client nodes, or at least requires authorization in the 214 form of a payment. At the same time, the clients must be able to 215 authenticate the router and make sure that it belongs to the 216 trusted operator. Depending on the link layer authentication 217 protocol and its deployment, the link layer MAY take care of the 218 mutual authentication. The link layer authentication protocol MAY 219 allow the client nodes and the access router to create a security 220 association. Notice that there exists authentication protocols, 221 e.g., variants of EAP, that do not create secure keying material 222 and/or do not allow the client to authenticate the network. 224 In this scenario, cryptographically securing the link layer does 225 not necessarily block all the threats outlined in Section 4.0; see 226 the individual threat descriptions. Specifically, even in 802.11i 227 RNS/EAP the broadcast and multicast keys are shared between all 228 nodes. Even if the underlying link layer is aware of all the 229 nodes' link layer addresses, and is able to check that no source 230 addresses were falsified, there may still be vulnerabilities. 232 There seems to be two ways to bring in security into this scenario. 233 One is to enforce strong security between the clients and the 234 access router, and make the access router aware of the IP layer 235 protocol details. That is, the router would check ICMPv6 packet 236 contents, and filter packets that contain information which does 237 not match the network topology. The other way is to add 238 cryptographic protection to the ICMPv6 packets carrying ND 239 messages. 241 3.3 Ad Hoc Network 243 In an ad hoc network, or any network without a trusted operator, 244 none of the nodes trust each other. Since there are no a priori 245 trust relationships, the nodes cannot rely on traditional 246 authentication. However, it is still possible to use 247 self-identifying mechanisms, such as Cryptographically Generated 248 Addresses [CGA]. These allow the nodes to ensure that they are 249 talking to the same nodes (as before) at all times, and that each 250 of the nodes indeed have generated their IP address themselves and 251 not "stolen" someone else's address. It may also be possible to 252 learn the identities of any routers using various kinds of 253 heuristics, such as testing the node's ability to convery 254 cryptographically protected traffic towards a known and trusted 255 node somewhere in the Internet. Methods like these seem to 256 mitigate (but not completely block) some of the attacks outlined in 257 the next section. 259 4.0 Threats on a (Public) Multi-Access Link 261 In this section we discuss threats against the current IPv6 262 Neighbor Discovery mechanisms, when used in multi-access 263 links. The threats are discussed in the light of the trust models 264 defined in the previous section. 266 draft-ietf-send-psreq-00.txt P. Nikander (editor) 268 There are two general types of threats: 270 1) Redirect attacks in which a malicious node redirects packets 271 away from the last hop router to another node on the link. 273 2) Denial of Service (DoS) attacks, in which a malicious node 274 prevents communication between the node under attack and all 275 other nodes, or a specific destination address. 277 A redirect attack can be used for DoS purposes by having the node to 278 which the packets were redirected drop the packets, either 279 completely or by selectively forwarding some of them and not 280 others. 282 The subsections below identify specific threats for IPv6 network 283 access. The threat descriptions are organized in three subsections. 284 We first consider threats that do not involve routers or routing 285 information, and only after then those that do. Finally, we consider 286 threats that are remotely exploitable. All threats are discussed in 287 the light of the trust models. 289 4.1 Non router/routing related threats 291 In this section we discuss attacks against "pure" Neighbor 292 Discovery functions, i.e., Neighbor Discovery, Neigbor 293 Unreachability Discovery, and Address Autoconfiguration. 295 4.1.1 Neighbor Solicitation/Advertisement Spoofing 297 Nodes on the link use Neighbor Solicitation and Adverticement 298 messages to created bindings between IP addresses and MAC addresses. 300 An attacking node can cause packets for legitimate nodes, both hosts 301 and routers, to be sent to some other link-layer address. This can 302 be done by either sending a Neighbor Solicitation with a different 303 source link-layer address option, or sending a Neighbor 304 Advertisement with a different target link-layer address option. The 305 IP address could additionally be the subnet router anycast address, 306 allowing the attacker to capture traffic to that address. The attack 307 results because the Neighbor Cache entry with the new link-layer 308 address overwrites the old. If the spoofed link-layer address is a 309 valid one, as long as the attacker responds to the unicast Neighbor 310 Solicitation messages sent as part of the Neighbor Unreachability 311 Detection, packets will continue to be redirected. This is a 312 redirect/DoS attack. 314 This mechanism can be used for a DoS attack by specifying an unused 315 link-layer address, however, the attack is of limited duration since 316 after 30-50 seconds (with default timer values) the Neighbor 317 Unreachability Detection mechanism will discard the bad link-layer 318 address and multicast anew to discover the link-layer address. As a 319 consequence, the attacker will need to keep responding with 320 fabricated link layer addresses if it wants to maintain the attack 321 beyond the timeout. 323 draft-ietf-send-psreq-00.txt P. Nikander (editor) 325 This threat involves Neighbor Solicitation and Neighbor 326 Advertisement messages. 328 This attack is not a concern if access to the link is restricted to 329 trusted nodes. In the case just the operator is trusted, the nodes 330 may rely on the operator to certify the address bindings for other 331 local nodes. In the ad hoc network case, and optionally in the 332 trusted operator case, the nodes may use self certifying techniques 333 (e.g. CGA) to authorize address bindings. 335 4.1.2 Neighbor Unreachability Detection (NUD) failure 337 Nodes on the link monitor the reachability of local destinations 338 and routers with the Neighbor Unreachability procedure [RFC2461]. 339 Normally the nodes rely on upper-layer information to determine 340 whether peer nodes are still reachable. However, if there is a 341 sufficiently long delay on upper-layer traffic, or if the node 342 stops receiving replies from a peer node, the NUD procedure is 343 invoked. The node first waits for a small random delay, and then 344 sends a targeted NS to the peer node. If the peer is still 345 reachable, it will reply with a NA. However, if the soliciting 346 node receives no reply, it tries a few more times, eventually 347 deleting the neighbor cache entry. If needed, this triggers the 348 standard address resolution protocol. No higher level traffic can 349 proceed if this procedure flushes out neighbor cache entries after 350 determining (perhaps incorrectly) that the peer is not reachable. 352 A malicious node may keep sending fabricated NAs in response to NUD 353 NS messages. Unless the NA messages are cryptographically 354 protected, the attacker may be able to distrupt communications for 355 a long time using this technique. This is a DoS attack. 357 This threat involves Neighbor Solicitation/Advertisement. 359 This attack is not a concern if access to the link is restricted to 360 trusted nodes. Under the two other trust models, a solution 361 requires that the node performing NUD is able to make a 362 disctinction between genuine and fabricated NA responses. 364 4.1.3 Duplicate Address Detection DoS Attack 366 In networks where the entering hosts obtain their addresses using 367 stateless address autoconfiguration [RFC2462], an attacking node 368 could launch a DoS attack by responding to every duplicate address 369 detection attempt by an entering host. If the attacker claims the 370 address, then the host will never be able to obtain an address. 371 This threat was identified in RFC 2462 [RFC2462]. This is a DoS 372 attack. 374 This attack involves Neighbor Solicitation/Advertisement. 376 draft-ietf-send-psreq-00.txt P. Nikander (editor) 378 This attack is not a concern if access to the link is restricted to 379 trusted nodes. Under the two other trust models, a solution 380 requires that the node performing DAD is able to verify whether the 381 sender of the NA response is authorized to use the given IP address 382 or not. In the trusted operator case, the operator may acts as an 383 authorizer, keeping track of allocated addresses and making sure 384 that no node may allocated more than a few (hundreds of) addresses. 385 In the ad noc network case one has to structure the addresses in 386 such a way that self authorization is possible. CGA [CGA] provides 387 one possible way to achieve that. 389 4.2 Router/routing involving threats 391 In this section we consider threats pertient to router discovery or 392 other router assisted/related mechanisms. 394 4.2.1 Malicious Last Hop Router 396 This threat was identified in [MIP_TH], but was classified as a 397 general IPv6 threat and not specific to Mobile IPv6. It is also 398 identified in [RFC2461]. This threat is a redirect/DoS attack. 400 An attacking node on the same subnet as a host attempting to 401 discover a legitimate last hop router could masquerade as an IPv6 402 last hop router by multicasting legitimate-looking IPv6 Router 403 Advertisements or unicasting Router Advertisements in response to 404 multicast Router Advertisement Solicitations from the entering 405 host. If the entering host selects the attacker as its default 406 router, the attacker has the opportunity to siphon off traffic from 407 the host, or mount a man-in-the-middle attack. The attacker could 408 ensure that the entering host selected itself as the default router 409 by multicasting periodic Router Advertisements for the real last 410 hop router having a lifetime of zero. This may spoof the 411 entering host into believing that the real access router is not 412 willing to take any traffic. Once accepted as a legitimate router, 413 the attacker could send Redirect messages to hosts, then disappear, 414 thus covering its tracks. 416 [XXX: The section above needs reconsideration. It appears that 417 just sending an RA with a zero lifetime is not enough. New text is 418 needed.] 420 This threat involves Router Advertisement and Router Advertisement 421 Solicitation. 423 This attack is not a concern if access to the link is restricted to 424 trusted nodes. In the case of a trusted operator, there must be a 425 means for the nodes to make a distinction between trustworthy 426 routers, run by the operator, and other nodes. There are currently 427 no known solutions for the ad hoc network case, and the issue 428 remains as a research question. 430 draft-ietf-send-psreq-00.txt P. Nikander (editor) 432 4.2.2 Good Router Goes Bad 434 In this attack, a router that previously was trusted is 435 compromised. The attacks available are the same as those discussed 436 in Section 4.2.1. This is a redirect/DoS attack. 438 There are currently no known solutions for any of the presented 439 three trust models. On the other hand, on a multi-router link one 440 could imagine a solution involving revocation of router rights. 441 The situation remains as a research question. 443 4.2.3 Spoofed Redirect Message 445 The Redirect message can be used to send packets for a given 446 destination to any link-layer address on the link. The attacker uses 447 the link-local address of the current first-hop router in order to 448 send a Redirect message to a legitimate host. Since the host 449 identifies the message by the link-local address as coming from its 450 first hop router, it accepts the Redirect. As long as the attacker 451 responds to Neighbor Unreachability Detection probes to the link- 452 layer address, the Redirect will remain in effect. This is a 453 redirect/DoS attack. 455 This threat involves Redirect messages. 457 This attack is not a concern if access to the link is restricted to 458 trusted nodes. In the case of a trusted operator, there must be a 459 means for the nodes to make a distinction between trustworthy 460 routers, run by the operator, and other nodes. There are currently 461 no known solutions for the ad hoc network case, and the issue 462 remains as a research question. 464 4.2.4 Bogus On-Link Prefix 466 An attacking node can send a Router Advertisement message specifying 467 that some prefix of arbitrary length is on-link. If a sending host 468 thinks the prefix is on-link, it will never send a packet for that 469 prefix to the router. Instead, the host will try to perform address 470 resolution by sending Neighbor Solicitations, but the Neighbor 471 Solicitations will not result in a response, denying service to the 472 attacked host. This is a DoS attack. 474 The attacker can use an arbitrary lifetime on the bogus prefix 475 advertisement. If the lifetime is infinity, the sending host will be 476 denied service until it loses the state in its prefix list e.g., by 477 rebooting, or the same prefix is advertised with a zero lifetime. 478 The attack could also be perpetrated selectively for packets 479 destined to a particular prefix by using 128 bit prefixes, i.e. full 480 addresses. 482 This threat involves Router Advertisement messages. 484 This attack is not a concern if access to the link is restricted to 485 trusted nodes. In the case of a trusted operator, there must be a 486 means for the nodes to make a distinction between trustworthy 487 draft-ietf-send-psreq-00.txt P. Nikander (editor) 489 routers, run by the operator, and other nodes. There are currently 490 no known solutions for the ad hoc network case, and the issue 491 remains as a research question. 493 4.2.5 Bogus Address Configuration Prefix 495 An attacking node can send a Router Advertisement message specifying 496 an invalid subnet prefix to be used by a host for address 497 autoconfiguration. A host executing the address autoconfiguration 498 algorithm uses the advertised prefix to construct an address [RFC2462], 499 even though that address is not valid for the subnet. As a result, 500 return packets never reach the host because the host's source 501 address is invalid. This is a DoS attack. 503 This attack has the potential to propagate beyond the immediate 504 attacked host if the attacked host performs a dynamic update to the 505 DNS based on the bogus constructed address. DNS update causes the 506 bogus address to be added to the host's AAAA record in the DNS. 507 Should this occur, applications performing name resolution through 508 the DNS obtain the bogus address and an attempt to contact the host 509 fails. However, well-written applications will fall back and try the 510 other IP address in the AAAA RRset, which may be correct. 512 This threat involves Router Advertisement messages. 514 This attack is not a concern if access to the link is restricted to 515 trusted nodes. In the case of a trusted operator, there must be a 516 means for the nodes to make a distinction between trustworthy 517 routers, run by the operator, and other nodes. There are currently 518 no known solutions for the ad hoc network case, and the issue 519 remains as a research question. 521 4.2.6 Parameter Spoofing 523 IPv6 Router Advertisements contain a few parameters used by hosts 524 when they send packets and to tell hosts whether or not they should 525 perform stateful address configuration [RFC2461]. An attacking 526 node could send out a valid-seeming Router Advertisement that 527 duplicates the Router Advertisement from the legitimate default 528 router, except the included parameters are designed to disrupt 529 legitimate traffic. This is a DoS attack. 531 Specific attacks include: 533 1) The attacker includes a Current Hop Limit of one or another 534 small number which the attacker knows will cause legitimate 535 packets to be dropped before they reach their destination. 537 2) The attacker implements a bogus DHCPv6 server or relay and the 538 'M' and/or 'O' flag is set, indicating that stateful address 539 configuration and/or stateful configuration of other 540 parameters should be done. The attacker is then in a position 541 to answer the stateful configuration queries of a legitmate 542 host with its own bogus replies. 544 draft-ietf-send-psreq-00.txt P. Nikander (editor) 546 This attack involves Router Advertisements. 548 This attack is not a concern if access to the link is restricted to 549 trusted nodes. In the case of a trusted operator, there must be a 550 means for the nodes to make a distinction between trustworthy 551 routers, run by the operator, and other nodes. There are currently 552 no known solutions for the ad hoc network case, and the issue 553 remains as a research question. 554 4.3 Remotely exploitable attacks 556 4.3.1 Neighbor Discovery DoS Attack 558 In this attack, the attacking node begins fabricating addresses with 559 the subnet prefix and continuously sending packets to them. The last 560 hop router is obligated to resolve these addresses by sending 561 neighbor solicitation packets. A legitimate host attempting to enter 562 the network may not be able to obtain Neighbor Discovery service 563 from the last hop router as it will be already busy with sending 564 other solicitations. This DoS attack is different from the others in 565 that the attacker may be off link. The resource being attacked in 566 this case is the conceptual neighbor cache, which will be filled 567 with attempts to resolve IPv6 addresses having a valid prefix but 568 invalid suffix. This is a DoS attack. 570 This attack involves Neighbor Solicitation. 572 This attack does not directly involve the trust models presented. 573 However, if access to the link is restricted to registed nodes, and 574 the access router keeps track of nodes that have registered for 575 access on the link, the attack may be trivially plugged. However, 576 no such mechanisms are currently standardized. 578 It is an open question whether the SEND WG should address this 579 threat or not. 581 draft-ietf-send-psreq-00.txt P. Nikander (editor) 583 4.4 Summary of the attacks 585 Columns: 587 N/R Neighbor Discovery (ND) or Router Discovery (RD) attack 588 R/D Redirect/DoS (Redir) or just DoS attack 589 Msgs Messages involved in the attack: NA, NS, RA, RS, Redir 590 1 Present in trust model 1 (corporate intranet) 591 2 Present in trust model 2 (public operator run network) 592 3 Present in trust model 3 (ad hoc network) 594 Symbols in trust model columns: 596 - The threat is not present 597 + The threat is present and at least one solution is known 598 R The threat is present but solving it is a research problem 600 +-------+----------------------------+-----+-------+-------+---+---+---+ 601 | Sec | Attack name | N/R | R/D | Msgs | 1 | 2 | 3 | 602 +-------+----------------------------+-----+-------+-------+---+---+---+ 603 | 4.1.1 | NS/NA spoofing | ND | Redir | NA NS | - | + | + | 604 | 4.1.2 | NUD failure | ND | DoS | NA NS | - | + | + | 605 | 4.1.3 | DAD DoS | ND | DoS | NA NS | - | + | + | 606 +-------+----------------------------+-----+-------+-------+---+---+---+ 607 | 4.2.1 | Malicious router | RD | Redir | RA RS | - | + | R | 608 | 4.2.2 | Good router goes bad | RD | Redir | RA RS | R | R | R | 609 | 4.2.3 | Spoofed redirect | RD | Redir | Redir | - | + | R | 610 | 4.2.4 | Bogus on-link prefix | RD | DoS | RA | - | + | R | 611 | 4.2.5 | Bogus address config prefix| RD | DoS | RA | - | + | R | 612 | 4.2.6 | Parameter spoofing | RD | DoS | RA | - | + | R | 613 +-------+----------------------------+-----+-------+-------+---+---+---+ 614 | 4.3.1 | Remote ND DoS | ND | DoS | NS | + | + | + | 615 +------------------------------------+-----+-------+-------+---+---+---+ 616 draft-ietf-send-psreq-00.txt P. Nikander (editor) 618 5.0 Security Considerations 620 This document discusses security threats to network access in IPv6. 621 As such, it is concerned entirely with security. 623 6.0 Acknowledgements 625 Thanks to Alper Yegin of DoCoMo Communications Laboratories USA for 626 identifying the Neighbor Discovery DOS attack. We would also like 627 to thank Tuomas Aura and Michael Roe of Microsoft Research 628 Cambridge as well as Jari Arkko and Vesa-Matti M�ntyl� of Ericsson 629 Research Nomadiclab for discussing some of the threats with us. 631 7.0 References 633 [RFC2461] T. Narten, E. Nordmark, and W. Simson, "Neighbor 634 Discovery for IP Version 6 (IPv6)," RFC2461, 635 December, 1998. 637 [RFC2462] Thomas, S., and Narten, T., "IPv6 Stateless Address 638 Autoconfiguration," RFC 2462, December, 1998. 640 [RFC2402] Kent, S., and Atkinson, R., "IP Authentication Header," RFC 641 2402, November 1998. 643 [MIP_TH] Mankin, et. al., "Threat Models introduced by Mobile IPv6 and 644 Requirements for Security in Mobile IPv6," draft-ietf-mobileip- 645 mipv6-scrty-reqts-01.txt, a work in progress. 647 [EAP] Blunk, L., and Vollbrecht, J., "PPP Extensible Authentication 648 Protocol (EAP)," RFC 2284, March, 1998. 650 [RFC2472] Haskin, D. and Allen, E., "IP Version 6 over PPP," RFC 2472, 651 December, 1998. 653 [DHCPv6] Droms, R., editor, "Dynamic Host Configuration Protocol for 654 IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-20.txt, a work in 655 progress. 657 [ABK] J. Kempf, C. Gentry, A. Silverberg, "Securing IPv6 658 Neighbor Discovery Using Address Based Keys (ABKs)," 659 work in progress, draft-kempf-secure-nd-00.txt, 660 February 2002. 662 [CGA] M. Roe, T. Aura, G. O'Shea, J. Arkko, "Authentication 663 of Mobile IPv6 binding updates and acknowledgements," 664 work in progress, draft-roe-mobileip-updateauth-02.txt, 665 IETF Mobile IP WG, February 2002. 667 [IKE-ND] J. Arkko, "Effects of ICMPv6 on IKE and IPsec 668 Policies," work in progress, 669 drat-arkko-icmpv6-ike-effects-02.txt, June 2002. 671 draft-ietf-send-psreq-00.txt P. Nikander (editor) 673 8.0 Authors' Addresses 675 Pekka Nikander (editor) 676 Ericsson Research Nomadic Lab Phone: +358 9 299 1 677 FIN-02420 JORVAS Email: pekka.nikander@nomadiclab.com 678 FINLAND 680 James Kempf 681 DoCoMo USA Labs 682 181 Metro Drive, Suite 300 Phone: +1 408 451 4711 683 San Jose, CA, 95110 Email: kempf@docomolabs-usa.com 684 USA 686 Erik Nordmark 687 Sun Microsystems Laboratories Phone: +33 4 76 18 88 03 688 29, Chemin du Vieux Chene Fax: +33 4 76 18 88 88 689 38240 Meylan Email: erik.nordmark@sun.com 690 France 692 9.0 Copyright Statement 694 Copyright (c) The Internet Society (2002). All Rights Reserved. This 695 document and translations of it may be copied and furnished to 696 others, and derivative works that comment on or otherwise explain it 697 or assist in its implementation may be prepared, copied, published 698 and distributed, in whole or in part, without restriction of any 699 kind, provided that the above copyright notice and this paragraph are 700 included on all such copies and derivative works. However, this 701 document itself may not be modified in any way, such as by removing 702 the copyright notice or references to the Internet Society or other 703 Internet organizations, except as needed for the purpose of 704 developing Internet standards in which case the procedures for 705 copyrights defined in the Internet Standards process must be 706 followed, or as required to translate it into languages other than 707 English. 709 The limited permissions granted above are perpetual and will not be 710 revoked by the Internet Society or its successors or assigns. 712 This document and the information contained herein is provided on an 713 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 714 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 715 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 716 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 717 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 719 SEND Working Group P. Nikander (editor) 720 Expires: April 17, 2002