diff options
Diffstat (limited to 'doc/rfc/rfc6611.txt')
| -rw-r--r-- | doc/rfc/rfc6611.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc6611.txt b/doc/rfc/rfc6611.txt new file mode 100644 index 0000000..59eb8b1 --- /dev/null +++ b/doc/rfc/rfc6611.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) K. Chowdhury, Ed. +Request for Comments: 6611 Radio Mobile Access, Inc. +Category: Standards Track A. Yegin +ISSN: 2070-1721 Samsung + May 2012 + + + Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario + +Abstract + + Mobile IPv6 bootstrapping can be categorized into two primary + scenarios: the split scenario and the integrated scenario. In the + split scenario, the mobile node's mobility service is authorized by a + different service authorizer than the network access authorizer. In + the integrated scenario, the mobile node's mobility service is + authorized by the same service authorizer as the network access + service authorizer. This document defines a method for home agent + information discovery for the integrated scenario. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6611. + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +Chowdhury & Yegin Standards Track [Page 1] + +RFC 6611 MIPv6 Bootstrapping Integrated Scenario May 2012 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction and Scope ..........................................2 + 2. Terminology .....................................................3 + 3. Assumptions and Conformance .....................................4 + 4. Solution Overview ...............................................5 + 4.1. Logical View of the Integrated Scenario ....................5 + 4.2. Bootstrapping Message Sequence .............................6 + 4.2.1. Home Agent Allocation in the MSP ....................7 + 4.2.2. Home Agent Allocation in the ASP ....................9 + 4.3. Bootstrapping Message Sequence: Fallback Case .............10 + 4.4. HoA and IKEv2 SA Bootstrapping in the Integrated + Scenario ..................................................10 + 5. Security Considerations ........................................10 + 6. Acknowledgements ...............................................11 + 7. Contributors ...................................................11 + 8. References .....................................................11 + 8.1. Normative References ......................................11 + 8.2. Informative References ....................................12 + +1. Introduction and Scope + + The Mobile IPv6 protocol [RFC6275] requires the mobile node to have + the following information: + + o the Home Address (HoA), + + o the home agent address, and + + o the cryptographic materials for establishing an IPsec security + association with the home agent. + + + + + + + + +Chowdhury & Yegin Standards Track [Page 2] + +RFC 6611 MIPv6 Bootstrapping Integrated Scenario May 2012 + + + The cryptographic materials need to be established prior to + initiating the registration process. The mechanism via which the + mobile node obtains this 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. [RFC4640] + describes the problem statement for Mobile IPv6 bootstrapping. It + also defines the 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, ASA) and the + entity that authenticates and authorizes the mobile node for mobility + service (i.e., the Mobility Service Authorizer, MSA). The scenario + in which the Access Service Authorizer is not the Mobility Service + Authorizer is called the "split" scenario. The bootstrapping + solution for the split scenario is defined in [RFC5026]. 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. + + [RFC5026] identifies four different components of the bootstrapping + problem: home agent address discovery, HoA assignment, IPsec Security + Association [RFC4301] setup, and Authentication and Authorization + with the MSA. This document defines a mechanism for home agent + address discovery. The other components of bootstrapping are as per + [RFC5026]. + + In the integrated scenario, the bootstrapping of the home agent + information can be achieved via DHCPv6. This document defines the + MIPv6 bootstrapping procedures for the integrated scenario. It + enables home agent assignment in the integrated scenario by utilizing + DHCP and Authentication, Authorization, and Accounting (AAA) + protocols. The specification utilizes DHCP and AAA options and + attribute-value pairs (AVPs) that are defined in [RFC6610] and + [RFC5447]. This document specifies the interworking among Mobile + Node (MN), Network Access Server (NAS), DHCP, and AAA entities for + the bootstrapping procedure in the integrated scenario. + +2. Terminology + + The key words "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]. + + + + + + + + +Chowdhury & Yegin Standards Track [Page 3] + +RFC 6611 MIPv6 Bootstrapping Integrated Scenario May 2012 + + + 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. An MSP is called a "home MSP" when MSP == MSA. + In this document, the term MSP means a Mobility Service Provider that + has a roaming relationship with the MSA but it is not the MSA. + + 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. + +3. Assumptions and Conformance + + The following assumptions are made in this document: + + (a) MSA == ASA. + + (b) MSA and MSP have a roaming relationship. + + (c) DHCP relay and NAS are either co-located or there is a mechanism + to transfer received AAA information from the NAS to the DHCP + relay. + + Note: If assignment of a home agent in the home MSP is not + required by a deployment, co-location of the NAS and the DHCP + relay functions or a mechanism to transfer received AAA + information from the NAS to the DHCP relay won't be + necessary. In such a case, only the implementation of the + options and procedures defined in [RFC6610] should suffice. + + (d) The NAS shall support MIPv6-specific AAA attributes as specified + in [RFC5447]. + + + + + +Chowdhury & Yegin Standards Track [Page 4] + +RFC 6611 MIPv6 Bootstrapping Integrated Scenario May 2012 + + + (e) The AAA server in the home domain (AAAH) used for network access + authentication (ASA) has access to the same database as the AAAH + used for the mobility service authentication (MSA). + + If home agent assignment is required only in the ASP by the + deployment, a minimal implementation of this specification MAY only + support the delivery of information from the DHCP server to the DHCP + client through [RFC6610]. However, if home agent assignment in the + MSP is required by the deployment, an implementation conforming to + this specification SHALL be able to transfer the information received + from the AAA server to the NAS, and from the NAS to the DHCP relay + function. This can be achieved either by co-locating the NAS and the + DHCP relay functions or via an interface between these functions. + The details of this interface are out of the scope of this + specification. + +4. Solution Overview + +4.1. Logical View of the Integrated Scenario + + In the integrated scenario, the mobile node utilizes the 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 MIP6-specific AAA + attributes and a co-located DHCP relay agent. + + Figure 1 shows the AAA infrastructure with a AAA client (NAS), a AAA + proxy in the visited network (AAAV), and a AAA server in the home + network (AAAH). + + + + + + + + + + + + + + + + + + + + +Chowdhury & Yegin Standards Track [Page 5] + +RFC 6611 MIPv6 Bootstrapping Integrated Scenario May 2012 + + + | + ASP(/MSP) | ASA/MSA(/MSP) + | + | + +-------+ | +-------+ + | | | | | + |AAAV |-----------|--------|AAAH | + | | | | | + +-------+ | +-------+ + | | + | | + | | + | | + +-----+ +------+ | + +----+ | NAS/| |DHCP | | + | MN |------|DHCP |----|Server| | + +----+ |Relay| | | | + +-----+ +------+ | + | + | + +--------+ | +--------+ + | HA | | | HA | + | in ASP | | |in MSP | + +--------+ | +--------+ + + Figure 1: Integrated Scenario, Network Diagram with DHCP Server + + The user's home network authorizes the mobile node for network access + and mobility services. Note that usage of a home agent with the + mobile node might be selected in the access service provider's + network or alternatively in the mobility service provider's network. + + The MSP may be co-located with the ASP, or the ASA/MSA, or + independent of the two. + + 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. + +4.2. Bootstrapping Message Sequence + + In this case, the mobile node is able to acquire the home agent + address via a DHCPv6 query. 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 + + + + +Chowdhury & Yegin Standards Track [Page 6] + +RFC 6611 MIPv6 Bootstrapping Integrated Scenario May 2012 + + + and mobility service at the same time. When the MN performs Mobile + IPv6 registration, the AAAH ensures that the MN is accessing the + assigned home agent for that MSP. + + Figure 2 shows the message sequence for home agent allocation in both + scenarios -- HA in the ASP (which is co-located with the MSP), or HA + in an MSP that is separate from ASP and possibly from the ASA/MSA as + well. + + | + --------------ASP------>|<--ASA+MSA-- + | + +----+ +------+ +-------+ +-----+ + | | | | | | | | + | MN/| |NAS/ | | DHCP | |AAAH | + |User| |DHCP | | Server| | | + | | |relay | | | | | + +----+ +------+ +-------+ +-----+ + | | | | + | 1 | 1 | | + |<------------->|<---------------------->| + | | | | + | | | | + | 2 | | | + |-------------->| | | + | | | | + | | 3 | | + | |------------>| | + | | | | + | | 4 | | + | |<------------| | + | | | | + | 5 | | | + |<--------------| | | + | | | | + + Figure 2: Message Sequence for Home Agent Allocation + +4.2.1. Home Agent Allocation in the MSP + + This section describes a scenario where the home agent is allocated + in the mobile node's MSP network(s) that is (are) not co-located with + the ASP. 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 a AAA protocol, e.g., [RFC5447]. + + Figure 2 shows the message sequence for home agent allocation. In + the scenario with HA in the MSP, the following details apply. + + + +Chowdhury & Yegin Standards Track [Page 7] + +RFC 6611 MIPv6 Bootstrapping Integrated Scenario May 2012 + + + (1) The mobile node executes the network access authentication + procedure (e.g., IEEE 802.11i/802.1X), and it 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 the + Mobile IPv6 service. The AAAH assigns a home agent in the home + MSP, and it assigns one or more home agents in other authorized + MSPs and returns this information to the NAS. The NAS may keep + the received information for a configurable duration, or it may + keep the information for as long as the MN is connected 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 following: + + * the Option Code for the Visited Home Network Information + option [RFC6610] in the OPTION_ORO. + + * Client Home Network ID FQDN option identifying the MSP. + + * 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 Relay-Supplied Options option [RFC6610]. If a NAS + implementation does not store the received information as long + as the MN's session remains in the ASP, and if the MN delays + sending a DHCP request, the NAS/DHCP relay does not include the + Relay-Supplied Options option in the Relay Forward message. + + (4) The DHCP server: + + * identifies the client by looking at the DHCP Unique + Identifier (DUID) for the client in the OPTION_CLIENTID. + + * determines that the mobile node is requesting home agent + information in the MSP by looking at the Home Network ID FQDN + option. + + * determines that the home agent is allocated by the AAAH by + looking at the Relay-Supplied Options option. + + + + + + +Chowdhury & Yegin Standards Track [Page 8] + +RFC 6611 MIPv6 Bootstrapping Integrated Scenario May 2012 + + + * extracts the allocated home agent information from the Relay- + Supplied Options option and includes it in the Identified + Home Network Information option [RFC6610] in the Reply + Message. If the requested information is not available in + the DHCP server, it follows the behavior described in + [RFC6610]. + + (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. + +4.2.2. Home Agent Allocation in the ASP + + This section describes a scenario where the mobile node requests home + agent allocation in the ASP by setting the id-type field to zero in + the Home Network Identifier Option [RFC6610] in the DHCPv6 request + message. In this scenario, the ASP becomes the MSP for the duration + of the network access authentication session. + + Figure 2 shows the message sequence for home agent allocation. In + the scenario with HA in the ASP, the following details apply. + + (1) The mobile node executes the network access authentication + procedure (e.g., IEEE 802.11i/802.1X) and 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 the + Mobile IPv6 services. The AAAH assigns a home agent in the home + MSP, and it assigns one or more home agents in other authorized + MSPs and returns this information to the NAS. Note that the + AAAH is not aware of the fact that the mobile node prefers 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. + + (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 following: + + * the Option Code for the Home Network Identifier Option + [RFC6610] in the OPTION_ORO. + + * the OPTION_CLIENTID to identify itself to the DHCP server. + + + + + +Chowdhury & Yegin Standards Track [Page 9] + +RFC 6611 MIPv6 Bootstrapping Integrated Scenario May 2012 + + + (3) The relay agent (which is the NAS) intercepts the Information + Request from the mobile node and forwards it to the DHCP server. + The relay agent also includes the received AAA AVP from the AAAH + in the Relay-Supplied Options option [RFC6610]. + + (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 Visited Home Network + Information option. If configured to do so, the DHCP server + allocates a home agent from its configured list of home agents + and includes it in the Visited Home Network Information Option + [RFC6610] in the Reply Message. Note that in this case, the + DHCP server does not use the received information in the Relay- + Supplied Options 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. + +4.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 [RFC5026]. + To perform DNS-based home agent discovery, the mobile node needs to + know the DNS server address. The details of how the MN is configured + with the DNS server address are outside the scope of this document. + +4.4. HoA and IKEv2 SA Bootstrapping in the Integrated Scenario + + In the integrated scenario, the HoA, IPsec Security Association + setup, and Authentication and Authorization with the MSA are + bootstrapped via the same mechanism as described in the bootstrapping + solution for the split scenario [RFC5026]. + +5. 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 may only be integrity protected as per standard Diameter or other + AAA protocol security mechanisms. No additional security + considerations are imposed by the usage of this document. The + security mechanisms provided by [RFC3588] are applicable for this + purpose. This document does not introduce any new security issues to + Mobile IPv6. + + + + + +Chowdhury & Yegin Standards Track [Page 10] + +RFC 6611 MIPv6 Bootstrapping Integrated Scenario May 2012 + + +6. Acknowledgements + + The authors would like to thank Kilian Weniger, Vidya Narayanan, and + George Tsirtsis for their review and comments. Thanks to Alfred + Hoenes for thorough review and valuable suggestions to improve the + readability of the document. + +7. Contributors + + This contribution is a joint effort of the bootstrapping solution + design team of the MEXT WG. The contributors include Jari Arkko, + Julien Bournelle, Kuntal Chowdhury, Vijay Devarapalli, Gopal Dommety, + Gerardo Giaretta, Junghoon Jee, James Kempf, Alpesh Patel, Basavaraj + Patil, Hannes Tschofenig, and Alper Yegin. + + The design team members can be reached at the following email + addresses: + + Jari Arkko jari.arkko@kolumbus.fi + Julien Bournelle julien.bournelle@orange-ftgroup.com + Kuntal Chowdhury kc@radiomobiles.com + Vijay Devarapalli Vijay.Devarapalli@AzaireNet.com + Gopal Dommety dommety@yahoo.com + Gerardo Giaretta gerardog@qualcomm.com + Junghoon Jee jhjee@etri.re.kr + James Kempf kempf@docomolabs-usa.com + Alpesh Patel alpesh@cisco.com + Basavaraj Patil basavaraj.patil@nsn.com + Hannes Tschofenig hannes.tschofenig@nsn.com + Alper Yegin alper.yegin@yegin.org + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [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. + + + + + + + +Chowdhury & Yegin Standards Track [Page 11] + +RFC 6611 MIPv6 Bootstrapping Integrated Scenario May 2012 + + + [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 + Bootstrapping in Split Scenario", RFC 5026, October 2007. + + [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., + and K. Chowdhury, "Diameter Mobile IPv6: Support for + Network Access Server to Diameter Server Interaction", + RFC 5447, February 2009. + + [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support + in IPv6", RFC 6275, July 2011. + + [RFC6610] Jang, H., Yegin, A., Chowdhury, K., Choi, J., and T. + Lemon, "DHCP Option for Home Agent Discovery in Mobile + IPv6 (MIPv6)", RFC 6610, May 2012. + +8.2. Informative References + + [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", + RFC 3753, June 2004. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for + bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, + September 2006. + +Authors' Addresses + + Kuntal Chowdhury (editor) + Radio Mobile Access, Inc. + 100 Ames Pond Dr. + Tewksbury MA 01876 + + EMail: kc@radiomobiles.com + + + Alper Yegin + Samsung + Istanbul + Turkey + + EMail: alper.yegin@yegin.org + + + + + + + + +Chowdhury & Yegin Standards Track [Page 12] + |