idnits 2.17.1 draft-arkko-send-ndopt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 434: '...served for future use. The value MUST...' RFC 2119 keyword, line 435: '... the sender, and MUST be ignored by th...' RFC 2119 keyword, line 461: '... former option MUST be the public ke...' RFC 2119 keyword, line 463: '... keys MUST be silently discarded....' RFC 2119 keyword, line 478: '...sing the CGA option MUST construct the...' (141 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1196 has weird spacing: '... or the unspe...' == Line 1197 has weird spacing: '... is allow...' -- 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 (June 19, 2003) is 7614 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: '2' is defined on line 2024, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 2030, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 2079, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 2111, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 2125, but no explicit reference was found in the text == Unused Reference: '32' is defined on line 2132, but no explicit reference was found in the text == Unused Reference: '33' is defined on line 2136, but no explicit reference was found in the text == Unused Reference: '34' is defined on line 2140, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. '1') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2401 (ref. '2') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '3') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2407 (ref. '4') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2461 (ref. '6') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '7') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2463 (ref. '8') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3041 (ref. '9') (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3280 (ref. '11') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3281 (ref. '12') (Obsoleted by RFC 5755) ** Obsolete normative reference: RFC 3513 (ref. '13') (Obsoleted by RFC 4291) == Outdated reference: A later version (-03) exists of draft-ietf-pkix-x509-ipaddr-as-extn-00 == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-22 -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '21') (Obsoleted by RFC 4306) == Outdated reference: A later version (-02) exists of draft-arkko-icmpv6-ike-effects-01 == Outdated reference: A later version (-02) exists of draft-arkko-manual-icmpv6-sas-01 == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-esp-v3-04 == Outdated reference: A later version (-06) exists of draft-ietf-send-cga-00 == Outdated reference: A later version (-01) exists of draft-ietf-send-ipsec-00 == Outdated reference: A later version (-04) exists of draft-ietf-send-psreq-00 Summary: 14 errors (**), 0 flaws (~~), 21 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Expires: December 18, 2003 June 19, 2003 6 SEcure Neighbor Discovery (SEND) 7 draft-arkko-send-ndopt-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on December 18, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 IPv6 nodes use the Neighbor Discovery (ND) protocol to discover other 39 nodes on the link, to determine each other's link-layer addresses, to 40 find routers and to maintain reachability information about the paths 41 to active neighbors. If not secured, ND protocol is vulnerable to 42 various attacks. This document specifies security mechanisms for ND. 43 Contrary to the original ND specifications, these mechanisms do not 44 make use of IPsec. 46 The purpose of this draft is to present an alternative to the current 47 approach in the Working Group. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3. Neighbor and Router Discovery Overview . . . . . . . . . . 6 54 4. Secure Neighbor Discovery Overview . . . . . . . . . . . . 9 55 5. Neighbor Discovery Options . . . . . . . . . . . . . . . . 10 56 5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . 10 57 5.1.1 Processing Rules for Senders . . . . . . . . .12 58 5.1.2 Processing Rules for Receivers . . . . . . . .12 59 5.2 Signature Option . . . . . . . . . . . . . . . . . . 13 60 5.2.1 Processing Rules for Senders . . . . . . . . .14 61 5.2.2 Processing Rules for Receivers . . . . . . . .15 62 5.2.3 Configuration . . . . . . . . . . . . . . . .15 63 5.3 Timestamp Option . . . . . . . . . . . . . . . . . . 17 64 5.4 Nonce Option . . . . . . . . . . . . . . . . . . . . 18 65 5.5 Proxy Neighbor Discovery . . . . . . . . . . . . . . 19 66 6. Authorization Delegation Discovery . . . . . . . . . . . . 20 67 6.1 Delegation Chain Solicitation Message Format . . . . 20 68 6.2 Delegation Chain Advertisement Message Format . . . 22 69 6.3 Trusted Root Option . . . . . . . . . . . . . . . . 24 70 6.4 Certificate Option . . . . . . . . . . . . . . . . . 25 71 6.5 Router Authorization Certificate Format . . . . . . 26 72 6.5.1 Field Values . . . . . . . . . . . . . . . . .27 73 6.6 Processing Rules for Routers . . . . . . . . . . . . 28 74 6.7 Processing Rules for Hosts . . . . . . . . . . . . . 29 75 7. Securing Neighbor Discovery with SEND . . . . . . . . . . 32 76 7.1 Neighbor Solicitation Messages . . . . . . . . . . . 32 77 7.1.1 Sending Secure Neighbor Solicitations . . . .32 78 7.1.2 Receiving Secure Neighbor Solicitations . . .32 79 7.2 Neighbor Advertisement Messages . . . . . . . . . . 32 80 7.2.1 Sending Secure Neighbor Advertisements . . . .32 81 7.2.2 Receiving Secure Neighbor Advertisements . . .33 82 7.3 Other Requirements . . . . . . . . . . . . . . . . . 33 83 8. Securing Router Discovery with SEND . . . . . . . . . . . 34 84 8.1 Router Solicitation Messages . . . . . . . . . . . . 34 85 8.1.1 Sending Secure Router Solicitations . . . . .34 86 8.1.2 Receiving Secure Router Solicitations . . . .34 87 8.2 Router Advertisement Messages . . . . . . . . . . . 34 88 8.2.1 Sending Secure Router Advertisements . . . . .34 89 8.2.2 Receiving Secure Router Advertisements . . . .35 90 8.3 Redirect Messages . . . . . . . . . . . . . . . . . 35 91 8.3.1 Sending Redirects . . . . . . . . . . . . . .35 92 8.3.2 Receiving Redirects . . . . . . . . . . . . .35 93 8.4 Other Requirements . . . . . . . . . . . . . . . . . 36 94 9. Co-Existence of SEND and ND . . . . . . . . . . . . . . . 37 95 10. Performance Considerations . . . . . . . . . . . . . . . . 38 96 11. Security Considerations . . . . . . . . . . . . . . . . . 39 97 11.1 Threats to the Local Link Not Covered by SEND . . . 39 98 11.2 How SEND Counters Threats to Neighbor Discovery . . 39 99 11.2.1 Neighbor Solicitation/Advertisement Spoofing .39 100 11.2.2 Neighbor Unreachability Detection Failure . .41 101 11.2.3 Duplicate Address Detection DoS Attack . . . .41 102 11.2.4 Router Solicitation and Advertisement Attacks 41 103 11.2.5 Replay Attacks . . . . . . . . . . . . . . . .41 104 11.2.6 Neighbor Discovery DoS Attack . . . . . . . .42 105 11.3 Attacks against SEND Itself . . . . . . . . . . . . 42 106 12. IANA Considerations . . . . . . . . . . . . . . . . . . . 44 107 13. Comparison to AH-Based Approach . . . . . . . . . . . . . 45 108 Normative References . . . . . . . . . . . . . . . . . . . 48 109 Informative References . . . . . . . . . . . . . . . . . . 50 110 Author's Address . . . . . . . . . . . . . . . . . . . . . 51 111 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 52 112 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 53 113 C. IPR Considerations . . . . . . . . . . . . . . . . . . . . 54 114 Intellectual Property and Copyright Statements . . . . . . 55 116 1. Introduction 118 IPv6 defines the Neighbor Discovery (ND) protocol in RFC 2461 [6]. 119 Nodes on the same link use the ND protocol to discover each other's 120 presence, to determine each other's link-layer addresses, to find 121 routers and to maintain reachability information about the paths to 122 active neighbors. The ND protocol is used both by hosts and routers. 123 Its functions include Router Discovery (RD), Address Auto- 124 configuration, Address Resolution, Neighbor Unreachability Detection 125 (NUD), Duplicate Address Detection (DAD), and Redirection. 127 RFC 2461 called for the use of IPsec for protecting the ND messages. 128 However, it turns out that in this particular application IPsec can 129 only be used with a manual configuration of security associations due 130 to chicken-and-egg problems in using IKE [23, 21] before ND is 131 operational. Furthermore, the number of such manually configured 132 security associations needed for protecting ND is impractically large 133 [24]. Finally, RFC 2461 did not specify detailed instructions for 134 using IPsec to secure ND. 136 Section 4 describes our overall approach to securing ND. This 137 approach involves the use of new ND options to carry public-key based 138 signatures. A zero-configuration mechanism is used for showing 139 address ownership, and routers are certified by a trusted root. The 140 formats, procedures, and cryptographic mechanisms for the 141 zero-configuration mechanism are described in a related specification 142 [27]. 144 Section 6 describes the mechanism for distributing certificate chains 145 to establish authorization delegation chain to a common trusted root. 146 The new ND options are discussed in Section 5, and Section 8 show how 147 to apply these components to securing Neighbor and Router Discovery. 149 Finally, Section 9 discusses the co-existence of secure and 150 non-secure Neighbor Discovery on the same link, Section 10 discusses 151 performance considerations, and Section 11 discusses security 152 considerations for SEND. 154 2. Terms 156 Authorization Certificate (AC) 158 The signer of an authorization certificate has authorized the 159 entity designated in the certificate for a specific task or 160 service. 162 Authorization Delegation Discovery (ADD) 164 This is a process through which SEND nodes can acquire a 165 certificate chain from a peer node to a trusted root. 167 Cryptographically Generated Addresses (CGAs) 169 A technique [27, 31] where the address of the node is 170 cryptographically generated from the public key of the node and 171 some other parameters using a one-way hash function. 173 Duplicate Address Detection (DAD) 175 This mechanism defined in RFC 2462 [7] assures that two IPv6 nodes 176 on the same link are not using the same addresses. 178 Internet Control Message Protocol version 6 (ICMPv6) 180 The IPv6 control signaling protocol. Neighbor Discovery is a part 181 of ICMPv6. 183 Neighbor Discovery (ND) 185 The IPv6 Neighbor Discovery protocol [6]. 187 Neighbor Unreachability Detection (NUD) 189 This mechanism defined in RFC 2461 [6] is used for tracking the 190 reachability of neighbors. 192 Nonce 194 Nonces are random numbers generated by a node. In SEND, they are 195 used to ensure that a particular advertisement is linked to the 196 solicitation that triggered it. 198 3. Neighbor and Router Discovery Overview 200 IPv6 Neighbor and Router Discovery have several functions. Many of 201 these functions are overloaded on a few central message types such as 202 the ICMPv6 Neighbor Discovery message. In this section we explain 203 some of these tasks and their effects in order to understand better 204 how the messages should be treated. Where this section and the 205 original Neighbor Discovery RFCs are in conflict, the original RFCs 206 take precedence. 208 In IPv6, many of the tasks traditionally done at lower layers such as 209 ARP have been moved to the IP layer. As a consequence, unified 210 mechanisms can be applied across link layers, security mechanisms or 211 other extensions can be adopted more easily, and a clear separation 212 of the roles between the IP and link layer can be achieved. 214 The main functions of IPv6 Neighbor Discovery are as follows: 216 o Neighbor Unreachability Detection (NUD) is used for tracking the 217 reachability of neighbors, both hosts and routers. NUD is defined 218 in Section 7.3 of RFC 2461 [6]. NUD is security-sensitive, 219 because an attacker could falsely claim that reachability exists 220 when it in fact does not. 222 o Duplicate Address Detection (DAD) is used for preventing address 223 collisions [7]. A node that intends to assign a new address to 224 one of its interfaces runs first the DAD procedure to verify that 225 other nodes are not using the same address. Since the outlined 226 rules forbid the use of an address until it has been found unique, 227 no higher layer traffic is possible until this procedure has 228 completed. Thus, preventing attacks against DAD can help ensure 229 the availability of communications for the node in question. 231 o Address Resolution is similar to IPv4 ARP [20]. The Address 232 Resolution function resolves a node's IPv6 address to the 233 corresponding link-layer address for nodes on the link. Address 234 Resolution is defined in Section 7.2 of RFC 2461 [6] and it is 235 used for hosts and routers alike. Again, no higher level traffic 236 can proceed until the sender knows the hardware address of the 237 destination node or the next hop router. Note that like its 238 predecessor in ARP, IPv6 Neighbor Discovery does not check the 239 source link layer address against the information learned through 240 Address Resolution. This allows for an easier addition of network 241 elements such as bridges and proxies, and eases the stack 242 implementation requirements as less information needs to be passed 243 from layer to layer. 245 o Address Autoconfiguration is used for automatically assigning 246 addresses to a host [7]. This allows hosts to operate without 247 configuration related to IP connectivity. The Address 248 Autoconfiguration mechanism is stateless, where the hosts use 249 prefix information delivered to them during Router Discovery to 250 create addresses, and then test these addresses for uniqueness 251 using the DAD procedure. A stateful mechanism, DHCPv6 [25], 252 provides additional Autoconfiguration features. Router and Prefix 253 Discovery and Duplicate Address Detection have an effect to the 254 Address Autoconfiguration tasks. 256 o The Redirect function is used for automatically redirecting hosts 257 to an alternate router. Redirect is specified in Section 8 of RFC 258 2461 [6]. It is similar to the ICMPv4 Redirect message [19]. 260 o The Router Discovery function allows IPv6 hosts to discover the 261 local routers on an attached link. Router Discovery is described 262 in Section 6 of RFC 2461 [6]. The main purpose of Router 263 Discovery is to find neighboring routers that are willing to 264 forward packets on behalf of hosts. Prefix discovery involves 265 determining which destinations are directly on a link; this 266 information is necessary in order to know whether a packet should 267 be sent to a router or to the destination node directly. 268 Typically, address autoconfiguration and other tasks can not 269 proceed until suitable routers and prefixes have been found. 271 The Neighbor Discovery messages follow the ICMPv6 message format and 272 ICMPv6 types from 133 to 137. The IPv6 Next Header value for ICMPv6 273 is 58. The actual Neighbor Discovery message includes an ND message 274 header consisting of ICMPv6 header and ND message-specific data, and 275 zero or more ND options: 277 <------------ND Message-----------------> 278 *-------------------------------------------------------------* 279 | IPv6 Header | ICMPv6 | ND message- | ND Message | 280 | Next Header = 58 | Header | specific | Options | 281 | (ICMPv6) | | data | | 282 *-------------------------------------------------------------* 283 <--ND Message header---> 285 The ND message options are formatted in the Type-Length-Value format. 287 All IPv6 ND protocol functions are realized using the following 288 messages: 290 ICMPv6 Type Message 291 ------------------------------------ 292 133 Router Solicitation (RS) 293 134 Router Advertisement (RA) 294 135 Neighbor Solicitation (NS) 295 136 Neighbor Advertisement (NA) 296 137 Redirect 298 The functions of the ND protocol are realized using these messages as 299 follows: 301 o Router Discovery uses the RS and RA messages. 303 o Duplicate Address Detection uses the NS and NA messages. 305 o Address Autoconfiguration uses the NS, NA, RS, and RA messages. 307 o Address Resolution uses the NS and NA messages. 309 o Neighbor Unreachability Detection uses the NS and NA messages. 311 o Redirect uses the Redirect message. 313 The destination addresses used in these messages are as follows: 315 o Neighbor Solicitation: The destination address is either the 316 solicited-node multicast address, unicast address, or an anycast 317 address. 319 o Neighbor Advertisement: The destination address is either a 320 unicast address or the All Nodes multicast address [1]. 322 o Router Solicitation: The destination address is typically the All 323 Routers multicast address [1]. 325 o Router Advertisement: The destination address can be either a 326 unicast or the All Nodes multicast address [1]. Like the 327 solicitation message, the advertisement is also local to the link 328 only. 330 o Redirect: This message is always sent from the router's link-local 331 address to the source address of the packet that triggered the 332 Redirect. Hosts verify that the IP source address of the Redirect 333 is the same as the current first-hop router for the specified ICMP 334 Destination Address. Rules in [1] dictate that unspecified, 335 anycast, or multicast addresses may not be used as source 336 addresses. Therefore, the destination address will always be a 337 unicast address. 339 4. Secure Neighbor Discovery Overview 341 New Neighbor Discovery options are used in to protect Neighbor and 342 Router Discovery messages. This specification introduces these 343 options, an authorization delegation discovery process, an address 344 ownership proof mechanism, and requirements for the use of these 345 components for Neighbor Discovery. 347 The components of the solution specified in this document are as 348 follows: 350 o Trusted roots are expected to certify the authority of routers. A 351 host and a router must have at least one common trusted root 352 before the host can adopt the router as its default router. 353 Optionally, an authorization certificate can specify the prefixes 354 for which the router is allowed to act as a router. Delegation 355 Chain Solicitation and Advertisement messages are used to discover 356 a certificate chain to the trusted root without requiring the 357 actual Router Discovery messages to carry lengthy certificate 358 chains. 360 o Cryptographically Generated Addresses are used to assure that the 361 sender of a Neighbor or Router Advertisement is the owner of an 362 the claimed address. A public-private key pair needs to be 363 generated by all nodes before they can claim an address. 365 o A new Neighbor Discovery option, the Signature option is used to 366 protect all messages relating to Neighbor and Router discovery. 368 Public key signatures are used. The trust to the public key is 369 established either with the authorization delegation process or 370 the address ownership proof mechanism, depending on configuration 371 and the type of the message protected. 373 o In order to prevent replay attacks, the new Neighbor Discovery 374 options Timestamp and Nonce are used. Given that Neighbor and 375 Router Discovery messages are in some cases sent to multicast 376 addresses, the Timestamp option offers replay protection without 377 previously established state or sequence numbers. In addition, 378 solicitation - advertisement pairs are protected through the Nonce 379 option. 381 5. Neighbor Discovery Options 383 The following new ND mechanisms are required in SEND: 385 o The CGA option can be present in all Neighbor Discovery messages. 387 o The Signature option is required in all Neighbor Discovery 388 messages. 390 o The Timestamp option is required in all Neighbor Discovery 391 advertisements and Redirects. 393 o The Nonce option is required in all Neighbor Discovery 394 solicitations, and for all solicited advertisements. 396 o Proxy Neighbor Discovery is not supported in this specification 397 (it will be specified in a future document). 399 5.1 CGA Option 401 The CGA option allows the verification of the sender's CGA. The 402 format of the CGA option is described in the following: 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Type | Length | Reserved | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | | 410 . . 411 . Key Information . 412 . . 413 | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | | 416 . . 417 . Padding . 418 . . 419 | | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 The meaning of the fields is described below: 424 Type 426 TBD for CGA. 428 Length 430 The length of the option in units of 8 octets, i.e., 2. 432 Reserved 434 This is an 16-bit field reserved for future use. The value MUST 435 be initialized to zero by the sender, and MUST be ignored by the 436 receiver.. 438 Key Information 440 This variable length field contains the public key of the sender. 441 It also may contain some other additional information which is 442 necessary when CGA is used. 444 The contents of the Key Information field are represented as ASN.1 445 DER-encoded data item of the following type: 447 SendKeyInformation ::= CGAParameters 449 CGAParameters ::= SEQUENCE { 450 publicKey SubjectPublicKeyInfo, 451 auxParameters CGAAuxParameters } 453 (The normative definition of the type CGAParameters is in in 454 [27]). 456 The verification of the CGA is based on the contents of the 457 CGAParameters structure. 459 This specification requires that if both the CGA option and the 460 Signature option are present, then the publicKey field in the 461 former option MUST be the public key referred to in the Key Hash 462 field in the latter option. Packets received with two different 463 keys MUST be silently discarded. Note that a future extension may 464 provide a mechanism which allows the owner of an address and the 465 signer to be different parties. 467 The length of the Key Information field is determined by the ASN.1 468 encoding. 470 Padding 472 This variable length field begins after the ASN.1 encoding of the 473 previous field has ends, and continues to the end of the option, 474 as specified by the Length field. 476 5.1.1 Processing Rules for Senders 478 A node sending a message using the CGA option MUST construct the 479 message as follows: 481 The Key Information field in the Authentication Data field is set to 482 the SendKeyInformation structure according to the rules presented 483 above and in [27]. The used public key is taken from configuration. 485 An address MUST be constructed as specified in [27]. Depending on 486 the type of the message, this address appears in different places: 488 Redirect 490 The address MUST be the source address of the message. 492 Neighbor Solicitation 494 The address MUST be the Target Address for solicitations sent for 495 the purpose of Duplicate Address Detection, and source address of 496 the message otherwise. 498 Neighbor Advertisement 500 The address MUST be the source address of the message. 502 Router Solicitation 504 The address MUST be the source address of the message, unless it 505 is the unspecified address. 507 Router Advertisement 509 The address MUST be the source address of the message. 511 5.1.2 Processing Rules for Receivers 513 A message containing a Signature option MUST be checked as follows: 515 If the use of CGA has been configured, we require the receiving node 516 to verify the source address of the packet using the algorithm 517 described in Section 5 of [27]. The inputs for the algorithm are the 518 contents of the CGAParameters structure from the Key Information 519 field, the source address of the packet, and the minimum acceptable 520 Sec value from the security association. If the CGA verification is 521 successful, the recipient proceeds with the cryptographically more 522 time consuming check of the signature. 524 Note that a receiver which does not support CGA or has not specified 525 its use in its security associations can still verify packets using 526 trusted roots, even if CGA had been used on a packet. The CGA 527 property of the address is simply left untested. 529 5.2 Signature Option 531 The Signature option allows public-key based signatures to be 532 attached to Neighbor Discovery messages. Both trusted root 533 authentication and CGAs can be used. The format of the Signature 534 option is described in the following: 536 0 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Type | Length | Reserved | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | | 542 | Key Hash | 543 | | 544 | | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | | 547 . . 548 . Digital Signature . 549 . . 550 | | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | | 553 . . 554 . Padding . 555 . . 556 | | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 The meaning of the fields is described below: 561 Type 563 TBD for Signature. 565 Length 567 The length of the option in units of 8 octets, i.e., 2. 569 Reserved 571 This is an 16-bit field reserved for future use. The value MUST 572 be initialized to zero by the sender, and MUST be ignored by the 573 receiver.. 575 Key Hash 577 This 128 bit field contains a SHA1 hash of the public key used for 578 the constructing the signature. Its purpose is to associate the 579 signature to a particular key known by the receiver. Such a key 580 can be either stored in the certificate cache of the receiver, or 581 be received in the CGA option in the same message. 583 Digital Signature 585 This variable length field contains the signature made using the 586 sender's private key, over the the whole packet as defined by the 587 usual AH rules [3]. The signature is made using the RSA algorithm 588 and MUST be encoded as private key encryption in PKCS #1 format 589 [17]. 591 This field starts after the Key Hash field. The length of the 592 Digital Signature field is determined by the PKCS #1 encoding. 594 Padding 596 This variable length field begins after the PKCS #1 encoding of 597 the previous field has ends, and continues to the end of the 598 option, as specified by the Length field. 600 5.2.1 Processing Rules for Senders 602 A node sending a message using the Signature option MUST construct 603 the message as follows: 605 o The message is constructed in its entirety. 607 o The Signature option is added as the last option in the message. 609 o For the purpose of constructing a signature, the following data 610 items are appended: 612 * The source address of the message. 614 * The destination address of the message. 616 * The contents of the message, starting from the ICMPv6 header, 617 up to and including the Key Information field in the Signature 618 option. The Signature and the Padding fields are not included. 620 o The message, in the form defined above, is signed using the 621 configured private key, and the resulting PCKS #1 signature is put 622 to the Digital Signature field. 624 5.2.2 Processing Rules for Receivers 626 A message containing a Signature option MUST be checked as follows: 628 o The Signature option appears as the last option. 630 o The Key Information and Digital Signature fields have correct 631 encoding, and do not exceed the length of the Authentication Data 632 field. 634 o The Digital Signature verification shows that it has been 635 calculated as specified in the previous section. 637 o If the use of a trusted root has been configured, a valid 638 authorization delegation chain is known between the receiver's 639 trusted root and the sender's public key. 641 Note that the receiver may verify just the CGA property of a 642 packet, even if the sender has used a trusted root as well. 644 Messages that do not pass all the above tests MUST be silently 645 discarded. 647 5.2.3 Configuration 649 All nodes that support the reception of the Signature option MUST 650 record the following configuration information: 652 authorization method 654 This parameter determines the mechanisms through which the 655 authority of the sender is determined. It can have four values: 657 trusted root 659 The authority of the sender is verified as described in Section 660 6.5. The sender may have additional authorization through the 661 use of CGAs, but this is neither required nor verified. 663 CGA 665 The CGA property of the sender's address is verified as 666 described in [27]. The sender may have additional authority 667 through a trusted root, but this is neither required nor 668 verified. 670 trusted root and CGA 672 Both the trusted root and the CGA verification is required. 674 trusted root or CGA 676 Either the trusted root or the CGA verification is required. 678 root 680 The public key of the trusted root, if authorization method is not 681 set CGA. 683 minbits 685 The minimum acceptable key length for peer public keys (and any 686 intermediaries between the trusted root and the peer). The 687 default SHOULD be 1024 bits. Implementations MAY also set an 688 upper limit in order to limit the amount of computation they need 689 to perform when verifying packets that use these security 690 associations. 692 minSec 694 The minimum acceptable Sec value, if CGA verification is required 695 (see Section 2 in [27]. This parameter is intended to facilitate 696 future extensions and experimental work. The minSec value SHOULD 697 always be set to zero. 699 All nodes that support the sending of the Signature option MUST 700 record the following configuration information: 702 keypair 704 A public-private key pair. If authorization delegation is in use, 705 there must exist a delegation chain from a trusted root to this 706 key pair. 708 CGA flag 710 A flag that indicates whether or not the CGA is used. 712 CGA parameters 714 Optionally any information required to construct CGAs, including 715 the used Sec value and nonce, and the CGA itself. 717 5.3 Timestamp Option 719 The purpose of the Timestamp option is to ensure that unsolicited 720 advertisements and redirects have not been replayed. The format of 721 the Timestamp option is described in the following: 723 0 1 2 3 724 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 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Type | Length | Reserved | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 728 | | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | | 731 + Timestamp + 732 | | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 Where the fields are as follows: 737 Type 739 TBD for Timestamp. 741 Length 743 The length of the option in units of 8 octets, i.e., 2. 745 Reserved 747 This is a 48-bit field reserved for future use. The value MUST be 748 initialized to zero by the sender, and MUST be ignored by the 749 receiver.. 751 Timestamp 753 This 64 bit unsigned integer field contains a timestamp. The 754 format is 64 bits, and the contents are the number of milliseconds 755 since January 1, 1970 00:00 UTC. 757 Senders SHOULD set the Timestamp field to the current time. 759 Receivers SHOULD be configured with an allowed Delta value. They 760 SHOULD maintain a cache of the last received timestamp value from 761 each specific source address within this time period. Receivers 762 SHOULD then check the Timestamp field as follows: 764 o A packet with a Timestamp field value beyond the current time plus 765 or minus the allowed Delta value MUST be silently discarded. 767 Recommended default value for the allowed Delta is 3,600 seconds. 769 o A packet accepted according to the above rule MUST be checked 770 against the last received timestamp value from the given source 771 address. A packet that has already been seen from the same source 772 with the same or lower Timestamp field value MUST be silently 773 discarded. 775 o If packet passes both of the above tests, a new timestamp value 776 MUST be registered in the cache for the given source address. 778 o If the cache becomes full, the receiver SHOULD temporarily reduce 779 the Delta value for that source address so that all messages 780 within that value can still be stored. 782 5.4 Nonce Option 784 The purpose of the Nonce option is to ensure that an advertisement is 785 a fresh response to a solicitation sent earlier by this same node. 786 The format of the Nonce option is as described in the following: 788 0 1 2 3 789 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 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Type | Length | Nonce ... | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 793 | | 794 . . 795 . . 796 | | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 Where the fields are as follows: 801 Type 803 TBD for Nonce. 805 Length 807 The length of the option (including the Type, Length, and Nonce 808 fields) in units of 8 octets. 810 Nonce 812 This field contains a random number selected by the sender of the 813 solicitation message. The length of the number MUST be at least 6 814 bytes. 816 5.5 Proxy Neighbor Discovery 818 The Target Address in Neighbor Advertisement is required to be equal 819 to the source address of the packet, except in the case of proxy 820 Neighbor Discovery. Proxy Neighbor Discovery is discussed in another 821 specification. 823 6. Authorization Delegation Discovery 825 Several protocols, including IPv6 Neighbor Discovery, allow a node to 826 automatically configure itself based on information it learns shortly 827 after connecting to a new link. It is particularly easy for "rogue" 828 routers to be configured, and it is particularly difficult for a 829 network node to distinguish between valid and invalid sources of 830 information when the node needs this information before communicating 831 off-link. 833 Since the newly-connected node likely can not communicate off-link, 834 it can not be responsible for searching information to help validate 835 the router; however, given a chain of appropriately signed 836 certificates, it can check someone else's search results and conclude 837 that a particular message comes from an authorized source. 838 Similarly, the router, which is already connected to the network, can 839 if necessary communicate off-link and construct the certificate 840 chain. 842 The Secure Neighbor Discovery protocol introduces two new ICMPv6 843 messages that are used between hosts and routers to allow the client 844 to learn the certificate chain with the assistance of the router. 845 Where hosts have certificates from a trusted root, these messages MAY 846 also optionally be used between hosts to acquire the peer's 847 certificate chain. 849 The Delegation Chain Solicitation message is sent by hosts when they 850 wish to request the certificate chain between a router and the one of 851 the hosts' trusted roots. The Delegation Chain Advertisement message 852 is sent as an answer to this message, or periodically to the All 853 Nodes multicast address. These messages are separate from the rest 854 of the Neighbor Discovery in order to reduce the effect of the 855 potentially voluminous certificate chain information to other 856 messages. 858 The Authorization Delegation Discovery process does not exclude other 859 forms of discovering the certificate chains. For instance, during 860 fast movements mobile nodes may learn information - including the 861 certificate chains - of the next router from the previous router. 863 6.1 Delegation Chain Solicitation Message Format 865 Hosts send Delegation Chain Solicitations in order to prompt routers 866 to generate Delegation Chain Advertisements quickly. 868 0 1 2 3 869 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 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Type | Code | Checksum | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Identifier | Reserved | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Options ... 876 +-+-+-+-+-+-+-+-+-+-+-+- 878 IP Fields: 880 Source Address 882 An IP address assigned to the sending interface, or the 883 unspecified address if no address is assigned to the sending 884 interface. 886 Destination Address 888 Typically the all-routers multicast address, the solicited-node 889 multicast address, or the address of the hosts' default router. 891 Hop Limit 893 255 895 ICMP Fields: 897 Type 899 TBD for Delegation Chain Solicitation. 901 Code 903 0 905 Checksum 907 The ICMP checksum [8].. 909 Identifier 911 This 16 bit unsigned integer field acts as an identifier to 912 help match advertisements to solicitations. The Identifier 913 field MUST NOT be zero. 915 Reserved 917 This field is unused. It MUST be initialized to zero by the 918 sender and MUST be ignored by the receiver. 920 Valid Options: 922 Trusted Root 924 One or more trusted roots that the client is willing to accept. 926 Future versions of this protocol may define new option types. 927 Receivers MUST silently ignore any options they do not recognize 928 and continue processing the message. 930 6.2 Delegation Chain Advertisement Message Format 932 Routers send out Delegation Chain Advertisement messages 933 periodically, or in response to a Delegation Chain Solicitation. 935 0 1 2 3 936 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 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Type | Code | Checksum | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Identifier | Component | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Reserved | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Options ... 945 +-+-+-+-+-+-+-+-+-+-+-+- 947 IP Fields: 949 Source Address 951 MUST be a unicast address assigned to the interface from which 952 this message is sent. 954 Destination Address 956 Either the solicited-node multicast address of the receiver or 957 the all-nodes multicast address. 959 Hop Limit 961 255 963 ICMP Fields: 965 Type 967 TBD for Delegation Chain 968 Advertisement. 970 Code 972 0 974 Checksum 976 The ICMP checksum [8].. 978 Identifier 980 This 16 bit unsigned integer field acts as an identifier to 981 help match advertisements to solicitations. The Identifier 982 field MUST be zero for unsolicited advertisements and MUST NOT 983 be zero for solicited advertisements. 985 Component 987 This is a 16 bit unsigned integer field used for informing the 988 receiver which certificate is being sent, and how many are 989 still left to be sent in the whole chain. 991 A single advertisement MUST be broken into separately sent 992 components if there is more than one Certificate option, in 993 order to avoid excessive fragmentation at the IP layer. Unlike 994 the fragmentation at the IP layer, individual components of an 995 advertisement may be stored and taken in use before all the 996 components have arrived; this makes them slightly more reliable 997 and less prone to Denial-of-Service attacks. 999 The first message in a N-component advertisement has the 1000 Component field set to N-1, the second set to N-2, and so on. 1001 Zero indicates that there are no more components coming in this 1002 advertisement. 1004 The components MUST be ordered so that the trusted root end of 1005 the chain is the one sent first, each certificate sent after it 1006 can be verified with previously sent certificates, and the 1007 certificate of the sender comes last. 1009 Reserved 1011 This field is unused. It MUST be initialized to zero by the 1012 sender and MUST be ignored by the receiver. 1014 Valid Options: 1016 Certificate 1018 One certificate is provided in Certificate option, to establish 1019 a (part of) certificate chain to a trusted root. 1021 Trusted Root 1023 Zero or more Trusted Root options may be included to help 1024 receivers decide which advertisements are useful for them. If 1025 present, these options MUST appear in the first component of a 1026 multi-component advertisement. 1028 Future versions of this protocol may define new option types. 1029 Receivers MUST silently ignore any options they do not recognize 1030 and continue processing the message. 1032 6.3 Trusted Root Option 1034 The format of the Trusted Root option is as described in the 1035 following: 1037 0 1 2 3 1038 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 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | Type | Length | Name Type | Name Length | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | Name ... 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 Where the fields are as follows: 1047 Type 1049 TBD for Trusted Root. 1051 Length 1053 The length of the option (including the Type, Length, Name Type, 1054 Name Length, and Name fields) in units of 8 octets. 1056 Name Type 1058 The type of the name included in the Name field. This 1059 specification defines only one legal value for this field: 1061 1 FQDN 1063 Name Length 1065 The length of the Name field, in bytes. Octets beyond this length 1066 but within the length specified by the Length field are padding 1067 and MUST be set to zero by senders and ignored by receivers. 1069 Name 1071 When the Name Type field is set to 1, the Name field contains the 1072 Fully Qualified Domain Name of the trusted root, for example 1073 "trustroot.operator.com". 1075 6.4 Certificate Option 1077 The format of the certificate option is as described in the 1078 following: 1080 0 1 2 3 1081 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 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | Type | Length | Cert Type | Pad Length | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Certificate ... 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 Where the fields are as follows: 1090 Type 1092 TBD for Certificate. 1094 Length 1096 The length of the option (including the Type, Length, Cert Type, 1097 Pad Length, and Certificate fields) in units of 8 octets. 1099 Cert Type 1101 The type of the certificate included in the Name field. This 1102 specification defines only one legal value for this field: 1104 1 X.509 Certificate 1106 Pad Length 1108 The amount of padding beyond the end of the Certificate field but 1109 within the length specified by the Length field. Padding MUST be 1110 set to zero by senders and ignored by receivers. 1112 Certificate 1114 When the Cert Type field is set to 1, the Certificate field 1115 contains an X.509 certificate [16]. 1117 6.5 Router Authorization Certificate Format 1119 The certificate chain of a router terminates in a router 1120 authorization certificate that authorizes a specific IPv6 node as a 1121 router. Because authorization chains are not common practice in the 1122 Internet at the time this specification is being written, the chain 1123 MUST consist of standard Public Key Certificates (PKC, in the sense 1124 of [11]) for identity from the trusted root shared with the host to 1125 the router. This allows the host to anchor trust for the router's 1126 public key in the trusted root. The last item in the chain is an 1127 Authorization Certificate (AC, in the sense of [12]) authorizing the 1128 router's right to route. Stronger certification is necessary here 1129 than for CGAs because the right to route must be granted by an 1130 authorizing agency. Future versions of this specification may 1131 include provision for full authorization certificate chains, should 1132 they become common practice. 1134 SEND nodes MUST support the RFC 3281 X.509 attribute certificate 1135 format [12] as the default format for router authorization 1136 certificates, and MAY support other formats. Router authorization 1137 certificates MUST be signed by the network operator or other trusted 1138 third party whose PKC is above the router's PKC in the delegation 1139 chain. Routers MAY advertise multiple ACs if the trust delegation 1140 obtains from different trust roots, and the authorized prefixes in 1141 those certificates MAY be disjoint. A router SHOULD only advertise 1142 one AC corresponding to one trust root and all interfaces and 1143 prefixes covered by that trust root MUST be in the AC. 1145 In the attribute certificate, the GeneralName type MUST be either a 1146 dNSName or iPAddress for the router, unless otherwise specified by 1147 RFC 3281. If the GeneralName attribute is a dNSName, it MUST be 1148 resolvable to a global unicast address assigned to the router. If 1149 the GeneralName attribute is an iPAddress, it MUST be a global 1150 unicast address assigned to the router. For purposes of facilitating 1151 renumbering, a dNSName SHOULD be used. However, hosts MUST NOT use a 1152 dNSName or iPAddress for validating the certificate. The router's 1153 public key hash, stored in the 1154 acinfo.holder.objectDigestInfo.objectDigest field of the certificate 1155 provides the definitive validation. As explained in Section 8.2, the 1156 addresses from the certificate can be matched against the global 1157 addresses claimed in the Router Advertisement. 1159 6.5.1 Field Values 1161 acinfo.holder.entityName 1163 This field MAY contain one or several entityNames, of type dNSName 1164 or iPAddress, referring to global address(es) belonging to the 1165 router. 1167 acinfo.objectDigestInfo.digestedObjectType 1169 This field MUST be present and of type (1), publicKey. 1171 acinfo.holder.digestAlgorithm 1173 This field MUST indicate id-sha1 as indicated in RFC 3279 [10]. 1175 acinfo.objectDigestInfo.objectDigest 1177 This field MUST be a SHA-1 digest over either a PKCS#1 [17] (RSA) 1178 or an RFC 3279 Section 2.3.2 representation [10] (DSA) 1179 representation of the router's public key. If this digest does 1180 not match the digest of the router's public key from its PKC, a 1181 node MUST discard the certificate. 1183 acinfo.issuer.v2form.issuerName 1185 The field MUST contain the distinguished name from the PKC used to 1186 sign the router AC. 1188 acinfo.attrCertValidityPeriod 1190 A node MUST NOT accept a certificate if the validity period has 1191 ended or has not yet started. 1193 acinfo.attributes 1195 This field MUST contain a list of prefixes that the router is 1196 authorized to route, or the unspecified prefix if the router 1197 is allowed to route any prefix. The field has the following 1198 type: 1200 name: AuthorizedSubnetPrefix 1201 OID: {id-rcert} 1202 Syntax: iPAddress 1203 values: Multiple allowed 1204 Multiple prefix values are allowed. 1206 The details of the above syntax are specified in Section 2.2.3.8 1207 of [14]. 1209 If the router is authorized only to route specific prefixes, the 1210 ipAddress values consist of IPv6 addresses in standard RFC 3513 1211 [13] prefix format. One iPAddress value appears for each prefix 1212 routed by the router. If the router is authorized to route any 1213 prefix, a single ipAddress value appears with the value of the 1214 unspecified address. 1216 6.6 Processing Rules for Routers 1218 Routers SHOULD possess a key pair and certificate from at least one 1219 certificate authority. 1221 A router MUST silently discard any received Delegation Chain 1222 Solicitation messages that do not satisfy all of the following 1223 validity checks: 1225 o The IP Hop Limit field has a value of 255, i.e., the packet could 1226 not possibly have been forwarded by a router. 1228 o If the message includes an IP Authentication Header, the message 1229 authenticates correctly. 1231 o ICMP Checksum is valid. 1233 o ICMP Code is 0. 1235 o ICMP length (derived from the IP length) is 8 or more octets. 1237 o Identifier field is non-zero. 1239 o All included options have a length that is greater than zero. 1241 The contents of the Reserved field, and of any unrecognized options, 1242 MUST be ignored. Future, backward-compatible changes to the protocol 1243 may specify the contents of the Reserved field or add new options; 1244 backward-incompatible changes may use different Code values. The 1245 contents of any defined options that are not specified to be used 1246 with Router Solicitation messages MUST be ignored and the packet 1247 processed in the normal manner. The only defined option that may 1248 appear is the Trusted Root option. A solicitation that passes the 1249 validity checks is called a "valid solicitation". 1251 Routers MAY send unsolicited Delegation Chain Advertisements for 1252 their trusted root. When such advertisements are sent, their timing 1253 MUST follow the rules given for Router Advertisements in RFC 2461 1254 [6]. The only defined option that may appear is the Certificate 1255 option. At least one such option MUST be present. Router SHOULD 1256 also include at least one Trusted Root option to indicate the trusted 1257 root on which the Certificate is based. 1259 In addition to sending periodic, unsolicited advertisements, a router 1260 sends advertisements in response to valid solicitations received on 1261 an advertising interface. A router MUST send the response to the 1262 all-nodes multicast address, if the source address in the 1263 solicitation was the unspecified address. If the source address was 1264 a unicast address, the router MUST send the response to the 1265 solicited-node multicast address corresponding to the source address. 1267 In a solicited advertisement, the router SHOULD include suitable 1268 Certificate options so that a delegation chain to the solicited root 1269 can be established. The root is identified by the FQDN from the 1270 Trusted Root option being equal to an FQDN in the AltSubjectName 1271 field of the root's certificate. The router SHOULD include the 1272 Trusted Root option(s) in the advertisement for which the delegation 1273 chain was found. 1275 If the router is unable to find a chain to the requested root, it 1276 SHOULD send an advertisement without any certificates. In this case 1277 the router SHOULD include the Trusted Root options which were 1278 solicited. 1280 Rate limitation of Delegation Chain Advertisements is performed as 1281 specified for Router Advertisements in RFC 2461 [6]. 1283 6.7 Processing Rules for Hosts 1285 Hosts SHOULD possess the certificate of at least one certificate 1286 authority, and MAY possess their own key pair and certificate from 1287 this authority. 1289 A host MUST silently discard any received Delegation Chain 1290 Advertisement messages that do not satisfy all of the following 1291 validity checks: 1293 o IP Source Address is a unicast address. Note that routers may use 1294 multiple addresses, so this address not sufficient for the unique 1295 identification of routers. 1297 o IP Destination Address is either the all-nodes multicast address 1298 or the solicited-node multicast address corresponding to one of 1299 the unicast addresses assigned to the host. 1301 o The IP Hop Limit field has a value of 255, i.e., the packet could 1302 not possibly have been forwarded by a router. 1304 o If the message includes an IP Authentication Header, the message 1305 authenticates correctly. 1307 o ICMP Checksum is valid. 1309 o ICMP Code is 0. 1311 o ICMP length (derived from the IP length) is 16 or more octets. 1313 o All included options have a length that is greater than zero. 1315 The contents of the Reserved field, and of any unrecognized options, 1316 MUST be ignored. Future, backward-compatible changes to the protocol 1317 may specify the contents of the Reserved field or add new options; 1318 backward-incompatible changes may use different Code values. The 1319 contents of any defined options that are not specified to be used 1320 with Delegation Chain Advertisement messages MUST be ignored and the 1321 packet processed in the normal manner. The only defined option that 1322 may appear is the Certificate option. An advertisement that passes 1323 the validity checks is called a "valid advertisement". 1325 Hosts SHOULD store certificate chains retrieved in Delegation Chain 1326 Discovery messages if they start from a root trusted by the host. 1327 The certificates chains SHOULD be verified before storing them. 1328 Routers are required to send the certificates one by one, starting 1329 from the trusted root end of the chain. Except for temporary 1330 purposes to allow for message loss and reordering, hosts SHOULD NOT 1331 store certificates received in a Delegation Chain Advertisement 1332 unless they contain a certificate which can be immediately verified 1333 either to the trusted root or to a certificate which has been 1334 verified earlier. 1336 Note that it may be useful to cache this information and implied 1337 verification results for use over multiple attachments to the 1338 network. In order to use an advertisement for the verification of a 1339 specific Neighbor Discovery message, the host matches the key hash in 1340 acinfo.Holder.objectDigestInfo to the public key carried in the IPsec 1341 AH Authentication Data field. 1343 When an interface becomes enabled, a host may be unwilling to wait 1344 for the next unsolicited Delegation Chain Advertisement. To obtain 1345 such advertisements quickly, a host SHOULD transmit up to 1346 MAX_RTR_SOLICITATIONS Delegation Chain Solicitation messages each 1347 separated by at least RTR_SOLICITATION_INTERVAL seconds. Delegation 1348 Chain Solicitations SHOULD be sent after any of the following events: 1350 o The interface is initialized at system startup time. 1352 o The interface is reinitialized after a temporary interface failure 1353 or after being temporarily disabled by system management. 1355 o The system changes from being a router to being a host, by having 1356 its IP forwarding capability turned off by system management. 1358 o The host attaches to a link for the first time. 1360 o A movement has been indicated by lower layers or has been inferred 1361 from changed information in a Router Advertisement. 1363 o The host re-attaches to a link after being detached for some time. 1365 o A Router Advertisement has been received with a public key that is 1366 not stored in the hosts' cache of certificates, or there is no 1367 authorization delegation chain to the host's trusted root. 1369 Delegation Chain Solicitations MUST NOT be sent if the host has a 1370 currently valid certificate chain for the router to a trusted root, 1371 including the Attribute Certificate for the desired router (or host). 1373 A host MUST send Delegation Chain Solicitations either to the 1374 All-Routers multicast address, if it has not selected a default 1375 router yet, or to the default router's IP address if it has already 1376 been selected. 1378 If two hosts communicate with the solicitations and advertisements, 1379 the solicitations MUST be sent to the solicited-node multicast 1380 address of the receiver. The advertisements MUST be sent as 1381 specified above for routers. 1383 Delegation Chain Solicitations SHOULD be rate limited and timed 1384 similarly with Router Solicitations, as specified in RFC 2461 [6]. 1386 When processing a possible advertisement sent as a response to a 1387 solicitation, the host MAY prefer to process first those 1388 advertisements with the same Identifier field value as in the 1389 solicitation. This makes Denial-of-Service attacks against the 1390 mechanism harder (see Section 11.3). 1392 7. Securing Neighbor Discovery with SEND 1394 This section describes how to use the mechanisms from Section 5, 1395 Section 6, and the reference [27] in order to provide security for 1396 Neighbor Discovery. 1398 7.1 Neighbor Solicitation Messages 1400 All Neighbor Solicitation messages are protected with SEND. 1402 7.1.1 Sending Secure Neighbor Solicitations 1404 Secure Neighbor Solicitation messages are sent as described in RFC 1405 2461 and 2462, with the additional requirements listed in the 1406 following. 1408 All Neighbor Solicitation messages sent MUST contain the Nonce, 1409 Timestamp and Signature options, and MAY contain the CGA option. The 1410 Signature option MUST be configured with the sender's key pair, 1411 setting the authorization method and additional information as is 1412 desired. 1414 7.1.2 Receiving Secure Neighbor Solicitations 1416 Received Neighbor Solicitation messages are processed as described in 1417 RFC 2461 and 2462, with the additional SEND-related requirements 1418 listed in the following. 1420 Neighbor Solicitation messages received without the Nonce, Timestamp, 1421 or Signature option MUST be silently discarded. The Signature option 1422 MUST be configured with the expected authorization method, the 1423 minimum allowable key size, and optionally with the information 1424 related to the trusted root and the acceptable minSec value. 1426 7.2 Neighbor Advertisement Messages 1428 All Neighbor Advertisement messages are protected with SEND. 1430 7.2.1 Sending Secure Neighbor Advertisements 1432 Secure Neighbor Advertisement messages are sent as described in RFC 1433 2461 and 2462, with the additional requirements listed in the 1434 following. 1436 All Neighbor Advertisement messages sent MUST be sent with the 1437 Timestamp and Signature options and MAY be sent with the CGA option. 1438 The Signature option MUST be configured with the sender's key pair, 1439 setting the authorization method and additional information as is 1440 desired. 1442 Neighbor Advertisements sent in response to a Neighbor Solicitation 1443 MUST contain a copy of the Nonce option included in the solicitation. 1445 7.2.2 Receiving Secure Neighbor Advertisements 1447 Received Neighbor Advertisement messages are processed as described 1448 in RFC 2461 and 2462, with the additional SEND-related requirements 1449 listed in the following. 1451 Neighbor Advertisement messages received without the Timestamp and 1452 Signature options MUST be silently discarded. The Signature option 1453 MUST be configured with the expected authorization mechanism (CGA or 1454 trusted root), the minimum allowable key size, and optionally with 1455 the information related to the trusted root and the acceptable minSec 1456 value. 1458 Received Neighbor Advertisements sent to a unicast destination 1459 address without a Nonce option MUST be silently discarded. 1461 7.3 Other Requirements 1463 Upon receiving a message for which the receiver has no certificate 1464 chain to a trusted root, the receiver MAY use Authorization 1465 Delegation Discovery to learn the certificate chain of the peer. 1467 Hosts that use stateless address autoconfiguration MUST generate a 1468 new CGA as specified in Section 4 of [27] for each new 1469 autoconfiguration run. 1471 It is outside the scope of this specification to describe the use of 1472 trusted root authorization between hosts with dynamically changing 1473 addresses. Such dynamically changing addresses may be the result of 1474 stateful or stateless address autoconfiguration or through the use of 1475 RFC 3041 [9]. If the CGA method is not used, hosts would be required 1476 to exchange certificate chains that terminate in a certificate 1477 authorizing a host to use an IP address having a particular interface 1478 identifier. This specification does not specify the format of such 1479 certificates, since there are currently a few cases where such 1480 certificates are required by the link layer and it is up to the link 1481 layer to provide certification for the interface identifier. This 1482 may be the subject of a future specification. It is also outside the 1483 scope of this specification to describe how stateful address 1484 autoconfiguration works with the CGA method. 1486 8. Securing Router Discovery with SEND 1488 This section describes how to use the mechanisms from Section 5, 1489 Section 6, and the reference [27] in order to provide security for 1490 Router Discovery. 1492 8.1 Router Solicitation Messages 1494 All Router Solicitation messages are protected with SEND. 1496 8.1.1 Sending Secure Router Solicitations 1498 Secure Router Solicitation messages are sent as described in RFC 1499 2461, with the additional requirements listed in the following. 1501 Router Solicitation messages sent with an unspecified source address 1502 MUST have the Nonce and Timestamp options. Other Router 1503 Solicitations MUST have the Nonce, Timestamp, and Signature options. 1504 The Signature option MUST be configured with the sender's key pair, 1505 setting the authorization method and additional information as is 1506 desired. 1508 8.1.2 Receiving Secure Router Solicitations 1510 Received Router Solicitation messages are processed as described in 1511 RFC 2461, with the additional SEND-related requirements listed in the 1512 following. 1514 Router Solicitation message sent with an unspecified source address 1515 and without the Nonce and Timestamp options MUST be silently 1516 discarded. Router Solicitation messages received with another type 1517 of source address but without the Nonce, Timestamp, and Signature 1518 options MUST be silently discarded. The Signature option MUST be 1519 configured with the expected authorization mechanism (CGA or trusted 1520 root), the minimum allowable key size, and optionally with the 1521 information related to the trusted root and the acceptable minSec 1522 value. 1524 8.2 Router Advertisement Messages 1526 All Router Advertisement messages are protected with SEND. 1528 8.2.1 Sending Secure Router Advertisements 1530 Secure Router Advertisement messages are sent as described in RFC 1531 2461, with the additional requirements listed in the following. 1533 All Router Advertisement messages sent MUST contain a Timestamp and 1534 Signature options. The Signature option SHOULD be configured to 1535 protect the advertisement with the trusted root authorization method 1536 and MAY be configured to additionally protect it with the CGA 1537 authorization method. 1539 Router Advertisements sent in response to a Router Solicitation MUST 1540 contain a copy of the Nonce option included in the solicitation. 1542 8.2.2 Receiving Secure Router Advertisements 1544 Received Router Advertisement messages are processed as described in 1545 RFC 2461, with the additional SEND-related requirements listed in the 1546 following. 1548 Router Advertisement messages received without the Timestamp and 1549 Signature options MUST be silently discarded. The Signature option 1550 SHOULD be configured to require the trusted-root authorization method 1551 and they MAY additionally be configured to require CGA 1552 authentication. 1554 Received Router Advertisements sent to a unicast destination address 1555 without a Nonce option MUST be silently discarded. 1557 8.3 Redirect Messages 1559 All Redirect messages are protected with SEND. 1561 8.3.1 Sending Redirects 1563 Secure Redirect messages are sent as described in RFC 2461, with the 1564 additional requirements listed in the following. 1566 All Redirect messages sent MUST contain the Timestamp and Signature 1567 options. The security associations used for this MUST be configured 1568 with the sender's key pair, setting the authorization method and 1569 additional information as is desired. 1571 8.3.2 Receiving Redirects 1573 Received Redirect messages are processed as described in RFC 2461, 1574 with the additional SEND-related requirements listed in the 1575 following. 1577 Redirect messages received without the Timestamp and Signature 1578 options MUST be silently discarded. The Signature option MUST be 1579 configured with the expected authorization mechanism (CGA or trusted 1580 root), the minimum allowable key size, and optionally with the 1581 information related to the trusted root and the acceptable minSec 1582 value. 1584 If only CGA-based security associations are used, hosts MUST follow 1585 the rules defined below when receiving Redirect messages: 1587 1. The Redirect message MUST be protected as discussed above. 1589 2. The receiver MUST verify that the Redirect message comes from an 1590 IP address to which the host may have earlier sent the packet 1591 that the Redirect message now partially returns. That is, the 1592 source address of the Redirect message must be the default router 1593 for traffic sent to the destination of the returned packet. If 1594 this is not the case, the message MUST be silently discarded. 1596 This step prevents a bogus router from sending a Redirect message 1597 when the host is not using the bogus router as a default router. 1599 8.4 Other Requirements 1601 The certificate for a router MAY specify the global IP address(es) of 1602 the router. If so, only these addresses can appear in advertisements 1603 where the Router Address (R) bit [15] is set. All hosts MUST have 1604 the certificate of a trusted root. 1606 Hosts SHOULD use Authorization Delegation Discovery to learn the 1607 certificate chain of their default router or peer host, as explained 1608 in Section 6. The receipt of a protected Router Advertisement 1609 message for which no router Authorization Certificate and certificate 1610 chain is available triggers Authorization Delegation Discovery. 1612 9. Co-Existence of SEND and ND 1614 During the transition to secure links or as a policy consideration, 1615 network operators may want to run a particular link with a mixture of 1616 secure and insecure nodes. However, all routers are required to 1617 support SEND. The following behaviour is mandated: 1619 o Router Solicitations SHOULD be accepted without the Nonce, 1620 Timestamp, CGA, and Signature options. The router SHOULD respond 1621 according to the rules outlined in Section 8.2 except that a Nonce 1622 option is not sent. 1624 o Neighbor Solicitations SHOULD be accepted without the Nonce, 1625 Timestamp, CGA, and Signature options. The receiver SHOULD 1626 respond according to the rules outlined in Section 7.2 except that 1627 a Nonce option is not sent. 1629 o Neighbor Advertisements SHOULD be accepted without the Timestamp, 1630 CGA and Signature options. The receiver SHOULD act according to 1631 the RFC 2461 [6] and RFC 2462 [7] rules, but take precedence for 1632 information sent using SEND over plain ND. 1634 10. Performance Considerations 1636 The computations related to AH_RSA_Sig transform are computationally 1637 relatively expensive operations. 1639 In the application for which AH_RSA_Sig has been designed, however, 1640 hosts typically have the need to perform only a few operations as 1641 they enter a link, and a few operations as they find a new on-link 1642 peer with which to communicate. 1644 Routers are required to perform a larger number of operations, 1645 particularly when the frequency of router advertisements is high due 1646 to mobility requirements. Still, the number of operations on a 1647 router is on the order of a few dozen operations per second, some of 1648 which can be precomputed as discussed below. A large number of 1649 router solicitations may cause higher demand for performing 1650 asymmetric operations, although RFC 2461 limits the rate at which 1651 responses to solicitations can be sent. 1653 Signatures related to the use of the AH_RSA_Sig transform MAY be 1654 precomputed for Multicast Neighbor and Router Advertisements. 1655 Typically, solicited advertisements are sent to the unicast address 1656 from which the solicitation was sent. Given that the IPv6 header is 1657 covered by the AH integrity protection, it is typically not possible 1658 to precompute solicited advertisements. 1660 11. Security Considerations 1662 11.1 Threats to the Local Link Not Covered by SEND 1664 SEND does not compensate for an insecure link layer. In particular, 1665 there is no cryptographic binding in SEND between the link layer 1666 frame address and the IPv6 address. On an insecure link layer that 1667 allows nodes to spoof the link layer address of other nodes, an 1668 attacker could disrupt IP service by sending out a Neighbor 1669 Advertisement having the source address on the link layer frame of a 1670 victim, a valid CGA with valid AH signature corresponding to itself, 1671 and a Target Link-layer Address extension corresponding to the 1672 victim. The attacker could then proceed to cause a traffic stream to 1673 bombard the victim in a DoS attack. To protect against such attacks, 1674 link layer security MUST be used. An example of such for 802 type 1675 networks is port-based access control [35]. 1677 Prior to participating in Neighbor Discovery and Duplicate Address 1678 Detection, nodes must subscribe to the All Nodes Multicast Group and 1679 Solicited Node Multicast Group for the address that they are claiming 1680 RFC 2461 [6]. Subscribing to a multicast group requires that the 1681 nodes use MLD [22]. MLD contains no provision for security. An 1682 attacker could send an MLD Done message to unsubscribe a victim from 1683 the Solicited Node Multicast address. However, the victim should be 1684 able to detect such an attack because the router sends a 1685 Multicast-Address-Specific Query to determine whether any listeners 1686 are still on the address, at which point the victim can respond to 1687 avoid being dropped from the group. This technique will work if the 1688 router on the link has not been compromised. Other attacks using MLD 1689 are possible, but they primarily lead to extraneous (but not 1690 overwhelming) traffic. 1692 11.2 How SEND Counters Threats to Neighbor Discovery 1694 The SEND protocol is designed to counter the threats to IPv6 Neighbor 1695 Discovery outlined in [29]. The following subsections contain a 1696 regression of the SEND protocol against the threats, to illustrate 1697 what aspects of the protocol counter each threat. 1699 11.2.1 Neighbor Solicitation/Advertisement Spoofing 1701 This threat is defined in Section 4.1.1 of [29]. The threat is that 1702 a spoofed Neighbor Solicitation or Neighbor Advertisement causes a 1703 false entry in a node's Neighbor Cache. There are two cases: 1705 1. Entries made as a side effect of a Neighbor Solicitation or 1706 Router Solicitation. There are two cases: 1708 1. A router receiving a Router Solicitation with a firm IPv6 1709 source address and a Target Link-Layer Address extension 1710 inserts an entry for the IPv6 address into its Neighbor 1711 Cache. 1713 2. A node doing Duplicate Address Detection (DAD) that receives 1714 a Neighbor Solicitation for the same address regards the 1715 situation as a collision and ceases to solicit for the 1716 address. 1718 2. Entries made as a result of a Neighbor Advertisement sent as a 1719 response to a Neighbor Solicitation for purposes of on-link 1720 address resolution. 1722 11.2.1.1 Solicitations with Effect 1724 SEND counters the threat of solicitations with effect in the 1725 following ways: 1727 1. As discussed in Section 5, SEND nodes preferably send Router 1728 Solicitations with a firm IPv6 address and AH header, which the 1729 router can verify, so the Neighbor Cache binding is correct. If 1730 a SEND node must send a Router Solicitation with the unspecified 1731 address, the router will not update its Neighbor Cache, as per 1732 RFC 2461. 1734 2. When SEND nodes are performing DAD, they use the tentative 1735 address as the source address on the Neighbor Solicitation 1736 packet, and include an IPv6 AH header. This allows the receiving 1737 SEND node to verify the solicitation. 1739 See Section 11.2.5, below, for discussion about replay protection and 1740 timestamps. 1742 11.2.1.2 Address Resolution 1744 SEND counters attacks on address resolution by requiring that the 1745 responding node include an AH header with a signature on the packet, 1746 and that the node's interface identifier either be a CGA or that the 1747 node be able to produce a certificate authorizing that node to use 1748 the interface identifier. 1750 The Neighbor Solicitation and Advertisement pairs implement a 1751 challenge-response protocol, as explained in Section 7 and discussed 1752 in Section 11.2.5 below. 1754 11.2.2 Neighbor Unreachability Detection Failure 1756 This attack is described in Section 4.1.2 of [29]. SEND counters 1757 this attack by requiring a node responding to Neighbor Solicitations 1758 sent as NUD probes to include an AH header and proof of authorization 1759 to use the interface identifier in the address being probed. If 1760 these prerequisites are not met, the node performing NUD discards the 1761 responses. 1763 11.2.3 Duplicate Address Detection DoS Attack 1765 This attack is described in Section 4.1.3 of [29]. SEND counters 1766 this attack by requiring the Neighbor Advertisements sent as 1767 responses to DAD to include an AH header and proof of authorization 1768 to use the interface identifier in the address being tested. If 1769 these prerequisites are not met, the node performing DAD discards the 1770 responses. 1772 When a SEND node is used on a link that also connects to non-SEND 1773 nodes, the SEND node defends its addresses by sending unprotected 1774 Neighbor Solicitations with an unspecified address, as explained in 1775 Section 9. However, the SEND node ignores any unprotected Neighbor 1776 Solicitations or Advertisements that may be send by the non-SEND 1777 nodes. This protects the SEND node from DAD DoS attacks by non-SEND 1778 nodes or attackers simulating to non-SEND nodes, at the cost of a 1779 potential address collision between a SEND node and non-SEND node. 1780 The probability and effects of such an address collision are 1781 discussed in [27]. 1783 11.2.4 Router Solicitation and Advertisement Attacks 1785 These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6, 1786 and 4.2.7 of [29]. SEND counters these attacks by requiring Router 1787 Advertisements to contain an AH header, and that the signature in the 1788 header be calculated using the public key of a host that can prove 1789 its authorization to route the subnet prefixes contained in any 1790 Prefix Information Options. The router proves it authorization by 1791 showing an attribute certificate containing the specific prefix or 1792 the indication that the router is allowed to route any prefix. A 1793 Router Advertisement without these protections is dropped as part of 1794 the IPsec processing. 1796 SEND does not protect against brute force attacks on the router, such 1797 as DoS attacks, or compromise of the router, as described in Sections 1798 4.4.2 and 4.4.3 of [29]. 1800 11.2.5 Replay Attacks 1801 This attack is described in Section 4.3.1 of [29]. SEND protects 1802 against attacks in Router Solicitation/Router Advertisement and 1803 Neighbor Solicitation/Neighbor Advertisement transactions by 1804 including a Nonce option in the solicitation and requiring the 1805 advertisement to include a matching option. Together with the 1806 signatures this forms a challenge-response protocol. SEND protects 1807 against attacks from unsolicited messages such as Neighbor 1808 Advertisements, Router Advertisements, and Redirects by including a 1809 timestamp into the AH header. A window of vulnerability for replay 1810 attacks exists until the timestamp expires. 1812 When timestamps are used, SEND nodes are protected against replay 1813 attacks as long as they cache the state created by the message 1814 containing the timestamp. The cached state allows the node to 1815 protect itself against replayed messages. However, once the node 1816 flushes the state for whatever reason, an attacker can re-create the 1817 state by replaying an old message while the timestamp is still valid. 1818 Since most SEND nodes are likely to use fairly coarse grained 1819 timestamps, as explained in Section 5.3, this may affect some nodes. 1821 11.2.6 Neighbor Discovery DoS Attack 1823 This attack is described in Section 4.3.2 of [29]. In this attack, 1824 the attacker bombards the router with packets for fictitious 1825 addresses on the link, causing the router to busy itself with 1826 performing Neighbor Solicitations for addresses that do not exist. 1827 SEND does not address this threat because it can be addressed by 1828 techniques such as rate limiting Neighbor Solicitations, restricting 1829 the amount of state reserved for unresolved solicitations, and clever 1830 cache management. These are all techniques involved in implementing 1831 Neighbor Discovery on the router. 1833 11.3 Attacks against SEND Itself 1835 The CGAs have a 59-bit hash value. The security of the CGA mechanism 1836 has been discussed in [27]. 1838 Some Denial-of-Service attacks against ND and SEND itself remain. 1839 For instance, an attacker may try to produce a very high number of 1840 packets that a victim host or router has to verify using asymmetric 1841 methods. While safeguards are required to prevent an excessive use 1842 of resources, this can still render SEND non-operational. 1844 Security associations based on the use of asymmetric cryptography can 1845 be vulnerable to Denial-of-Service attacks, particularly when the 1846 attacker can guess the SPIs and destination addresses used in the 1847 security associations. In SEND this is easy, as both the SPIs and 1848 the addresses (such as all nodes multicast address) are standardized. 1850 Due to the use of multicast, one packet sent by the attacker will be 1851 processed by multiple receivers. 1853 When CGA protection is used, SEND deals with these attacks using the 1854 verification process described in Section 5.2.2. In this process a 1855 simple hash verification of the CGA property of the address is 1856 performed first before performing the more expensive signature 1857 verification. 1859 When trusted roots and certificates are used for address validation 1860 in SEND, the defenses are not quite as effective. Implementations 1861 SHOULD track the resources devoted to the processing of packets 1862 received with the AH_RSA_Sig transform, and start selectively 1863 dropping packets if too many resources are spent. Implementations 1864 MAY also drop first packets that are not protected with CGA. 1866 The Authorization Delegation Discovery process may also be vulnerable 1867 to Denial-of-Service attacks. An attack may target a router by 1868 request a large number of delegation chains to be discovered for 1869 different roots. Routers SHOULD defend against such attacks by 1870 caching discovered information (including negative responses) and by 1871 limiting the number of different discovery processes they engage in. 1873 Attackers may also target hosts by sending a large number of 1874 unnecessary certificate chains, forcing hosts to spend useless memory 1875 and verification resources for them. Hosts defend against such 1876 attacks by limiting the amount of resources devoted to the 1877 certificate chains and their verification. Hosts SHOULD also 1878 prioritize advertisements sent as a response to their requests above 1879 multicast advertisements. 1881 12. IANA Considerations 1883 This document defines two new ICMP message types, used in 1884 Authorization Delegation Discovery. These messages must be assigned 1885 ICMPv6 type numbers from the informational message range: 1887 o The Delegation Chain Solicitation message, described in Section 1888 6.1. 1890 o The Delegation Chain Advertisement message, described in Section 1891 6.2. 1893 This document defines two new Neighbor Discovery [6] options, which 1894 must be assigned Option Type values within the option numbering space 1895 for Neighbor Discovery messages: 1897 o The Trusted Root option, described in Section 6.3. 1899 o The Certificate option, described in Section 6.4. 1901 o The CGA option, described in Section 5.1. 1903 o The Signature option, described in Section 5.2. 1905 o The Timestamp option, described in Section 5.3. 1907 o The Nonce option, described in Section 5.4. 1909 This document defines a new name space for the Name Type field in the 1910 Trusted Root option. Future values of this field can be allocated 1911 using standards action [5]. 1913 Another new name space is allocated for the Cert Type field in the 1914 Certificate option. Future values of this field can be allocated 1915 using standards action [5]. 1917 13. Comparison to AH-Based Approach 1919 This approach has the following benefits compared to the current 1920 Working Group document approach: 1922 o The full implementation of the security mechanism, including 1923 Nonces and CGAs, exists within one module. There is no need to 1924 analyze the security of the mechanism across ND, IPsec, and 1925 possibly the CGA layers. 1927 o The CGA part of the solution can easily be separated into its own 1928 optional specification, if IPR concerns can not be resolved. This 1929 is possible because the CGA handling is done in its own option. 1930 (The authorization method configuration flag is the only thing 1931 common to the CGA and Signature options.) 1933 o No extensions or modifications of IPsec processing are required: 1934 SPD entries are not required to distinguish ICMP types, AH does 1935 not need to support public keys or CGAs, and destination address 1936 acgnostic security associations are not needed. 1938 o It is not necessary to allocate a new multicast address to 1939 represent the solicited-node multicast address for SEND nodes. 1941 o It is not necessary to change the Neighbor Discovery behavior with 1942 regards to the use of the unspecified address. Since all 1943 information is available within the Neighbor Discovery messages, 1944 unspecified source addresses can be used, still being able to 1945 correlate the CGA property with the Target Address in a Neighbor 1946 Solicitation during Duplicate Address Detection. 1948 o The transition mechanisms for links with both SEND and non-SEND 1949 nodes are significantly simpler. In particular, non-SEND nodes 1950 will be able to receive DAD probes and other messages sent by the 1951 SEND nodes. 1953 o Only a single set of Neighbor Discovery messages from the router 1954 needs to be transmitted on a link. This helps avoid extra 1955 overhead for mobility beacons and other frequently occurring 1956 messaging. 1958 o Given that the asymmetric computations required in SEND are 1959 computationally expensive, it is necessary to control the number 1960 of these operations in order to avoid Denial-of-Service attacks. 1961 This control is easier to arrange with "application layer" 1962 information. For instance, a router need not verify more Router 1963 Solicitations with an unspecified source address than it can 1964 respond to according to the RFC 2461 rules. 1966 o There is no need for an API to communicate certificate chains 1967 requests and certificate chains between the IPsec and Neighbor 1968 Discovery modules. 1970 Also, a good implementation of SEND would not require the user to 1971 configure it (beyond perhaps enabling it). In order to achieve 1972 this with IPsec, a set of policy entries needs to be automatically 1973 created upon system start. This may require an additional API. 1975 o There is no need for the CGA parameters to be stored both in the 1976 IPsec and Neighbor Discovery modules, where they are needed for 1977 the construction of AH headers and addresses, respectively. 1979 o It is not necessary to change existing BITS or BITW IPsec 1980 implementations to support SEND and AH_RSA_Sig. There are two 1981 problems associated with such changes: 1983 * A SEND implementation in such environment can not proceed until 1984 this modification has been completed. 1986 * Typical hardware that processes IPsec packets may not be easily 1987 changed to process asymmetric transforms. (Of course such 1988 packets can be passed to the main CPU at the node, assuming 1989 this can easily be done in the given implementation.) 1991 o In addition, many IPsec implementations are highly optimized 1992 because they are on the fast path for packet processing. For 1993 example, the Linux implementation runs in the kernel interrupt 1994 thread. Some of the SEND modifications might require IPsec 1995 processing to wait on a semaphore while, for example, a 1996 certificate chain is fetched, an operation that takes place out of 1997 band in regular IPsec processing because it is done using IKE. 1998 While it is possible that the implemenation can be arranged so 1999 that general IPsec processing isn't impacted, the resulting code 2000 could increase in complexity. 2002 The use of IPsec to protect ND is possible, but the limits and 2003 capabilities of IPsec have to be stretched. Small changes in the ND 2004 protocol (or our understanding of the issues) may cause a situation 2005 which is no longer easily handled when the "application" and the 2006 security exist at different layers. Although IPsec as defined in RFC 2007 2402 just defines a header format, RFC 2401 and the ensuing years of 2008 implementation have evolved a complex interconnected set of 2009 components for IPsec which will require some modification to 2010 accommodate SEND. 2012 On the other hand, IPsec is the current solution for securing ND in 2013 the original ND RFCs. Even if the current IPsec can be used only in 2014 very limited networks to secure ND, it could be argued that it is 2015 logical to continue its use. Also, the existence of an asymmetric 2016 transform in IPsec would be potentially useful in other contexts as 2017 well. 2019 Normative References 2021 [1] Hinden, R. and S. Deering, "IP Version 6 Addressing 2022 Architecture", RFC 2373, July 1998. 2024 [2] Kent, S. and R. Atkinson, "Security Architecture for the 2025 Internet Protocol", RFC 2401, November 1998. 2027 [3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 2028 November 1998. 2030 [4] Piper, D., "The Internet IP Security Domain of Interpretation 2031 for ISAKMP", RFC 2407, November 1998. 2033 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2034 Considerations Section in RFCs", BCP 26, RFC 2434, October 2035 1998. 2037 [6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 2038 for IP Version 6 (IPv6)", RFC 2461, December 1998. 2040 [7] Thomson, S. and T. Narten, "IPv6 Stateless Address 2041 Autoconfiguration", RFC 2462, December 1998. 2043 [8] Conta, A. and S. Deering, "Internet Control Message Protocol 2044 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 2045 Specification", RFC 2463, December 1998. 2047 [9] Narten, T. and R. Draves, "Privacy Extensions for Stateless 2048 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 2050 [10] Bassham, L., Polk, W. and R. Housley, "Algorithms and 2051 Identifiers for the Internet X.509 Public Key Infrastructure 2052 Certificate and Certificate Revocation List (CRL) Profile", RFC 2053 3279, April 2002. 2055 [11] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 2056 Public Key Infrastructure Certificate and Certificate 2057 Revocation List (CRL) Profile", RFC 3280, April 2002. 2059 [12] Farrell, S. and R. Housley, "An Internet Attribute Certificate 2060 Profile for Authorization", RFC 3281, April 2002. 2062 [13] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 2063 Addressing Architecture", RFC 3513, April 2003. 2065 [14] Lynn, C., "X.509 Extensions for IP Addresses and AS 2066 Identifiers", Internet-Draft (expired) 2067 draft-ietf-pkix-x509-ipaddr-as-extn-00, February 2002. 2069 [15] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in 2070 IPv6", draft-ietf-mobileip-ipv6-22 (work in progress), May 2071 2003. 2073 [16] International Organization for Standardization, "The Directory 2074 - Authentication Framework", ISO Standard X.509, 2000. 2076 [17] RSA Laboratories, "RSA Encryption Standard, Version 1.5", PKCS 2077 1, November 1993. 2079 [18] National Institute of Standards and Technology, "Secure Hash 2080 Standard", FIPS PUB 180-1, April 1995, . 2083 Informative References 2085 [19] Postel, J., "Internet Control Message Protocol", STD 5, RFC 2086 792, September 1981. 2088 [20] Plummer, D., "Ethernet Address Resolution Protocol: Or 2089 converting network protocol addresses to 48.bit Ethernet 2090 address for transmission on Ethernet hardware", STD 37, RFC 2091 826, November 1982. 2093 [21] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 2094 RFC 2409, November 1998. 2096 [22] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener 2097 Discovery (MLD) for IPv6", RFC 2710, October 1999. 2099 [23] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies", 2100 draft-arkko-icmpv6-ike-effects-01 (work in progress), June 2101 2002. 2103 [24] Arkko, J., "Manual SA Configuration for IPv6 Link Local 2104 Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress), 2105 June 2002. 2107 [25] Droms, R., "Dynamic Host Configuration Protocol for IPv6 2108 (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), 2109 November 2002. 2111 [26] Kent, S., "IP Encapsulating Security Payload (ESP)", 2112 draft-ietf-ipsec-esp-v3-04 (work in progress), March 2003. 2114 [27] Aura, T., "Cryptographically Generated Addresses (CGA)", 2115 draft-ietf-send-cga-00.txt (work in progress), May 2003. 2117 [28] Arkko, J., Kempf, J., Sommerfeld, B. and B. Zill, "SEcure 2118 Neighbor Discovery (SEND) Protocol", 2119 draft-ietf-send-ipsec-00.txt (work in progress), February 2003. 2121 [29] Nikander, P., "IPv6 Neighbor Discovery trust models and 2122 threats", draft-ietf-send-psreq-00 (work in progress), October 2123 2002. 2125 [30] Montenegro, G. and C. Castelluccia, "SUCV Identifiers and 2126 Addresses", draft-montenegro-sucv-03 (work in progress), July 2127 2002. 2129 [31] O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6", 2130 Computer Communications Review, April 2001. 2132 [32] Nikander, P., "Denial-of-Service, Address Ownership, and Early 2133 Authentication in the IPv6 World", Proceedings of the Cambridge 2134 Security Protocols Workshop, April 2001. 2136 [33] Arkko, J., Aura, T., Kempf, J., Mantyla, V., Nikander, P. and 2137 M. Roe, "Securing IPv6 Neighbor Discovery", Wireless Security 2138 Workshop, September 2002. 2140 [34] Montenegro, G. and C. Castelluccia, "Statistically Unique and 2141 Cryptographically Verifiable (SUCV) Identifiers and Addresses", 2142 NDSS, February 2002. 2144 [35] Institute of Electrical and Electronics Engineers, "Local and 2145 Metropolitan Area Networks: Port-Based Network Access Control", 2146 IEEE Standard 802.1X, September 2001. 2148 Author's Address 2150 Jari Arkko 2151 Ericsson 2152 Jorvas 02420 2153 Finland 2155 EMail: jari.arkko@ericsson.com 2157 Appendix A. Contributors 2159 Most of the substantive material in this document has been derived 2160 from the current official Working Group item [28]. The authors of 2161 that document have deserve full credit for this document as well. 2162 All errors are mine, however. 2164 Appendix B. Acknowledgements 2166 The author would like to thank James Kempf, Pekka Nikander, Tuomas 2167 Aura, Ran Atkinson for interesting discussions in this problem space. 2169 Appendix C. IPR Considerations 2171 The optional CGA part of SEND uses public keys and hashes to prove 2172 address ownership. Several IPR claims have been made about such 2173 methods. 2175 Intellectual Property Statement 2177 The IETF takes no position regarding the validity or scope of any 2178 intellectual property or other rights that might be claimed to 2179 pertain to the implementation or use of the technology described in 2180 this document or the extent to which any license under such rights 2181 might or might not be available; neither does it represent that it 2182 has made any effort to identify any such rights. Information on the 2183 IETF's procedures with respect to rights in standards-track and 2184 standards-related documentation can be found in BCP-11. Copies of 2185 claims of rights made available for publication and any assurances of 2186 licenses to be made available, or the result of an attempt made to 2187 obtain a general license or permission for the use of such 2188 proprietary rights by implementors or users of this specification can 2189 be obtained from the IETF Secretariat. 2191 The IETF invites any interested party to bring to its attention any 2192 copyrights, patents or patent applications, or other proprietary 2193 rights which may cover technology that may be required to practice 2194 this standard. Please address the information to the IETF Executive 2195 Director. 2197 Full Copyright Statement 2199 Copyright (C) The Internet Society (2003). All Rights Reserved. 2201 This document and translations of it may be copied and furnished to 2202 others, and derivative works that comment on or otherwise explain it 2203 or assist in its implementation may be prepared, copied, published 2204 and distributed, in whole or in part, without restriction of any 2205 kind, provided that the above copyright notice and this paragraph are 2206 included on all such copies and derivative works. However, this 2207 document itself may not be modified in any way, such as by removing 2208 the copyright notice or references to the Internet Society or other 2209 Internet organizations, except as needed for the purpose of 2210 developing Internet standards in which case the procedures for 2211 copyrights defined in the Internet Standards process must be 2212 followed, or as required to translate it into languages other than 2213 English. 2215 The limited permissions granted above are perpetual and will not be 2216 revoked by the Internet Society or its successors or assignees. 2218 This document and the information contained herein is provided on an 2219 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2220 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2221 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2222 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2223 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2225 Acknowledgement 2227 Funding for the RFC Editor function is currently provided by the 2228 Internet Society.