Network Working Group K. Chowdhury, Editor Internet-Draft Starent Networks Intended status: Standards Track A. Yegin Expires: August 11, 2007 Samsung AIT February 7, 2007 MIP6-bootstrapping for the Integrated Scenario draft-ietf-mip6-bootstrapping-integrated-02.txt Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 August 11, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 1] Internet-Draft February 2007 Abstract The Mobile IPv6 bootstrapping problem statement describes two main scenarios. In the first scenario (i.e. the split scenario), the mobile node's mobility service is authorized by a different service authorizer than the basic network access authorizer. In the second scenario (i.e. the integrated scenario), the mobile node's mobility service is authorized by the same service authorizer as the basic network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario. Table of Contents 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Logical Diagram of the Integrated Scenario . . . . . . . . 5 3.2. Bootstrapping Message Sequence, Success Case . . . . . . . 6 3.2.1. Home Agent allocation in the MSP . . . . . . . . . . . 6 3.2.2. Home Agent allocation in the ASP . . . . . . . . . . . 8 3.3. Bootstrapping Message Sequence: Fallback case . . . . . . 10 3.4. HoA and IKEv2 SA Bootstrapping in the Integrated Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 2] Internet-Draft February 2007 1. Introduction and Scope The Mobile IPv6 protocol [RFC3775] requires the mobile node to have knowledge of its Home Address, the home agent address and the cryptographic materials for establishing an IPsec security association with the home agent prior to performing home registration. The mechanism via which the mobile node obtains these information is called Mobile IPv6 bootstrapping. In order to allow a flexible deployment model for Mobile IPv6, it is desirable to define a bootstrapping mechanism for the mobile node to acquire these parameters dynamically. The [RFC4640] describes the problem statement for Mobile IPv6 bootstrapping. It also defines two bootstrapping scenarios based on the relationship between the entity that authenticates and authorizes the mobile node for network access (i.e., the Access Service Authorizer) and the entity that authenticates and authorizes the mobile node for mobility service (i.e., the Mobility Service Authorizer). The scenario in which the Access Service Authorizer is not the Mobility Service Authorizer is called the "Split" scenario. The bootstrapping solution for split scenario is defined in [BOOT-SPLIT]. The scenario in which the Access Service Authorizer is also the Mobility Service Authorizer is called the "Integrated" scenario. This document defines a bootstrapping solution for the Integrated scenario. [BOOT-SPLIT] identifies four different components of the bootstrapping problem: home agent address discovery, HoA assignment, IPsec Security Association setup and Authentication and Authorization with the MSA. This document defines a mechanism for home agent address discovery. For the rest of components, please refer to [BOOT-SPLIT]. In the integrated scenario, the bootstrapping of the home agent information can be performed via DHCPv6. DHCPv6 is designed for configuration management and it is being deployed by operators to handle their configuration management needs in their networks. Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 3] Internet-Draft February 2007 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. General mobility terminology can be found in [RFC3753]. The following additional terms, as defined in [RFC4640], are used in this document: Access Service Authorizer (ASA): A network operator that authenticates a mobile node and establishes the mobile node's authorization to receive Internet service. Access Service Provider (ASP): A network operator that provides direct IP packet forwarding to and from the mobile node. Mobility Service Authorizer (MSA): A service provider that authorizes Mobile IPv6 service. Mobility Service Provider (MSP): A service provider that provides Mobile IPv6 service. In order to obtain such service, the mobile node must be authenticated and authorized to obtain the Mobile IPv6 service. Split scenario: A scenario where the mobility service and the network access service are authorized by different entities. Integrated Scenario: A scenario where the mobility service and the network access service are authorized by the same entity. Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 4] Internet-Draft February 2007 3. Solution Overview 3.1. Logical Diagram of the Integrated Scenario In the integrated scenario the mobile node utilizes network access authentication process to bootstrap Mobile IPv6. It is assumed that the access service authorizer is mobility service aware. This allows for Mobile IPv6 bootstrapping at the time of access authentication and authorization. Also, the mechanism defined in this document requires the NAS to support Mobile IPv6 specific AAA attributes and a collocated DHCP relay agent. The following diagram shows the network elements and layout in the integrated scenario: | ASP(/MSP) | ASA/MSA(/MSP) | | +-------+ | +-------+ | | | | | |AAAV |-----------|--------|AAAH | | | | | | | | | | | +-------+ | +-------+ | | | | | | | | | | | | | | +-----+ +------+ | +----+ | | |DHCP | | | MN |------| NAS/|----|Server| | +----+ |Relay| | | | +-----+ +------+ | | | +--------+ | +--------+ | HA | | | HA | | in ASP | | |in MSP | +--------+ | +--------+ Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 5] Internet-Draft February 2007 Integrated Scenario, Network Diagram with DHCP Figure 1. Integrated Scenario, Network Diagram with DHCP Figure 1 shows the AAA infrastructure with a AAA client (NAS), a AAA proxy in the visited network and a AAA server in the home network. The user's home network authorizes the mobile node for network access and also for mobility services. Note that a home agent for usage with the mobile node might be selected in the access service provider's network or alternatively in the mobility service provider's network. The mobile node interacts with the DHCP Server via the Relay Agent after the network access authentication as part of the mobile node configuration procedure. 3.2. Bootstrapping Message Sequence, Success Case In the success case, the mobile node is able to acquire the home agent address via a DHCPv6 query. The message flows for home agent allocation in the ASP and the MSP are illustrated below. Since, in the integrated scenario, the ASA and the MSA are the same, it can be safely assumed that the AAAH used for network access authentication (ASA) has access to the same database as the AAAH used for the mobility service authentication (MSA). Hence, the same AAAH can authorize the mobile node for network access and mobility service at the same time. 3.2.1. Home Agent allocation in the MSP This section describes a scenario where the home agent is allocated in the mobile node's home MSP network. in order to provide the mobile node with information about the assigned home agent the AAAH conveys the assigned home agent's information to the NAS via AAA protocol [MIP6-RADIUS] or [MIP6-Dime]. Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 6] Internet-Draft February 2007 | --------------ASP------>|<--ASA+MSA-- | +----+ +------+ +-------+ +-----+ | | | | | | | | | MN/| |NAS/ | | DHCP | |AAAH | |User| |DHCP | | Server| | | | | |relay | | Server| | | +----+ +------+ +-------+ +-----+ | | | | | 1 | 1 | | |<------------->|<---------------------->| | | | | | | | | | 2 | | | |-------------->| | | | | | | | | 3 | | | |------------>| | | | | | | | 4 | | | |<------------| | | | | | | 5 | | | |<--------------| | | | | | | Home Agent in the MSP Figure 2. The home agent allocation in the home MSP Figure 2 shows the message sequence for home agent allocation in the home MSP. (1) The mobile node executes the network access authentication procedure (e.g., IEEE 802.11i/802.1X) and thereby interacts with the NAS. The NAS is in the ASP and it interacts with the AAAH, which is in the ASA/MSA, to authenticate the mobile node. In the process of authorizing the mobile node the AAAH verifies in the AAA profile that the mobile node is allowed to use Mobile IPv6 service. The AAAH assigns a home agent in the home MSP and returns this information to the NAS. (2) The mobile node sends a DHCPv6 Information Request message [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. In this message the mobile node (DHCP client) SHALL include the Option Code for Home Network Identifier Option [HIOPT] in the Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 7] Internet-Draft February 2007 OPTION_ORO, Home Network Identifier Option with id-type set to 1 and the Home Network Identifier field set to the network realm of the home MSP [HIOPT]. The mobile node SHALL also include the OPTION_CLIENTID to identify itself to the DHCP server. (3) The Relay Agent intercepts the Information Request from the mobile node and forwards it to the DHCP server. The Relay Agent also includes the received home agent information from the AAAH in the OPTION_MIP6-RELAY-Option [HIOPT]. (4) The DHCP server identifies the client by looking at the DUID for the client in the OPTION_CLIENTID. The DHCP server also determines that the mobile node is requesting home agent information in the MSP by looking at the Home Network Identifier Option (id-type 1). The DHCP server determines that the home agent is allocated by the AAAH by looking at the MIP6 home agent sub-option in the OPTION_MIP6- RELAY-Option. The DHCP server extracts the allocated home agent information from the OPTION_MIP6-RELAY-Option and includes it in the Home Network Information Option [HIOPT] in the Reply Message. (5) The Relay Agent relays the Reply Message from the DHCP server to the mobile node. At this point, the mobile node has the home agent information that it requested. 3.2.2. Home Agent allocation in the ASP This section describes a scenario where the mobile node requests for home agent allocation in the ASP by setting the id-type field to zero in the Home Network Identifier Option in the DHCPv6 request message. In this scenario, the ASP becomes the MSP for the duration of the network access authentication session. Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 8] Internet-Draft February 2007 | --------------ASP-------->|<--ASA+MSA-- | +----+ +-------+ +-------+ +------+ | | | | | | | | | MN/| | NAS/ | | DHCP | |AAAH | |User| | DHCP | | Server| | | | | | relay | | Server| | | +----+ +-------+ +-------+ +------+ | | | | | 1 | 1 | | |<------------->|<------------------------>| | | | | | | | | | 2 | | | |-------------->| | | | | | | | | 3 | | | |------------->| | | | | | | | 4 | | | |<-------------| | | | | | | 5 | | | |<--------------| | | | | | | Home Agent in the ASP Figure 3. The home agent allocation in the ASP Figure 3 shows the message sequence for home agent allocation in the ASP. (1) The mobile node executes the network access authentication procedure (e.g., IEEE 802.11i/802.1X) and thereby interacts with the NAS. The NAS is in the ASP and it interacts with the AAAH, which is in the ASA/MSA, to authenticate the mobile node. In the process of authorizing the mobile node the AAAH verifies in the AAA profile that the mobile node is allowed to use Mobile IPv6 services. The AAAH assigns a home agent in the home MSP and returns this information to the NAS. Note that the AAAH is not aware of the fact that the mobile node will rather request for a home agent allocation in the ASP. Therefore the assigned home agent may not be used by the mobile node. This leaves the location of the mobility anchor point decision to the mobile node. Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 9] Internet-Draft February 2007 (2) The mobile node sends a DHCPv6 Information Request message [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. In this message the mobile node (DHCP client) SHALL include the Option Code for Home Network Identifier Option [HIOPT] in the OPTION_ORO, Home Network Identifier Option with id-type set to 0. The mobile node SHALL also include the OPTION_CLIENTID to identify itself to the DHCP server. (3) The Relay Agent intercepts the Information Request from the mobile node and forwards it to the DHCP server. The Relay Agent (which is the NAS) also includes the received AAA AVP from the AAAH in the OPTION_MIP6-RELAY-Option [HIOPT]. (4) The DHCP server identifies the client by looking at the DUID for the client in the OPTION_CLIENTID. The DHCP server also determines that the mobile node is requesting home agent information in the ASP by looking at the Home Network Identifier Option (id-type 0). If configured to do so, the DHCP server allocates an home agent from its configured list of home agents and includes it in the Home Network Information Option [HIOPT] in the Reply Message. Note that in this case, the DHCP server does not use the received information in the OPTION_MIP6-RELAY-Option. (5) The Relay Agent relays the Reply Message from the DHCP server to the mobile node. At this point, the mobile node has the home agent information that it requested. 3.3. Bootstrapping Message Sequence: Fallback case In the fallback case, the mobile node is not able to acquire the home agent information via DHCPv6. The mobile node MAY perform DNS queries to discover the home agent address as defined in [BOOT-SPLIT]. To perform DNS based home agent discovery, the mobile node needs to know the DNS server address. How the mobile node knows the DNS server address is outside the scope of this document. 3.4. HoA and IKEv2 SA Bootstrapping in the Integrated Scenario In the integrated scenario, the HoA, IPsec Security Associations setup, and Authentication and Authorization with the MSA are bootstrapped via the same mechanism as described in the bootstrapping solution for split scenario [BOOT-SPLIT]. Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 10] Internet-Draft February 2007 4. Security Considerations The transport of the assigned home agent information via the AAA infrastructure (i.e., from the AAA server to the AAA client) to the NAS is subject to the standard RADIUS and Diameter security considerations. No new security considerations are imposed by the usage of this document. The security mechanisms provided by [RFC2865] and [RFC3588] are applicable and provide adequate security for this purpose. The communication between the NAS/DHCP relay agent to the DHCP server must be authenticated, integrity and replay protected. Deployments MAY either rely on lower-layer security, (i.e., physical or link layer security), or rely on security mechanisms specifically defined for DHCPv6, such as [RFC4030]. The communication between the DHCP client and the DHCP server for the exchange of home agent information is security sensitive and requires authentication, integrity and replay protection. Either lower-layer security (such as link layer security established as part of the network access authentication protocol run) or DHCP security [RFC3118] can be used. The latter approach is only applicable in non-roaming environments due to the limited applicability of the DHCP security mechanisms. An adversary that is able to modify home agent information can force the mobile node to use a different home agent than intended by the MSA. However, this type of attack can be detected by the security mechanism between the mobile node and the home agent. Overall, the home agent information carried by the AAA protocols and DHCP does not impose any new security concerns for the transport protocols. If the home agent selected by the mobile node is local or nearby, (as in section 3.2.2), disclosing the mobile node's home address (e.g., by updating the mobile node's FQDN in the DNS) has the potential to expose some information about the mobile node's location. Just by knowing the mobile node's home address, an attacker cannot determine whether the mobile node's home address belongs to a home agent that is local, nearby or remote for the mobile node and, hence, cannot determine where the mobile node is actually located. However, if additional information such as the mobile node's home agent selection policy and the home agent allocation policy of ASPs is known by an attacker, this may be different. For instance, if an attacker knows that the mobile node's home agent selection policy is to bootstrap with a new local home agent whenever entering a new network (e.g., because the mobile node wants to improve routing Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 11] Internet-Draft February 2007 efficiency in Bi-directional Tunneling mode), the attacker can track the mobile node's movement if it is aware of the mobile node's current home addresses. The accuracy of the revealed location information depends on the deployment style of home agents and the frequency of bootstrapping. Consequently, if a high level of location privacy is desired, a mobile node should not switch to local home agents in an eager manner or should not reveal its home address to untrusted nodes. Furthermore, the disclosure of policy information that can help locating the mobile node should be carefully considered. Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 12] Internet-Draft February 2007 5. IANA Considerations None Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 13] Internet-Draft February 2007 6. Acknowledgements The authors would like to thank Kilian Weniger for his valuable comment related to location privacy. Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 14] Internet-Draft February 2007 7. Contributors This contribution is a joint effort of the bootstrapping solution design team of the MIP6 WG. The contributors include Gerardo Giaretta, Basavaraj Patil, Alpesh Patel, Jari Arkko, James Kempf, Gopal Dommety, Alper Yegin, Junghoon Jee, Vijay Devarapalli, Kuntal Chowdhury, Julien Bournelle, and Hannes Tschofenig. The design team members can be reached at: Gerardo Giaretta gerardo.giaretta@tilab.com Basavaraj Patil basavaraj.patil@nokia.com Alpesh Patel alpesh@cisco.com Jari Arkko jari.arkko@kolumbus.fi James Kempf kempf@docomolabs-usa.com Gopal Dommety gdommety@cisco.com Alper Yegin alper.yegin@samsung.com Junghoon Jee jhjee@etri.re.kr Vijay Devarapalli vijayd@iprg.nokia.com Kuntal Chowdhury kchowdhury@starentnetworks.com Julien Bournelle julien.bournelle@int-evry.fr Hannes Tschofenig hannes.tschofenig@siemens.com Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 15] Internet-Draft February 2007 8. References 8.1. Normative References [HIOPT] Hee Jang et. al., A., "DHCP Option for Home Agent Discovery in MIPv6.", draft-ietf-mip6-hiopt-01.txt (work in progress), December 2006. [MIP6-Dime] Korhonen et. al., J., "Diameter Mobile IPv6: NAS - HAAA Support.", draft-ietf-dime-mip6-integrated-02.txt (work in progress), January 2007. [MIP6-RADIUS] Chowdhury et. al., K., "RADIUS Mobile IPv6 Support.", draft-ietf-mip6-radius-01.txt (work in progress), October 2006. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [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. [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 16] Internet-Draft February 2007 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 4030, March 2005. [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 8.2. Informative References [BOOT-SPLIT] Giaretta et. al., A., "Mobile IPv6 bootstrapping in split scenario.", draft-ietf-mip6-bootstrapping-split-04.txt (work in progress), December 2006. Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 17] Internet-Draft February 2007 Authors' Addresses Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 US Phone: +1 214-550-1416 Email: kchowdhury@starentnetworks.com Alper Yegin Samsung AIT Istanbul, Turkey Phone: Email: alper01.yegin@partner.samsung.com Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 18] Internet-Draft February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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 ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Chowdhury, Editor & Yegin Expires August 11, 2007 [Page 19]