Network Working Group G. Montenegro Internet-Draft Sun Labs Europe Expires: September 1, 2003 J. Laganier ENS Lyon/Sun Labs Europe C. Castelluccia INRIA Rhone-Alpes March 3, 2003 Securing IPv6 Neighbor Discovery draft-montenegro-send-cga-rr-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 1, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The known security vulnerabilities in Neighbor Discovery have not been properly dealt with. This note suggests some techniques based on cryptographically generated addresses and probes that may be applied even in the absence of a pre-established security relationship between the parties involved. Montenegro, et al. Expires September 1, 2003 [Page 1] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 Table of Contents 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 2. Node Configuration and Requirements . . . . . . . . . . . . . 5 3. Securing Neighbor Advertisements . . . . . . . . . . . . . . . 6 4. Cryptographic Layering Enforcement (CLE) . . . . . . . . . . 7 5. Securing Router Advertisements . . . . . . . . . . . . . . . . 9 5.1 Delegation Certificate Chains . . . . . . . . . . . . . . . . 9 5.2 Reverse Probing and Traceroute . . . . . . . . . . . . . . . . 10 5.3 The Objective in Securing Router Advertisements . . . . . . . 12 5.4 Securing Redirects . . . . . . . . . . . . . . . . . . . . . . 13 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Changes from Previous Versions . . . . . . . . . . . . . . . . 17 9. Intellectual Property Considerations . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 Normative References . . . . . . . . . . . . . . . . . . . . . 20 Informative References . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23 Montenegro, et al. Expires September 1, 2003 [Page 2] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 1. Introduction and Problem Statement [4] identified several security issues with IPv6 signaling packets such as Neighbor discovery [1] and stateless address autoconfiguration [6] Other issues are identified within the specifications themselves. The usual recommendation is to use IPsec to secure the traffic. At the heart of these issues is the difficulty in securing a security association such that any node can verify another node's authorization when issuing a given IPv6 signaling packet. Such difficulty precludes a straightforward application of IPsec between any two previously unknown nodes (either of which may be a router). The impossibility of always having the choice of obtaining such a security association by leveraging a centralized infrastructure (PKI, KDC, TTC, etc) has led to cryptographic techniques commonly known as CGA or SUCV to be applied under similar constraints to problems of securing Mobile IPv6 [3][10], group management for multicast and anycast [12], and others. Despite the strong cryptographic assurances afforded by the above, Mobile IPv6 has adopted non-cryptographic techniques in its base specification [2]. The basis of adopting the Return Routability (RR) procedure is the assumption that by means of "liveness probes", trust in the routing infrastructure can be leveraged to infer some level of trust in binding updates. Of course, as in the MIPv6 case, relying on probes does not offer as much protection as cryptographic techniques. Accordingly, this note presents a very high level overview of the suggested techniques. Further details (including packet formats) are deferred to other documents. We assume that the CGA-related material is sent by some available means. This could either be packets immediately preceding the protected neighbor discovery messages (similar to how sucvP has been proposed to protect Mobile IPv6 Binding Updates [3]) or a modified AH header preceding the ND itself (as in the SEND protocol). Instead, the crypto material could be sent as neighbor discovery options, as suggested by others. However, in the interest of interoperability, the neighbor discovery options mechanism mandates that any unrecognized options are simply ignored. This allows, in effect, a very simple "bidding-down" attack precluding requiring compliance with a secure version of neighbor discovery. This note proposes techniques based on CGA and probes to secure neighbor discovery in the absence of any pre-existing security . relationships. The initial version of this document aimed at generating discussion about the proposed mechanisms. Most of these, Montenegro, et al. Expires September 1, 2003 [Page 3] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 or some variant of them, are currently part of the official SEND Protocol specification [11]. This document's only remaining sections not included there are those on CLE and Reverse Probing and Traceroute. We currently include all the sections to give better background and context. Nevertheless, a future version of this document may remove the redundant sections and instead reference the SEND protocol specification more fully. Montenegro, et al. Expires September 1, 2003 [Page 4] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 2. Node Configuration and Requirements Each node that wants its messages to be verifiable (and heeded) by other nodes generates a public-private key pair, PK and SK, respectively. The nodes then use PK to obtain an IPv6 Cryptographically Generated Address (CGA): CGA = NetworkPrefix | SHA1_64( PK | Imprint ) Where Imprint is a fixed 64 bit quantity used to restrict the validity scope of the CGA on which both parties have agreed. This is usually the IPv6 Network Prefix as found in [10]. Notice that this does not mandate that all nodes generate and use SUCV addresses. This is only required for those nodes that wish to sign their packets. Montenegro, et al. Expires September 1, 2003 [Page 5] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 3. Securing Neighbor Advertisements A Neighbor Solicitation message triggers the response of a Neighbor Advertisement message. A direct application of CGA or SUCV would have the node sign the Neighbor Advertisement packet with its private key SK. Along with the packet, the node includes PK and its signature in a format TBD. At a receiving node, verification of this packet's signature produces two assurances: 1. Integrity of the packet contents. 2. Data origin of the packet. A node's Neighbor Advertisement messages need not change. If so, the node can prepare the signed message in advance and simply send it out when solicited. Nevertheless, the signed Neighbor Advertisement message is significantly larger than the incoming Neighbor Discovery message (it must carry the signature as well as the public key of the source). Particularly when operating over wireless links, it is desirable to limit transmission time as much as possible due to its cost in terms of power (battery life) and money. Because of this, it may also be desirable to delay sending the Neighbor Advertisement (beyond the rate-limiting already mandated by neighbor discovery) in order to protect against DoS attacks. Accordingly, a procedure similar to sucvP [3] could be used by the responding node's assuming that the initial Neighbor Discovery is equivalent to sucvP1. Accordingly, instead of responding with a signed Neighbor Advertisement packet, the responder may choose to issue an sucvP2 packet containing a cookie puzzle for the initiator. Receiving a valid solution in sucvP3 would finally cause the responder to issue a signed Neighbor Advertisement message to the initiator. Nevertheless, such a procedure may be justified only if the objective is to use sucvP in order to obtain a security association with the peer. This would allow subsequent Neighbor Unreachability Detection to be secured via HMAC as used with ESP, for example. Neighbor Solicitation messages also have the cabapility to change neighbor cache entries. Accordingly, the mechanism outlined above may also be applied to secure these messages as well in order to avoid caching non-authentic information. Montenegro, et al. Expires September 1, 2003 [Page 6] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 4. Cryptographic Layering Enforcement (CLE) Threats to Neighbor Discovery are particularly serious for multi- access link-layers which use addresses to deliver frames or packets [4]. The local delivery depends on correctly mapping the link-layer (also known as MAC) addresses with the corresponding IP addresses. When these identifiers are sufficiently long (more than 48 bits), these bits may be used to improve the level of security provided by CGA from 62 (of the 64 bits in the interface identifier portion of the address) bits to approximately 100, and most commonly 110 bits. This is secure enough for any application for a long time. These link-layer addresses are usually outside the purview of the IETF. The observation is that this lack of coordination between the IP layer and the underlying link-layer is precisely the weakness that makes them so easy to attack. The CLE proposal aims at establishing a cryptographic coordination between these two layers, thus closing this gaping hole in ND security. This is a straighforward way to extend the security afforded by CGA beyond the current 62 bits. The advantage of this mechanism, as opposed to that suggested in [11] is its simplicity, but above all, the fact that the additional security does not incur additional work load when generating the addresses. This point is essential for resource constrained devices, which will become arguably the majority of the node population. CLE defines the link-layer address (LLaddr) as a CGA using the same public key as that used to generate the CGA IP address (IPaddr). However, these two addresses use different bit ranges from the resultant hash. For example: (1) LLaddr = h_bottom( PK | Imprint ) (2) IPaddr = h_top( PK | Imprint ) By doing so, a node is able to prove that: (3) It owns its IPaddr (protected by h_bottom bits) (4) It owns its LLaddr (protected by h_top bits) But what is most important, is the fact that the node can prove that it is authorized to establish the mapping: (5) IPaddr is at LLaddr (protected by h_top + h_bottom bits) Thus, an attacker will have a much harder time finding a collision on the mapping. Of course, the attackers task of defeating either the Montenegro, et al. Expires September 1, 2003 [Page 7] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 link-layer or the IP level CGA when trying a candidate public key PK_i is: (6) P( LLaddr ) = probability that he'll find a collision with PK_i such that LLaddr = h_bottom( PK_i ) (7) P( IPaddr ) = probability that he'll find a collision with PK_i such that IPaddr = h_top( PK_i ) Given that the hash function acts as an unbiased random-bit generator [13], (6) and (7) are independent events. Since they are independent events, the probability of finding a valid mapping (5) is then: (8) P( IPaddr & LLaddr ) = P( IPaddr ) * P( LLaddr ) So the attacker's task is much much harder than to defeat the individual CGA addresses. Furthermore, one could similarly protect other mappings between addresses (for example, that of the home address and the care-of address in Mobile IP). If one uses different bit ranges from the hash output for the different CGA addresses, one can arrive at a relationship between addresses which is very hard to forge. True, at any given point in time, not all observers would be able to judge and verify more than one such mapping (where each mapping specifies the link between two addresses), but having all the address mappings obey such strict cryptographic binding increases the chance that at least one observer can detect attempted forgeries. Montenegro, et al. Expires September 1, 2003 [Page 8] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 5. Securing Router Advertisements Securing Router Advertisements is not as straightforward because what is at hand is a router's authorization to "speak for" a given global routing prefix [7], and CGA does not enable routing prefix generation. [5] proposes that ISP's generate private keys such that the 64 bit prefix is the public key used by routers to sign their advertisements. However, it is not clear why malicious nodes cannot themselves generate these private keys using the same techniques as the ISP's. Accordingly, it seems like in the absence of any security relationship, trust in the routing hierarchy can be leveraged to infer trust in any particular router. This is similar to the justification behind return routability adopted by MIPv6 [2]. In the interest of generating discussion, we present two different proposals on how to carry this out. 5.1 Delegation Certificate Chains Here, we use concepts similar to those in [12]. Each router is also a CGA node. That is, each router has a public- private key pair and uses CGA addresses as above. The idea then is that each router R signs its router advertisements using its private key. Additionally, each router must obtain a delegation certificate such as is used in [12] signed by a router higher up in the routing hierarchy (I). This certificate includes: the public key of I anything necessary to generate the SUCV address of I (perhaps an anycast address itself) delegation allowing R the right to handle the given 64 bit prefix signed by I with its private key Notice that R may include several such independently issued certificates from I1, I2, ... Ij along with its Router Advertisements. Presumably, the collection of signers I1..Ij would include the routing authorities directly above R in the hierarchy, but it should not be limited to these as it may prove beneficial to have other authorities vouch for R as well. The delegation certificate chain must be anchored at a public Montenegro, et al. Expires September 1, 2003 [Page 9] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 topology point [8]. Each TLA must issue delegation certificates for its NLA's. In order to verify routing advertisements from router R, a node M verifies the chain up to the TLA. The first element in the chain is the delegation certificate whereby IANA gives control of a given TLA ID (i.e. /16 prefix) to the entity which owns a certain public key. Let's call this the TLA authorization certificate, and it must also include a secure binding between the TLA ID and the public key of the entity owning that TLA ID: TLA Authorization Certificate: o signed by IANA o beneficiary: an entity with public key P o authorization to manage a given TLA ID Now, verification of the entire chain requires secure establishment of IANA's public key. This step is possible by IANA's using a third party certificate (via a PKI provider) or via a grass-roots web of trust certificate like PGP. Furthermore, IANA's public key can be downloaded and verified in advance. It need not (should not) be done in real-time, so chain verification can take place locally upon receiving a signed router advertisement. This method implies quite an overhead in terms of operations and management. Also, each level in the hierarchy must also use SUCV addresses in order for this chain to be verifiable in the absence of a PKI. The overhead implied by the certificate chains may be reduced by certificate reduction as explained in [12]. Another possible optimization is for the visiting node to do some preprocessing by downloading and verifying all the TLA authorization certificates. This is certainly possible, given the maximum limit of 8,192 TLA authorization certificates with the current scheme [8]. Doing this would enable the visiting node to save a list of TLA ID's along with the corresponding public key of the managing entities. This would save one verification step, that of the first element in all chains. Such preprocessing would eliminate the need to send the first element in the chain, saving on bandwidth as well as CPU. Nevertheless, the main obstacle is probably convincing IANA to issue the TLA authorization certificates as described above. 5.2 Reverse Probing and Traceroute As compared to the previous method, this second method is much more lightweight operationally. However, it presupposes the existence of Montenegro, et al. Expires September 1, 2003 [Page 10] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 a "friendly" node, F, that will aid a node M in determining the suitability of the different routers it discovers. This assumes that M has trust in some part of the Internet, which it then uses to derive some diminished level of trust in its vicinity (just enough to decide which first hop router to use). Suppose the following scenario in which M hears router advertisements from multiple routers. Without loss of generality, assume there are two such routers, R1 and R2, each advertising prefixes P1 and P2, respectively. M / \ / \ R1 R2 | | /-----------\ | | | Internet | | | \-----------/ | | F M has a "friend", F, in some other location with which it has mutual trust, and which is willing to carry out certain operations on its behalf. We assume M and F have a secure channel, perhaps via IPsec ESP. The security association between them may be a pre-shared secret, or established dynamically via IKE or sucvP (F could be M's VPN gateway, for example). M follows this algorithm: If P1 != P2 it auto configures two addresses M1 and M2. M sends simple probes to F via R1 and R2, using source addresses M1 and M2, respectively. If one performs much better (less dropped packets) than the other, prefer that router. If both perform approximately the same, request F to carry out a reverse probe (perhaps augmented with reverse traceroute [9]) towards M. Montenegro, et al. Expires September 1, 2003 [Page 11] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 F reports results to M, and M chooses the "best" router. The above assumes that a node can always reach a friendly system F regardless of where it connects in the Internet. If this is not the case, then presumably, M is not able to reach any trusted node, in which case there is no trust to leverage from, so none of this applies. In the absence of any security relationship with the existing infrastructure, involving the routing infrastructure in either of the manners specified above seems to be a scalable method for an arbitrary node to gain some level of trust in the surrounding routing fabric. 5.3 The Objective in Securing Router Advertisements Depending on which parties are interested in gaining trust in the infrastructure, either of the above proposals may be a better fit. For example, if the objective is for the routing fabric to verify itself, then the first scheme using the delegation certificates would allow basically any router within an administrative domain to verify another router's authorization to route certain prefixes. Being within an administrative domain allows the routers to cryptographically derive strong trust in the surrounding infrastructure. This would apply as well to any node that belongs to that administrative domain. Of course, being within a given administrative domain would allow the use of conventional certificates in which case CGA would not be necessary. The benefit of using CGA addresses is that they imply the binding from a public key to the corresponding address without recourse to a separate certificate. This seemingly small point has a large simplifying effect. Because of this, even within a given administrative domain, the distributed nature of CGA's helps in avoiding issues due to centralization (bottlenecks, single points of failure, etc). On the other hand, the objective may be to allow an arbitrary visiting node to gain some level of confidence in the infrastructure of a domain it is visiting. How much confidence? Just enough to be able to choose a first-hop router. However, this may not be a realistic expectation in the general case. In particular, it may be able to verify the SUCV chain of delegation and find its way to the TLA level (which it must verify independently Montenegro, et al. Expires September 1, 2003 [Page 12] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 of SUCV) this implies no judgement on the scruples or practices of the NLA. It is interesting to compare this scenario to a node M which dials up via a well-known public ISP. In this case, there is much greater trust in the fact that the first hop router is indeed authorized to perform that function. There is less doubt as PPP will only reveal one such device on the other end, and because this process relies on telephony routing which, presumably, is much harder to subvert than internet routing. Nevertheless, both situations are approximately the same in terms of the precautions that M must take. Namely, in both cases there is little or no trust in the intervening Internet fabric. Accordingly, in both cases M must secure its communications in an end-to-end fashion by using IKE with IPsec, sucvP with IPsec, TLS, SSH or similar protocols. Even if there is complete trust in the first hop router's authorization to route a certain prefix, this has little or no bearing on the overall trust in the end-to-end path. Therefore, choosing amongst multiple router advertisements becomes a question of reliability. The objective of the above procedure is simply: Find the most reliable first hop router upon which to establish a secure end-to-end session. Because of this, the procedure to choose should be predominantly based on performance of the possibly multiple paths, as exemplified by the procedure outlined previously. 5.4 Securing Redirects [1] specifies the usage of AH during ND operations, but does not say how to set up the associated SAs. Furthermore, a host may be configured to ignore non AH-protected ICMP Redirect headers, to avoid trivial spoofing attacks. To avoid the loss of ICMP Redirect facility, we can secure the message in the same way as ND: o The router could include its signature along with the Redirect header along the lines outlined above for Neighbor Advertisement and solicitation. Alternatively, the router could engage in sucvP as in [3] in order to provide some protection against DoS attacks. In such a case: o The router responds to the initial packet with the equivalent of an sucvP2. Montenegro, et al. Expires September 1, 2003 [Page 13] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 o To avoid DoS attacks, the router must not retain the redirected destination address between the sending of p2 and the reception of p3. So we must include in p3 the initial destination address to allow the router to issue a p4 carrying an appropriate Redirect message. Note that we can obtain approximately the same level of trust by asking the new preferred router (the target) to advertise the neighbor prefix which matches the redirected address, and protecting the NS-NA exchange with sucvP as shown in the previous section. But it is also interesting to consider this as a mean of spinning a web of trust from a router which support sucvP to others routers who don't. In other words to gain trust from routing infrastructure. However, we don't consider the matter of establishing trust between a router issuing redirect messages targeted to a non-sucvP router. This is out of scope. Montenegro, et al. Expires September 1, 2003 [Page 14] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 6. Conclusion This note presents a high level overview of how CGA and probing techniques can be used to secure Neighbor Discovery. The techniques are sufficiently well understood and can use widely deployed and implemented mechanisms. This proposal works in the absence of any previously established direct or indirect (via a broker, AAA roaming operator or trusted third party) security relationship. Because of this, these methods are very practical and deployable. Montenegro, et al. Expires September 1, 2003 [Page 15] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 7. Security Considerations This document discusses security issues specifically with respect to neighbor discovery, and outlines some high level mechanisms to address them. Some of the mechanisms discussed impose a heavy load on processing nodes due to the use of public key cryptography. When packets are not variable, these operations may be amortized at the source by doing them once and reusing the resultant signed packets as frequently as deemed appropriate. However, this allows any node to replay the packets, misleading Neighbor Unreachability Detection to incorrectly assume liveness for the original signer of the packets. Accordingly, a replay protection mechanism is in order. It may be possible to protect against replay without incurring heavy processing costs by judicious use of hash chain techniques. This is under study. Many neighbor discovery operations include link-layer information. In order to reap full benefit of CGA techniques, it is worthwhile considering the option of using cryptographically generated address at the link layer as well. Doing so would enable a node to not only prove it has legitimate claim to using a given IPv6 address, but also the underlying link-layer address. This is under study. Montenegro, et al. Expires September 1, 2003 [Page 16] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 8. Changes from Previous Versions This section details the non-editorial changes made in between the different versions of this document. From rev 00 to 01: The publication of [11] is reflected throughout, for example by allowing it as a possible means to obtain the CGA crypto material, and by acknowledging that most of the topics in this draft are now addressed in that SEND protocol document. Addition of the section on CLE (cryptographic layering enforcement). Montenegro, et al. Expires September 1, 2003 [Page 17] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 9. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of intellectual property or other rights that might be claimed pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Montenegro, et al. Expires September 1, 2003 [Page 18] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 10. Acknowledgements Thanks to Jari Arkko, Jim Kempf and Erik Nordmark for their comments and discussion. Montenegro, et al. Expires September 1, 2003 [Page 19] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 Normative References [1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. Montenegro, et al. Expires September 1, 2003 [Page 20] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 Informative References [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-mobileip-ipv6-21, February 2003. [3] Montenegro, G. and C. Castelluccia, "Statistically Unique and Cryptographically Verifiable (SUCV) Identifiers and Addresses.", NDSS 2002, February 2002. [4] Kempf, J. and E. Nordmark, "Threat Analysis for IPv6 Public Multi-Access Links", draft-kempf-ipng-netaccess-threats-01 (work in progress), June 2002. [5] Kempf, J., Gentry, C. and A. Silverberg, "Securing IPv6 Neighbor Discovery Using Address Based Keys (ABKs)", draft- kempf-secure-nd-00.txt (work in progress), February 2002. [6] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [7] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture (under revision as "draft-ietf-ipngwg-addr-arch- v3-07.txt)"", RFC 2373, July 1998. [8] Hinden, R. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998. [9] "Reverse Tracing and Traceroute", Web Resources http:// www.slac.stanford.edu/comp/net/wan-mon/traceroute-srv.html, http://sourceforge.net/projects/rtraceroute/, //www.caida.org/ analysis/routing/reversetrace/. [10] Roe, M., Aura, T., O'Shea, G. and J. Arkko, "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", draft-roe- mobileip-updateauth (work in progress), February 2002. [11] Arkko, J., Kempf, J., Sommerfeld, B. and B. Zill, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ipsec (work in progress), February 2003. [12] Castelluccia, C. and G. Montenegro, "Securing Group Management in IPv6 with Cryptographically Generated Addresses", INRIA Research Report RR-4523, August 2002. [13] Schneier, B., "Applied Cryptography, Second Edition", Wiley , 1996. Montenegro, et al. Expires September 1, 2003 [Page 21] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 Authors' Addresses Gabriel Montenegro Sun Labs Europe 29, chemin du Vieux Chene 38240 Meylan France EMail: gab@sun.com Julien Laganier ENS Lyon/Sun Labs Europe 46 Allee d'Italie 69007 Lyon France EMail: julien.laganier@sun.com Claude Castelluccia INRIA Rhone-Alpes 65 avenue de l'Europe 38330 Montbonnot Saint-Martin France EMail: claude.castelluccia@inria.fr Montenegro, et al. Expires September 1, 2003 [Page 22] Internet-Draft Securing IPv6 Neighbor Discovery March 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Montenegro, et al. Expires September 1, 2003 [Page 23]