Network Working Group G. Daley Internet-Draft Monash University CTIE Expires: January 10, 2005 July 12, 2004 Securing Proxy Neighbour Discovery Problem Statement draft-daley-send-spnd-prob-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 January 10, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Proxy Neighbour Discovery is used to provide an address presence on a link from hosts which are absent. It allows a host to receive packets directed at its address by allowing another device to neighbour advertise on its behalf. Proxy Neighbour Discovery is used in Mobile IPv6 and related protocols to provide reachability from hosts on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. Daley Expires January 10, 2005 [Page 1] Internet-Draft Securing PND Problem Statement July 2004 Proxy Neighbour Discovery currently cannot be secured using SEND. SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbour Discovery relates to Secured Neighbour Discovery. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Proxy Neighbour Discovery and SEND . . . . . . . . . . . . . . 4 3. Proxy ND in Mobility . . . . . . . . . . . . . . . . . . . . . 4 4. Potential Approaches to Securing Proxy ND . . . . . . . . . . 5 5. Secured Proxy ND and Mobile IPv6 . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7.1 Router Trust Assumption . . . . . . . . . . . . . . . . . 6 7.2 Certificate Transport . . . . . . . . . . . . . . . . . . 7 7.3 Timekeeping . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 9.2 Informative References . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 Daley Expires January 10, 2005 [Page 2] Internet-Draft Securing PND Problem Statement July 2004 1. Introduction Proxy Neighbour Discovery is defined in IPv6 Neighbour Discovery and is used in Mobile IPv6 [2][4]. It allows a device which is not physically present on a link to have another advertise its presence, and forward on packets to the off-link device. Proxy Neighbour Discovery relies upon another device, the proxy, to monitor for Neighbour Solicitations, and answer with Neighbour Advertisements. These proxy Neighbour Advertisements direct data traffic through the proxy. Proxied traffic is then forwarded on to the end destination. When moving in the Internet, the aim of Mobile IPv6 is to allow a device continued packet delivery, whether present on its home network or not. For Mobile IPv6 Mobile Nodes (MNs), it is necessary to keep existing sessions going even when one leaves the home network. If a neighbour is actively delivering packets to a Mobile Node which is at home, this neighbour will have a valid neighbour cache entry pointed at the MN's link-layer address on the Home link. If Cryptographically Generated Addressing (CGA) is available, the MN may be able to secure its neighbour cache bindings while at home using Secured Neighbour Discovery (SEND) [5]. SEND assumes that the address owner is the advertiser and therefore has access to the keys required to sign advertisements about the address. Movement away from the home link requires that a proxy undertake Neighbour Discovery. In Mobile IPv6, the role of the proxy is undertaken by the Home Agent. While the Home agent has a security association with the MN, it as proxy will not have access to the public-private key pair used to generate the MN's cryptographic address. This prevents Proxy Neighbour Discovery from using SEND as defined [5]. Where a host moves from the home network to a visited network, the proxy needs to override existing valid neighbour cache entries which may have SEND protection. This is needed in order to redirect traffic to use the proxy's link-layer address, allowing packets to flow onto the tunnel connecting the Home Agent/Proxy and the MN. With current specifications, any solicitation or advertisement sent by the proxy will not be able to update the MN's home address if the existing NC entry is protected by SEND. Such existing neighbour cache entries will time-out after Neighbour Unreachability Detection [2]. Where secured proxy services are not able to be provided, a proxy's advertisement may be overridden by a bogus proxy without it even Daley Expires January 10, 2005 [Page 3] Internet-Draft Securing PND Problem Statement July 2004 knowing the attack has occurred. This document describes some of the issues in providing security for proxy Neighbour Discovery, and how Mobile IPv6 interacts with these requirements. 2. Proxy Neighbour Discovery and SEND There are currently no existing secured Neighbour Discovery procedures for proxied addresses, and all Neighbour Advertisements from SEND nodes are required to have equal source and target addresses (section 7.4 of [5]). Signatures over SEND messages are required to be applied on the CGA source address of the message, and there is no way of indicating that a message is proxied. Therefore, a router wishing to provide proxy Neighbour Advertisement service can not use SEND on those messages. A host may wish to establish a session with a device which is not on-link but is proxied. As a SEND host, it prefers to create neighbour cache entries using secured procedures. Since SEND signatures cannot be applied to an existing proxy Neighbour Advertisement, it must accept non-SEND advertisements in order to receive proxy Neighbour Advertisements. Neighbour Cache spoofing of another host therefore becomes trivial, as any address may be proxy advertised to the SEND node, and overridden only if the node is there to protect itself. When a node is present to defend itself, it may also be difficult for the solicitor determine the difference between a proxy-spoofing attack, and a situation where a proxied device returns to a link and overrides other proxy advertisers [2]. Initiation of Proxy Neighbour Discovery also requires Duplicate Address Detection (DAD) checks of the address[3]. These DAD checks need to be performed by sending Neighbour Solicitations, from the unspecified source address, with the target being the proxied address. In SEND, the address which is used for CGA tests on DAD NSs is the target address. A Proxy is unable to generate a signature for this address and must undertake DAD with an unsecured NS. 3. Proxy ND in Mobility Whenever a mobile device moves off a link and requires another device to forward packets from that address to the MN's new location, proxy Neighbour Discovery is required. Daley Expires January 10, 2005 [Page 4] Internet-Draft Securing PND Problem Statement July 2004 In the Mobile IPv6 case, where the Mobile Node moves away from home, a Home Agent needs to be able to override existing neighbour cache entries in order to redirect packet flow over a tunnel to the Mobile Node's CoA [4]. In Fast Handovers for Mobile IPv6, local neighbours or routers with existing valid neighbour cache states need to be told the PAR's link-layer address when the MN is departing for a new link, or after arrival on the new link when tunnel forwarding begins[6]. This allows the MN to maintain reachability to the hosts on that link until it is able to send Mobile IPv6 Binding signalling subsequent to address configuration on the new network. 4. Potential Approaches to Securing Proxy ND SEND nodes already have the concept of delegated authority through requiring external authorization of routers to perform their routing and advertisement roles. The authorization of these routers takes the form of delegation certificates. Proxy Neighbour Discovery requires a delegation of authority on behalf of the absent address owner, to the proxier. Without this authority, other devices on the link have no reason to trust an advertiser. Existing trust relationships lend themselves to providing authority for proxying in two alternative ways. First, the SEND router authorization mechanisms described above provide delegation from the organization responsible for routing in an address domain, to the certified routers. It may be argued that routers so certified may be trusted to provide service for nodes which form part of a link's address range, but are themselves absent. Second, where the proxied address is itself a CGA, the holder of the public and private keys is seen to be authoritative about the address' use. If this address owner was able to sign the proxier's address and public key information, it would be possible to identify that the proxy is known and trusted by the CGA address owner for proxy service. This method requires that the proxied address know or learn the proxy's address and public key, and that the certificate signed by the proxied node's is passed to the proxy, either while they share the same link, or at a later stage. In both methods, the original address owner's advertisements need to override the proxy if it suddenly returns, and therefore timing and replay protection from such messages need to be carefully considered. Daley Expires January 10, 2005 [Page 5] Internet-Draft Securing PND Problem Statement July 2004 5. Secured Proxy ND and Mobile IPv6 Mobile IPv6 has a security association between the Mobile Node and Home Agent. The Mobile Node sends a Binding Update to the Home Agent, to indicate that it is not at home. This implies that the Mobile Node wishes the Home Agent to begin proxy Neighbour Discovery operations for its home address(es). Proxy Neighbour Advertisements based on existing router trust require no explicit authorization signalling between HA and MN to allow proxying. Existing hosts on the home link will believe advertisements solely because they come from a trusted router. Where proxy Neighbour Discovery is delegated by the MN to the home agent as proxy, the MN needs to learn the CGA public key for the Home Agent, so that it can generate a certificate authorizing this address and public-private key-pair to be used in proxying. It may conceivably either do this using Delegation Chain Solicitations over a home tunnel, over the Internet, or Router Discovery while still at home [5]. When sending its Binding Update to the HA, the MN would need to provide a certificate containing the subject(proxy-HA)'s CGA public key and address, the issuer(MN)'s CGA and public key, and timestamps indicating when the authority began and when it ends. This certificate would need to be passed near to binding time, possibly in a Delegation Chain Advertisement[5]. 6. IANA Considerations No new options or messages are defined in this document. 7. Security Considerations This document is at a very early stage of its development. The author actively elicits feedback regarding the security issues for proxy Neighbour Discovery and the potential solution space. Please monitor this section for further security considerations as the document develops. 7.1 Router Trust Assumption Router based authorization for Secured Proxy ND may occur without the knowledge or consent of a device. It is susceptible to the 'Good Router Goes Bad' attack described in [7]. Daley Expires January 10, 2005 [Page 6] Internet-Draft Securing PND Problem Statement July 2004 7.2 Certificate Transport The certification delegation relies upon transfer of the new credentials to the proxying HA in order to undertake Proxy ND on its behalf. Since the Binding cannot come into effect until DAD has taken place, the delegation of the proxying authority necessarily predates the return of the Binding Ack, as described in [4]. In the above described case, the home tunnel which comes into creation as part of the binding process may be required for DCS or DCA transport. This constitutes a potential chicken-and-egg problem. Either modifications to initial home binding semantics or certificate transport are required. This may be trivial if signed, non-repudiable certificates are sent in the clear between the MN's CoA and the HA without being tunneled. 7.3 Timekeeping Both of these methods rely on accurate timekeeping on the receiver nodes of Neighbour Discovery Timestamps. For router authorized proxy ND, a neighbour may not know that a particular ND message is replayed from the time when the proxied host was still on-link, since the message's timestamp falls within the valid timing window. Where the router advertises its secured proxy NA, a subsequent replay of the old message will override the NC entry created by the proxy. Creating the neighbour cache entry in this way, without reference to accurate subsequent timing, may only be done once. Otherwise the receiver will notice that the timestamp of the advertisement is old or doesn't match. One way of creating a sequence of replayable messages which have timestamps likely to be accepted is to pretend to do an unsecured DAD on the address each second while the MN is at home. The attacker saves each DAD defence in a sequence. The granularity of SEND timestamp matching is around 1 second, so the attacker has a set of SEND NA's to advertise, starting at a particular timestamp, and valid for as many seconds as the original NA gathering occurred. This sequence may then be played against any host which doesn't have a timestamp history for that MN, by tracking the number of seconds elapsed since the initial transmission of the replayed NA to that victim, and replaying the appropriate cached NA. Where certificate based authorization of proxy ND is in use, the origination/starting timestamp of the delegated authority may be used to override a replayed (non-proxy) SEND NA, while also ensuring that Daley Expires January 10, 2005 [Page 7] Internet-Draft Securing PND Problem Statement July 2004 the Proxy NA's timestamp (provided by the proxy) is fresh. A returning MN would advertise a more recent timestamp than the delegated authority and thus override it. This method is therefore not subject to the above attack, since the proxy advertisement's certificate will have a timestamp greater than any replayed messages, preventing it from being overridden. 8. Acknowledgments Jean-Michel Combes brought this issue to the attention of the SEND WG. Contributions to discussion on this topic helped to develop this document. Thanks go to Jari Arkko, Vijay Devarapalli, James Kempf and Mohan Parthasarathy. 9. References 9.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [3] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [5] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05 (work in progress), April 2004. [6] Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-01 (work in progress), February 2004. 9.2 Informative References [7] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. Daley Expires January 10, 2005 [Page 8] Internet-Draft Securing PND Problem Statement July 2004 Author's Address Greg Daley Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton, Victoria 3800 Australia Phone: +61 3 9905 4655 EMail: greg.daley@eng.monash.edu.au Daley Expires January 10, 2005 [Page 9] Internet-Draft Securing PND Problem Statement July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Daley Expires January 10, 2005 [Page 10]