draft-ietf-mip6-bootstrap-ps-01.txt   draft-ietf-mip6-bootstrap-ps-02.txt 
MIP6 Alpesh. Patel, (Editor) MIP6 A. Patel, Editor
Internet-Draft cisco Systems Internet-Draft Cisco
Expires: April 13, 2005 October 13, 2004 Expires: September 16, 2005 March 18, 2005
Problem Statement for bootstrapping Mobile IPv6 Problem Statement for bootstrapping Mobile IPv6
draft-ietf-mip6-bootstrap-ps-01 draft-ietf-mip6-bootstrap-ps-02.txt
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 33 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 April 13, 2005. This Internet-Draft will expire on September 16, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
A mobile node needs home address, home agent address and security A mobile node needs at least the following information: a home
association with home agent to register with the home agent. The address, home agent address and a security association with home
process of obtaining this information is called bootstrapping. This agent to register with the home agent. The process of obtaining this
document defines the problem for how the mobile can be bootstrapped information is called bootstrapping. This document discuss the
in various deployment scenarios. issues involved with how the mobile node can be bootstrapped for
Mobile IPv6 and various potential deployment scenarios for
bootstrapping the mobile node.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Motivation for bootstrapping . . . . . . . . . . . . . . . . . 9 5. Motivation for bootstrapping . . . . . . . . . . . . . . . . . 10
5.1 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1 Dynamic Home Address Assignment . . . . . . . . . . . 9 5.1.1 Dynamic Home Address Assignment . . . . . . . . . . . 10
5.1.2 Dynamic Home Agent Assignment . . . . . . . . . . . . 10 5.1.2 Dynamic Home Agent Assignment . . . . . . . . . . . . 11
5.1.3 Management requirements . . . . . . . . . . . . . . . 11 5.1.3 Management requirements . . . . . . . . . . . . . . . 12
5.2 Security Infrastructure . . . . . . . . . . . . . . . . . 11 5.2 Security Infrastructure . . . . . . . . . . . . . . . . . 12
5.2.1 Integration with AAA Infrastructure . . . . . . . . . 11 5.2.1 Integration with AAA Infrastructure . . . . . . . . . 12
5.2.2 Opportunistic or Local Discovery . . . . . . . . . . . 12 5.2.2 "Opportunistic" or "Local" Discovery . . . . . . . . . 13
5.3 Topology Change . . . . . . . . . . . . . . . . . . . . . 12 5.3 Topology Change . . . . . . . . . . . . . . . . . . . . . 13
5.3.1 Dormant Mode Mobile Nodes . . . . . . . . . . . . . . 12 5.3.1 Dormant Mode Mobile Nodes . . . . . . . . . . . . . . 13
6. Network Access and Mobility services . . . . . . . . . . . . . 13 6. Network Access and Mobility services . . . . . . . . . . . . . 14
7. Deployment scenarios . . . . . . . . . . . . . . . . . . . . . 15 7. Deployment scenarios . . . . . . . . . . . . . . . . . . . . . 16
7.1 Mobility Service Subscription Scenario . . . . . . . . . . 15 7.1 Mobility Service Subscription Scenario . . . . . . . . . . 16
7.2 Integrated ASP network scenario . . . . . . . . . . . . . 15 7.2 Integrated ASP network scenario . . . . . . . . . . . . . 16
7.3 Third party MSP scenario . . . . . . . . . . . . . . . . . 16 7.3 Third party MSP scenario . . . . . . . . . . . . . . . . . 17
7.4 Infrastructure-less scenario . . . . . . . . . . . . . . . 17 7.4 Infrastructure-less scenario . . . . . . . . . . . . . . . 18
8. Parameters for authentication . . . . . . . . . . . . . . . . 18 8. Parameters for authentication . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1 Security Requirements of Mobile IPv6 . . . . . . . . . . . 21
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 9.2 Threats to the Bootstrapping Process . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 24
12.2 Informative References . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 25 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . 26 12.2 Informative References . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . 27
1. Introduction 1. Introduction
Mobile IPv6 [2] specifies mobility support based on the assumption Mobile IPv6 [RFC3775] specifies mobility support based on the
that a mobile node has a trust relationship with an entity called the assumption that a mobile node has a trust relationship with an entity
home agent. Once the home agent address has been learned either via called the home agent. Once the home agent address has been learned
manual configuration or via anycast discovery mechanisms, Mobile IPv6 for example via manual configuration, via anycast discovery
signaling messages between the mobile node and the home agent are mechanisms, via DNS lookup; Mobile IPv6 signaling messages between
secured with IPsec. The requirements for this security architecture the mobile node and the home agent are secured with IPsec or
are created with [2] and the details of this procedure are described authentication protocol [I-D.ietf-mip6-mn-auth-protocol-02]. The
in [3]. requirements for this security architecture are created with
[RFC3775] and the details of this procedure are described in
[RFC3776].
In [2] there is an implicit requirement that the MN be provisioned In [RFC3775] there is an implicit requirement that the MN be
with enough information that will permit it to register successfully provisioned with enough information that will permit it to register
with its home agent. The requirement to have this information successfully with its home agent. However, having this information
statically 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 the process of the mobile node obtaining
mobile node, so that the mobile node can successfully register with enough information, so that it can successfully register with an
an appropriate home agent. 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
information available differs depending on the deployment scenario. information available differs depending on the deployment scenario.
This document defines/describes various deployment scenarios and This document defines/describes various deployment scenarios and
provides for a set of minimal parameters that are available in each provides for a set of minimal parameters that are available in each
deployment scenario. deployment scenario.
This document stops short of suggesting the various solutions to This document stops short of suggesting the various solutions to
obtaining information on the mobile node. Such details will be obtaining information on the mobile node. Such details will be
available from separate documents. available from separate documents.
1.1 Overview of the Problem 1.1 Overview of the Problem
Mobile IPv6 [2] expects the mobile node to have a static home Mobile IPv6 [RFC3775] expects the mobile node to have a static home
address, home agent address (or anycast address and do dynamic home address, home agent address (or anycast address and do dynamic home
agent discovery of Home Agent using ICMP messages) and a security agent discovery of Home Agent using ICMP messages) and a security
association with a home agent (multiple home agents on the home association with a home agent (multiple home agents on the home
network if dynamic home agent discovery is in use and multiple home network if dynamic home agent discovery is in use and multiple home
agents are deployed.) agents are deployed.)
This static provisioning of information has various problems as This static provisioning of information has various problems as
discussed in Section 5. discussed in Section 5.
The aim of this draft is to: The aim of this draft is to:
o Define bootstrapping. o Define bootstrapping.
o Identify sample deployment scenarios where MIPv6 will be deployed, o Identify sample deployment scenarios where MIPv6 will be deployed,
taking into account the relationship between the subscriber and taking into account the relationship between the subscriber and
the service provider. the service provider.
o Identify the minimal set of information required on the Mobile o Identify the minimal set of information required on the Mobile
Node (and/or) in the network in order for the the mobile node to Node (and/or) in the network in order for the mobile node to
obtain address and security credentials, to register with the home obtain address and security credentials, to register with the home
agent. agent.
1.2 What is Bootstrapping? 1.2 What is 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. Specifically, this means obtaining the an appropriate home agent. Specifically, this means obtaining the
home agent address, home address and security credentials for the home agent address, home address and security credentials for the
mobile node and home agent to authenticate and mutually construct mobile node and home agent to authenticate and mutually construct
security credentials for Mobile IPv6 without requiring security credentials for Mobile IPv6 without requiring
preconfiguration. preconfiguration.
Typically, bootstrapping happens when a mobile node does not have all Typically, bootstrapping happens when a mobile node does not have all
the information it needs to setup Mobile IPv6 service. This the information it needs to setup the Mobile IPv6 service. This
includes, but is not limited to MN not having any information when it includes, but is not limited to MN not having any information when it
boots up for the first time (out of the box), it does not retain any boots up for the first time (out of the box), it does not retain any
information during reboots, is instructed by the Home Agent (via some information during reboots, is instructed by the Home Agent (via some
form of signalling) to do so etc. form of signalling) to do so etc.
Also, in certain scenarios, after the MN bootstraps for the first Also, in certain scenarios, after the MN bootstraps for the first
time (out of the box), subsequent bootstrapping is implementation time (out of the box), subsequent bootstrapping is implementation
dependent. For instance, MN may bootstrap everytime it boots, dependent. For instance, the MN may bootstrap everytime it boots,
bootstrap everytime on prefix change, bootstrap periodically to bootstrap everytime on prefix change, bootstrap periodically to
anchor to an optimal (distance, load etc) HA, etc. anchor to an optimal (distance, load etc) HA, etc.
1.3 Terminology 1.3 Terminology
For a complete introduction to terminology, please refer to [4]. General mobility terminology can be found in
[I-D.ietf-seamoby-mobility]. The following additional terms are used
here:
General mobility terminology can be found in [4]. The following Trust relationship
additional terms are used here: In the context of this draft, trust relationship means that two
parties in question, typically the user of the mobile host and the
mobility or access service provider, have some sort of prior
contact in which the mobile host was provisioned with credentials.
These credentials allow the mobile host to authenticate itself to
the mobility or access service authorizer and to prove its
authorization to obtain service.
Infrastructureless relationship
In the context of this draft, an infrastructureless relationship
is one in which the user of the mobile host and the mobility or
access service provider have no previous contact and the mobile
host 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 or mechanism used by a mobile host to authenticate itself to
a mobility or access network service provider and prove
authorization to receive service. User name/passwords, one time
password cards, public/private key pairs with certificates,
biometric information, etc. are some examples.
ASA
Access Service Authorizer. A network operator that authenticates
a mobile host and establishes the mobile host's authorization to
receive Internet service.
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.
Serving Network Access Provider
A network operator that is the mobile host's ASP but not its ASA.
The serving network accesss provider may or may not additionally
provide mobility service.
Home Network Access Provider
A network operator that is both the mobile host's ASP and ASA.
The home network access provider may or may not additionally
provide mobility service (note that this is a slighlty different
definition from RFC 3775).
IASP IASP
Integrated Access Service Provider. A service provider providing Integrated Access Service Provider. A service provider that
both network access and mobility. Referred to as IASP or ASP/MSP provides both authorization for network access and also provides
in the document. mobility service.
MSA
Mobility Service Authorizer. A service provider that authorizes
Mobile IPv6 service.
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. In order to obtain such service, the mobile
authentication. host 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.
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 [RFC3775] is that there
trust relationship between the mobile node and MSP. This trust is a trust relationship between the mobile node and MSP. This
relationship can be direct, or indirect through, for instance, an trust relationship can be direct, or indirect through, for
ASP that has a contract with the MSP. This trust relationship can instance, an ASP that has a contract with the MSP. This trust
be used to bootstrap the MN. relationship can 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).
document, two distinct types of AAA are considered: infrastructure. In this document, two distinct uses 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 an address and send/receive access the network (obtain address and send/receive packets).
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 [I-D.ietf-mip6-mn-ident-option-02] or [RFC2794] is
MN to identify itself to the ASP and MSP. provisioned on the MN which permits the MN to identify itself to
the ASP and ASP.
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 agent address * MN's home agent address
* IPsec SA between MN and HA or IKE pre-shared secret between MN * MN's home address
and HA. * IPsec SA between MN and HA, IKE pre-shared secret between MN
o The bootstrapping procedure can be triggered at any time. and HA or shared secret/security association for authentication
protocol [I-D.ietf-mip6-mn-auth-protocol-02]
o The bootstrapping procedure can be triggered at any time, either
by the MN or by the network. Bootstrapping can occur, for
instance due to administrative action, information going stale, HA
indicating the MN etc. Bootstrapping may be initiated even when
the MN is registered with the HA and has all the required
credentials. This may typically happen to refresh/renew the
credentials.
o Subsequent protocol interaction (for example updating the IPsec o Subsequent protocol interaction (for example updating the IPsec
SA) can be executed between the MN and the HA itself without SA) can be executed between the MN and the HA itself without
involving the infrastructure that was used during bootstrapping. 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 o Solutions to the bootstrapping problem should not exclude storage
of user-specific information on entities other than the home of user-specific information on entities other than the home
agent. agent.
o Configuration information which is exchanged between the mobile o Configuration information which is exchanged between the mobile
node and the home agent must be secured using integrity and replay node and the home agent needs to be secured using integrity and
protection. Confidentiality protection SHOULD be provided if replay protection. Confidentiality protection should be provided
necessary. if necessary.
o All feasible deployment scenarios, along with the relevant o All feasible deployment scenarios, along with the relevant
authentication/authorization models must be considered. authentication/authorization models should be considered.
4. Non-Goals 4. Non-Goals
This following issues are clearly outside the scope of bootstrapping: This following issues are clearly outside the scope of bootstrapping:
o Home prefix renumbering is not explicity supported as part of o Home prefix renumbering is not explicity supported as part of
bootstrapping. If the MN executes the bootstrap procedures bootstrapping. If the MN executes the bootstrap procedures
everytime it powers-on (as opposed to caching state information everytime it powers-on (as opposed to caching state information
from previous bootstrap process), then home network renumbering is from previous bootstrap process), then home network renumbering is
taken care of automatically. taken care of automatically.
o Bootstrapping in the absence of a trust relationship between MN o Bootstrapping in the absence of a trust relationship between MN
and any provider, is not considered. The reason for this is and any provider is not considered.
described in Section 9.
5. Motivation for bootstrapping 5. Motivation for bootstrapping
5.1 Addressing 5.1 Addressing
The default bootstrapping described in the Mobile IPv6 base The default bootstrapping described in the Mobile IPv6 base
specification [2] has a tight binding to the home addresses and home specification [RFC3775] has a tight binding to the home addresses and
agent addresses. home agent addresses.
In this section, we discuss the problems caused by the currently In this section, we discuss the problems caused by the currently
tight binding to home addresses and home agent addresses. tight binding to home addresses and home agent addresses.
5.1.1 Dynamic Home Address Assignment 5.1.1 Dynamic Home Address Assignment
While it is possible for the home address to be dynamically assigned, Currently, the home agent uses the mobile node's home address for
the HA cannot verify that the MN is authorized to use a particular authorization. When manual keying is used, this happens through the
security policy database, which specifies that a certain security
association may only use 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 based on a dynamically assigned home
address. As a result, static home address assignment is really the address. As a result, static home address assignment is really the
only home address configuration technique compatible with the current only home address configuration technique compatible with the current
specification. specification.
However, support for dynamic home address assignment would be However, support for dynamic home address assignment would be
desirable for the following reasons: desirable for the following reasons:
DHCP-based address assignment DHCP-based address assignment
Some ASPs may want to use DHCPv6 from the home network to Some ASPs may want to use DHCPv6 from the home network to
skipping to change at page 10, line 7 skipping to change at page 11, line 8
It may be desirable to establish randomly generated addresses as It may be desirable to establish randomly generated addresses as
in RFC 3041 and use them for a short period of time. in RFC 3041 and use them for a short period of time.
Unfortunately, current protocols make it possible to use such Unfortunately, current protocols make it possible to use such
addresses only from the visited network. As a result, these addresses only from the visited network. As a result, these
addresses can not be used for communications lasting longer than addresses can not be used for communications lasting longer than
the attachment to a particular visited network. the attachment to a particular visited network.
Ease of deployment Ease of deployment
In order to make deployment of Mobile IPv6 easy, it would be In order to simplify the deployment of Mobile IPv6, it is
desirable to free users and administrators from the task of desirable to free users and administrators from the task of
allocating home addresses and specifying them in the security allocating home addresses and specifying them in the security
policy database. policy database.
This is consistent with the general IPv6 design goal of using This is consistent with the general IPv6 design goal of using
autoconfiguration whereever possible. autoconfiguration wherever possible.
Prefix changes in the home network Prefix changes in the home network
The Mobile IPv6 specification contains support for a mobile node The Mobile IPv6 specification contains support for a mobile node
to autoconfigure a home address based on its discovery of prefix to autoconfigure a home address based on its discovery of prefix
information on the home subnet [2]. Autoconfiguration in case of information on the home subnet [RFC3775]. Autoconfiguration in
network renumbering is done by replacing the existing network case of network renumbering is done by replacing the existing
prefix with the new network prefix. network prefix with the new network prefix.
Subsequently, the MN needs to update the mobility binding in the Subsequently, the MN needs to update the mobility binding in the
HA to register the newly configured Home Address. However, the MN HA to register the newly configured Home Address. However, the MN
may not be able to register the newly configured address with the may not be able to register the newly configured address with the
HA if a security association related to that reconfigured Home HA if a security association related to that reconfigured Home
Address does not exist in the MN and the HA. This situation is Address does not exist in the MN and the HA. This situation is
not handled in the current MIPv6 specification [2]. not handled in the current MIPv6 specification [RFC3775].
5.1.2 Dynamic Home Agent Assignment 5.1.2 Dynamic Home Agent Assignment
Currently, the address of the home agent is specified in the security Currently, the address of the home agent is specified in the security
policy database. Support for multiple home agents requires the policy database. Support for multiple home agents requires the
configuration of multiple security policy database entries. configuration of multiple security policy database entries.
However, support for dynamic home agent assignment would be desirable However, support for dynamic home agent assignment would be desirable
for the following reasons: for the following reasons:
Home agent discovery Home agent discovery
The Mobile IPv6 specification contains support for a mobile node The Mobile IPv6 specification contains support for a mobile node
to autoconfigure a home agent address based on a discovery to autoconfigure a home agent address based on a discovery
protocol [2]. protocol [RFC3775].
Independent network management Independent network management
An ASP may want to dynamically assign home agents in different An ASP may want to dynamically assign home agents in different
subnets, that is, not require that a roaming mobile node have a subnets, that is, not require that a roaming mobile node have a
fixed home subnet. fixed home subnet.
Local home agents Local home agents
The mobile node's home ASP may want to allow a local roaming The mobile node's home ASP may want to allow a local roaming
skipping to change at page 11, line 34 skipping to change at page 12, line 34
system for updating the security policy entries, or manual system for updating the security policy entries, or manual
configuration. These requirements apply to both home agents and configuration. These requirements apply to both home agents and
mobile nodes, but it can not be expected that mobile node users are mobile nodes, but it can not be expected that mobile node users are
capable of performing the required tasks. capable of performing the required tasks.
5.2 Security Infrastructure 5.2 Security Infrastructure
5.2.1 Integration with AAA Infrastructure 5.2.1 Integration with AAA Infrastructure
The current IKEv1-based dynamic key exchange protocol described in The current IKEv1-based dynamic key exchange protocol described in
[3] has no integration with backend authentication, authorization and [RFC3776] has no integration with backend authentication,
accounting techniques unless the authentication credentials and trust authorization and accounting techniques unless the authentication
relationships use certificates or pre-shared secrets. credentials and trust relationships use certificates or pre-shared
secrets.
Using certificates may require the ASP to deploy a PKI, which may not Using certificates may require the ASP to deploy a PKI, which may not
be possible or desirable in certain circumstances. Where a be possible or desirable in certain circumstances. Where a
traditional AAA infrastructure is used, the home agent is not able to traditional AAA infrastructure is used, the home agent is not able to
leverage authentication and authorization information established leverage authentication and authorization information established
between the mobile node, the foreign AAA server, and the home AAA between the mobile node, the foreign AAA server, and the home AAA
server when the mobile node gains access to the foreign network, in server when the mobile node gains access to the foreign network, in
order to authenticate the mobile node's identity and determine if the order to authenticate the mobile node's identity and determine if the
mobile node is authorized for mobility service. mobile node is authorized for mobility service.
The lack of connection to the AAA infrastructure also means the home The lack of connection to the AAA infrastructure also means the home
agent does not know where to issue accounting records at appropriate agent does not know where to issue accounting records at appropriate
times during the mobile node's session, as determined by the business times during the mobile node's session, as determined by the business
relationship between the home ASP and the mobile node's owner. relationship between the home ASP and the mobile node's owner.
Presumably, some backend AAA protocol between the home agent and home Presumably, some backend AAA protocol between the home agent and home
AAA could be utilized, but IKEv1 does not contain support for AAA could be utilized, but IKEv1 does not contain support for
exchanging full AAA credentials with the mobile node. It is exchanging full AAA credentials with the mobile node. It is
worthwhile to note that IKEv2 provides this feature. worthwhile to note that IKEv2 provides this feature.
5.2.2 Opportunistic or Local Discovery 5.2.2 "Opportunistic" or "Local" Discovery
The home agent discovery protocol does not support an "opportunistic" The home agent discovery protocol does not support an "opportunistic"
or local discovery mechanisms in an ASP's local access network. It or local discovery mechanisms in an ASP's local access network. It
is expected that the mobile node must know the prefix of the home is expected that the mobile node must know the prefix of the home
subnet in order to be able to discover a home agent. It must either subnet in order to be able to discover a home agent. It must either
obtain that information through prefix update or have it statically obtain that information through prefix update or have it statically
configured. A more typical pattern for interdomain service discovery configured. A more typical pattern for interdomain service discovery
in the Internet is that the client (mobile node in this case) knows in the Internet is that the client (mobile node in this case) knows
the domain name of the service, and uses DNS in some manner to find the domain name of the service, and uses DNS in some manner to find
the server in the other domain. For local service discovery, DHCP is the server in the other domain. For local service discovery, DHCP is
typically used. typically used.
5.3 Topology Change 5.3 Topology Change
5.3.1 Dormant Mode Mobile Nodes 5.3.1 Dormant Mode Mobile Nodes
The description of the protocol to push prefix information to mobile The description of the protocol to push prefix information to mobile
nodes in Section 10.6 in [2] has an implicit assumption that the nodes in Section 10.6 in [RFC3775] has an implicit assumption that
mobile node is active and taking IP traffic. In fact, many, if not the mobile node is active and taking IP traffic. In fact, many, if
most, mobile devices will be in a low power "dormant mode" to save not most, mobile devices will be in a low power "dormant mode" to
battery power, or even switched off, so they will miss any save battery power, or even switched off, so they will miss any
propagation of prefix information. As a practical matter, if this propagation of prefix information. As a practical matter, if this
protocol is used, an ASP will need to keep the old prefix around and protocol is used, an ASP will need to keep the old prefix around and
handle any queries to the old home agent anycast address on the old 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 subnet, whereby the mobile node asks for a new home agent as
described in Section 11.4, until all mobile nodes are accounted for. 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 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, long periods, some owners would need to be contacted by other means,
reducing the utility of the protocol. reducing the utility of the protocol.
Bootstrapping does not explicitly try to solve this problem of home Bootstrapping does not explicitly try to solve this problem of home
skipping to change at page 13, line 18 skipping to change at page 14, line 18
practical network deployment/roaming scenarios. This description practical network deployment/roaming scenarios. This description
lays the ground work for Section 7. The focus is on the 'service' lays the ground work for Section 7. The focus is on the 'service'
model since, ultimately, it is the provider providing the service model since, ultimately, it is the provider providing the service
that wants to authenticate the mobile (and vice-versa for mutual that wants to authenticate the mobile (and vice-versa for mutual
authentication between provider and the user of the service). authentication between provider and the user of the service).
Network access service enables a host to send and receive IP packets Network access service enables a host to send and receive IP packets
on the Internet or an intranet. IP address configuration and IP on the Internet or an intranet. IP address configuration and IP
packet forwarding capabilities are required to deliver this service. packet forwarding capabilities are required to deliver this service.
A network operator providing this service is called an access service A network operator providing this service is called an access service
provider (ASP). An ASP can be a commercial ASP, the IT department of provider (ASP). An ASP can, for example, be a commercial ASP, the IT
an enterprise network, or the maintainer of a home (residential) department of an enterprise network, or the maintainer of a home
network. (residential) network.
When the network service requires authentication, the concept of home
ASP and serving ASP comes into the picture. Home ASP is the provider
with whom the user has an account. Therefore, when the user directly
connects to the home ASP network, the ASP can perform authentication
without relying on any other service provider. On the other hand,
when the user is roaming on the Internet, it may connect to another
ASP network that has a roaming agreement with the home ASP. That ASP
is called serving ASP. The serving ASP cannot authenticate a roaming
user on its own, for that it needs to contact the home ASP.
A host does not always have to use an IP address from one of its home
ASP prefixes. It may be configured with one from the serving ASP's
prefixes. In fact, the home ASP may not even have a physical access
network, in which case it could be identified as a virtual operator.
Another service is called Mobile IPv6 service, which enables a host
to maintain its IP reachability despite changing its network
attachment points (subnets). Providing Mobile IPv6 service involves
setting up a home agent on a subnet that acts as a Mobile IPv6 home
link. Home agent's responsibility include tunneling host's IP
packets between the home link and its current point-of attachment. A
network operator providing this service is called a mobility service
provider (MSP). Mobile IPv6 requires authentication between the host
and the home agent. The MSP that maintains an account for the user
is called a home MSP. A home MSP can authenticate its users without
relying on any other service provider. Conceptually, the user may be
receiving the Mobile IP service from another MSP that has a roaming
agreement with the home MSP. Such a service provider is called
serving MSP. A serving MSP needs to contact the home MSP in order to
authenticate the user before providing the mobility service.
A host may authenticate with a MSP based on the some kind of AAA If the mobile host is within the geographical area in which network
association with the ASP (typically the home ASP or through the home access service is not provided by its home network access service
ASP). provider, the mobile host is roaming. The home network access
service provider in this case 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 host 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, while 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.
A host does not always have to use a Mobile IPv6 home address from Mobility service using Mobile IPv6 is conceptually and possibly also
one of its home MSP prefixes. It may be configured with one from the in practice separate from network access service, though of course
serving MSP's prefixes. In fact, the home MSP may not even have a network access is required prior to providing mobility. Mobile IPv6
physical access network, in which case it could be identified as a service enables an IPv6 host to maintain its reachability despite
virtual operator. 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 a host to authenticate
and prove authorization for the service. A network operator that
authenticates a mobile host and authorizes mobility service is called
a mobility service authorizer. 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 provider by
another, the operator providing the service is called the serving
mobility service provider. The serving MSP must contact the mobile
host's mobility service authorizer to check the mobile host's
authorization prior to granting mobility service.
Network access and Mobile IPv6 are two distinct services. A host can The service model defined here clearly separates the entity providing
choose to have only network access service, or both network access the service from the entity that authentications and authorizes the
and Mobile IPv6 services at the same time. Only having Mobile IPv6 service. In the case of basic network access, this supports the
service is not possible, since the Mobile IPv6 protocol requires traditional and well-known roaming model, in which inter-operator
ability to send and receive IPv6 packets. Even when both services roaming agreements allow a host to obtain network access in areas
are received by a host, the service providers involved might vary. where their home network access provider does not have coverage. In
All combinations are possible with respect to the choice of ASPs and the case of mobility service, this allows a roaming mobile host to
MSPs: 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, like, 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 o The serving ASP might be the home ASP. Similarly, the serving MSP
might be the home MSP. might be the home MSP.
o The home ASP and the home MSP may be the same operator, or not. 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 When they are the same, the same set of credentials may be used
for both services. for both services.
o The serving ASP and the serving MSP may be the same operator, or o The serving ASP and the serving MSP may be the same operator, or
not. not.
o It is possible that serving ASP and home MSP are the same o It is possible that serving ASP and home MSP are the same
operator. operator.
Similarly the home ASP and serving MSP may be the same. Similarly the home ASP and serving MSP may be the same. Also, the
ASA and MSA may be the same.
These entities and possible combinations must be taken into These entities and possible combinations must be taken into
consideration when solving the Mobile IPv6 bootstraping problem. consideration when solving the Mobile IPv6 bootstraping problem.
They impact home agent discovery, home address configuration, and They impact home agent discovery, home address configuration, and
mobile node to home agent authentication aspects. mobile node to home agent authentication aspects.
7. Deployment scenarios 7. Deployment scenarios
This section describes the various network deployment scenarios. The This section describes the various network deployment scenarios. The
various combinations of service providers as described in Section 6 various combinations of service providers as described in Section 6
are considered. are considered.
For each scenario, the underlying assumptions are described. The For each scenario, the underlying assumptions are described. The
basic assumption is that there is a trust relationship between mobile basic assumption is that there is a trust relationship between mobile
user and the MSP. Typically, this trust relationship is between the user and the MSP. Typically, this trust relationship is between the
mobile user and AAA in the MSP network. Seed information needed to mobile user and AAA in the MSA's network. Seed information needed to
bootstrap the mobile node is considered in two cases (i) AAA bootstrap the mobile node is considered in two cases:
authentication is mandatory for network access "&amp" (ii) AAA o AAA authentication is mandatory for network access
authentication is not part of network access. The seed information o AAA authentication is not part of network access. The seed
is described further in Section 8. information is described further in Section 8.
7.1 Mobility Service Subscription Scenario 7.1 Mobility Service Subscription Scenario
Many commercial deployments are based on the assumption that mobile Many commercial deployments are based on the assumption that mobile
nodes have a subscription with a service provider. In particular, in nodes have a subscription with a service provider. In particular, in
this scenario the MN has a subscription with an MSP, called the home this scenario the MN has a subscription with an MSP, called the home
MSP, for Mobile IPv6 service. As stated in Section 6, the MSP is MSP, for Mobile IPv6 service. As stated in Section 6, the MSP is
responsible of setting up a home agent on a subnet that acts as a responsible of setting up a home agent on a subnet that acts as a
Mobile IPv6 home link. As a consequence, the home MSP should Mobile IPv6 home link. As a consequence, the home MSP should
explicitly authorize and control the whole bootstrapping procedure. explicitly authorize and control the whole bootstrapping procedure.
skipping to change at page 16, line 26 skipping to change at page 17, 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 supported by the base Mobile IPv6 This is certainly the only model support 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 MSA 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.
This arrangement is similar to the visited - home operator roaming This arrangement is similar to the visited - home operator roaming
arrangement for network access. arrangement for network access.
skipping to change at page 18, line 44 skipping to change at page 19, 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 another IKE credentials, the home agent may communicate with other entity
entity (e.g., a AAA server) to perform mutual authentication in (for example a AAA server) to perform mutual authentication in
IKE. In such a case, the IKE credentials include the credentials IKE. In such a case, the IKE credentials include the credentials
used between the mobile node and the other entity. In the case used between the mobile node and the other entity. In the case
where a AAA protocol is used for the communication between the where a AAA protocol is used for the communication between the
home agent and the other entity during the IKE procedure, AAA for home agent and the other entity during the IKE procedure, AAA for
Mobile IPv6 service may be involved in IKE. Mobile IPv6 service may be involved in IKE.
If authentication protocol [I-D.ietf-mip6-mn-auth-protocol-02] is
used, the shared key based security association with home agent is
needed.
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 20, line 7 skipping to change at page 21, line 7
* Network access credentials(*) * Network access credentials(*)
(*) A pair of a NAI and a pre-shared secret is an example set of (*) A pair of a NAI and a pre-shared secret is an example set of
credentials. A pair of an NAI and a public key, which may be credentials. A pair of an NAI and a public key, which may be
provided as a digital certificate, is another example set of provided as a digital certificate, is another example set of
credentials. credentials.
9. Security Considerations 9. Security Considerations
The bootstrapping procedure needs to create a security association There are two aspects of security for the Mobile IPv6 bootstrapping
that matches the requirements set for its use. Mobile IPv6 base problem:
specification expects strong, mutual authentication and trust 1. The security requirements imposed on the outcome of the
relationship between the mobile node and home agent. This is bootstrapping process by RFC 3775 and other RFCs used by Mobile
necessary, for instance, to ensure that fraudulent mobile nodes that IPv6 for security.
flood other nodes with traffic [draft-ietf-mipv6-ro-sec] can not only 2. The security of the bootstrapping process itself, in the sense of
be shut off from the service, but also tracked down. The use of threats to the bootstrapping process imposed by active or passive
infrastructureless techniques does not satisfy these requirements, at attackers.
least not without introducing additional routability tests to the
Mobile IPv6 home registration procedure.
Thus, the case of infrastructure-less network where there is Note that the two are related, in that if the bootstrapping process
absolutely no pre-mediated trust is kept outside of scope of this is compromised, the level of security required by RFC 3775 may not be
document. obtained.
Another requirement is that the "ownership" to a particular home The following two sections discuss these issues.
address must be authorized to at most one mobile node at a time.
This implies that a Mobile IPv6 security association is always tied
to zero or more such authorizations; these authorizations can either
be created at the time the security association is created, or
dynamically managed through, for instance, a First Come First Served
allocation policy.
Where an automatic bootstrap process is used, it becomes necessary to 9.1 Security Requirements of Mobile IPv6
associate a lifetime with all the parameters which are bootstrapped.
Otherwise a large number of unused security associations would have
to be stored by the participating nodes, either by accident or
through malicious behaviour or the mobile node will have stale
information.
The specific mean of verifying the security association is not The Mobile IPv6 specification in RFC 3775 requires the establishment
defined in this document, but it can be, for example a set of IKE of a collection of IPsec SAs between the home agent and mobile host
credentials, an IPsec security association, a username-password -like to secure the signaling traffic for Mobile IP, and, optionally, also
association or digital signature constructed by a certified key. to secure data traffic. The security of an IPsec SA required by the
relevent 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 host. If other parties
are involved in the establishing the SA, through key distribution for
example, the process should follow the constraints [eap_keying]
designed to provide equivalent security.
The bootstrap process itself may have vulnerabilities. The following RFC 3775 also requires a trust relationship as defined in Section 1.3
issues need to be addressed: between the mobile host and mobility service provider. This is
necessary, for instance, to ensure that fradulent mobile hosts which
attempt to flood other mobile hosts with traffic can not only be shut
off but tracked down [I-D.rosec]. An infrastructureless relationship
as defined in Section 1.3 does not satisfy this requirement. Any
bootstrapping solution must include a trust relationship between
mobile host and mobility service provider. Solutions that depend on
an infrastructureless relationship are out of scope for
bootstrapping.
o Mutual authentication and trust relationship between the mobile Another requirement is that a home address is authorized to one
node and the entity handling the bootstrap process. Refer to specific host at a time. RFC 3775 requires this in order to that
Section 7.15 in [9] and [10] for further information. misbehaving mobile hosts can be shut down. This implies that, in
o Cryptographic separation and naming of session keys used for addition to the IPsec SA, the home agent must somehow authorize the
multiple purposes, such as network access authentication and mobile host for a home address. The authorization can be either
mobility service. implicit (for example, as a side effect of the authentication for
o Ensuring that key lifetimes are not exceeded. mobility service) or explicit. The authorization can either be done
at the time the SA is created or dynamically managed through a first
come, first served allocation policy.
o Binding security associations to specific home agent and address 9.2 Threats to the Bootstrapping Process
allocations.
o Support of multiple algorithms for the resulting security Various attacks are possible on the bootstrapping process itself.
associations. These attacks can compromise the process such that the RFC 3775
o Avoidance of denial-of-service vulnerabilities. requirements for Mobile IP security are not met, or they can serve to
simply disrupt the process such that bootstrapping cannot complete.
Here are some possible attacks:
o An attacking network entity purporting to offer the mobile host a
legitimate home agent address or boostrapping 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 host's traffic
or otherwise disrupts the mobile host's mobility service.
o An attacking mobile host may attempt to steal mobility service by
offering up fake credentials to a bootstrapping network entity or
otherwise disrupt the home agent's ability to offer mobility
service.
o A man in the middle on the link between the mobile host 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 [2284bis] and [I-D.mariblanca-aaa-eap-lla-00] 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, separately
named, and have separate lifetimes, including if the keys are
generated from the same authentication credentials This is necessary
because a mobile host 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.
10. Contributors 10. Contributors
This contribution is a joint effort of the problem statement design This contribution is a joint effort of the problem statement design
team of the Mobile IPv6 WG. The contributors (alphabetical order) team of the Mobile IPv6 WG. The contributors include Basavaraj
include Jari Arkko, Samita Chakrabarti, Kuntal Chowdhury, Vijay Patil, Gerardo Giaretta, Jari Arkko, James Kempf, Yoshihiro Ohba,
Devarapalli, Gopal Dommety, Gerardo Giaretta, James Kempf, Kent Ryuji Wakikawa, Hiroyuki Ohnishi, Mayumi Yanagiya Samita Chakrabarti,
Leung, Yoshihiro Ohba, Hiroyuki Ohnishi, Basavaraj Patil, Hannes Gopal Dommety, Kent Leung, Alper Yegin, Hannes Tschofenig, Vijay
Tschofenig, Ryuji Wakikawa, Mayumi Yanagiya and Alper Yegin. Devarapalli, Kuntal Chowdury.
The design team members can be reached at:
Basavaraj Patil basavaraj.patil@nokia.com
Gerardo Giaretta gerardo.giaretta@tilab.com
Jari Arkko jari.arkko@kolumbus.fi
James Kempf kempf@docomolabs-usa.com
Yoshihiro Ohba yohba@tari.toshiba.com
Ryuji Wakikawa ryuji@sfc.wide.ad.jp
Hiroyuki Ohnishi ohnishi.hiroyuki@lab.ntt.co.jp
Mayumi Yanagiya yanagiya.mayumi@lab.ntt.co.jp
Samita Chakrabarti Samita.Chakrabarti@eng.sun.com
Gopal Dommety gdommety@cisco.com
Kent Leung kleung@cisco.com
Alper Yegin alper.yegin@samsung.com
Hannes Tschofenig hannes.tschofenig@siemens.com
Vijay Devarapalli vijayd@iprg.nokia.com
Kuntal Chowdury kchowdury@starentnetworks.com
11. Acknowledgments 11. Acknowledgments
Special thanks to James Kempf and Jari Arkko for writing the initial Special thanks to James Kempf and Jari Arkko for writing the initial
version of the bootstrapping statement. version of the bootstrapping statement. Thanks to John Loughney for
a detailed editorial review.
12. References 12. References
12.1 Normative References 12.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [I-D.ietf-mip6-mn-auth-protocol-02]
Levels", RFC 2119, March 1997. Patel et. al., A., "Authentication Protocol for Mobile
IPv6", draft-ietf-mip6-auth-protocol-02.txt (work in
progress), November 2004,
[2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in <http://www.ietf.org/internet-drafts/draft-ietf-mip6-auth-protocol-02.txt>
IPv6", RFC 3775, July 2003. .
[3] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to [I-D.ietf-seamoby-mobility]
Protect Mobile IPv6 Signaling between Mobile Nodes and Home Manner, J. and M. Kojo, "Mobility Related Terminology",
Agents", RFC 3776, July 2003. draft-ietf-seamoby-mobility-terminology-06 (work in
progress), February 2004,
[4] Manner, J. and M. Kojo, "Mobility Related Terminology", <http://www.ietf.org/internet-drafts/draft-ietf-seamoby-mobility-terminology
draft-ietf-seamoby-mobility-terminology-06 (work in progress), -06.txt>
February 2004. .
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3776] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, June 2004.
12.2 Informative References 12.2 Informative References
[5] Giaretta, G., "MIPv6 Authorization and Configuration based on [2284bis] Levkowetz, Ed., H., "Extensible Authentication Protocol
EAP", draft-giaretta-mip6-authorization-eap-00 (work in (EAP)", February 2004,
progress), February 2004.
[6] Kempf, J. and J. Arkko, "The Mobile IPv6 Bootstrapping <http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-09.txt>
Problem", draft-kempf-mip6-bootstrap-00 (work in progress), .
March 2004.
[7] Patel, A., Leung, K., Akthar, H., Khalil, M. and K. Chowdhury, [I-D.giaretta-mip6-authorization-eap]
"Network Access Identifier Option for Mobile IPv6", Giaretta, G., "MIPv6 Authorization and Configuration based
draft-ietf-mip6-nai-option-00 (work in progress), February on EAP", draft-giaretta-mip6-authorization-eap-00 (work in
2004. progress), February 2004,
[8] Calhoun, P. and C. Perkins, "Mobile IP Network Access <http://www.ietf.org/internet-drafts/draft-giaretta-mip6-authorization-eap-0
Identifier Extension for IPv4", RFC 2794, March 2000. 0.txt>
.
[9] Levkowetz, Ed., H., "Extensible Authentication Protocol (EAP)", [I-D.ietf-mip6-mn-ident-option-02]
draft-ietf-eap-rfc2284bis-09 (work in progress), February 2004. Patel, A., Leung, K., Akthar, H., Khalil, M. and K.
Chowdhury, "Mobile Node Identifier Option for Mobile
IPv6", draft-ietf-mip6-mn-ident-option-02.txt (work in
progress), February 2004,
[10] Mariblanca, D., "EAP lower layer attributes for AAA protocols", <http://www.ietf.org/internet-drafts/draft-ietf-mip6-mn-ident-option-02.txt>
draft-mariblanca-aaa-eap-lla-00.txt (work in progress), May .
2004.
[11] Yegin, A., "AAA Mobile IPv6 Application Framework", [I-D.kempf-mip6-bootstrap]
draft-yegin-mip6-aaa-fwk-00 (work in progress), August 2004. Kempf, J. and J. Arkko, "The Mobile IPv6 Bootstrapping
Problem", draft-kempf-mip6-bootstrap-00 (work in
progress), March 2004,
<http://www.ietf.org/internet-drafts/draft-kempf-mip6-bootstrap-00.txt>
.
[I-D.mariblanca-aaa-eap-lla-00]
Mariblanca, D., "EAP lower layer attributes for AAA
protocols", May 2004,
<http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-lla-00.txt>
.
[I-D.rosec]
Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E.
Nordmark, "Mobile IP version 6 Route Optimization Security
Design Background", draft-ietf-mip6-ro-sec-02 (work in
progress), October 2004,
<http://www.ietf.org/internet-drafts/draft-ietf-mip6-ro-sec-02.txt>
.
[eap_keying]
Aboba et. al., B., "Extensible Authentication Protocol
(EAP) Key Management Framework",
draft-ietf-eap-keying-05.txt (work in progress), February
2005,
<http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-05.txt>
.
Author's Address Author's Address
Alpesh Patel Alpesh Patel
cisco Systems Cisco
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
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
skipping to change at page 26, line 41 skipping to change at page 27, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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