Mobility for IPv6 (MIP6) WG Basavaraj Patil INTERNET-DRAFT Nokia Date: September 2004 Gopal Dommety Cisco Why Authentication Data suboption is needed for MIP6 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The security for signaling messages between the mobile node and home agent in Mobile IPv6 is based on the existence of an IPsec SA between the two entities. I-D: draft-ietf-mip6-auth-protocol-00.txt specifies a mechanism to secure the binding update and binding acknowledgement messages using an authentication option carried within these mes- sages. This document captures the reasons why the authentication option mechanism needs to be standardized by the Mobile IPv6 working group. Patil, Dommety [Page i] INTERNET-DRAFT Authdata option for MIP6 September 2004 Table of Contents Status of This Memo ............................................... i 1. Introduction ........ ......................................... 1 2. Background ....... ......................................... 1 3. Problem Description ......................................... 1 4. Solution .................................................... 4 5. Security Considerations .................................. 4 6. Conclusion ............................................... 4 Patil, Dommety [Page ii] INTERNET-DRAFT Authdata option for MIP6 September 2004 1. Introduction The MIP6 working group is currently debating the reasons why an alternate mechanism to IPsec (specified in RFC 3775/3776) to secure the binding update/Ack messages between the MN and HA is needed. This document outlines some of the reasons why such a mechanism is essential to ensure the wider deployment of the protocol. It should be noted that the alternate solution does not imply that the IPsec based solution would be deprecated. It simply means that in certain deployment scenarios there is a need for supporting MIP6 without an IPsec SA between the MN and HA. So the alternate solution would be in addition to the IPsec based mechanism specified in the base RFCs. 2. Background Mobile IPv6 signaling involves several messages. These include: - The binding update/Binding ACK between the mobile node and the home agent. - The route optimization signaling messages which include HoTI/Hot, CoTI/CoT and BU/BAck between the MN and CN. HoTI and HoT signaling messages are routed through the MNs HA. - Mobile prefix solicitation and advertisements between the MN and HA. - Home agent discovery by MNs. The signaling messages between the MN and HA are secured using the IPsec SA that is established between these entities. The exception to this are the messages involved in the home agent discovery pro- cess. 3. Problem Description The use of IPsec for performing Registration with a home agent is not always an optimal solution. While it is true that IPsec is an integral part of the IPv6 stack, it is still a considerable Patil, Dommety [Page 1] INTERNET-DRAFT Authdata option for MIP6 September 2004 overhead from a deployment perspective of using IPsec as the secu- rity mechanism for the signaling messages between the MN and HA. Deployment of Mobile IPv6 on a large scale is possible only when the protocol is flexible for being adapted to various scenarios. The scenario being considered is the deployment in cdma2000 net- works. cdma2000 networks are currently deployed in many countries today. The packet data network architecture of cdma2000 [REF TIA- 835 C] includes a MIP4 foreign agent/Home agent and a Radius based AAA infrastrucutre for authentication, authorization and account- ing purposes. The AAA infrastructure provides the authentication capability in the case of Mobile IPv4. Typically, the Mobile Node shares a security association with the AAA-Home entity. This is the preferred mode of operation over having a shared secret between the MN and HA because the AAA-Home entity provides a central location for provisioning and adminis- tering the shared secrets for a large number of mobiles (mil- lions). This mode of operation also makes dynamic home address and dynamic home agent assignment easier. A similar approach is needed for the deployment of Mobile IPv6 in these networks. There is no practical mechanism to use IPsec directly with the AAA infras- tructure with out the use of IKE or some other mechanism that enables the establishment of the IPsec SA between the MN and HA. Mobile IPv6 as specified in RFC3775 and RFC3776 implies a very specific model for deployment. It anticipates the Mobile nodes having a static home IPv6 address and a designated home agent. An IPsec SA is expected to be created, either via manual keying or established dynamically by using IKE. These assumptions do not necessarily fit in very well for the deployment model envisioned in cdma2000 networks. cdma2000 networks would prefer to allocate home addresses to MNs on a dynamic basis. The advantage of doing so is the fact that the HA can be assigned on a link that is close to the MNs point of attachment. While route-optimization negates the benefit of having a home-agent on a link close to the MN, it cannot be always guaranteed that the MN and CN will use or support route- optimization. There may also be instances where the operator prefers to not allow route optimization for various reasons such as accounting aggregation or enforcing service contracts. In such cases an HA that is close to the MNs point of attachment reduces the issues of latency etc. of forward and reverse tunnelling of pcakets between the MN and HA. cdma2000 networks that are operational today have large numbers of subscribers who are authenticated via the AAA infrastrucure. Patil, Dommety [Page 2] INTERNET-DRAFT Authdata option for MIP6 September 2004 Deployment of Mobile IPv6 should leverage the existing AAA infras- tructure. The security model needed in these networks is an SA between the MN and AAA-Home entity. This is the primary security association that should be used for authenticating and authorizing users to utilize MIPv6 service. This SA is then used for estab- lishing session keys between the MN and the dynamically assigned HA for authenticating Binding updates and binding acknowledgements between them. Establishing an IPsec SA between the MN and HA using AAA infrastrucure is not specified for Mobile IPv6 today. RFC3776 explains how IKE is used for establishing the SA between the MN and HA. And even in this case, the MN has a designated home address. cdma2000 network operators would prefer to assign home addresses to the MN on a dynamic basis and do this preferably using the AAA infrastrucutre which contains subscriber profile and capability information. A large subset of MNs in cdma2000 networks do not have IKE capa- bility. As a result the use of RFC3776 for setting up the MN-HA IPsec SA is not an option. It should also be noted that IKE requires several transactions before it is able to establish the IPsec SA. cdma2000 operators are extremely concious in terms of the number of messages sent and received over the air-interface for signal- ing. The overhead associated with sending/receiving a large number of signaling messages over the air interface has a direct impact on the overall capacity and cost for the operator. Optimization of the number of messages needed for using a service like Mobile IPv6 is of great concern. As a result the use of IKE for Mobile IPv6 deployment is detrimental to the operators bottom line. Another downside of IKE for setting up the IPsec SA between the MN and HA is that IKE does not integrate very well with the Radius based AAA back-end. Since operators rely on the AAA infrastrucure to provision subscribers as well as define profiles, keys etc. in the AAA-Home, there is no getting away from the use of AAA in cdma2000 networks. In summary the current model of Mobile IPv6 deployment which man- dates the existence of an IPsec SA between the MN and HA, as specified in RFCs 3775 and 3776, is too rigid and does not meet the requirements of operators building networks based on the cdma2000 [TIA-835] specifications. This is a problem that needs to be addressed in order to ensure wide-scale deployment of the pro- tocol. Patil, Dommety [Page 3] INTERNET-DRAFT Authdata option for MIP6 September 2004 4. Solution The above issues can be addressed by developing a solution that allows MIPv6 deployment that does not mandate the use of IPsec for securing the binding update and binding acknowledgment messages between the MN and HA. A solution similar to the one that is used in Mobile IPv4 today can be applied to Mobile IPv6 as well. The experience gained in deploying Mobile IPv4 in cdma2000 networks on a large scale can be reused for Mobile IPv6 also. The only con- sideration is that the alternative solution should not be vulner- able to attacks that are otherwise prevented by the use of IPsec. 5. Security Considerations The security requirements for the signaling messages between the MN and HA when using the authentication option mechanism are the same as those when using IPsec to secure them. 6. Conclusion Mobile IPv6 has been standardized only recently. Deployment of this protocol on a large scale is in the interest of the IETF and the working group as well as the many people who have worked on this. A rigid model for deployment will cause the protocol to be limited to an academic exercise only. It is extremely critical that the working group consider the needs of the industry and the deployemnt scenarios and address them accordingly. Hence the solution proposed in I-D draft-ietf- mip6-auth-protocol-00.txt should be standardized by the MIP6 WG in the IETF. 7. Acknowledgments The authors would like to thank Alpesh Patel, AC Mahendra, Kun- tal Chowdhury and Vijay Devarapalli for their input and discus- sions. Patil, Dommety [Page 4] INTERNET-DRAFT Authdata option for MIP6 September 2004 8. References 1 Mobility support in IPv6; RFC 3775 2 Using IPsec to Protest Mobile IPv6 Signaling between Mobile Nodes and Home Agents; RFC 3776 3 TIA-835-C cdma2000 Wireless IP Network Standard Patil, Dommety [Page 5] INTERNET-DRAFT Authdata option for MIP6 September 2004 9. Authors's Addresses Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 894-6709 E-mail: basavaraj.patil@nokia.com Gopal Dommety Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 USA Phone: +1 408 525-1404 E-mail: gdommety@cisco.com Patil, Dommety [Page 6] INTERNET-DRAFT Authdata option for MIP6 September 2004 Patil, Dommety [Page iii]