Network Working Group A. Patel, Ed. Request for Comments: 4640 Cisco Category: Informational G. Giaretta, Ed. Telecom Italia September 2006 Problem Statement for Bootstrapping Mobile IPv6 (MIPv6) Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006).
AbstractA mobile node needs at least the following information: a home address, a home agent address, and a security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This document discusses issues involved with how the mobile node can be bootstrapped for Mobile IPv6 (MIPv6) and various potential deployment scenarios for mobile node bootstrapping. 1. Introduction ....................................................2 1.1. Overview of the Problem ....................................3 1.2. Bootstrapping ..............................................3 1.3. Terminology ................................................4 2. Assumptions .....................................................5 3. Design Goals ....................................................6 4. Non-goals .......................................................7 5. Motivation for bootstrapping ....................................7 5.1. Addressing .................................................7 5.1.1. Dynamic Home Address Assignment .....................7 5.1.2. Dynamic Home Agent Assignment .......................9 5.1.3. "Opportunistic" or "Local" Discovery ................9 5.1.4. Management Requirements .............................9 5.2. Security Infrastructure ...................................10 5.2.1. Integration with AAA Infrastructure ................10 5.3. Topology Change ...........................................10
5.3.1. Dormant Mode Mobile Nodes ..........................10 6. Network Access and Mobility Services ...........................11 7. Deployment Scenarios ...........................................13 7.1. Mobility Service Subscription Scenario ....................13 7.2. Integrated ASP Network Scenario ...........................14 7.3. Third-Party MSP Scenario ..................................14 7.4. Infrastructure-less Scenario ..............................15 8. Parameters for Authentication ..................................15 9. Security Considerations ........................................17 9.1. Security Requirements of Mobile IPv6 ......................17 9.2. Threats to the Bootstrapping Process ......................18 10. Contributors ..................................................19 11. Acknowledgements ..............................................20 12. Informative References ........................................20 RFC3775] specifies mobility support based on the assumption that a mobile node (MN) has a trust relationship with an entity called the home agent. Once the home agent address has been learned (for example, via manual configuration, anycast discovery mechanisms, or DNS lookup), Mobile IPv6 signaling messages between the mobile node and the home agent are secured with IPsec or with the authentication protocol, as defined in [RFC4285]. The requirements for this security architecture are created with [RFC3775], and the details of this procedure are described in [RFC3776]. In [RFC3775], there is an implicit requirement that the MN be provisioned with enough information that will permit it to register successfully with its home agent. However, having this information statically provisioned creates practical deployment issues. This document serves to define the problem of bootstrapping. Bootstrapping is defined as the process of obtaining enough information at the mobile node that it can successfully register with an appropriate home agent. The requirements for bootstrapping could consider various scenarios/network deployment issues. It is the basic assumption of this document that certain minimal parameters (seed information) are available to the mobile node to aid in bootstrapping. The exact seed information available differs depending on the deployment scenario. This document describes various deployment scenarios and provides a set of minimal parameters that are available in each deployment scenario.
This document stops short of suggesting the preferred solutions for how the mobile node should obtain information. Such details will be available from separate documents. RFC3775] expects the mobile node to have a static home address, a home agent address (which can be derived from an anycast address), and a security association with a home agent (or multiple home agents). This static provisioning of information has various problems, as discussed in Section 5. The aim of this document is: o To define bootstrapping; o To identify sample deployment scenarios where Mobile Internet Protocol version 6 (MIPv6) will be deployed, taking into account the relationship between the subscriber and the service provider; and o To identify the minimal set of information required on the Mobile Node and in the network in order for the mobile node to obtain address and security credentials, to register with the home agent.
RFC3753]. The following additional terms are used here: Trust relationship In the context of this document, trust relationship means that the two parties in question, typically the user of the mobile host and the mobility or access service authorizer, have some sort of prior contact in which the mobile node was provisioned with credentials. These credentials allow the mobile node to authenticate itself to the mobility or access service provider and to prove its authorization to obtain service. Infrastructureless relationship In the context of this document, an infrastructureless relationship is one in which the user of the mobile node and the mobility or access service provider have no previous contact and the mobile node is not required to supply credentials to authenticate and prove authorization for service. Mobility and/or network access service is provided without any authentication or authorization. Infrastructureless in this context does not mean that there is no network infrastructure, such as would be the case for an ad hoc network. Credentials Data used by a mobile node to authenticate itself to a mobility or access network service authorizer and to prove authorization to receive service. User name/passwords, one time password cards, public/private key pairs with certificates, and biometric information are some examples. ASA Access Service Authorizer. A network operator that authenticates a mobile node and establishes the mobile node's authorization to receive Internet service. ASP Access Service Provider. A network operator that provides direct IP packet forwarding to and from the end host.
Serving Network Access Provider A network operator that is the mobile node's ASP but not its ASA. The serving network access provider may or may not additionally provide mobility service. Home Network Access Provider A network operator that is both the mobile node's ASP and ASA. The home network access provider may or may not additionally provide mobility service (note that this is a slightly different definition from that in RFC 3775). IASP Integrated Access Service Provider. A service provider that provides both authorization for network access and mobility service. MSA Mobility Service Authorizer. A service provider that authorizes Mobile IPv6 service. MSP Mobility Service Provider. A service provider that provides Mobile IPv6 service. In order to obtain such service, the mobile node must be authenticated and prove authorization to obtain the service. Home Mobility Service Provider A MSP that both provides mobility service and authorizes it. Serving Mobility Service Provider A MSP that provides mobility service but depends on another service provider to authorize it. RFC3775] is that there is a trust relationship between the mobile node and its home agent(s). This trust relationship can be direct, or indirect through, for instance, an ASP that has a contract with the MSP. This trust relationship can be used to bootstrap the MN.
One typical way of verifying the trust relationship is using authentication, authorization, and accounting (AAA) infrastructure. In this document, two distinct uses of AAA are considered: AAA for Network Access This functionality provides authentication and authorization to access the network (obtain address and send/receive packets). AAA for Mobility Service This functionality provides authentication and authorization for mobility services. These functionalities may be implemented in a single entity or in different entities, depending on the service models described in Section 6 or deployment scenarios as described in Section 7. o Some identifier, such as an Network Access Identifier (NAI), as defined in [RFC4283] or [RFC2794], is provisioned on the MN that permits the MN to identify itself to the ASP and MSP.
o Subsequent protocol interaction (for example, updating the IPsec SA) can be executed between the MN and the HA itself without involving the infrastructure that was used during bootstrapping. o Solutions to the bootstrapping problem should enable storage of user-specific information on entities other than the home agent. o Solutions to the bootstrapping problem should not exclude storage of user-specific information on entities other than the home agent. o Configuration information which is exchanged between the mobile node and the home agent must be secured using integrity and replay protection. Confidentiality protection should be provided if necessary. o The solution should be applicable to all feasible deployment scenarios that can be envisaged, along with the relevant authentication/authorization models. RFC3775] has a tight binding to the home addresses and home agent addresses. In this section, we discuss the problems caused by the currently tight binding to home addresses and home agent addresses.
security policy database, which specifies that a certain security association may only be used for a specific home address. When dynamic keying is used, the home agent ensures that the IKE Phase 1 identity is authorized to request security associations for the given home address. Mobile IPv6 uses IKEv1, which is unable to update the security policy database according to a dynamically assigned home address. As a result, static home address assignment is really the only home address configuration technique compatible with the base specification. However, support for dynamic home address assignment would be desirable for the following reasons: Dynamic Host Configuration Protocol (DHCP)-based address assignment. Some providers may want to use DHCPv6 or other dynamic address assignment (e.g., IKEv2) from the home network to configure home addresses. Recovery from a duplicate address collision. It may be necessary to recover from a collision of addresses on the home network by one of the mobile nodes changing its home address. Addressing privacy. It may be desirable to establish randomly generated addresses as in [RFC3041] and use them for a short period of time. Unfortunately, current protocols make it possible to use such addresses only from the visited network. As a result, these addresses cannot be used for communications lasting longer than the attachment to a particular visited network. Ease of deployment. In order to simplify the deployment of Mobile IPv6, it is desirable to free users and administrators from the task of allocating home addresses and specifying them in the security policy database. This is consistent with the general IPv6 design goal of using autoconfiguration wherever possible. Prefix changes in the home network. The Mobile IPv6 specification contains support for a mobile node to autoconfigure a home address as based on its discovery of prefix information on the home subnet [RFC3775]. Autoconfiguration in case of network renumbering is done by replacing the existing network prefix with the new network prefix. Subsequently, the MN needs to update the mobility binding in the HA to register the newly configured Home Address. However, the MN may not be able to register the newly configured address with the HA if a security association related to that reconfigured Home Address does not exist in the MN and the HA. This situation is not handled in the current MIPv6 specification [RFC3775].
RFC3775]. Independent network management. An MSP may want to assign home agents dynamically in different subnets; for instance, not require that a roaming mobile node have a fixed home subnet. Local home agents. The mobile node's MSP may want to allow the serving MSP to assign a local home agent for the mobile node. This is useful from the point of view of communications efficiency and has also been mentioned as one approach to support location privacy. Ease of deployment. In order to simplify the deployment of Mobile IPv6, it is desirable to free users and administrators from the task of allocating home agent addresses in a static manner. Moreover, an MSP may want to have a dynamic home agent assignment mechanism to load balance users among home agents located on different links.
mobile nodes, but it cannot be expected that mobile node users are capable of performing the required tasks. RFC3776], has no integration with backend authentication, authorization, and accounting techniques unless the authentication credentials and trust relationships use certificates or pre-shared secrets. Certificates are not easily supported by traditional AAA infrastructures. Where a traditional AAA infrastructure is used, the home agent is not able to leverage authentication and authorization information established between the mobile node, the foreign AAA server, and the home AAA server. This would be desirable when the mobile node gains access to the foreign network, in order to authenticate the mobile node's identity and determine whether the mobile node is authorized for mobility service. The lack of connection to the AAA infrastructure also means that the home agent does not know where to send accounting records at appropriate times during the mobile node's session, as determined by the business relationship between the MSP and the mobile node's owner. Presumably, some backend AAA protocol between the home agent and home AAA could be utilized, but IKEv1 does not contain support for exchanging full AAA credentials with the mobile node. It is worthwhile to note that IKEv2 provides this feature. Section 10.6 of [RFC3775] has an implicit assumption that the mobile node is active and taking IP traffic. In fact, many, if not most, mobile devices will be in a low power "dormant mode" to save battery power, or will even be switched off, so they will miss any propagation of prefix information. As a practical matter, if this protocol is used, an MSP will need to keep the old prefix around and handle any queries to the old home agent anycast address on the old subnet, whereby the mobile node asks for a new home agent as described in Section 11.4, until all mobile nodes are accounted for. Even then, since some mobile nodes are likely to be turned off for
long periods, some owners would need to be contacted by other means, reducing the utility of the protocol. Bootstrapping does not explicitly try to solve this problem of home network renumbering when MN is in dormant mode. If the MN can configure itself after it 'comes back on' by reinitiating the bootstrapping process, then network renumbering problem is fixed as a side effect. Section 7. The focus is on the 'service' model since, ultimately, it is the provider providing the service that wants to authenticate the mobile (and vice versa for mutual authentication between provider and the user of the service). Network access service enables a host to send and receive IP packets on the Internet or an intranet. IP address configuration and IP packet forwarding capabilities are required to deliver this service. A network operator providing this service is called an access service provider (ASP). An ASP can, for example, be a commercial ASP, the IT department of an enterprise network, or the maintainer of a home (residential) network. If the mobile node is not directly usable for communication at the current location of the MN in which network access service is provided by its home ASP, the mobile node is roaming. In this case, the home ASP acts as the access service authorizer, but the actual network access is provided by the serving network access provider. During the authentication and authorization prior to the mobile nodes having Internet access, the serving network access provider may simply act as a routing agent for authentication and authorization back to the access service authorizer, or it may require an additional authentication and authorization step itself. An example of a roaming situation is when a business person is using a hotspot service in an airport and the hotspot service provider has a roaming agreement with the business person's cellular provider. In that case, the hotspot network is acting as the serving network access provider, and the cellular network is acting as the access service authorizer. When the business person moves from the hotspot network to the cellular network, the cellular network is both the home access service provider and the access service authorizer. Mobility service using Mobile IPv6 is conceptually and possibly also in practice separate from network access service, though of course network access is required prior to providing mobility. Mobile IPv6
service enables an IPv6 host to maintain its reachability despite changing its network attachment point (subnets). A network operator providing Mobile IPv6 service is called a mobility service provider (MSP). Granting Mobile IPv6 service requires that a host authenticate and prove authorization for the service. A network operator that authenticates a mobile node and authorizes mobility service is called a mobility service authorizer (MSA). If both types of operation are performed by the same operator, that operator is called a home mobility service provider. If authentication and authorization is provided by one operator and the actual service is provided by another, the operator providing the service is called the serving mobility service provider. The serving MSP must contact the mobile node's mobility service authorizer to check the mobile node's authorization prior to granting mobility service. The service model defined here clearly separates the entity providing the service from the entity that authenticates and authorizes the service. In the case of basic network access, this supports the traditional and well-known roaming model, in which inter-operator roaming agreements allow a host to obtain network access in areas where their home network access provider does not have coverage. In the case of mobility service, this allows a roaming mobile node to obtain mobility service in the local operator's network while having that service authorized by the home operator. The service model also allows mobility service and network access service to be provided by different entities. This allows a network operator with no wireless access, such as, for example, an enterprise network operator, to deploy a Mobile IPv6 home agent for mobility service while the actual wireless network access is provided by the serving network access providers with which the enterprise operator has a contract. Here are some other possible combinations of ASPs and MSPs: o The serving ASP might be the home ASP. Similarly, the serving MSP might be the home MSP. o The home ASP and the home MSP may be the same operator, or not. When they are the same, the same set of credentials may be used for both services. o The serving ASP and the serving MSP may be the same operator, or not. o It is possible that serving ASP and home MSP are the same operator. Similarly the home ASP and serving MSP may be the same. Also, the ASA and MSA may be the same.
These entities and all combinations that are reasonable from a deployment perspective must be taken into consideration to solve the Mobile IPv6 bootstrapping problem. They impact home agent discovery, home address configuration, and mobile node-to-home agent authentication aspects. Section 6 are considered. For each scenario, the underlying assumptions are described. The basic assumption is that there is a trust relationship between mobile user and the MSA. Typically, this trust relationship is between the mobile user and AAA in the MSA's network. Seed information needed to bootstrap the mobile node is considered in two cases: o AAA authentication is mandatory for network access. o AAA authentication is not part of network access. The seed information is described further in Section 8. Section 6, the MSP is responsible for setting up a home agent on a subnet that acts as a Mobile IPv6 home link. As a consequence, the home MSP should explicitly authorize and control the whole bootstrapping procedure. Since the MN is assumed to have a pre-established trust relationship with its home provider, it must be configured with an identity and credentials; for instance, an NAI and a shared secret by some out- of-band means (i.e., manual configuration) before bootstrapping. In order to guarantee ubiquitous service, the MN should be able to bootstrap MIPv6 operations with its home MSP from any possible access location, such as an open network or a network managed by an ASP, that may be different from the MSP and that may not have any pre- established trust relationship with it.
Figure 1 describes an AAA design example for integrated ASP scenario. +----------------------------+ | IASP(ASA+MSA) | +----+ +-----+ +----+ | | MN |--- | NAS | | HA | | +----+ +-----+ +----+ | | \ \ | | \ +------+ \ +-------+ | | -|AAA-NA| -|AAA-MIP| | | +------+ +-------+ | +----------------------------+ NAS: Network Access Server AAA-NA: AAA for network access AAA-MIP: AAA for Mobile IP service Figure 1. Integrated ASP network
Figure 2 describes an example of a network for the third-party MSP scenario. +--------------+ +--------+ | | |Serving | | ASP | | MSP | +----+ +-----+ | | +----+ | | MN |--- | NAS | | | | HA | | +-------------------+ +----+ +-----+ |===| +----+ | | MSA | | \ | | \ || (e.g., corporate NW)| | \ +------+ | | \ | +-------+ | | -|AAA-NA| | | -------|AAA-MIP| | | +------+ | | | | +-------+ | +------------ + +--------+ +-------------------+ Figure 2. Third-Party MSP network Section 9.
o Parameter Set 1 In this case, authentication for network access is independent of authentication for mobility services. If the home agent address is not known to the mobile node, the following parameter is needed for discovering the home agent address: * The domain name or Fully Qualified Domain Name (FQDN) of the home agent This parameter may be derived in various ways, such as (but not limited to) static configuration, use of the domain name from the network access NAI (even if AAA for network access is not otherwise used), or use of the domain name of the serving ASP, where the domain name may be obtained via DHCP in the serving ASP. If the home agent address is not known but the home subnet prefix is known, Dynamic Home Agent Address Discovery of Mobile IPv6 may be used for discovering the home agent address, and the above parameter may not be used. When the home agent address is known to the mobile node, the following parameter is needed for performing mutual authentication between the mobile node and the home agent by using IKE: * IKE credentials (*) In the case where the home agent does not have the entire set of IKE credentials, the home agent may communicate with another entity (for example, an AAA server) to perform mutual authentication in IKE. In such a case, the IKE credentials include the credentials used between the mobile node and the other entity. In the case where an AAA protocol is used for the communication between the home agent and the other entity during the IKE procedure, AAA for Mobile IPv6 service may be involved in IKE. If the authentication protocol [RFC4285] is used, the shared key-based security association with the home agent is needed. o Parameter Set 2 In this case, some dependency exists between authentication for network access and authentication for mobility services in that a security association that is established as a result of authentication for network access is re-used for authentication for mobility services.
All required information, including IKE credentials, is bootstrapped from the following parameter: * Network access credentials(*) (*) A pair of an NAI and a pre-shared secret is an example of a set of credentials. A pair of an NAI and a public key, which may be provided as a digital certificate, is another example of a set of credentials. RFC 3775 and other RFCs used by Mobile IPv6 for security. 2. The security of the bootstrapping process itself, in the sense of threats to the bootstrapping process imposed by active or passive attackers. Note that the two are related; if the bootstrapping process is compromised, the level of security required by RFC 3775 may not be achieved. The following two sections discuss these issues. RFC 3775 requires the establishment of a collection of IPsec SAs between the home agent and mobile node to secure the signaling traffic for Mobile IP, and, optionally, also to secure data traffic. The security of an IPsec SA required by the relevant IPsec RFCs must be quite strong. Provisioning of keys and other cryptographic material during the establishment of the SA through bootstrapping must be done in a manner such that authenticity is proved and confidentiality is ensured. In addition, the generation of any keying material or other cryptographic material for the SA must be done in a way such that the probability of compromise after the SA is in place is minimized. The best way to minimize the probability of such a compromise is to have the cryptographic material only known or calculable by the two end nodes that share the SA -- in this case, the home agent and mobile node. If other parties are involved in establishing the SA (through key distribution, for example) the process should follow the constraints designed to provide equivalent security.
RFC 3775 also requires a trust relationship, as defined in Section 1.3, between the mobile node and its home agent(s). This is necessary, for instance, to ensure that fraudulent mobile nodes that attempt to flood other mobile nodes with traffic be not only shut off but tracked down. An infrastructureless relationship as defined in Section 1.3 does not satisfy this requirement. Any bootstrapping solution must include a trust relationship between mobile node and mobility service provider. Solutions that depend on an infrastructureless relationship are out of scope for bootstrapping. Another requirement is that a home address be authorized to one specific host at a time. RFC 3775 requires this so that misbehaving mobile nodes can be shut down. This implies that, in addition to the IPsec SA, the home agent must somehow authorize the mobile node for a home address. The authorization can be either implicit (for example, as a side effect of the authentication for mobility service) or explicit. The authorization can either be done at the time the SA is created or be dynamically managed through a first come, first served allocation policy. RFC 3775 requirements for Mobile IP security are not met, or they can serve simply to disrupt the process such that bootstrapping cannot be completed. Here are some possible attacks: o An attacking network entity purporting to offer the mobile node a legitimate home agent address or bootstrapping for the IPsec SAs may instead offer a bogus home agent address or configure bogus SAs that allow the home agent to steal the mobile node's traffic or otherwise disrupt the mobile node's mobility service. o An attacking mobile node may attempt to steal mobility service by offering up fake credentials to a bootstrapping network entity or otherwise disrupting the home agent's ability to offer mobility service. o A man in the middle on the link between the mobile node and the bootstrapping network entity could steal credentials or other sensitive information and use that to steal mobility service or deny it to the legitimate owner of the credentials. Refer to Section 7.15 in [RFC3748] and [AAA-EAP-LLA] for further information.
o An attacker could arrange for a distributed denial-of-service attack on the bootstrapping entity, to disrupt legitimate users from bootstrapping. In addition to these attacks, there are other considerations that are important in achieving a good security design. As mobility and network access authentication are separate services, keys generated for these services need to be cryptographically separate, to be separately named, and to have separate lifetimes. This needs to be achieved even though the keys are generated from the same authentication credentials. This is necessary because a mobile node must be able to move from one serving (or roaming) network access provider to another without needing to change its mobility access provider. Finally, basic cryptographic processes must provide for multiple algorithms in order to accommodate the widely varying deployment needs; the need for replacement of algorithms when attacks become possible must also be considered in the design.
Gopal Dommety: email@example.com Kent Leung: firstname.lastname@example.org Alper Yegin: email@example.com Hannes Tschofenig: firstname.lastname@example.org Vijay Devarapalli: email@example.com Kuntal Chowdhury: firstname.lastname@example.org [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [AAA-EAP-LLA] Mariblanca, D., "EAP lower layer attributes for AAA protocols", Work in Progress, May 2004. [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000. [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3776] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 3777, June 2004. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
Full Copyright Statement Copyright (C) The Internet Society (2006). 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. 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. Intellectual Property 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 email@example.com. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).