idnits 2.17.1 draft-montenegro-send-cga-rr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 363 has weird spacing: '...ill aid a nod...' -- 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 (March 3, 2003) is 7718 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) ** Obsolete normative reference: RFC 2461 (ref. '1') (Obsoleted by RFC 4861) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-21 == Outdated reference: A later version (-02) exists of draft-kempf-ipng-netaccess-threats-01 == Outdated reference: A later version (-01) exists of draft-kempf-secure-nd-00 -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '6') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2373 (ref. '7') (Obsoleted by RFC 3513) -- Obsolete informational reference (is this intentional?): RFC 2374 (ref. '8') (Obsoleted by RFC 3587) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Montenegro 3 Internet-Draft Sun Labs Europe 4 Expires: September 1, 2003 J. Laganier 5 ENS Lyon/Sun Labs Europe 6 C. Castelluccia 7 INRIA Rhone-Alpes 8 March 3, 2003 10 Securing IPv6 Neighbor Discovery 11 draft-montenegro-send-cga-rr-01 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 1, 2003. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 The known security vulnerabilities in Neighbor Discovery have not 43 been properly dealt with. This note suggests some techniques based 44 on cryptographically generated addresses and probes that may be 45 applied even in the absence of a pre-established security 46 relationship between the parties involved. 48 Table of Contents 50 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 51 2. Node Configuration and Requirements . . . . . . . . . . . . . 5 52 3. Securing Neighbor Advertisements . . . . . . . . . . . . . . . 6 53 4. Cryptographic Layering Enforcement (CLE) . . . . . . . . . . 7 54 5. Securing Router Advertisements . . . . . . . . . . . . . . . . 9 55 5.1 Delegation Certificate Chains . . . . . . . . . . . . . . . . 9 56 5.2 Reverse Probing and Traceroute . . . . . . . . . . . . . . . . 10 57 5.3 The Objective in Securing Router Advertisements . . . . . . . 12 58 5.4 Securing Redirects . . . . . . . . . . . . . . . . . . . . . . 13 59 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 61 8. Changes from Previous Versions . . . . . . . . . . . . . . . . 17 62 9. Intellectual Property Considerations . . . . . . . . . . . . . 18 63 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 64 Normative References . . . . . . . . . . . . . . . . . . . . . 20 65 Informative References . . . . . . . . . . . . . . . . . . . . 21 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 67 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23 69 1. Introduction and Problem Statement 71 [4] identified several security issues with IPv6 signaling packets 72 such as Neighbor discovery [1] and stateless address 73 autoconfiguration [6] Other issues are identified within the 74 specifications themselves. The usual recommendation is to use IPsec 75 to secure the traffic. 77 At the heart of these issues is the difficulty in securing a security 78 association such that any node can verify another node's 79 authorization when issuing a given IPv6 signaling packet. Such 80 difficulty precludes a straightforward application of IPsec between 81 any two previously unknown nodes (either of which may be a router). 82 The impossibility of always having the choice of obtaining such a 83 security association by leveraging a centralized infrastructure (PKI, 84 KDC, TTC, etc) has led to cryptographic techniques commonly known as 85 CGA or SUCV to be applied under similar constraints to problems of 86 securing Mobile IPv6 [3][10], group management for multicast and 87 anycast [12], and others. 89 Despite the strong cryptographic assurances afforded by the above, 90 Mobile IPv6 has adopted non-cryptographic techniques in its base 91 specification [2]. The basis of adopting the Return Routability (RR) 92 procedure is the assumption that by means of "liveness probes", trust 93 in the routing infrastructure can be leveraged to infer some level of 94 trust in binding updates. Of course, as in the MIPv6 case, relying 95 on probes does not offer as much protection as cryptographic 96 techniques. 98 Accordingly, this note presents a very high level overview of the 99 suggested techniques. Further details (including packet formats) 100 are deferred to other documents. We assume that the CGA-related 101 material is sent by some available means. This could either be 102 packets immediately preceding the protected neighbor discovery 103 messages (similar to how sucvP has been proposed to protect Mobile 104 IPv6 Binding Updates [3]) or a modified AH header preceding the ND 105 itself (as in the SEND protocol). Instead, the crypto material could 106 be sent as neighbor discovery options, as suggested by others. 107 However, in the interest of interoperability, the neighbor discovery 108 options mechanism mandates that any unrecognized options are simply 109 ignored. This allows, in effect, a very simple "bidding-down" attack 110 precluding requiring compliance with a secure version of neighbor 111 discovery. 113 This note proposes techniques based on CGA and probes to secure 114 neighbor discovery in the absence of any pre-existing security . 115 relationships. The initial version of this document aimed at 116 generating discussion about the proposed mechanisms. Most of these, 117 or some variant of them, are currently part of the official SEND 118 Protocol specification [11]. This document's only remaining sections 119 not included there are those on CLE and Reverse Probing and 120 Traceroute. We currently include all the sections to give better 121 background and context. Nevertheless, a future version of this 122 document may remove the redundant sections and instead reference the 123 SEND protocol specification more fully. 125 2. Node Configuration and Requirements 127 Each node that wants its messages to be verifiable (and heeded) by 128 other nodes generates a public-private key pair, PK and SK, 129 respectively. The nodes then use PK to obtain an IPv6 130 Cryptographically Generated Address (CGA): 132 CGA = NetworkPrefix | SHA1_64( PK | Imprint ) 134 Where Imprint is a fixed 64 bit quantity used to restrict the 135 validity scope of the CGA on which both parties have agreed. This is 136 usually the IPv6 Network Prefix as found in [10]. 138 Notice that this does not mandate that all nodes generate and use 139 SUCV addresses. This is only required for those nodes that wish to 140 sign their packets. 142 3. Securing Neighbor Advertisements 144 A Neighbor Solicitation message triggers the response of a Neighbor 145 Advertisement message. A direct application of CGA or SUCV would 146 have the node sign the Neighbor Advertisement packet with its private 147 key SK. Along with the packet, the node includes PK and its 148 signature in a format TBD. 150 At a receiving node, verification of this packet's signature produces 151 two assurances: 153 1. Integrity of the packet contents. 155 2. Data origin of the packet. 157 A node's Neighbor Advertisement messages need not change. If so, the 158 node can prepare the signed message in advance and simply send it out 159 when solicited. Nevertheless, the signed Neighbor Advertisement 160 message is significantly larger than the incoming Neighbor Discovery 161 message (it must carry the signature as well as the public key of the 162 source). Particularly when operating over wireless links, it is 163 desirable to limit transmission time as much as possible due to its 164 cost in terms of power (battery life) and money. 166 Because of this, it may also be desirable to delay sending the 167 Neighbor Advertisement (beyond the rate-limiting already mandated by 168 neighbor discovery) in order to protect against DoS attacks. 169 Accordingly, a procedure similar to sucvP [3] could be used by the 170 responding node's assuming that the initial Neighbor Discovery is 171 equivalent to sucvP1. Accordingly, instead of responding with a 172 signed Neighbor Advertisement packet, the responder may choose to 173 issue an sucvP2 packet containing a cookie puzzle for the initiator. 174 Receiving a valid solution in sucvP3 would finally cause the 175 responder to issue a signed Neighbor Advertisement message to the 176 initiator. 178 Nevertheless, such a procedure may be justified only if the objective 179 is to use sucvP in order to obtain a security association with the 180 peer. This would allow subsequent Neighbor Unreachability Detection 181 to be secured via HMAC as used with ESP, for example. 183 Neighbor Solicitation messages also have the cabapility to change 184 neighbor cache entries. Accordingly, the mechanism outlined above 185 may also be applied to secure these messages as well in order to 186 avoid caching non-authentic information. 188 4. Cryptographic Layering Enforcement (CLE) 190 Threats to Neighbor Discovery are particularly serious for multi- 191 access link-layers which use addresses to deliver frames or packets 192 [4]. The local delivery depends on correctly mapping the link-layer 193 (also known as MAC) addresses with the corresponding IP addresses. 194 When these identifiers are sufficiently long (more than 48 bits), 195 these bits may be used to improve the level of security provided by 196 CGA from 62 (of the 64 bits in the interface identifier portion of 197 the address) bits to approximately 100, and most commonly 110 bits. 198 This is secure enough for any application for a long time. These 199 link-layer addresses are usually outside the purview of the IETF. 200 The observation is that this lack of coordination between the IP 201 layer and the underlying link-layer is precisely the weakness that 202 makes them so easy to attack. 204 The CLE proposal aims at establishing a cryptographic coordination 205 between these two layers, thus closing this gaping hole in ND 206 security. This is a straighforward way to extend the security 207 afforded by CGA beyond the current 62 bits. The advantage of this 208 mechanism, as opposed to that suggested in [11] is its simplicity, 209 but above all, the fact that the additional security does not incur 210 additional work load when generating the addresses. This point is 211 essential for resource constrained devices, which will become 212 arguably the majority of the node population. 214 CLE defines the link-layer address (LLaddr) as a CGA using the same 215 public key as that used to generate the CGA IP address (IPaddr). 216 However, these two addresses use different bit ranges from the 217 resultant hash. For example: 219 (1) LLaddr = h_bottom( PK | Imprint ) 221 (2) IPaddr = h_top( PK | Imprint ) 223 By doing so, a node is able to prove that: 225 (3) It owns its IPaddr (protected by h_bottom bits) 227 (4) It owns its LLaddr (protected by h_top bits) 229 But what is most important, is the fact that the node can prove that 230 it is authorized to establish the mapping: 232 (5) IPaddr is at LLaddr (protected by h_top + h_bottom bits) 234 Thus, an attacker will have a much harder time finding a collision on 235 the mapping. Of course, the attackers task of defeating either the 236 link-layer or the IP level CGA when trying a candidate public key 237 PK_i is: 239 (6) P( LLaddr ) = probability that he'll find a collision with 240 PK_i such that LLaddr = h_bottom( PK_i ) 242 (7) P( IPaddr ) = probability that he'll find a collision with 243 PK_i such that IPaddr = h_top( PK_i ) 245 Given that the hash function acts as an unbiased random-bit generator 246 [13], (6) and (7) are independent events. 248 Since they are independent events, the probability of finding a valid 249 mapping (5) is then: 251 (8) P( IPaddr & LLaddr ) = P( IPaddr ) * P( LLaddr ) 253 So the attacker's task is much much harder than to defeat the 254 individual CGA addresses. 256 Furthermore, one could similarly protect other mappings between 257 addresses (for example, that of the home address and the care-of 258 address in Mobile IP). If one uses different bit ranges from the 259 hash output for the different CGA addresses, one can arrive at a 260 relationship between addresses which is very hard to forge. True, at 261 any given point in time, not all observers would be able to judge and 262 verify more than one such mapping (where each mapping specifies the 263 link between two addresses), but having all the address mappings obey 264 such strict cryptographic binding increases the chance that at least 265 one observer can detect attempted forgeries. 267 5. Securing Router Advertisements 269 Securing Router Advertisements is not as straightforward because what 270 is at hand is a router's authorization to "speak for" a given global 271 routing prefix [7], and CGA does not enable routing prefix 272 generation. 274 [5] proposes that ISP's generate private keys such that the 64 bit 275 prefix is the public key used by routers to sign their 276 advertisements. However, it is not clear why malicious nodes cannot 277 themselves generate these private keys using the same techniques as 278 the ISP's. Accordingly, it seems like in the absence of any security 279 relationship, trust in the routing hierarchy can be leveraged to 280 infer trust in any particular router. This is similar to the 281 justification behind return routability adopted by MIPv6 [2]. 283 In the interest of generating discussion, we present two different 284 proposals on how to carry this out. 286 5.1 Delegation Certificate Chains 288 Here, we use concepts similar to those in [12]. 290 Each router is also a CGA node. That is, each router has a public- 291 private key pair and uses CGA addresses as above. 293 The idea then is that each router R signs its router advertisements 294 using its private key. Additionally, each router must obtain a 295 delegation certificate such as is used in [12] signed by a router 296 higher up in the routing hierarchy (I). This certificate includes: 298 the public key of I 300 anything necessary to generate the SUCV address of I (perhaps an 301 anycast address itself) 303 delegation allowing R the right to handle the given 64 bit prefix 305 signed by I with its private key 307 Notice that R may include several such independently issued 308 certificates from I1, I2, ... Ij along with its Router 309 Advertisements. Presumably, the collection of signers I1..Ij would 310 include the routing authorities directly above R in the hierarchy, 311 but it should not be limited to these as it may prove beneficial to 312 have other authorities vouch for R as well. 314 The delegation certificate chain must be anchored at a public 315 topology point [8]. Each TLA must issue delegation certificates for 316 its NLA's. In order to verify routing advertisements from router R, 317 a node M verifies the chain up to the TLA. The first element in the 318 chain is the delegation certificate whereby IANA gives control of a 319 given TLA ID (i.e. /16 prefix) to the entity which owns a certain 320 public key. Let's call this the TLA authorization certificate, and 321 it must also include a secure binding between the TLA ID and the 322 public key of the entity owning that TLA ID: 324 TLA Authorization Certificate: 326 o signed by IANA 328 o beneficiary: an entity with public key P 330 o authorization to manage a given TLA ID 332 Now, verification of the entire chain requires secure establishment 333 of IANA's public key. This step is possible by IANA's using a third 334 party certificate (via a PKI provider) or via a grass-roots web of 335 trust certificate like PGP. Furthermore, IANA's public key can be 336 downloaded and verified in advance. It need not (should not) be done 337 in real-time, so chain verification can take place locally upon 338 receiving a signed router advertisement. 340 This method implies quite an overhead in terms of operations and 341 management. Also, each level in the hierarchy must also use SUCV 342 addresses in order for this chain to be verifiable in the absence of 343 a PKI. The overhead implied by the certificate chains may be reduced 344 by certificate reduction as explained in [12]. 346 Another possible optimization is for the visiting node to do some 347 preprocessing by downloading and verifying all the TLA authorization 348 certificates. This is certainly possible, given the maximum limit of 349 8,192 TLA authorization certificates with the current scheme [8]. 350 Doing this would enable the visiting node to save a list of TLA ID's 351 along with the corresponding public key of the managing entities. 352 This would save one verification step, that of the first element in 353 all chains. Such preprocessing would eliminate the need to send the 354 first element in the chain, saving on bandwidth as well as CPU. 356 Nevertheless, the main obstacle is probably convincing IANA to issue 357 the TLA authorization certificates as described above. 359 5.2 Reverse Probing and Traceroute 361 As compared to the previous method, this second method is much more 362 lightweight operationally. However, it presupposes the existence of 363 a "friendly" node, F, that will aid a node M in determining the 364 suitability of the different routers it discovers. 366 This assumes that M has trust in some part of the Internet, which it 367 then uses to derive some diminished level of trust in its vicinity 368 (just enough to decide which first hop router to use). 370 Suppose the following scenario in which M hears router advertisements 371 from multiple routers. Without loss of generality, assume there are 372 two such routers, R1 and R2, each advertising prefixes P1 and P2, 373 respectively. 375 M 376 / \ 377 / \ 378 R1 R2 379 | | 380 /-----------\ 381 | | 382 | Internet | 383 | | 384 \-----------/ 385 | 386 | 387 F 389 M has a "friend", F, in some other location with which it has mutual 390 trust, and which is willing to carry out certain operations on its 391 behalf. We assume M and F have a secure channel, perhaps via IPsec 392 ESP. The security association between them may be a pre-shared 393 secret, or established dynamically via IKE or sucvP (F could be M's 394 VPN gateway, for example). 396 M follows this algorithm: 398 If P1 != P2 it auto configures two addresses M1 and M2. 400 M sends simple probes to F via R1 and R2, using source addresses 401 M1 and M2, respectively. 403 If one performs much better (less dropped packets) than the other, 404 prefer that router. 406 If both perform approximately the same, request F to carry out a 407 reverse probe (perhaps augmented with reverse traceroute [9]) 408 towards M. 410 F reports results to M, and M chooses the "best" router. 412 The above assumes that a node can always reach a friendly system F 413 regardless of where it connects in the Internet. If this is not the 414 case, then presumably, M is not able to reach any trusted node, in 415 which case there is no trust to leverage from, so none of this 416 applies. 418 In the absence of any security relationship with the existing 419 infrastructure, involving the routing infrastructure in either of the 420 manners specified above seems to be a scalable method for an 421 arbitrary node to gain some level of trust in the surrounding routing 422 fabric. 424 5.3 The Objective in Securing Router Advertisements 426 Depending on which parties are interested in gaining trust in the 427 infrastructure, either of the above proposals may be a better fit. 429 For example, if the objective is for the routing fabric to verify 430 itself, then the first scheme using the delegation certificates would 431 allow basically any router within an administrative domain to verify 432 another router's authorization to route certain prefixes. Being 433 within an administrative domain allows the routers to 434 cryptographically derive strong trust in the surrounding 435 infrastructure. 437 This would apply as well to any node that belongs to that 438 administrative domain. Of course, being within a given 439 administrative domain would allow the use of conventional 440 certificates in which case CGA would not be necessary. The benefit 441 of using CGA addresses is that they imply the binding from a public 442 key to the corresponding address without recourse to a separate 443 certificate. 445 This seemingly small point has a large simplifying effect. Because 446 of this, even within a given administrative domain, the distributed 447 nature of CGA's helps in avoiding issues due to centralization 448 (bottlenecks, single points of failure, etc). 450 On the other hand, the objective may be to allow an arbitrary 451 visiting node to gain some level of confidence in the infrastructure 452 of a domain it is visiting. How much confidence? Just enough to be 453 able to choose a first-hop router. 455 However, this may not be a realistic expectation in the general case. 456 In particular, it may be able to verify the SUCV chain of delegation 457 and find its way to the TLA level (which it must verify independently 458 of SUCV) this implies no judgement on the scruples or practices of 459 the NLA. 461 It is interesting to compare this scenario to a node M which dials up 462 via a well-known public ISP. In this case, there is much greater 463 trust in the fact that the first hop router is indeed authorized to 464 perform that function. There is less doubt as PPP will only reveal 465 one such device on the other end, and because this process relies on 466 telephony routing which, presumably, is much harder to subvert than 467 internet routing. 469 Nevertheless, both situations are approximately the same in terms of 470 the precautions that M must take. Namely, in both cases there is 471 little or no trust in the intervening Internet fabric. Accordingly, 472 in both cases M must secure its communications in an end-to-end 473 fashion by using IKE with IPsec, sucvP with IPsec, TLS, SSH or 474 similar protocols. Even if there is complete trust in the first hop 475 router's authorization to route a certain prefix, this has little or 476 no bearing on the overall trust in the end-to-end path. Therefore, 477 choosing amongst multiple router advertisements becomes a question of 478 reliability. The objective of the above procedure is simply: 480 Find the most reliable first hop router upon which to establish a 481 secure end-to-end session. 483 Because of this, the procedure to choose should be predominantly 484 based on performance of the possibly multiple paths, as exemplified 485 by the procedure outlined previously. 487 5.4 Securing Redirects 489 [1] specifies the usage of AH during ND operations, but does not say 490 how to set up the associated SAs. Furthermore, a host may be 491 configured to ignore non AH-protected ICMP Redirect headers, to avoid 492 trivial spoofing attacks. 494 To avoid the loss of ICMP Redirect facility, we can secure the 495 message in the same way as ND: 497 o The router could include its signature along with the Redirect 498 header along the lines outlined above for Neighbor Advertisement 499 and solicitation. 501 Alternatively, the router could engage in sucvP as in [3] in order to 502 provide some protection against DoS attacks. In such a case: 504 o The router responds to the initial packet with the equivalent of 505 an sucvP2. 507 o To avoid DoS attacks, the router must not retain the redirected 508 destination address between the sending of p2 and the reception of 509 p3. So we must include in p3 the initial destination address to 510 allow the router to issue a p4 carrying an appropriate Redirect 511 message. 513 Note that we can obtain approximately the same level of trust by 514 asking the new preferred router (the target) to advertise the 515 neighbor prefix which matches the redirected address, and protecting 516 the NS-NA exchange with sucvP as shown in the previous section. 518 But it is also interesting to consider this as a mean of spinning a 519 web of trust from a router which support sucvP to others routers who 520 don't. In other words to gain trust from routing infrastructure. 521 However, we don't consider the matter of establishing trust between a 522 router issuing redirect messages targeted to a non-sucvP router. 523 This is out of scope. 525 6. Conclusion 527 This note presents a high level overview of how CGA and probing 528 techniques can be used to secure Neighbor Discovery. The techniques 529 are sufficiently well understood and can use widely deployed and 530 implemented mechanisms. This proposal works in the absence of any 531 previously established direct or indirect (via a broker, AAA roaming 532 operator or trusted third party) security relationship. Because of 533 this, these methods are very practical and deployable. 535 7. Security Considerations 537 This document discusses security issues specifically with respect to 538 neighbor discovery, and outlines some high level mechanisms to 539 address them. Some of the mechanisms discussed impose a heavy load 540 on processing nodes due to the use of public key cryptography. When 541 packets are not variable, these operations may be amortized at the 542 source by doing them once and reusing the resultant signed packets as 543 frequently as deemed appropriate. 545 However, this allows any node to replay the packets, misleading 546 Neighbor Unreachability Detection to incorrectly assume liveness for 547 the original signer of the packets. Accordingly, a replay protection 548 mechanism is in order. It may be possible to protect against replay 549 without incurring heavy processing costs by judicious use of hash 550 chain techniques. This is under study. 552 Many neighbor discovery operations include link-layer information. 553 In order to reap full benefit of CGA techniques, it is worthwhile 554 considering the option of using cryptographically generated address 555 at the link layer as well. Doing so would enable a node to not only 556 prove it has legitimate claim to using a given IPv6 address, but also 557 the underlying link-layer address. This is under study. 559 8. Changes from Previous Versions 561 This section details the non-editorial changes made in between the 562 different versions of this document. 564 From rev 00 to 01: 566 The publication of [11] is reflected throughout, for example by 567 allowing it as a possible means to obtain the CGA crypto material, 568 and by acknowledging that most of the topics in this draft are now 569 addressed in that SEND protocol document. 571 Addition of the section on CLE (cryptographic layering 572 enforcement). 574 9. Intellectual Property Considerations 576 The IETF takes no position regarding the validity or scope of 577 intellectual property or other rights that might be claimed pertain 578 to the implementation or use of the technology described in this 579 document or the extent to which any license under such rights might 580 or might not be available; neither does it represent that it has made 581 any effort to identify any such rights. Information on the IETF's 582 procedures with respect to rights in standards-track and standards- 583 related documentation can be found in BCP-11. Copies of claims of 584 rights made available for publication and any assurances of licenses 585 to be made available, or the result of an attempt made to obtain a 586 general license or permission for the use of such proprietary rights 587 by implementors or users of this specification can be obtained from 588 the IETF Secretariat. 590 The IETF invites any interested party to bring to its attention any 591 copyrights, patents or patent applications, or other proprietary 592 rights which may cover technology that may be required to practice 593 this standard. Please address the information to the IETF Executive 594 Director. 596 The IETF has been notified of intellectual property rights claimed in 597 regard to some or all of the specification contained in this 598 document. For more information consult the online list of claimed 599 rights. 601 10. Acknowledgements 603 Thanks to Jari Arkko, Jim Kempf and Erik Nordmark for their comments 604 and discussion. 606 Normative References 608 [1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 609 IP Version 6 (IPv6)", RFC 2461, December 1998. 611 Informative References 613 [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 614 IPv6", Internet-Draft http://www.ietf.org/internet-drafts/ 615 draft-ietf-mobileip-ipv6-21, February 2003. 617 [3] Montenegro, G. and C. Castelluccia, "Statistically Unique and 618 Cryptographically Verifiable (SUCV) Identifiers and 619 Addresses.", NDSS 2002, February 2002. 621 [4] Kempf, J. and E. Nordmark, "Threat Analysis for IPv6 Public 622 Multi-Access Links", draft-kempf-ipng-netaccess-threats-01 623 (work in progress), June 2002. 625 [5] Kempf, J., Gentry, C. and A. Silverberg, "Securing IPv6 626 Neighbor Discovery Using Address Based Keys (ABKs)", draft- 627 kempf-secure-nd-00.txt (work in progress), February 2002. 629 [6] Thomson, S. and T. Narten, "IPv6 Stateless Address 630 Autoconfiguration", RFC 2462, December 1998. 632 [7] Hinden, R. and S. Deering, "IP Version 6 Addressing 633 Architecture (under revision as "draft-ietf-ipngwg-addr-arch- 634 v3-07.txt)"", RFC 2373, July 1998. 636 [8] Hinden, R. and S. Deering, "An IPv6 Aggregatable Global Unicast 637 Address Format", RFC 2374, July 1998. 639 [9] "Reverse Tracing and Traceroute", Web Resources http:// 640 www.slac.stanford.edu/comp/net/wan-mon/traceroute-srv.html, 641 http://sourceforge.net/projects/rtraceroute/, //www.caida.org/ 642 analysis/routing/reversetrace/. 644 [10] Roe, M., Aura, T., O'Shea, G. and J. Arkko, "Authentication of 645 Mobile IPv6 Binding Updates and Acknowledgments", draft-roe- 646 mobileip-updateauth (work in progress), February 2002. 648 [11] Arkko, J., Kempf, J., Sommerfeld, B. and B. Zill, "SEcure 649 Neighbor Discovery (SEND)", draft-ietf-send-ipsec (work in 650 progress), February 2003. 652 [12] Castelluccia, C. and G. Montenegro, "Securing Group Management 653 in IPv6 with Cryptographically Generated Addresses", INRIA 654 Research Report RR-4523, August 2002. 656 [13] Schneier, B., "Applied Cryptography, Second Edition", Wiley , 657 1996. 659 Authors' Addresses 661 Gabriel Montenegro 662 Sun Labs Europe 663 29, chemin du Vieux Chene 664 38240 Meylan 665 France 667 EMail: gab@sun.com 669 Julien Laganier 670 ENS Lyon/Sun Labs Europe 671 46 Allee d'Italie 672 69007 Lyon 673 France 675 EMail: julien.laganier@sun.com 677 Claude Castelluccia 678 INRIA Rhone-Alpes 679 65 avenue de l'Europe 680 38330 Montbonnot Saint-Martin 681 France 683 EMail: claude.castelluccia@inria.fr 685 Full Copyright Statement 687 Copyright (C) The Internet Society (2003). All Rights Reserved. 689 This document and translations of it may be copied and furnished to 690 others, and derivative works that comment on or otherwise explain it 691 or assist in its implementation may be prepared, copied, published 692 and distributed, in whole or in part, without restriction of any 693 kind, provided that the above copyright notice and this paragraph are 694 included on all such copies and derivative works. However, this 695 document itself may not be modified in any way, such as by removing 696 the copyright notice or references to the Internet Society or other 697 Internet organizations, except as needed for the purpose of 698 developing Internet standards in which case the procedures for 699 copyrights defined in the Internet Standards process must be 700 followed, or as required to translate it into languages other than 701 English. 703 The limited permissions granted above are perpetual and will not be 704 revoked by the Internet Society or its successors or assigns. 706 This document and the information contained herein is provided on an 707 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 708 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 709 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 710 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 711 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 713 Acknowledgement 715 Funding for the RFC Editor function is currently provided by the 716 Internet Society.