Network Working Group G. Montenegro Internet-Draft Sun Labs Europe Expires: December 23, 2002 J. Laganier ENS Lyon/Sun Labs Europe C. Castelluccia INRIA Rhone-Alpes June 24, 2002 Securing IPv6 Neighbor Discovery draft-montenegro-send-cga-rr-00 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 December 23, 2002. Copyright Notice Copyright (C) The Internet Society (2002). 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 December 23, 2002 [Page 1] Internet-Draft Securing IPv6 Neighbor Discovery June 2002 Table of Contents 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 2. Node Configuration and Requirements . . . . . . . . . . . . . 4 3. Securing Neighbor Advertisements . . . . . . . . . . . . . . . 5 4. Securing Router Advertisements . . . . . . . . . . . . . . . . 6 4.1 Delegation Certificate Chains . . . . . . . . . . . . . . . . 6 4.2 Reverse Probing and Traceroute . . . . . . . . . . . . . . . . 7 4.3 The Objective in Securing Router Advertisements . . . . . . . 9 4.4 Securing Redirects . . . . . . . . . . . . . . . . . . . . . . 10 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Intellectual Property Considerations . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18 Montenegro, et al. Expires December 23, 2002 [Page 2] Internet-Draft Securing IPv6 Neighbor Discovery June 2002 1. Introduction and Problem Statement [3] identified several security issues with IPv6 signaling packets such as Neighbor discovery [8] and stateless address autoconfiguration [5] 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 [2][10], group management for multicast and anycast [11], and others. Despite the strong cryptographic assurances afforded by the above, Mobile IPv6 has adopted non-cryptographic techniques in its base specification [1]. The basis of adopting the Return Routability (RR) procedure is the realization by using "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. This note proposes techniques based on CGA and probes to secure neighbor discovery. The objective is to generate discussion and explore whether these techniques are applicable in the absence of any security relationship between the parties involved. 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 as sucvP packets immediately preceding the protected neighbor discovery messages, similar to how sucvP has been proposed to protect Mobile IPv6 Binding Updates [2]. 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. Montenegro, et al. Expires December 23, 2002 [Page 3] Internet-Draft Securing IPv6 Neighbor Discovery June 2002 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, P and S, respectively. The nodes then use P to obtain a Cryptographically Generated Address (CGA) as specified in [2]. 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 December 23, 2002 [Page 4] Internet-Draft Securing IPv6 Neighbor Discovery June 2002 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. Along with the packet, the node includes P 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 [2] 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 December 23, 2002 [Page 5] Internet-Draft Securing IPv6 Neighbor Discovery June 2002 4. 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 [6], and CGA does not enable routing prefix generation. [4] 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 [1]. In the interest of generating discussion, we present two different proposals on how to carry this out. 4.1 Delegation Certificate Chains Here, we use concepts similar to those in [11]. 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 sign its router advertisements using its private key. Additionally, each router must obtain a delegation certificate such as is used in [11] 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 December 23, 2002 [Page 6] Internet-Draft Securing IPv6 Neighbor Discovery June 2002 topology point [7]. 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 [11]. 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 [7]. 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. 4.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 December 23, 2002 [Page 7] Internet-Draft Securing IPv6 Neighbor Discovery June 2002 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 December 23, 2002 [Page 8] Internet-Draft Securing IPv6 Neighbor Discovery June 2002 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. 4.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 December 23, 2002 [Page 9] Internet-Draft Securing IPv6 Neighbor Discovery June 2002 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. 4.4 Securing Redirects [8] 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 [2] 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 December 23, 2002 [Page 10] Internet-Draft Securing IPv6 Neighbor Discovery June 2002 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 December 23, 2002 [Page 11] Internet-Draft Securing IPv6 Neighbor Discovery June 2002 5. 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 December 23, 2002 [Page 12] Internet-Draft Securing IPv6 Neighbor Discovery June 2002 6. 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 December 23, 2002 [Page 13] Internet-Draft Securing IPv6 Neighbor Discovery June 2002 7. Intellectual Property Considerations Ericsson and Microsoft have claimed intellectual property on the CGA mechanism. For more information see the IETF intellectual property web site. Montenegro, et al. Expires December 23, 2002 [Page 14] Internet-Draft Securing IPv6 Neighbor Discovery June 2002 8. Acknowledgements Thanks to Jari Arkko, Jim Kempf and Erik Nordmark for their comments and discussion. Montenegro, et al. Expires December 23, 2002 [Page 15] Internet-Draft Securing IPv6 Neighbor Discovery June 2002 References [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-mobileip-ipv6-16, March 2002. [2] Montenegro, G. and C. Castelluccia, "Statistically Unique and Cryptographically Verifiable (SUCV) Identifiers and Addresses.", NDSS 2002, February 2002. [3] Kempf, J. and E. Nordmark, "Threat Analysis for IPv6 Public Multi-Access Links", draft-kempf-ipng-netaccess-threats-01 (work in progress), June 2002. [4] 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. [5] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [6] 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. [7] Hinden, R. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998. [8] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 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-02 (work in progress), February 2002. [11] Castelluccia, C. and G. Montenegro, "Securing Group Management in IPv6 with Cryptographically Generated Addresses", draft- irtf-gsec-sgmv6-00 (work in progress), April 2002. Montenegro, et al. Expires December 23, 2002 [Page 16] Internet-Draft Securing IPv6 Neighbor Discovery June 2002 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 December 23, 2002 [Page 17] Internet-Draft Securing IPv6 Neighbor Discovery June 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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 December 23, 2002 [Page 18]