GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4640

Network Working Group A. Patel, Ed. 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

Patel & Giaretta Informational [Page 1] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

         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.

Patel & Giaretta Informational [Page 2] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

 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.).

Patel & Giaretta Informational [Page 3] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

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.

Patel & Giaretta Informational [Page 4] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

 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.

Patel & Giaretta Informational [Page 5] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

    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.

Patel & Giaretta Informational [Page 6] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

 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

Patel & Giaretta Informational [Page 7] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

 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].

Patel & Giaretta Informational [Page 8] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

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

Patel & Giaretta Informational [Page 9] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

 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

Patel & Giaretta Informational [Page 10] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

 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

Patel & Giaretta Informational [Page 11] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

 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
 operator that authenticates a mobile node and authorizes mobility
 service is called a mobility service authorizer (MSA).  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
 provided by another, the operator providing the service is called the
 serving mobility service provider.  The serving MSP must contact the
 mobile node's mobility service authorizer to check the mobile node's
 authorization prior to granting mobility service.
 The service model defined here clearly separates the entity providing
 the service from the entity that authenticates and authorizes the
 service.  In the case of basic network access, this supports the
 traditional and well-known roaming model, in which inter-operator
 roaming agreements allow a host to obtain network access in areas
 where their home network access provider does not have coverage.  In
 the case of mobility service, this allows a roaming mobile node to
 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, such as, 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
    might be the home MSP.
 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
    for both services.
 o  The serving ASP and the serving MSP may be the same operator, or
    not.
 o  It is possible that serving ASP and home MSP are the same
    operator.
 Similarly the home ASP and serving MSP may be the same.  Also, the
 ASA and MSA may be the same.

Patel & Giaretta Informational [Page 12] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

 These entities and all combinations that are reasonable from a
 deployment perspective must be taken into consideration to solve the
 Mobile IPv6 bootstrapping problem.  They impact home agent discovery,
 home address configuration, and mobile node-to-home agent
 authentication aspects.

7. Deployment Scenarios

 This section describes the various network deployment scenarios.  The
 various combinations of service providers described in Section 6 are
 considered.
 For each scenario, the underlying assumptions are described.  The
 basic assumption is that there is a trust relationship between mobile
 user and the MSA.  Typically, this trust relationship is between the
 mobile user and AAA in the MSA's network.  Seed information needed to
 bootstrap the mobile node is considered in two cases:
 o  AAA authentication is mandatory for network access.
 o  AAA authentication is not part of network access.
 The seed information is described further in Section 8.

7.1. Mobility Service Subscription Scenario

 Many commercial deployments are based on the assumption that mobile
 nodes have a subscription with a service provider.  In this scenario
 the MN has a subscription with an MSA, also called the home MSP, for
 Mobile IPv6 service.  As stated in Section 6, the MSP is responsible
 for setting up a home agent on a subnet that acts as a Mobile IPv6
 home link.  As a consequence, the home MSP should explicitly
 authorize and control the whole bootstrapping procedure.
 Since the MN is assumed to have a pre-established trust relationship
 with its home provider, it must be configured with an identity and
 credentials; for instance, an NAI and a shared secret by some out-
 of-band means (i.e., manual configuration) before bootstrapping.
 In order to guarantee ubiquitous service, the MN should be able to
 bootstrap MIPv6 operations with its home MSP from any possible access
 location, such as an open network or a network managed by an ASP,
 that may be different from the MSP and that may not have any pre-
 established trust relationship with it.

Patel & Giaretta Informational [Page 13] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

7.2. Integrated ASP Network Scenario

 In this scenario, the ASA and MSA are the same entity.  The MN has
 security credentials for access to the network, and these credentials
 can also be used to bootstrap MIPv6.
 Figure 1 describes an AAA design example for integrated ASP scenario.
                   +----------------------------+
                   | IASP(ASA+MSA)              |
      +----+    +-----+         +----+          |
      | MN |--- | NAS |         | HA |          |
      +----+    +-----+         +----+          |
                   | \            \             |
                   |  \ +------+   \ +-------+  |
                   |   -|AAA-NA|    -|AAA-MIP|  |
                   |    +------+     +-------+  |
                   +----------------------------+
           NAS: Network Access Server
           AAA-NA: AAA for network access
           AAA-MIP: AAA for Mobile IP service
         Figure 1.  Integrated ASP network

7.3. Third-Party MSP Scenario

 Mobility service has traditionally been provided by the same entity
 that authenticates and authorizes the subscriber for network access.
 This is certainly the only model supported by the base Mobile IPv6
 specification.
 In the third-party mobility service provider scenario, the
 subscription for mobility service is made with one entity (the MSA,
 is for instance, a corporate), but the actual mobility service is
 provided by yet another entity (such as an operator specializing in
 this service, the serving MSP).  These two entities have a trust
 relationship.  Transitive trust among the mobile node and these two
 entities may be used to assure the participants that they are dealing
 with trustworthy peers.
 This arrangement is similar to the visited - home operator roaming
 arrangement for network access.

