draft-ietf-mip6-bootstrap-ps-00.txt   draft-ietf-mip6-bootstrap-ps-01.txt 
MIP6 Alpesh. Patel, (Editor) MIP6 Alpesh. Patel, (Editor)
Internet-Draft cisco Systems Internet-Draft cisco Systems
Expires: January 7, 2005 July 9, 2004 Expires: April 13, 2005 October 13, 2004
Problem Statement for bootstrapping Mobile IPv6 Problem Statement for bootstrapping Mobile IPv6
draft-ietf-mip6-bootstrap-ps-00 draft-ietf-mip6-bootstrap-ps-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 32 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2005. This Internet-Draft will expire on April 13, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
A mobile node needs home address, home agent address and security A mobile node needs home address, home agent address and security
association with home agent to register with the home agent. The association with home agent to register with the home agent. The
process of obtaining this information is called bootstrapping. This process of obtaining this information is called bootstrapping. This
document This document defines the problem for how the mobile can be document defines the problem for how the mobile can be bootstrapped
bootstrapped in various deployment scenarios. in various deployment scenarios.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview of the Problem . . . . . . . . . . . . . . . . . 3 1.1 Overview of the Problem . . . . . . . . . . . . . . . . . 3
1.2 What is Bootstrapping? . . . . . . . . . . . . . . . . . . 4 1.2 What is Bootstrapping? . . . . . . . . . . . . . . . . . . 4
1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 2, line 37 skipping to change at page 2, line 37
7.2 Integrated ASP network scenario . . . . . . . . . . . . . 15 7.2 Integrated ASP network scenario . . . . . . . . . . . . . 15
7.3 Third party MSP scenario . . . . . . . . . . . . . . . . . 16 7.3 Third party MSP scenario . . . . . . . . . . . . . . . . . 16
7.4 Infrastructure-less scenario . . . . . . . . . . . . . . . 17 7.4 Infrastructure-less scenario . . . . . . . . . . . . . . . 17
8. Parameters for authentication . . . . . . . . . . . . . . . . 18 8. Parameters for authentication . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 24
12.2 Informative References . . . . . . . . . . . . . . . . . . . 24 12.2 Informative References . . . . . . . . . . . . . . . . . . . 24
Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . 26
1. Introduction 1. Introduction
Mobile IPv6 [2] specifies mobility support based on the assumption Mobile IPv6 [2] specifies mobility support based on the assumption
that a mobile node has a trust relationship with an entity called the that a mobile node has a trust relationship with an entity called the
home agent. Once the home agent address has been learned either via home agent. Once the home agent address has been learned either via
manual configuration or via anycast discovery mechanisms, Mobile IPv6 manual configuration or via anycast discovery mechanisms, Mobile IPv6
signaling messages between the mobile node and the home agent are signaling messages between the mobile node and the home agent are
secured with IPsec. The requirements for this security architecture secured with IPsec. The requirements for this security architecture
are created with [2] and the details of this procedure are described are created with [2] and the details of this procedure are described
in [3]. in [3].
In [2] there is an implicit requirement that the MN be provisioned In [2] there is an implicit requirement that the MN be provisioned
with enough information that will permit it to register successfully with enough information that will permit it to register successfully
with its home agent. Requirement to have this information statically with its home agent. The requirement to have this information
provisioned creates practical deployment issues. statically provisioned creates practical deployment issues.
This document serves to define the problem of bootstrapping. This document serves to define the problem of bootstrapping.
Bootstrapping is defined as obtaining enough information at the Bootstrapping is defined as obtaining enough information at the
mobile node, so that the mobile node can successfully register with mobile node, so that the mobile node can successfully register with
an appropriate home agent. an appropriate home agent.
The requirements for bootstrapping could consider various scenarios/ The requirements for bootstrapping could consider various scenarios/
network deployment issues. It is the basic assumption of this network deployment issues. It is the basic assumption of this
document that certain minimal parameters (seed information) is document that certain minimal parameters (seed information) is
available to the mobile node to aid in bootstrapping. The exact seed available to the mobile node to aid in bootstrapping. The exact seed
skipping to change at page 4, line 49 skipping to change at page 4, line 49
For a complete introduction to terminology, please refer to [4]. For a complete introduction to terminology, please refer to [4].
General mobility terminology can be found in [4]. The following General mobility terminology can be found in [4]. The following
additional terms are used here: additional terms are used here:
ASP ASP
Access Service Provider. A network operator that provides direct Access Service Provider. A network operator that provides direct
IP packet forwarding to and from the end host. IP packet forwarding to and from the end host.
IASP IASP
Integrated Internet Service Provider. A service provider Integrated Access Service Provider. A service provider providing
providing both network access and mobility. Referred to as IASP both network access and mobility. Referred to as IASP or ASP/MSP
or ASP/MSP in the document. in the document.
MSP MSP
Mobility Service Provider. A service provider that provides Mobility Service Provider. A service provider that provides
Mobile IPv6 service. Granting such service requires Mobile IPv6 service. Granting such service requires
authentication. authentication.
2. Assumptions 2. Assumptions
o A basic assumption in the Mobile IPv6 RFC [2] is that there is a o A basic assumption in the Mobile IPv6 RFC [2] is that there is a
trust relationship between the mobile node and MSP. This trust trust relationship between the mobile node and MSP. This trust
relationship can be direct, or indirect through, for instance, an relationship can be direct, or indirect through, for instance, an
ASP that has a contract with the MSP. This trust relationship can ASP that has a contract with the MSP. This trust relationship can
be used to bootstrap the MN. be used to bootstrap the MN.
One typical way of verifying the trust relationship is using One typical way of verifying the trust relationship is using
authentication, authorization, and accounting (AAA). In this authentication, authorization, and accounting (AAA). In this
document, two distinct types of AAA are considered: document, two distinct types of AAA are considered:
AAA for Network Access AAA for Network Access
This functionality provides authentication and authorization to This functionality provides authentication and authorization to
access the network (obtain address and send/receive packets). access the network (obtain an address and send/receive
packets).
AAA for Mobility Service AAA for Mobility Service
This functionality provides authentication and authorization This functionality provides authentication and authorization
for mobility services. for mobility services.
These functionalities may be implemented in a single entity or in These functionalities may be implemented in a single entity or in
different entities, depending on the service models described in different entities, depending on the service models described in
Section 6 or deployment scenarios as described in Section 7. Section 6 or deployment scenarios as described in Section 7.
o Yet another assumption is that some identifier, such as NAI, as o Yet another assumption is that some identifier, such as NAI, as
defined in [7] or [8] is provisioned on the MN which permits the defined in [7] or [8] is provisioned on the MN which permits the
MN to identify itself to the ASP and ASP. MN to identify itself to the ASP and MSP.
3. Design Goals 3. Design Goals
A solution to the bootstrapping problem has the following design A solution to the bootstrapping problem has the following design
goals: goals:
o The following information must be available at the end of o The following information must be available at the end of
bootstrapping, to enable the MN to register with the HA. bootstrapping, to enable the MN to register with the HA.
* MN's home address * MN's home address
skipping to change at page 16, line 26 skipping to change at page 16, line 26
NAS: Network Access Server NAS: Network Access Server
AAA-NA: AAA for network access AAA-NA: AAA for network access
AAA-MIP: AAA for Mobile IP service AAA-MIP: AAA for Mobile IP service
Figure 1: Integrated ASP network Figure 1: Integrated ASP network
7.3 Third party MSP scenario 7.3 Third party MSP scenario
Mobility service has traditionally been provided by the same entity Mobility service has traditionally been provided by the same entity
that authenticates and authorizes the subscriber for network access. that authenticates and authorizes the subscriber for network access.
This is certainly the only model support by the base Mobile IPv6 This is certainly the only model supported by the base Mobile IPv6
specification. specification.
In the 3rd party mobility service provider scenario, the subscription In the 3rd party mobility service provider scenario, the subscription
for mobility service is made with one entity (home MSP for instance a for mobility service is made with one entity (home MSP for instance a
corporate network), but the actual mobility service is provided by corporate network), but the actual mobility service is provided by
yet another entity (such as an operator specializing on this service, yet another entity (such as an operator specializing on this service,
the serving MSP). These two entities have a trust relationship. the serving MSP). These two entities have a trust relationship.
Transitive trust among the mobile node and these two entities may be Transitive trust among the mobile node and these two entities may be
used to assure the participants that they are dealing with, are used to assure the participants that they are dealing with, are
trustworthy peers. trustworthy peers.
skipping to change at page 18, line 44 skipping to change at page 18, line 44
be used for discovering the home agent address and the above be used for discovering the home agent address and the above
parameter may not be used. parameter may not be used.
When the home agent address is known to the mobile node, the When the home agent address is known to the mobile node, the
following parameter is needed for performing mutual authentication following parameter is needed for performing mutual authentication
between the mobile node and the home agent by using IKE: between the mobile node and the home agent by using IKE:
* IKE credentials(*) * IKE credentials(*)
In the case where the home agent does not have the entire set of In the case where the home agent does not have the entire set of
IKE credentials, the home agent may communicate with other entity IKE credentials, the home agent may communicate with another
(e.g., a AAA server) to perform mutual authentication in IKE. In entity (e.g., a AAA server) to perform mutual authentication in
such a case, the IKE credentials include the credentials used IKE. In such a case, the IKE credentials include the credentials
between the mobile node and the other entity. In the case where a used between the mobile node and the other entity. In the case
AAA protocol is used for the communication between the home agent where a AAA protocol is used for the communication between the
and the other entity during the IKE procedure, AAA for Mobile IPv6 home agent and the other entity during the IKE procedure, AAA for
service may be involved in IKE. Mobile IPv6 service may be involved in IKE.
o Parameter Set 2 o Parameter Set 2
In this case, some dependency exists between authentication for In this case, some dependency exists between authentication for
network access and authentication for mobility services in that a network access and authentication for mobility services in that a
security association that is established as a result of security association that is established as a result of
authentication for network access is re-used for authentication authentication for network access is re-used for authentication
for mobility services. for mobility services.
All required information including IKE credentials are All required information including IKE credentials are
skipping to change at page 25, line 5 skipping to change at page 24, line 48
[8] Calhoun, P. and C. Perkins, "Mobile IP Network Access [8] Calhoun, P. and C. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC 2794, March 2000. Identifier Extension for IPv4", RFC 2794, March 2000.
[9] Levkowetz, Ed., H., "Extensible Authentication Protocol (EAP)", [9] Levkowetz, Ed., H., "Extensible Authentication Protocol (EAP)",
draft-ietf-eap-rfc2284bis-09 (work in progress), February 2004. draft-ietf-eap-rfc2284bis-09 (work in progress), February 2004.
[10] Mariblanca, D., "EAP lower layer attributes for AAA protocols", [10] Mariblanca, D., "EAP lower layer attributes for AAA protocols",
draft-mariblanca-aaa-eap-lla-00.txt (work in progress), May draft-mariblanca-aaa-eap-lla-00.txt (work in progress), May
2004. 2004.
Editor's Address [11] Yegin, A., "AAA Mobile IPv6 Application Framework",
draft-yegin-mip6-aaa-fwk-00 (work in progress), August 2004.
Author's Address
Alpesh Patel Alpesh Patel
cisco Systems cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 853 9580 Phone: +1 408 853 9580
EMail: alpesh@cisco.com EMail: alpesh@cisco.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/