RFC 4640

Problem Statement for bootstrapping Mobile IPv6 (MIPv6)

📅 published September 2006, from ietf

RFC 4640: Problem Statement for Bootstrapping Mobile IPv6 (MIPv6) 🎀

okay bestie, let's get into this one 🧚 it's from the Network Working Group and the title block has the important stuff:

  • Authors: A. Patel, Ed. (Cisco) and G. Giaretta, Ed. (Telecom Italia) 💖
  • Category: Informational 🌸
  • Date: September 2006 📅
  • Obsoletes / Updates: nothing is listed in the title block, so it doesn't obsolete or update any other document 🫶

Status of This Memo ✨

this one is giving "just here to share info" energy 💅 It gives information to the Internet community and does not specify an Internet standard of any kind. Distribution is unlimited, so share away 🦋

Copyright (C) The Internet Society (2006).

Abstract 🌸

okay so a mobile node needs three things to register with its home agent: a home address, a home agent address, and a security association with that home agent 🔥 Getting those three things is called bootstrapping. This doc looks at the issues around bootstrapping a mobile node for Mobile IPv6 (MIPv6) and at the different ways it could be deployed 💜

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 ✨

okay so Mobile IPv6 [RFC3775] is built on the idea that a mobile node (MN) has a trust relationship with an entity called the home agent 💖 Once the mobile node has learned the home agent address (through manual configuration, anycast discovery, or a DNS lookup, for example), the Mobile IPv6 signaling between the two gets secured with IPsec or with the authentication protocol from [RFC4285]. The requirements for that security setup come from [RFC3775], and the details of how it works are in [RFC3776] 🔥

here's the catch: [RFC3775] kinda assumes the MN already has enough info to register with its home agent successfully 🙈 Having that info manually pre-loaded causes real deployment headaches.

this document defines the bootstrapping problem 💅 Bootstrapping is the process of getting enough information onto the mobile node that it can successfully register with an appropriate home agent.

the requirements for bootstrapping could cover lots of different scenarios and deployment issues 🌸 The basic assumption here is that some minimal parameters (called seed information) are available to the mobile node to help it bootstrap. The exact seed information depends on the deployment scenario. This document walks through several deployment scenarios and lists the minimal parameters available in each one 🦋

this doc stops short of recommending preferred solutions for how the mobile node should get its information. Those details will show up in 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 come from an anycast address), and a security association with a home agent (or with several home agents) 💜

relying on that static provisioning causes various problems, which are covered in Section 5 🙈

the aim of this document is:

  • To define bootstrapping 💖
  • 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 🌸
  • To identify the minimal set of information required on the Mobile Node and in the network so that the mobile node can obtain address and security credentials and register with the home agent 🔥

1.2. Bootstrapping 🌈

bootstrapping means getting enough info onto the mobile node that it can register successfully with an appropriate home agent ✨ Specifically, that means getting the home agent address and home address, and letting the mobile node and home agent authenticate each other and mutually build security credentials for Mobile IPv6 🦋

bootstrapping usually happens when a mobile node doesn't have everything it needs to set up the Mobile IPv6 service 💅 That includes (but isn't limited to) situations where the mobile node has no info when it first boots up (out of the box), or where it doesn't keep any info across reboots 🙈

also, in some scenarios, what happens after the MN bootstraps for the very first time (out of the box) is up to the implementation 🧚 For example, the MN might bootstrap every time it boots, bootstrap every time its prefix changes, 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] 💖 These additional terms are used here:

Trust relationship 🌸

In this doc, a trust relationship means the two parties (usually the user of the mobile host and the mobility or access service authorizer) had some prior contact where the mobile node was given credentials 🔥 Those credentials let the mobile node authenticate itself to the mobility or access service provider and prove it's authorized to get service.

Infrastructureless relationship 🦋

In this doc, an infrastructureless relationship is one where the user of the mobile node and the mobility or access service provider have no previous contact, and the mobile node isn't required to supply credentials to authenticate or prove authorization for service 💅 Mobility and/or network access service is provided with no authentication or authorization at all. "Infrastructureless" here doesn't mean there's no network infrastructure, like you'd have in an ad hoc network 🙈

Credentials 🎀