Patel & Giaretta Informational [Page 14] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

 Figure 2 describes an example of a network for the third-party MSP
 scenario.
              +--------------+   +--------+
              |              |   |Serving |
              | ASP          |   | MSP    |
 +----+    +-----+           |   | +----+ |
 | MN |--- | NAS |           |   | | HA | |  +-------------------+
 +----+    +-----+           |===| +----+ |  | MSA               |
              | \            |   |    \   || (e.g., corporate NW)|
              |  \ +------+  |   |     \     | +-------+         |
              |   -|AAA-NA|  |   |      -------|AAA-MIP|         |
              |    +------+  |   |        |  | +-------+         |
              +------------  +   +--------+  +-------------------+
         Figure 2.  Third-Party MSP network

7.4. Infrastructure-less Scenario

 Infrastructure refers to network entities like AAA, Public-Key
 Infrastructure (PKI), and Home Location Register (HLR).
 "Infrastructure-less" implies that there is no dependency on any
 elements in the network with which the user has any form of trust
 relationship.
 In such a scenario, there is absolutely no relationship between host
 and infrastructure.
 A good example of infrastructure-less environment for MIPv6
 bootstrapping is the IETF network at IETF meetings.  It is possible
 that there could be MIP6 service available on this network (i.e., a
 MIPv6 HA).  However, there is not really any AAA infrastructure or,
 for that matter, any trust relationship that a user attending the
 meeting has with any entity in the network.
 This specific scenario is not supported in this document.  The reason
 for this is described in Section 9.

8. Parameters for Authentication

 The following is a list of parameters that are used as the seed for
 the bootstrapping procedure.  The parameters vary depending on
 whether authentication for network access is independent of
 authentication for mobility services.  If different client identities
 are used for network access and mobility services, authentication for
 network access is independent of authentication for mobility
 services.

Patel & Giaretta Informational [Page 15] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

 o  Parameter Set 1
    In this case, authentication for network access is independent of
    authentication for mobility services.
    If the home agent address is not known to the mobile node, the
    following parameter is needed for discovering the home agent
    address:
  • The domain name or Fully Qualified Domain Name (FQDN) of the

home agent

    This parameter may be derived in various ways, such as (but not
    limited to) static configuration, use of the domain name from the
    network access NAI (even if AAA for network access is not
    otherwise used), or use of the domain name of the serving ASP,
    where the domain name may be obtained via DHCP in the serving ASP.
    If the home agent address is not known but the home subnet prefix
    is known, Dynamic Home Agent Address Discovery of Mobile IPv6 may
    be used for discovering the home agent address, and the above
    parameter may not be used.
    When the home agent address is known to the mobile node, the
    following parameter is needed for performing mutual authentication
    between the mobile node and the home agent by using IKE:
  • IKE credentials (*)
    In the case where the home agent does not have the entire set of
    IKE credentials, the home agent may communicate with another
    entity (for example, an AAA server) to perform mutual
    authentication in IKE.  In such a case, the IKE credentials
    include the credentials used between the mobile node and the other
    entity.  In the case where an AAA protocol is used for the
    communication between the home agent and the other entity during
    the IKE procedure, AAA for Mobile IPv6 service may be involved in
    IKE.  If the authentication protocol [RFC4285] is used, the shared
    key-based security association with the home agent is needed.
 o  Parameter Set 2
    In this case, some dependency exists between authentication for
    network access and authentication for mobility services in that a
    security association that is established as a result of
    authentication for network access is re-used for authentication
    for mobility services.

Patel & Giaretta Informational [Page 16] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

    All required information, including IKE credentials, is
    bootstrapped from the following parameter:
  • Network access credentials(*)
 (*) A pair of an NAI and a pre-shared secret is an example of a set
 of credentials.  A pair of an NAI and a public key, which may be
 provided as a digital certificate, is another example of a set of
 credentials.

9. Security Considerations

 There are two aspects of security for the Mobile IPv6 bootstrapping
 problem:
 1.  The security requirements imposed on the outcome of the
     bootstrapping process by RFC 3775 and other RFCs used by Mobile
     IPv6 for security.
 2.  The security of the bootstrapping process itself, in the sense of
     threats to the bootstrapping process imposed by active or passive
     attackers.
 Note that the two are related; if the bootstrapping process is
 compromised, the level of security required by RFC 3775 may not be
 achieved.
 The following two sections discuss these issues.

9.1. Security Requirements of Mobile IPv6

 The Mobile IPv6 specification in RFC 3775 requires the establishment
 of a collection of IPsec SAs between the home agent and mobile node
 to secure the signaling traffic for Mobile IP, and, optionally, also
 to secure data traffic.  The security of an IPsec SA required by the
 relevant 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 node.  If other parties
 are involved in establishing the SA (through key distribution, for
 example) the process should follow the constraints designed to
 provide equivalent security.

