idnits 2.17.1 draft-arkko-manual-icmpv6-sas-02.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 a Security Considerations section. ** 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.) == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (March 3, 2003) is 7697 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) ** Obsolete normative reference: RFC 2373 (ref. '2') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2401 (ref. '3') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (ref. '4') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2461 (ref. '5') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '6') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2463 (ref. '7') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3041 (ref. '8') (Obsoleted by RFC 4941) == Outdated reference: A later version (-01) exists of draft-ietf-send-ipsec-00 == Outdated reference: A later version (-04) exists of draft-ietf-send-psreq-00 == Outdated reference: A later version (-02) exists of draft-arkko-icmpv6-ike-effects-01 Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft P. Nikander 4 Expires: September 1, 2003 Ericsson 5 T. Kivinen 6 M. Rossi 7 SSH Communications Security 8 March 3, 2003 10 Manual Configuration of Security Associations for IPv6 Neighbor 11 Discovery 12 draft-arkko-manual-icmpv6-sas-02.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 1, 2003. 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 This informational document discusses the use of manually configured 44 IPsec security associations to protect IPv6 Neighbor Discovery (ND) 45 messages. IPsec security associations are generally identified by 46 the triple (security parameters index, destination address, 47 protocol). In the case of Neighbor Discovery, configuring these 48 associations requires some effort, however. There are multiple known 49 destination addresses plus a number of addresses that depend on the 50 physical link addresses. This document describes the security 51 implications of protecting or not protecting the Neighbor Discovery 52 messages and lists the security associations that must be configured 53 manually. The presented method is applicable only in small networks, 54 but some approaches for reducing the configuration effort are 55 discussed. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. Neighbor Discovery Tasks . . . . . . . . . . . . . . . . . . . 8 64 5.1 Router and Prefix Discovery . . . . . . . . . . . . . . 8 65 5.2 Address Autoconfiguration . . . . . . . . . . . . . . . 8 66 5.3 Duplicate Address Detection . . . . . . . . . . . . . . 9 67 5.4 Address Resolution . . . . . . . . . . . . . . . . . . . 9 68 5.5 Neighbor Reachability Detection . . . . . . . . . . . . 9 69 5.6 Redirect . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6. Recommendation for manual security association setup . . . . . 11 71 7. Security Implications of Neighbor Discovery Messages . . . . . 14 72 7.1 Router Discovery . . . . . . . . . . . . . . . . . . . . 15 73 7.2 Address Resolution . . . . . . . . . . . . . . . . . . . 15 74 7.3 Duplicate Address Detection . . . . . . . . . . . . . . 16 75 7.4 Address Autoconfiguration . . . . . . . . . . . . . . . 16 76 7.5 Neighbor Reachability Detection . . . . . . . . . . . . 16 77 7.6 Redirect . . . . . . . . . . . . . . . . . . . . . . . . 17 78 7.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . 17 79 8. Approaches for Reducing Configuration Effort . . . . . . . . . 19 80 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 Normative References . . . . . . . . . . . . . . . . . . . . . 22 82 Informative References . . . . . . . . . . . . . . . . . . . . 23 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 84 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 85 Intellectual Property and Copyright Statements . . . . . . . . 26 87 1. Introduction 89 IPv6 architecture makes it possible to secure all IP packets using 90 IPsec [3], even control messages and even to multicast addresses. 91 IPsec architecture has a Security Policy Database that specifies 92 which traffic is protected, and how. 94 The IPv6 Neighbor Discovery [5] protocol is intended to be used for 95 router discovery, address resolution, and other tasks on the local 96 link. As described elsewhere [11], dynamically negotiated security 97 associations cannot be used to protect these messages as the 98 negotiation would already require the messages to have been 99 exchanged. Instead, manually configured security associations must 100 be used. 102 However, setting up these security associations is not easy. This 103 document lists those fixed multicast, calculated multicast, and node 104 addresses for which the security associations must be created. We 105 will also discuss the security implications of the Neighbor Discovery 106 messages under various assumptions of attacker capabilities. 107 Finally, we discuss approaches that can be used to reduce 108 configuration work in setting up the manual security associations. 109 These approaches include configuration tools, the use of well-known 110 SPI numbers with special treatment, and new protocols. 112 The configuration guidelines in this document are one approach which 113 MAY be used by system administrators. The guidelines do not imply 114 any implementation modifications or extensions for Neighbor Discovery 115 or IPsec. However, the ability of IPsec security policy entries to 116 use ICMP type as a selector eases the construction of the entries. 117 Such extensions are outside the scope of this document. 119 2. Terminology 121 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [1]. 125 3. Terms 127 Internet Control Message Protocol version 6 (ICMPv6) 129 The IPv6 control signaling protocol. Neighbor Discovery is a part 130 of ICMPv6. 132 Neighbor Discovery (ND) 134 The IPv6 Neighbor Discovery protocol [5]. 136 Security association (SA) 138 A security association (SA) is a simplex "connection" that affords 139 security services to the traffic carried by it. Security services 140 are afforded to an security association by the use of AH, or ESP, 141 but not both. A security association is uniquely identified by a 142 triple consisting of a Security Parameter Index (SPI), an IP 143 Destination Address, and a security protocol (AH or ESP) 144 identifier [3]. 146 Security Association Database (SAD) 148 A nominal database containing parameters that are associated with 149 each (active) security association. For inbound and outbound 150 IPsec processing, these databases are separate. 152 Security Parameters Index (SPI) 154 An arbitrary 32-bit value. Together with the destination IP 155 address and security protocol (ESP or AH) identifier, the SPI 156 uniquely identifies the Security Association. Values from 1 to 157 255 are reserved. 159 Security Parameters Index (SPI) 161 A security parameters index identifies a particular security 162 association among a group of security associations with the same 163 destination address and protocol. 165 Security Policy 167 The security policy determines the security services afforded to 168 an IPsec protected packet and the treatment of the packet in the 169 network. 171 Security Policy Database (SPD) 173 A nominal database containing a list of policy entries. Each 174 policy entry is keyed by one or more selectors that define the set 175 of IP traffic encompassed by this policy entry. Separate entries 176 for inbound and outbound traffic is required [3]. 178 4. Addressing 180 Neighbor Discovery messages are sent using various kinds of source 181 and destination address types. The nature of the destination address 182 is of relevance here, as the destination address is used to find the 183 right security association. The destination address can be either a 184 well known multicast address, a computed multicast address, such as 185 the solicited-node multicast address, or a unicast address. Many 186 Neighbor Discovery messages use multicast addresses in most cases. 187 Some messages can also be sent to unicast addresses in certain 188 situations. For instance, the Neighbor Solicitation messages are 189 usually sent to multicast addresses, but the Neighbor Advertisement 190 messages are also sent to unicast addresses when sent as a response 191 to a node that has an address. 193 The Neighbor Discovery specifications do not always use specific 194 language when talking about the possible forms of addresses for the 195 messages. The word "typically" is in some cases used to describe an 196 address that would most logically be used for a particular message, 197 but other addresses may still be used in some situations or in some 198 implementations. 200 5. Neighbor Discovery Tasks 202 Neighbor Discovery has several tasks, and many of these tasks are 203 overloaded on a few central message types such as the Neighbor 204 Solicitation message. In this chapter we explain some of these tasks 205 and their effects in order to understand better how the messages 206 should be treated. We will only discuss those tasks for which manual 207 security association protection is relevant, i.e., which cannot be 208 protected using IKE-based [4] security associations according to 209 [11]. 211 5.1 Router and Prefix Discovery 213 The main purpose of the router discovery is to find neighboring 214 routers that are willing to forward packets on the behalf of hosts. 215 Prefix discovery involves determining which destinations are directly 216 on a link; this information is necessary in order to know whether a 217 packet should be sent to a router or to the destination directly. 218 Typically, address autoconfiguration and other tasks can not proceed 219 until the router discovery process has run. 221 The Router Solicitation and Router Advertisement messages are used 222 for this and only this purpose. 224 The Router Solicitation message has ICMPv6 type 133. The destination 225 address is typically the All Routers multicast address [2]. This 226 message is always used only locally on the link. 228 The Router Advertisement message has ICMPv6 typer 134. The 229 destination address can be either a unicast or the All Nodes 230 multicast address [2]. Like the solicitation message, the 231 advertisement is also local to the link only. 233 5.2 Address Autoconfiguration 235 Address autoconfiguration is another part of the Neighbor Discovery 236 protocol [6]. It's purpose is to automatically assign addresses to 237 interfaces. It comes in two variants, stateless and stateful. In 238 this document we consider only the stateless autoconfiguration 239 aspects. 241 The Neighbor Solicitation and Advertisement messages are used for 242 this purpose, among other things. Furthermore, Router and Prefix 243 Discovery and Duplicate Address Detection have an effect to the 244 Address Autoconfiguration tasks. 246 The Neighbor Solicitation message has ICMPv6 type 135. The 247 destination address is either the solicited node multicast address, 248 unicast address, or an anycast address [2, 7]. Neighbor Solicitation 249 and Advertisement messages are used for multiple purposes: address 250 autoconfiguration, duplicate address detection, and reachability 251 detection. In all these roles they are link local. 253 The Neighbor Advertisement type is 136. The the destination address 254 is either a unicast address or the All Nodes multicast address [2]. 255 Like the solicitation message, this message is link local. 257 5.3 Duplicate Address Detection 259 As a part of the stateless address autoconfiguration procedure, nodes 260 check for duplicate addresses prior to assigning an address to an 261 interface [6]. This procedure uses the same messages as the Neighbor 262 Discovery protocol [5]. Since the rules outlined in RFC 2462 [6] 263 forbid the use of an address for both sending and receiving packets 264 until it has been found unique, no higher layer traffic is possible 265 until this procedure has completed. 267 The Neighbor Solicitation and Advertisement messages are used also 268 for this purpose. 270 5.4 Address Resolution 272 In address resolution nodes determine the link-layer address of a 273 local destination given only the destination's IP address. Again, no 274 higher level traffic can proceed until the sender knows the hardware 275 address of the destination or the next hop router. 277 The Neighbor Solicitation and Advertisement messages are used also 278 for this purpose. 280 5.5 Neighbor Reachability Detection 282 Hosts monitor the reachability of local destinations and routers in 283 the Neighbor Unreachability procedure, which is a part of the 284 Neighbor Discovery protocol [5]. No higher level traffic can proceed 285 if this procedure flushes out neighbor cache entries after (perhaps 286 incorrectly) determining that the peer is not reachable. 288 The Neighbor Solicitation and Advertisement messages are used also 289 for this purpose. 291 5.6 Redirect 293 In the Redirect procedure, a router informs a host of a better 294 first-hop node to reach a particular destination [5]. It is a part 295 of the Neighbor Discovery protocol. As routers forward packets 296 regardless of them being sent first to the wrong place, 297 communications can still be established without the ability to 298 process Redirect messages. 300 The Redirect message is used solely in the Redirect procedure. Its 301 ICMPv6 type is 137. The Redirect message is always sent from a 302 unicast addresses to the source address of the packet that triggered 303 the Redirect. Rules in RFC 2373 [2] dictate that unspecified, 304 anycast, or multicast addresses may not be used as source addresses. 305 Therefore, the destination address will always be a unicast address. 306 This message is only used for link local purposes, not for end-to-end 307 communications. 309 6. Recommendation for manual security association setup 311 As described above, Neighbor Discovery uses as a destination address 312 either an unicast address, a known multicast address, or a computed 313 multicast addresses (based on the physical link addresses). On a 314 given link, the following security associations are required if all 315 Neighbor Discovery traffic is to be secured with IPsec: 317 1. ICMPv6 packets to the All Nodes multicast address 318 FF02:0:0:0:0:0:0:1 [2]. 320 2. ICMPv6 packets to the All Routers multicast address 321 FF02:0:0:0:0:0:0:1 [2]. 323 3. For each node on the network, ICMPv6 packets to the Solicited 324 Node multicast address FF02:0:0:0:0:1:FFXX:XXXX target='RFC2373' 325 />. Note that, in general, there will be multiple such addresses 326 when there are multiple nodes, but it is also possible that some 327 of these multicast addresses collide since only 24 bits from the 328 physical link addresses are used in the multicast address. 330 4. For each node on the network, ICMPv6 packets to the unicast 331 address of that node. 333 Given that such ICMPv6 packets may be sent also from other 334 sources than the those on the local link, it is necessary to 335 construct the security policy entries in the following manner: 337 * Only the addresses of other nodes on the same link can appear 338 as the source address, along with the Unspecified address 339 (::). 341 * Alternatively, only ICMP types related to Neighbor Discovery 342 (Neighbor Solicitation, Neighbor Advertisement, Router 343 Solicitation, Router Advertisement, and Redirect) are listed. 344 However, this requires the IPsec security policy mechanisms to 345 support ICMP type as a selector in the manner described in 346 [9]. 348 5. For each node that has multiple unicast addresses, items (3) and 349 (4) have to be repeated for each address. 351 These rules result in at most 2 * (N * M + 1) security associations 352 where N is the number of nodes in the network and M is the number of 353 addresses each node has. Table 1 below tabulates the number of 354 security associations required as a function of the number of nodes 355 in the network: 357 +--------------+-------------+-------------+ 358 | # of Nodes | # of Addrs | # of SAs | 359 +--------------+-------------+-------------+ 360 | 1 | 1 | 4 | 361 +--------------+-------------+-------------+ 362 | 1 | 2 | 6 | 363 +--------------+-------------+-------------+ 364 | 4 | 1 | 10 | 365 +--------------+-------------+-------------+ 366 | 4 | 2 | 18 | 367 +--------------+-------------+-------------+ 368 | 10 | 1 | 22 | 369 +--------------+-------------+-------------+ 370 | 10 | 2 | 42 | 371 +--------------+-------------+-------------+ 372 | 20 | 1 | 42 | 373 +--------------+-------------+-------------+ 374 | 20 | 2 | 82 | 375 +--------------+-------------+-------------+ 376 | 50 | 1 | 102 | 377 +--------------+-------------+-------------+ 378 | 50 | 2 | 202 | 379 +--------------+-------------+-------------+ 380 | 100 | 1 | 202 | 381 +--------------+-------------+-------------+ 382 | 100 | 2 | 402 | 383 +--------------+-------------+-------------+ 384 | 1000 | 1 | 2002 | 385 +--------------+-------------+-------------+ 386 | 1000 | 2 | 4002 | 387 +--------------+-------------+-------------+ 389 The above setup also implies that one knows beforehand the physical 390 link and IP level addresses of each node on the link, including the 391 multiple addresses mentioned under (5). Normally, a node may not 392 necessarily know the addresses itself but they are rather specified 393 in the set of router advertisements received. These things 394 complicate the setup. But the complication is similar to the 395 requirement that the keys can be configured manually for all of these 396 nodes; it is not possible to provide security and at the same time 397 allow previously unknown nodes to the system when manual keying is 398 used. 400 Note that if the address privacy extension [8] is used for address 401 autoconfiguration, it may not be possible to know the physical 402 address identifiers. Even if the hosts could reveal this information 403 for some time to the future, the network would have to support 404 multiple addresses for the same node. One possible way to deal with 405 this is to use stable addresses for link local messages and run IPsec 406 tunnel mode to autoconfigure the temporary identifiers, and then use 407 those for the end-to-end traffic. 409 7. Security Implications of Neighbor Discovery Messages 411 In this chapter we discuss the security implications of either 412 securing or not securing the link local messages. In this analysis 413 we will make a few alternative assumptions. The first assumption is 414 that all subsequent communications at a higher level are secured 415 using e.g. IPsec and IKE. It can be argued that making this 416 assumption is reasonable since higher level traffic can already very 417 well be secured using existing mechanisms, and if security is of 418 interest, these mechanisms should be used. Note that this assumption 419 has a number of consequences. For instance, being able to redirect a 420 message flow to an attacker does not really gain any information 421 about the flow. 423 In practice we can not always have secure higher layer 424 communications. First of all, because there is always some traffic 425 that goes to public servers e.g. on the Internet and it is not 426 likely that we will have the trust and key infrastructure necessary 427 to be able to communicate with everyone securely. Secondly, even for 428 other communications it may be that upper layer security does not 429 exist for reasons of missing support in the involved nodes, lack of 430 time to set these up properly, or performance. Therefore, it also 431 also necessary to study the security implications of the Neighbor 432 Discovery messages in the case of insecure higher layers. 434 The second set of alternative assumptions divides the tools the 435 attacker has available in to two categories. The weak attacker can 436 do nothing more than eavesdrop other messages and inject forged 437 messages. The strong attacker can also block some or all messages. 438 It is interesting to consider these two as separate, because strong 439 measures such as jamming WLAN reception are likely to be detected and 440 less likely to be available to large numbers of attackers, whereas 441 the weak measures are easily available to anyone with standard 442 hardware and software. 444 We will use the following attacks to classify the dangers: 446 o Denial-of-Service. For instance, being able to block all traffic 447 to and from a node. 449 o Impersonation; the ability of the attacker to claim that it is the 450 node at a particular IP address and not the real node. 452 o Spying; being able to read packets in transit. In general, spying 453 is always possible for the local traffic unless higher layer 454 security is in place. 456 o Man-in-the-middle; being able to read and modify packets in 457 transit. In general, this is always possible on a local link for 458 a strong attacker if there is no higher layer security. 460 o Identity selection; being able to have an effect to the IP address 461 selection of a node. 463 7.1 Router Discovery 465 First we deal with the secure higher layer assumption. A weak 466 attacker can make the network believe there are additional addresses 467 and prefixes on the link, or that the route towards the Internet is 468 on another router than it really is. However, since hosts are 469 required to detect when communication to a destination appears to be 470 failing [5] they should be able to find the real router sooner or 471 later. Also, additional address prefixes should not cause any 472 problems either, except in the case the attacker makes the host 473 believe that a destination somewhere else is actually on the link. 474 In this special case the result is a Denial-of-Service attack. 476 Strong attackers can also hide prefixes and addresses and routers 477 that really exist on the link. As such, they can perform various 478 kinds of Denial-of-Service attacks. 480 In the case of insecure higher layers, even weak attackers can read 481 and modify traffic contents towards remote destinations, or 482 impersonate as something they are not. For instance, if the weak 483 attacker has control over a node outside the local link, he can 484 tunnel all traffic he receives from himself to this outside node, 485 resulting in a Man-in-the-Middle attack. The situation may continue 486 for an extended period of time, not allowing the nodes to find out 487 the "real" router but diverting all traffic through the attacker. A 488 strong attacker can perform impersonation on the behalf of any node 489 on the link by hiding the router advertisement with the correct 490 prefix, and claiming to be a router towards the impersonated node. 491 Reading and modification of local traffic is also possible using only 492 router discovery messages through sending different router discovery 493 messages to different nodes on the same network. 495 7.2 Address Resolution 497 In the secure higher layer situation, weak attackers can cause a 498 Denial-of-Service by making other nodes on the link believe that the 499 node is in some other address than it really is on. 501 Strong attackers can also prevent correct address resolution messages 502 from being read by others, but the result of this is no worse than 503 the Denial-of-Service already caused by the weak attacker. 505 In the case of no security at higher layers, both weak and strong 506 attackers can read traffic destined anywhere as well as impersonate 507 other nodes and perform Man-in-the-Middle attacks. Even weak 508 attackers can fake address resolution messages by sending forged 509 messages right after seeing the correct ones. 511 7.3 Duplicate Address Detection 513 Regardless of the higher layer security situation, a weak attacker 514 can easily forge messages that cause other nodes on the link to 515 believe their addresses are duplicates. This makes it impossible for 516 them to communicate using these addresses, causing an all-out 517 Denial-of-Service situation. 519 Strong attackers can cause nodes to believe there is no duplicates 520 when there is one in fact. This will cause several problems later in 521 the communication, in practice leading to a Denial-of-Service 522 situation for all or most communication from the nodes. On the other 523 hand, if there really was a duplicate address situation they would 524 not have been able to communicate in the first place. Therefore, the 525 strong attacker can not really cause any more damage than the weak 526 one. 528 When stateful address autoconfiguration is used, both weak and strong 529 attackers can use the duplicate address detection procedure to 530 artificially cause given addresses to fail; it may be possible to 531 force a particular address to be selected by repeatedly blocking the 532 use of certain addresses. 534 7.4 Address Autoconfiguration 536 All attacks against the duplicate address detection and router 537 discovery apply also here. 539 7.5 Neighbor Reachability Detection 541 The weak attacker can only make a node believe that another node is 542 up when in reality it is not. This can be done by sending a forged 543 answer to a reachability detection message. This causes a weak form 544 of a Denial-of-Service attack; the communications would not have 545 succeeded anyway but now one node thinks that it can communicate with 546 the other node. Depending on what kind of communications is in 547 question, this may imply either nothing or delay the attempt of the 548 node to switch to an alternative communications partner. 550 A strong attacker can also cause the reverse, i.e. make a node 551 believe that another node is down. This results in a full 552 Denial-of-Service attack. 554 7.6 Redirect 556 At worst in the secure higher layer case, the attacker succeeds in a 557 Denial-of-Service attack by either constructing a forged Redirect 558 message or blocking a real Redirect message. The latter action is 559 only available to a strong attacker. 561 In the case of insecure higher layer, any attacker can now reroute 562 non-local traffic to itself, presenting additional opportunities for 563 spying, impersonation and Man-in-the-Middle attacks. 565 7.7 Summary 567 The following table summarizes the security effects of the link local 568 control functions under different assumption. In the table we have 569 listed the additional dangers resulting e.g. from an insecure 570 address resolution function. The table does not include dangers 571 already inherent in the network otherwise, such as the obvious 572 ability to read all traffic given insecure higher layer protocols. 574 +-----------+---------------------------+---------------------------+ 575 | | Secure higher layer | Insecure higher layer | 576 | Control +-------------+-------------+-------------+-------------+ 577 | Function | Weak | Strong | Weak | Strong | 578 | | Attacker | Attacker | Attacker | Attacker | 579 +-----------+-------------+-------------+-------------+-------------+ 580 | Router | DoS(R) | DoS | DoS(R),Spy- | DoS, Spy, | 581 | Discovery | | | (R), Imp(R),| Imp, | 582 | | | | MitM(R) | MitM | 583 +-----------+---------------------------+---------------------------+ 584 | Address | DoS | DoS | DoS, Spy, | DoS, Spy, | 585 | Resolution| | | Imp, MitM | Imp, MitM | 586 | | | | | | 587 +-----------+---------------------------+---------------------------+ 588 | Duplicate | DoS, | DoS, | DoS, | DoS, | 589 | Address | IDSel(Sf) | IDSel(Sf) | IDSel(Sf) | IDSel(Sf) | 590 | Detection | | | | | 591 +-----------+---------------------------+---------------------------+ 592 | Address | DoS, | DoS, | DoS, | DoS, | 593 | Autoconfi-| IDSel(Sf) | IDSel(Sf) | IDSel(Sf) | IDSel(Sf) | 594 | guration | | | | | 595 +-----------+---------------------------+---------------------------+ 596 | Neighbor | DoS(Pd) | DoS | DoS(Pd) | DoS | 597 | Reachab. | | | | | 598 | Detection | | | | | 599 +-----------+---------------------------+---------------------------+ 600 | Redirect | DoS(R) | DoS(R) | DoS(R),Spy- | DoS(R),Spy- | 601 | | | | (R), Imp(R),| (R), Imp(R),| 602 | | | | MitM(R) | MitM(R) | 603 +-----------+---------------------------+---------------------------+ 605 Notation: 607 DoS = Denial-of-Service 608 Spy = Listening in 609 Imp = Impersonation 610 MitM = Man-in-the-Middle 611 IDSel = Identity selection (forcing a particular IP address on a 612 host) 613 (R) = This attack is only possible for traffic destined to hosts 614 outside the local link 615 (Sf) = This attack is possible only with stateful address 616 autoconfiguration 617 (Pd) = Weak form; the attack only succeeds in hiding the fact that 618 the other peer is down 620 These results can be compared to the original situation for payload 621 packets. In there, weak attackers cannot perform any attacks if 622 there is security at higher layers, but strong attackers succeed in 623 Denial-of-Service. If there is no security at higher layers, both 624 weak and strong attackers also succeed in Denial-of-Service and can 625 perform Spying, Impersonation and Man-in-the-Middle attacks. In 626 conclusion, the additional dangers resulting from the insecure 627 control traffic are the following: 629 Denial-of-Service for weak attackers under higher layer security. 631 Man-in-the-Middle, Spying, and Impersonation for all attackers 632 under no higher layer security. 634 Identity selection in all situations, if stateful address 635 autoconfiguration is used. 637 8. Approaches for Reducing Configuration Effort 639 If the Neighbor Discovery messages need to be protected in a given 640 environment, a number of security associations is needed. One may 641 question the feasibility of configuring very large networks in this 642 manner. There are possible remedies for this situation. These 643 include the following: 645 o Management tools exist at a higher level to create security 646 associations for the link local traffic in an easy manner for the 647 user, but several security associations would still be used on the 648 wire. This has the effect of removing the configuration problems 649 for the user while still being able to use existing 650 implementations as is. However, resources such as memory must 651 still be reserved for the security associations. 653 o A well-known SPI number could be reserved from the 654 IANA-administered range (0-255) to stand for Neighbor Discovery 655 protection. In conjunction with this, the rules for processing 656 incoming IPsec packets would have to be changed in order to ignore 657 the destination address for this special SPI. This has 658 implications to existing implementations, and potentially even 659 hardware-based packet matching and/or security association search. 661 A fixed set of security association parameters must be used 662 throughout the local network. Obviously, replay protection can 663 not be employed as several nodes use the same security 664 associations. It might be possible to use more than SPI number to 665 enable the simultaneous use of several security associations 666 during a manual key change period (such changes would typically be 667 long-lasting since mobile nodes might easily be away from their 668 home LAN for weeks). 670 This approach has the advantage that it would enable the use of 671 the address privacy extension [8] as the security associations 672 could be configured without knowledge of the actual physical 673 addresses and/or randomly generated temporary addresses. 675 o In conjunction with the above, an automatic change procedure could 676 be designed to force the nodes to regularly update the local 677 security association from a central server. One of the routers on 678 the link could act as the server. 680 o A unicast key management protocol and a group key management 681 protocol would be used to create security associations for the 682 Neighbor Discovery traffic. It is not clear, however, if this is 683 feasible. Reference [11] already describes how IKE runs into 684 chicken and egg problems in this area; and this is not simply a 685 problem of IKE but rather a fundamental limitation in 686 communications architecture. Likewise, it is likely that 687 multicast key management schemes such as those worked by the 688 multicast key management WG in the IETF will run into similar 689 problems. 691 o A specific key management mechanism could be developed for 692 Neighbor Discovery. Such a protocol would run as a part of the 693 ICMPv6 messages. This seems to be a possible approach and ideas 694 along this approach have been presented [12] and [9]. The 695 protocol would have to handle both unicast and multicast key 696 management. 698 9. Conclusions 700 When payload packets are cryptographically protected, 701 Denial-of-Service is the most serious attack ``weak attackers'' are 702 able to mount on Neighbor Discovery. When these messages are 703 protected with IPsec as well, in the manner described in this 704 document, these attacks can be prevented. Against a ``strong 705 attacker'', Denial-of-Service can not be prevented, for instance the 706 whole radio link can be jammed. However, such attacks are perhaps 707 easier to detect than IP-layer attacks. 709 Without security for payload packets, the situation is more serious 710 and even weak attackers can perform various kinds of attacks, 711 including Impersonation and Spying. This is particularly dangerous 712 as it is likely that at least some traffic on the Internet will 713 remain unprotected well into the future. 715 The Denial-of-Service and other attacks performed by outsiders can be 716 solved with the use of IPsec. In order to use IPsec, the security 717 associations must be configured manually as described in this 718 document. A fair amount of configuration work is involved, and this 719 scheme is generally possible only on a limited scale. A more 720 scalable method which requires IPsec extensions is described in [9]. 722 This work does not consider the authorization problems in Neighbor 723 Discovery. These are treated more in depth in [9] and [10]. The 724 Neighbor Discovery protocol provides no mechanism to determine, which 725 neighbors are authorized to send a particular type of message, e.g a 726 Router Advertisement. The current set of IPsec policy selectors do 727 not allow us to define which nodes are allowed to send which 728 particular Neighbor Discovery messages. Furthermore, even if a 729 particular node is authorized to send Neighbor Advertisements, it is 730 usually authorized to send them only on its own behalf. Thus, the 731 presented mechanisms can not protect against attacks from the 732 legitimate hosts in the same manner as is possible in [9]. 734 Normative References 736 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 737 Levels", BCP 14, RFC 2119, March 1997. 739 [2] Hinden, R. and S. Deering, "IP Version 6 Addressing 740 Architecture", RFC 2373, July 1998. 742 [3] Kent, S. and R. Atkinson, "Security Architecture for the 743 Internet Protocol", RFC 2401, November 1998. 745 [4] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 746 RFC 2409, November 1998. 748 [5] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 749 IP Version 6 (IPv6)", RFC 2461, December 1998. 751 [6] Thomson, S. and T. Narten, "IPv6 Stateless Address 752 Autoconfiguration", RFC 2462, December 1998. 754 [7] Conta, A. and S. Deering, "Internet Control Message Protocol 755 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 756 Specification", RFC 2463, December 1998. 758 [8] Narten, T. and R. Draves, "Privacy Extensions for Stateless 759 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 761 Informative References 763 [9] Arkko, J., Kempf, J., Sommerfeld, B. and B. Zill, "SEcure 764 Neighbor Discovery (SEND) Protocol", 765 draft-ietf-send-ipsec-00.txt (work in progress), February 2003. 767 [10] Nikander, P., "IPv6 Neighbor Discovery trust models and 768 threats", draft-ietf-send-psreq-00 (work in progress), October 769 2002. 771 [11] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies", 772 draft-arkko-icmpv6-ike-effects-01 (work in progress), June 773 2002. 775 [12] Nikander, P., "Denial-of-Service, Address Ownership, and Early 776 Authentication in the IPv6 World", Proceedings of the Cambridge 777 Security Protocols Workshop, April 2001. 779 Authors' Addresses 781 Jari Arkko 782 Ericsson 783 Jorvas 02420 784 Finland 786 EMail: jari.arkko@ericsson.com 788 Pekka Nikander 789 Ericsson 790 Jorvas 02420 791 Finland 793 EMail: Pekka.Nikander@nomadiclab.com 795 Tero Kivinen 796 SSH Communications Security 797 Fredrikinkatu 42 798 Helsinki 00100 799 Finland 801 EMail: kivinen@ssh.fi 802 Markku Rossi 803 SSH Communications Security 804 Fredrikinkatu 42 805 Helsinki 00100 806 Finland 808 EMail: mtr@ssh.fi 810 Appendix A. Acknowledgements 812 The authors would like that Erik Nordmark, James Kempf, Bill 813 Sommerfeld, Gabriel Montenegro, Tuomas Aura, Mike Roe, and others for 814 interesting discussions in this problem space. 816 Intellectual Property Statement 818 The IETF takes no position regarding the validity or scope of any 819 intellectual property or other rights that might be claimed to 820 pertain to the implementation or use of the technology described in 821 this document or the extent to which any license under such rights 822 might or might not be available; neither does it represent that it 823 has made any effort to identify any such rights. Information on the 824 IETF's procedures with respect to rights in standards-track and 825 standards-related documentation can be found in BCP-11. Copies of 826 claims of rights made available for publication and any assurances of 827 licenses to be made available, or the result of an attempt made to 828 obtain a general license or permission for the use of such 829 proprietary rights by implementors or users of this specification can 830 be obtained from the IETF Secretariat. 832 The IETF invites any interested party to bring to its attention any 833 copyrights, patents or patent applications, or other proprietary 834 rights which may cover technology that may be required to practice 835 this standard. Please address the information to the IETF Executive 836 Director. 838 Full Copyright Statement 840 Copyright (C) The Internet Society (2003). All Rights Reserved. 842 This document and translations of it may be copied and furnished to 843 others, and derivative works that comment on or otherwise explain it 844 or assist in its implementation may be prepared, copied, published 845 and distributed, in whole or in part, without restriction of any 846 kind, provided that the above copyright notice and this paragraph are 847 included on all such copies and derivative works. However, this 848 document itself may not be modified in any way, such as by removing 849 the copyright notice or references to the Internet Society or other 850 Internet organizations, except as needed for the purpose of 851 developing Internet standards in which case the procedures for 852 copyrights defined in the Internet Standards process must be 853 followed, or as required to translate it into languages other than 854 English. 856 The limited permissions granted above are perpetual and will not be 857 revoked by the Internet Society or its successors or assignees. 859 This document and the information contained herein is provided on an 860 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 861 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 862 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 863 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 864 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 866 Acknowledgement 868 Funding for the RFC Editor function is currently provided by the 869 Internet Society.