MIP6 J. Kempf Internet-Draft DoCoMo Labs USA Expires: June 3, 2005 E. Nordmark SUN Microsystems S. Chakrabarti Sun December 3, 2004 Bootstrapping Mobile IPv6 draft-chakrabarti-mip6-bmip-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she 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 June 3, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document defines an easy mechanism of boot-strapping Mobile IPv6 service. The boot-strapping mechanism includes locating a home agent, dynamic home-address allocation and setting up initial security association with the home-agent using IKE version 2 and EAP. Kempf, et al. Expires June 3, 2005 [Page 1] Internet-Draft BMIP December 2004 This solution provides a way of secure and easy deployment without the involvement of AAA servers for the boot-strapping purpose. It is particularly useful in scenarios where AAA infrastructure is not available, although this mechanism can be applicable in general. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Deployment Examples . . . . . . . . . . . . . . . . . . . . . 5 2.1 Universal Access Method . . . . . . . . . . . . . . . . . 5 2.2 Enterprise/University Campus Network . . . . . . . . . . . 6 2.3 Network Access Provider Service Only . . . . . . . . . . . 6 3. Protocol Descriptions . . . . . . . . . . . . . . . . . . . . 7 3.1 Obtaining Home Agent Address . . . . . . . . . . . . . . . 7 3.2 Setting up Security Association . . . . . . . . . . . . . 7 3.3 Dynamic Home Address Assignment . . . . . . . . . . . . . 8 3.4 Renewal of Bootstrapping Materials . . . . . . . . . . . . 8 4. Home Agent Requirements . . . . . . . . . . . . . . . . . . . 10 5. Mobile Node Requirements . . . . . . . . . . . . . . . . . . . 11 6. EAP Considerations . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 A. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 10.2 Informative References . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Kempf, et al. Expires June 3, 2005 [Page 2] Internet-Draft BMIP December 2004 1. Introduction Mobile IPv6 [3] describes mobility protocol between a Mobile Node and a Home Agent. This document describes a simple method to initiate the Mobile IPv6 service by the Mobile Node, without requiring home network topology-dependent information, such as the home agent address, on the Mobile Node. The initiation or boot-strapping of Mobile IPv6 [3] can happen any time depending on the policy applied on the Mobile Node. It is possible that the boot-strapping method starts every time a Mobile Node boots or wakes up from standby status; alternately, it can be started when the user turns on "Mobility Service". Mobile IPv6 Bootstrapping problem statement [9] indicates that the mobile node must know its Home Agent address, its own Home Address and materials to obtain MN-HA [4] security association in order to start the Mobility service in a deployment scenario. Mobile IPv6 [3][4] protocols do not describe a method to obtain such initial information; it assumes that a Mobile Node is already configured with a home-address from its Home Agent and MN-HA security association is configured at MN and HA. However, in real deployment, this assumption requires manual configuration which does not scale as the Mobile Nodes increase in number. This document, in the following sections describes a solution for bootstrapping method that only involves Domain Naming Service (DNS) and a Home Agent running IKE version 2 [6]. Hence it does not require any other additional infrastructure such as AAA (Authentication, Authorization and Accounting Protocol) and operates separately from whatever scheme is used for authenticating the network access for the mobile node. The solution refers to other existing protocols and documents whenever possible. The document assumes that the mobile node has already acquired IP service at its location, which might have been authenticated any number of ways: o IEEE 802.1X o PANA o Universal Access Methods [13] or web-based credit card number verification for authenticated and authorized network access. o Other local schemes based on manually handling out L2 (WEP) keys, registering MAC addresses, or controlling physical access a (wired) network. Thus it does not necessarily assume that the L2/EAP authentication is used for network access authentication. Privacy considerations are discussed in the Appendix. Kempf, et al. Expires June 3, 2005 [Page 3] Internet-Draft BMIP December 2004 The keywords MUST, MUST NOT, SHOULD, SHOULD NOT, MAY and RECOMMENDED are defined in [1]. Kempf, et al. Expires June 3, 2005 [Page 4] Internet-Draft BMIP December 2004 2. Deployment Examples This section describes a few examples of where AAA bootstrapping might not be available. 2.1 Universal Access Method Universal Access Method [13] is a technology for basic network access authentication and authorization that is widely used in 802.11 hotspot networks throughout the world. In a UAM network, the host is allowed to perform DHCP to obtain an IP address and other parameters necessary for network access, but routing to the Internet is inhibited until the host completes a login process. The login process requires the host's user to attempt to browse a Web page, using a Web browser. Any other IP traffic is dropped. The HTTP GET issued by the Web browser is redirected, and a login page is displayed instead. On the login page, the user typically has a choice to either provide a login/password, for an account on file with the service provider, or a credit card number, for one-time only access. If a login/password is provided, the back end conducts a typical Radius AAA transaction back to the home network AAA server. If a credit card number is provided, a secure E-commerce protocol is used to contact the user's credit card provider, and the charges are billed to the user's credit card. Acceptance of the charge by the credit card provider constitutes authorization for the user to get IP service. Once the user has been authenticated and authorized for IP service, routing to the Internet is established and the original Web page browsed by the user is displayed. The only protocol involved in the transaction is HTTP. In this deployment scenario, there is no hook for providing the Mobile Node with Mobile IPv6 bootstrapping parameters, because there is no L2 AAA transaction conducted between the Mobile Node and the network. For account-based access, Radius is used on the back end, between the network access server (called a Public Access Control (PAC) Gateway in the UAM architecture) and the home network of the user, but there is no path from the PAC Gateway to the Mobile Node for delivering the bootstrap parameters. For one-time access, there is no AAA involved at all. The protocol discussed in this document would be an appropriate solution to bootstrapping in this scenario, because it could be run after the PAC Gateway has opened Internet routing access. Kempf, et al. Expires June 3, 2005 [Page 5] Internet-Draft BMIP December 2004 2.2 Enterprise/University Campus Network Many university and enterprise networks authenticate hosts attempting to use their network by checking whether the MAC address corresponds to a MAC address in a database of allowed terminals. Some such deployments additionally require a login/password from the user for an account, using the same kind of HTTP Redirect procedure used by UAM. In order for a user to access the network, the MAC address of the laptop must be provided to system administrators and an account established. In such deployment scenarios, there is also no L2 AAA transaction between the Mobile Node and the network that can serve to provide configuration parameters. The protocol described in this document can be deployed by the campus or enterprise system administrator to bootstrap Mobile IPv6 service. 2.3 Network Access Provider Service Only The Mobile IPv6 Bootstrapping problem statement [9] describes a case where an Internet service provider only provides network access and does not provide mobility service. In this case, the initial L2 AAA transaction cannot provide the Mobile Node with bootstrapping parameters, because the access network provider doesn't provide Mobile IPv6 service. In this case, the Mobile Node could use the protocol discussed in this document to obtain service from another provider, perhaps one discovered opportunistically or perhaps one with which the user has a long term account. Kempf, et al. Expires June 3, 2005 [Page 6] Internet-Draft BMIP December 2004 3. Protocol Descriptions Mobile IPv6 Bootstrapping [9] problem statement describes network access service and Mobile IPv6 service. This document does not define protocols for network access and assumes that network access and authorization have taken place before the Mobile Node bootstraps for mobility service. Thus, the following steps are required to perform this solution, they are: o Find appropriate Home Agent FQDN from DNS SRV record o Use IKEv2, possibly with EAP method to obtain IKE security association. (And this would allow an evolution towards certificate-based authentication in the future without changing any protocols.) o Use IKEv2 to obtain the Home-address dynamically if its not available to the Mobile Node already and then obtain MN-HA security association 3.1 Obtaining Home Agent Address A Mobile Node queries the DNS server to request information on Home Agent service. RFC 2782[2] describes the policies to choose a service agent based on the preference and weight values. The DNS SRV record may contain the preference and weight values for multiple Home Agents available to the Mobile Node in addition to the Home Agent FQDNs. If multiple Home Agents are available in the DNS SRV record then Mobile Node is responsible to process the information as per policy and pick one Home Agent. If the Home Agent of choice does not respond for some reason or the IKE authentication fails, the Mobile Node SHOULD try other Home Agents on the list. The Home Agent information MUST be stored in the Mobile Node as long as it is using the mobility service or on the same access network in order to expedite the bootstrapping process for obtaining security association and home address. The service name for Mobile IPv6 home agent service as required by RFC 2782 is "mip6" and the protocol name is "ipv6". Note that a transport name cannot be used here because Mobile IPv6 does not run over a transport. Example: A mobile node with the example.net home domain would perform a SRV query for _mip6._ipv6.example.net. 3.2 Setting up Security Association IKEv2 [6] describes IKE authentication by using EAP methods. IKE version 2 allows a client to use an EAP method for authentication Kempf, et al. Expires June 3, 2005 [Page 7] Internet-Draft BMIP December 2004 while the responder uses certificates or pre-shared keys for the server authentication. Thus the Mobile Node must have some information about the Home Agent's certificate authority in order to verify the certificate. Such information MUST be preconfigured on the Mobile Node, if the Mobile Node has a long term relationship with the mobility service provider. If that is not the case, the Home Agent's certificate certificate authority (CA) or root CA information SHOULD be obtained from the Home Agent's network through the DNS SRV record. Each Home Agent's information is bound to its root CA or certificate authority. While certificates are not commonly used on hosts today, certificate-based authentication - in which no EAP transaction is involved - can also be accommodated by the protocol. For purposes of tying the Mobile Node's IKEv2 identity to its EAP identity, the users Network Access Identifier [8] SHOULD be used to establish the IKEv2 security association. This corresponds to an IKEv2 identity type of 3 (ID_RFC822_ADDR). For more details in setting up the parameters for IKE authentication phase and consequent IKE child-SA phase refer to [5]. 3.3 Dynamic Home Address Assignment A Mobile Node may obtain its home address dynamically from the Home Agent when it reboots or when its security association with the Home Agent expires. If Home Agent knows its home address or the last used home address for the corresponding Home Agent, it SHOULD include that home address in the assignment request. If Mobile Node is using SEND [10], it SHOULD supply a host id suffix for a CGA (Cryptographically generated address). The details of home address assignment using IKEv2 is described in [5]. A Mobile Node SHOULD store the home address locally for efficient renewal of security association with its Home Agent. 3.4 Renewal of Bootstrapping Materials A Mobile Node SHOULD store the home address and the Home Agent information locally as long as it is in the same network or using the same Mobile IPv6 service. A Mobile Node MUST have its unique identity (for example, NAI) which is bound with home address and MN-HA IKEv2/IPsec security associations. This unique identity must be stored both at Mobile Node and at the Home Agent. This identity is used by the Home Agent to verify that it is talking to the same node which perhaps expired the SA (security Association) recently. This is useful for additional proof of authentication. Binding to unique identity is also useful when a mobile node uses multiple home addresses. Kempf, et al. Expires June 3, 2005 [Page 8] Internet-Draft BMIP December 2004 A Mobile Node SHOULD renew its IKE/IPsec security associations before they expire. It is recommended that the default IKE security association is at least same as IPsec SA and home-address lifetime. The default IKE SA lifetime SHOULD be large (say IKE_BMIP_SA_LIFETIME_MAX). Thus the Mobile Node does not need to go through the whole bootstrapping process to renew home Address and IKE SA if it stays on the same access network for a long period of time. Dynamic home address lifetime SHOULD be at least long enough to match IKE/IPsec SA lifetimes in order to prevent unnecessary boot-strapping messaging exchange. Upon reboot, a Mobile Node may or may not lose its home address, Home Agent address and IKE/IPsec security associations depending on the Mobile Node configuration options. By default, a Mobile Node must start bootstrapping process upon reboot. If the access method involves user interaction, such as UAM, the user may be presented with a Web page after initial network access offering the FQDNs of one or several mobility service provider links. These links, when selected, may directly or indirectly cause the bootstrapping procedure described here to run. Reasons for re-bootstrapping after the initial one are subject to individual service provider policy, but some possible reasons for re-bootstrapping are the following: o Load balancing o Home Agents being taken off line for maintenance o Unanticipated HA failure Note that RFC 3775 [3] currently defines no way for a HA to inform its active Mobile Nodes that it is about to go down and that it should find a new HA or recommending a new HA, like the ICMP Redirect message used by a first hop router. By the existing Mobile IPv6 standard, an MN will only discover that its HA is unavailable when either tunneled packets stop arriving, if traffic is not route optimized, or when it tries to perform a binding update to the HA and the HA does not respond. It is possible that IKEv2 could provide some indication that the IPsec SA is being deactivated, but such an indication would not provide enough information to determine whether the MN should re-bootstrap and find a new HA, since the SA may be deactivated for other reasons. Kempf, et al. Expires June 3, 2005 [Page 9] Internet-Draft BMIP December 2004 4. Home Agent Requirements Home Agent MUST support [5]. A Home Agent MAY operate along with a AAA home-server. But the communication between Home Agent and the AAA home-server is independent of the boot-strapping process in this solution. Kempf, et al. Expires June 3, 2005 [Page 10] Internet-Draft BMIP December 2004 5. Mobile Node Requirements o A Mobile Node is aware of its Home Domain name or Home ISP domain name o A Mobile Node MUST support [5]. o A Mobile Node must have configuration policies to control bootstrapping frequencies o A Mobile Node must be capable of storing home address and Home Agent address and IKE MN-HA [5] security associations o A Mobile Node MUST be configured with a Network Access Identifier or other identity sufficient to obtain mobility service. Kempf, et al. Expires June 3, 2005 [Page 11] Internet-Draft BMIP December 2004 6. EAP Considerations IKE version 2 [6] specifies that when using EAP authentication of the initiator the responder must have a certificate. There is a draft [11] discusses how EAP methods that provide mutual authentication and key agreement can be used for responder authentication instead of certificates. If this proposal is standardized as an extension of EAP usage in IKEV2, then boot-strapping process does not need to use or process certificates. However, for wide scale deployments, responder authentication using certificates may be more practical. Kempf, et al. Expires June 3, 2005 [Page 12] Internet-Draft BMIP December 2004 7. Security Considerations The protocol uses IKEv2/IPsec and EAP methods for secure exchange of initial security material exchange and security association. It also talks about an unique Mobile Node identity to bind with the offered home addresses and the IPsec/IKE security associations. Kempf, et al. Expires June 3, 2005 [Page 13] Internet-Draft BMIP December 2004 8. Protocol Constants IKE_BMIP_SA_LIFETIME_MAX 1 day Kempf, et al. Expires June 3, 2005 [Page 14] Internet-Draft BMIP December 2004 9. Acknowledgments None so far. Kempf, et al. Expires June 3, 2005 [Page 15] Internet-Draft BMIP December 2004 Appendix A. Privacy Considerations Bootstrapping process can be leveraged to assign a temporary address [7] to the Mobile Node in addition to the home address. The Home Agent SHOULD tie these temporary addresses with the same MN-HA tunnel that is used for home address of the Mobile Node. Thus the Mobile Node and Home Agent should share the same security associations as with Home address. The unique identity binding is also useful in this case. Purpose of having temporary home-address assignment is that the Mobile Node may use them for some applications as it does in non- mobile cases for privacy reasons. Publishing Home Agent addresses publicly in DNS servers may lead to unwarranted attention from undesirable elements seeking to disrupt mobility service through DoS attack. While IKEv2 has been carefully engineered to prevent subtle DoS attacks, such as state depletion, a brute force DDoS attack can still be mounted. The threat from DDoS in this case is no larger than for any other widely known public Internet server, such as a popular Web site or, indeed, a DNS server for a top level domain. Measures similar to those used by popular Web site providers or DNS server operators can be deployed to mitigate such attacks. Note that measures which "hide" Home Agent addresses by only sending them to authorized nodes through AAA transactions are not exempt from DDoS attack, because worm-style probing - in which the attacker sequentially iterates through all addresses on a subnet - can be used to determine whether a particular address corresponds to a deployed Home Agent. In IPv6, such probing attacks are expected to be less effective due to the enormously enlarged address space, but with enough zombie nodes under their control, an attacker could still tie up a network. Kempf, et al. Expires June 3, 2005 [Page 16] Internet-Draft BMIP December 2004 10. References 10.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [3] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [4] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [5] Devarapalli, V., "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture", draft-ietf-mip6-ikev2-ipsec-00 (work in progress), October 2004. [6] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. 10.2 Informative References [7] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [9] Kempf, J. and J. Arkko, "The Mobile IPv6 Bootstrapping Problem", draft-kempf-mip6-bootstrap-00 (work in progress), March 2004. [10] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 (work in progress), July 2004. [11] Eronen, P., "Extension for EAP Authentication in IKEv2", draft-eronen-ipsec-ikev2-eap-auth-02 (work in progress), October 2004. [12] Giaretta, G., "MIPv6 Authorization and Configuration based on EAP", draft-giaretta-mip6-authorization-eap-02 (work in progress), October 2004. Kempf, et al. Expires June 3, 2005 [Page 17] Internet-Draft BMIP December 2004 [13] Anton, B., Bullock, B. and J. Short, "Best Current Practices for Wireless Service Provider (WISP) Roaming", Feb. 2003, . Authors' Addresses James Kempf DoCoMo Labs USA 181 Metro Drive Suite 300 San Jose, CA, 95110 USA Phone: +1 408 451 4711 EMail: kempf@docomolabs-usa.com Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park, CA 95025 USA Phone: +1 650 786 2921 EMail: erik.nordmark@sun.com Samita Chakrabarti Sun Microsystems Inc. 16 Network Circle Menlo Park, CA 95024 USA Phone: +1 650 786 5068 EMail: samita.chakrabarti@sun.com Kempf, et al. Expires June 3, 2005 [Page 18] Internet-Draft BMIP December 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. Kempf, et al. Expires June 3, 2005 [Page 19]