data a mobile node uses to authenticate itself to a mobility or access network service authorizer and prove it's authorized to receive service ✨ Some examples are user name/passwords, one time password cards, public/private key pairs with certificates, and biometric information.

ASA 💜

Access Service Authorizer 💖 a network operator that authenticates a mobile node and establishes its 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 also 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 also provide mobility service (note this is a slightly different definition from the one 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. To get that service, the mobile node has to be authenticated and prove it's authorized.

Home Mobility Service Provider 🎀

an MSP that both provides mobility service and authorizes it ✨

Serving Mobility Service Provider 💅

an MSP that provides mobility service but depends on another service provider to authorize it 💜

2. Assumptions 🔥

  • a basic assumption in Mobile IPv6 [RFC3775] is that there's 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 to verify the trust relationship is with authentication, authorization, and accounting (AAA) infrastructure 🦋 This doc considers two distinct uses of AAA:

  • AAA for Network Access 🌈 This provides authentication and authorization to access the network (obtain an address and send/receive packets).
  • AAA for Mobility Service ✨ This provides authentication and authorization for mobility services.

these functions might live in a single entity or in different entities, depending on the service models in Section 6 or the deployment scenarios in Section 7 💅

  • some identifier, such as a Network Access Identifier (NAI) defined in [RFC4283] or [RFC2794], is provisioned on the MN so it can identify itself to the ASP and MSP 🙈

3. Design Goals ✨

okay so this section is basically the wishlist for fixing bootstrapping 🎀 and it is GIVING organized. here's what a good solution needs to hit:

  • The following information MUST be available at the end of bootstrapping, so the MN can register with the HA 💖:
    • the MN's home agent address
    • the MN's home address
    • an IPsec Security Association (SA) between the MN and the HA, plus an Internet Key Exchange Protocol (IKE) pre-shared secret between the MN and the HA 🔐
  • The bootstrapping procedure can be triggered at any time, either by the MN or by the network 🦋. It can happen because of administrative action, information going stale, or the HA indicating the MN. Bootstrapping MAY be started even when the MN is already registered with the HA and has all the required credentials, which is super typical for refreshing or renewing those credentials 🔄.
  • Later protocol interaction (like updating the IPsec SA) can happen between the MN and the HA directly, without involving the infrastructure that was used during bootstrapping 🫶.
  • Solutions to the bootstrapping problem SHOULD enable storage of user-specific information on entities other than the home agent 🌸.
  • Solutions to the bootstrapping problem SHOULD NOT exclude storage of user-specific information on entities other than the home agent 💅.
  • Configuration information exchanged between the mobile node and the home agent MUST be secured using integrity and replay protection. Confidentiality protection SHOULD be provided if necessary 🔒.
  • The solution SHOULD be applicable to all feasible deployment scenarios that can be envisaged, along with the relevant authentication/authorization models 🌈.

4. Non-goals 🙈

these are the things that are clearly OUT of scope for bootstrapping, so don't go trying to solve them here, bestie 💀:

  • Home prefix renumbering is not explicitly supported as part of bootstrapping. BUT if the MN runs the bootstrap procedures every time it powers on (instead of caching state from a previous bootstrap), then home network renumbering gets handled automatically ✨.
  • Bootstrapping in the absence of a trust relationship between the 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 super tight binding to the home addresses and home agent addresses. it's giving clingy 🫠.

in this section we talk about the problems caused by that tight binding to home addresses and home agent addresses 🔍.

5.1.1. Dynamic Home Address Assignment 🎀

right now the home agent uses the mobile node's home address for authorization. with manual keying, this happens through the security policy database, which says a certain security association may ONLY be used for one specific home address. with dynamic keying, the home agent makes sure the IKE Phase 1 identity is authorized to request security associations for the given home address 🔑.

here's the tea: Mobile IPv6 uses IKEv1, which can't update the security policy database according to a dynamically assigned home address 💀. so static home address assignment is really the only home address configuration technique that works with the base specification. not ideal, bestie 😭.

BUT dynamic home address assignment would still be desirable, for these reasons 👑:

  • 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 having one of the mobile nodes change 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 only let you use such addresses from the visited network 😤. so these addresses can't be used for communications lasting longer than the attachment to a particular visited network 🥲.
  • Ease of deployment. to simplify deployment of Mobile IPv6, it's desirable to free users and administrators from allocating home addresses and specifying them in the security policy database. this matches the general IPv6 design goal of using autoconfiguration wherever possible ✨.
  • Prefix changes in the home network. the Mobile IPv6 specification supports a mobile node autoconfiguring a home address based on its discovery of prefix information on the home subnet [RFC3775]. autoconfiguration during network renumbering is done by replacing the existing network prefix with the new one 🔁.

so then the MN needs to update the mobility binding in the HA to register the newly configured Home Address. but the MN may NOT be able to register that new address with the HA if a security association related to the reconfigured Home Address doesn't 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 🦋

right now the address of the home agent is specified in the security policy database. supporting multiple home agents means configuring multiple security policy database entries 📝.

still, dynamic home agent assignment would be desirable, for these reasons 💜:

  • Home agent discovery. the Mobile IPv6 specification supports a mobile node autoconfiguring a home agent address based on a discovery protocol [RFC3775] 🔍.
  • Independent network management. an MSP may want to assign home agents dynamically in different subnets. for instance, it shouldn't require that a roaming mobile node have a fixed home subnet 🌍.
  • Local home agents. the mobile node's MSP may want to let the serving MSP assign a local home agent for the mobile node. this is useful for communications efficiency and has also been mentioned as one approach to support location privacy 🕵️‍♀️.
  • Ease of deployment. to simplify deployment of Mobile IPv6, it's desirable to free users and administrators from allocating home agent addresses in a static manner. plus, an MSP may want a dynamic home agent assignment mechanism to load balance users among home agents on different links ⚖️.

5.1.3. "Opportunistic" or "Local" Discovery 🕵️

the home agent discovery protocol does NOT support "opportunistic" or local discovery mechanisms in an ASP's local access network 🙅‍♀️. it's expected that the mobile node must know the prefix of the home subnet to be able to discover a home agent. it has to either get that info through prefix update or have it statically configured 😵.

a more typical pattern for inter-domain service discovery on the Internet is that the client (the 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's 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 can't 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 aren't easily supported by traditional AAA infrastructures 🙃. where a traditional AAA infrastructure is used, the home agent can't leverage authentication and authorization information established between the mobile node, the foreign AAA server, and the home AAA server. that would be desirable when the mobile node gains access to the foreign network, so the home agent can 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 the home agent doesn't know where to send accounting records at the right 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 used, but IKEv1 doesn't support exchanging full AAA credentials with the mobile node. it's worth noting that IKEv2 DOES provide 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 reality, many, if not most, mobile devices will be in a low power "dormant mode" to save battery, or even be switched off, so they'll 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 (where 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, which reduces the utility of the protocol 😬.

bootstrapping does NOT explicitly try to solve this problem of home network renumbering when the MN is in dormant mode 🙅. but if the MN can configure itself after it "comes back on" by reinitiating the bootstrapping process, then the network renumbering problem gets fixed as a side effect 🎉✨.

6. Network Access and Mobility Services 🌸

okay bestie, this section sets up some terms for authentication and real-world network deployment and roaming 🫶 it lays the groundwork for Section 7. the focus is on the 'service' model because, at the end of the day, it's the provider giving 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 lets a host 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 be, for example, a commercial ASP, the IT department of an enterprise network, or the maintainer of a home (residential) network 🏡

If the mobile node isn't directly usable for communication at the current location of the MN, where 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 that happens before the mobile node gets 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 lets an IPv6 host keep its reachability even while 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 let a host get network access in areas where its home network access provider has no coverage 🗺️ In the case of mobility service, this lets a roaming mobile node get mobility service in the local operator's network while having that service authorized by the home operator 👑 The service model also lets mobility service and network access service be provided by different entities. This means a network operator with no wireless access, such as an enterprise network operator, can deploy a Mobile IPv6 home agent for mobility service while the actual wireless network access is provided by the serving network access providers it has a contract with 💼 Here are some other possible combinations of ASPs and MSPs:

  • The serving ASP might be the home ASP. Similarly, the serving MSP might be the home MSP.
  • 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.
  • The serving ASP and the serving MSP may be the same operator, or not.
  • 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 🌷

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 different 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's a trust relationship between the 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:

  • AAA authentication is mandatory for network access.
  • AAA authentication is not part of network access.

The seed information is described further in Section 8 ✨

7.1. Mobility Service Subscription Scenario

Lots of 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 ASP may be different from the MSP, and it may not have any pre-established trust relationship with it 💅

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 the 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, for instance a corporation), 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're dealing with trustworthy peers 🛡️

This arrangement is similar to the visited-home operator roaming arrangement for network access 🌸

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 an infrastructure-less environment for MIPv6 bootstrapping is the IETF network at IETF meetings 🍓 It's possible that there could be MIP6 service available on this network (i.e., a MIPv6 HA). However, there's 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 ✨

okay so this is the list of parameters that act as the seed for the bootstrapping procedure 🌱 which ones you need depends 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, then network access auth is independent of mobility services auth 🫶

  • 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 can be derived in a bunch of ways, like (but not limited to) static configuration, using the domain name from the network access NAI (even if AAA for network access isn't otherwise used), or using the domain name of the serving ASP, where that 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 doesn't 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 that case, the IKE credentials include the credentials used between the mobile node and the other entity. and if an AAA protocol is used for 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 💜

  • Parameter Set 2

in this case there's some dependency between authentication for network access and authentication for mobility services, because a security association that gets established as a result of network access auth is re-used for mobility services auth 🌸

all the required info, including IKE credentials, gets bootstrapped from this one 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 🔐

okay this section is serious but make it cute 💖 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.

the two are related, btw. if the bootstrapping process gets compromised, the level of security RFC 3775 requires may not be achieved 😭

the following two sections dig into these issues ✨

9.1. Security Requirements of Mobile IPv6

the Mobile IPv6 spec 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 while the SA is being set up through bootstrapping must be done in a way where authenticity is proved and confidentiality is ensured. also, generating any keying material or other cryptographic material for the SA must be done so that the probability of compromise after the SA is in place is minimized. the best way to minimize that probability is to have the cryptographic material known or calculable only by the two end nodes that share the SA, which here means 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 🧠

RFC 3775 also requires a trust relationship, as defined in Section 1.3, between the mobile node and its home agent(s). this is needed, for instance, so that fraudulent mobile nodes that try to flood other mobile nodes with traffic aren't just 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. it 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

okay the bootstrapping process itself has some attacks it can face 😬 these attacks can compromise the process so the RFC 3775 requirements for Mobile IP security aren't met, or they can just disrupt the process so bootstrapping can't be completed. here are some possible attacks:

  • 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. 💀
  • 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. 🥸
  • 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. 👀
  • 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 things that matter for a good security design 🧁 since mobility and network access authentication are separate services, keys generated for these services need to be cryptographically separate, separately named, and have separate lifetimes. this has to be achieved even though the keys come from the same authentication credentials 🔑 it's 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 to handle the super varied deployment needs. and the need to replace 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 these 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

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 also 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.
  • [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

Okay, copyright time 🎀 The Internet Society (2006) owns the copyright on this one. It's subject to the rights, licenses and restrictions in BCP 78, and apart from what that says, the authors keep all their rights 💅

The document and the info in it come "AS IS" 😭 The contributor, the organization they represent or are sponsored by (if any), the Internet Society and the IETF all disclaim every warranty, express or implied. That includes any warranty that using the info won't infringe anyone's rights, and any implied warranty of merchantability or fitness for a particular purpose.

Intellectual Property 🦋

The IETF doesn't take a side on whether any Intellectual Property Rights (or other rights someone might claim) are valid, how far they reach, or whether a license for them is even available. It also hasn't made any independent effort to find out what rights exist, so no promises there 🙈 If you want the rules on rights in RFC documents, check out BCP 78 and BCP 79 📚

Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that might be available, and the results of any attempt to get a general license or permission to use those proprietary rights for implementers or users of this spec can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🔍

The IETF also invites anyone who knows about copyrights, patents, patent applications or other proprietary rights that might cover technology needed to implement this standard to let them know. Send that info to the IETF at ietf-ipr@ietf.org 📬✨

Acknowledgement 🌸

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 🫶

📦 where this page comes from