idnits 2.17.1 draft-ietf-send-ipsec-00.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 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 461: '... MUST be at least 3. N is used as a...' RFC 2119 keyword, line 655: '... field MUST NOT be zero....' RFC 2119 keyword, line 659: '...d is unused. It MUST be initialized t...' RFC 2119 keyword, line 660: '... sender and MUST be ignored by th...' RFC 2119 keyword, line 669: '... Receivers MUST silently ignore a...' (87 more instances...) 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 (February 24, 2003) is 7730 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: '9' is defined on line 1779, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. '1') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2401 (ref. '2') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '3') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2407 (ref. '4') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2461 (ref. '6') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '7') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2463 (ref. '8') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3041 (ref. '9') (Obsoleted by RFC 4941) -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '15') (Obsoleted by RFC 4306) == Outdated reference: A later version (-02) exists of draft-arkko-icmpv6-ike-effects-01 == Outdated reference: A later version (-02) exists of draft-arkko-manual-icmpv6-sas-01 Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Expires: August 25, 2003 J. Kempf 5 DoCoMo Communications Labs USA 6 B. Sommerfeld 7 SUN Microsystems 8 B. Zill 9 Microsoft 10 February 24, 2003 12 SEcure Neighbor Discovery (SEND) 13 draft-ietf-send-ipsec-00.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 25, 2003. 38 Copyright Notice 40 Copyright (C) The Internet Society (2003). All Rights Reserved. 42 Abstract 44 IPv6 nodes use the Neighbor Discovery (ND) protocol to discover other 45 nodes on the link, to determine each other's link-layer addresses, to 46 find routers and to maintain reachability information about the paths 47 to active neighbors. If not secured, ND protocol is vulnerable to 48 various attacks. This document specifies an extension to IPsec for 49 securing ND. Contrary to the original ND specifications that also 50 called for use of IPsec, this extension does not require the creation 51 of a large number of manually configured security associations. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Neighbor and Router Discovery Overview . . . . . . . . . . . 6 58 4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 9 59 5. Cryptographically Generated Addresses . . . . . . . . . . . 11 60 5.1 Address Format . . . . . . . . . . . . . . . . . . . . 12 61 5.2 Basic Interface Identifier Generation . . . . . . . . 12 62 5.3 Address Generation . . . . . . . . . . . . . . . . . . 13 63 5.4 Duplicate Address Detection . . . . . . . . . . . . . 14 64 6. Authorization Delegation Discovery . . . . . . . . . . . . . 15 65 6.1 Delegation Chain Solicitation Message Format . . . . . 15 66 6.2 Delegation Chain Advertisement Message Format . . . . 17 67 6.3 Trusted Root Option . . . . . . . . . . . . . . . . . 19 68 6.4 Certificate Option . . . . . . . . . . . . . . . . . . 20 69 6.5 Processing Rules for Routers . . . . . . . . . . . . . 21 70 6.6 Processing Rules for Hosts . . . . . . . . . . . . . . 22 71 7. IPsec Extensions . . . . . . . . . . . . . . . . . . . . . . 25 72 7.1 The AH_RSA_Sig Transform . . . . . . . . . . . . . . . 25 73 7.1.1 Reserved SPI Number . . . . . . . . . . . . . . 25 74 7.1.2 Authentication Data Format . . . . . . . . . . . 25 75 7.1.3 AH_RSA_Sig Security Associations . . . . . . . . 27 76 7.1.4 Replay Protection . . . . . . . . . . . . . . . 28 77 7.1.5 Processing Rules for Senders . . . . . . . . . . 28 78 7.1.6 Processing Rules for Receivers . . . . . . . . . 29 79 7.2 Other IPsec Extensions . . . . . . . . . . . . . . . . 30 80 7.2.1 Destination Agnostic Security Associations . . . 30 81 7.2.2 ICMP Type Specific Selectors . . . . . . . . . . 31 82 8. Securing Neighbor Discovery with SEND . . . . . . . . . . . 32 83 8.1 Using IPsec to Secure Neighbor Advertisement Messages 32 84 8.2 Security Policy and SA Database Configuration . . . . 32 85 9. Securing Router Discovery with SEND . . . . . . . . . . . . 34 86 9.1 Using IPsec to Secure Router Advertisement Messages . 34 87 9.2 Using IPsec to Secure Redirect Messages . . . . . . . 34 88 9.3 Security Policy and SA Database Configuration . . . . 35 89 10. Operational Considerations . . . . . . . . . . . . . . . . . 37 90 11. Performance Considerations . . . . . . . . . . . . . . . . . 39 91 12. Security Considerations . . . . . . . . . . . . . . . . . . 40 92 12.1 Achieved Security Properties . . . . . . . . . . . . . 40 93 12.2 Attacks against SEND Itself . . . . . . . . . . . . . 40 94 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 42 95 14. Conclusions and Remaining Work . . . . . . . . . . . . . . . 43 96 Normative References . . . . . . . . . . . . . . . . . . . . 44 97 Informative References . . . . . . . . . . . . . . . . . . . 45 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 46 99 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 47 100 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 101 C. IPR Considerations . . . . . . . . . . . . . . . . . . . . . 49 102 Intellectual Property and Copyright Statements . . . . . . . 50 104 1. Introduction 106 IPv6 defines the Neighbor Discovery (ND) protocol in RFC 2461 [6]. 107 Nodes on the same link use the ND protocol to discover each other's 108 presence, to determine each other's link-layer addresses, to find 109 routers and to maintain reachability information about the paths to 110 active neighbors. The ND protocol is used both by hosts and routers. 111 Its functions include Router Discovery (RD), Address Auto- 112 configuration, Address Resolution, Neighbor Unreachability Detection 113 (NUD), Duplicate Address Detection (DAD), and Redirection. 115 RFC 2461 called for the use of IPsec for protecting the ND messages. 116 However, it turns out that in this particular application IPsec can 117 only be used with a manual configuration of security associations due 118 to chicken-and-egg problems [17] in using IKE [15] before ND is 119 operational. Furthermore, the number of security associations needed 120 for protecting ND is impractically large [18]. Finally, RFC 2461 did 121 not specify detailed instructions for using IPsec to secure ND. 123 Section 4 describes our overall approach to securing ND. This 124 approach involves the use of IPsec AH [3] to secure all 125 advertisements relating to Neighbor and Router Discovery. A new 126 transform for AH allows public keys to be used. Routers are 127 certified by a trusted root, and a zero-configuration mechanism for 128 showing address ownership. 130 Section 5 describes the mechanism for showing address ownership, 131 based on the use of Cryptographically Generated Addresses (CGAs). 132 Section 6 describes the mechanism for distributing certificate chains 133 to establish authorization delegation chain to a common trusted root. 134 Section 7 describes the necessary modifications to IPsec. Finally, 135 Section 8 show how to apply these components to securing Neighbor and 136 Router Discovery. 138 2. Terms 140 Cryptographically Generated Addresses (CGAs) A technique [22] where 141 the address of the node is cryptographically generated from the 142 public key of the node and some other parameters using a one-way 143 hash function. 145 Internet Control Message Protocol version 6 (ICMPv6) The IPv6 control 146 signaling protocol. Neighbor Discovery is a part of ICMPv6. 148 Neighbor Discovery (ND) The IPv6 Neighbor Discovery protocol [6]. 150 Security Association (SA) A Security Association (SA) is a simplex 151 "connection" that affords security services to the traffic carried 152 by it. Security services are afforded to an SA by the use of AH, 153 or ESP, but not both. A SA is uniquely identified by a triple 154 consisting of a Security Parameter Index (SPI), an IP Destination 155 Address, and a security protocol (AH or ESP) identifier [2]. 157 Security Association Database (SAD) A nominal database containing 158 parameters that are associated with each (active) security 159 association. For inbound and outbound IPsec processing, these 160 databases are separate. 162 Security Parameters Index (SPI) An arbitrary 32-bit value. Together 163 with the destination IP address and security protocol (ESP or AH) 164 identifier, the SPI uniquely identifies the Security Association. 165 Values from 1 to 255 are reserved. 167 Special SPI A Security Parameters Index from the reserved range 1 to 168 255. 170 Security Policy The Security Policy determines the security services 171 afforded to an IPsec protected packet and the treatment of the 172 packet in the network. 174 Security Policy Database (SPD) A nominal database containing a list 175 of policy entries. Each policy entry is keyed by one or more 176 selectors that define the set of IP traffic encompassed by this 177 policy entry. Separate entries for inbound and outbound traffic 178 is required [2]. 180 3. Neighbor and Router Discovery Overview 182 IPv6 Neighbor and Router Discovery have several functions. Many of 183 these functions are overloaded on a few central message types such as 184 the ICMPv6 Neighbour Discovery message. In this section we explain 185 some of these tasks and their effects in order to understand better 186 how the messages should be treated. Where this section and the 187 original Neighbor Discovery RFCs are in conflict, the original RFCs 188 take precedence. 190 In IPv6, many of the tasks traditionally done at lower layers such as 191 ARP have been moved to the IP layer. As a consequence, unified 192 mechanisms can be applied across link layers, security mechanisms or 193 other extensions can be adopted more easily, and a clear separation 194 of the roles between the IP and link layer can be achieved. 196 The main functions of IPv6 Neighbor Discovery are as follows: 198 o Neighbor Unreachability Detection (NUD) is used for tracking the 199 reachability of neighbors, both hosts and routers. NUD is defined 200 in Section 7.3 of RFC 2461 [6]. No higher level traffic can 201 proceed if this procedure flushes out neighbour cache entries 202 after (perhaps incorrectly) determining that the peer is not 203 reachable. 205 o Duplicate Address Detection (DAD) is used for preventing address 206 collisions [7]. A node that intends to assign a new address to 207 one of its interfaces runs first the DAD procedure to verify that 208 other nodes are not using the same address. Since the outlined 209 rules forbid the use of an address until it has been found unique, 210 no higher layer traffic is possible until this procedure has 211 completed. 213 o Address Resolution is similar to IPv4 ARP [14]. The Address 214 Resolution function resolves a node's IPv6 address to the 215 corresponding link-layer address for nodes on the link. Address 216 Resolution is defined in Section 7.2 of RFC 2461 [6] and it is 217 used for hosts and routers alike. Again, no higher level traffic 218 can proceed until the sender knows the hardware address of the 219 destination node or the next hop router. Note that like its 220 predecessor in ARP, IPv6 Neighbor Discovery does not check the 221 source link layer address against the information learned through 222 Address Resolution. This allows for an easier addition of network 223 elements such as bridges and proxies, and eases the stack 224 implementation requirements as less information needs to be passed 225 from layer to another layer. 227 o Address Autoconfiguration is used for automatically assigning 228 addresses to a host [7]. This allows hosts to operate without 229 configuration related to IP connectivity. The Address 230 Autoconfiguration mechanism is stateless, where the hosts use 231 prefix information delivered to them during Router Discovery to 232 create addresses, and then test these addresses for uniqueness 233 using the DAD procedure. A stateful mechanism, DHCPv6 [19], 234 provides additional Autoconfiguration features. Router and Prefix 235 Discovery and Duplicate Address Detection have an effect to the 236 Address Autoconfiguration tasks. 238 o The Redirect function is used for automatically redirecting hosts 239 to an alternate router. Redirect is specified in Section 8 of RFC 240 2461 [6]. It is similar to the ICMPv4 Redirect message [13]. 242 o The Router Discovery function allows IPv6 hosts to discover the 243 local routers on an attached link. Router Discovery is described 244 in Section 6 of RFC 2461 [6]. The main purpose of Router 245 Discovery is to find neighboring routers that are willing to 246 forward packets on the behalf of hosts. Prefix discovery involves 247 determining which destinations are directly on a link; this 248 information is necessary in order to know whether a packet should 249 be sent to a router or to the destination node directly. 250 Typically, address autoconfiguration and other tasks can't proceed 251 until suitable routers and prefixes have been found. 253 The Neighbor Discovery messages follow the ICMPv6 message format and 254 ICMPv6 types from 133 to 137. The IPv6 Next Header value for ICMPv6 255 is 58. The actual Neighbor Discovery message includes an ND message 256 header consisting of ICMPv6 header and ND message-specific data, and 257 zero or more ND options: 259 <------------ND Message-----------------> 260 *-------------------------------------------------------------* 261 | IPv6 Header | ICMPv6 | ND message- | ND Message | 262 | Next Header = 58 | Header | specific | Options | 263 | (ICMPv6) | | data | | 264 *-------------------------------------------------------------* 265 <--ND Message header---> 267 The ND message options are formatted in the Type-Length-Value format. 269 All IPv6 ND protocol functions are realized using the following 270 messages: 272 ICMPv6 Type Message 273 ------------------------------------ 274 133 Router Solicitation (RS) 275 134 Router Advertisement (RA) 276 135 Neighbor Solicitation (NS) 277 136 Neighbor Advertisement (NA) 278 137 Redirect 280 The functions of the ND protocol are realized using these messages as 281 follows: 283 o Router Discovery uses the RS and RA messages. 285 o Duplicate Address Detection uses the NS and NA messages. 287 o Address Autoconfiguration uses the NS, NA, RS, and RA messages. 289 o Address Resolution uses the NS and NA messages. 291 o Neighbor Unreachability Detection uses the NS and NA messages. 293 o Redirect uses the Redirect message. 295 The addresses used in these messages are as follows: 297 o Neighbor Solicitation: The destination address is either the 298 solicited node multicast address, unicast address, or an anycast 299 address. 301 o Neighbour Advertisement: The destination address is either a 302 unicast address or the All Nodes multicast address [1]. 304 o Router Solicitation: The destination address is typically the All 305 Routers multicast address [1]. 307 o Router Advertisement: The destination address can be either a 308 unicast or the All Nodes multicast address [1]. Like the 309 solicitation message, the advertisement is also local to the link 310 only. 312 o Redirect: This message is always sent from the router's link-local 313 address to the source address of the packet that triggered the 314 Redirect. Hosts verify that the IP source address of the Redirect 315 is the same as the current first-hop router for the specified ICMP 316 Destination Address. Rules in [1] dictate that unspecified, 317 anycast, or multicast addresses may not be used as source 318 addresses. Therefore, the destination address will always be a 319 unicast address. 321 4. Secure Neighbor Discovery Overview 323 IPsec AH is used in to protect Neighbor and Router Discovery 324 messages. This specification introduces the use of a new transform 325 for IPsec AH, extensions to the current IPsec selectors, an 326 authorization delegation discovery process, and an address ownership 327 proof mechanism. 329 The components of the solution specified in this document are as 330 follows: 332 o IPsec AH is used to protect all advertisement messages relating to 333 Neighbor and Router discovery. Solicitation messages are not 334 protected, as they do not carry any information. 336 o IPsec security policy database and security association database 337 are configured to require the protection as indicated above. Note 338 that such configuration may take place manually or the operating 339 system may perform it automatically upon enabling Secure Neighbor 340 Discovery. 342 This specification introduces extensions to the required selectors 343 used in security policy database entries. This is necessary in 344 order to enable the protection of specific ICMP message types, 345 while leaving other messages unprotected. 347 o A new transform for IPsec AH allows public keys to be used on a 348 security association directly without the involvement of a key 349 management protocol. Symmetric session keys are not used, public 350 key signatures are used instead. The trust to the public key is 351 established either with the authorization delegation process or 352 the address ownership proof mechanism, depending on configuration 353 and the type of the message protected. 355 The new transform uses also a fixed, standardized SPI (Security 356 Parameters Index) number. This necessary again in order to avoid 357 the involvement of a key management protocol. 359 Given that Neighbor and Router Discovery messages are in some 360 cases sent to multicast addresses, the new transform uses a 361 timestamp mechanism as a replay mechanism instead of sequence 362 numbers. 364 o Trusted roots are expected to certify the authority of routers. A 365 host and a router must have at least one common trusted root 366 before the host can accept adopt the router as its default router. 367 Delegation Chain Solicitation and Advertisement messages are used 368 to discover a certificate chain to the trusted root without 369 requiring the actual Router Discovery messages to carry lengthy 370 certificate chains. 372 o Cryptographically Generated Addresses are used to assure that the 373 sender of a Neighbor or Router Advertisement is the owner of an 374 the claimed address. A public-private key pair needs to be 375 generated by all nodes before they can claim an address. 377 5. Cryptographically Generated Addresses 379 Cryptographically Generated Addresses (CGAs) [22][23][20][25] are a 380 technique whereby a node's IPv6 address can be unalterably tied to 381 the node's public key. Conceptually, CGAs allow a recipient of a 382 message to determine whether the sender is authorized to use the 383 public key and address claimed to be associated with the packet. 384 Typically, this requires the sender to use the hash of the node's 385 public key as the interface identifier in the bottom 64 bits of the 386 IPv6 address. 388 Authorization through CGAs and certificates are related, but separate 389 mechanisms. It is separate in that other techniques of authorization 390 (i.e. digital certificates) can be used instead of CGAs to achieve 391 the same effect. However, certificates require a means to create and 392 distribute them, thereby imposing more overhead than CGA. It is 393 related in that a digital signature is required in addition to the 394 CGA address and the signature must cover the address, in order that 395 the recipient can have the confidence that the address was not 396 altered in transit. Furthermore, to properly authorize the address 397 use, the issuer of the certificate must be considered as a valid 398 source of authority for certifying address usage, and must be capable 399 of making statements about an individual's use of IP addresses. 400 Theoretically, proper use of certificates provides more assurance 401 about address usage authorization than CGA. However, it is often 402 practically difficult to arrange the certificate authorities so that 403 they can control which IP addresses can be used by which parties. 404 The authorization provide by CGA is computational in nature, deriving 405 its strength from the computational difficulty of creating duplicate 406 CGA addresses. It does not require any configuration tasks, and it 407 does not impose any requirements on the infrastructure. 408 Respectively, certificate based authorization is administrative in 409 nature, and does not impose restrictions to the structure of the 410 addresses. 412 CGAs are particularly useful for Neighbor Discovery because they 413 provide a low overhead way for the sender of a Neighbor Advertisement 414 to indicate their authorization for claiming the address. The 415 recipient of a Neighbor Advertisement with a CGA Address, a public 416 key, and a digital signature in the header can have confidence that: 418 o The packet was not modified in transit (due to the signature), 420 o The sender of the packet has a right to claim possession of the 421 address (due to the authenticated CGA address). 423 In this section, we describe how a sender generates CGA addresses and 424 digital signatures for the AH header in Neighbor Advertisement 425 packets, and how the receiver of such a packet verifies it. The 426 description of CGA use for IPv6 Neighbor Discovery follows closely 427 that described in [24]. 429 5.1 Address Format 431 The basic idea behind CGA addresses is to use some function of the 432 host's public key as input to a hash function to generate the 433 interface identifier (bottom 64 bits) in the IPv6 address. 434 Variations on this basic theme provide additional security against 435 denial of service attacks and futureproofing against increases in 436 attacker processing power due to Moore's Law. For purposes of secure 437 Neighbor Discovery, CGA addresses are modified EUI-64 addresses [1] 438 in which the "universal/local" bit (bit 6) is set to 1 (indicating 439 global scope) and the "individual/group" bit (bit 7) is set to 1 440 (indicating the CGA group). Correct handling of these bits 441 effectively reduces the size of the interface identifier to 62 bits. 443 5.2 Basic Interface Identifier Generation 445 The basic hash algorithm for CGA addresses generates a 160 bit hash 446 by concatenating the node's public key, a nonce, and routing prefix 447 for the address in question. This result is then hashed to obtain 448 the actual interface identifier. The input hash is generated as 449 follows: 451 Equation (1). 452 H(N) = Hash-160(public_key | 453 nonce | 454 routing_prefix) 455 H(i) = Hash-160(H(i+1)) 457 where Hash-160 is the 160 bits obtained from applying the SHA-1 458 secure hashing algorithm [12], public_key is the node's public key in 459 the format defined in Section 7.1.2, and nonce is a random octet 460 string of 8 or more bytes. The selection N is a local matter, but it 461 MUST be at least 3. N is used as a defense mechanism against 462 denial-of-service attacks. 464 The routing_prefix is the routing prefix for the address in question. 465 Note that this value is used regardless of whether the scope of the 466 address to be generated is link-local, site-local, or global. If the 467 scope is not global, it is possible that different networks will be 468 using the same routing prefix, such as the FE80::/10 prefix for 469 link-local addresses. This is allowed, as the addresses are not used 470 in the same network. In any case, other components in Equation (1) 471 typically provide sufficient randomness to avoid collisions and 472 Duplicate Address Detection would avoid possibly remaining address 473 collisions. 475 The host generates a series of these hash values. The actual 476 interface identifier is then generated by performing taking the 477 rightmost 60 bits of the SHA-1 hash applied to the input value: 479 Equation (2). 480 interface_id = Hash-60(H(i)) 482 where Hash-60 is the rightmost 60 bits obtained from the application 483 of the SHA-1 algorithm, i starts at 0 and increases depending on 484 whether additional rounds of duplicate address detection must be 485 negotiated (see Section 5.4). 487 The routing_prefix term is included in the above in order to 488 introduce a strong binding between the prefixes and interface 489 identifiers, and to add some randomness in order to defeat brute 490 force and birthday attacks. If it is not included, an attacker can 491 generate a lookup table of key pairs for each of the possible 2**60 492 values of the interface identifier and use them to disrupt duplicate 493 address detection. Note, however, that including these in the 494 address requires the host to perform duplicate address detection for 495 each address configured on the interface, not just for the link local 496 address, as is allowed by RFC 2462. 498 5.3 Address Generation 500 Equation (2) in Section 4.1.1 only takes 60 bits of the SHA-1 hash, 501 although 62 bits are theoretically available after the "u" and "g" 502 bits are omitted. This is because the right most 2 bits of the 503 interface identifier are reserved for a security parameter. The 504 security parameter can have a value of 0 through 3, and is a way of 505 future-proofing the CGA address against increases in processing power 506 in attackers due to Moore's Law, since 62 bits is on the borderline 507 of what is today computationally difficult to attack. Conceptually, 508 the security parameter is a way to increase the computational effort 509 of both generating and attacking an address. While this has the side 510 effect of increasing the effort for the client, the client presumably 511 only has to generate the address once, while an attacker may have to 512 generate the address multiple times. 514 The algorithm for generating the actual address is as follows, given 515 the security parameter has value Sec: 517 1. Generate a key pair. 519 2. Generate a nonce value. 521 3. Generate a table of hash values according to Equation (1). 523 4. Generate a target identifier according to Equation (2), but 524 taking 20 x Sec + 60 bits instead of just 60 bits. 526 5. Compare the leftmost 20 x Sec to zero. If not zero, go back to 527 Step 2. 529 6. Set the universal and group bits to 1 and the rightmost two bits 530 to Sec. 532 7. Use the result of Step 6 as the interface identifier for the 533 address. 535 If the security parameter is zero, this algorithm is the basic CGA 536 algorithm. 538 If the security parameter is greater than zero, the algorithm is not 539 guaranteed to terminate after a certain number of iterations (though 540 it will ultimately terminate). For security parameter values 1, 2, 541 and 3, the average number of iterations required to produce a 542 matching hash output are 2**19, 2**39, and 2**59, i.e. 2**(20 x Sec 543 -1) [24]. The additional amount of computational effort involved in 544 increasing the security parameter allows the SEND algorithm to scale 545 as Moore's law increases processing power. 547 5.4 Duplicate Address Detection 549 During Duplicate Address Detection, a node may encounter a clash with 550 another node on the link. One possible denial of service attack 551 occurs when the attacker deliberately provokes an address clash, in 552 order to prevent the victim from claiming the address. RFC 2462 [7] 553 inadvertently facilitates this attack, by requiring nodes to 554 terminate Duplicate Address Detection when a clash is detected. 556 For Secure Neighbor Discovery, a node performs Duplicate Address 557 Detection a maximum of 3 times. If an address clash is detected, the 558 node restarts interface identifier generation at Step 2 of the 559 algorithm described in Section 4.1.2, by selecting a different hash 560 input for target identifier generation. If clashes are detected 561 after three tries, the node is probably under attack, so it should 562 shut down and report the situation to an administrator. 564 6. Authorization Delegation Discovery 566 Several protocols, including IPv6 Neighbor Discovery, allow a node to 567 automatically configure itself based on information it learns shortly 568 after connecting to a new link. It is particularly easy for "rogue" 569 routers to be configured, and it is particularly difficult for a 570 network node to distinguish between valid and invalid sources of 571 information when the node needs this information before to 572 communicate off-link. 574 Since the newly-connected node likely can't communicate off-link, it 575 can't be responsible for searching information to help validate the 576 router; however, given a chain of appropriately signed certificates, 577 it can check someone else's search results and conclude that a 578 particular message comes from an authorized source. Similarly, the 579 router, which is already connected to the network, can if necessary 580 communicate off-link and construct the certificate chain. 582 The Secure Neighbor Discovery protocol introduces two new ICMPv6 583 messages that can be used between hosts and routers to allow the 584 client to learn the certificate chain with the assistance of the 585 router. Where hosts have certificates from a trusted root, these 586 messages may also optionally be used between hosts to acquire the 587 peer's certificate chain. 589 The Delegation Chain Solicitation message is sent by hosts when they 590 wish to request the certificate chain between a router and the one of 591 the hosts' trusted roots. The Delegation Chain Advertisement message 592 is sent as an answer to this message, or periodically to the All 593 Nodes multicast address. Due to the size of certificates and 594 potentially long certificate chains, the advertisement message may be 595 large. The messages have been made separate from the rest of 596 Neighbor Discovery in order to reduce their effect on the size of 597 other messages. Long certificate chains may also be broken to 598 multiple messages. 600 The Authorization Delegation Discovery process does not exclude other 601 forms of discovering the certificate chains. For instance, during 602 fast movements mobile nodes may learn information - including the 603 chains - of the next router from the previous router. 605 6.1 Delegation Chain Solicitation Message Format 607 Hosts send Delegation Chain Solicitations in order to prompt routers 608 to generate Delegation Chain Advertisements quickly. 610 0 1 2 3 611 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Type | Code | Checksum | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Identifier | Reserved | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Options ... 618 +-+-+-+-+-+-+-+-+-+-+-+- 620 IP Fields: 622 Source Address 624 An IP address assigned to the sending interface, or the 625 unspecified address if no address is assigned to the sending 626 interface. 628 Destination Address 630 Typically the all-routers multicast address, or the address of 631 the hosts' default router. 633 Hop Limit 635 255 637 ICMP Fields: 639 Type 641 TBD for Delegation Chain Solicitation. 643 Code 645 0 647 Checksum 649 The ICMP checksum [8].. 651 Identifier 653 This 16 bit unsigned integer field acts as an identifier to 654 help match advertisements to solicitations. The Identifier 655 field MUST NOT be zero. 657 Reserved 659 This field is unused. It MUST be initialized to zero by the 660 sender and MUST be ignored by the receiver. 662 Valid Options: 664 Trusted Root 666 One or more trusted roots that the client is willing to accept. 668 Future versions of this protocol may define new option types. 669 Receivers MUST silently ignore any options they do not recognize 670 and continue processing the message. 672 6.2 Delegation Chain Advertisement Message Format 674 Routers send out Delegation Chain Advertisement messages 675 periodically, or in response to a Delegation Chain Solicitation. 677 0 1 2 3 678 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Type | Code | Checksum | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Identifier |M| Component | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Reserved | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Options ... 687 +-+-+-+-+-+-+-+-+-+-+-+- 689 IP Fields: 691 Source Address 693 MUST be the link-local address assigned to the interface from 694 which this message is sent. 696 Destination Address 698 Typically the Source Address of a host invoking Delegation 699 Chain Solicitation or the all-nodes multicast address. 701 Hop Limit 703 255 705 ICMP Fields: 707 Type 709 TBD for Delegation Chain 710 Advertisement. 712 Code 714 0 716 Checksum 718 The ICMP checksum [8].. 720 Identifier 722 This 16 bit unsigned integer field acts as an identifier to 723 help match advertisements to solicitations. The Identifier 724 field MUST be zero for unsolicited advertisements and MUST NOT 725 be zero for solicited advertisements. 727 M 729 A single advertisement MUST be broken into separately sent 730 components if there is more than one Certificate option, in 731 order to avoid excessive fragmentation at the IP layer. Unlike 732 the fragmentation at the IP layer, individual components of an 733 advertisement may be stored and taken in use before all the 734 components have arrived; this makes them slightly more reliable 735 and less prone to Denial-of-Service attacks. The 'M' flag, 736 when set, indicates that there are more components coming in 737 this advertisement. 739 Component 741 This is a 15 bit unsigned integer field. The first message in 742 a multi-component advertisement has the Component field set to 743 0, the second set to 1, and so on. 745 Reserved 747 This field is unused. It MUST be initialized to zero by the 748 sender and MUST be ignored by the receiver. 750 Valid Options: 752 Certificate 754 Zero or one certificates are provided in Certificate options, 755 to establish a certificate chain to a trusted root. 757 Trusted Root 759 Zero or more Trusted Root options may be included to help 760 receivers decide which advertisements are useful for them. If 761 present, these options MUST appear in the first component of a 762 multi-component advertisement. 764 Future versions of this protocol may define new option types. 765 Receivers MUST silently ignore any options they do not recognize 766 and continue processing the message. 768 6.3 Trusted Root Option 770 The format of the Trusted Root option is as described in the 771 following: 773 0 1 2 3 774 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Type | Length | Name Type | Name Length | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Name ... 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 Where the fields are as follows: 783 Type 785 TBD for Trusted Root. 787 Length 789 The length of the option (including the Type, Length, Name Type, 790 Name Length, and Name fields) in units of 8 octets. 792 Name Type 794 The type of the name included in the Name field. This 795 specification defines only one legal value for this field: 797 1 FQDN 799 Name Length 801 The length of the Name field, in bytes. Octets beyond this length 802 but within the length specified by the Length field are padding 803 and MUST be set to zero by senders and ignored by receivers. 805 Name 807 When the Name Type field is set to 1, the Name field contains the 808 Fully Qualified Domain Name of the trusted root, for example 809 "trustroot.operator.com". 811 6.4 Certificate Option 813 The format of the certificate option is as described in the 814 following: 816 0 1 2 3 817 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Type | Length | Cert Type | Pad Length | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Certificate ... 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 Where the fields are as follows: 826 Type 828 TBD for Certificate. 830 Length 832 The length of the option (including the Type, Length, Cert Type, 833 Pad Length, and Certificate fields) in units of 8 octets. 835 Cert Type 837 The type of the certificate included in the Name field. This 838 specification defines only one legal value for this field: 840 1 X.509 Certificate 842 Pad Length 844 The amount of padding beyond the end of the Certificate field but 845 within the length specified by the Length field. Padding MUST be 846 set to zero by senders and ignored by receivers. 848 Certificate 850 When the Cert Type field is set to 1, the Certificate field 851 contains an X.509 certificate [10]. 853 6.5 Processing Rules for Routers 855 Routers SHOULD possess a keypair and certificate from at least one 856 certificate authority. 858 A router MUST silently discard any received Delegation Chain 859 Solicitation messages that do not satisfy all of the following 860 validity checks: 862 o The IP Hop Limit field has a value of 255, i.e., the packet could 863 not possibly have been forwarded by a router. 865 o If the message includes an IP Authentication Header, the message 866 authenticates correctly. 868 o ICMP Checksum is valid. 870 o ICMP Code is 0. 872 o ICMP length (derived from the IP length) is 8 or more octets. 874 o Identifier field is non-zero. 876 o All included options have a length that is greater than zero. 878 The contents of the Reserved field, and of any unrecognized options, 879 MUST be ignored. Future, backward-compatible changes to the protocol 880 may specify the contents of the Reserved field or add new options; 881 backward-incompatible changes may use different Code values. The 882 contents of any defined options that are not specified to be used 883 with Router Solicitation messages MUST be ignored and the packet 884 processed as normal. The only defined option that may appear is the 885 Trusted Root option. A solicitation that passes the validity checks 886 is called a "valid solicitation". 888 Routers MAY send unsolicited Delegation Chain Advertisements for 889 their trusted root. When such advertisements are sent, their timing 890 MUST follow the rules given for Router Advertisements in RFC 2461 891 [6]. The only defined option that may appear is the Certificate 892 option. At least one such option MUST be present. Router SHOULD 893 also include at least one Trusted Root option to indicate the trusted 894 root on which the Certificate is based. 896 In addition to sending periodic, unsolicited advertisements, a router 897 sends advertisements in response to valid solicitations received on 898 an advertising interface. A router MAY choose to unicast the 899 response directly to the soliciting host's address (if the 900 solicitation's source address is not the unspecified address), but 901 the usual case is to multicast the response to the all-nodes group. 903 In a solicited advertisement, the router SHOULD include suitable 904 Certificate options so that a delegation chain to the solicited root 905 can be established. The root is identified by the FQDN from the 906 Trusted Root option being equal to an FQDN in the AltSubjectName 907 field of the root's certificate. The router SHOULD include the 908 Trusted Root option(s) in the advertisement for which the delegation 909 chain was found. 911 If the router is unable to find a chain to the requested root, it 912 SHOULD send an advertisement without any certificates. In this case 913 the router SHOULD include the Trusted Root options which were 914 solicited. 916 Rate limitation of Delegation Chain Advertisements is performed as 917 specified for Router Advertisements in RFC 2461 [6]. 919 6.6 Processing Rules for Hosts 921 Hosts SHOULD possess the certificate of at least one certificate 922 authority, and MAY possess their own keypair and certificate from 923 this authority. 925 A host MUST silently discard any received Router Advertisement 926 messages that do not satisfy all of the following validity checks: 928 o IP Source Address is a link-local address. Routers must use their 929 link-local address as the source for Router Advertisement and 930 Redirect messages so that hosts can uniquely identify routers. 932 o The IP Hop Limit field has a value of 255, i.e., the packet could 933 not possibly have been forwarded by a router. 935 o If the message includes an IP Authentication Header, the message 936 authenticates correctly. 938 o ICMP Checksum is valid. 940 o ICMP Code is 0. 942 o ICMP length (derived from the IP length) is 16 or more octets. 944 o All included options have a length that is greater than zero. 946 The contents of the Reserved field, and of any unrecognized options, 947 MUST be ignored. Future, backward-compatible changes to the protocol 948 may specify the contents of the Reserved field or add new options; 949 backward-incompatible changes may use different Code values. The 950 contents of any defined options that are not specified to be used 951 with Router Advertisement messages MUST be ignored and the packet 952 processed as normal. The only defined option that may appear is the 953 Certificate option. An advertisement that passes the validity checks 954 is called a "valid advertisement". 956 Hosts SHOULD store all certificates retrieved in Delegation Chain 957 Advertisements for use in subsequent verification of Router (and 958 optionally Neighbor) Advertisements. Note that it may be useful to 959 cache this information and implied verification results for use over 960 multiple attachments to the network. 962 When an interface becomes enabled, a host may be unwilling to wait 963 for the next unsolicited Delegation Chain Advertisement. To obtain 964 such advertisements quickly, a host SHOULD transmit up to 965 MAX_RTR_SOLICITATIONS Delegation Chain Solicitation messages each 966 separated by at least RTR_SOLICITATION_INTERVAL seconds. Delegation 967 Chain Solicitations may be sent after any of the following events: 969 o The interface is initialized at system startup time. 971 o The interface is reinitialized after a temporary interface failure 972 or after being temporarily disabled by system management. 974 o The system changes from being a router to being a host, by having 975 its IP forwarding capability turned off by system management. 977 o The host attaches to a link for the first time. 979 o A movement has been indicated by lower layers or has been inferred 980 from changed information in a Router Advertisement. 982 o The host re-attaches to a link after being detached for some time. 984 o A Router Advertisement has been received with a public key that is 985 not stored in the hosts' cache of certificates, or there is no 986 authorization delegation chain to the host's trusted root. 988 Delegation Chain Solicitations MUST NOT be sent if a valid 989 certificate chain exists in the host's cache from the desired router 990 (or host) to the host's trusted root. 992 A host MUST send Delegation Chain Solicitations either to the 993 All-Routers multicast address, if it hasn't selected a default router 994 yet, or to the default router's IP address if it has already been 995 selected. If two hosts communicate with the solicitations and 996 advertisements, these MUST be unicast to the hosts's address. 998 Delegation Chain Solicitations SHOULD be rate limited and timed 999 similarly with Router Solicitations, as specified in RFC 2461 [6]. 1001 When processing a possible advertisement sent as a response to a 1002 solicitation, the host MAY prefer to process first those 1003 advertisements with the same Identifier field value as in the 1004 solicitation. This make Denial-of-Service attacks against the 1005 mechanism harder (see Section 12.2). 1007 7. IPsec Extensions 1009 In order to use IPsec in securing Neighbor and Router Discovery some 1010 extensions have been specified in this document. These include a new 1011 transform suitable for the use of public keys and/or CGAs, a 1012 timestamp mechanism suitable for replay protection in a multicast 1013 environment, and some extensions to security association and security 1014 policy databases. 1016 7.1 The AH_RSA_Sig Transform 1018 The AH_RSA_Sig transform specifies how AH can be used without a 1019 symmetric key. This transform introduces the use of a new reserved 1020 SPI number and a new format for the Authentication Data field in AH. 1022 AH_RSA_Sig MUST NOT be negotiated in IKE. For consistency it has an 1023 IPsec DOI [4] Transform ID TBD , however. 1025 7.1.1 Reserved SPI Number 1027 The AH_RSA_Sig MUST be only be used with the reserved SPI number TBD 1028 . 1030 7.1.2 Authentication Data Format 1032 The format of the Authentication Data field in AH depends on the 1033 chosen transform. For the AH_RSA_Sig transform, the format is as 1034 follows: 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | PK_Len | Nonce_Len | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | | 1040 + Timestamp + 1041 | | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | | 1044 . . 1045 . Public key . 1046 . . 1047 | | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | | 1050 . . 1051 . Nonce (optional) . 1052 . . 1053 | | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | | 1056 . . 1057 . Digital Signature (remaining bytes) . 1058 . . 1059 | | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 The meaning of the fields is described below: 1064 PK_Len 1066 This 16 bit unsigned integer field contains the length of the 1067 Public Key field in bytes. 1069 Nonce_Len 1071 This 16 bit unsigned integer field contains the length of the 1072 Nonce field in bytes. The length is set to zero if that field is 1073 not present. 1075 Timestamp 1077 This 64 bit unsigned integer field contains a timestamp used for 1078 replay protection (the Sequence Number field in AH is not used for 1079 AH_RSA_Sig). The use of this field is discussed in Section 7.1.4. 1081 Public key 1083 This variable length field contains the public key of the sender 1084 in X.509 format [10]. 1086 Nonce 1088 This variable length field, if present, contains the nonce used in 1089 the construction of the CGA address. 1091 Digital Signatures 1093 This variable length field, if present, contains the signature 1094 made using the sender's private key, over the the whole packet as 1095 defined by the usual AH rules [3]. The signature is made using 1096 the RSA algorithm and MUST be encoded as private key encryption in 1097 PKCS #1 format [11]. 1099 7.1.3 AH_RSA_Sig Security Associations 1101 Security associations that specify the use of AH_RSA_Sig transform 1102 MUST record the following additional configuration information: 1104 o A flag that indicates whether or not authorization delegation to a 1105 trusted root is used. 1107 o A flag that indicates whether or not CGA addresses are used. 1109 Incoming security associations MUST also record the following 1110 additional information: 1112 o The public key of the trusted root, if authorization delegation is 1113 in use. 1115 o The minimum acceptable key length for peer public keys (and any 1116 intermediaries between the trusted root and the peer). The 1117 default SHOULD be 768 bits. Implementations MAY also set an upper 1118 limit in order to limit the amount of computation they need to 1119 perform when verifying packets that use these security 1120 associations. 1122 o The minimum acceptable Sec value, if CGA verification is required. 1124 Outgoing security associations MUST also record the following 1125 additional information: 1127 o A public-private keypair. If authorization delegation is in use, 1128 there must exist a delegation chain from a trusted root to this 1129 keypair. 1131 o Optionally any information required to construct CGA signatures, 1132 including the used Sec value and nonce, and the resulting CGA 1133 address. 1135 7.1.4 Replay Protection 1137 For AH_RSA_Sig, the Sequence Number field in AH MUST be set to zero 1138 by the sender and ignored by receivers. 1140 If anti-replay has been enabled in the security association, senders 1141 MUST set the Timestamp field to the current time. The format is 64 1142 bits, and the contents are the number of milliseconds since January 1143 1, 1970 00:00 UTC. 1145 If anti-replay has been enabled, receivers MUST be configured with an 1146 allowed Delta value and maintain a cache of messages received within 1147 this time period from each specific source address. Receivers MUST 1148 then check the Timestamp field as follows: 1150 o A packet with a Timestamp field value beyond the current time plus 1151 or minus the allowed Delta value MUST be silently discarded. 1153 o A packet accepted according to the above rule MUST be checked for 1154 uniqueness within the cache of received messages from the given 1155 source address. A packet that has already been seen from the same 1156 source with the same Timestamp field value MUST be silently 1157 discard. 1159 o A packet that passes both of the above tests MUST be registered in 1160 the cache for the given source address. 1162 o If the cache becomes full, the receiver SHOULD temporarily reduce 1163 the Delta value for that source address so that all messages 1164 within that value can still be stored. 1166 7.1.5 Processing Rules for Senders 1168 A node sending a packet using the AH_RSA_Sig transform MUST construct 1169 the packet as follows: 1171 o The Next Header, Payload Len, and Reserved fields are set as 1172 described in RFC 2402. 1174 o The Security Parameters Index is set to the value specified in 1175 Section 7.1.1. 1177 o The Sequence Number field is set to 0. 1179 o The PK_Len field in Authentication Data is set to the length of 1180 the public key used for signing this packet. This public key is 1181 stored in the security association. The key itself is put to the 1182 Public key field. 1184 o If the security association has specified the use of the CGA 1185 method, the Nonce_len field is set to the length of the nonce used 1186 in the construction of the CGA address. In this case the nonce is 1187 copied to the Nonce field. Otherwise, the Nonce_Len field is set 1188 to zero and the Nonce field is omitted. 1190 o The Timestamp field is set as described in Section 7.1.4. 1192 o The packet, in the form defined for AH's coverage, is signed using 1193 the private key in the security association, and the resulting 1194 PCKS #1 signature is put to the Digital Signature field. 1196 o Additionally, if the use of CGA has been specified for the 1197 security association we require that the source address of the 1198 packet has been constructed as specified in Section 5. A sending 1199 node uses as inputs the sender's public key, nonce, the subnet 1200 prefix from the Target Address, and the Target Link Layer Address. 1201 The Target Address (including the subnet prefix) is put to the 1202 Source Address field in the IPv6 header, and the public key and 1203 the nonce are put to the Authentication Data field in the AH 1204 header. 1206 7.1.6 Processing Rules for Receivers 1208 A packet received on a security association employing AH_RSA_Sig 1209 transform MUST be checked as follows: 1211 o Next Header and Payload Len fields are valid as specified in RFC 1212 2402. 1214 o The SPI field is equal to the value defined in Section 7.1.1. 1216 o The sum of the PK_Len, Nonce_Len, and LLA_Len fields does not 1217 exceed the length of the Authentication Data field. 1219 o The Nonce_Len field is non-zero if the use of CGA has been 1220 specified in the security association. 1222 o The Timestamp field is verified as described in Section 7.1.4. 1224 o If the use of CGA has been specified in the security association, 1225 we additionally require that A node receiving an Neighbor or 1226 Router Advertisement message with CGA protection first checks the 1227 CGA address in the Target Address field by generating the address 1228 using the algorithm described in Section 5.3. The inputs for the 1229 algorithm are the sender's public key and nonce, included in the 1230 AH packet as described in Section 7.1.2, the subnet prefix from 1231 the Target Address, the Target Link Layer Address, which MUST be 1232 included in a Target Link Layer Address option, and the security 1233 parameter from the rightmost two bits of the Target Address. If 1234 the interface identifier checks, the recipient proceeds with the 1235 cryptographically more time consuming check of the AH signature. 1237 Note that a receiver which does not support CGA or has not 1238 specified its use in its security associations can still verify 1239 packets using trusted roots, even if CGA had been used on a 1240 packet. The CGA property of the address is simply left untested. 1242 o The Public key and Digital Signature fields can be correctly 1243 decoded, and the the Digital Signature verifies as specified in 1244 the previous section. 1246 o If the use of a trusted root has been configured for the security 1247 association, a valid authorization delegation chain is known 1248 between the receiver's trusted root and the sender's public key. 1250 Note that the receiver may verify just the CGA property of a 1251 packet, even if the sender has used a trusted root as well. 1253 Packets that do not pass all the above tests MUST be silently 1254 discarded. 1256 7.2 Other IPsec Extensions 1258 7.2.1 Destination Agnostic Security Associations 1260 In order to allow the same security association to be used when the 1261 the node sends packets to different peers using the same addresses, a 1262 change must be provided to the RFC 2401 rules on how security 1263 associations are identified. This change is particularly important, 1264 for instance, when routers use the same keys and security association 1265 to send Router Advertisements for up to number of prefixes x 2^64 1266 hosts on an interface. 1268 The change is mandatory for all nodes that support the AH_RSA_Sig 1269 transform. Security associations that use the SPI value specified in 1270 Section 7.1.1 MUST be identified solely by the SPI and protocol 1271 numbers, not by the destination IP address. 1273 7.2.2 ICMP Type Specific Selectors 1275 In order to allow finer granularity of protection for various ICMPv6 1276 messages, it is necessary to extend the security policy database and 1277 security association selectors with the capability to distinguish 1278 between different messages. 1280 All nodes that support the AH_RSA_Sig transform MUST be capable of 1281 using ICMP and ICMPv6 Type field as a selector. 1283 8. Securing Neighbor Discovery with SEND 1285 This section describes how to use IPsec and the mechanisms from 1286 Section 5, Section 6, Section 7 in order to provide security for 1287 Neighbor Discovery. 1289 8.1 Using IPsec to Secure Neighbor Advertisement Messages 1291 All Neighbor Solicitation messages SHOULD be sent without protection. 1293 All Neighbor Advertisement messages MUST be protected with IPsec, 1294 using the AH_RSA_Sig transform. The protection can be based on CGA 1295 addresses, node certificates and trusted roots, or both as specified 1296 in the security association. 1298 All nodes MUST have the necessary key pairs, and as applicable, 1299 certificates and CGA parameters associated with their relationship to 1300 trusted root or to an address. 1302 Hosts that use stateless address autoconfiguration MUST generate new 1303 CGA addresses as specified in Section 5 for each new 1304 autoconfiguration run. 1306 It is outside the scope of this specification to describe trusted 1307 roots and address autoconfiguration (stateful or stateless) with 1308 dynamically changing addresses works. It is also outside the scope 1309 of this specification to describe how stateful address 1310 autoconfiguration works with the CGA method. 1312 Hosts MAY use Authorization Delegation Discovery to learn the 1313 certificate chain of their default router or peer host. 1315 8.2 Security Policy and SA Database Configuration 1317 This section gives a description for the security policy and security 1318 associations database entries, under which the outbound and inbound 1319 Neighbor Advertisement messages can be protected. 1321 The following table summarizes the inbound security policy data base 1322 along with the inbound security associations: 1324 Policy entries: 1326 *------------------------------------------------------------------* 1327 | Proto: Type | Source | Destination | Treatment | 1328 *------------------------------------------------------------------* 1329 | ICMPv6: NS | * | * | pass | 1330 *------------------------------------------------------------------* 1331 | ICMPv6: NA | * | own | SA = NA_In | 1332 *------------------------------------------------------------------* 1333 | ICMPv6: NA | * | all-nodes MC | SA = NA_In | 1334 *------------------------------------------------------------------* 1336 Security associations: 1338 +------------------------------------------------------------------+ 1339 | Name | Direction | SPI | Proto | Transform | 1340 +------------------------------------------------------------------+ 1341 | NA_In | Inbound | TBD (fixed) | AH | AH_RSA_Sig | 1342 | | | | | CGA = yes/no | 1343 | | | | | root = ... (opt)| 1344 +------------------------------------------------------------------+ 1346 The following table summarizes outbound security policy database: 1348 Policy entries: 1350 *------------------------------------------------------------------* 1351 | Proto: Type | Source | Destination | Treatment | 1352 *------------------------------------------------------------------* 1353 | ICMPv6: NS | * | * | pass | 1354 *------------------------------------------------------------------* 1355 | ICMPv6: NA | own | * | SA = NA_Out | 1356 *------------------------------------------------------------------* 1358 Security associations: 1360 +------------------------------------------------------------------+ 1361 | Name | Direction | SPI | Proto | Transform | 1362 +------------------------------------------------------------------+ 1363 | NA_Out | Outbound | TBD (fixed) | AH | AH_RSA_Sig | 1364 | | | | | key pair = ... | 1365 | | | | | CGA = yes/no | 1366 | | | | | CGA params = ...| 1367 | | | | | root = ... (opt)| 1368 +------------------------------------------------------------------+ 1370 9. Securing Router Discovery with SEND 1372 This section describes how to use IPsec and the mechanisms from 1373 Section 5, Section 6, Section 7 in order to provide security for 1374 Router Discovery. 1376 9.1 Using IPsec to Secure Router Advertisement Messages 1378 All Router Solicitation messages SHOULD be sent without protection. 1380 All Router Advertisement messages MUST be protected with IPsec, using 1381 the AH_RSA_Sig transform. The protection can be based on CGA 1382 addresses, node certificates and trusted roots, or both as specified 1383 in the security association. 1385 All routers MUST have the necessary key pairs, and as applicable, 1386 certificates and CGA parameters associated with their relationship to 1387 trusted root or to an address. All hosts MUST have the certificate 1388 of a trusted root. 1390 Hosts SHOULD use Authorization Delegation Discovery to learn the 1391 certificate chain of their default router or peer host. 1393 9.2 Using IPsec to Secure Redirect Messages 1395 All Redirect messages MUST be protected with IPsec, using the 1396 AH_RSA_Sig transform. The protection can be based on CGA addresses, 1397 node certificates and trusted roots, or both as specified in the 1398 security association. 1400 If only CGA-based security associations are used, hosts MUST follow 1401 the rules defined below when receiving Redirect messages: 1403 1. The Redirect message MUST be protected as discussed above. 1405 2. The receiver MUST verify that the Redirect message comes from an 1406 IP address to which the host may have earlier sent the packet 1407 that the Redirect message now partially returns. That is, the 1408 source address of the Redirect message must be the default router 1409 for traffic sent to the destination of the returned packet. If 1410 this is not the case, the message MUST be silently discarded. 1412 This step prevents a bogus router from sending a Redirect message 1413 when the host is not using the bogus router as a default router. 1415 9.3 Security Policy and SA Database Configuration 1417 This section gives a description for the security policy and security 1418 associations database entries, under which the outbound and inbound 1419 Router Advertisement and Redirect messages can be protected. 1421 The following table summarizes the inbound security policy data base 1422 along with the inbound security associations: 1424 Policy entries: 1426 *------------------------------------------------------------------* 1427 | Proto: Type | Source | Destination | Treatment | 1428 *------------------------------------------------------------------* 1429 | ICMPv6: RS | * | * | pass | 1430 *------------------------------------------------------------------* 1431 | ICMPv6: RA | * | own | SA = RA_In | 1432 *------------------------------------------------------------------* 1433 | ICMPv6: RA | * | all-nodes MC | SA = RA_In | 1434 *------------------------------------------------------------------* 1435 | ICMPv6: REDIRECT | * | own | SA = RE_In | 1436 *------------------------------------------------------------------* 1438 Security associations: 1440 +------------------------------------------------------------------+ 1441 | Name | Direction | SPI | Proto | Transform | 1442 +------------------------------------------------------------------+ 1443 | RA_In | Inbound | TBD (fixed) | AH | AH_RSA_Sig | 1444 | | | | | CGA = yes/no | 1445 | | | | | root = ... (opt)| 1446 +------------------------------------------------------------------+ 1447 | RE_In | Inbound | TBD (fixed) | AH | AH_RSA_Sig | 1448 | | | | | CGA = yes/no | 1449 | | | | | root = ... (opt)| 1450 +------------------------------------------------------------------+ 1452 The following table summarizes outbound security policy database. 1453 The Router Advertisement and Redirect entries are only present in 1454 routers. 1456 Policy entries: 1458 *------------------------------------------------------------------* 1459 | Proto: Type | Source | Destination | Treatment | 1460 *------------------------------------------------------------------* 1461 | ICMPv6: RS | * | * | pass | 1462 *------------------------------------------------------------------* 1463 | ICMPv6: RA | own | * | SA = RA_Out | 1464 *------------------------------------------------------------------* 1465 | ICMPv6: REDIRECT | own | * | SA = RE_Out | 1466 *------------------------------------------------------------------* 1468 Security associations: 1470 +------------------------------------------------------------------+ 1471 | Name | Direction | SPI | Proto | Transform | 1472 +------------------------------------------------------------------+ 1473 | RA_Out | Outbound | TBD (fixed) | AH | AH_RSA_Sig | 1474 | | | | | key pair = ... | 1475 | | | | | CGA = yes/no | 1476 | | | | | CGA params = ...| 1477 | | | | | root = ... (opt)| 1478 +------------------------------------------------------------------+ 1479 | RE_Out | Outbound | TBD (fixed) | AH | AH_RSA_Sig | 1480 | | | | | key pair = ... | 1481 | | | | | CGA = yes/no | 1482 | | | | | CGA params = ...| 1483 | | | | | root = ... (opt)| 1484 +------------------------------------------------------------------+ 1486 10. Operational Considerations 1488 During the transition to secure links or as a policy consideration, 1489 network operators may want to run a particular link with a mixture of 1490 secure and insecure nodes. In such a case, the link is required to 1491 operate as two separate logical links, and packets between a secure 1492 and insecure node always go through the router. 1494 Routers configured for SEND advertise two sets of globally routable 1495 prefixes: one set for SEND nodes and one set for nodes that implement 1496 insecure Neighbor Discovery. The insecure nodes will ignore the 1497 advertisements sent using SEND, as the original Neighbor Discovery 1498 specifications require silently discarding packets if they contain an 1499 AH header that they can not verify. 1501 The following considerations apply to hosts: 1503 o Hosts configured for SEND MUST use SEND for all of their 1504 addresses, including link local addresses. 1506 o Hosts configured for SEND MUST validate all Router Advertisements 1507 with the protocol described in Section 8. Note that this includes 1508 discarding advertisements received without a valid IPsec AH header 1509 and CGA address, thus making insecure prefixes invisible to them. 1511 o Hosts configured for SEND MUST secure and validate all Neighbor 1512 Advertisements with the protocol described in Section 8. Note 1513 that this includes discarding advertisements received without a 1514 valid IPsec AH header and CGA address. 1516 The following considerations apply to routers: 1518 o Routers MUST send two sets of Router Advertisements. The 1519 advertisements containing the secure prefixes MUST be secured with 1520 the protocol described in Section 9. The advertisements 1521 containing the insecure prefixes MUST be sent without security. 1523 o Routers MUST assign different addresses for their secure and 1524 insecure communications, including their link-local addresses. 1525 Secure Router and Neighbor Advertisements MUST use a source 1526 address that satisfies the security properties outlined in Section 1527 9. Unless this address is link-local, it MUST belong to one of 1528 the advertised secure prefixes. Similarly, source addresses for 1529 insecure advertisements MUST belong to one of the advertised 1530 insecure prefixes, unless the address is link-local. 1532 o Routers MUST refrain from sending Redirects to a SEND-secured node 1533 with the Destination Address field set to an address for an 1534 insecure node. Similarly, routers MUST refrain from sending 1535 Redirects to a insecure node with the Destination Address field 1536 set to an address for a SEND-secured node 1538 The above rules require secure nodes to ignore all insecure Neighbor 1539 and Router Discovery messages, and all insecure nodes to ignore all 1540 SEND-secured messages. This implies that the secure and insecure 1541 nodes will not be able to discover each other, or even realize that 1542 the other prefixes are on-link. Thus, these hosts will request the 1543 router to route packets destined to the a host in the other group. 1544 The rules regarding Redirect messages above have been provided to 1545 ensure that the router performs its routing task and does not 1546 instruct the hosts to communicate directly. 1548 One effect of this is that secure hosts can not communicate with 1549 insecure hosts using link-local addresses, and vice versa. 1551 The security policy or security association database entries are 1552 needed for insecure nodes as far as Neighbor Discovery is concerned. 1553 SEND-secured nodes have the usual entries required by SEND. 1555 11. Performance Considerations 1557 The computations related to AH_RSA_Sig transform are substantially 1558 more expensive than those with traditional symmetric transforms. 1559 While computational power is increasing, it appears still impractical 1560 to use asymmetric transforms for a significant amount packets. 1562 In the application for which AH_RSA_Sig has been designed, however, 1563 hosts typically have the need to perform only a few operations as 1564 they enter a link, and a few operations as they find a new on-link 1565 peer to communicate with. 1567 Routers are required to perform a larger amount of operations, 1568 particularly when the frequency of router advertisements is high due 1569 to mobility requirements. Still, the number of operations on a 1570 router is in the order of a few dozen operations per second, some of 1571 which can be precomputed as discussed below. A large number of 1572 router solicitations may cause higher demand for performing 1573 asymmetric operations, although RFC 2461 limits the rate at which 1574 responses to solicitations can be sent. 1576 Signatures related to the use of the AH_RSA_Sig transform MAY be 1577 precomputed for Multicast Neighbor and Router Advertisements. 1578 Typically, solicited advertisements are sent to the unicast address 1579 from which the solicitation was sent. Given that the IPv6 header is 1580 covered by the AH integrity protection, it is typically not possible 1581 to precompute solicited advertisements. 1583 12. Security Considerations 1585 12.1 Achieved Security Properties 1587 The CGA method assures that the received messages are coming from the 1588 owner of the address. However, this method does not eliminate all 1589 security vulnerabilities related to the ND functions. CGA prevents 1590 spoofed answers to DAD queries. An attacker may still be able to 1591 prevent valid responses or requests from reaching the intended 1592 recipient. As a result both participants are forced to believe that 1593 no address collision exists, when there in fact is. 1595 Within Address Resolution and NUD functions CGA can be used to 1596 prevent spoofed responses. However, it is still possible to prevent 1597 the Address Resolution and NUD from completing for a given address. 1598 For the NUD, this means that a node is claimed to be unreachable, 1599 when it really is not. 1601 Hosts can use CGA to show that the Redirect messages come from their 1602 current router. Still, we cannot say anything about the other router 1603 mentioned in the Redirect message. When trusted roots are used to 1604 certify routers, this is, however, not an issue. 1606 Within the Router Discovery functionality the CGA method ensures that 1607 we are communicating with the same router all the time, and prevents 1608 spoofing of the link-layer address of the router. But it does not 1609 help to verify that the router is connected to the Internet or that 1610 it is authorized to advertise a specific route prefix. A proper 1611 verification of these properties will not be possible without 1612 involving a trusted root. 1614 Protection of Router (or Neighbor) Discovery with trusted roots 1615 ensures that the given router (or neighbor) belongs to the set of 1616 trusted entities. It does not provide assurance that the given 1617 router is not spoofing another legitimate router (but see Section 1618 14). 1620 12.2 Attacks against SEND Itself 1622 The CGA addresses have a 60-bit hash. This length is in within the 1623 range of an feasible attack in the future. The following mechanisms 1624 have been built in this draft to counteract such attacks: 1626 The inclusion of the routing prefix prevents precomputation 1627 attacks. 1629 The Sec parameter helps the SEND algorithm to scale as Moore's law 1630 increases processing power. Additional amount of computational 1631 effort is involved in for both attackers and owners of an address; 1632 verifiers of a message still need to spend the same amount of 1633 effort. 1635 Some Denial-of-Service attacks against ND and SEND itself remain. 1636 For instance, an attacker may try to produce a very high number of 1637 packets that a victim host or router has to verify using asymmetric 1638 methods. While safeguards are required to prevent an excessive use 1639 of resources, this can still render the SEND in-operational. 1641 Security associations based on the use of asymmetric cryptography can 1642 be vulnerable to Denial-of-Service attacks, particularly when the 1643 attacker can guess the SPIs and destination addresses used in the 1644 security associations. In SEND this is easy, as both the SPIs and 1645 the addresses (such as all nodes multicast address) are standardized. 1646 Due to the use of multicast, one packet sent by the attacker will be 1647 processed by multiple receivers. 1649 When CGA protection is used, SEND deals with these attacks using the 1650 verification process described Section 7.1.6. In this process a 1651 simple hash verification of the CGA property of the address is 1652 performed first before performing the more expensive signature 1653 verification. 1655 When trusted roots and certificates are used in SEND, the defenses 1656 are not quite as effective. Implementations SHOULD track how much 1657 resources are being devoted to the processing of packets received 1658 with the AH_RSA_Sig transform, and start selectively dropping packets 1659 if too much resources are spent. Implementations MAY also start 1660 first dropping packets that which are not protected with CGA. 1662 The Authorization Delegation Discovery process may also be vulnerable 1663 to Denial-of-Service attacks. An attack may target a router by 1664 request a large number of delegation chains to be discovered for 1665 different roots. Routers SHOULD defend against such attacks by 1666 caching discovered information (including negative responses) and by 1667 limiting the number of different discovery processes they engage in. 1669 Attackers may also target hosts by sending a large number of 1670 unnecessary certificate chains, forcing hosts to spend useless memory 1671 and verification resources for them. Hosts defend against such 1672 attacks by limiting the amount of resources devoted to the 1673 certificate chains and their verification. Hosts SHOULD also 1674 prioritize advertisements sent as a response to their requests over 1675 multicast advertisements. 1677 13. IANA Considerations 1679 This document defines two new ICMP message types, used in 1680 Authorization Delegation Discovery. These messages must be assigned 1681 ICMPv6 type numbers from the informational message range: 1683 o The Delegation Chain Solicitation message, described in Section 1684 6.1. 1686 o The Delegation Chain Advertisement message, described in Section 1687 6.2. 1689 This document defines two new Neighbor Discovery [6] options, which 1690 must be assigned Option Type values within the option numbering space 1691 for Neighbor Discovery messages: 1693 o The Trusted Root option, described in Section 6.3. 1695 o The Certificate option, described in Section 6.4. 1697 This document defines a new reserved SPI number in the Reserved SPI 1698 range 1-255 [3]. 1700 This document defines a new IPSEC AH Transform Identifier for the 1701 IPsec DOI [4]. This identifier represents the AH_RSA_Sig transform 1702 from Section 7.1. 1704 This document defines a new name space for the Name Type field in the 1705 Trusted Root option. Future values of this field can be allocated 1706 using standards action [5]. 1708 Another new name space is allocated for the Cert Type field in the 1709 Certificate option. Future values of this field can be allocated 1710 using standards action [5]. 1712 14. Conclusions and Remaining Work 1714 This draft documents ongoing work. The following areas are still 1715 being studied: 1717 o Protection of solicitations. There are no provisions yet for the 1718 protection of Address Resolution which takes place as a 1719 side-effect of Neighbor Solicitations. Similarly, the effects of 1720 Duplicate Address Detection probes on other nodes currently doing 1721 DAD have not been covered, as they too are carried by 1722 solicitations. 1724 o CGA detailed format and calculation formulas: The CGA formulas 1725 used in this document are from an early approach to the control of 1726 the security level in an environment with a constrained number of 1727 output bits. An advanced version of this approach will be 1728 published soon and appears interesting [21]. 1730 o Transition issues: Security policy and security association 1731 database entry examples are needed before the correctness of the 1732 approach outlined in Section 10 can be estimated. Also, the 1733 ability of hosts to simultaneously use SEND and insecure ND 1734 without a router. The ability of a non-SEND router to participate 1735 on a link with SEND-capable hosts and other routers. 1737 o The security considerations, achieved security properties, and the 1738 treatment of Denial-of-Service attacks on the SEND mechanisms 1739 themselves need further work. 1741 o The formats used to carry trusted root references, certificates, 1742 and public keys may change. 1744 o It is unclear at this time how, and if, router and neighbor 1745 protection based on trusted roots relates to addresses and 1746 prefixes. Is a router only certified to use a particular IP 1747 address, or to provide a particular prefix to the link? 1749 o It is unclear whether MLD [16] protection is needed or not. 1751 Normative References 1753 [1] Hinden, R. and S. Deering, "IP Version 6 Addressing 1754 Architecture", RFC 2373, July 1998. 1756 [2] Kent, S. and R. Atkinson, "Security Architecture for the 1757 Internet Protocol", RFC 2401, November 1998. 1759 [3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1760 November 1998. 1762 [4] Piper, D., "The Internet IP Security Domain of Interpretation 1763 for ISAKMP", RFC 2407, November 1998. 1765 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1766 Considerations Section in RFCs", BCP 26, RFC 2434, October 1767 1998. 1769 [6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 1770 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1772 [7] Thomson, S. and T. Narten, "IPv6 Stateless Address 1773 Autoconfiguration", RFC 2462, December 1998. 1775 [8] Conta, A. and S. Deering, "Internet Control Message Protocol 1776 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1777 Specification", RFC 2463, December 1998. 1779 [9] Narten, T. and R. Draves, "Privacy Extensions for Stateless 1780 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1782 [10] International Organization for Standardization, "The Directory 1783 - Authentication Framework", ISO Standard X.509, 2000. 1785 [11] RSA Laboratories, "RSA Encryption Standard, Version 1.5", PKCS 1786 1, November 1993. 1788 [12] National Institute of Standards and Technology, "Secure Hash 1789 Standard", FIPS PUB 180-1, April 1995, . 1792 Informative References 1794 [13] Postel, J., "Internet Control Message Protocol", STD 5, RFC 1795 792, September 1981. 1797 [14] Plummer, D., "Ethernet Address Resolution Protocol: Or 1798 converting network protocol addresses to 48.bit Ethernet 1799 address for transmission on Ethernet hardware", STD 37, RFC 1800 826, November 1982. 1802 [15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 1803 RFC 2409, November 1998. 1805 [16] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener 1806 Discovery (MLD) for IPv6", RFC 2710, October 1999. 1808 [17] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies", 1809 draft-arkko-icmpv6-ike-effects-01 (work in progress), June 1810 2002. 1812 [18] Arkko, J., "Manual SA Configuration for IPv6 Link Local 1813 Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress), 1814 June 2002. 1816 [19] Droms, R., "Dynamic Host Configuration Protocol for IPv6 1817 (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), 1818 November 2002. 1820 [20] Montenegro, G. and C. Castelluccia, "SUCV Identifiers and 1821 Addresses", draft-montenegro-sucv-03 (work in progress), July 1822 2002. 1824 [21] Aura, T., "Cryptographically Generated Addresses (CGA)", 1825 draft-aura-cga-00.txt (work in progress), February 2003. 1827 [22] O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6", 1828 Computer Communications Review, April 2001. 1830 [23] Nikander, P., "Denial-of-Service, Address Ownership, and Early 1831 Authentication in the IPv6 World", Proceedings of the Cambridge 1832 Security Protocols Workshop, April 2001. 1834 [24] Arkko, J., Aura, T., Kempf, J., Mantyla, V., Nikander, P. and 1835 M. Roe, "Securing IPv6 Neighbor Discovery", Wireless Security 1836 Workshop, September 2002. 1838 [25] Montenegro, G. and C. Castelluccia, "Statistically Unique and 1839 Cryptographically Verifiable (SUCV) Identifiers and Addresses", 1840 NDSS, February 2002. 1842 Authors' Addresses 1844 Jari Arkko 1845 Ericsson 1846 Jorvas 02420 1847 Finland 1849 EMail: jari.arkko@ericsson.com 1851 James Kempf 1852 DoCoMo Communications Labs USA 1853 181 Metro Drive 1854 San Jose, CA 94043 1855 USA 1857 EMail: kempf@docomolabs-usa.com 1859 Bill Sommerfeld 1860 SUN Microsystems 1861 USA 1863 EMail: sommerfeld@east.sun.com 1865 Brian Zill 1866 Microsoft 1867 USA 1869 EMail: bzill@microsoft.com 1871 Appendix A. Contributors 1873 Steven Bellovin was the first to suggest the use of IPsec in this 1874 manner for the protection of Neighbor Discovery. Pekka Nikander and 1875 Vesa-Matti Mantyla were co-authors of an unpublished draft from which 1876 many of the details of this document have been inherited. The 1877 theoretical foundations of protecting Neighbor Discovery were laid 1878 out in a paper [24] where Tuomas Aura, Vesa-Matti Mantyla, Pekka 1879 Nikander, and Mike Roe were co-authors. 1881 Appendix B. Acknowledgements 1883 The authors would like to thank Erik Nordmark and Gabriel Montenegro 1884 for interesting discussions in this problem space. 1886 Appendix C. IPR Considerations 1888 The optional CGA part of SEND uses public keys and hashes to prove 1889 address ownership. Several IPR claims have been made about such 1890 methods. 1892 Intellectual Property Statement 1894 The IETF takes no position regarding the validity or scope of any 1895 intellectual property or other rights that might be claimed to 1896 pertain to the implementation or use of the technology described in 1897 this document or the extent to which any license under such rights 1898 might or might not be available; neither does it represent that it 1899 has made any effort to identify any such rights. Information on the 1900 IETF's procedures with respect to rights in standards-track and 1901 standards-related documentation can be found in BCP-11. Copies of 1902 claims of rights made available for publication and any assurances of 1903 licenses to be made available, or the result of an attempt made to 1904 obtain a general license or permission for the use of such 1905 proprietary rights by implementors or users of this specification can 1906 be obtained from the IETF Secretariat. 1908 The IETF invites any interested party to bring to its attention any 1909 copyrights, patents or patent applications, or other proprietary 1910 rights which may cover technology that may be required to practice 1911 this standard. Please address the information to the IETF Executive 1912 Director. 1914 Full Copyright Statement 1916 Copyright (C) The Internet Society (2003). All Rights Reserved. 1918 This document and translations of it may be copied and furnished to 1919 others, and derivative works that comment on or otherwise explain it 1920 or assist in its implementation may be prepared, copied, published 1921 and distributed, in whole or in part, without restriction of any 1922 kind, provided that the above copyright notice and this paragraph are 1923 included on all such copies and derivative works. However, this 1924 document itself may not be modified in any way, such as by removing 1925 the copyright notice or references to the Internet Society or other 1926 Internet organizations, except as needed for the purpose of 1927 developing Internet standards in which case the procedures for 1928 copyrights defined in the Internet Standards process must be 1929 followed, or as required to translate it into languages other than 1930 English. 1932 The limited permissions granted above are perpetual and will not be 1933 revoked by the Internet Society or its successors or assignees. 1935 This document and the information contained herein is provided on an 1936 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1937 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1938 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1939 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1940 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1942 Acknowledgement 1944 Funding for the RFC Editor function is currently provided by the 1945 Internet Society.