idnits 2.17.1 draft-ietf-send-ndopt-04.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 (February 16, 2004) is 7374 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 2013, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 2016, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2019, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 2054, 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 3490 (ref. '11') (Obsoleted by RFC 5890, RFC 5891) == Outdated reference: A later version (-06) exists of draft-ietf-send-cga-03 -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '16') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '18') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3281 (ref. '19') (Obsoleted by RFC 5755) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '20') (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: 10 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Neighbor Discovery Working J. Arkko, Editor 3 Group Ericsson 4 Internet-Draft J. Kempf 5 Expires: August 16, 2004 DoCoMo Communications Labs USA 6 B. Sommerfeld 7 Sun Microsystems 8 B. Zill 9 Microsoft 10 P. Nikander 11 Ericsson 12 February 16, 2004 14 SEcure Neighbor Discovery (SEND) 15 draft-ietf-send-ndopt-04 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at http:// 33 www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 16, 2004. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). All Rights Reserved. 44 Abstract 46 IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover 47 other nodes on the link, to determine the link-layer addresses of 48 other nodes on the link, to find routers, and to maintain 49 reachability information about the paths to active neighbors. If not 50 secured, NDP is vulnerable to various attacks. This document 51 specifies security mechanisms for NDP. Unlike to the original NDP 52 specifications, these mechanisms do not make use of IPsec. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1 Specification of Requirements . . . . . . . . . . . . 4 58 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Neighbor and Router Discovery Overview . . . . . . . . . . . 7 60 4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 9 61 5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 11 62 5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . .11 63 5.1.1 Processing Rules for Senders . . . . . . . . . 12 64 5.1.2 Processing Rules for Receivers . . . . . . . . 13 65 5.1.3 Configuration . . . . . . . . . . . . . . . . 14 66 5.2 Signature Option . . . . . . . . . . . . . . . . . . .15 67 5.2.1 Processing Rules for Senders . . . . . . . . . 17 68 5.2.2 Processing Rules for Receivers . . . . . . . . 17 69 5.2.3 Configuration . . . . . . . . . . . . . . . . 18 70 5.2.4 Performance Considerations . . . . . . . . . . 19 71 5.3 Timestamp and Nonce options . . . . . . . . . . . . .20 72 5.3.1 Timestamp Option . . . . . . . . . . . . . . . 20 73 5.3.2 Nonce Option . . . . . . . . . . . . . . . . . 21 74 5.3.3 Processing rules for senders . . . . . . . . . 21 75 5.3.4 Processing rules for receivers . . . . . . . . 22 76 6. Authorization Delegation Discovery . . . . . . . . . . . . . 25 77 6.1 Certificate Format . . . . . . . . . . . . . . . . . .25 78 6.1.1 Router Authorization Certificate Profile . . . 25 79 6.2 Certificate Transport . . . . . . . . . . . . . . . .28 80 6.2.1 Delegation Chain Solicitation Message Format . 28 81 6.2.2 Delegation Chain Advertisement Message Format 30 82 6.2.3 Trust Anchor Option . . . . . . . . . . . . . 32 83 6.2.4 Certificate Option . . . . . . . . . . . . . . 34 84 6.2.5 Processing Rules for Routers . . . . . . . . . 35 85 6.2.6 Processing Rules for Hosts . . . . . . . . . . 36 86 7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 38 87 7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . .38 88 7.2 Redirect Addresses . . . . . . . . . . . . . . . . . .38 89 7.3 Advertised Prefixes . . . . . . . . . . . . . . . . .38 90 7.4 Limitations . . . . . . . . . . . . . . . . . . . . .39 91 8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 41 92 9. Security Considerations . . . . . . . . . . . . . . . . . . 43 93 9.1 Threats to the Local Link Not Covered by SEND . . . .43 94 9.2 How SEND Counters Threats to NDP . . . . . . . . . . .43 95 9.2.1 Neighbor Solicitation/Advertisement Spoofing . 44 96 9.2.2 Neighbor Unreachability Detection Failure . . 44 97 9.2.3 Duplicate Address Detection DoS Attack . . . . 44 98 9.2.4 Router Solicitation and Advertisement Attacks 45 99 9.2.5 Replay Attacks . . . . . . . . . . . . . . . . 45 100 9.2.6 Neighbor Discovery DoS Attack . . . . . . . . 46 101 9.3 Attacks against SEND Itself . . . . . . . . . . . . .46 102 10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 48 103 11. Protocol Variables . . . . . . . . . . . . . . . . . . . . . 49 104 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 50 105 Normative References . . . . . . . . . . . . . . . . . . . . 51 106 Informative References . . . . . . . . . . . . . . . . . . . 53 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53 108 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 55 109 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 56 110 C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 57 111 Intellectual Property and Copyright Statements . . . . . . . 58 113 1. Introduction 115 IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7] 116 and 2462 [8]. Nodes on the same link use NDP to discover each 117 other's presence, to determine each other's link-layer addresses, to 118 find routers, and to maintain reachability information about the 119 paths to active neighbors. NDP is used both by hosts and routers. 120 Its functions include Neighbor Discovery (ND), Router Discovery (RD), 121 Address Autoconfiguration, Address Resolution, Neighbor 122 Unreachability Detection (NUD), Duplicate Address Detection (DAD), 123 and Redirection. 125 The original NDP specifications called for the use of IPsec to 126 protect NDP messages. However, the RFCs do not give detailed 127 instructions for using IPsec for this. In this particular 128 application, IPsec can only be used with a manual configuration of 129 security associations, due to bootstrapping problems in using IKE 130 [21, 16]. Furthermore, the number of such manually configured 131 security associations needed for protecting NDP can be very large 132 [22], making that approach impractical for most purposes. 134 This document is organized as follows. Section 2 and Section 3 135 define some terminology and present a brief review of NDP, 136 respectively. Section 4 describes the overall approach to securing 137 NDP. This approach involves the use of new NDP options to carry 138 public-key based signatures. A zero-configuration mechanism is used 139 for showing address ownership on individual nodes; routers are 140 certified by a trust anchor [10]. The formats, procedures, and 141 cryptographic mechanisms for the zero-configuration mechanism are 142 described in a related specification [13]. 144 The required new NDP options are discussed in Section 5. Section 6 145 describes the mechanism for distributing certificate chains to 146 establish an authorization delegation chain to a common trust anchor. 148 Finally, Section 8 discusses the co-existence of secure and 149 non-secure NDP on the same link and Section 9 discusses security 150 considerations for Secure Neighbor Discovery (SEND). 152 1.1 Specification of Requirements 154 In this document, several words are used to signify the requirements 155 of the specification. These words are often capitalized. The key 156 words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and 157 "MAY" in this document are to be interpreted as described in [2]. 159 2. Terms 161 Authorization Delegation Discovery (ADD) 163 A process through which SEND nodes can acquire a certificate chain 164 from a peer node to a trust anchor. 166 Cryptographically Generated Address (CGA) 168 A technique [13] whereby an IPv6 address of a node is 169 cryptographically generated using a one-way hash function from the 170 node's public key and some other parameters. 172 Duplicate Address Detection (DAD) 174 A mechanism which assures that two IPv6 nodes on the same link are 175 not using the same address. 177 Neighbor Discovery Protocol (NDP) 179 The IPv6 Neighbor Discovery Protocol [7, 8]. 181 Neighbor Discovery Protocol is a part of ICMPv6 [9]. 183 Neighbor Discovery (ND) 185 The Neighbor Discovery function of the Neighbor Discovery Protocol 186 (NDP). NDP contains also other functions besides ND. 188 Neighbor Unreachability Detection (NUD) 190 A mechanism used for tracking the reachability of neighbors. 192 Nonce 194 An unpredictable random or pseudorandom number generated by a node 195 and used exactly once. In SEND, nonces are used to assure that a 196 particular advertisement is linked to the solicitation that 197 triggered it. 199 Router Authorization Certificate 201 An X.509v3 [10] public key certificate using the profile specified 202 in Section 6.1.1. 204 SEND node 206 An IPv6 node that implements this specification. 208 Non-SEND node 210 An IPv6 node that does not implement this specification but uses 211 only RFC 2461 and RFC 2462 without security. 213 Router Discovery (RD) 215 Router Discovery allows the hosts to discover what routers exist 216 on the link, and what prefixes are available. Router Discovery is 217 a part of the Neighbor Discovery Protocol. 219 3. Neighbor and Router Discovery Overview 221 The Neighbor Discovery Protocol has several functions. Many of these 222 functions are overloaded on a few central message types, such as the 223 ICMPv6 Neighbor Advertisement message. In this section we review 224 some of these tasks and their effects in order to understand better 225 how the messages should be treated. This section is not normative, 226 and if this section and the original Neighbor Discovery RFCs are in 227 conflict, the original RFCs take precedence. 229 The main functions of NDP are the following. 231 o The Router Discovery function allows IPv6 hosts to discover the 232 local routers on an attached link. Router Discovery is described 233 in Section 6 of RFC 2461 [7]. The main purpose of Router 234 Discovery is to find neighboring routers that are willing to 235 forward packets on behalf of hosts. Prefix discovery involves 236 determining which destinations are directly on a link; this 237 information is necessary in order to know whether a packet should 238 be sent to a router or directly to the destination node. 240 o The Redirect function is used for automatically redirecting a host 241 to a better first-hop router, or to inform hosts that a 242 destination is in fact a neighbor (i.e., on-link). Redirect is 243 specified in Section 8 of RFC 2461 [7]. 245 o Address Autoconfiguration is used for automatically assigning 246 addresses to a host [8]. This allows hosts to operate without 247 explicit configuration related to IP connectivity. The default 248 autoconfiguration mechanism is stateless. To create IP addresses, 249 hosts use any prefix information delivered to them during Router 250 Discovery, and then test the newly formed addresses for 251 uniqueness. A stateful mechanism, DHCPv6 [20], provides 252 additional autoconfiguration features. 254 o Duplicate Address Detection (DAD) is used for preventing address 255 collisions [8], for instance during Address Autoconfiguration. A 256 node that intends to assign a new address to one of its interfaces 257 first runs the DAD procedure to verify that there is no other node 258 using the same address. Since the rules forbid the use of an 259 address until it has been found unique, no higher layer traffic is 260 possible until this procedure has been completed. Thus, 261 preventing attacks against DAD can help ensure the availability of 262 communications for the node in question. 264 o The Address Resolution function allows a node on the link to 265 resolve another node's IPv6 address to the corresponding 266 link-layer address. Address Resolution is defined in Section 7.2 267 of RFC 2461 [7], and it is used for hosts and routers alike. 268 Again, no higher level traffic can proceed until the sender knows 269 the link layer address of the destination node or the next hop 270 router. Note the source link layer address on link layer frames 271 is not checked against the information learned through Address 272 Resolution. This allows for an easier addition of network 273 elements such as bridges and proxies, and eases the stack 274 implementation requirements as less information needs to be passed 275 from layer to layer. 277 o Neighbor Unreachability Detection (NUD) is used for tracking the 278 reachability of neighboring nodes, both hosts and routers. NUD is 279 defined in Section 7.3 of RFC 2461 [7]. NUD is 280 security-sensitive, because an attacker could falsely claim that 281 reachability exists when it in fact does not. 283 The NDP messages follow the ICMPv6 message format. All NDP functions 284 are realized using the Router Solicitation (RS), Router Advertisement 285 (RA), Neighbor Solicitation (NS), Neighbor Advertisement (NA), and 286 Redirect messages. An actual NDP message includes an NDP message 287 header, consisting of an ICMPv6 header and ND message-specific data, 288 and zero or more NDP options. The NDP message options are formatted 289 in the Type-Length-Value format. 291 <------------NDP Message----------------> 292 *-------------------------------------------------------------* 293 | IPv6 Header | ICMPv6 | ND Message- | ND Message | 294 | Next Header = 58 | Header | specific | Options | 295 | (ICMPv6) | | data | | 296 *-------------------------------------------------------------* 297 <--NDP Message header--> 299 4. Secure Neighbor Discovery Overview 301 To secure the various functions in NDP, a set of new Neighbor 302 Discovery options is introduced. They are used to protect NDP 303 messages. This specification introduces these options, an 304 authorization delegation discovery process, an address ownership 305 proof mechanism, and requirements for the use of these components in 306 NDP. 308 The components of the solution specified in this document are as 309 follows: 311 o Certificate chains, anchored on trusted parties, are expected to 312 certify the authority of routers. A host and a router must have 313 at least one common trust anchor before the host can adopt the 314 router as its default router. Delegation Chain Solicitation and 315 Advertisement messages are used to discover a certificate chain to 316 the trust anchor without requiring the actual Router Discovery 317 messages to carry lengthy certificate chains. The receipt of a 318 protected Router Advertisement message for which no certificate 319 chain is available triggers the authorization delegation discovery 320 process. 322 o Cryptographically Generated Addresses are used to assure that the 323 sender of a Neighbor Discovery message is the "owner" of the 324 claimed address. A public-private key pair is generated by all 325 nodes before they can claim an address. A new NDP option, the CGA 326 option, is used to carry the public key and associated parameters. 328 This specification also allows a node to use non-CGAs with 329 certificates to authorize their use. However, the details of such 330 use are beyond the scope of this specification. 332 o A new NDP option, the Signature option, is used to protect all 333 messages relating to Neighbor and Router discovery. 335 Public key signatures protect the integrity of the messages and 336 authenticate the identity of their sender. The authority of a 337 public key is established either with the authorization delegation 338 process, using certificates, or through the address ownership 339 proof mechanism, using CGAs, or both, depending on configuration 340 and the type of the message protected. 342 o In order to prevent replay attacks, two new Neighbor Discovery 343 options, Timestamp and Nonce, are introduced. Given that Neighbor 344 and Router Discovery messages are in some cases sent to multicast 345 addresses, the Timestamp option offers replay protection without 346 any previously established state or sequence numbers. When the 347 messages are used in solicitation - advertisement pairs, they are 348 protected using the Nonce option. 350 5. Neighbor Discovery Protocol Options 352 The options described in this section MUST be supported by all SEND 353 nodes. 355 5.1 CGA Option 357 The CGA option allows the verification of the sender's CGA. The 358 format of the CGA option is described as follows. 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Type | Length | Collision Cnt | Reserved | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | | 366 | Modifier | 367 | | 368 | | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | | 371 . . 372 . Key Information . 373 . . 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | 377 . . 378 . Padding . 379 . . 380 | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Type 385 TBD . 387 Length 389 The length of the option (including the Type, Length, Collision 390 Cnt, Reserved, Modifier, Key Information, and Padding fields) in 391 units of 8 octets. 393 Collision Cnt 395 An 8-bit collision count, which can be 0, 1 or 2. Its semantics 396 are defined in [13]. 398 Reserved 400 An 8-bit field reserved for future use. The value MUST be 401 initialized to zero by the sender, and MUST be ignored by the 402 receiver. 404 Modifier 406 A random 128-bit number used in CGA generation. Its semantics are 407 defined in [13]. 409 Key Information 411 A variable length field containing the public key of the sender, 412 represented as an ASN.1 type SubjectPublicKeyInfo [10], encoded as 413 described in Section 4 of [13]. 415 This specification requires that if both the CGA option and the 416 Signature option are present, then the publicKey field in the CGA 417 option MUST be the public key referred by the Key Hash field in 418 the Signature option. Packets received with two different keys 419 MUST be silently discarded. Note that a future extension may 420 provide a mechanism which allows the owner of an address and the 421 signer to be different parties. 423 The length of the Key Information field is determined by the ASN.1 424 encoding. 426 Padding 428 A variable length field making the option length a multiple of 8, 429 beginning after the ASN.1 encoding of the previous field ends, and 430 continuing to the end of the option, as specified by the Length 431 field. 433 5.1.1 Processing Rules for Senders 435 The CGA option MUST be present in all Neighbor Solicitation and 436 Advertisement messages, and MUST be present in Router Solicitation 437 messages unless they are sent with the unspecified source address. 438 The CGA option MAY be present in other messages. 440 A node sending a message using the CGA option MUST construct the 441 message as follows. 443 The Modifier, Collision Cnt, and Key Information fields in the CGA 444 option are filled in according to the rules presented above and in 446 [13]. The public key in the Key Information field is taken from the 447 node's configuration used to generate the CGA; typically from a data 448 structure associated with the source address. The address MUST be 449 constructed as specified in Section 4 of [13]. Depending on the type 450 of the message, this address appears in different places: 452 Redirect 454 The address MUST be the source address of the message. 456 Neighbor Solicitation 458 The address MUST be the Target Address for solicitations sent for 459 Duplicate Address Detection, and the source address of the message 460 otherwise. 462 Neighbor Advertisement 464 The address MUST be the source address of the message. 466 Router Solicitation 468 The address MUST be the source address of the message. Note that 469 the CGA option is not used when the source address is the 470 unspecified address. 472 Router Advertisement 474 The address MUST be the source address of the message. 476 5.1.2 Processing Rules for Receivers 478 Neighbor Solicitation and Advertisement messages without the CGA 479 option MUST be treated as insecure, i.e., processed in the same way 480 as NDP messages sent by a non-SEND node. The processing of insecure 481 messages is specified in Section 8. Note that SEND nodes that do not 482 attempt to interoperate with non-SEND nodes MAY simply discard the 483 insecure messages. 485 Router Solicitation messages without the CGA option MUST be also 486 treated as insecure, unless the source address of the message is the 487 unspecified address. 489 A message containing a CGA option MUST be checked as follows: 491 If the interface has been configured to use CGA, the receiving 492 node MUST verify the source address of the packet using the 493 algorithm described in Section 5 of [13]. The inputs to the 494 algorithm are the claimed address, as defined in the previous 495 section, and the concatenation from left to right of the following 496 data: the contents of the 8-octet Modifier field, the 8-octet 497 subnet-prefix part of the claimed address, the content of the 498 1-octet Collision Cnt field, and contents of the variable-length 499 Key Information Field. 501 If the CGA verification is successful, the recipient proceeds with 502 the cryptographically more time consuming check of the signature. 503 However, even if the CGA verification succeeds, no claims about 504 the validity of the use can be made, until the signature has been 505 checked. 507 Note that a receiver that does not support CGA or has not specified 508 its use for a given interface can still verify packets using trust 509 anchors, even if a CGA is used on a packet. In such a case, the CGA 510 property of the address is simply left unverified. 512 5.1.3 Configuration 514 All nodes that support the verification of the CGA option MUST record 515 the following configuration information: 517 minbits 519 The minimum acceptable key length for public keys used in the 520 generation of CGAs. The default SHOULD be 1024 bits. 521 Implementations MAY also set an upper limit in order to limit the 522 amount of computation they need to perform when verifying packets 523 that use these security associations. The upper limit SHOULD be 524 at least 2048 bits. Any implementation should follow prudent 525 cryptographic practice in determining the appropriate key lengths. 527 minSec 529 The minimum acceptable Sec value, if CGA verification is required. 530 This parameter is intended to facilitate future extensions and 531 experimental work. Currently, the minSec value SHOULD always be 532 set to zero. 534 See Section 2 in [13]. 536 All nodes that support the sending of the CGA option MUST record the 537 following configuration information: 539 CGA parameters 541 Any information required to construct CGAs, including the used Sec 542 and Modifier values, and the CGA address itself. 544 5.2 Signature Option 546 The Signature option allows public-key based signatures to be 547 attached to NDP messages. Configured trust anchors, CGAs, or both 548 are supported as the trusted root. The format of the Signature 549 option is described in the following diagram: 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Type | Length | Pad Length | Reserved | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | | 557 | Key Hash | 558 | | 559 | | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | | 562 . . 563 . Digital Signature . 564 . . 565 | | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | | 568 . . 569 . Padding . 570 . . 571 | | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Type 576 TBD . 578 Length 580 The length of the option (including the Type, Length, Pad Length, 581 Reserved, Key Hash, Digital Signature, and Padding fields) in 582 units of 8 octets. 584 Pad Length 586 An 8-bit integer field, giving the length of the Pad field in 587 units of an octet. 589 Reserved 591 An 8-bit field reserved for future use. The value MUST be 592 initialized to zero by the sender, and MUST be ignored by the 593 receiver. 595 Key Hash 597 A 128-bit field containing the most significant (leftmost) 598 128-bits of a SHA-1 hash of the public key used for constructing 599 the signature. The SHA-1 hash is taken over the presentation used 600 in the Key Information field of the CGA option. Its purpose is to 601 associate the signature to a particular key known by the receiver. 602 Such a key can be either stored in the certificate cache of the 603 receiver, or be received in the CGA option in the same message. 605 Digital Signature 607 A variable length field containing a PKCS#1 signature, constructed 608 using the sender's private key, over the the following sequence of 609 octets: 611 1. The 128-bit CGA Message Type tag [13] value for SEND, 0x086F 612 CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been 613 generated randomly by the editor of this specification.). 615 2. The 128-bit Source Address field from the IP header. 617 3. The 128-bit Destination Address field from the IP header. 619 4. The 32-bit ICMP header. 621 5. The NDP message header. 623 6. All NDP options preceding the Signature option. 625 The signature value is computed with the RSASSA-PKCS1-v1_5 626 algorithm and SHA-1 hash as defined in [14]. 628 This field starts after the Key Hash field. The length of the 629 Digital Signature field is determined by the length of the 630 Signature option minus the length of the other fields (including 631 the variable length Pad field). 633 Padding 635 This variable length field contains padding, as many bytes as is 636 given by the Pad Length field. 638 5.2.1 Processing Rules for Senders 640 Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, 641 and Redirect messages MUST contain the Signature option. Router 642 Solicitation messages not sent with the unspecified source address 643 MUST contain the Signature option. 645 A node sending a message using the Signature option MUST construct 646 the message as follows: 648 o The message is constructed in its entirety, without the Signature 649 option. 651 o The Signature option is added as the last option in the message. 653 o For the purpose of constructing a signature, the following data 654 items are concatenated: 656 * The 128-bit CGA Type Tag. 658 * The source address of the message. 660 * The destination address of the message. 662 * The contents of the message, starting from the ICMPv6 header, 663 up to but excluding the Signature option. 665 o The message, in the form defined above, is signed using the 666 configured private key, and the resulting PKCS#1 signature is put 667 to the Digital Signature field. 669 5.2.2 Processing Rules for Receivers 671 Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, 672 and Redirect messages without the Signature option MUST be treated as 673 insecure, i.e., processed in the same way as NDP messages sent by a 674 non-SEND node. See Section 8. 676 Router Solicitation messages without the Signature option MUST be 677 also treated as insecure, unless the source address of the message is 678 the unspecified address. 680 A message containing a Signature option MUST be checked as follows: 682 o The receiver MUST ignore any options the come after the first 683 Signature option. 685 o The Key Hash field MUST indicate the use of a known public key, 686 either one learned from a preceding CGA option in the same 687 message, or one known by other means. 689 o The Digital Signature field MUST have correct encoding, and not 690 exceed the length of the Signature option minus the Padding. 692 o The Digital Signature verification MUST show that the signature 693 has been calculated as specified in the previous section. 695 o If the use of a trust anchor has been configured, a valid 696 authorization delegation chain MUST be known between the 697 receiver's trust anchor and the sender's public key. 699 Note that the receiver may verify just the CGA property of a 700 packet, even if, in addition to CGA, the sender has used a trust 701 anchor. 703 Messages that do not pass all the above tests MUST be silently 704 discarded. The receiver MAY also otherwise silently discard packets, 705 e.g., as a response to an apparent CPU exhausting DoS attack. 707 5.2.3 Configuration 709 All nodes that support the reception of the Signature options MUST be 710 configured with the following information for each separate NDP 711 message type: 713 authorization method 715 This parameter determines the method through which the authority 716 of the sender is determined. It can have four values: 718 trust anchor 720 The authority of the sender is verified as described in Section 721 6.1. The sender may claim additional authorization through the 722 use of CGAs, but that is neither required nor verified. 724 CGA 726 The CGA property of the sender's address is verified as 727 described in [13]. The sender may claim additional authority 728 through a trust anchor, but that is neither required nor 729 verified. 731 trust anchor and CGA 733 Both the trust anchor and the CGA verification is required. 735 trust anchor or CGA 737 Either the trust anchor or the CGA verification is required. 739 anchor 741 The public keys and names of the allowed trust anchor(s), if the 742 authorization method is not set to CGA. 744 All nodes that support the sending of Signature options MUST record 745 the following configuration information: 747 keypair 749 A public-private key pair. If authorization delegation is in use, 750 there must exist a delegation chain from a trust anchor to this 751 key pair. 753 CGA flag 755 A flag that indicates whether CGA is used or not. This flag may 756 be per interface or per node. (Note that in future extensions of 757 the SEND protocol, this flag may be per subnet-prefix.) 759 5.2.4 Performance Considerations 761 The construction and verification of this option is computationally 762 expensive. In the NDP context, however, the hosts typically have the 763 need to perform only a few signature operations as they enter a link, 764 and a few operations as they find a new on-link peer with which to 765 communicate. 767 Routers are required to perform a larger number of operations, 768 particularly when the frequency of router advertisements is high due 769 to mobility requirements. Still, the number of required signature 770 operations is on the order of a few dozen per second, some of which 771 can be precomputed as explained below. A large number of router 772 solicitations may cause higher demand for performing asymmetric 773 operations, although RFC 2461 limits the rate at which responses to 774 solicitations can be sent. 776 Signatures can be precomputed for unsolicited (multicast) Neighbor 777 and Router Advertisements if the timing of such future advertisements 778 is known. Typically, solicited advertisements are sent to the 779 unicast address from which the solicitation was sent. Given that the 780 IPv6 header is covered by the signature, it is not possible to 781 precompute solicited advertisements. 783 5.3 Timestamp and Nonce options 785 5.3.1 Timestamp Option 787 The purpose of the Timestamp option is to assure that unsolicited 788 advertisements and redirects have not been replayed. The format of 789 this option is described in the following: 791 0 1 2 3 792 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 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Type | Length | Reserved | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 796 | | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | | 799 + Timestamp + 800 | | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 Type 805 TBD . 807 Length 809 The length of the option (including the Type, Length, Reserved, 810 and Timestamp fields) in units of 8 octets, i.e., 2. 812 Reserved 814 A 48-bit field reserved for future use. The value MUST be 815 initialized to zero by the sender, and MUST be ignored by the 816 receiver. 818 Timestamp 820 A 64-bit unsigned integer field containing a timestamp. The value 821 indicates the number of seconds since January 1, 1970 00:00 UTC, 822 using a fixed point format. In this format the integer number of 823 seconds is contained in the first 48 bits of the field, and the 824 remaining 16 bits indicate the number of 1/64K fractions of a 825 second. 827 5.3.2 Nonce Option 829 The purpose of the Nonce option is to assure that an advertisement is 830 a fresh response to a solicitation sent earlier by the node. The 831 format of this option is described in the following: 833 0 1 2 3 834 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 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Type | Length | Nonce ... | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 838 | | 839 . . 840 . . 841 | | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 Type 846 TBD . 848 Length 850 The length of the option (including the Type, Length, and Nonce 851 fields) in units of 8 octets. 853 Nonce 855 A field containing a random number selected by the sender of the 856 solicitation message. The length of the random number MUST be at 857 least 6 bytes. The length of the random number MUST be selected 858 so that the length of the nonce option is a multiple of 8 octets. 860 5.3.3 Processing rules for senders 862 All solicitation messages MUST include a Nonce. When sending a 863 solicitation, the sender MUST store the nonce internally so that it 864 can recognize any replies containing that particular nonce. 866 All solicited advertisements MUST include a Nonce, copied from the 867 received solicitation. Note that routers may decide to send a 868 multicast advertisement to all nodes instead of a response to a 869 specific host. In such case the router MAY still include the nonce 870 value for the host that triggered the multicast advertisement. 872 All solicitation, advertisement, and redirect messages MUST include a 873 Timestamp. Senders SHOULD set the Timestamp field to the current 874 time, according to their real time clock. 876 If a message has both Nonce and Timestamp options, the Nonce option 877 SHOULD precede the Timestamp option in the message. 879 5.3.4 Processing rules for receivers 881 The processing of the Nonce and Timestamp options depends on whether 882 a packet is a solicited advertisement. A system may implement the 883 distinction in various ways. Section 5.3.4.1 defines the processing 884 rules for solicited advertisements. Section 5.3.4.2 defines the 885 processing rules for all other messages. 887 In addition, the following rules apply in all cases: 889 o Messages received with the Signature option but without the 890 Timestamp option MUST be silently discarded. 892 o Solicitation messages received with the Signature option but 893 without the Nonce option MUST be silently discarded. 895 o Advertisements sent to a unicast destination address with the 896 Signature option but without a Nonce option MUST be silently 897 discarded. 899 o An implementation MAY utilize some mechanism such as a timestamp 900 cache to strengthen resistance to replay attacks. When there is a 901 very large number of nodes on the same link, or when a cache 902 filling attack is in progress, it is possible that the cache 903 holding the most recent timestamp per sender becomes full. In 904 this case the node MUST remove some entries from the cache or 905 refuse some new requested entries. The specific policy as to 906 which entries are preferred over the others is left as an 907 implementation decision. However, typical policies may prefer 908 existing entries over new ones, CGAs with a large Sec value over 909 smaller Sec values, and so on. The issue is briefly discussed in 910 Appendix C. 912 o The receiver MUST be prepared to receive the Timestamp and Nonce 913 options in any order, as per RFC 2461 [7] Section 9. 915 5.3.4.1 Processing solicited advertisements 917 The receiver MUST verify that it has recently sent a matching 918 solicitation, and that the received advertisement contains a copy of 919 the Nonce sent in the solicitation. 921 If the message contains a Nonce option, but the Nonce value is not 922 recognized, the message MUST be silently discarded. 924 Otherwise, if the message does not contain a Nonce option, it MAY be 925 considered as an unsolicited advertisement, and processed according 926 to Section 5.3.4.2. 928 If the message is accepted, the receiver SHOULD store the receive 929 time of the message and the time stamp time in the message, as 930 specified in Section 5.3.4.2. 932 5.3.4.2 Processing all other messages 934 Receivers SHOULD be configured with an allowed timestamp Delta value, 935 a "fuzz factor" for comparisons, and an allowed clock drift 936 parameter. The recommended default value for the allowed Delta is 937 TIMESTAMP_DELTA, for fuzz factor TIMESTAMP_FUZZ, and for clock drift 938 TIMESTAMP_DRIFT (see Section 11. 940 To facilitate timestamp checking, each node SHOULD store the 941 following information for each peer: 943 o The receive time of the last received and accepted SEND message. 944 This is called RDlast. 946 o The time stamp in the last received and accepted SEND message. 947 This is called TSlast. 949 An accepted SEND message is any successfully verified Neighbor 950 Solicitation, Neighbor Advertisement, Router Solicitation, Router 951 Advertisement, or Redirect message from the given peer. It is 952 required that the Signature option has been used in such a message 953 before it can update the above variables. 955 Receivers SHOULD then check the Timestamp field as follows: 957 o When a message is received from a new peer, i.e., one that is not 958 stored in the cache, the received timestamp, TSnew, is checked and 959 the packet is accepted if the timestamp is recent enough with 960 respect to the reception time of the packet, RDnew: 962 -Delta < (RDnew - TSnew) < +Delta 964 The RDnew and TSnew values SHOULD be stored into the cache as 965 RDlast and TSlast. 967 o If the timestamp is NOT within the boundaries but the message is a 968 Neighbor Solicitation message which should be answered by the 969 receiver, the receiver MAY respond to the message. However, if it 970 does respond to the message, it MUST NOT create a Neighbor Cache 971 entry. This allows nodes that have large differences in their 972 clocks to still communicate with each other, by exchanging NS/NA 973 pairs. 975 o When a message is received from a known peer, i.e., one that 976 already has an entry in the cache, the time stamp is checked 977 against the previously received SEND message: 979 TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz 981 If this inequality does not hold, the receiver SHOULD silently 982 discard the message. On the other hand, if the inequality holds, 983 the receiver SHOULD process the message. 985 Moreover, if the above inequality holds and TSnew > TSlast, the 986 receiver SHOULD update RDlast and TSlast. Otherwise, the receiver 987 MUST NOT update update RDlast or TSlast. 989 6. Authorization Delegation Discovery 991 NDP allows a node to automatically configure itself based on 992 information learned shortly after connecting to a new link. It is 993 particularly easy to configure "rogue" routers on an unsecured link, 994 and it is particularly difficult for a node to distinguish between 995 valid and invalid sources of router information, because the node 996 needs this information before being able to communicate with nodes 997 outside of the link. 999 Since the newly-connected node cannot communicate off-link, it cannot 1000 be responsible for searching information to help validate the 1001 router(s); however, given a chain of appropriately signed 1002 certificates, it can check someone else's search results and conclude 1003 that a particular message comes from an authorized source. In the 1004 typical case, a router already connected to beyond the link, can (if 1005 necessary) communicate with off-link nodes and construct such a 1006 certificate chain. 1008 The Secure Neighbor Discovery Protocol mandates a certificate format 1009 and introduces two new ICMPv6 messages that are used between hosts 1010 and routers to allow the host to learn a certificate chain with the 1011 assistance of the router. 1013 6.1 Certificate Format 1015 The certificate chain of a router terminates in a Router 1016 Authorization Certificate that authorizes a specific IPv6 node to act 1017 as a router. Because authorization chains are not a common practice 1018 in the Internet at the time this specification was written, the chain 1019 MUST consist of standard Public Key Certificates (PKC, in the sense 1020 of [19]). The certificate chain MUST start from the identity of a 1021 trust anchor that is shared by the host and the router. This allows 1022 the host to anchor trust for the router's public key in the trust 1023 anchor. Note that there MAY be multiple certificates issued by a 1024 single trust anchor. 1026 6.1.1 Router Authorization Certificate Profile 1028 Router Authorization Certificates are X.509v3 certificates, as 1029 defined in RFC 3280 [10], and MUST contain at least one instance of 1030 the X.509 extension for IP addresses, as defined in [12]. The parent 1031 certificates in the certificate chain MUST contain one or more X.509 1032 IP address extensions, back up to a trusted party (such as the user's 1033 ISP) that configured the original IP address space block for the 1034 router in question, or delegated the right to do so. The 1035 certificates for the intermediate delegating authorities MUST contain 1036 X.509 IP address extension(s) for subdelegations. The router's 1037 certificate is signed by the delegating authority for the prefixes 1038 the router is authorized to to advertise. 1040 The X.509 IP address extension MUST contain at least one 1041 addressesOrRanges element. This element MUST contain an 1042 addressPrefix element containing an IPv6 address prefix for a prefix 1043 the router or the intermediate entity is authorized to route. If the 1044 entity is allowed to route any prefix, the used IPv6 address prefix 1045 is the null prefix, ::/0. The addressFamily element of the 1046 containing IPAddrBlocks sequence element MUST contain the IPv6 1047 Address Family Identifier (0002), as specified in [12] for IPv6 1048 prefixes. Instead of an addressPrefix element, the addressesOrRange 1049 element MAY contain an addressRange element for a range of prefixes, 1050 if more than one prefix is authorized. The X.509 IP address 1051 extension MAY contain additional IPv6 prefixes, expressed either as 1052 an addressPrefix or an addressRange. 1054 A SEND node receiving a Router Authorization Certificate MUST first 1055 check whether the certificate's signature was generated by the 1056 delegating authority. Then the client MUST check whether all the 1057 addressPrefix or addressRange entries in the router's certificate are 1058 contained within the address ranges in the delegating authority's 1059 certificate, and whether the addressPrefix entries match any 1060 addressPrefix entries in the delegating authority's certificate. If 1061 an addressPrefix or addressRange is not contained within the 1062 delegating authority's prefixes or ranges, the client MAY attempt to 1063 take an intersection of the ranges/prefixes, and use that 1064 intersection. If the addressPrefix in the certificate is the null 1065 prefix, ::/0, such an intersection SHOULD be used. (In that case the 1066 intersection is the parent prefix or range.) If the resulting 1067 intersection is empty, the client MUST NOT accept the certificate. 1069 The above check SHOULD be done for all certificates in the chain. If 1070 any of the checks fail, the client MUST NOT accept the certificate. 1071 The client also needs to perform validation of advertised prefixes as 1072 discussed in Section 7.3. 1074 Care should be taken if the certificates used in SEND are re-used to 1075 provide authorization in other circumstances, for example with 1076 routing protocols. It is necessary to ensure that the authorization 1077 information is appropriate for all applications. SEND certificates 1078 may authorize a larger set of prefixes than the router is really 1079 authorized to advertise on a given interface. For instance, SEND 1080 allows the use of the null prefix. This prefix might cause 1081 verification or routing problems in other applications. It is 1082 RECOMMENDED that SEND certificates containing the null prefix are 1083 only used for SEND. 1085 Since it is possible that some public key certificates used with SEND 1086 do not immediately contain the X.509 IP address extension element, an 1087 implementation MAY contain facilities that allow the prefix and range 1088 checks to be relaxed. However, any such configuration options SHOULD 1089 be off by default. That is, the system SHOULD have a default 1090 configuration that requires rigorous prefix and range checks. 1092 The following is an example of a certificate chain. Suppose that 1093 isp_group_example.net is the trust anchor. The host has this 1094 certificate: 1096 Certificate 1: 1097 Issuer: isp_group_example.net 1098 Validity: Jan 1, 2004 through Dec 31, 2004 1099 Subject: isp_group_example.net 1100 Extensions: 1101 IP address delegation extension: 1102 Prefixes: P1, ..., Pk 1103 ... possibly other extensions ... 1104 ... other certificate parameters ... 1106 When the host attaches to a link served by 1107 router_x.isp_foo_example.net, it receives the following certificate 1108 chain: 1110 Certificate 2: 1111 Issuer: isp_group_example.net 1112 Validity: Jan 1, 2004 through Dec 31, 2004 1113 Subject: isp_foo_example.net 1114 Extensions: 1115 IP address delegation extension: 1116 Prefixes: Q1, ..., Qk 1117 ... possibly other extensions ... 1118 ... other certificate parameters ... 1120 Certificate 3: 1121 Issuer: isp_foo_example.net 1122 Validity: Jan 1, 2004 through Dec 31, 2004 1123 Subject: router_x.isp_foo_example.net 1124 Extensions: 1125 IP address delegation extension: 1126 Prefixes R1, ..., Rk 1127 ... possibly other extensions ... 1128 ... other certificate parameters ... 1130 When processing the three certificates, the usual RFC 3280 [10] 1131 certificate path validation is performed. Note, however, that at the 1132 time a node is checking certificates received in a DCA from a router, 1133 it typically does not have a connection to the Internet yet, and so 1134 it is not possible to perform an on-line Certificate Revocation List 1135 (CRL) check if such a check is necessary. Until such a check is 1136 performed, acceptance of the certificate MUST be considered 1137 provisional, and the node MUST perform a check as soon as it has 1138 established a connection with the Internet through the router. If 1139 the router has been compromised, it could interfere with the CRL 1140 check. Should performance of the CRL check be disrupted or should 1141 the check fail, the node SHOULD immediately stop using the router as 1142 a default and use another router on the link instead. 1144 In addition, the IP addresses in the delegation extension must be a 1145 subset of the IP addresses in the delegation extension of the 1146 issuer's certificate. So in this example, R1, ..., Rs must be a 1147 subset of Q1,...,Qr, and Q1,...,Qr must be a subset of P1,...,Pk. If 1148 the certificate chain is valid, then router_foo.isp_foo_example.com 1149 is authorized to route the prefixes R1,...,Rs. 1151 6.2 Certificate Transport 1153 The Delegation Chain Solicitation (DCS) message is sent by a host 1154 when it wishes to request a certificate chain between a router and 1155 the one of the host's trust anchors. The Delegation Chain 1156 Advertisement (DCA) message is sent in reply to the DCS message. 1157 These messages are separate from the rest of Neighbor and Router 1158 Discovery, in order to reduce the effect of the potentially 1159 voluminous certificate chain information on other messages. 1161 The Authorization Delegation Discovery (ADD) process does not exclude 1162 other forms of discovering certificate chains. For instance, during 1163 fast movements mobile nodes may learn information - including the 1164 certificate chains - of the next router from a previous router, or 1165 nodes may be preconfigured with certificate chains from roaming 1166 partners. 1168 Where hosts themselves are certified by a trust anchor, these 1169 messages MAY also optionally be used between hosts to acquire the 1170 peer's certificate chain. However, the details of such usage are 1171 beyond the scope of this specification. 1173 6.2.1 Delegation Chain Solicitation Message Format 1175 Hosts send Delegation Chain Solicitations in order to prompt routers 1176 to generate Delegation Chain Advertisements. 1178 0 1 2 3 1179 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 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Type | Code | Checksum | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Identifier | Reserved | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Options ... 1186 +-+-+-+-+-+-+-+-+-+-+-+- 1188 IP Fields: 1190 Source Address 1192 A link-local unicast address assigned to the sending interface, 1193 or the unspecified address if no address is assigned to the 1194 sending interface. 1196 Destination Address 1198 Typically the All-Routers multicast address, the Solicited-Node 1199 multicast address, or the address of the host's default router. 1201 Hop Limit 1203 255 1205 ICMP Fields: 1207 Type 1209 TBD . 1211 Code 1213 0 1215 Checksum 1217 The ICMP checksum [9]. 1219 Identifier 1221 A 16-bit unsigned integer field, acting as an identifier to 1222 help matching advertisements to solicitations. The Identifier 1223 field MUST NOT be zero, and its value SHOULD be randomly 1224 generated. This randomness does not need to be 1225 cryptographically hard, since its purpose is only to avoid 1226 collisions. 1228 Reserved 1230 An unused field. It MUST be initialized to zero by the sender 1231 and MUST be ignored by the receiver. 1233 Valid Options: 1235 Trust Anchor 1237 One or more trust anchors that the client is willing to accept. 1238 The first (or only) Trust Anchor option MUST contain a DER 1239 Encoded X.501 Name; see Section 6.2.3. If there is more than 1240 one Trust Anchor option, the options past the first one may 1241 contain any type of trust anchor. 1243 Future versions of this protocol may define new option types. 1244 Receivers MUST silently ignore any options they do not recognize 1245 and continue processing the message. All included options MUST 1246 have a length that is greater than zero. 1248 ICMP length (derived from the IP length) MUST be 8 or more octets. 1250 6.2.2 Delegation Chain Advertisement Message Format 1252 Routers send out Delegation Chain Advertisement messages in response 1253 to a Delegation Chain Solicitation. 1255 0 1 2 3 1256 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 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | Type | Code | Checksum | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Identifier | Component | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | Reserved | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | Options ... 1265 +-+-+-+-+-+-+-+-+-+-+-+- 1267 IP Fields: 1269 Source Address 1271 A link-local unicast address assigned to the interface from 1272 which this message is sent. Note that routers may use multiple 1273 addresses, and therefore this address is not sufficient for the 1274 unique identification of routers. 1276 Destination Address 1278 Either the Solicited-Node multicast address of the receiver or 1279 the link-scoped All-Nodes multicast address. 1281 Hop Limit 1283 255 1285 ICMP Fields: 1287 Type 1289 TBD . 1292 Code 1294 0 1296 Checksum 1298 The ICMP checksum [9]. 1300 Identifier 1302 A 16-bit unsigned integer field, acting as an identifier to 1303 help matching advertisements to solicitations. The Identifier 1304 field MUST be zero for advertisements sent to the All-Nodes 1305 multicast address and MUST NOT be zero for others. 1307 Component 1309 A 16-bit unsigned integer field, used for informing the 1310 receiver which certificate is being sent, and how many are 1311 still left to be sent in the whole chain. 1313 A single advertisement MUST be broken into separately sent 1314 components if there is more than one Certificate option, in 1315 order to avoid excessive fragmentation at the IP layer. Unlike 1316 the fragmentation at the IP layer, individual components of an 1317 advertisement may be stored and used before all the components 1318 have arrived; this makes them slightly more reliable and less 1319 prone to Denial-of-Service attacks. 1321 The first message in a N-component advertisement has the 1322 Component field set to N-1, the second set to N-2, and so on. 1323 Zero indicates that there are no more components coming in this 1324 advertisement. 1326 The components MUST be ordered so that the certificate after 1327 the trust anchor is the one sent first. Each certificate sent 1328 after the first can be verified with the previously sent 1329 certificates. The certificate of the sender comes last. 1331 Reserved 1333 An unused field. It MUST be initialized to zero by the sender 1334 and MUST be ignored by the receiver. 1336 Valid Options: 1338 Certificate 1340 One certificate is provided in each Certificate option, to 1341 establish a (part of a) certificate chain to a trust anchor. 1343 The certificate of the trust anchor itself SHOULD NOT be 1344 included. 1346 Trust Anchor 1348 Zero or more Trust Anchor options may be included to help 1349 receivers decide which advertisements are useful for them. If 1350 present, these options MUST appear in the first component of a 1351 multi-component advertisement. 1353 Future versions of this protocol may define new option types. 1354 Receivers MUST silently ignore any options they do not recognize 1355 and continue processing the message. All included options MUST 1356 have a length that is greater than zero. 1358 ICMP length (derived from the IP length) MUST be 8 or more octets. 1360 6.2.3 Trust Anchor Option 1362 The format of the Trust Anchor option is described in the following: 1364 0 1 2 3 1365 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 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | Type | Length | Name Type | Pad Length | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 | Name ... 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 Type 1374 TBD . 1376 Length 1378 The length of the option, (including the Type, Length, Name Type, 1379 Pad Length, and Name fields) in units of 8 octets. 1381 Name Type 1383 The type of the name included in the Name field. This 1384 specification defines two legal values for this field: 1386 1 DER Encoded X.501 Name 1387 2 FQDN 1389 Pad Length 1391 The number of padding octets beyond the end of the Name field but 1392 within the length specified by the Length field. Padding octets 1393 MUST be set to zero by senders and ignored by receivers. 1395 Name 1397 When the Name Type field is set to 1, the Name field contains a 1398 DER encoded X.501 certificate Name, represented and encoded 1399 exactly as in the matching X.509v3 trust anchor certificate. 1401 When the Name Type field is set to 2, the Name field contains a 1402 Fully Qualified Domain Name of the trust anchor, for example, 1403 "trustanchor.example.com". The name is stored as a string, in the 1404 "preferred name syntax" DNS format, as specified in RFC 1034 [1] 1405 Section 3.5. Additionally, the restrictions discussed in RFC 3280 1406 [10] Section 4.2.1.7 apply. 1408 In the FQDN case the Name field is an "IDN-unaware domain name 1409 slot" as defined in [11]. That is, it can contain only ASCII 1410 characters. An implementation MAY support internationalized 1411 domain names (IDNs) using the ToASCII operation; see [11] for more 1412 information. 1414 All systems MUST support the DER Encoded X.501 Name. 1415 Implementations MAY support the FQDN name type. 1417 6.2.4 Certificate Option 1419 The format of the certificate option is described in the following: 1421 0 1 2 3 1422 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 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 | Type | Length | Cert Type | Pad Length | 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 | Certificate ... 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 Type 1431 TBD . 1433 Length 1435 The length of the option, (including the Type, Length, Cert Type, 1436 Pad Length, and Certificate fields) in units of 8 octets. 1438 Cert Type 1440 The type of the certificate included in the Certificate field. 1441 This specification defines only one legal value for this field: 1443 1 X.509v3 Certificate, as specified below 1445 Pad Length 1447 The number of padding octets beyond the end of the Certificate 1448 field but within the length specified by the Length field. 1449 Padding octets MUST be set to zero by senders and ignored by 1450 receivers. 1452 Certificate 1454 When the Cert Type field is set to 1, the Certificate field 1455 contains an X.509v3 certificate [10], as described in Section 1456 6.1.1. 1458 6.2.5 Processing Rules for Routers 1460 Routers should be configured with a key pair and a certificate from 1461 at least one certificate authority. 1463 A router MUST silently discard any received Delegation Chain 1464 Solicitation messages that do not conform to the message format 1465 defined in Section 6.2.1. The contents of the Reserved field, and of 1466 any unrecognized options, MUST be ignored. Future, 1467 backward-compatible changes to the protocol may specify the contents 1468 of the Reserved field or add new options; backward-incompatible 1469 changes may use different Code values. The contents of any defined 1470 options that are not specified to be used with Router Solicitation 1471 messages MUST be ignored and the packet processed in the normal 1472 manner. The only defined option that may appear is the Trust Anchor 1473 option. A solicitation that passes the validity checks is called a 1474 "valid solicitation". 1476 Routers SHOULD send advertisements in response to valid solicitations 1477 received on an advertising interface. If the source address in the 1478 solicitation was the unspecified address, the router MUST send the 1479 response to the link-scoped All-Nodes multicast address. If the 1480 source address was a unicast address, the router MUST send the 1481 response to the Solicited-Node multicast address corresponding to the 1482 source address, except when under load, as specified below. Routers 1483 SHOULD NOT send Delegation Chain Advertisements more than 1484 MAX_DCA_RATE times within a second. When there are more 1485 solicitations, the router SHOULD send the response to the All-Nodes 1486 multicast address regardless of the source address that appeared in 1487 the solicitation. 1489 In an advertisement, the router SHOULD include suitable Certificate 1490 options so that a delegation chain to the solicited trust anchor can 1491 be established. The anchor is identified by the Trust Anchor option. 1492 If the Trust Anchor option is represented as a DER Encoded X.501 1493 Name, then the Name must be equal to the Subject field in the 1494 anchor's certificate. If the Trust Anchor option is represented as 1495 an FQDN, the FQDN must be equal to an FQDN in the subjectAltName 1496 field of the anchor's certificate. The router SHOULD include the 1497 Trust Anchor option(s) in the advertisement for which the delegation 1498 chain was found. 1500 If the router is unable to find a chain to the requested anchor, it 1501 SHOULD send an advertisement without any certificates. In this case 1502 the router SHOULD include the Trust Anchor options which were 1503 solicited. 1505 6.2.6 Processing Rules for Hosts 1507 Hosts SHOULD possess the public key and trust anchor name of at least 1508 one certificate authority, they SHOULD possess their own key pair, 1509 and they MAY possess certificates from certificate authorities. 1511 A host MUST silently discard any received Delegation Chain 1512 Advertisement messages that do not conform to the message format 1513 defined in Section 6.2.2. The contents of the Reserved field, and of 1514 any unrecognized options, MUST be ignored. Future, 1515 backward-compatible changes to the protocol MAY specify the contents 1516 of the Reserved field or add new options; backward-incompatible 1517 changes MUST use different Code values. The contents of any defined 1518 options that are not specified to be used with Delegation Chain 1519 Advertisement messages MUST be ignored and the packet processed in 1520 the normal manner. The only defined options that may appear are the 1521 Certificate and Trust Anchor options. An advertisement that passes 1522 the validity checks is called a "valid advertisement". 1524 Hosts SHOULD store certificate chains retrieved in Delegation Chain 1525 Discovery messages if they start from an anchor trusted by the host. 1526 The certificate chains MUST be verified, as defined in Section 6.1, 1527 before storing them. Routers MUST send the certificates one by one, 1528 starting from the trust anchor end of the chain. Except for 1529 temporary purposes to allow for message loss and reordering, hosts 1530 SHOULD NOT store certificates received in a Delegation Chain 1531 Advertisement unless they contain a certificate which can be 1532 immediately verified either to the trust anchor or to a certificate 1533 that has been verified earlier. 1535 Note that caching this information and the implied verification 1536 results between network attachments for use over multiple attachments 1537 to the network can help improve performance. But periodic 1538 certificate revocation checks are still needed even with cached 1539 results, to make sure that the certificates are still valid. 1541 The host has a need to retrieve a delegation chain when a Router 1542 Advertisement has been received with a public key that is not stored 1543 in the hosts' cache of certificates, or there is no authorization 1544 delegation chain to the host's trust anchor. In these situations, 1545 the host MAY transmit up to MAX_DCS_MESSAGES Delegation Chain 1546 Solicitation messages, each separated by at least DCS_INTERVAL 1547 seconds. 1549 Delegation Chain Solicitations SHOULD NOT be sent if the host has a 1550 currently valid certificate chain from a reachable router to a trust 1551 anchor. 1553 When soliciting certificates for a router, a host MUST send 1554 Delegation Chain Solicitations either to the All-Routers multicast 1555 address, if it has not selected a default router yet, or to the 1556 default router's IP address, if a default router has already been 1557 selected. 1559 If two hosts want to establish trust with the DCS and DCA messages, 1560 the DCS message SHOULD be sent to the Solicited-Node multicast 1561 address of the receiver. The advertisements SHOULD be sent as 1562 specified above for routers. However, the exact details are outside 1563 the scope of this specification. 1565 When processing possible advertisements sent as responses to a 1566 solicitation, the host MAY prefer to process first those 1567 advertisements with the same Identifier field value as in the 1568 solicitation. This makes Denial-of-Service attacks against the 1569 mechanism harder (see Section 9.3). 1571 7. Addressing 1573 7.1 CGAs 1575 Nodes that use stateless address autoconfiguration SHOULD generate a 1576 new CGA as specified in Section 4 of [13] each time they run the 1577 autoconfiguration procedure. The nodes MAY continue to use the same 1578 public key and modifier, and start the process from Step 4 of the 1579 generation algorithm. 1581 By default, a SEND-enabled node SHOULD use only CGAs for its own 1582 addresses. Other types of addresses MAY be used in testing, 1583 diagnostics or for other purposes. However, this document does not 1584 describe how to choose between different types of addresses for 1585 different communications. A dynamic selection can be provided by an 1586 API, such as the one defined in [23]. 1588 7.2 Redirect Addresses 1590 If the Target Address and Destination Address fields in the ICMP 1591 Redirect message are equal, then this message is used to inform hosts 1592 that a destination is in fact a neighbor. In this case the receiver 1593 MUST verify that the given address falls within the range defined by 1594 the router's certificate. Redirect messages failing this check MUST 1595 be silently discarded. 1597 Note that RFC 2461 rules prevent a host from accepting a Redirect 1598 message from a router that is not its default router. This prevents 1599 an attacker from tricking a node into redirecting traffic when the 1600 attacker is not the default router. 1602 7.3 Advertised Prefixes 1604 The router's certificate defines the address range(s) that it is 1605 allowed to advertise securely. A router MAY, however, advertise a 1606 combination of certified and uncertified prefixes. Uncertified 1607 prefixes are treated as insecure, i.e., processed in the same way as 1608 insecure router advertisements sent by non-SEND routers. The 1609 processing of insecure messages is specified in Section 8. Note that 1610 SEND nodes that do not attempt to interoperate with non-SEND nodes 1611 MAY simply discard the insecure information. 1613 Certified prefixes fall into the following two categories: 1615 Constrained 1617 If the network operator wants to constrain which routers are 1618 allowed to route particular prefixes, routers should be configured 1619 with certificates having prefixes listed in the prefix extension. 1620 Routers so configured SHOULD advertise the prefixes which they are 1621 certified to route, or a subset thereof. 1623 Unconstrained 1625 Network operators that do not want to constrain routers this way 1626 should configure routers with certificates containing either the 1627 null prefix or no prefix extension at all. 1629 Upon processing a Prefix Information option within a Router 1630 Advertisement, nodes SHOULD verify that the prefix specified in this 1631 option falls within the range defined by the certificate, if the 1632 certificate contains a prefix extension. Options failing this check 1633 are treated as containing uncertified prefixes. 1635 Nodes SHOULD use one of the certified prefixes for stateless 1636 autoconfiguration. If none of the advertised prefixes match, the 1637 host SHOULD use a different advertising router as its default router, 1638 if available. If the node is performing stateful autoconfiguration, 1639 it SHOULD check the address provided by the DHCP server against the 1640 certified prefixes and SHOULD NOT use the address if the prefix is 1641 not certified. 1643 7.4 Limitations 1645 This specification does not address the protection of NDP packets for 1646 nodes that are configured with a static address (e.g., PREFIX::1). 1647 Future certificate chain-based authorization specifications are 1648 needed for such nodes. 1650 It is outside the scope of this specification to describe the use of 1651 trust anchor authorization between nodes with dynamically changing 1652 addresses. Such dynamically changing addresses may be the result of 1653 stateful or stateless address autoconfiguration, or through the use 1654 of RFC 3041 [18] addresses. If the CGA method is not used, nodes 1655 would be required to exchange certificate chains that terminate in a 1656 certificate authorizing a node to use an IP address having a 1657 particular interface identifier. This specification does not specify 1658 the format of such certificates, since there are currently a few 1659 cases where such certificates are required by the link layer and it 1660 is up to the link layer to provide certification for the interface 1661 identifier. This may be the subject of a future specification. It 1662 is also outside the scope of this specification to describe how 1663 stateful address autoconfiguration works with the CGA method. 1665 The Target Address in Neighbor Advertisement is required to be equal 1666 to the source address of the packet, except in the case of proxy 1667 Neighbor Discovery. Proxy Neighbor Discovery is not supported by 1668 this specification. 1670 8. Transition Issues 1672 During the transition to secure links or as a policy consideration, 1673 network operators may want to run a particular link with a mixture of 1674 secure and insecure nodes. Nodes that support SEND SHOULD support 1675 the use of SEND and plain NDP at the same time. 1677 In a mixed environment, SEND nodes receive both secure and insecure 1678 messages but give priority to "secured" ones. Here, the "secured" 1679 messages are ones that contain a valid signature option, as specified 1680 above, and "insecure" messages are ones that contain no signature 1681 option. 1683 SEND nodes MUST send only secured messages. Plain (non-SEND) 1684 Neighbor Discovery nodes will obviously send only insecure messages. 1685 Per RFC 2461 [7], such nodes will ignore the unknown options and will 1686 treat secured messages in the same way as they treat insecure ones. 1687 Secured and insecure nodes share the same network resources, such as 1688 prefixes and address spaces. 1690 In a mixed environment SEND nodes follow the protocols defined in RFC 1691 2461 and RFC 2462 with the following exceptions: 1693 o All solicitations sent by a SEND node MUST be secured. 1695 o Unsolicited advertisements sent by a SEND node MUST be secured. 1697 o A SEND node MUST send a secured advertisement in response to a 1698 secured solicitation. Advertisements sent in response to an 1699 insecure solicitation MUST be secured as well, but MUST NOT 1700 contain the Nonce option. 1702 o A SEND node that uses the CGA authorization method for protecting 1703 Neighbor Solicitations SHOULD perform Duplicate Address Detection 1704 as follows. If Duplicate Address Detection indicates the 1705 tentative address is already in use, generate a new tentative CGA. 1706 If after 3 consecutive attempts no non-unique address was 1707 generated, log a system error and give up attempting to generate 1708 an address for that interface. 1710 When performing Duplicate Address Detection for the first 1711 tentative address, accept both secured and insecure Neighbor 1712 Advertisements and Solicitations received as response to the 1713 Neighbor Solicitations. When performing Duplicate Address 1714 Detection for the second or third tentative address, ignore 1715 insecure Neighbor Advertisements and Solicitations. 1717 o The node MAY have a configuration option that causes it to ignore 1718 insecure advertisements even when performing Duplicate Address 1719 Detection for the first tentative address. This configuration 1720 option SHOULD be disabled by default. This is a recovery 1721 mechanism, in case attacks against the first address become 1722 common. 1724 o The Neighbor Cache, Prefix List and Default Router list entries 1725 MUST have a secured/insecure flag that indicates whether the 1726 message that caused the creation or last update of the entry was 1727 secured or insecure. Received insecure messages MUST NOT cause 1728 changes to existing secured entries in the Neighbor Cache, Prefix 1729 List or Default Router List. The Neighbor Cache SHOULD implement 1730 a flag on entries indicating whether the entry issecured. 1731 Received secured messages MUST cause an update of the matching 1732 entries and flagging of them as secured. 1734 o The conceptual sending algorithm is modified so that an insecure 1735 router is selected only if there is no reachable SEND router for 1736 the prefix. That is, the algorithm for selecting a default router 1737 favors reachable SEND routers over reachable non-SEND ones. 1739 o A SEND node SHOULD have a configuration option that causes it to 1740 ignore all insecure Neighbor Solicitation and Advertisement, 1741 Router Solicitation and Advertisement, and Redirect messages. 1742 This can be used to enforce SEND-only networks. 1744 9. Security Considerations 1746 9.1 Threats to the Local Link Not Covered by SEND 1748 SEND does not provide confidentiality for NDP communications. 1750 SEND does not compensate for an insecure link layer. For instance, 1751 there is no assurance that payload packets actually come from the 1752 same peer that the NDP was run against. 1754 There may be no cryptographic binding in SEND between the link layer 1755 frame address and the IPv6 address. On an insecure link layer that 1756 allows nodes to spoof the link layer address of other nodes, an 1757 attacker could disrupt IP service by sending out a Neighbor 1758 Advertisement having the source address on the link layer frame of a 1759 victim, a valid CGA address and a valid signature corresponding to 1760 itself, and a Target Link-layer Address extension corresponding to 1761 the victim. The attacker could then proceed to cause a traffic 1762 stream to bombard the victim in a DoS attack. This attack cannot be 1763 prevented just by securing the link layer. 1765 Even on a secure link layer, SEND does not require that the addresses 1766 on the link layer and Neighbor Advertisements correspond to each 1767 other. However, it is RECOMMENDED that such checks be performed 1768 where this is possible on the given link layer technology. 1770 Prior to participating in Neighbor Discovery and Duplicate Address 1771 Detection, nodes must subscribe to the link-scoped All-Nodes 1772 Multicast Group and the Solicited-Node Multicast Group for the 1773 address that they are claiming for their addresses; RFC 2461 [7]. 1774 Subscribing to a multicast group requires that the nodes use MLD 1775 [17]. MLD contains no provision for security. An attacker could 1776 send an MLD Done message to unsubscribe a victim from the 1777 Solicited-Node Multicast address. However, the victim should be able 1778 to detect such an attack because the router sends a 1779 Multicast-Address-Specific Query to determine whether any listeners 1780 are still on the address, at which point the victim can respond to 1781 avoid being dropped from the group. This technique will work if the 1782 router on the link has not been compromised. Other attacks using MLD 1783 are possible, but they primarily lead to extraneous (but not 1784 overwhelming) traffic. 1786 9.2 How SEND Counters Threats to NDP 1788 The SEND protocol is designed to counter the threats to NDP, as 1789 outlined in [24]. The following subsections contain a regression of 1790 the SEND protocol against the threats, to illustrate what aspects of 1791 the protocol counter each threat. 1793 9.2.1 Neighbor Solicitation/Advertisement Spoofing 1795 This threat is defined in Section 4.1.1 of [24]. The threat is that 1796 a spoofed message may cause a false entry in a node's Neighbor Cache. 1797 There are two cases: 1799 1. Entries made as a side effect of a Neighbor Solicitation or 1800 Router Solicitation. A router receiving a Router Solicitation 1801 with a Target Link-Layer Address extension and the IPv6 source 1802 address not equal to the unspecified address inserts an entry for 1803 the IPv6 address into its Neighbor Cache. Also, a node 1804 performing Duplicate Address Detection (DAD) that receives a 1805 Neighbor Solicitation for the same address regards the situation 1806 as a collision and ceases to solicit for the address. 1808 In either case, SEND counters these treats by requiring the 1809 Signature and CGA options to be present in such solicitations. 1811 SEND nodes can send Router Solicitation messages with a CGA 1812 source address and a CGA option, which the router can verify, so 1813 the Neighbor Cache binding is correct. If a SEND node must send 1814 a Router Solicitation with the unspecified address, the router 1815 will not update its Neighbor Cache, as per RFC 2461. 1817 2. Entries made as a result of a Neighbor Advertisement message. 1818 SEND counters this threat by requiring the Signature and CGA 1819 options to be present in these advertisements. 1821 See also Section 9.2.5, below, for discussion about replay protection 1822 and timestamps. 1824 9.2.2 Neighbor Unreachability Detection Failure 1826 This attack is described in Section 4.1.2 of [24]. SEND counters 1827 this attack by requiring a node responding to Neighbor Solicitations 1828 sent as NUD probes to include a Signature option and proof of 1829 authorization to use the interface identifier in the address being 1830 probed. If these prerequisites are not met, the node performing NUD 1831 discards the responses. 1833 9.2.3 Duplicate Address Detection DoS Attack 1835 This attack is described in Section 4.1.3 of [24]. SEND counters 1836 this attack by requiring the Neighbor Advertisements sent as 1837 responses to DAD to include a Signature option and proof of 1838 authorization to use the interface identifier in the address being 1839 tested. If these prerequisites are not met, the node performing DAD 1840 discards the responses. 1842 When a SEND node is performing DAD, it may listen for address 1843 collisions from non-SEND nodes for the first address it generates, 1844 but not for new attempts. This protects the SEND node from DAD DoS 1845 attacks by non-SEND nodes or attackers simulating to non-SEND nodes, 1846 at the cost of a potential address collision between a SEND node and 1847 non-SEND node. The probability and effects of such an address 1848 collision are discussed in [13]. 1850 9.2.4 Router Solicitation and Advertisement Attacks 1852 These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6, 1853 and 4.2.7 of [24]. SEND counters these attacks by requiring Router 1854 Advertisements to contain a Signature option, and that the signature 1855 is calculated using the public key of a node that can prove its 1856 authorization to route the subnet prefixes contained in any Prefix 1857 Information Options. The router proves its authorization by showing 1858 a certificate containing the specific prefix or the indication that 1859 the router is allowed to route any prefix. A Router Advertisement 1860 without these protections is discarded. 1862 SEND does not protect against brute force attacks on the router, such 1863 as DoS attacks, or compromise of the router, as described in Sections 1864 4.4.2 and 4.4.3 of [24]. 1866 9.2.5 Replay Attacks 1868 This attack is described in Section 4.3.1 of [24]. SEND protects 1869 against attacks in Router Solicitation/Router Advertisement and 1870 Neighbor Solicitation/Neighbor Advertisement transactions by 1871 including a Nonce option in the solicitation and requiring the 1872 advertisement to include a matching option. Together with the 1873 signatures this forms a challenge-response protocol. SEND protects 1874 against attacks from unsolicited messages such as Neighbor 1875 Advertisements, Router Advertisements, and Redirects by including a 1876 Timestamp option. A window of vulnerability for replay attacks 1877 exists until the timestamp expires. 1879 When timestamps are used, SEND nodes are protected against replay 1880 attacks as long as they cache the state created by the message 1881 containing the timestamp. The cached state allows the node to 1882 protect itself against replayed messages. However, once the node 1883 flushes the state for whatever reason, an attacker can re-create the 1884 state by replaying an old message while the timestamp is still valid. 1885 Since most SEND nodes are likely to use fairly coarse grained 1886 timestamps, as explained in Section 5.3.1, this may affect some 1887 nodes. 1889 9.2.6 Neighbor Discovery DoS Attack 1891 This attack is described in Section 4.3.2 of [24]. In this attack, 1892 the attacker bombards the router with packets for fictitious 1893 addresses on the link, causing the router to busy itself with 1894 performing Neighbor Solicitations for addresses that do not exist. 1895 SEND does not address this threat because it can be addressed by 1896 techniques such as rate limiting Neighbor Solicitations, restricting 1897 the amount of state reserved for unresolved solicitations, and clever 1898 cache management. These are all techniques involved in implementing 1899 Neighbor Discovery on the router. 1901 9.3 Attacks against SEND Itself 1903 The CGAs have a 59-bit hash value. The security of the CGA mechanism 1904 has been discussed in [13]. 1906 Some Denial-of-Service attacks against NDP and SEND itself remain. 1907 For instance, an attacker may try to produce a very high number of 1908 packets that a victim host or router has to verify using asymmetric 1909 methods. While safeguards are required to prevent an excessive use 1910 of resources, this can still render SEND non-operational. 1912 When CGA protection is used, SEND deals with the DoS attacks using 1913 the verification process described in Section 5.2.2. In this 1914 process, a simple hash verification of the CGA property of the 1915 address is performed before performing the more expensive signature 1916 verification. However, even if the CGA verification succeeds, no 1917 claims about the validity of the message can be made, until the 1918 signature has been checked. 1920 When trust anchors and certificates are used for address validation 1921 in SEND, the defenses are not quite as effective. Implementations 1922 SHOULD track the resources devoted to the processing of packets 1923 received with the Signature option, and start selectively discarding 1924 packets if too many resources are spent. Implementations MAY also 1925 first discard packets that are not protected with CGA. 1927 The Authorization Delegation Discovery process may also be vulnerable 1928 to Denial-of-Service attacks. An attack may target a router by 1929 requesting a large number of delegation chains to be discovered for 1930 different trust anchors. Routers SHOULD defend against such attacks 1931 by caching discovered information (including negative responses) and 1932 by limiting the number of different discovery processes they engage 1933 in. 1935 Attackers may also target hosts by sending a large number of 1936 unnecessary certificate chains, forcing hosts to spend useless memory 1937 and verification resources for them. Hosts can defend against such 1938 attacks by limiting the amount of resources devoted to the 1939 certificate chains and their verification. Hosts SHOULD also 1940 prioritize advertisements that sent as a response to their 1941 solicitations above unsolicited advertisements. 1943 10. Protocol Constants 1945 Host constants: 1947 MAX_DCS_MESSAGES 3 transmissions 1948 DCS_INTERVAL 4 seconds 1950 Router constants: 1952 MAX_DCA_RATE 10 times per second 1954 11. Protocol Variables 1956 TIMESTAMP_DELTA 3,600 seconds (1 hour) 1957 TIMESTAMP_FUZZ 1 second 1958 TIMESTAMP_DRIFT 1 % (0.01) 1960 12. IANA Considerations 1962 This document defines two new ICMP message types, used in 1963 Authorization Delegation Discovery. These messages must be assigned 1964 ICMPv6 type numbers from the informational message range: 1966 o The Delegation Chain Solicitation message, described in Section 1967 6.2.1. 1969 o The Delegation Chain Advertisement message, described in Section 1970 6.2.2. 1972 This document defines six new Neighbor Discovery Protocol [7] 1973 options, which must be assigned Option Type values within the option 1974 numbering space for Neighbor Discovery Protocol messages: 1976 o The CGA option, described in Section 5.1. 1978 o The Signature option, described in Section 5.2. 1980 o The Timestamp option, described in Section 5.3.1. 1982 o The Nonce option, described in Section 5.3.2. 1984 o The Trust Anchor option, described in Section 6.2.3. 1986 o The Certificate option, described in Section 6.2.4. 1988 This document defines a new 128-bit value under the CGA Message Type 1989 [13] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08. 1991 This document defines a new name space for the Name Type field in the 1992 Trust Anchor option. Future values of this field can be allocated 1993 using Standards Action [6]. The current values for this field are: 1995 1 DER Encoded X.501 Name 1997 2 FQDN 1999 Another new name space is allocated for the Cert Type field in the 2000 Certificate option. Future values of this field can be allocated 2001 using Standards Action [6]. The current values for this field are: 2003 1 X.509v3 Certificate 2005 Normative References 2007 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 2008 13, RFC 1034, November 1987. 2010 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2011 Levels", BCP 14, RFC 2119, March 1997. 2013 [3] Kent, S. and R. Atkinson, "Security Architecture for the 2014 Internet Protocol", RFC 2401, November 1998. 2016 [4] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 2017 November 1998. 2019 [5] Piper, D., "The Internet IP Security Domain of Interpretation 2020 for ISAKMP", RFC 2407, November 1998. 2022 [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2023 Considerations Section in RFCs", BCP 26, RFC 2434, October 2024 1998. 2026 [7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 2027 for IP Version 6 (IPv6)", RFC 2461, December 1998. 2029 [8] Thomson, S. and T. Narten, "IPv6 Stateless Address 2030 Autoconfiguration", RFC 2462, December 1998. 2032 [9] Conta, A. and S. Deering, "Internet Control Message Protocol 2033 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 2034 Specification", RFC 2463, December 1998. 2036 [10] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 2037 Public Key Infrastructure Certificate and Certificate 2038 Revocation List (CRL) Profile", RFC 3280, April 2002. 2040 [11] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing 2041 Domain Names in Applications (IDNA)", RFC 3490, March 2003. 2043 [12] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP 2044 Addresses and AS Identifiers", 2045 draft-ietf-pkix-x509-ipaddr-as-extn-03 (work in progress), 2046 September 2003. 2048 [13] Aura, T., "Cryptographically Generated Addresses (CGA)", 2049 draft-ietf-send-cga-03 (work in progress), December 2003. 2051 [14] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS 2052 1, November 2002. 2054 [15] National Institute of Standards and Technology, "Secure Hash 2055 Standard", FIPS PUB 180-1, April 1995, . 2058 Informative References 2060 [16] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 2061 RFC 2409, November 1998. 2063 [17] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener 2064 Discovery (MLD) for IPv6", RFC 2710, October 1999. 2066 [18] Narten, T. and R. Draves, "Privacy Extensions for Stateless 2067 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 2069 [19] Farrell, S. and R. Housley, "An Internet Attribute Certificate 2070 Profile for Authorization", RFC 3281, April 2002. 2072 [20] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 2073 Carney, "Dynamic Host Configuration Protocol for IPv6 2074 (DHCPv6)", RFC 3315, July 2003. 2076 [21] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies", 2077 draft-arkko-icmpv6-ike-effects-02 (work in progress), March 2078 2003. 2080 [22] Arkko, J., "Manual SA Configuration for IPv6 Link Local 2081 Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress), 2082 June 2002. 2084 [23] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API 2085 for Address Selection", draft-chakrabarti-ipv6-addrselect-02 2086 (work in progress), October 2003. 2088 [24] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 2089 Discovery trust models and threats", draft-ietf-send-psreq-04 2090 (work in progress), October 2003. 2092 Authors' Addresses 2094 Jari Arkko 2095 Ericsson 2097 Jorvas 02420 2098 Finland 2100 EMail: jari.arkko@ericsson.com 2101 James Kempf 2102 DoCoMo Communications Labs USA 2103 181 Metro Drive 2104 San Jose, CA 94043 2105 USA 2107 EMail: kempf@docomolabs-usa.com 2109 Bill Sommerfeld 2110 Sun Microsystems 2111 1 Network Drive UBUR02-212 2112 Burlington, MA 01803 2113 USA 2115 EMail: sommerfeld@east.sun.com 2117 Brian Zill 2118 Microsoft 2120 USA 2122 EMail: bzill@microsoft.com 2124 Pekka Nikander 2125 Ericsson 2127 Jorvas 02420 2128 Finland 2130 EMail: Pekka.Nikander@nomadiclab.com 2132 Appendix A. Contributors 2134 Tuomas Aura contributed the transition mechanism specification in 2135 Section 8. Jonathan Trostle contributed the certificate chain 2136 example in Section 6.1.1. 2138 Appendix B. Acknowledgments 2140 The authors would like to thank Tuomas Aura, Erik Nordmark, Gabriel 2141 Montenegro, Pasi Eronen, Greg Daley, Jon Wood, Julien Laganier, 2142 Francis Dupont, and Pekka Savola for interesting discussions in this 2143 problem space and feedback regarding the SEND protocol. 2145 Appendix C. Cache Management 2147 In this section we outline a cache management algorithm that allows a 2148 node to remain partially functional even under a cache filling DoS 2149 attack. This appendix is informational, and real implementations 2150 SHOULD use different algorithms in order to avoid he dangers of 2151 mono-cultural code. 2153 There are at least two distinct cache related attack scenarios: 2155 1. There are a number of nodes on a link, and someone launches a 2156 cache filling attack. The goal here is clearly make sure that 2157 the nodes can continue to communicate even if the attack is going 2158 on. 2160 2. There is already a cache filling attack going on, and a new node 2161 arrives to the link. The goal here is to make it possible for 2162 the new node to become attached to the network, in spite of the 2163 attack. 2165 From this point of view, it is clearly better to be very selective in 2166 how to throw out entries. Reducing the timestamp Delta value is very 2167 discriminative against those nodes that have a large clock 2168 difference, while an attacker can reduce its clock difference into 2169 arbitrarily small. Throwing out old entries just because their clock 2170 difference is large seems like a bad approach. 2172 A reasonable idea seems to be to have a separate cache space for new 2173 entries and old entries, and under an attack more eagerly drop new 2174 cache entries than old ones. One could track traffic, and only allow 2175 those new entries that receive genuine traffic to be converted into 2176 old cache entries. While such a scheme will make attacks harder, it 2177 will not fully prevent them. For example, an attacker could send a 2178 little traffic (i.e. a ping or TCP syn) after each NS to trick the 2179 victim into promoting its cache entry to the old cache. Hence, the 2180 node may be more intelligent in keeping its cache entries, and not 2181 just have a black/white old/new boundary. 2183 It also looks like a good idea to consider the sec parameter when 2184 forcing cache entries out, and let those entries with a larger sec a 2185 higher chance of staying in. 2187 Intellectual Property Statement 2189 The IETF takes no position regarding the validity or scope of any 2190 intellectual property or other rights that might be claimed to 2191 pertain to the implementation or use of the technology described in 2192 this document or the extent to which any license under such rights 2193 might or might not be available; neither does it represent that it 2194 has made any effort to identify any such rights. Information on the 2195 IETF's procedures with respect to rights in standards-track and 2196 standards-related documentation can be found in BCP-11. Copies of 2197 claims of rights made available for publication and any assurances of 2198 licenses to be made available, or the result of an attempt made to 2199 obtain a general license or permission for the use of such 2200 proprietary rights by implementors or users of this specification can 2201 be obtained from the IETF Secretariat. 2203 The IETF invites any interested party to bring to its attention any 2204 copyrights, patents or patent applications, or other proprietary 2205 rights which may cover technology that may be required to practice 2206 this standard. Please address the information to the IETF Executive 2207 Director. 2209 The IETF has been notified of intellectual property rights claimed in 2210 regard to some or all of the specification contained in this 2211 document. For more information consult the online list of claimed 2212 rights. 2214 Full Copyright Statement 2216 Copyright (C) The Internet Society (2004). All Rights Reserved. 2218 This document and translations of it may be copied and furnished to 2219 others, and derivative works that comment on or otherwise explain it 2220 or assist in its implementation may be prepared, copied, published 2221 and distributed, in whole or in part, without restriction of any 2222 kind, provided that the above copyright notice and this paragraph are 2223 included on all such copies and derivative works. However, this 2224 document itself may not be modified in any way, such as by removing 2225 the copyright notice or references to the Internet Society or other 2226 Internet organizations, except as needed for the purpose of 2227 developing Internet standards in which case the procedures for 2228 copyrights defined in the Internet Standards process must be 2229 followed, or as required to translate it into languages other than 2230 English. 2232 The limited permissions granted above are perpetual and will not be 2233 revoked by the Internet Society or its successors or assignees. 2235 This document and the information contained herein is provided on an 2236 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2237 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2238 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2239 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2240 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2242 Acknowledgement 2244 Funding for the RFC Editor function is currently provided by the 2245 Internet Society.