idnits 2.17.1 draft-ietf-send-ndopt-06.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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 (July 17, 2004) is 7222 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: '3' is defined on line 2302, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 2305, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2308, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 2351, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (ref. '3') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '4') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2407 (ref. '5') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2434 (ref. '6') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2461 (ref. '7') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '8') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2463 (ref. '9') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3280 (ref. '10') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3281 (ref. '11') (Obsoleted by RFC 5755) ** Obsolete normative reference: RFC 3490 (ref. '12') (Obsoleted by RFC 5890, RFC 5891) -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '18') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '20') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '21') (Obsoleted by RFC 8415) == Outdated reference: A later version (-02) exists of draft-arkko-manual-icmpv6-sas-01 -- No information found for draft-chakrabarti-ipv6-addrselect - is the name correct? Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Secure Neighbor Discovery Working J. Arkko (Editor) 2 Group Ericsson 3 Internet-Draft J. Kempf 4 Expires: January 15, 2005 DoCoMo Communications Labs USA 5 B. Sommerfeld 6 Sun Microsystems 7 B. Zill 8 Microsoft 9 P. Nikander 10 Ericsson 11 July 17, 2004 13 SEcure Neighbor Discovery (SEND) 14 draft-ietf-send-ndopt-06 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as 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 January 15, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover 45 other nodes on the link, to determine the link-layer addresses of 46 other nodes on the link, to find routers, and to maintain 47 reachability information about the paths to active neighbors. If not 48 secured, NDP is vulnerable to various attacks. This document 49 specifies security mechanisms for NDP. Unlike the original NDP 50 specifications these mechanisms do not make use of IPsec. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1 Specification of Requirements . . . . . . . . . . . . 5 56 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3. Neighbor and Router Discovery Overview . . . . . . . . . . . 9 58 4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 11 59 5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 13 60 5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . . 13 61 5.1.1 Processing Rules for Senders . . . . . . . . . . 14 62 5.1.2 Processing Rules for Receivers . . . . . . . . . 15 63 5.1.3 Configuration . . . . . . . . . . . . . . . . . 16 64 5.2 RSA Signature Option . . . . . . . . . . . . . . . . . 16 65 5.2.1 Processing Rules for Senders . . . . . . . . . . 18 66 5.2.2 Processing Rules for Receivers . . . . . . . . . 19 67 5.2.3 Configuration . . . . . . . . . . . . . . . . . 20 68 5.2.4 Performance Considerations . . . . . . . . . . . 21 69 5.3 Timestamp and Nonce options . . . . . . . . . . . . . 21 70 5.3.1 Timestamp Option . . . . . . . . . . . . . . . . 21 71 5.3.2 Nonce Option . . . . . . . . . . . . . . . . . . 22 72 5.3.3 Processing rules for senders . . . . . . . . . . 23 73 5.3.4 Processing rules for receivers . . . . . . . . . 24 74 6. Authorization Delegation Discovery . . . . . . . . . . . . . 27 75 6.1 Authorization Model . . . . . . . . . . . . . . . . . 27 76 6.2 Deployment Model . . . . . . . . . . . . . . . . . . . 28 77 6.3 Certificate Format . . . . . . . . . . . . . . . . . . 29 78 6.3.1 Router Authorization Certificate Profile . . . . 29 79 6.3.2 Suitability of Standard Identity Certificates . 32 80 6.4 Certificate Transport . . . . . . . . . . . . . . . . 32 81 6.4.1 Certification Path Solicitation Message Format . 32 82 6.4.2 Certification Path Advertisement Message Format 34 83 6.4.3 Trust Anchor Option . . . . . . . . . . . . . . 37 84 6.4.4 Certificate Option . . . . . . . . . . . . . . . 38 85 6.4.5 Processing Rules for Routers . . . . . . . . . . 39 86 6.4.6 Processing Rules for Hosts . . . . . . . . . . . 40 87 6.5 Configuration . . . . . . . . . . . . . . . . . . . . 42 88 7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 43 89 7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . . 43 90 7.2 Redirect Addresses . . . . . . . . . . . . . . . . . . 43 91 7.3 Advertised Subnet Prefixes . . . . . . . . . . . . . . 43 92 7.4 Limitations . . . . . . . . . . . . . . . . . . . . . 44 93 8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 46 94 9. Security Considerations . . . . . . . . . . . . . . . . . . 49 95 9.1 Threats to the Local Link Not Covered by SEND . . . . 49 96 9.2 How SEND Counters Threats to NDP . . . . . . . . . . . 49 97 9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 50 98 9.2.2 Neighbor Unreachability Detection Failure . . . 50 99 9.2.3 Duplicate Address Detection DoS Attack . . . . . 50 100 9.2.4 Router Solicitation and Advertisement Attacks . 51 101 9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 51 102 9.2.6 Neighbor Discovery DoS Attack . . . . . . . . . 52 103 9.3 Attacks against SEND Itself . . . . . . . . . . . . . 52 104 10. Protocol Values . . . . . . . . . . . . . . . . . . . . . . 54 105 10.1 Constants . . . . . . . . . . . . . . . . . . . . . . 54 106 10.2 Variables . . . . . . . . . . . . . . . . . . . . . . 54 107 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 55 108 Normative References . . . . . . . . . . . . . . . . . . . . 56 109 Informative References . . . . . . . . . . . . . . . . . . . 58 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 58 111 A. Contributors and Acknowledgments . . . . . . . . . . . . . . 60 112 B. Cache Management . . . . . . . . . . . . . . . . . . . . . . 61 113 C. Message Size When Carrying Certificates . . . . . . . . . . 62 114 Intellectual Property and Copyright Statements . . . . . . . 63 116 1. Introduction 118 IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7] 119 and 2462 [8]. Nodes on the same link use NDP to discover each 120 other's presence, to determine each other's link-layer addresses, to 121 find routers, and to maintain reachability information about the 122 paths to active neighbors. NDP is used both by hosts and routers. 123 Its functions include Neighbor Discovery (ND), Router Discovery (RD), 124 Address Autoconfiguration, Address Resolution, Neighbor 125 Unreachability Detection (NUD), Duplicate Address Detection (DAD), 126 and Redirection. 128 The original NDP specifications called for the use of IPsec to 129 protect NDP messages. However, the RFCs do not give detailed 130 instructions for using IPsec for this. In this particular 131 application, IPsec can only be used with a manual configuration of 132 security associations, due to bootstrapping problems in using IKE 133 [22, 18]. Furthermore, the number of such manually configured 134 security associations needed for protecting NDP can be very large 135 [23], making that approach impractical for most purposes. 137 The SEND protocol is designed to counter the threats to NDP. These 138 threats are described in detail in [25]. SEND is applicable in 139 environments where physical security on the link is not assured (such 140 as over wireless) and attacks on NDP are a concern. 142 This document is organized as follows. Section 2 and Section 3 define 143 some terminology and present a brief review of NDP, respectively. 144 Section 4 describes the overall approach to securing NDP. This 145 approach involves the use of new NDP options to carry public-key 146 based signatures. A zero-configuration mechanism is used for showing 147 address ownership on individual nodes; routers are certified by a 148 trust anchor [10]. The formats, procedures, and cryptographic 149 mechanisms for the zero-configuration mechanism are described in a 150 related specification [14]. 152 The required new NDP options are discussed in Section 5. Section 6 153 describes the mechanism for distributing certification paths to 154 establish an authorization delegation chain to a trust anchor. 156 Finally, Section 8 discusses the co-existence of secured and 157 unsecured NDP on the same link and Section 9 discusses security 158 considerations for Secure Neighbor Discovery (SEND). 160 Out of scope for this document is the use of identity certificates 161 provisioned on end hosts for authorizing address use, and security of 162 NDP when the entity defending an address is not the same as the 163 entity claiming that adddress (also known as "proxy ND"). These are 164 extensions of SEND that may be treated in separate documents should 165 the need arise. 167 1.1 Specification of Requirements 169 In this document, several words are used to signify the requirements 170 of the specification. These words are often capitalized. The key 171 words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and 172 "MAY" in this document are to be interpreted as described in [2]. 174 2. Terms 176 Authorization Delegation Discovery (ADD) 178 A process through which SEND nodes can acquire a certification 179 path from a peer node to a trust anchor. 181 Certificate Revocation List (CRL) 183 In one method of certificate revocation, an authority periodically 184 issues a signed data structure called the Certificate Revocation 185 List. This list is a time stamped list identifying revoked 186 certificates, signed by the issuer, and made freely available in a 187 public repository. 189 Certification Path Advertisement (CPA) 191 The advertisement message used in the ADD process. 193 Certification Path Solicitation (CPS) 195 The solicitation message used in the ADD process. 197 Cryptographically Generated Address (CGA) 199 A technique [14] whereby an IPv6 address of a node is 200 cryptographically generated using a one-way hash function from the 201 node's public key and some other parameters. 203 Distinguished Encoding Rules (DER) 205 An encoding scheme for data values, defined in [15]. 207 Duplicate Address Detection (DAD) 209 A mechanism which assures that two IPv6 nodes on the same link are 210 not using the same address. 212 Fully Qualified Domain Name (FQDN) 214 A fully qualified domain name consists of a host and domain name, 215 including top-level domain. 217 Internationalized Domain Name (IDN) 219 Internationalized Domain Names can be used to represent domain 220 names that contain characters outside the ASCII repertoire. See 221 RFC 3490 [12]. 223 Neighbor Discovery (ND) 225 The Neighbor Discovery function of the Neighbor Discovery Protocol 226 (NDP). NDP contains other functions besides ND. 228 Neighbor Discovery Protocol (NDP) 230 The IPv6 Neighbor Discovery Protocol [7, 8]. 232 The Neighbor Discovery Protocol is a part of ICMPv6 [9]. 234 Neighbor Unreachability Detection (NUD) 236 A mechanism used for tracking the reachability of neighbors. 238 Non-SEND node 240 An IPv6 node that does not implement this specification but uses 241 only the Neighbor Discovery protocol defined in RFC 2461 and RFC 242 2462, as updated, without security. 244 Nonce 246 An unpredictable random or pseudorandom number generated by a node 247 and used exactly once. In SEND, nonces are used to assure that a 248 particular advertisement is linked to the solicitation that 249 triggered it. 251 Router Authorization Certificate 253 An X.509v3 [10] public key certificate using the profile specified 254 in Section 6.3.1. 256 SEND node 258 An IPv6 node that implements this specification. 260 Router Discovery (RD) 262 Router Discovery allows the hosts to discover what routers exist 263 on the link, and what subnet prefixes are available. Router 264 Discovery is a part of the Neighbor Discovery Protocol. 266 Trust Anchor 268 Hosts are configured with a set of trust anchors for the purposes 269 of protecting Router Discovery. A trust anchor is an entity that 270 the host trusts to authorize routers to act as routers. A trust 271 anchor configuration consists of a public key and some associated 272 parameters (see Section 6.5 for a detailed explanation of these 273 parameters). 275 3. Neighbor and Router Discovery Overview 277 The Neighbor Discovery Protocol has several functions. Many of these 278 functions are overloaded on a few central message types, such as the 279 ICMPv6 Neighbor Advertisement message. In this section we review 280 some of these tasks and their effects in order to understand better 281 how the messages should be treated. This section is not normative, 282 and if this section and the original Neighbor Discovery RFCs are in 283 conflict, the original RFCs, as updated, take precedence. 285 The main functions of NDP are the following. 287 o The Router Discovery function allows IPv6 hosts to discover the 288 local routers on an attached link. Router Discovery is described 289 in Section 6 of RFC 2461 [7]. The main purpose of Router 290 Discovery is to find neighboring routers that are willing to 291 forward packets on behalf of hosts. Subnet prefix discovery 292 involves determining which destinations are directly on a link; 293 this information is necessary in order to know whether a packet 294 should be sent to a router or directly to the destination node. 296 o The Redirect function is used for automatically redirecting a host 297 to a better first-hop router, or to inform hosts that a 298 destination is in fact a neighbor (i.e., on-link). Redirect is 299 specified in Section 8 of RFC 2461 [7]. 301 o Address Autoconfiguration is used for automatically assigning 302 addresses to a host [8]. This allows hosts to operate without 303 explicit configuration related to IP connectivity. The default 304 autoconfiguration mechanism is stateless. To create IP addresses, 305 hosts use any prefix information delivered to them during Router 306 Discovery, and then test the newly formed addresses for 307 uniqueness. A stateful mechanism, DHCPv6 [21], provides additional 308 autoconfiguration features. 310 o Duplicate Address Detection (DAD) is used for preventing address 311 collisions [8], for instance during Address Autoconfiguration. A 312 node that intends to assign a new address to one of its interfaces 313 first runs the DAD procedure to verify that there is no other node 314 using the same address. Since the rules forbid the use of an 315 address until it has been found unique, no higher layer traffic is 316 possible until this procedure has been completed. Thus, 317 preventing attacks against DAD can help ensure the availability of 318 communications for the node in question. 320 o The Address Resolution function allows a node on the link to 321 resolve another node's IPv6 address to the corresponding 322 link-layer address. Address Resolution is defined in Section 7.2 323 of RFC 2461 [7], and it is used for hosts and routers alike. 324 Again, no higher level traffic can proceed until the sender knows 325 the link layer address of the destination node or the next hop 326 router. Note the source link layer address on link layer frames is 327 not checked against the information learned through Address 328 Resolution. This allows for an easier addition of network 329 elements such as bridges and proxies, and eases the stack 330 implementation requirements as less information needs to be passed 331 from layer to layer. 333 o Neighbor Unreachability Detection (NUD) is used for tracking the 334 reachability of neighboring nodes, both hosts and routers. NUD is 335 defined in Section 7.3 of RFC 2461 [7]. NUD is 336 security-sensitive, because an attacker could falsely claim that 337 reachability exists when it in fact does not. 339 The NDP messages follow the ICMPv6 message format. All NDP functions 340 are realized using the Router Solicitation (RS), Router Advertisement 341 (RA), Neighbor Solicitation (NS), Neighbor Advertisement (NA), and 342 Redirect messages. An actual NDP message includes an NDP message 343 header, consisting of an ICMPv6 header and ND message-specific data, 344 and zero or more NDP options. The NDP message options are formatted 345 in the Type-Length-Value format. 347 <------------NDP Message----------------> 348 *-------------------------------------------------------------* 349 | IPv6 Header | ICMPv6 | ND Message- | ND Message | 350 | Next Header = 58 | Header | specific | Options | 351 | (ICMPv6) | | data | | 352 *-------------------------------------------------------------* 353 <--NDP Message header--> 355 4. Secure Neighbor Discovery Overview 357 To secure the various functions in NDP, a set of new Neighbor 358 Discovery options is introduced. They are used to protect NDP 359 messages. This specification introduces these options, an 360 authorization delegation discovery process, an address ownership 361 proof mechanism, and requirements for the use of these components in 362 NDP. 364 The components of the solution specified in this document are as 365 follows: 367 o Certification paths, anchored on trusted parties, are expected to 368 certify the authority of routers. A host must be configured with 369 a trust anchor to which the router has a certification path before 370 the host can adopt the router as its default router. 371 Certification Path Solicitation and Advertisement messages are 372 used to discover a certification path to the trust anchor without 373 requiring the actual Router Discovery messages to carry lengthy 374 certification paths. The receipt of a protected Router 375 Advertisement message for which no certification path is available 376 triggers the authorization delegation discovery process. 378 o Cryptographically Generated Addresses are used to assure that the 379 sender of a Neighbor Discovery message is the "owner" of the 380 claimed address. A public-private key pair is generated by all 381 nodes before they can claim an address. A new NDP option, the CGA 382 option, is used to carry the public key and associated parameters. 384 This specification also allows a node to use non-CGAs with 385 certificates to authorize their use. However, the details of such 386 use are beyond the scope of this specification and are left for 387 future work. 389 o A new NDP option, the RSA Signature option, is used to protect all 390 messages relating to Neighbor and Router discovery. 392 Public key signatures protect the integrity of the messages and 393 authenticate the identity of their sender. The authority of a 394 public key is established either with the authorization delegation 395 process, using certificates, or through the address ownership 396 proof mechanism, using CGAs, or both, depending on configuration 397 and the type of the message protected. 399 Note: RSA is mandated because having multiple signature algorithms 400 would break compatibility between implementations or increase 401 implementation complexity by forcing implementation of multiple 402 algorithms and the mechanism to select among them. A second 403 signature algorithm is only necessary as a recovery mechanism, in 404 case a flaw is found in RSA. If that happens, a stronger signature 405 algorithm can be selected and SEND can be revised. The 406 relationship between the new algorithm and the RSA-based SEND 407 described in this document would be similar to that between the 408 RSA-based SEND and Neighbor Discovery without SEND. Information 409 signed with the stronger algorithm has precedence over that signed 410 with RSA, in the same way as RSA-signed information now takes 411 precedence over unsigned information. Implementations of the 412 current and revised specs would still be compatible. 414 o In order to prevent replay attacks, two new Neighbor Discovery 415 options, Timestamp and Nonce, are introduced. Given that Neighbor 416 and Router Discovery messages are in some cases sent to multicast 417 addresses, the Timestamp option offers replay protection without 418 any previously established state or sequence numbers. When the 419 messages are used in solicitation - advertisement pairs, they are 420 protected using the Nonce option. 422 5. Neighbor Discovery Protocol Options 424 The options described in this section MUST be supported. 426 5.1 CGA Option 428 The CGA option allows the verification of the sender's CGA. The 429 format of the CGA option is described as follows. 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Type | Length | Pad Length | Reserved | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | | 437 . . 438 . CGA Parameters . 439 . . 440 | | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | | 443 . . 444 . Padding . 445 . . 446 | | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 Type 451 TBD . 453 Length 455 The length of the option (including the Type, Length, Pad Length, 456 Reserved, CGA Parameters, and Padding fields) in units of 8 457 octets. 459 Pad Length 461 The number of padding octets beyond the end of the CGA Parameters 462 field but within the length specified by the Length field. Padding 463 octets MUST be set to zero by senders and ignored by receivers. 465 Reserved 467 An 8-bit field reserved for future use. The value MUST be 468 initialized to zero by the sender, and MUST be ignored by the 469 receiver. 471 CGA Parameters 473 A variable length field containing the CGA Parameters data 474 structure described in Section 4 of [14]. 476 This specification requires that if both the CGA option and the 477 RSA Signature option are present, then the public key found from 478 the CGA Parameters field in the CGA option MUST be the public key 479 referred by the Key Hash field in the RSA Signature option. 480 Packets received with two different keys MUST be silently 481 discarded. Note that a future extension may provide a mechanism 482 which allows the owner of an address and the signer to be 483 different parties. 485 Padding 487 A variable length field making the option length a multiple of 8, 488 containing as many octets as specified in the Pad Length field. 490 5.1.1 Processing Rules for Senders 492 If the node has been configured to use SEND, the CGA option MUST be 493 present in all Neighbor Solicitation and Advertisement messages, and 494 MUST be present in Router Solicitation messages unless they are sent 495 with the unspecified source address. The CGA option MAY be present in 496 other messages. 498 A node sending a message using the CGA option MUST construct the 499 message as follows. 501 The CGA Parameter field in the CGA option is filled in according to 502 the rules presented above and in [14]. The public key in the field is 503 taken from the node's configuration used to generate the CGA; 504 typically from a data structure associated with the source address. 505 The address MUST be constructed as specified in Section 4 of [14]. 506 Depending on the type of the message, this address appears in 507 different places: 509 Redirect 511 The address MUST be the source address of the message. 513 Neighbor Solicitation 515 The address MUST be the Target Address for solicitations sent for 516 Duplicate Address Detection, and the source address of the message 517 otherwise. 519 Neighbor Advertisement 521 The address MUST be the source address of the message. 523 Router Solicitation 525 The address MUST be the source address of the message. Note that 526 the CGA option is not used when the source address is the 527 unspecified address. 529 Router Advertisement 531 The address MUST be the source address of the message. 533 5.1.2 Processing Rules for Receivers 535 Neighbor Solicitation and Advertisement messages without the CGA 536 option MUST be treated as unsecured, i.e., processed in the same way 537 as NDP messages sent by a non-SEND node. The processing of unsecured 538 messages is specified in Section 8. Note that SEND nodes that do not 539 attempt to interoperate with non-SEND nodes MAY simply discard the 540 unsecured messages. 542 Router Solicitation messages without the CGA option MUST also be 543 treated as unsecured, unless the source address of the message is the 544 unspecified address. 546 Redirect, Neighbor Solicitation, Neighbor Advertisement, Router 547 Solicitation, and Router Advertisement messages containing a CGA 548 option MUST be checked as follows: 550 If the interface has been configured to use CGA, the receiving 551 node MUST verify the source address of the packet using the 552 algorithm described in Section 5 of [14]. The inputs to the 553 algorithm are the claimed address, as defined in the previous 554 section, and the CGA Parameters field. 556 If the CGA verification is successful, the recipient proceeds with 557 more time consuming cryptographic check of the signature. Note 558 that even if the CGA verification succeeds, no claims about the 559 validity of the use can be made, until the signature has been 560 checked. 562 A receiver that does not support CGA or has not specified its use for 563 a given interface can still verify packets using trust anchors, even 564 if a CGA is used on a packet. In such a case, the CGA property of 565 the address is simply left unverified. 567 5.1.3 Configuration 569 All nodes that support the verification of the CGA option MUST record 570 the following configuration information: 572 minbits 574 The minimum acceptable key length for public keys used in the 575 generation of CGAs. The default SHOULD be 1024 bits. 576 Implementations MAY also set an upper limit in order to limit the 577 amount of computation they need to perform when verifying packets 578 that use these security associations. The upper limit SHOULD be at 579 least 2048 bits. Any implementation should follow prudent 580 cryptographic practice in determining the appropriate key lengths. 582 All nodes that support the sending of the CGA option MUST record the 583 following configuration information: 585 CGA parameters 587 Any information required to construct CGAs, as described in [14]. 589 5.2 RSA Signature Option 591 The RSA Signature option allows public-key based signatures to be 592 attached to NDP messages. The format of the RSA Signature option is 593 described in the following diagram: 595 0 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Type | Length | Reserved | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | | 601 | Key Hash | 602 | | 603 | | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | | 606 . . 607 . Digital Signature . 608 . . 609 | | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | | 612 . . 613 . Padding . 614 . . 615 | | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 Type 620 TBD . 622 Length 624 The length of the option (including the Type, Length, Reserved, 625 Key Hash, Digital Signature, and Padding fields) in units of 8 626 octets. 628 Reserved 630 A 16-bit field reserved for future use. The value MUST be 631 initialized to zero by the sender, and MUST be ignored by the 632 receiver. 634 Key Hash 636 A 128-bit field containing the most significant (leftmost) 637 128-bits of a SHA-1 hash of the public key used for constructing 638 the signature. The SHA-1 hash is taken over the presentation used 639 in the Public Key field of the CGA Parameters data structure that 640 is carried in the CGA option. Its purpose is to associate the 641 signature to a particular key known by the receiver. Such a key 642 can be either stored in the certificate cache of the receiver, or 643 be received in the CGA option in the same message. 645 Digital Signature 647 A variable length field containing a PKCS#1 v1.5 signature, 648 constructed using the sender's private key, over the the following 649 sequence of octets: 651 1. The 128-bit CGA Message Type tag [14] value for SEND, 0x086F 652 CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been 653 generated randomly by the editor of this specification.). 655 2. The 128-bit Source Address field from the IP header. 657 3. The 128-bit Destination Address field from the IP header. 659 4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from 660 the ICMP header. 662 5. The NDP message header, starting from the octet after the ICMP 663 Checksum field and continuing up to but not including NDP 664 options. 666 6. All NDP options preceding the RSA Signature option. 668 The signature value is computed with the RSASSA-PKCS1-v1_5 669 algorithm and SHA-1 hash as defined in [16]. 671 This field starts after the Key Hash field. The length of the 672 Digital Signature field is determined by the length of the RSA 673 Signature option minus the length of the other fields (including 674 the variable length Pad field). 676 Padding 678 This variable length field contains padding, as many bytes as 679 remains after end of the signature. 681 5.2.1 Processing Rules for Senders 683 If the node has been configured to use SEND, Neighbor Solicitation, 684 Neighbor Advertisement, Router Advertisement, and Redirect messages 685 MUST contain the RSA Signature option. Router Solicitation messages 686 not sent with the unspecified source address MUST contain the RSA 687 Signature option. 689 A node sending a message using the RSA Signature option MUST 690 construct the message as follows: 692 o The message is constructed in its entirety, without the RSA 693 Signature option. 695 o The RSA Signature option is added as the last option in the 696 message. 698 o The data to be signed is constructed as explained in Section 5.2, 699 under the description of the Digital Signature field. 701 o The message, in the form defined above, is signed using the 702 configured private key, and the resulting PKCS#1 v1.5 signature is 703 put in the Digital Signature field. 705 5.2.2 Processing Rules for Receivers 707 Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, 708 and Redirect messages without the RSA Signature option MUST be 709 treated as unsecured, i.e., processed in the same way as NDP messages 710 sent by a non-SEND node. See Section 8. 712 Router Solicitation messages without the RSA Signature option MUST 713 also be treated as unsecured, unless the source address of the 714 message is the unspecified address. 716 Redirect, Neighbor Solicitation, Neighbor Advertisement, Router 717 Solicitation, and Router Advertisement messages containing an RSA 718 Signature option MUST be checked as follows: 720 o The receiver MUST ignore any options that come after the first RSA 721 Signature option. (The options are ignored for both signature 722 verification and NDP processing purposes.) 724 o The Key Hash field MUST indicate the use of a known public key, 725 either one learned from a preceding CGA option in the same 726 message, or one known by other means. 728 o The Digital Signature field MUST have correct encoding, and not 729 exceed the length of the RSA Signature option minus the Padding. 731 o The Digital Signature verification MUST show that the signature 732 has been calculated as specified in the previous section. 734 o If the use of a trust anchor has been configured, a valid 735 certification path (see Section 6.3) MUST be known between the 736 receiver's trust anchor and the sender's public key. 738 Note that the receiver may verify just the CGA property of a 739 packet, even if, in addition to CGA, the sender has used a trust 740 anchor. 742 Messages that do not pass all the above tests MUST be silently 743 discarded if the host has been configured to only accept secured ND 744 messages. The messages MAY be accepted if the host has been 745 configured to accept both secured and unsecured messages, but MUST be 746 treated as an unsecured message. The receiver MAY also otherwise 747 silently discard packets, e.g., as a response to an apparent CPU 748 exhausting DoS attack. 750 5.2.3 Configuration 752 All nodes that support the reception of the RSA Signature options 753 MUST allow the following information to be configured for each 754 separate NDP message type: 756 authorization method 758 This parameter determines the method through which the authority 759 of the sender is determined. It can have four values: 761 trust anchor 763 The authority of the sender is verified as described in Section 764 6.3. The sender may claim additional authorization through the 765 use of CGAs, but that is neither required nor verified. 767 CGA 769 The CGA property of the sender's address is verified as 770 described in [14]. The sender may claim additional authority 771 through a trust anchor, but that is neither required nor 772 verified. 774 trust anchor and CGA 776 Both the trust anchor and the CGA verification is required. 778 trust anchor or CGA 780 Either the trust anchor or the CGA verification is required. 782 anchor 784 The allowed trust anchor(s), if the authorization method is not 785 set to CGA. 787 All nodes that support the sending of RSA Signature options MUST 788 record the following configuration information: 790 keypair 792 A public-private key pair. If authorization delegation is in use, 793 there must exist a certification path from a trust anchor to this 794 key pair. 796 CGA flag 798 A flag that indicates whether CGA is used or not. This flag may be 799 per interface or per node. (Note that in future extensions of the 800 SEND protocol, this flag may also be per subnet-prefix.) 802 5.2.4 Performance Considerations 804 The construction and verification of the RSA Signature option is 805 computationally expensive. In the NDP context, however, hosts 806 typically need to perform only a few signature operations as they 807 enter a link, a few operations as they find a new on-link peer with 808 which to communicate, or Neighbor Unreachability Detection with 809 existing neighbors. 811 Routers are required to perform a larger number of operations, 812 particularly when the frequency of router advertisements is high due 813 to mobility requirements. Still, the number of required signature 814 operations is on the order of a few dozen per second, some of which 815 can be precomputed as explained below. A large number of router 816 solicitations may cause higher demand for performing asymmetric 817 operations, although the base NDP protocol limits the rate at which 818 responses to solicitations can be sent. 820 Signatures can be precomputed for unsolicited (multicast) Neighbor 821 and Router Advertisements if the timing of such future advertisements 822 is known. Typically, solicited advertisements are sent to the unicast 823 address from which the solicitation was sent. Given that the IPv6 824 header is covered by the signature, it is not possible to precompute 825 solicited advertisements. 827 5.3 Timestamp and Nonce options 829 5.3.1 Timestamp Option 831 The purpose of the Timestamp option is to assure that unsolicited 832 advertisements and redirects have not been replayed. The format of 833 this option is described in the following: 835 0 1 2 3 836 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 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Type | Length | Reserved | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 840 | | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | | 843 + Timestamp + 844 | | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 Type 849 TBD . 851 Length 853 The length of the option (including the Type, Length, Reserved, 854 and Timestamp fields) in units of 8 octets, i.e., 2. 856 Reserved 858 A 48-bit field reserved for future use. The value MUST be 859 initialized to zero by the sender, and MUST be ignored by the 860 receiver. 862 Timestamp 864 A 64-bit unsigned integer field containing a timestamp. The value 865 indicates the number of seconds since January 1, 1970 00:00 UTC, 866 using a fixed point format. In this format the integer number of 867 seconds is contained in the first 48 bits of the field, and the 868 remaining 16 bits indicate the number of 1/64K fractions of a 869 second. 871 Implementation note: This format is compatible with the usual 872 representation of time under UNIX, although the number of bits 873 available for the integer and fraction parts may vary. 875 5.3.2 Nonce Option 877 The purpose of the Nonce option is to assure that an advertisement is 878 a fresh response to a solicitation sent earlier by the node. The 879 format of this option is described in the following: 881 0 1 2 3 882 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 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Type | Length | Nonce ... | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 886 | | 887 . . 888 . . 889 | | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 Type 894 TBD . 896 Length 898 The length of the option (including the Type, Length, and Nonce 899 fields) in units of 8 octets. 901 Nonce 903 A field containing a random number selected by the sender of the 904 solicitation message. The length of the random number MUST be at 905 least 6 bytes. The length of the random number MUST be selected so 906 that the length of the nonce option is a multiple of 8 octets. 908 5.3.3 Processing rules for senders 910 If the node has been configured to use SEND, all solicitation 911 messages MUST include a Nonce. When sending a solicitation, the 912 sender MUST store the nonce internally so that it can recognize any 913 replies containing that particular nonce. 915 If the node has been configured to use SEND, all advertisements sent 916 in reply to a solicitation MUST include a Nonce, copied from the 917 received solicitation. Note that routers may decide to send a 918 multicast advertisement to all nodes instead of a response to a 919 specific host. In such case the router MAY still include the nonce 920 value for the host that triggered the multicast advertisement. 921 (Omitting the nonce value may cause the host to ignore the router's 922 advertisement, unless the clocks in these nodes are sufficiently 923 synchronized so that timestamps function properly.) 925 If the node has been configured to use SEND, all solicitation, 926 advertisement, and redirect messages MUST include a Timestamp. 927 Senders SHOULD set the Timestamp field to the current time, according 928 to their real time clock. 930 5.3.4 Processing rules for receivers 932 The processing of the Nonce and Timestamp options depends on whether 933 a packet is a solicited advertisement. A system may implement the 934 distinction in various ways. Section 5.3.4.1 defines the processing 935 rules for solicited advertisements. Section 5.3.4.2 defines the 936 processing rules for all other messages. 938 In addition, the following rules apply in all cases: 940 o Messages received without at least one of the the Timestamp and 941 Nonce options MUST be treated as unsecured, i.e., processed in the 942 same way as NDP messages sent by a non-SEND node. 944 o Messages received with the RSA Signature option but without the 945 Timestamp option MUST be silently discarded. 947 o Solicitation messages received with the RSA Signature option but 948 without the Nonce option MUST be silently discarded. 950 o Advertisements sent to a unicast destination address with the RSA 951 Signature option but without a Nonce option SHOULD be processed as 952 unsolicited advertisements. 954 o An implementation MAY utilize some mechanism such as a timestamp 955 cache to strengthen resistance to replay attacks. When there is a 956 very large number of nodes on the same link, or when a cache 957 filling attack is in progress, it is possible that the cache 958 holding the most recent timestamp per sender becomes full. In 959 this case the node MUST remove some entries from the cache or 960 refuse some new requested entries. The specific policy as to 961 which entries are preferred over the others is left as an 962 implementation decision. However, typical policies may prefer 963 existing entries over new ones, CGAs with a large Sec value over 964 smaller Sec values, and so on. The issue is briefly discussed in 965 Appendix B. 967 o The receiver MUST be prepared to receive the Timestamp and Nonce 968 options in any order, as per RFC 2461 [7] Section 9. 970 5.3.4.1 Processing solicited advertisements 972 The receiver MUST verify that it has recently sent a matching 973 solicitation, and that the received advertisement contains a copy of 974 the Nonce sent in the solicitation. 976 If the message contains a Nonce option, but the Nonce value is not 977 recognized, the message MUST be silently discarded. 979 Otherwise, if the message does not contain a Nonce option, it MAY be 980 considered as an unsolicited advertisement, and processed according 981 to Section 5.3.4.2. 983 If the message is accepted, the receiver SHOULD store the receive 984 time of the message and the time stamp time in the message, as 985 specified in Section 5.3.4.2. 987 5.3.4.2 Processing all other messages 989 Receivers SHOULD be configured with an allowed timestamp Delta value, 990 a "fuzz factor" for comparisons, and an allowed clock drift 991 parameter. The recommended default value for the allowed Delta is 992 TIMESTAMP_DELTA, for fuzz factor TIMESTAMP_FUZZ, and for clock drift 993 TIMESTAMP_DRIFT (see Section 10.2). 995 To facilitate timestamp checking, each node SHOULD store the 996 following information for each peer: 998 o The receive time of the last received and accepted SEND message. 999 This is called RDlast. 1001 o The time stamp in the last received and accepted SEND message. 1002 This is called TSlast. 1004 An accepted SEND message is any successfully verified Neighbor 1005 Solicitation, Neighbor Advertisement, Router Solicitation, Router 1006 Advertisement, or Redirect message from the given peer. The RSA 1007 Signature option MUST be used in such a message before it can update 1008 the above variables. 1010 Receivers SHOULD then check the Timestamp field as follows: 1012 o When a message is received from a new peer (i.e., one that is not 1013 stored in the cache) the received timestamp, TSnew, is checked and 1014 the packet is accepted if the timestamp is recent enough with 1015 respect to the reception time of the packet, RDnew: 1017 -Delta < (RDnew - TSnew) < +Delta 1019 The RDnew and TSnew values SHOULD be stored into the cache as 1020 RDlast and TSlast. 1022 o Even if the timestamp is NOT within the boundaries but the message 1023 is a Neighbor Solicitation message that should be answered by the 1024 receiver, the receiver SHOULD respond to the message. However, if 1025 it does respond to the message, it MUST NOT create a Neighbor 1026 Cache entry. This allows nodes that have large differences in 1027 their clocks to still communicate with each other, by exchanging 1028 NS/NA pairs. 1030 o When a message is received from a known peer, i.e., one that 1031 already has an entry in the cache, the time stamp is checked 1032 against the previously received SEND message: 1034 TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz 1036 If this inequality does not hold, the receiver SHOULD silently 1037 discard the message. On the other hand, if the inequality holds, 1038 the receiver SHOULD process the message. 1040 Moreover, if the above inequality holds and TSnew > TSlast, the 1041 receiver SHOULD update RDlast and TSlast. Otherwise, the receiver 1042 MUST NOT update update RDlast or TSlast. 1044 As unsolicited messages may be used in a Denial-of-Service attack to 1045 cause the receiver to verify computationally expensive signatures, 1046 all nodes SHOULD apply a mechanism to prevent excessive use of 1047 resources for processing such messages. 1049 6. Authorization Delegation Discovery 1051 NDP allows a node to automatically configure itself based on 1052 information learned shortly after connecting to a new link. It is 1053 particularly easy to configure "rogue" routers on an unsecured link, 1054 and it is particularly difficult for a node to distinguish between 1055 valid and invalid sources of router information, because the node 1056 needs this information before being able to communicate with nodes 1057 outside of the link. 1059 Since the newly-connected node cannot communicate off-link, it cannot 1060 be responsible for searching information to help validate the 1061 router(s); however, given a certification path, the node can check 1062 someone else's search results and conclude that a particular message 1063 comes from an authorized source. In the typical case, a router 1064 already connected beyond the link, can (if necessary) communicate 1065 with off-link nodes and construct such a certification path. 1067 The Secure Neighbor Discovery Protocol mandates a certificate format 1068 and introduces two new ICMPv6 messages that are used between hosts 1069 and routers to allow the host to learn a certification path with the 1070 assistance of the router. 1072 6.1 Authorization Model 1074 To protect Router Discovery, SEND requires routers to be authorized 1075 to act as routers. This authorization is provisioned in both routers 1076 and hosts: routers are given certificates from a trust anchor and the 1077 hosts are configured with the trust anchor(s) to authorize routers. 1078 This provisioning is specific to SEND, and does not assume that 1079 certificates already deployed for some other purpose can be used. 1081 The authorization for routers in SEND is twofold: 1083 o Routers are authorized to act as routers. The router belongs to 1084 the set of routers trusted by the trust anchor. All routers in 1085 this set have the same authorization. 1087 o Optionally, routers may also be authorized to advertise a certain 1088 set of subnet prefixes. A specific router is given a specific set 1089 of subnet prefixes to advertise; other routers have an 1090 authorization to advertise other subnet prefixes. Trust anchors 1091 may also delegate a certain set of subnet prefixes to someone 1092 (such as an ISP), who in turn delegates parts of this set to 1093 individual routers. 1095 Note that while communicating with hosts, routers typically present 1096 also a number of other parameters beyond the above. For instance, 1097 routers have their own IP addresses, subnet prefixes have lifetimes, 1098 routers control the use of stateless and stateful address 1099 autoconfiguration, and so on. However, the ability to be a router and 1100 the subnet prefixes are the most fundamental parameters to authorize. 1101 This is because the host needs to choose a router that it uses as its 1102 default router, and because the advertised subnet prefixes have an 1103 impact on the addresses the host uses. In addition, the subnet 1104 prefixes also represent a claim about the topological location of the 1105 router in the network. 1107 Care should be taken if the certificates used in SEND are also used 1108 to provide authorization in other circumstances, for example with 1109 routing protocols. It is necessary to ensure that the authorization 1110 information is appropriate for all applications. SEND certificates 1111 may authorize a larger set of subnet prefixes than the router is 1112 really authorized to advertise on a given interface. For instance, 1113 SEND allows the use of the null prefix. This prefix might cause 1114 verification or routing problems in other applications. It is 1115 RECOMMENDED that SEND certificates containing the null prefix are 1116 only used for SEND. 1118 Note that end hosts need not be provisioned with their own certified 1119 public keys, just as Web clients today do not require end host 1120 provisioning with certified keys. Public keys for CGA generation do 1121 not need to be certified, since such keys derive their ability to 1122 authorize operations on the CGA by the tie to the address. 1124 6.2 Deployment Model 1126 The deployment model for trust anchors can be either a globally 1127 rooted public key infrastructure, or a more local, decentralized 1128 deployment model similar to the current model used for TLS in Web 1129 servers. The centralized model assumes a global root capable of 1130 authorizing routers and, optionally, the address space they 1131 advertise. The end hosts are configured with the public keys of the 1132 global root. The global root could operate, for instance, under the 1133 Internet Assigned Numbers Authority (IANA) or as a co-operative among 1134 Regional Internet Registries (RIRs). However, no such global root 1135 currently exists. 1137 In the decentralized model, end hosts are configured with a 1138 collection of trusted public keys. The public keys could be issued 1139 from a variety of places, for example: a) a public key for the end 1140 host's own organization, b) a public key for the end host's home ISP 1141 and for ISPs with which the home ISP has a roaming agreement, or c) 1142 public keys for roaming brokers that act as intermediaries for ISPs 1143 that don't want to run their own certification authority. 1145 This decentralized model works even when a SEND node is used both in 1146 networks that have certified routers and in networks that do not. As 1147 discussed in Section 8, a SEND node can fall back to the use of a 1148 non-SEND router. This makes it possible to start with a local trust 1149 anchor even if there is no trust anchor for all possible networks. 1151 6.3 Certificate Format 1153 The certification path of a router terminates in a Router 1154 Authorization Certificate that authorizes a specific IPv6 node to act 1155 as a router. Because authorization paths are not a common practice 1156 in the Internet at the time this specification was written, the path 1157 MUST consist of standard Public Key Certificates (PKC, in the sense 1158 of [11]). The certification path MUST start from the identity of a 1159 trust anchor that is shared by the host and the router. This allows 1160 the host to anchor trust for the router's public key in the trust 1161 anchor. Note that there MAY be multiple certificates issued by a 1162 single trust anchor. 1164 6.3.1 Router Authorization Certificate Profile 1166 Router Authorization Certificates are X.509v3 certificates, as 1167 defined in RFC 3280 [10], and SHOULD contain at least one instance of 1168 the X.509 extension for IP addresses, as defined in [13]. The parent 1169 certificates in the certification path SHOULD contain one or more 1170 X.509 IP address extensions, back up to a trusted party (such as the 1171 user's ISP) that configured the original IP address block for the 1172 router in question, or delegated the right to do so. The certificates 1173 for the intermediate delegating authorities SHOULD contain X.509 IP 1174 address extension(s) for subdelegations. The router's certificate is 1175 signed by the delegating authority for the subnet prefixes the router 1176 is authorized to advertise. 1178 The X.509 IP address extension MUST contain at least one 1179 addressesOrRanges element. This element MUST contain an addressPrefix 1180 element containing an IPv6 address prefix for a prefix the router or 1181 the intermediate entity is authorized to route. If the entity is 1182 allowed to route any prefix, the used IPv6 address prefix is the null 1183 prefix, ::/0. The addressFamily element of the containing 1184 IPAddrBlocks sequence element MUST contain the IPv6 Address Family 1185 Identifier (0002), as specified in [13] for IPv6 subnet prefixes. 1186 Instead of an addressPrefix element, the addressesOrRange element MAY 1187 contain an addressRange element for a range of subnet prefixes, if 1188 more than one prefix is authorized. The X.509 IP address extension 1189 MAY contain additional IPv6 subnet prefixes, expressed either as an 1190 addressPrefix or an addressRange. 1192 A node receiving a Router Authorization Certificate MUST first check 1193 whether the certificate's signature was generated by the delegating 1194 authority. Then the client SHOULD check whether all the 1195 addressPrefix or addressRange entries in the router's certificate are 1196 contained within the address ranges in the delegating authority's 1197 certificate, and whether the addressPrefix entries match any 1198 addressPrefix entries in the delegating authority's certificate. If 1199 an addressPrefix or addressRange is not contained within the 1200 delegating authority's subnet prefixes or ranges, the client MAY 1201 attempt to take an intersection of the ranges/subnet prefixes, and 1202 use that intersection. If the resulting intersection is empty, the 1203 client MUST NOT accept the certificate. If the addressPrefix in the 1204 certificate is missing or is the null prefix, ::/0, the parent prefix 1205 or range SHOULD be used. If there is no parent prefix or range, the 1206 subnet prefixes that the router advertises are said to be 1207 unconstrained (see Section 7.3). That is, the router is allowed to 1208 advertise any prefix. 1210 The above check SHOULD be done for all certificates in the path. If 1211 any of the checks fail, the client MUST NOT accept the certificate. 1212 The client also needs to perform validation of advertised subnet 1213 prefixes as discussed in Section 7.3. 1215 Hosts MUST check the subjectPublicKeyInfo field within the last 1216 certificate in the certificate path to ensure that only RSA public 1217 keys are used to attempt validation of router signatures, and MUST 1218 disregard the certificate for SEND if it does not contain an RSA key. 1220 Since it is possible that some public key certificates used with SEND 1221 do not immediately contain the X.509 IP address extension element, an 1222 implementation MAY contain facilities that allow the prefix and range 1223 checks to be relaxed. However, any such configuration options SHOULD 1224 be off by default. That is, the system SHOULD have a default 1225 configuration that requires rigorous prefix and range checks. 1227 The following is an example of a certification path. Suppose that 1228 isp_group_example.net is the trust anchor. The host has this 1229 certificate: 1231 Certificate 1: 1232 Issuer: isp_group_example.net 1233 Validity: Jan 1, 2004 through Dec 31, 2004 1234 Subject: isp_group_example.net 1235 Extensions: 1236 IP address delegation extension: 1237 Prefixes: P1, ..., Pk 1238 ... possibly other extensions ... 1239 ... other certificate parameters ... 1241 When the host attaches to a link served by 1242 router_x.isp_foo_example.net, it receives the following certification 1243 path: 1245 Certificate 2: 1246 Issuer: isp_group_example.net 1247 Validity: Jan 1, 2004 through Dec 31, 2004 1248 Subject: isp_foo_example.net 1249 Extensions: 1250 IP address delegation extension: 1251 Prefixes: Q1, ..., Qk 1252 ... possibly other extensions ... 1253 ... other certificate parameters ... 1255 Certificate 3: 1256 Issuer: isp_foo_example.net 1257 Validity: Jan 1, 2004 through Dec 31, 2004 1258 Subject: router_x.isp_foo_example.net 1259 Extensions: 1260 IP address delegation extension: 1261 Prefixes R1, ..., Rk 1262 ... possibly other extensions ... 1264 ... other certificate parameters ... 1266 When processing the three certificates, the usual RFC 3280 [10] 1267 certificate path validation is performed. Note, however, that at the 1268 time a node is checking certificates received from a router, it 1269 typically does not have a connection to the Internet yet, and so it 1270 is not possible to perform an on-line Certificate Revocation List 1271 (CRL) check if such a check is necessary. Until such a check is 1272 performed, acceptance of the certificate MUST be considered 1273 provisional, and the node MUST perform a check as soon as it has 1274 established a connection with the Internet through the router. If the 1275 router has been compromised, it could interfere with the CRL check. 1276 Should performance of the CRL check be disrupted or should the check 1277 fail, the node SHOULD immediately stop using the router as a default 1278 and use another router on the link instead. 1280 In addition, the IP addresses in the delegation extension MUST be a 1281 subset of the IP addresses in the delegation extension of the 1282 issuer's certificate. So in this example, R1, ..., Rs must be a 1283 subset of Q1,...,Qr, and Q1,...,Qr must be a subset of P1,...,Pk. If 1284 the certification path is valid, then router_foo.isp_foo_example.com 1285 is authorized to route the prefixes R1,...,Rs. 1287 6.3.2 Suitability of Standard Identity Certificates 1289 Since deployment of the IP address extension is, itself, not common, 1290 a network service provider MAY choose to deploy standard identity 1291 certificates on the router to supply the router's public key for 1292 signed Router Advertisements. 1294 If there is no prefix information further up in the certification 1295 path, a host interprets a standard identity certificate as allowing 1296 unconstrained prefix advertisements. 1298 If the other certificates do contain prefix information, a standard 1299 identity certificate is interpreted as allowing those subnet 1300 prefixes. 1302 6.4 Certificate Transport 1304 The Certification Path Solicitation (CPS) message is sent by a host 1305 when it wishes to request a certification path between a router and 1306 one of the host's trust anchors. The Certification Path 1307 Advertisement (CPA) message is sent in reply to the CPS message. 1308 These messages are separate from the rest of Neighbor and Router 1309 Discovery, in order to reduce the effect of the potentially 1310 voluminous certification path information on other messages. 1312 The Authorization Delegation Discovery (ADD) process does not exclude 1313 other forms of discovering certification paths. For instance, during 1314 fast movements mobile nodes may learn information - including the 1315 certification paths - of the next router from a previous router, or 1316 nodes may be preconfigured with certification paths from roaming 1317 partners. 1319 Where hosts themselves are certified by a trust anchor, these 1320 messages MAY also optionally be used between hosts to acquire the 1321 peer's certification path. However, the details of such usage are 1322 beyond the scope of this specification. 1324 6.4.1 Certification Path Solicitation Message Format 1326 Hosts send Certification Path Solicitations in order to prompt 1327 routers to generate Certification Path Advertisements. 1329 0 1 2 3 1330 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 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | Type | Code | Checksum | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | Identifier | Component | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | Options ... 1337 +-+-+-+-+-+-+-+-+-+-+-+- 1339 IP Fields: 1341 Source Address 1343 A link-local unicast address assigned to the sending interface, 1344 or the unspecified address if no address is assigned to the 1345 sending interface. 1347 Destination Address 1349 Typically the All-Routers multicast address, the Solicited-Node 1350 multicast address, or the address of the host's default router. 1352 Hop Limit 1354 255 1356 ICMP Fields: 1358 Type 1360 TBD . 1363 Code 1365 0 1367 Checksum 1369 The ICMP checksum [9]. 1371 Identifier 1373 A 16-bit unsigned integer field, acting as an identifier to 1374 help matching advertisements to solicitations. The Identifier 1375 field MUST NOT be zero, and its value SHOULD be randomly 1376 generated. This randomness does not need to be 1377 cryptographically hard, since its purpose is only to avoid 1378 collisions. 1380 Component 1382 This 16-bit unsigned integer field is set to 65,535 if the 1383 sender desires to retrieve all certificates. Otherwise, it is 1384 set to the component identifier corresponding to the 1385 certificate that the receiver wants to retrieve (see Section 1386 6.4.2 and Section 6.4.6). 1388 Valid Options: 1390 Trust Anchor 1392 One or more trust anchors that the client is willing to accept. 1393 The first (or only) Trust Anchor option MUST contain a DER 1394 Encoded X.501 Name; see Section 6.4.3. If there is more than 1395 one Trust Anchor option, the options past the first one may 1396 contain any type of trust anchor. 1398 Future versions of this protocol may define new option types. 1399 Receivers MUST silently ignore any options they do not recognize 1400 and continue processing the message. All included options MUST 1401 have a length that is greater than zero. 1403 ICMP length (derived from the IP length) MUST be 8 or more octets. 1405 6.4.2 Certification Path Advertisement Message Format 1407 Routers send out Certification Path Advertisement messages in 1408 response to a Certification Path Solicitation. 1410 0 1 2 3 1411 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 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 | Type | Code | Checksum | 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 | Identifier | All Components | 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | Component | Reserved | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 | Options ... 1420 +-+-+-+-+-+-+-+-+-+-+-+- 1422 IP Fields: 1424 Source Address 1426 A link-local unicast address assigned to the interface from 1427 which this message is sent. Note that routers may use multiple 1428 addresses, and therefore this address is not sufficient for the 1429 unique identification of routers. 1431 Destination Address 1433 Either the Solicited-Node multicast address of the receiver or 1434 the link-scoped All-Nodes multicast address. 1436 Hop Limit 1438 255 1440 ICMP Fields: 1442 Type 1444 TBD . 1447 Code 1449 0 1451 Checksum 1453 The ICMP checksum [9]. 1455 Identifier 1457 A 16-bit unsigned integer field, acting as an identifier to 1458 help matching advertisements to solicitations. The Identifier 1459 field MUST be zero for advertisements sent to the All-Nodes 1460 multicast address and MUST NOT be zero for others. 1462 All Components 1464 A 16-bit unsigned integer field, used for informing the 1465 receiver how many certificates are in the entire path. 1467 A single advertisement SHOULD be broken into separately sent 1468 components if there is more than one certificate in the path, 1469 in order to avoid excessive fragmentation at the IP layer. 1471 Individual certificates in a path MAY be stored and used as 1472 received before all the certificates have arrived; this makes 1473 the protocol slightly more reliable and less prone to 1474 Denial-of-Service attacks. 1476 Example packet lengths of Certification Path Advertisement 1477 messages for typical certification paths are listed in Appendix 1478 C. 1480 Component 1482 A 16-bit unsigned integer field, used for informing the 1483 receiver which certificate is being sent. 1485 The first message in a N-component advertisement has the 1486 Component field set to N-1, the second set to N-2, and so on. 1487 Zero indicates that there are no more components coming in this 1488 advertisement. 1490 The sending of path components SHOULD be ordered so that the 1491 certificate after the trust anchor is sent first. Each 1492 certificate sent after the first can be verified with the 1493 previously sent certificates. The certificate of the sender 1494 comes last. The trust anchor certificate SHOULD NOT be sent. 1496 Reserved 1498 An unused field. It MUST be initialized to zero by the sender 1499 and MUST be ignored by the receiver. 1501 Valid Options: 1503 Certificate 1505 One certificate is provided in each Certificate option, to 1506 establish part of a certification path to a trust anchor. 1508 The certificate of the trust anchor itself SHOULD NOT be sent. 1510 Trust Anchor 1512 Zero or more Trust Anchor options may be included to help 1513 receivers decide which advertisements are useful for them. If 1514 present, these options MUST appear in the first component of a 1515 multi-component advertisement. 1517 Future versions of this protocol may define new option types. 1518 Receivers MUST silently ignore any options they do not recognize 1519 and continue processing the message. All included options MUST 1520 have a length that is greater than zero. 1522 ICMP length (derived from the IP length) MUST be 8 or more octets. 1524 6.4.3 Trust Anchor Option 1526 The format of the Trust Anchor option is described in the following: 1528 0 1 2 3 1529 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 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | Type | Length | Name Type | Pad Length | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | Name ... | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | ... Padding | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 Type 1540 TBD . 1542 Length 1544 The length of the option, (including the Type, Length, Name Type, 1545 Pad Length, and Name fields) in units of 8 octets. 1547 Name Type 1549 The type of the name included in the Name field. This 1550 specification defines two legal values for this field: 1552 1 DER Encoded X.501 Name 1553 2 FQDN 1555 Pad Length 1557 The number of padding octets beyond the end of the Name field but 1558 within the length specified by the Length field. Padding octets 1559 MUST be set to zero by senders and ignored by receivers. 1561 Name 1563 When the Name Type field is set to 1, the Name field contains a 1564 DER encoded X.501 Name identifying the trust anchor. The value is 1565 encoded as defined in [15] and [10]. 1567 When the Name Type field is set to 2, the Name field contains a 1568 Fully Qualified Domain Name of the trust anchor, for example, 1569 "trustanchor.example.com". The name is stored as a string, in the 1570 DNS wire format, as specified in RFC 1034 [1]. Additionally, the 1571 restrictions discussed in RFC 3280 [10] Section 4.2.1.7 apply. 1573 In the FQDN case, the Name field is an "IDN-unaware domain name 1574 slot" as defined in [12]. That is, it can contain only ASCII 1575 characters. An implementation MAY support internationalized 1576 domain names (IDNs) using the ToASCII operation; see [12] for more 1577 information. 1579 All systems MUST support the DER Encoded X.501 Name. 1580 Implementations MAY support the FQDN name type. 1582 Padding 1584 A variable length field making the option length a multiple of 8, 1585 beginning after the previous field ends, and continuing to the end 1586 of the option, as specified by the Length field. 1588 6.4.4 Certificate Option 1590 The format of the certificate option is described in the following: 1592 0 1 2 3 1593 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 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | Type | Length | Cert Type | Reserved | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 | Certificate ... 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | ... Padding | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 Type 1604 TBD . 1606 Length 1608 The length of the option, (including the Type, Length, Cert Type, 1609 Pad Length, and Certificate fields) in units of 8 octets. 1611 Cert Type 1613 The type of the certificate included in the Certificate field. 1614 This specification defines only one legal value for this field: 1616 1 X.509v3 Certificate, as specified below 1618 Reserved 1620 An 8-bit field reserved for future use. The value MUST be 1621 initialized to zero by the sender, and MUST be ignored by the 1622 receiver. 1624 Certificate 1626 When the Cert Type field is set to 1, the Certificate field 1627 contains an X.509v3 certificate [10], as described in Section 1628 6.3.1. 1630 Padding 1632 A variable length field making the option length a multiple of 8, 1633 beginning after the ASN.1 encoding of the previous field [10, 15] 1634 ends, and continuing to the end of the option, as specified by the 1635 Length field. 1637 6.4.5 Processing Rules for Routers 1639 A router MUST silently discard any received Certification Path 1640 Solicitation messages that do not conform to the message format 1641 defined in Section 6.4.1. The contents of the Reserved field, and of 1642 any unrecognized options, MUST be ignored. Future, 1643 backward-compatible changes to the protocol may specify the contents 1644 of the Reserved field or add new options; backward-incompatible 1645 changes may use different Code values. The contents of any defined 1646 options that are not specified to be used with Router Solicitation 1647 messages MUST be ignored and the packet processed in the normal 1648 manner. The only defined option that may appear is the Trust Anchor 1649 option. A solicitation that passes the validity checks is called a 1650 "valid solicitation". 1652 Routers SHOULD send advertisements in response to valid solicitations 1653 received on an advertising interface. If the source address in the 1654 solicitation was the unspecified address, the router MUST send the 1655 response to the link-scoped All-Nodes multicast address. If the 1656 source address was a unicast address, the router MUST send the 1657 response to the Solicited-Node multicast address corresponding to the 1658 source address, except when under load, as specified below. Routers 1659 SHOULD NOT send Certification Path Advertisements more than 1660 MAX_CPA_RATE times within a second. When there are more 1661 solicitations, the router SHOULD send the response to the All-Nodes 1662 multicast address regardless of the source address that appeared in 1663 the solicitation. 1665 In an advertisement, the router SHOULD include suitable Certificate 1666 options so that a certification path to the solicited trust anchor 1667 can be established (or a part of it, if the Component field in the 1668 solicitation is not equal to 65,535). Note also that a single 1669 advertisement is broken into separately sent components and ordered 1670 in a particular way (see Section 6.4.2) when there is more than one 1671 certificate in the path. 1673 The anchor is identified by the Trust Anchor option. If the Trust 1674 Anchor option is represented as a DER Encoded X.501 Name, then the 1675 Name must be equal to the Subject field in the anchor's certificate. 1676 If the Trust Anchor option is represented as an FQDN, the FQDN must 1677 be equal to an FQDN in the subjectAltName field of the anchor's 1678 certificate. The router SHOULD include the Trust Anchor option(s) in 1679 the advertisement for which the certification path was found. 1681 If the router is unable to find a path to the requested anchor, it 1682 SHOULD send an advertisement without any certificates. In this case 1683 the router SHOULD include the Trust Anchor options which were 1684 solicited. 1686 6.4.6 Processing Rules for Hosts 1688 A host MUST silently discard any received Certification Path 1689 Advertisement messages that do not conform to the message format 1690 defined in Section 6.4.2. The contents of the Reserved field, and of 1691 any unrecognized options, MUST be ignored. Future, 1692 backward-compatible changes to the protocol MAY specify the contents 1693 of the Reserved field or add new options; backward-incompatible 1694 changes MUST use different Code values. The contents of any defined 1695 options that are not specified to be used with Certification Path 1696 Advertisement messages MUST be ignored and the packet processed in 1697 the normal manner. The only defined options that may appear are the 1698 Certificate and Trust Anchor options. An advertisement that passes 1699 the validity checks is called a "valid advertisement". 1701 Hosts SHOULD store certification paths retrieved in Certification 1702 Path Discovery messages if they start from an anchor trusted by the 1703 host. The certification paths MUST be verified, as defined in Section 1704 6.3, before storing them. Routers send the certificates one by one, 1705 starting from the trust anchor end of the path. 1707 Note: except for temporary purposes to allow for message loss and 1708 reordering, hosts might not store certificates received in a 1709 Certification Path Advertisement unless they contain a certificate 1710 which can be immediately verified either to the trust anchor or to a 1711 certificate that has been verified earlier. This measure is to 1712 prevent Denial-of-Service attacks, whereby an attacker floods a host 1713 with certificates that the host cannot validate and overwhelms memory 1714 for certificate storage. 1716 Note that caching this information and the implied verification 1717 results between network attachments for use over multiple attachments 1718 to the network can help improve performance. But periodic certificate 1719 revocation checks are still needed even with cached results, to make 1720 sure that the certificates are still valid. 1722 The host has a need to retrieve a certification path when a Router 1723 Advertisement has been received with a public key that is not 1724 available from a certificate in the hosts' cache of certificates, or 1725 there is no certification path to the one of the host's trust 1726 anchors. In these situations, the host MAY send a Certification Path 1727 Solicitation message to retrieve the path. If there is no response 1728 within CPS_RETRY seconds, the message should be retried. The wait 1729 interval for each subsequent retransmission MUST exponentially 1730 increase, doubling each time. If there is no response after 1731 CPS_RETRY_MAX seconds, the host abandons the certification path 1732 retrieval process. If the host receives only a part of a 1733 certification path within CPS_RETRY_FRAGMENTS seconds of receiving 1734 the first part, it MAY in addition transmit a Certification Path 1735 Solicitation message with the Component field set to a value not 1736 equal to 65,535. This message can be retransmitted using the same 1737 process as in the initial message. If there are multiple missing 1738 certificates, additional such CPS messages can be sent after getting 1739 a response to first one. However, the complete retrieval process may 1740 last at most CPS_RETRY_MAX seconds. 1742 Certification Path Solicitations SHOULD NOT be sent if the host has a 1743 currently valid certification path from a reachable router to a trust 1744 anchor. 1746 When soliciting certificates for a router, a host MUST send 1747 Certification Path Solicitations either to the All-Routers multicast 1748 address, if it has not selected a default router yet, or to the 1749 default router's IP address, if a default router has already been 1750 selected. 1752 If two hosts want to establish trust with the CPS and CPA messages, 1753 the CPS message SHOULD be sent to the Solicited-Node multicast 1754 address of the receiver. The advertisements SHOULD be sent as 1755 specified above for routers. However, the exact details are outside 1756 the scope of this specification. 1758 When processing possible advertisements sent as responses to a 1759 solicitation, the host MAY prefer to process first those 1760 advertisements with the same Identifier field value as in the 1761 solicitation. This makes Denial-of-Service attacks against the 1762 mechanism harder (see Section 9.3). 1764 6.5 Configuration 1766 End hosts are configured with a set of trust anchors for the purposes 1767 of protecting Router Discovery. A trust anchor configuration consists 1768 of the following items: 1770 o A public key signature algorithm and associated public key, which 1771 may optionally include parameters. 1773 o A name as described in Section 6.4.3. 1775 o An optional public key identifier. 1777 o An optional list of address ranges for which the trust anchor is 1778 authorized. 1780 If the host has been configured to use SEND, it SHOULD possess the 1781 above information for at least one trust anchor. 1783 Routers are configured with a collection of certification paths and a 1784 collection of certified keys and the certificates containing them, 1785 down to the key and certificate for the router itself. Certified keys 1786 are required for routers in order that a certification path can be 1787 established between the router's certificate and the public key of a 1788 trust anchor. 1790 If the router has been configured to use SEND, it should be 1791 configured with its own key pair and certificate, and at least one 1792 certification path. 1794 7. Addressing 1796 7.1 CGAs 1798 By default, a SEND-enabled node SHOULD use only CGAs for its own 1799 addresses. Other types of addresses MAY be used in testing, 1800 diagnostics or for other purposes. However, this document does not 1801 describe how to choose between different types of addresses for 1802 different communications. A dynamic selection can be provided by an 1803 API, such as the one defined in [24]. 1805 7.2 Redirect Addresses 1807 If the Target Address and Destination Address fields in the ICMP 1808 Redirect message are equal, then this message is used to inform hosts 1809 that a destination is in fact a neighbor. In this case the receiver 1810 MUST verify that the given address falls within the range defined by 1811 the router's certificate. Redirect messages failing this check MUST 1812 be treated as unsecured, as described in Section 7.3. 1814 Note that base NDP rules prevent a host from accepting a Redirect 1815 message from a router that the host is not using to reach the 1816 destination mentioned in the redirect. This prevents an attacker from 1817 tricking a node into redirecting traffic when the attacker is not the 1818 default router. 1820 7.3 Advertised Subnet Prefixes 1822 The router's certificate defines the address range(s) that it is 1823 allowed to advertise securely. A router MAY, however, advertise a 1824 combination of certified and uncertified subnet prefixes. Uncertified 1825 subnet prefixes are treated as unsecured, i.e., processed in the same 1826 way as unsecured router advertisements sent by non-SEND routers. The 1827 processing of unsecured messages is specified in Section 8. Note that 1828 SEND nodes that do not attempt to interoperate with non-SEND nodes 1829 MAY simply discard the unsecured information. 1831 Certified subnet prefixes fall into the following two categories: 1833 Constrained 1835 If the network operator wants to constrain which routers are 1836 allowed to route particular subnet prefixes, routers should be 1837 configured with certificates having subnet prefixes listed in the 1838 prefix extension. Routers so configured SHOULD advertise the 1839 subnet prefixes which they are certified to route, or a subset 1840 thereof. 1842 Unconstrained 1844 Network operators that do not want to constrain routers this way 1845 should configure routers with certificates containing either the 1846 null prefix or no prefix extension at all. 1848 Upon processing a Prefix Information option within a Router 1849 Advertisement, nodes SHOULD verify that the prefix specified in this 1850 option falls within the range defined by the certificate, if the 1851 certificate contains a prefix extension. Options failing this check 1852 are treated as containing uncertified subnet prefixes. 1854 Nodes SHOULD use one of the certified subnet prefixes for stateless 1855 autoconfiguration. If none of the advertised subnet prefixes match, 1856 the host SHOULD use a different advertising router as its default 1857 router, if available. If the node is performing stateful 1858 autoconfiguration, it SHOULD check the address provided by the DHCP 1859 server against the certified subnet prefixes and SHOULD NOT use the 1860 address if the prefix is not certified. 1862 7.4 Limitations 1864 This specification does not address the protection of NDP packets for 1865 nodes that are configured with a static address (e.g., PREFIX::1). 1866 Future certification path-based authorization specifications are 1867 needed for such nodes. This specification also does not apply to 1868 addresses generated by the IPv6 stateless address autoconfiguration 1869 using other fixed forms of interface identifiers (such as EUI-64) as 1870 a basis. 1872 It is outside the scope of this specification to describe the use of 1873 trust anchor authorization between nodes with dynamically changing 1874 addresses. Such dynamically changing addresses may be the result of 1875 stateful or stateless address autoconfiguration, or through the use 1876 of RFC 3041 [20] addresses. If the CGA method is not used, nodes are 1877 required to exchange certification paths that terminate in a 1878 certificate authorizing a node to use an IP address having a 1879 particular interface identifier. This specification does not specify 1880 the format of such certificates, since there are currently only a few 1881 cases where such certificates are provided by the link layer and it 1882 is up to the link layer to provide certification for the interface 1883 identifier. This may be the subject of a future specification. It 1884 is also outside the scope of this specification to describe how 1885 stateful address autoconfiguration works with the CGA method. 1887 The Target Address in Neighbor Advertisement is required to be equal 1888 to the source address of the packet, except in the case of proxy 1889 Neighbor Discovery. Proxy Neighbor Discovery is not supported by this 1890 specification. 1892 8. Transition Issues 1894 During the transition to secured links or as a policy consideration, 1895 network operators may want to run a particular link with a mixture of 1896 nodes accepting secured and unsecured messages. Nodes that support 1897 SEND SHOULD support the use of secured and unsecured NDP messages at 1898 the same time. 1900 In a mixed environment, SEND nodes receive both secured and unsecured 1901 messages but give priority to secured ones. Here, the "secured" 1902 messages are ones that contain a valid signature option, as specified 1903 above, and "unsecured" messages are ones that contain no signature 1904 option. 1906 A SEND node SHOULD have a configuration option that causes it to 1907 ignore all unsecured Neighbor Solicitation and Advertisement, Router 1908 Solicitation and Advertisement, and Redirect messages. This can be 1909 used to enforce SEND-only networks. The default for this 1910 configuration option SHOULD be that both secured and unsecured 1911 messages are allowed. 1913 A SEND node MAY also have a configuration option that causes it to 1914 disable the use of SEND completely, even for the messages it sends 1915 itself. The default for this configuration option SHOULD be off; that 1916 is, that SEND is used. Plain (non-SEND) NDP nodes will obviously send 1917 only unsecured messages. Per RFC 2461 [7], such nodes will ignore 1918 the unknown options and will treat secured messages in the same way 1919 as they treat unsecured ones. Secured and unsecured nodes share the 1920 same network resources, such as subnet prefixes and address spaces. 1922 SEND nodes configured to use SEND at least in their own messages 1923 behave in a mixed environment as is explained below. 1925 SEND adheres to the rules defined for the base NDP protocol with the 1926 following exceptions: 1928 o All solicitations sent by a SEND node MUST be secured. 1930 o Unsolicited advertisements sent by a SEND node MUST be secured. 1932 o A SEND node MUST send a secured advertisement in response to a 1933 secured solicitation. Advertisements sent in response to an 1934 unsecured solicitation MUST be secured as well, but MUST NOT 1935 contain the Nonce option. 1937 o A SEND node that uses the CGA authorization method for protecting 1938 Neighbor Solicitations SHOULD perform Duplicate Address Detection 1939 as follows. If Duplicate Address Detection indicates the 1940 tentative address is already in use, generate a new tentative CGA. 1941 If after 3 consecutive attempts no non-unique address was 1942 generated, log a system error and give up attempting to generate 1943 an address for that interface. 1945 When performing Duplicate Address Detection for the first 1946 tentative address, accept both secured and unsecured Neighbor 1947 Advertisements and Solicitations received as response to the 1948 Neighbor Solicitations. When performing Duplicate Address 1949 Detection for the second or third tentative address, ignore 1950 unsecured Neighbor Advertisements and Solicitations. (The security 1951 implications of this are discussed in Section 9.2.3 and [14].) 1953 o The node MAY have a configuration option that causes it to ignore 1954 unsecured advertisements even when performing Duplicate Address 1955 Detection for the first tentative address. This configuration 1956 option SHOULD be disabled by default. This is a recovery 1957 mechanism, in case attacks against the first address become 1958 common. 1960 o The Neighbor Cache, Prefix List and Default Router list entries 1961 MUST have a secured/unsecured flag that indicates whether the 1962 message that caused the creation or last update of the entry was 1963 secured or unsecured. Received unsecured messages MUST NOT cause 1964 changes to existing secured entries in the Neighbor Cache, Prefix 1965 List or Default Router List. The Neighbor Cache SHOULD implement a 1966 flag on entries indicating whether the entry is secured. Received 1967 secured messages MUST cause an update of the matching entries and 1968 flagging of them as secured. 1970 o Neighbor Solicitations for the purpose of Neighbor Unreachabilty 1971 Detection (NUD) MUST be sent to that neighbor's solicited-nodes 1972 multicast address, if the entry is not secured with SEND. 1974 Upper layer confirmations on unsecured neighbor cache entries 1975 SHOULD NOT update neighbor cache state from STALE to REACHABLE on 1976 a SEND node, if the neighbour cache entry has never previously 1977 been REACHABLE. This ensures that if an entry spoofing a valid 1978 SEND host is created by a non-SEND attacker without being 1979 solicited, NUD will be done within 5 seconds of use of the entry 1980 for data transmission. 1982 As a result, in mixed mode attackers can take over a Neighbor 1983 Cache entry of a SEND node for a longer time only if (a) the SEND 1984 node was not communicating with the victim node so that there is 1985 no secure entry for it and (b) the SEND node is not currently on 1986 the link (or is unable to respond). 1988 o The conceptual sending algorithm is modified so that an unsecured 1989 router is selected only if there is no reachable SEND router for 1990 the prefix. That is, the algorithm for selecting a default router 1991 favors reachable SEND routers over reachable non-SEND ones. 1993 o A node MAY adopt a router sending unsecured messages, or a router 1994 for which secured messages have been received, but for which full 1995 security checks have not yet been completed, while security 1996 checking is underway. Security checks in this case include 1997 certification path solicitation, certificate verification, CRL 1998 checks, and RA signature checks. A node MAY also adopt a router 1999 sending unsecured messages if a router known to be secured becomes 2000 unreachable, but SHOULD attempt to find a router known to be 2001 secured as soon as possible, since the unreachability may be the 2002 result of an attack. Note that while this can speed up attachment 2003 to a new network, accepting a router sending unsecured messages or 2004 for which security checks are not complete opens the node to 2005 possible attacks, and nodes that choose to accept such routers do 2006 so at their own risk. The node SHOULD in any case prefer a router 2007 known to be secure as soon as one is available with completed 2008 security checks. 2010 9. Security Considerations 2012 9.1 Threats to the Local Link Not Covered by SEND 2014 SEND does not provide confidentiality for NDP communications. 2016 SEND does not compensate for an unsecured link layer. For instance, 2017 there is no assurance that payload packets actually come from the 2018 same peer against which the NDP was run. 2020 There may be no cryptographic binding in SEND between the link layer 2021 frame address and the IPv6 address. On an unsecured link layer that 2022 allows nodes to spoof the link layer address of other nodes, an 2023 attacker could disrupt IP service by sending out a Neighbor 2024 Advertisement with the link layer source address on the frame being 2025 the source address of a victim, a valid CGA address and a valid 2026 signature corresponding to itself, and a Target Link-layer Address 2027 extension corresponding to the victim. The attacker could then 2028 proceed to cause a traffic stream to bombard the victim in a DoS 2029 attack. This attack cannot be prevented just by securing the link 2030 layer. 2032 Even on a secured link layer, SEND does not require that the 2033 addresses on the link layer and Neighbor Advertisements correspond to 2034 each other. However, it is RECOMMENDED that such checks be performed 2035 if the link layer technology permits. 2037 Prior to participating in Neighbor Discovery and Duplicate Address 2038 Detection, nodes must subscribe to the link-scoped All-Nodes 2039 Multicast Group and the Solicited-Node Multicast Group for the 2040 address that they are claiming for their addresses; RFC 2461 [7]. 2041 Subscribing to a multicast group requires that the nodes use MLD 2042 [19]. MLD contains no provision for security. An attacker could 2043 send an MLD Done message to unsubscribe a victim from the 2044 Solicited-Node Multicast address. However, the victim should be able 2045 to detect such an attack because the router sends a 2046 Multicast-Address-Specific Query to determine whether any listeners 2047 are still on the address, at which point the victim can respond to 2048 avoid being dropped from the group. This technique will work if the 2049 router on the link has not been compromised. Other attacks using MLD 2050 are possible, but they primarily lead to extraneous (but not 2051 overwhelming) traffic. 2053 9.2 How SEND Counters Threats to NDP 2055 The SEND protocol is designed to counter the threats to NDP, as 2056 outlined in [25]. The following subsections contain a regression of 2057 the SEND protocol against the threats, to illustrate what aspects of 2058 the protocol counter each threat. 2060 9.2.1 Neighbor Solicitation/Advertisement Spoofing 2062 This threat is defined in Section 4.1.1 of [25]. The threat is that 2063 a spoofed message may cause a false entry in a node's Neighbor Cache. 2064 There are two cases: 2066 1. Entries made as a side effect of a Neighbor Solicitation or 2067 Router Solicitation. A router receiving a Router Solicitation 2068 with a Target Link-Layer Address extension and the IPv6 source 2069 address not equal to the unspecified address inserts an entry for 2070 the IPv6 address into its Neighbor Cache. Also, a node performing 2071 Duplicate Address Detection (DAD) that receives a Neighbor 2072 Solicitation for the same address regards the situation as a 2073 collision and ceases to solicit for the address. 2075 In either case, SEND counters these treats by requiring the RSA 2076 Signature and CGA options to be present in such solicitations. 2078 SEND nodes can send Router Solicitation messages with a CGA 2079 source address and a CGA option, which the router can verify, so 2080 the Neighbor Cache binding is correct. If a SEND node must send 2081 a Router Solicitation with the unspecified address, the router 2082 will not update its Neighbor Cache, as per base NDP. 2084 2. Entries made as a result of a Neighbor Advertisement message. 2085 SEND counters this threat by requiring the RSA Signature and CGA 2086 options to be present in these advertisements. 2088 See also Section 9.2.5, below, for discussion about replay protection 2089 and timestamps. 2091 9.2.2 Neighbor Unreachability Detection Failure 2093 This attack is described in Section 4.1.2 of [25]. SEND counters 2094 this attack by requiring a node responding to Neighbor Solicitations 2095 sent as NUD probes to include an RSA Signature option and proof of 2096 authorization to use the interface identifier in the address being 2097 probed. If these prerequisites are not met, the node performing NUD 2098 discards the responses. 2100 9.2.3 Duplicate Address Detection DoS Attack 2102 This attack is described in Section 4.1.3 of [25]. SEND counters 2103 this attack by requiring the Neighbor Advertisements sent as 2104 responses to DAD to include an RSA Signature option and proof of 2105 authorization to use the interface identifier in the address being 2106 tested. If these prerequisites are not met, the node performing DAD 2107 discards the responses. 2109 When a SEND node is performing DAD, it may listen for address 2110 collisions from non-SEND nodes for the first address it generates, 2111 but not for new attempts. This protects the SEND node from DAD DoS 2112 attacks by non-SEND nodes or attackers simulating non-SEND nodes, at 2113 the cost of a potential address collision between a SEND node and a 2114 non-SEND node. The probability and effects of such an address 2115 collision are discussed in [14]. 2117 9.2.4 Router Solicitation and Advertisement Attacks 2119 These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6, 2120 and 4.2.7 of [25]. SEND counters these attacks by requiring Router 2121 Advertisements to contain an RSA Signature option, and that the 2122 signature is calculated using the public key of a node that can prove 2123 its authorization to route the subnet subnet prefixes contained in 2124 any Prefix Information Options. The router proves its authorization 2125 by showing a certificate containing the specific prefix or the 2126 indication that the router is allowed to route any prefix. A Router 2127 Advertisement without these protections is discarded. 2129 SEND does not protect against brute force attacks on the router, such 2130 as DoS attacks, or compromise of the router, as described in Sections 2131 4.4.2 and 4.4.3 of [25]. 2133 9.2.5 Replay Attacks 2135 This attack is described in Section 4.3.1 of [25]. SEND protects 2136 against attacks in Router Solicitation/Router Advertisement and 2137 Neighbor Solicitation/Neighbor Advertisement transactions by 2138 including a Nonce option in the solicitation and requiring the 2139 advertisement to include a matching option. Together with the 2140 signatures this forms a challenge-response protocol. 2142 SEND protects against attacks from unsolicited messages such as 2143 Neighbor Advertisements, Router Advertisements, and Redirects by 2144 including a Timestamp option. The following security issues are 2145 relevant only for unsolicited messages: 2147 o A window of vulnerability for replay attacks exists until the 2148 timestamp expires. 2150 However, such vulnerabilities are only useful for attackers if the 2151 advertised parameters change during the window. While some 2152 parameters (such as the remaining lifetime of a prefix) change 2153 often, radical changes typically happen only in the context of 2154 some special case, such as switching to a new link layer address 2155 due to a broken interface adapter. 2157 SEND nodes are also protected against replay attacks as long as 2158 they cache the state created by the message containing the 2159 timestamp. The cached state allows the node to protect itself 2160 against replayed messages. However, once the node flushes the 2161 state for whatever reason, an attacker can re-create the state by 2162 replaying an old message while the timestamp is still valid. 2163 Since most SEND nodes are likely to use fairly coarse grained 2164 timestamps, as explained in Section 5.3.1, this may affect some 2165 nodes. 2167 o Attacks against time synchronization protocols such as NTP [26] 2168 may cause SEND nodes to have an incorrect timestamp value. This 2169 can be used to launch replay attacks even outside the normal 2170 window of vulnerability. To protect against such attacks, it is 2171 recommended that SEND nodes keep independently maintained clocks, 2172 or apply suitable security measures for the time synchronization 2173 protocols. 2175 9.2.6 Neighbor Discovery DoS Attack 2177 This attack is described in Section 4.3.2 of [25]. In this attack, 2178 the attacker bombards the router with packets for fictitious 2179 addresses on the link, causing the router to busy itself with 2180 performing Neighbor Solicitations for addresses that do not exist. 2181 SEND does not address this threat because it can be addressed by 2182 techniques such as rate limiting Neighbor Solicitations, restricting 2183 the amount of state reserved for unresolved solicitations, and clever 2184 cache management. These are all techniques involved in implementing 2185 Neighbor Discovery on the router. 2187 9.3 Attacks against SEND Itself 2189 The CGAs have a 59-bit hash value. The security of the CGA mechanism 2190 has been discussed in [14]. 2192 Some Denial-of-Service attacks against NDP and SEND itself remain. 2193 For instance, an attacker may try to produce a very high number of 2194 packets that a victim host or router has to verify using asymmetric 2195 methods. While safeguards are required to prevent an excessive use 2196 of resources, this can still render SEND non-operational. 2198 When CGA protection is used, SEND deals with the DoS attacks using 2199 the verification process described in Section 5.2.2. In this process, 2200 a simple hash verification of the CGA property of the address is 2201 performed before performing the more expensive signature 2202 verification. However, even if the CGA verification succeeds, no 2203 claims about the validity of the message can be made, until the 2204 signature has been checked. 2206 When trust anchors and certificates are used for address validation 2207 in SEND, the defenses are not quite as effective. Implementations 2208 SHOULD track the resources devoted to the processing of packets 2209 received with the RSA Signature option, and start selectively 2210 discarding packets if too many resources are spent. Implementations 2211 MAY also first discard packets that are not protected with CGA. 2213 The Authorization Delegation Discovery process may also be vulnerable 2214 to Denial-of-Service attacks. An attack may target a router by 2215 requesting a large number of certification paths to be discovered for 2216 different trust anchors. Routers SHOULD defend against such attacks 2217 by caching discovered information (including negative responses) and 2218 by limiting the number of different discovery processes in which they 2219 engage. 2221 Attackers may also target hosts by sending a large number of 2222 unnecessary certification paths, forcing hosts to spend useless 2223 memory and verification resources for them. Hosts can defend against 2224 such attacks by limiting the amount of resources devoted to the 2225 certification paths and their verification. Hosts SHOULD also 2226 prioritize advertisements sent as a response to solicitations the 2227 hosts have sent above unsolicited advertisements. 2229 10. Protocol Values 2231 10.1 Constants 2233 Host constants: 2235 CPS_RETRY 1 second 2236 CPS_RETRY_FRAGMENTS 2 seconds 2237 CPS_RETRY_MAX 15 seconds 2239 Router constants: 2241 MAX_CPA_RATE 10 times per second 2243 10.2 Variables 2245 TIMESTAMP_DELTA 300 seconds (5 minutes) 2246 TIMESTAMP_FUZZ 1 second 2247 TIMESTAMP_DRIFT 1 % (0.01) 2249 11. IANA Considerations 2251 This document defines two new ICMP message types, used in 2252 Authorization Delegation Discovery. These messages must be assigned 2253 ICMPv6 type numbers from the informational message range: 2255 o The Certification Path Solicitation message, described in Section 2256 6.4.1. 2258 o The Certification Path Advertisement message, described in Section 2259 6.4.2. 2261 This document defines six new Neighbor Discovery Protocol [7] 2262 options, which must be assigned Option Type values within the option 2263 numbering space for Neighbor Discovery Protocol messages: 2265 o The CGA option, described in Section 5.1. 2267 o The RSA Signature option, described in Section 5.2. 2269 o The Timestamp option, described in Section 5.3.1. 2271 o The Nonce option, described in Section 5.3.2. 2273 o The Trust Anchor option, described in Section 6.4.3. 2275 o The Certificate option, described in Section 6.4.4. 2277 This document defines a new 128-bit value under the CGA Message Type 2278 [14] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08. 2280 This document defines a new name space for the Name Type field in the 2281 Trust Anchor option. Future values of this field can be allocated 2282 using Standards Action [6]. The current values for this field are: 2284 1 DER Encoded X.501 Name 2286 2 FQDN 2288 Another new name space is allocated for the Cert Type field in the 2289 Certificate option. Future values of this field can be allocated 2290 using Standards Action [6]. The current values for this field are: 2292 1 X.509v3 Certificate 2294 Normative References 2296 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 2297 13, RFC 1034, November 1987. 2299 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2300 Levels", BCP 14, RFC 2119, March 1997. 2302 [3] Kent, S. and R. Atkinson, "Security Architecture for the 2303 Internet Protocol", RFC 2401, November 1998. 2305 [4] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 2306 November 1998. 2308 [5] Piper, D., "The Internet IP Security Domain of Interpretation 2309 for ISAKMP", RFC 2407, November 1998. 2311 [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2312 Considerations Section in RFCs", BCP 26, RFC 2434, October 2313 1998. 2315 [7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 2316 for IP Version 6 (IPv6)", RFC 2461, December 1998. 2318 [8] Thomson, S. and T. Narten, "IPv6 Stateless Address 2319 Autoconfiguration", RFC 2462, December 1998. 2321 [9] Conta, A. and S. Deering, "Internet Control Message Protocol 2322 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 2323 Specification", RFC 2463, December 1998. 2325 [10] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 2326 Public Key Infrastructure Certificate and Certificate 2327 Revocation List (CRL) Profile", RFC 3280, April 2002. 2329 [11] Farrell, S. and R. Housley, "An Internet Attribute Certificate 2330 Profile for Authorization", RFC 3281, April 2002. 2332 [12] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing 2333 Domain Names in Applications (IDNA)", RFC 3490, March 2003. 2335 [13] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP 2336 Addresses and AS Identifiers", 2337 draft-ietf-pkix-x509-ipaddr-as-extn-03 (work in progress), 2338 September 2003. 2340 [14] Aura, T., "Cryptographically Generated Addresses (CGA)", 2341 draft-ietf-send-cga-06 (work in progress), April 2004. 2343 [15] International Telecommunications Union, "Information Technology 2344 - ASN.1 encoding rules: Specification of Basic Encoding Rules 2345 (BER), Canonical Encoding Rules (CER) and Distinguished 2346 Encoding Rules (DER)", ITU-T Recommendation X.690, July 2002. 2348 [16] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS 2349 1, November 2002. 2351 [17] National Institute of Standards and Technology, "Secure Hash 2352 Standard", FIPS PUB 180-1, April 1995, . 2355 Informative References 2357 [18] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 2358 RFC 2409, November 1998. 2360 [19] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener 2361 Discovery (MLD) for IPv6", RFC 2710, October 1999. 2363 [20] Narten, T. and R. Draves, "Privacy Extensions for Stateless 2364 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 2366 [21] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 2367 Carney, "Dynamic Host Configuration Protocol for IPv6 2368 (DHCPv6)", RFC 3315, July 2003. 2370 [22] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies", 2371 draft-arkko-icmpv6-ike-effects-02 (work in progress), March 2372 2003. 2374 [23] Arkko, J., "Manual SA Configuration for IPv6 Link Local 2375 Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress), 2376 June 2002. 2378 [24] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API 2379 for Address Selection", draft-chakrabarti-ipv6-addrselect-02 2380 (work in progress), October 2003. 2382 [25] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 2383 Discovery trust models and threats", draft-ietf-send-psreq-04 2384 (work in progress), October 2003. 2386 [26] Bishop, M., "A Security Analysis of the NTP Protocol", Sixth 2387 Annual Computer Security Conference Proceedings, December 1990. 2389 Authors' Addresses 2391 Jari Arkko 2392 Ericsson 2394 Jorvas 02420 2395 Finland 2397 EMail: jari.arkko@ericsson.com 2398 James Kempf 2399 DoCoMo Communications Labs USA 2400 181 Metro Drive 2401 San Jose, CA 94043 2402 USA 2404 EMail: kempf@docomolabs-usa.com 2406 Bill Sommerfeld 2407 Sun Microsystems 2408 1 Network Drive UBUR02-212 2409 Burlington, MA 01803 2410 USA 2412 EMail: sommerfeld@east.sun.com 2414 Brian Zill 2415 Microsoft 2417 USA 2419 EMail: bzill@microsoft.com 2421 Pekka Nikander 2422 Ericsson 2424 Jorvas 02420 2425 Finland 2427 EMail: Pekka.Nikander@nomadiclab.com 2429 Appendix A. Contributors and Acknowledgments 2431 Tuomas Aura contributed the transition mechanism specification in 2432 Section 8. Jonathan Trostle contributed the certification path 2433 example in Section 6.3.1. 2435 The authors would also like to thank Tuomas Aura, Erik Nordmark, 2436 Gabriel Montenegro, Pasi Eronen, Greg Daley, Jon Wood, Julien 2437 Laganier, Francis Dupont, Pekka Savola, Wenxiao He, Valtteri Niemi, 2438 Mike Roe, Russ Housley, Thomas Narten, and Steven Bellovin for 2439 interesting discussions in this problem space and feedback regarding 2440 the SEND protocol. 2442 Appendix B. Cache Management 2444 In this section we outline a cache management algorithm that allows a 2445 node to remain partially functional even under a cache filling DoS 2446 attack. This appendix is informational, and real implementations 2447 SHOULD use different algorithms in order to avoid the dangers of 2448 mono-cultural code. 2450 There are at least two distinct cache related attack scenarios: 2452 1. There are a number of nodes on a link, and someone launches a 2453 cache filling attack. The goal here is to make sure that the 2454 nodes can continue to communicate even if the attack is going on. 2456 2. There is already a cache filling attack going on, and a new node 2457 arrives to the link. The goal here is to make it possible for 2458 the new node to become attached to the network, in spite of the 2459 attack. 2461 Since the intent is to limit the damage to existing, valid cache 2462 entries, it is clearly better to be very selective in how to throw 2463 out entries. Reducing the timestamp Delta value is very 2464 discriminatory against those nodes that have a large clock 2465 difference, since an attacker can reduce its clock difference 2466 arbitrarily. Throwing out old entries just because their clock 2467 difference is large therefore seems like a bad approach. 2469 A reasonable idea seems to be to have a separate cache space for new 2470 entries and old entries, and under an attack more eagerly drop new 2471 cache entries than old ones. One could track traffic, and only allow 2472 those new entries that receive genuine traffic to be converted into 2473 old cache entries. While such a scheme can make attacks harder, it 2474 will not fully prevent them. For example, an attacker could send a 2475 little traffic (i.e. a ping or TCP syn) after each NS to trick the 2476 victim into promoting its cache entry to the old cache. To counter 2477 this, the node can be more intelligent in keeping its cache entries, 2478 and not just have a black/white old/new boundary. 2480 Consideration of the Sec parameter from the CGA Parameters when 2481 forcing cache entries out - by keeping entries with larger Sec 2482 parameters preferentially - also appears to be a possible approach, 2483 since CGAs with higher Sec parameters are harder to spoof. 2485 Appendix C. Message Size When Carrying Certificates 2487 In one example scenario using SEND, an Authorization Delegation 2488 Discovery test run was made using a certification path length of 2489 four. Three certificates are sent using Certification Path 2490 Advertisement messages, since the trust anchor's certificate is 2491 already known by both parties. With a key length of 1024 bits, the 2492 certificate lengths in the test run ranged from 864 to 888 bytes; the 2493 variation is due to the differences in the certificate issuer names 2494 and address prefix extensions. The different certificates had between 2495 one to four address prefix extensions. 2497 The three Certification Path Advertisement messages ranged from 1050 2498 to 1066 bytes on an Ethernet link layer. The certificate itself 2499 accounts for the bulk of the packet. The rest is the trust anchor 2500 option, ICMP header, IPv6 header, and link layer header. 2502 Intellectual Property Statement 2504 The IETF takes no position regarding the validity or scope of any 2505 intellectual property or other rights that might be claimed to 2506 pertain to the implementation or use of the technology described in 2507 this document or the extent to which any license under such rights 2508 might or might not be available; neither does it represent that it 2509 has made any effort to identify any such rights. Information on the 2510 IETF's procedures with respect to rights in standards-track and 2511 standards-related documentation can be found in BCP-11. Copies of 2512 claims of rights made available for publication and any assurances of 2513 licenses to be made available, or the result of an attempt made to 2514 obtain a general license or permission for the use of such 2515 proprietary rights by implementors or users of this specification can 2516 be obtained from the IETF Secretariat. 2518 The IETF invites any interested party to bring to its attention any 2519 copyrights, patents or patent applications, or other proprietary 2520 rights which may cover technology that may be required to practice 2521 this standard. Please address the information to the IETF Executive 2522 Director. 2524 The IETF has been notified of intellectual property rights claimed in 2525 regard to some or all of the specification contained in this 2526 document. For more information consult the online list of claimed 2527 rights. 2529 Full Copyright Statement 2531 Copyright (C) The Internet Society (2004). All Rights Reserved. 2533 This document and translations of it may be copied and furnished to 2534 others, and derivative works that comment on or otherwise explain it 2535 or assist in its implementation may be prepared, copied, published 2536 and distributed, in whole or in part, without restriction of any 2537 kind, provided that the above copyright notice and this paragraph are 2538 included on all such copies and derivative works. However, this 2539 document itself may not be modified in any way, such as by removing 2540 the copyright notice or references to the Internet Society or other 2541 Internet organizations, except as needed for the purpose of 2542 developing Internet standards in which case the procedures for 2543 copyrights defined in the Internet Standards process must be 2544 followed, or as required to translate it into languages other than 2545 English. 2547 The limited permissions granted above are perpetual and will not be 2548 revoked by the Internet Society or its successors or assignees. 2550 This document and the information contained herein is provided on an 2551 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2552 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2553 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2554 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2555 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2557 Acknowledgment 2559 Funding for the RFC Editor function is currently provided by the 2560 Internet Society.