idnits 2.17.1 draft-arkko-send-cga-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 10) being 68 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 413: '... All nodes MUST acquire a CGA-based a...' RFC 2119 keyword, line 419: '... 1. The node MUST use a CGA-based a...' RFC 2119 keyword, line 421: '... 2. The node MUST attach the Public...' RFC 2119 keyword, line 424: '... 3. The node MUST attach the Signat...' RFC 2119 keyword, line 429: '.... The NA message MUST have a Public Ke...' (32 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7985 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 2119' is mentioned on line 53, but not defined == Missing Reference: 'Section 8' is mentioned on line 159, but not defined == Missing Reference: 'Section 6' is mentioned on line 163, but not defined ** Obsolete normative reference: RFC 2461 (ref. 'ND98') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. 'AUTOCONF98') (Obsoleted by RFC 4862) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jari Arkko 3 INTERNET-DRAFT Pekka Nikander 4 Category: Informational Vesa-Matti Mantyla 5 Ericsson 6 June 2002 8 Securing IPv6 Neighbor Discovery Using Cryptographically Generated 9 Addresses (CGAs) 11 Status of this Memo 13 This document is an Internet Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet Drafts are 15 working documents of the Internet Engineering Task Force (IETF), its 16 areas, and working groups. Note that other groups may also distribute 17 working documents as 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 inapproporiate 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 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 The distribution of this memo is unlimited. It is filed as , and expires December 24, 2002. Please send 32 comments to the authors. 34 Abstract 36 IPv6 nodes use the Neighbor Discovery (ND) protocol to discover other 37 nodes on the link, to determine each other's link-layer addresses, to 38 find routers and to maintain reachability information about the paths 39 to active neighbors. The original ND specifications called for the 40 use of IPsec for protecting the ND messages. However, in this 41 particular application the use of IPsec may not always be feasible, 42 mainly due to difficulties in key management. If not secured, ND 43 protocol is vulnerable to various attacks. This document specifies a 44 lightweight security solution for ND that does not rely on pre- 45 configuration or trusted third parties. The presented solution uses 46 Cryptographically Generated Addresses. 48 Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", in this 52 document are to be interpreted as described in [RFC 2119]. 54 Table of contents 56 1. Introduction...................................................2 57 2. Definitions....................................................3 58 3. Neighbor Discovery.............................................3 59 4. Approaches for Securing Neighbor Discovery.....................4 60 5. Cryptogaphically Generated Addresses...........................6 61 5.1. Generation................................................6 62 5.2. Signatures................................................7 63 5.3. Verification .............................................7 64 5.4. Algorithms................................................8 65 6. Securing Neighbor Discovery with CGA...........................8 66 6.1. Duplicate Address Detection...............................8 67 6.2. Address Resolution........................................9 68 6.3. Neighbor Unreachability Detection.........................9 69 7. Securing Router Discovery with CGA.............................9 70 7.1. Router Discovery..........................................9 71 7.2. Redirect.................................................10 72 8. Option Formats................................................11 73 8.1. Public Key Option........................................11 74 8.2. Signature Option.........................................12 75 9. Security Considerations.......................................12 76 10. Acknowledgments...............................................13 77 11. References....................................................13 78 11.1. Normative References....................................13 79 11.2. Non-normative References................................13 80 12. IPR Considerations............................................14 81 13. Authors' Address..............................................14 83 1. Introduction 85 IPv6 defines the Neighbor Discovery (ND) protocol in RFC 2461 [ND98]. 86 Nodes on the same link use the ND protocol to discover each other's 87 presence, to determine each other's link-layer addresses, to find 88 routers and to maintain reachability information about the paths to 89 active neighbors. The ND protocol is used both by hosts and routers. 90 Its functions include Router Discovery (RD), Address Auto- 91 configuration, Address Resolution, Neighbor Unreachability Detection 92 (NUD), Duplicate Address Detection (DAD), and Redirection. 94 Section 4 gives a description of different approaches for securing 95 the ND protocol. This shows that the specified IPsec method isn't 96 always applicable. In Sections 6 to 8 we present a new, lightweight 97 solution for ND security. Our approach is based on the use of 98 Cryptographically Generated Addresses (CGAs) [CAM01]. 100 The CGA method provides a proof of address ownership, i.e., it 101 provides assurance that the node we are talking to is indeed the one 102 that came up with the very address. In our solution, there is no need 103 for an external key management infrastructure. All the used keys can 104 be self-generated, and can be presented without external credentials. 105 Section 5 briefly introduces the CGA method. 107 Our requirements call for secure ND signaling to be possible both in 108 private networks as well as in public access networks. In the public 109 access networks we can't trust all parties to behave in an 110 appropriate manner. 112 At the moment this specification considers only the case of networks 113 that are fully protected with our secure ND approach. That is, we do 114 not yet deal with the problem of securing some ND messages with our 115 approach while allow some other messages to be secured with the 116 traditional IPsec approach or even be left unsecured. 118 2. Definitions 120 Cryptographically Generated Addresses (CGAs) - A technique where the 121 address of the node is cryptographically generated from the public 122 key of the node and some other parameters using a one-way hash 123 function [CAM01]. Also called SUCD Identities in [SUCV]. 125 Internet Control Message Protocol version 6 (ICMPv6) - The IPv6 126 control signaling protocol. Neighbor Discovery is a part of ICMPv6. 128 Neighbor Discovery (ND) - The IPv6 Neighbor Discovery protocol[ND98]. 130 3. Neighbor Discovery 132 The main functions of IPv6 Neighbor Discovery are as follows: 134 - Neighbor Unreachability Detection (NUD) is used for tracking the 135 reachability of neighbors, both local destinations and routers 136 [ND98, Section 7.3]. 138 - Duplicate Address Detection (DAD) is used for preventing address 139 collisions [ND98, AUTOCONF98]. A node that intends to assign a new 140 address to one of its interfaces runs first the DAD procedure to 141 verify that other nodes are not using the same address. 143 - Address Resolution is similar to IPv4 ARP [ARP82]. The Address 144 Resolution function resolves a node's IPv6 address to the 145 corresponding link-layer address for nodes on the link [ND98, 146 Section 7.2]. Address Resolution is used for hosts and routers 147 alike. 149 - Address Autoconfiguration is used for automatically assigning 150 addresses to a host [AUTOCONF98]. This allows hosts to operate 151 without configuration related to IP connectivity. The Address 152 Autoconfiguration mechanism is stateless, where the hosts use 153 prefix information delivered to them during Router Discovery to 154 create addresses, and then test these addresses for uniqueness 155 using the DAD procedure. A stateful mechanism, DHCPv6, provides 156 additional Autoconfiguration features. 158 - The Redirection function is used for automatically redirecting 159 hosts to an alternate router [ND98, Section 8]. It is similar to 160 the ICMPv4 Redirect message [POS81]. 162 - The Router Discovery function allows IPv6 hosts to discover the 163 local routers on an attached link [ND98, Section 6]. 165 The Neighbor Discovery messages follow the ICMPv6 message format and 166 ICMPv6 types from 133 to 137. The IPv6 Next Header value for ICMPv6 167 is 58. The actual Neighbor Discovery message includes an ND message 168 header consisting of ICMPv6 header and ND message-specific data, and 169 zero or more ND options: 171 <------------ND Message-----------------> 172 *-----------------------------------------------------------* 173 | IPv6 Header | ICMPv6 | ND message- | ND Message | 174 | Next Header = 58 | Header | specific | Options | 175 | (ICMPv6) | | data | | 176 *-----------------------------------------------------------* 177 <--ND Message header--> 179 The ND message options are formatted in the Type-Length-Value format. 181 All IPv6 ND protocol functions are realized using the following 182 messages: 184 ICMPv6 Type Message 185 ------------------------------------ 186 133 Router Solicitation (RS) 187 134 Router Advertisement (RA) 188 135 Neighbor Solicitation (NS) 189 136 Neighbor Advertisement (NA) 190 137 Redirect 192 The functions of the ND protocol are realized using these messages as 193 follows: 195 - Router Discovery uses the RS and RA messages. 196 - Duplicate Address Detection uses the NS and NA messages. 197 - Address Autoconfiguration uses the NS, NA, RS, and RA messages. 198 - Address Resolution uses the NS and NA messages. 199 - Neighbor Unreachability Detection uses the NS and NA messages. 200 - Redirect uses the Redirect message. 202 All functions but Address Auto-configuration are explained in RFC 203 2461. The Address Auto-configuration is presented in RFC 2462. 205 In Section 8 we define two new ND message options that are used in 206 our security solution. 208 4. Approaches for Securing Neighbor Discovery 210 When ND is not secured, attackers can cause, for instance, the 211 following types of problems [Ark01, Ark02]: 213 - Making hosts adopt bogus prefixes. This leads to Denial-of- 214 Service. 215 - Making hosts adopt bogus default routers. This leads to Denial-of- 216 Service and can also be used in an attempt to place the attacker as 217 a Man-in-the-Middle for all communications. 219 - Sending spoofed answers to DAD queries in an attempt to prevent a 220 host from acquiring any address. 221 - Sending spoofed Address Resolution messages in an attempt to cause 222 Denial-of-Service or to place the attacker as a Man-in-the-Middle 223 between the neighbors. 224 - Sending spoofed NUD messages. This can be used to make the 225 neighbor believe the node is reachable when it is not. 226 - Sending spoofed Redirect messages, again in an attempt to cause 227 Denial-of-Service or to place the attacker as a Man-in-the-Middle. 229 The ND protocol ignores packets received from off-link nodes by 230 verifying that the Hop Limit field contains the value 255. Since 231 every forwarding router reduces this value by one, an ND packet 232 containing the Hop Limit value of 255 must originate from a 233 neighboring IPv6 node. However, this does not protect against 234 malicious neighbors. 236 It is possible to authenticate the ND protocol packet exchanges using 237 the IPSec Authentication Header, if a suitable SA exists. This is the 238 approach specified in the original specification [ND98]. However, 239 three different types of problems exist with this approach: 241 - Running an automatic keying protocol such as IKE would involve 242 sending IP traffic, which may be impossible in the initial stages 243 of some the ND procedures. For instance, we can't send IKE UDP 244 packets before we have an address. Also, the node needs to discover 245 the link layer address of the neighbor. This is a chicken-and-egg 246 problem, since getting an address or finding the link layer address 247 of the peer would require running ND, which in turn would require 248 the security associations to be already in place. 250 - Manual SAs can be configured, but as [Ark01] points out this may 251 lead to a large number of SAs. The definition of IPsec requires a 252 different SA for every IP address that is used as a destination. 254 - According to RFC 2461 [ND98], the ND protocol "provides no 255 mechanism to determine, which neighbors are authorized to send a 256 particular type of message", e.g a Router Advertisement. The 257 current set of IPsec policy selectors do not allow us to define 258 which nodes are allowed to send which particular ND messages. 260 - IPsec in general can prove that the peers are among the intended 261 users of the link. However, we also need to authorize the contents 262 of the messages. For instance, even if a particular node is 263 authorized to send Neighbor Advertisements, it is usually 264 authorized to send them only on its own behalf. Manually configured 265 SAs with security policy entries that limit the use of source 266 address can in some cases handle this, but it isn't expected that 267 trusted third parties and certificate infrastructures can keep up 268 with the right IP address identities of all users at all times. 270 Due to the above, the use of IPsec in securing ND for public access 271 networks is hard, and it isn't clear that attacks can be avoided even 272 when IPsec is used. 274 Various new approaches to securing ND have been designed. One of 275 these approaches is the Address Based Keys method which is discussed 276 in [ABK02]. 278 5. Cryptographically Generated Addresses 280 The purpose of the CGA method is to ensure that only the node that 281 "owns" an address has the right to make statements about this 282 address, e.g., for the purpose of address resolution. 284 In the CGA method a node first generates a private-public key pair. 285 The public key and some other parameters are used to generate the CGA 286 address. The private key is used for signing signaling messages 287 related to this address. The public key has to be distributed to the 288 receiving node(s) for the signature verification to be possible. It 289 isn't necessary to protect the transfer of the public key. 291 The following text gives a more detailed description of the 292 calculations the nodes have to perform when using the CGA. 294 5.1. Generation 296 An IPv6 address is composed of two parts: 298 Address = Routing Prefix | Interface ID 300 In the CGA scheme, the Route Prefix is derived in a usual manner, 301 whereas the Interface ID of the node is created using the following 302 procedure: 304 1. Select the security parameter Sec = 0, 1 , 2, 3. 306 2. Calculate 308 Hash = HASH("CGA" | Sec | Routing Prefix | PK | Random), 310 where 312 HASH A one-way hash algorithm. 314 PK The Public Key of the node. 316 "CGA" A three octet long string consisting of the ASCII 317 characters 'C', 'G', and 'A'. 319 Sec One octet security parameter that can be used to 320 tune the amount of work needed to create CGA 321 addresses. The rationale for Sec is discussed 322 more in depth in [Ark02]. 324 Routing Prefix 325 The 64 routing prefix. 327 Random A 64 bit long random number. 329 3. Select 64+20 x Sec rightmost bits of the hash output and compare 330 the 20 x Sec leftmost bits to zero. If not zero, proceed to 331 generate a new Random value and go back to Step 2. 333 4. Concatenate the 64-bit Routing Prefix and the rightmost 64 bits 334 of the Hash to obtain the Address. 336 5. Set the group and the universal bits [ADD98] to 1 and the two 337 rightmost bits to Sec. 339 6. Perform Duplicate Address Detection. If collision is detected, 340 proceed to generate a new Random value and return to Step 2. 341 After three collisions, stop and report error. 343 Note that the Sec parameter is included in both in the address and in 344 the hash input. The indication to use CGA-based addresses is encoded 345 by setting the group and universal bits to 1. 347 5.2. Signatures 349 SIG = SIGALG(HASH(Contents),SK), 351 Where 353 SIGALG A public key signature algorithm. 355 Contents Some statement relating to the address in question. 357 SK Secret Key of the node. 359 For ND messages, the Contents is formed from the following parts: 361 1. The IPv6 header with the exception of the destination address 362 field. (The purpose of omitting the destination address field is 363 to avoid the CPU intensive signature generation when responding 364 with the same message to different nodes.) 365 2. The ICMPv6/ND message with the exception of the Signature ND 366 option. (The rest of the IPv6 message, e.g. the IPv6 Payload 367 length or the ICMPv6 Length field are not modified as a result 368 of omitting this part.) 370 5.3. Verification 372 In order to verify that a given address has been formed using CGA, 373 the receiver performs the following steps: 375 1. Check that the group and the universal bits are 1. If not, the 376 verification process fails. 377 2. Retrieve the Routing Prefix from the highest 64 bits of the 378 address, Sec from the lowest 2 bits of the address, and PK and 379 Random from an option accompanying the ND message. If the 380 necessary option is not present in the message, the verification 381 process fails. 382 3. Calculate the hash as defined in Section 5.1, set the group and 383 universal bits, set the two lowest bits to Sec, and compare to 384 the 64 lowest bits in the given address. If the values are not 385 the same, the verification process fails. 386 4. The process succeeds. 388 In order to verify a given statement about a particular address, the 389 following process is used: 391 1. Check that the address in the source field of the message has 392 been formed using CGA, as explained above. If this fails, the 393 verification process fails. 394 2. Construct a Contents string as described in Section 5.2. 395 3. Verify that the signature found in the Signature ND option has 396 been produced using the private key corresponding to the public 397 key found from the Public Key ND option. If this fails, the 398 verification process fails. 399 4. The process succeeds. 401 5.4. Algorithms 403 In this specification, the one-way hash algorithm used in CGA 404 generation and signature calculation is the SHA1 algorithm [SHA1]. As 405 the public key algorithm we use the RSA algorithm [RSA78]. 407 6. Securing Neighbor Discovery 409 The following text describes the procedures involved in securing ND 410 with CGA. The method affects the transmitting and reception of 411 Neighbor Advertisement (NA) messages. 413 All nodes MUST acquire a CGA-based address on all interfaces they 414 communicate according to the procedure presented in Section 5.1. 416 All nodes follow the rules defined below when transmitting NA 417 messages: 419 1. The node MUST use a CGA-based address as the source address in 420 the IPv6 header that carries the ND message. 421 2. The node MUST attach the Public Key ND option to the NA message 422 with the same parameters that were used in the construction of 423 address in the source address field. 424 3. The node MUST attach the Signature ND option to the NA message, 425 and calculates this signature as specified in Section 5.2. 427 All nodes follow the rules defined below when receiving NA messages: 429 1. The NA message MUST have a Public Key and Signature ND options. 430 Messages that do not have these options MUST be silently 431 discarded. 432 2. The receiver MUST verify the signature as described in Section 433 5.3. Messages that fail this verification MUST be silently 434 discarded. 436 In the following we discuss how the above procedures affect the 437 security of ND functions. We will also describe function-specific 438 rules for the treatment of the NA messages. 440 6.1. Duplicate Address Detection 442 To the extent that CGA is secure, only the owner of the address can 443 reply with a verifiable signature to a DAD query. This prevents other 444 parties from sending replies in an attempt to prevent the host from 445 getting an address. 447 After receiving an NS message, in this case the DAD query, and 448 detecting an address collision, a node uses the above procedures for 449 sending the NA message. 451 A node that receives the DAD reply, i.e. the NA message, uses the 452 above procedures for receiving the NA message. If no valid replies 453 are received, the tentative address is set to the VALID state. If the 454 verification succeeded, the tentative address of the host is set to 455 the DISABLED state. 457 6.2. Address Resolution 459 Here, the CGA method is used to assure that only the real owner of 460 the address can produce a valid response. 462 The rules for sending and receiving the NA message have again been 463 described earlier. Note that the link-layer address ND option is also 464 protected with the signature, preventing a Man-in-the-Middle from 465 replacing another link-layer address to a legitimate reply. 467 6.3. Neighbor Unreachability Detection 469 Here the CGA method makes sure that attackers cannot claim that a 470 node is reachable when it is not. 472 For the procedure to process NA messages, see the beginning of 473 Section 6. After a successful verification of the NA message, the 474 node is marked as REACHABLE by the host. 476 7. Securing Router Discovery 478 For Router Discovery, we use CGA to ensure that a given message comes 479 from the claimed IP address. However, this does not offer any 480 information about the ability and willingness of the router to act as 481 a router, or that the advertised network prefixes are correct. We use 482 a heuristic process to verify these properties. 484 All routers MUST acquire a CGA-based address on all interfaces they 485 communicate according to the procedure presented in Section 5.1. The 486 router MUST use the same CGA-based address for both Neighbor 487 Discovery and Router Discovery purposes. 489 7.1. Router Discovery 491 All routers follow the rules defined below when transmitting RA 492 messages: 494 1. The router MUST use a CGA-based address as the source address in 495 the IPv6 header that carries the RA message. 496 2. The router MUST attach the Public Key ND option to the RA 497 message with the same parameters that were used in the 498 construction of address in the source address field. 499 3. The router MUST attach the Signature ND option to the RA 500 message, and calculates this signature as specified in Section 501 5.2. 503 All hosts follow the rules defined below when receiving RA messages: 505 1. The RA message MUST have a Public Key and Signature ND options. 506 Messages that do not have these options MUST be silently 507 discarded. 508 2. The receiver MUST verify the signature as described in Section 509 5.3. Messages that fail this verification MUST be silently 510 discarded. 512 Still, even if the signature is verified correctly the host MUST 513 check that the node claiming to be a router acts as a real router. We 514 propose the following heuristic method: 516 - Each entry in the default router list of the host is marked either 517 as an UNTESTED, TESTED, or FAILED router. All new entries start 518 from the UNTESTED state. 520 - All communications from a host SHOULD use a router in the TESTED 521 state, unless there are only UNTESTED ones available. FAILED 522 routers SHOULD NOT be used for communications. 524 - When communicating to a non-local destination through the 525 designated router, the host SHOULD keep track of the upper layer 526 forward progress, in the same manner as is used in avoiding NUD 527 [ND98, Section 7.3]. If such forward progress is being made, the 528 router in question SHOULD be marked as TESTED. 530 - If no forward progress is being made, the host MAY attempt to send 531 an ICMPv6 Echo request to verify that the router is working. Such 532 requests MUST be addressed to a non-local destination known to the 533 host, and MUST be rate-limited in the usual manner. A reply moves 534 the router to the TESTED state. 536 - If no forward progress is being made, and no replies have been 537 seen, the router SHOULD be marked as FAILED. 539 - Routers that have not been used by the host for a period of 120 540 seconds SHOULD be marked as UNTESTED. 542 - Routers in the FAILED state may be periodically tested with the 543 ICMPv6 Echo request. 545 A similar process SHOULD be applied to test the prefixes advertised 546 by the router. 548 Note that this heuristic process is inherently weak in the sense that 549 a smart attacker could spoof response messages to unprotected 550 communications or to the Echo requests. For this purpose it is 551 strongly recommended that the hosts use only IPsec or TLS-protected 552 communications as an indication of forward progress. This requires, 553 however, that the hosts share a security association with another 554 node in the Internet. Public web servers with TLS support and a 555 certificate from a trusted root server are one possibility for 556 arranging this security association in an easy manner. 558 7.2. Redirect 560 Routers use CGA to prove that the Redirect message comes from the 561 right router. 563 All routers follow the rules defined below when transmitting Redirect 564 messages: 566 1. The router MUST use a CGA-based address as the source address in 567 the IPv6 header that carries the Redirect message. 569 2. The router MUST attach the Public Key ND option to the Redirect 570 message with the same parameters that were used in the 571 construction of address in the source address field. 572 3. The router MUST attach the Signature ND option to the Redirect 573 message, and calculates this signature as specified in Section 574 5.2. 576 All hosts follow the rules defined below when receiving Redirect 577 messages: 579 1. The Redirect message MUST have a Public Key and Signature ND 580 options. Messages that do not have these options MUST be 581 silently discarded. 582 2. The receiver MUST verify the signature as described in Section 583 5.3. Messages that fail this verification MUST be silently 584 discarded. 585 3. The receiver MUST verify that the Redirect message comes from an 586 IP address to which the host may have earlier sent the packet 587 that the Redirect message now partially returns. That is, the 588 source address of the Redirect message must be the default 589 router for traffic sent to the destination of the returned 590 packet. If this is not the case, the message MUST be silently 591 discarded. 593 Step 3 prevents a bogus router from sending a Redirect message when 594 the host is not using the bogus router as a default router. 596 8. Option Formats 598 8.1. Public Key Option 600 The Public Key Option carries a public key of the node. This option 601 follows the format presented in [ND98]: 603 0 1 2 3 604 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 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Type | Length | Algorithm ID1 | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | | 609 + Random + 610 | | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Algorithm ID2 | | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 614 | | 615 + Public Key (N bits) + 616 | | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 where, 620 Type An IANA assigned 8 bit identifier TBD for 621 the option type. 623 Length An 8 bit unsigned integer indicating 624 the option length (type + length fields) 625 in units of 8 octets. 627 Algorithm ID1 An IANA assigned 16 bit identifier for 628 the signature algorithm. The currently 629 defined values are: 631 1 RSA 633 Random A 64 bit random number used in the 634 creation of the address from the public 635 key. 637 Algorithm ID2 An IANA assigned 16 bit identifier for 638 the hash algorithm. The currently 639 defined values are: 641 1 SHA1 643 Public Key An N bit field carrying the public key, 644 zero-padded to nearest 8 byte units. 645 The public key is in the format implied 646 by Algorithm ID1. 648 8.2. Signature Option 650 The Signature Option carries a digital signature calculated using the 651 private key of the node. This option follows the format presented in 652 [ND98]: 654 0 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Type | Length | | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 659 | | 660 + Digital Signature (N bits) + 661 | | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 where, 665 Type An IANA assigned 8 bit identifier TBD for 666 the option type. 668 Length An 8 bit unsigned integer indicating the 669 option length (type + length fields) in 670 units of 8 octets. 672 Digital Signature An N bit field carrying the digital 673 signature, zero-padded to nearest 8 byte 674 units. The signature is calculated using 675 the algorithm implied by Algorithm ID1 in 676 the public key option, and is also in the 677 format implied by this Algorithm ID1. 679 9. Security Considerations 681 The CGA method assures that the received messages are coming from the 682 owner of the address. However, this method does not eliminate all 683 security vulnerabilities related to the ND functions. 685 CGA prevents spoofed answers to DAD queries. An attacker may still be 686 able to prevent valid responses or requests from reaching the 687 intended recipient. As a result both participants are forced to 688 believe that no address collision exists, when there in fact is. 690 Within Address Resolution and NUD functions CGA can be used to 691 prevent spoofed responses. However, it is still possible to prevent 692 the Address Resolution and NUD from completing for a given address. 693 For the NUD, this means that a node is claimed to be unreachable, 694 when it really is not. 696 Hosts can use CGA to show that the Redirect messages come from their 697 current router. Still, we cannot say anything about the other router 698 mentioned in the Redirect message. It is not clear if this is 699 necessary, however. (If necessary, we could cross-certify routers 700 without involving hosts.) 702 Within the Router Discovery functionality the CGA method ensures that 703 we are communicating with the same router all the time, and prevents 704 spoofing of the link-layer address of the router. But it does not 705 help to verify that the router is connected to the Internet or that 706 it is authorized to advertise a specific route prefix. A proper 707 verification of these properties will not be possible without 708 involving a trusted third party. However, we propose a heuristic 709 method to test these properties in Section 7.1. 711 10. Acknowledgments 713 The authors would like to thank James Kempf, Gabriel Montenegro, Erik 714 Nordmark, Tuomas Aura and Mike Roe for interesting discussions in 715 this problem space. 717 11. References 719 11.1. Normative References 721 [ND98] Narten, T., Nordmark, E., and Simpson, W., "Neighbor 722 discovery for IP Version 6 (IPv6)", RFC 2461, December, 1998. 724 [AUTOCONF98] Thomson, S., Narten, T., "IPv6 Stateless Address 725 Autoconfiguration", RFC 2462, December 1998. 727 [ADD98] Hinden, R., Deering, S., "IP Version 6 Addressing 728 Architecture", RFC 2372, July 1998. 730 [RSA78] Rivest, R., Shamir, A., Adleman, L. "A Method for Obtaining 731 Digital Signatures and Public-Key Cryptosystems", Communications of 732 the ACM, 21 (2), pp. 120-126, February 1978. 734 [SHA1] Eastlake, D., Jones, P., "US Secure Hash Algorithm 1 735 (SHA1)", RFC 3174, September 2001. 737 11.2. Non-Normative References 739 [ABK02] Kempf, J., Gentry, G., Silverberg, A., "Securing IPv6 740 Neighbor Discovery Using Address Based Keys (ABKs)", Internet 741 Draft (work in progress), February 2002. 743 [Ark01] Arkko, J., Nikander, P., Kivinen, T., Rossi, M., "Manual SA 744 Configuration for IPv6 link Local Messages", Internet Draft (work 745 in progress), January 2001. 747 [Ark02] Arkko, J., Aura, T., Kempf, T., Mantyla, V.-M., Nikander, 748 P., Roe, M. "Securing IPv6 Neighbor Discovery". Submitted for 749 publication, 2002. 751 [ARP82] Plummer, D. C., "An Ethernet Address Resolution Protocol -- 752 or -- Converting Network Protocol Addresses to 48.bit Ethernet 753 Address for Transmission on Ethernet Hardware", RFC 826, November 754 1982. 756 [CAM01] O'Shea, G., Roe, M., "Child-proof Authentication for MIPv6 757 (CAM), Computer Communications Review", April 2001. 759 [POS81] Postel, J., "Internet Control Message Protocol", RFC 792, 760 September 1981. 762 [SUCV] Montenegro, G., Castelluccia, C., "SUCV Identifiers and 763 Addresses", Internet Draft (work in progress), November 2001. 765 12. IPR Considerations 767 The presented protocol uses public keys and hashes to prove address 768 ownership. Ericsson's IPR may apply on such methods. The Ericsson 769 policy on IPR issues can be checked from the Ericsson General IPR 770 statement for IETF, http://www.ietf.org/ietf/IPR/ERICSSON-General. 772 13. Authors' Addresses 774 Jari Arkko 775 Oy LM Ericsson Ab 776 02420 Jorvas 777 Finland 779 EMail: jari.arkko@ericsson.com 781 Pekka Nikander 782 Oy LM Ericsson Ab 783 02420 Jorvas 784 Finland 786 EMail: pekka.nikander@nomadiclab.com 788 Vesa-Matti Mantyla 789 Oy LM Ericsson Ab 790 Tutkijantie 2C 791 90570 Oulu 792 Finland 794 EMail: vesa-matti.mantyla@ericsson.fi 796 Full Copyright Statement 798 Copyright (C) The Internet Society (2002). All Rights Reserved. 800 This document and translations of it may be copied and furnished to 801 others, and derivative works that comment on or otherwise explain it 802 or assist in its implementation may be prepared, copied, published 803 and distributed, in whole or in part, without restriction of any 804 kind, provided that the above copyright notice and this paragraph 805 areincluded on all such copies and derivative works. However, this 806 document itself may not be modified in any way, such as by removing 807 the copyright notice or references to the Internet Society or other 808 Internet organizations, except as needed for the purpose of 809 developing Internet standards in which case the procedures for 810 copyrights defined in the Internet Standards process must be 811 followed, or as required to translate it into languages other than 812 English. 814 The limited permissions granted above are perpetual and will not be 815 revoked by the Internet Society or its successors or assigns. 817 This document and the information contained herein is provided on an 818 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 819 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 820 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 821 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 822 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.