Request for Comments: 4640 Cisco
Category: Informational G. Giaretta, Ed.
Telecom Italia
September 2006
Problem Statement for Bootstrapping Mobile IPv6 (MIPv6)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
A mobile node needs at least the following information: a home
address, a home agent address, and a security association with home
agent to register with the home agent. The process of obtaining this
information is called bootstrapping. This document discusses issues
involved with how the mobile node can be bootstrapped for Mobile IPv6
(MIPv6) and various potential deployment scenarios for mobile node
bootstrapping.
Table of Contents
1. Introduction ....................................................2
1.1. Overview of the Problem ....................................3
1.2. Bootstrapping ..............................................3
1.3. Terminology ................................................4
2. Assumptions .....................................................5
3. Design Goals ....................................................6
4. Non-goals .......................................................7
5. Motivation for bootstrapping ....................................7
5.1. Addressing .................................................7
5.1.1. Dynamic Home Address Assignment .....................7
5.1.2. Dynamic Home Agent Assignment .......................9
5.1.3. "Opportunistic" or "Local" Discovery ................9
5.1.4. Management Requirements .............................9
5.2. Security Infrastructure ...................................10
5.2.1. Integration with AAA Infrastructure ................10
5.3. Topology Change ...........................................10
5.3.1. Dormant Mode Mobile Nodes ..........................10
6. Network Access and Mobility Services ...........................11
7. Deployment Scenarios ...........................................13
7.1. Mobility Service Subscription Scenario ....................13
7.2. Integrated ASP Network Scenario ...........................14
7.3. Third-Party MSP Scenario ..................................14
7.4. Infrastructure-less Scenario ..............................15
8. Parameters for Authentication ..................................15
9. Security Considerations ........................................17
9.1. Security Requirements of Mobile IPv6 ......................17
9.2. Threats to the Bootstrapping Process ......................18
10. Contributors ..................................................19
11. Acknowledgements ..............................................20
12. Informative References ........................................20
1. Introduction
Mobile IPv6 [RFC3775] specifies mobility support based on the
assumption that a mobile node (MN) has a trust relationship with an
entity called the home agent. Once the home agent address has been
learned (for example, via manual configuration, anycast discovery
mechanisms, or DNS lookup), Mobile IPv6 signaling messages between
the mobile node and the home agent are secured with IPsec or with the
authentication protocol, as defined in [RFC4285]. The requirements
for this security architecture are created with [RFC3775], and the
details of this procedure are described in [RFC3776].
In [RFC3775], there is an implicit requirement that the MN be
provisioned with enough information that will permit it to register
successfully with its home agent. However, having this information
statically provisioned creates practical deployment issues.
This document serves to define the problem of bootstrapping.
Bootstrapping is defined as the process of obtaining enough
information at the mobile node that it can successfully register with
an appropriate home agent.
The requirements for bootstrapping could consider various
scenarios/network deployment issues. It is the basic assumption of
this document that certain minimal parameters (seed information) are
available to the mobile node to aid in bootstrapping. The exact seed
information available differs depending on the deployment scenario.
This document describes various deployment scenarios and provides a
set of minimal parameters that are available in each deployment
scenario.
This document stops short of suggesting the preferred solutions for
how the mobile node should obtain information. Such details will be
available from separate documents.
1.1. Overview of the Problem
Mobile IPv6 [RFC3775] expects the mobile node to have a static home
address, a home agent address (which can be derived from an anycast
address), and a security association with a home agent (or multiple
home agents).
This static provisioning of information has various problems, as
discussed in Section 5.
The aim of this document is:
o To define bootstrapping;
o To identify sample deployment scenarios where Mobile Internet
Protocol version 6 (MIPv6) will be deployed, taking into account
the relationship between the subscriber and the service provider;
and
o To identify the minimal set of information required on the Mobile
Node and in the network in order for the mobile node to obtain
address and security credentials, to register with the home agent.
1.2. Bootstrapping
Bootstrapping is defined as obtaining enough information at the
mobile node that the mobile node can successfully register with an
appropriate home agent. Specifically, this means obtaining the home
agent address and home address, and for the mobile node and home
agent to authenticate and mutually construct security credentials for
Mobile IPv6.
Typically, bootstrapping happens when a mobile node does not have all
the information it needs to set up the Mobile IPv6 service. This
includes, but is not limited to, situations in which the mobile node
does not having any information when it boots up for the first time
(out of the box), or does not retain any information during reboots.
Also, in certain scenarios, after the MN bootstraps for the first
time (out of the box), the need for subsequent bootstrapping is
implementation dependent. For instance, the MN may bootstrap every
time it boots, bootstrap every time on prefix change, or bootstrap
periodically to anchor to an optimal HA (based on distance, load,
etc.).
1.3. Terminology
General mobility terminology can be found in [RFC3753]. The
following additional terms are used here:
Trust relationship
In the context of this document, trust relationship means that the
two parties in question, typically the user of the mobile host and
the mobility or access service authorizer, have some sort of prior
contact in which the mobile node was provisioned with credentials.
These credentials allow the mobile node to authenticate itself to
the mobility or access service provider and to prove its
authorization to obtain service.
Infrastructureless relationship
In the context of this document, an infrastructureless
relationship is one in which the user of the mobile node and the
mobility or access service provider have no previous contact and
the mobile node 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 used by a mobile node to authenticate itself to a mobility or
access network service authorizer and to prove authorization to
receive service. User name/passwords, one time password cards,
public/private key pairs with certificates, and biometric
information are some examples.
ASA
Access Service Authorizer. A network operator that authenticates
a mobile node and establishes the mobile node’s authorization to
receive Internet service.
ASP
Access Service Provider. A network operator that provides direct
IP packet forwarding to and from the end host.
Serving Network Access Provider
A network operator that is the mobile node’s ASP but not its ASA.
The serving network access provider may or may not additionally
provide mobility service.
Home Network Access Provider
A network operator that is both the mobile node’s ASP and ASA.
The home network access provider may or may not additionally
provide mobility service (note that this is a slightly different
definition from that in RFC 3775).
IASP
Integrated Access Service Provider. A service provider that
provides both authorization for network access and mobility
service.
MSA
Mobility Service Authorizer. A service provider that authorizes
Mobile IPv6 service.
MSP
Mobility Service Provider. A service provider that provides
Mobile IPv6 service. In order to obtain such service, the mobile
node 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
o A basic assumption in Mobile IPv6 [RFC3775] is that there is a
trust relationship between the mobile node and its home agent(s).
This trust relationship can be direct, or indirect through, for
instance, an ASP that has a contract with the MSP. This trust
relationship can be used to bootstrap the MN.
One typical way of verifying the trust relationship is using
authentication, authorization, and accounting (AAA)
infrastructure. In this document, two distinct uses of AAA are
considered:
AAA for Network Access
This functionality provides authentication and authorization to
access the network (obtain address and send/receive packets).
AAA for Mobility Service
This functionality provides authentication and authorization
for mobility services.
These functionalities may be implemented in a single entity or in
different entities, depending on the service models described in
Section 6 or deployment scenarios as described in Section 7.
o Some identifier, such as an Network Access Identifier (NAI), as
defined in [RFC4283] or [RFC2794], is provisioned on the MN that
permits the MN to identify itself to the ASP and MSP.
3. Design Goals
A solution to the bootstrapping problem has the following design
goals:
o The following information must be available at the end of
bootstrapping, to enable the MN to register with the HA.
* MN’s home agent address
* MN’s home address
* IPsec Security Association (SA) between MN and HA, Intenet Key
Exchange Protocol (IKE) pre-shared secret between MN and HA
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,
or HA indicating the MN. 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
SA) can be executed between the MN and the HA itself without
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
of user-specific information on entities other than the home
agent.
o Configuration information which is exchanged between the mobile
node and the home agent must be secured using integrity and replay
protection. Confidentiality protection should be provided if
necessary.
o The solution should be applicable to all feasible deployment
scenarios that can be envisaged, along with the relevant
authentication/authorization models.
4. Non-goals
This following issues are clearly outside the scope of bootstrapping:
o Home prefix renumbering is not explicitly supported as part of
bootstrapping. If the MN executes the bootstrap procedures every
time it powers on (as opposed to caching state information from
previous bootstrap process), then home network renumbering is
taken care of automatically.
o Bootstrapping in the absence of a trust relationship between MN
and any provider is not considered.
5. Motivation for bootstrapping
5.1. Addressing
The default bootstrapping described in the Mobile IPv6 base
specification [RFC3775] has a tight binding to the home addresses and
home agent addresses.
In this section, we discuss the problems caused by the currently
tight binding to home addresses and home agent addresses.
5.1.1. Dynamic Home Address Assignment
Currently, the home agent uses the mobile node’s home address for
authorization. When manual keying is used, this happens through the
security policy database, which specifies that a certain security
association may only be used for 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 according to a dynamically assigned home
address. As a result, static home address assignment is really the
only home address configuration technique compatible with the base
specification.
However, support for dynamic home address assignment would be
desirable for the following reasons:
Dynamic Host Configuration Protocol (DHCP)-based address assignment.
Some providers may want to use DHCPv6 or other dynamic address
assignment (e.g., IKEv2) from the home network to configure home
addresses.
Recovery from a duplicate address collision. It may be necessary to
recover from a collision of addresses on the home network by one of
the mobile nodes changing its home address.
Addressing privacy. It may be desirable to establish randomly
generated addresses as in [RFC3041] and use them for a short period
of time. Unfortunately, current protocols make it possible to use
such addresses only from the visited network. As a result, these
addresses cannot be used for communications lasting longer than the
attachment to a particular visited network.
Ease of deployment. In order to simplify the deployment of Mobile
IPv6, it is desirable to free users and administrators from the task
of allocating home addresses and specifying them in the security
policy database. This is consistent with the general IPv6 design
goal of using autoconfiguration wherever possible.
Prefix changes in the home network. The Mobile IPv6 specification
contains support for a mobile node to autoconfigure a home address as
based on its discovery of prefix information on the home subnet
[RFC3775]. Autoconfiguration in case of network renumbering is done
by replacing the existing network prefix with the new network prefix.
Subsequently, the MN needs to update the mobility binding in the HA
to register the newly configured Home Address. However, the MN may
not be able to register the newly configured address with the HA if a
security association related to that reconfigured Home Address does
not exist in the MN and the HA. This situation is not handled in the
current MIPv6 specification [RFC3775].
5.1.2. Dynamic Home Agent Assignment
Currently, the address of the home agent is specified in the security
policy database. Support for multiple home agents requires the
configuration of multiple security policy database entries.
However, support for dynamic home agent assignment would be desirable
for the following reasons:
Home agent discovery. The Mobile IPv6 specification contains support
for a mobile node to autoconfigure a home agent address as based on a
discovery protocol [RFC3775].
Independent network management. An MSP may want to assign home
agents dynamically in different subnets; for instance, not require
that a roaming mobile node have a fixed home subnet.
Local home agents. The mobile node’s MSP may want to allow the
serving MSP to assign a local home agent for the mobile node. This
is useful from the point of view of communications efficiency and has
also been mentioned as one approach to support location privacy.
Ease of deployment. In order to simplify the deployment of Mobile
IPv6, it is desirable to free users and administrators from the task
of allocating home agent addresses in a static manner. Moreover, an
MSP may want to have a dynamic home agent assignment mechanism to
load balance users among home agents located on different links.
5.1.3. "Opportunistic" or "Local" Discovery
The home agent discovery protocol does not support an "opportunistic"
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
subnet in order to be able to discover a home agent. It must either
obtain that information through prefix update or have it statically
configured. A more typical pattern for inter-domain service
discovery in the Internet is that the client (mobile node in this
case) knows the domain name of the service and uses DNS to find the
server in the visited domain. For local service discovery, DHCP is
typically used.
5.1.4. Management Requirements
As described earlier, new addresses invalidate configured security
policy databases and authorization tables. Regardless of the
specific protocols used, there is a need for either an automatic
system for updating the security policy entries or manual
configuration. These requirements apply to both home agents and
mobile nodes, but it cannot be expected that mobile node users are
capable of performing the required tasks.
5.2. Security Infrastructure
5.2.1. Integration with AAA Infrastructure
The current IKEv1-based dynamic key exchange protocol, described in
[RFC3776], has no integration with backend authentication,
authorization, and accounting techniques unless the authentication
credentials and trust relationships use certificates or pre-shared
secrets.
Certificates are not easily supported by traditional AAA
infrastructures. Where a traditional AAA infrastructure is used, the
home agent is not able to leverage authentication and authorization
information established between the mobile node, the foreign AAA
server, and the home AAA server. This would be desirable when the
mobile node gains access to the foreign network, in order to
authenticate the mobile node’s identity and determine whether the
mobile node is authorized for mobility service.
The lack of connection to the AAA infrastructure also means that the
home agent does not know where to send accounting records at
appropriate times during the mobile node’s session, as determined by
the business relationship between the MSP and the mobile node’s
owner.
Presumably, some backend AAA protocol between the home agent and home
AAA could be utilized, but IKEv1 does not contain support for
exchanging full AAA credentials with the mobile node. It is
worthwhile to note that IKEv2 provides this feature.
5.3. Topology Change
5.3.1. Dormant Mode Mobile Nodes
The description of the protocol to push prefix information to mobile
nodes in Section 10.6 of [RFC3775] has an implicit assumption that
the mobile node is active and taking IP traffic. In fact, many, if
not most, mobile devices will be in a low power "dormant mode" to
save battery power, or will even be switched off, so they will miss
any propagation of prefix information. As a practical matter, if
this protocol is used, an MSP will need to keep the old prefix around
and 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
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
long periods, some owners would need to be contacted by other means,
reducing the utility of the protocol.
Bootstrapping does not explicitly try to solve this problem of home
network renumbering when MN is in dormant mode. If the MN can
configure itself after it ’comes back on’ by reinitiating the
bootstrapping process, then network renumbering problem is fixed as a
side effect.
6. Network Access and Mobility Services
This section defines some terms as they pertain to authentication and
practical network deployment/roaming scenarios. This description
lays the groundwork for Section 7. The focus is on the ’service’
model since, ultimately, it is the provider providing the service
that wants to authenticate the mobile (and vice versa for mutual
authentication between provider and the user of the service).
Network access service enables a host to send and receive IP packets
on the Internet or an intranet. IP address configuration and IP
packet forwarding capabilities are required to deliver this service.
A network operator providing this service is called an access service
provider (ASP). An ASP can, for example, be a commercial ASP, the IT
department of an enterprise network, or the maintainer of a home
(residential) network.
If the mobile node is not directly usable for communication at the
current location of the MN in which network access service is
provided by its home ASP, the mobile node is roaming. In this case,
the home ASP 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 nodes
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, and 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.
Mobility service using Mobile IPv6 is conceptually and possibly also
in practice separate from network access service, though of course
network access is required prior to providing mobility. Mobile IPv6
service enables an IPv6 host to maintain its reachability despite
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 that a host
authenticate and prove authorization for the service. A network