Patel & Giaretta Informational [Page 17] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

 RFC 3775 also requires a trust relationship, as defined in Section
 1.3, between the mobile node and its home agent(s).  This is
 necessary, for instance, to ensure that fraudulent mobile nodes that
 attempt to flood other mobile nodes with traffic be not only shut off
 but tracked down.  An infrastructureless relationship as defined in
 Section 1.3 does not satisfy this requirement.  Any bootstrapping
 solution must include a trust relationship between mobile node and
 mobility service provider.  Solutions that depend on an
 infrastructureless relationship are out of scope for bootstrapping.
 Another requirement is that a home address be authorized to one
 specific host at a time.  RFC 3775 requires this so that misbehaving
 mobile nodes can be shut down.  This implies that, in addition to the
 IPsec SA, the home agent must somehow authorize the mobile node for a
 home address.  The authorization can be either implicit (for example,
 as a side effect of the authentication for mobility service) or
 explicit.  The authorization can either be done at the time the SA is
 created or be dynamically managed through a first come, first served
 allocation policy.

9.2. Threats to the Bootstrapping Process

 Various attacks are possible on the bootstrapping process itself.
 These attacks can compromise the process such that the RFC 3775
 requirements for Mobile IP security are not met, or they can serve
 simply to disrupt the process such that bootstrapping cannot be
 completed.  Here are some possible attacks:
 o  An attacking network entity purporting to offer the mobile node a
    legitimate home agent address or bootstrapping 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 node's traffic
    or otherwise disrupt the mobile node's mobility service.
 o  An attacking mobile node may attempt to steal mobility service by
    offering up fake credentials to a bootstrapping network entity or
    otherwise disrupting the home agent's ability to offer mobility
    service.
 o  A man in the middle on the link between the mobile node 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 [RFC3748] and [AAA-EAP-LLA] for further
    information.

Patel & Giaretta Informational [Page 18] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

 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, to be
 separately named, and to have separate lifetimes.  This needs to be
 achieved even though the keys are generated from the same
 authentication credentials.  This is necessary because a mobile node
 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; the need for replacement of algorithms when attacks
 become possible must also be considered in the design.

10. Contributors

 This contribution is a joint effort of the problem statement design
 team of the Mobile IPv6 WG.  The contributors include Basavaraj
 Patil, Gerardo Giaretta, Jari Arkko, James Kempf, Yoshihiro Ohba,
 Ryuji Wakikawa, Hiroyuki Ohnishi, Mayumi Yanagiya Samita Chakrabarti,
 Gopal Dommety, Kent Leung, Alper Yegin, Hannes Tschofenig, Vijay
 Devarapalli, and Kuntal Chowdury.
 The design team members can be reached at the following email
 addresses:
 Basavaraj Patil: basavaraj.patil@nokia.com
 Gerardo Giaretta: gerardo.giaretta@telecomitalia.it
 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

Patel & Giaretta Informational [Page 19] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

 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 Chowdhury: kchowdhury@starentnetworks.com

11. Acknowledgements

 Special thanks to James Kempf and Jari Arkko for writing the initial
 version of the bootstrapping statement.  Thanks to John Loughney and
 T.J. Kniveton for their detailed reviews.

12. Informative References

 [RFC3748]     Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
               H. Levkowetz, "Extensible Authentication Protocol
               (EAP)", RFC 3748, June 2004.
 [AAA-EAP-LLA] Mariblanca, D., "EAP lower layer attributes for AAA
               protocols", Work in Progress, May 2004.
 [RFC2794]     Calhoun, P. and C. Perkins, "Mobile IP Network Access
               Identifier Extension for IPv4", RFC 2794, March 2000.
 [RFC3041]     Narten, T. and R. Draves, "Privacy Extensions for
               Stateless Address Autoconfiguration in IPv6", RFC 3041,
               January 2001.
 [RFC3753]     Manner, J. and M. Kojo, "Mobility Related Terminology",
               RFC 3753, June 2004.
 [RFC3775]     Johnson, D., Perkins, C., and J. Arkko, "Mobility
               Support in IPv6", RFC 3775, June 2004.
 [RFC3776]     Galvin, J., "IAB and IESG Selection, Confirmation, and
               Recall Process: Operation of the Nominating and Recall
               Committees", BCP 10, RFC 3777, June 2004.
 [RFC4283]     Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
               Chowdhury, "Mobile Node Identifier Option for Mobile
               IPv6 (MIPv6)", RFC 4283, November 2005.

Patel & Giaretta Informational [Page 20] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

 [RFC4285]     Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
               Chowdhury, "Authentication Protocol for Mobile IPv6",
               RFC 4285, January 2006.

Authors' Addresses

 Alpesh Patel
 Cisco
 170 W. Tasman Drive
 San Jose, CA  95134
 USA
 Phone: +1 408 853 9580
 EMail: alpesh@cisco.com
 Gerardo Giaretta
 Telecom Italia
 via Reiss Romoli 274
 Torino  10148
 Italy
 Phone: +39 011 228 6904
 EMail: gerardo.giaretta@telecomitalia.it

Patel & Giaretta Informational [Page 21] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

Patel & Giaretta Informational [Page 22]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4640.txt · Last modified: 2006/09/20 22:34 (external edit)