Network Working Group K. Chowdhury, Editor
Internet-Draft Starent Networks
Intended status: Standards Track A. Yegin
Expires: October 21, 2007 Samsung AIT
April 19, 2007
MIP6-bootstrapping for the Integrated Scenario
draft-ietf-mip6-bootstrapping-integrated-03.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 October 21, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Chowdhury, Editor & Yegin Expires October 21, 2007 [Page 1]
Internet-Draft April 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. List of Assumptions . . . . . . . . . . . . . . . . . . . . . 5
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Logical Diagram of the Integrated Scenario . . . . . . . . 6
4.2. Bootstrapping Message Sequence, Success Case . . . . . . . 7
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 . . . . . . 11
4.4. HoA and IKEv2 SA Bootstrapping in the Integrated
Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Chowdhury, Editor & Yegin Expires October 21, 2007 [Page 2]
Internet-Draft April 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. This
document defines the mip6 bootstrapping procedures for the integrated
scenario. This draft enables Home Agent assignment in the integrated
scenario by utilizing DHCP and AAA protocols. The specification
utilizes DHCP and AAA options and AVPs that are defined in [HIOPT],
[MIP6-Dime], and [MIP6-RADIUS]. This document specifies the
interworking among MN, NAS, DHCP, and AAA entities for bootstrapping
procedure in the integrated scenario.
Chowdhury, Editor & Yegin Expires October 21, 2007 [Page 3]
Internet-Draft April 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. A MSP is called home MSP when MSP == MSA. In
this document the term MSP means a Mobility Service Provider that has
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.
Chowdhury, Editor & Yegin Expires October 21, 2007 [Page 4]
Internet-Draft April 2007
3. List of Assumptions
The following assumptions are made in this document:
a. MSA == ASA.
b. MSA and MSP roaming relationship is assumed but not required.
c. DHCP relay and NAS are collocated or there is a way to pass
received AAA information from the NAS to the DHCP relay.
d. the NAS shall support MIPv6 specific AAA attributes as specified
in [MIP6-RADIUS] and [MIP6-Dime].
e. MSP == MSA scenario is termed as home MSP.
Chowdhury, Editor & Yegin Expires October 21, 2007 [Page 5]
Internet-Draft April 2007
4. Solution Overview
4.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 October 21, 2007 [Page 6]
Internet-Draft April 2007
Integrated Scenario, Network Diagram with DHCP Server
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.
4.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. When the MN performs Mobile IPv6 registration (IKEv2
exchanges), the AAAH ensures that the MN is accessing the assigned
Home Agent for that MSP.
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). 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 October 21, 2007 [Page 7]
Internet-Draft April 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 MSP
Figure 2 shows the message sequence for home agent allocation in the
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 home agent in the home MSP and 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.
Chowdhury, Editor & Yegin Expires October 21, 2007 [Page 8]
Internet-Draft April 2007
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 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]. 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 DHCP request, the NAS/DHCP
relay does not include the OPTION_MIP6-RELAY-Option in the Relay
Forward message.
(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. If the
requested information is not available in the DHCP server, it follows
the behavior described in [HIOPT].
(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 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 October 21, 2007 [Page 9]
Internet-Draft April 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 October 21, 2007 [Page 10]
Internet-Draft April 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.
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
[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.
4.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 October 21, 2007 [Page 11]
Internet-Draft April 2007
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 RADIUS and
Diameter security mechanisms. No additional security considerations
are imposed by the usage of this document. The security mechanisms
provided by [RFC2865] and [RFC3588] are applicable for this purpose.
Chowdhury, Editor & Yegin Expires October 21, 2007 [Page 12]
Internet-Draft April 2007
6. IANA Considerations
None
Chowdhury, Editor & Yegin Expires October 21, 2007 [Page 13]
Internet-Draft April 2007
7. Acknowledgements
The authors would like to thank Kilian Weniger, Vidya Narayanan, and
George Tsirtsis for their review and comments.
Chowdhury, Editor & Yegin Expires October 21, 2007 [Page 14]
Internet-Draft April 2007
8. 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 October 21, 2007 [Page 15]
Internet-Draft April 2007
9. Normative 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.
[HIOPT] Hee Jang et. al., A., "DHCP Option for Home Agent
Discovery in MIPv6.", draft-ietf-mip6-hiopt-02.txt (work
in progress), February 2007.
[MIP6-Dime]
Korhonen et. al., J., "Diameter Mobile IPv6: NAS - HAAA
Support.", draft-ietf-dime-mip6-integrated-03.txt (work in
progress), February 2007.
[MIP6-RADIUS]
Chowdhury et. al., K., "RADIUS Mobile IPv6 Support.",
draft-ietf-mip6-radius-02.txt (work in progress),
March 2007.
[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,
Chowdhury, Editor & Yegin Expires October 21, 2007 [Page 16]
Internet-Draft April 2007
"Diameter Network Access Server Application", RFC 4005,
August 2005.
[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.
Chowdhury, Editor & Yegin Expires October 21, 2007 [Page 17]
Internet-Draft April 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 October 21, 2007 [Page 18]
Internet-Draft April 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 October 21, 2007 [Page 19]
