idnits 2.17.1 draft-ietf-mip6-bootstrap-ps-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 853. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 830. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 837. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 843. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 859), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 24 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 13, 2004) is 7107 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 768, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 784, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 788, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 807, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-mobility-terminology (ref. '4') == Outdated reference: A later version (-04) exists of draft-giaretta-mip6-authorization-eap-00 == Outdated reference: A later version (-01) exists of draft-mariblanca-aaa-eap-lla-00 == Outdated reference: A later version (-01) exists of draft-yegin-mip6-aaa-fwk-00 Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Alpesh. Patel, (Editor) 3 Internet-Draft cisco Systems 4 Expires: April 13, 2005 October 13, 2004 6 Problem Statement for bootstrapping Mobile IPv6 7 draft-ietf-mip6-bootstrap-ps-01 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 13, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 A mobile node needs home address, home agent address and security 41 association with home agent to register with the home agent. The 42 process of obtaining this information is called bootstrapping. This 43 document defines the problem for how the mobile can be bootstrapped 44 in various deployment scenarios. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1 Overview of the Problem . . . . . . . . . . . . . . . . . 3 50 1.2 What is Bootstrapping? . . . . . . . . . . . . . . . . . . 4 51 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 5. Motivation for bootstrapping . . . . . . . . . . . . . . . . . 9 56 5.1 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 9 57 5.1.1 Dynamic Home Address Assignment . . . . . . . . . . . 9 58 5.1.2 Dynamic Home Agent Assignment . . . . . . . . . . . . 10 59 5.1.3 Management requirements . . . . . . . . . . . . . . . 11 60 5.2 Security Infrastructure . . . . . . . . . . . . . . . . . 11 61 5.2.1 Integration with AAA Infrastructure . . . . . . . . . 11 62 5.2.2 Opportunistic or Local Discovery . . . . . . . . . . . 12 63 5.3 Topology Change . . . . . . . . . . . . . . . . . . . . . 12 64 5.3.1 Dormant Mode Mobile Nodes . . . . . . . . . . . . . . 12 65 6. Network Access and Mobility services . . . . . . . . . . . . . 13 66 7. Deployment scenarios . . . . . . . . . . . . . . . . . . . . . 15 67 7.1 Mobility Service Subscription Scenario . . . . . . . . . . 15 68 7.2 Integrated ASP network scenario . . . . . . . . . . . . . 15 69 7.3 Third party MSP scenario . . . . . . . . . . . . . . . . . 16 70 7.4 Infrastructure-less scenario . . . . . . . . . . . . . . . 17 71 8. Parameters for authentication . . . . . . . . . . . . . . . . 18 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 73 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 74 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 76 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 77 12.2 Informative References . . . . . . . . . . . . . . . . . . . 24 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 25 79 Intellectual Property and Copyright Statements . . . . . . . . 26 81 1. Introduction 83 Mobile IPv6 [2] specifies mobility support based on the assumption 84 that a mobile node has a trust relationship with an entity called the 85 home agent. Once the home agent address has been learned either via 86 manual configuration or via anycast discovery mechanisms, Mobile IPv6 87 signaling messages between the mobile node and the home agent are 88 secured with IPsec. The requirements for this security architecture 89 are created with [2] and the details of this procedure are described 90 in [3]. 92 In [2] there is an implicit requirement that the MN be provisioned 93 with enough information that will permit it to register successfully 94 with its home agent. The requirement to have this information 95 statically provisioned creates practical deployment issues. 97 This document serves to define the problem of bootstrapping. 98 Bootstrapping is defined as obtaining enough information at the 99 mobile node, so that the mobile node can successfully register with 100 an appropriate home agent. 102 The requirements for bootstrapping could consider various scenarios/ 103 network deployment issues. It is the basic assumption of this 104 document that certain minimal parameters (seed information) is 105 available to the mobile node to aid in bootstrapping. The exact seed 106 information available differs depending on the deployment scenario. 107 This document defines/describes various deployment scenarios and 108 provides for a set of minimal parameters that are available in each 109 deployment scenario. 111 This document stops short of suggesting the various solutions to 112 obtaining information on the mobile node. Such details will be 113 available from separate documents. 115 1.1 Overview of the Problem 117 Mobile IPv6 [2] expects the mobile node to have a static home 118 address, home agent address (or anycast address and do dynamic home 119 agent discovery of Home Agent using ICMP messages) and a security 120 association with a home agent (multiple home agents on the home 121 network if dynamic home agent discovery is in use and multiple home 122 agents are deployed.) 124 This static provisioning of information has various problems as 125 discussed in Section 5. 127 The aim of this draft is to: 129 o Define bootstrapping. 130 o Identify sample deployment scenarios where MIPv6 will be deployed, 131 taking into account the relationship between the subscriber and 132 the service provider. 133 o Identify the minimal set of information required on the Mobile 134 Node (and/or) in the network in order for the the mobile node to 135 obtain address and security credentials, to register with the home 136 agent. 138 1.2 What is Bootstrapping? 140 Bootstrapping is defined as obtaining enough information at the 141 mobile node, so that the mobile node can successfully register with 142 an appropriate home agent. Specifically, this means obtaining the 143 home agent address, home address and security credentials for the 144 mobile node and home agent to authenticate and mutually construct 145 security credentials for Mobile IPv6 without requiring 146 preconfiguration. 148 Typically, bootstrapping happens when a mobile node does not have all 149 the information it needs to setup Mobile IPv6 service. This 150 includes, but is not limited to MN not having any information when it 151 boots up for the first time (out of the box), it does not retain any 152 information during reboots, is instructed by the Home Agent (via some 153 form of signalling) to do so etc. 155 Also, in certain scenarios, after the MN bootstraps for the first 156 time (out of the box), subsequent bootstrapping is implementation 157 dependent. For instance, MN may bootstrap everytime it boots, 158 bootstrap everytime on prefix change, bootstrap periodically to 159 anchor to an optimal (distance, load etc) HA, etc. 161 1.3 Terminology 163 For a complete introduction to terminology, please refer to [4]. 165 General mobility terminology can be found in [4]. The following 166 additional terms are used here: 168 ASP 169 Access Service Provider. A network operator that provides direct 170 IP packet forwarding to and from the end host. 172 IASP 173 Integrated Access Service Provider. A service provider providing 174 both network access and mobility. Referred to as IASP or ASP/MSP 175 in the document. 177 MSP 178 Mobility Service Provider. A service provider that provides 179 Mobile IPv6 service. Granting such service requires 180 authentication. 182 2. Assumptions 184 o A basic assumption in the Mobile IPv6 RFC [2] is that there is a 185 trust relationship between the mobile node and MSP. This trust 186 relationship can be direct, or indirect through, for instance, an 187 ASP that has a contract with the MSP. This trust relationship can 188 be used to bootstrap the MN. 190 One typical way of verifying the trust relationship is using 191 authentication, authorization, and accounting (AAA). In this 192 document, two distinct types of AAA are considered: 194 AAA for Network Access 195 This functionality provides authentication and authorization to 196 access the network (obtain an address and send/receive 197 packets). 199 AAA for Mobility Service 200 This functionality provides authentication and authorization 201 for mobility services. 203 These functionalities may be implemented in a single entity or in 204 different entities, depending on the service models described in 205 Section 6 or deployment scenarios as described in Section 7. 207 o Yet another assumption is that some identifier, such as NAI, as 208 defined in [7] or [8] is provisioned on the MN which permits the 209 MN to identify itself to the ASP and MSP. 211 3. Design Goals 213 A solution to the bootstrapping problem has the following design 214 goals: 216 o The following information must be available at the end of 217 bootstrapping, to enable the MN to register with the HA. 219 * MN's home address 220 * MN's home agent address 221 * IPsec SA between MN and HA or IKE pre-shared secret between MN 222 and HA. 223 o The bootstrapping procedure can be triggered at any time. 224 o Subsequent protocol interaction (for example updating the IPsec 225 SA) can be executed between the MN and the HA itself without 226 involving the infrastructure that was used during bootstrapping. 227 o Solutions to the bootstrapping problem should not exclude storage 228 of user-specific information on entities other than the home 229 agent. 230 o Configuration information which is exchanged between the mobile 231 node and the home agent must be secured using integrity and replay 232 protection. Confidentiality protection SHOULD be provided if 233 necessary. 234 o All feasible deployment scenarios, along with the relevant 235 authentication/authorization models must be considered. 237 4. Non-Goals 239 This following issues are clearly outside the scope of bootstrapping: 241 o Home prefix renumbering is not explicity supported as part of 242 bootstrapping. If the MN executes the bootstrap procedures 243 everytime it powers-on (as opposed to caching state information 244 from previous bootstrap process), then home network renumbering is 245 taken care of automatically. 247 o Bootstrapping in the absence of a trust relationship between MN 248 and any provider, is not considered. The reason for this is 249 described in Section 9. 251 5. Motivation for bootstrapping 253 5.1 Addressing 255 The default bootstrapping described in the Mobile IPv6 base 256 specification [2] has a tight binding to the home addresses and home 257 agent addresses. 259 In this section, we discuss the problems caused by the currently 260 tight binding to home addresses and home agent addresses. 262 5.1.1 Dynamic Home Address Assignment 264 While it is possible for the home address to be dynamically assigned, 265 the HA cannot verify that the MN is authorized to use a particular 266 address. As a result, static home address assignment is really the 267 only home address configuration technique compatible with the current 268 specification. 270 However, support for dynamic home address assignment would be 271 desirable for the following reasons: 273 DHCP-based address assignment 275 Some ASPs may want to use DHCPv6 from the home network to 276 configure home addresses. 278 Recovery from a duplicate address collision 280 It may be necessary to recover from a collision of addresses on 281 the home network. 283 Addressing privacy 285 It may be desirable to establish randomly generated addresses as 286 in RFC 3041 and use them for a short period of time. 287 Unfortunately, current protocols make it possible to use such 288 addresses only from the visited network. As a result, these 289 addresses can not be used for communications lasting longer than 290 the attachment to a particular visited network. 292 Ease of deployment 294 In order to make deployment of Mobile IPv6 easy, it would be 295 desirable to free users and administrators from the task of 296 allocating home addresses and specifying them in the security 297 policy database. 299 This is consistent with the general IPv6 design goal of using 300 autoconfiguration whereever possible. 302 Prefix changes in the home network 304 The Mobile IPv6 specification contains support for a mobile node 305 to autoconfigure a home address based on its discovery of prefix 306 information on the home subnet [2]. Autoconfiguration in case of 307 network renumbering is done by replacing the existing network 308 prefix with the new network prefix. 310 Subsequently, the MN needs to update the mobility binding in the 311 HA to register the newly configured Home Address. However, the MN 312 may not be able to register the newly configured address with the 313 HA if a security association related to that reconfigured Home 314 Address does not exist in the MN and the HA. This situation is 315 not handled in the current MIPv6 specification [2]. 317 5.1.2 Dynamic Home Agent Assignment 319 Currently, the address of the home agent is specified in the security 320 policy database. Support for multiple home agents requires the 321 configuration of multiple security policy database entries. 323 However, support for dynamic home agent assignment would be desirable 324 for the following reasons: 326 Home agent discovery 328 The Mobile IPv6 specification contains support for a mobile node 329 to autoconfigure a home agent address based on a discovery 330 protocol [2]. 332 Independent network management 334 An ASP may want to dynamically assign home agents in different 335 subnets, that is, not require that a roaming mobile node have a 336 fixed home subnet. 338 Local home agents 340 The mobile node's home ASP may want to allow a local roaming 341 partner ASP to assign a local home agent for the mobile node. 342 This is useful both from the point of view of communications 343 efficiency, and has also been mentioned as one approach to support 344 location privacy. 346 Ease of deployment 348 MSP may want to allow "opportunistic" discovery and utilization of 349 its mobility services without any prearranged contact. These 350 scenarios will require dynamic home address assignment. 352 5.1.3 Management requirements 354 As described earlier, new addresses invalidate configured security 355 policy databases and authorization tables. Regardless of the 356 specific protocols used, there is a need for either an automatic 357 system for updating the security policy entries, or manual 358 configuration. These requirements apply to both home agents and 359 mobile nodes, but it can not be expected that mobile node users are 360 capable of performing the required tasks. 362 5.2 Security Infrastructure 364 5.2.1 Integration with AAA Infrastructure 366 The current IKEv1-based dynamic key exchange protocol described in 367 [3] has no integration with backend authentication, authorization and 368 accounting techniques unless the authentication credentials and trust 369 relationships use certificates or pre-shared secrets. 371 Using certificates may require the ASP to deploy a PKI, which may not 372 be possible or desirable in certain circumstances. Where a 373 traditional AAA infrastructure is used, the home agent is not able to 374 leverage authentication and authorization information established 375 between the mobile node, the foreign AAA server, and the home AAA 376 server when the mobile node gains access to the foreign network, in 377 order to authenticate the mobile node's identity and determine if the 378 mobile node is authorized for mobility service. 380 The lack of connection to the AAA infrastructure also means the home 381 agent does not know where to issue accounting records at appropriate 382 times during the mobile node's session, as determined by the business 383 relationship between the home ASP and the mobile node's owner. 385 Presumably, some backend AAA protocol between the home agent and home 386 AAA could be utilized, but IKEv1 does not contain support for 387 exchanging full AAA credentials with the mobile node. It is 388 worthwhile to note that IKEv2 provides this feature. 390 5.2.2 Opportunistic or Local Discovery 392 The home agent discovery protocol does not support an "opportunistic" 393 or local discovery mechanisms in an ASP's local access network. It 394 is expected that the mobile node must know the prefix of the home 395 subnet in order to be able to discover a home agent. It must either 396 obtain that information through prefix update or have it statically 397 configured. A more typical pattern for interdomain service discovery 398 in the Internet is that the client (mobile node in this case) knows 399 the domain name of the service, and uses DNS in some manner to find 400 the server in the other domain. For local service discovery, DHCP is 401 typically used. 403 5.3 Topology Change 405 5.3.1 Dormant Mode Mobile Nodes 407 The description of the protocol to push prefix information to mobile 408 nodes in Section 10.6 in [2] has an implicit assumption that the 409 mobile node is active and taking IP traffic. In fact, many, if not 410 most, mobile devices will be in a low power "dormant mode" to save 411 battery power, or even switched off, so they will miss any 412 propagation of prefix information. As a practical matter, if this 413 protocol is used, an ASP will need to keep the old prefix around and 414 handle any queries to the old home agent anycast address on the old 415 subnet, whereby the mobile node asks for a new home agent as 416 described in Section 11.4, until all mobile nodes are accounted for. 417 Even then, since some mobile nodes are likely to be turned off for 418 long periods, some owners would need to be contacted by other means, 419 reducing the utility of the protocol. 421 Bootstrapping does not explicitly try to solve this problem of home 422 network renumbering when MN is in dormant mode. If the MN can 423 configure itself after it 'comes back on' by reinitiating the 424 bootstrapping process, then network renumbering problem is fixed as a 425 side-effect. 427 6. Network Access and Mobility services 429 This section defines some terms as it pertains to authentication and 430 practical network deployment/roaming scenarios. This description 431 lays the ground work for Section 7. The focus is on the 'service' 432 model since, ultimately, it is the provider providing the service 433 that wants to authenticate the mobile (and vice-versa for mutual 434 authentication between provider and the user of the service). 436 Network access service enables a host to send and receive IP packets 437 on the Internet or an intranet. IP address configuration and IP 438 packet forwarding capabilities are required to deliver this service. 439 A network operator providing this service is called an access service 440 provider (ASP). An ASP can be a commercial ASP, the IT department of 441 an enterprise network, or the maintainer of a home (residential) 442 network. 444 When the network service requires authentication, the concept of home 445 ASP and serving ASP comes into the picture. Home ASP is the provider 446 with whom the user has an account. Therefore, when the user directly 447 connects to the home ASP network, the ASP can perform authentication 448 without relying on any other service provider. On the other hand, 449 when the user is roaming on the Internet, it may connect to another 450 ASP network that has a roaming agreement with the home ASP. That ASP 451 is called serving ASP. The serving ASP cannot authenticate a roaming 452 user on its own, for that it needs to contact the home ASP. 454 A host does not always have to use an IP address from one of its home 455 ASP prefixes. It may be configured with one from the serving ASP's 456 prefixes. In fact, the home ASP may not even have a physical access 457 network, in which case it could be identified as a virtual operator. 459 Another service is called Mobile IPv6 service, which enables a host 460 to maintain its IP reachability despite changing its network 461 attachment points (subnets). Providing Mobile IPv6 service involves 462 setting up a home agent on a subnet that acts as a Mobile IPv6 home 463 link. Home agent's responsibility include tunneling host's IP 464 packets between the home link and its current point-of attachment. A 465 network operator providing this service is called a mobility service 466 provider (MSP). Mobile IPv6 requires authentication between the host 467 and the home agent. The MSP that maintains an account for the user 468 is called a home MSP. A home MSP can authenticate its users without 469 relying on any other service provider. Conceptually, the user may be 470 receiving the Mobile IP service from another MSP that has a roaming 471 agreement with the home MSP. Such a service provider is called 472 serving MSP. A serving MSP needs to contact the home MSP in order to 473 authenticate the user before providing the mobility service. 475 A host may authenticate with a MSP based on the some kind of AAA 476 association with the ASP (typically the home ASP or through the home 477 ASP). 479 A host does not always have to use a Mobile IPv6 home address from 480 one of its home MSP prefixes. It may be configured with one from the 481 serving MSP's prefixes. In fact, the home MSP may not even have a 482 physical access network, in which case it could be identified as a 483 virtual operator. 485 Network access and Mobile IPv6 are two distinct services. A host can 486 choose to have only network access service, or both network access 487 and Mobile IPv6 services at the same time. Only having Mobile IPv6 488 service is not possible, since the Mobile IPv6 protocol requires 489 ability to send and receive IPv6 packets. Even when both services 490 are received by a host, the service providers involved might vary. 491 All combinations are possible with respect to the choice of ASPs and 492 MSPs: 494 o The serving ASP might be the home ASP. Similarly, the serving MSP 495 might be the home MSP. 496 o The home ASP and the home MSP may be the same operator, or not. 497 When they are the same, the same set of credentials may be used 498 for both services. 499 o The serving ASP and the serving MSP may be the same operator, or 500 not. 501 o It is possible that serving ASP and home MSP are the same 502 operator. 504 Similarly the home ASP and serving MSP may be the same. 506 These entities and possible combinations must be taken into 507 consideration when solving the Mobile IPv6 bootstraping problem. 508 They impact home agent discovery, home address configuration, and 509 mobile node to home agent authentication aspects. 511 7. Deployment scenarios 513 This section describes the various network deployment scenarios. The 514 various combinations of service providers as described in Section 6 515 are considered. 517 For each scenario, the underlying assumptions are described. The 518 basic assumption is that there is a trust relationship between mobile 519 user and the MSP. Typically, this trust relationship is between the 520 mobile user and AAA in the MSP network. Seed information needed to 521 bootstrap the mobile node is considered in two cases (i) AAA 522 authentication is mandatory for network access "&" (ii) AAA 523 authentication is not part of network access. The seed information 524 is described further in Section 8. 526 7.1 Mobility Service Subscription Scenario 528 Many commercial deployments are based on the assumption that mobile 529 nodes have a subscription with a service provider. In particular, in 530 this scenario the MN has a subscription with an MSP, called the home 531 MSP, for Mobile IPv6 service. As stated in Section 6, the MSP is 532 responsible of setting up a home agent on a subnet that acts as a 533 Mobile IPv6 home link. As a consequence, the home MSP should 534 explicitly authorize and control the whole bootstrapping procedure. 536 Since the MN is assumed to have a pre-established trust relationship 537 with its home provider, it must be configured with an identity and 538 credentials, for instance an NAI and a shared secret by some 539 out-of-band means before bootstrapping, for example by manual 540 configuration. 542 In order to guarantee ubiquitous service, the MN should be able to 543 bootstrap MIPv6 operations with its home MSP from any possible access 544 location, such as an open network or a network managed by an ASP, 545 that may be different from the MSP and may not have any 546 pre-established trust relationship with it. 548 7.2 Integrated ASP network scenario 550 In this scenario, the ASP and MSP are the same ASP. MN shares 551 security credentials for access to the network and these credentials 552 can be used to bootstrap MIPv6. This bootstrapping can be done 553 during the same phase as access authentication/authorization or at a 554 later time (probably based on some state created during access 555 authentication/authorization). 557 Figure 1 describes an example AAA design for integrated ASP scenario. 559 +----------------------------+ 560 | IASP(ASP+MSP) | 561 +----+ +-----+ +----+ | 562 | MN |--- | NAS | | HA | | 563 +----+ +-----+ +----+ | 564 | \ \ | 565 | \ +------+ \ +-------+ | 566 | -|AAA-NA| -|AAA-MIP| | 567 | +------+ +-------+ | 568 +----------------------------+ 570 NAS: Network Access Server 571 AAA-NA: AAA for network access 572 AAA-MIP: AAA for Mobile IP service 574 Figure 1: Integrated ASP network 576 7.3 Third party MSP scenario 578 Mobility service has traditionally been provided by the same entity 579 that authenticates and authorizes the subscriber for network access. 580 This is certainly the only model supported by the base Mobile IPv6 581 specification. 583 In the 3rd party mobility service provider scenario, the subscription 584 for mobility service is made with one entity (home MSP for instance a 585 corporate network), but the actual mobility service is provided by 586 yet another entity (such as an operator specializing on this service, 587 the serving MSP). These two entities have a trust relationship. 588 Transitive trust among the mobile node and these two entities may be 589 used to assure the participants that they are dealing with, are 590 trustworthy peers. 592 This arrangement is similar to the visited - home operator roaming 593 arrangement for network access. 595 Figure 2 describes an example network for third party MSP scenario. 597 +--------------+ +--------+ 598 | | |Serving | 599 | ASP | | MSP | 600 +----+ +-----+ | | +----+ | 601 | MN |--- | NAS | | | | HA | | +-------------------+ 602 +----+ +-----+ |===| +----+ | | Home MSP | 603 | \ | | \ | | (e.g.corporate NW)| 604 | \ +------+ | | \ | +-------+ | 605 | -|AAA-NA| | | -------|AAA-MIP| | 606 | +------+ | | | | +-------+ | 607 +------------ + +--------+ +-------------------+ 609 Figure 2: Third Party MSP network 611 7.4 Infrastructure-less scenario 613 Infrastructure refers to network entities like AAA, PKI, HLR etc. 614 Infrastructure-less implies that there is no dependency on any 615 elements in the network with which the user has any form of trust 616 relationship. 618 In such a scenario, there is absolutely no relationship between host 619 and infrastructure. 621 A good example of infrastructure-less environment for MIP6 622 bootstrapping is the IETF network at IETF meetings. It is possible 623 that there could be MIP6 service available on this network (i.e a 624 MIPv6 HA). However there is not really any AAA infrastructure or for 625 that matter any trust relationship that a user attending the meeting 626 has with any entity in the network. 628 This specific scenario is not supported in this document. The reason 629 for this is described in Section 9. 631 8. Parameters for authentication 633 The following is a list of parameters that are used as the seed for 634 the bootstrapping procedure. The parameters vary depending on 635 whether authentication for network access is independent of 636 authentication for mobility services or not. Authentication for 637 network access is always independent of authentication for mobility 638 services if different client identities are used for network access 639 and mobility services. 641 o Parameter Set 1 643 In this case, authentication for network access is independent of 644 authentication for mobility services. 646 If the home agent address is not known to the mobile node the 647 following parameter is needed for discovering the home agent 648 address: 650 * The domain name or FQDN of the home agent 652 This parameter may be derived in various ways such as (but not 653 limited to) static configuration, use of the domain name from the 654 network access NAI (even if AAA for network access is not 655 otherwise used) or use of the domain name of the serving ASP where 656 the domain name may be obtained via DHCP in the serving ASP. 658 If the home agent address is not known but the home subnet prefix 659 is known, Dynamic Home Agent Address Discovery of Mobile IPv6 may 660 be used for discovering the home agent address and the above 661 parameter may not be used. 663 When the home agent address is known to the mobile node, the 664 following parameter is needed for performing mutual authentication 665 between the mobile node and the home agent by using IKE: 667 * IKE credentials(*) 669 In the case where the home agent does not have the entire set of 670 IKE credentials, the home agent may communicate with another 671 entity (e.g., a AAA server) to perform mutual authentication in 672 IKE. In such a case, the IKE credentials include the credentials 673 used between the mobile node and the other entity. In the case 674 where a AAA protocol is used for the communication between the 675 home agent and the other entity during the IKE procedure, AAA for 676 Mobile IPv6 service may be involved in IKE. 678 o Parameter Set 2 680 In this case, some dependency exists between authentication for 681 network access and authentication for mobility services in that a 682 security association that is established as a result of 683 authentication for network access is re-used for authentication 684 for mobility services. 686 All required information including IKE credentials are 687 bootstrapped from the following parameter: 689 * Network access credentials(*) 691 (*) A pair of a NAI and a pre-shared secret is an example set of 692 credentials. A pair of an NAI and a public key, which may be 693 provided as a digital certificate, is another example set of 694 credentials. 696 9. Security Considerations 698 The bootstrapping procedure needs to create a security association 699 that matches the requirements set for its use. Mobile IPv6 base 700 specification expects strong, mutual authentication and trust 701 relationship between the mobile node and home agent. This is 702 necessary, for instance, to ensure that fraudulent mobile nodes that 703 flood other nodes with traffic [draft-ietf-mipv6-ro-sec] can not only 704 be shut off from the service, but also tracked down. The use of 705 infrastructureless techniques does not satisfy these requirements, at 706 least not without introducing additional routability tests to the 707 Mobile IPv6 home registration procedure. 709 Thus, the case of infrastructure-less network where there is 710 absolutely no pre-mediated trust is kept outside of scope of this 711 document. 713 Another requirement is that the "ownership" to a particular home 714 address must be authorized to at most one mobile node at a time. 715 This implies that a Mobile IPv6 security association is always tied 716 to zero or more such authorizations; these authorizations can either 717 be created at the time the security association is created, or 718 dynamically managed through, for instance, a First Come First Served 719 allocation policy. 721 Where an automatic bootstrap process is used, it becomes necessary to 722 associate a lifetime with all the parameters which are bootstrapped. 723 Otherwise a large number of unused security associations would have 724 to be stored by the participating nodes, either by accident or 725 through malicious behaviour or the mobile node will have stale 726 information. 728 The specific mean of verifying the security association is not 729 defined in this document, but it can be, for example a set of IKE 730 credentials, an IPsec security association, a username-password -like 731 association or digital signature constructed by a certified key. 733 The bootstrap process itself may have vulnerabilities. The following 734 issues need to be addressed: 736 o Mutual authentication and trust relationship between the mobile 737 node and the entity handling the bootstrap process. Refer to 738 Section 7.15 in [9] and [10] for further information. 739 o Cryptographic separation and naming of session keys used for 740 multiple purposes, such as network access authentication and 741 mobility service. 742 o Ensuring that key lifetimes are not exceeded. 744 o Binding security associations to specific home agent and address 745 allocations. 746 o Support of multiple algorithms for the resulting security 747 associations. 748 o Avoidance of denial-of-service vulnerabilities. 750 10. Contributors 752 This contribution is a joint effort of the problem statement design 753 team of the Mobile IPv6 WG. The contributors (alphabetical order) 754 include Jari Arkko, Samita Chakrabarti, Kuntal Chowdhury, Vijay 755 Devarapalli, Gopal Dommety, Gerardo Giaretta, James Kempf, Kent 756 Leung, Yoshihiro Ohba, Hiroyuki Ohnishi, Basavaraj Patil, Hannes 757 Tschofenig, Ryuji Wakikawa, Mayumi Yanagiya and Alper Yegin. 759 11. Acknowledgments 761 Special thanks to James Kempf and Jari Arkko for writing the initial 762 version of the bootstrapping statement. 764 12. References 766 12.1 Normative References 768 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 769 Levels", RFC 2119, March 1997. 771 [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 772 IPv6", RFC 3775, July 2003. 774 [3] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to 775 Protect Mobile IPv6 Signaling between Mobile Nodes and Home 776 Agents", RFC 3776, July 2003. 778 [4] Manner, J. and M. Kojo, "Mobility Related Terminology", 779 draft-ietf-seamoby-mobility-terminology-06 (work in progress), 780 February 2004. 782 12.2 Informative References 784 [5] Giaretta, G., "MIPv6 Authorization and Configuration based on 785 EAP", draft-giaretta-mip6-authorization-eap-00 (work in 786 progress), February 2004. 788 [6] Kempf, J. and J. Arkko, "The Mobile IPv6 Bootstrapping 789 Problem", draft-kempf-mip6-bootstrap-00 (work in progress), 790 March 2004. 792 [7] Patel, A., Leung, K., Akthar, H., Khalil, M. and K. Chowdhury, 793 "Network Access Identifier Option for Mobile IPv6", 794 draft-ietf-mip6-nai-option-00 (work in progress), February 795 2004. 797 [8] Calhoun, P. and C. Perkins, "Mobile IP Network Access 798 Identifier Extension for IPv4", RFC 2794, March 2000. 800 [9] Levkowetz, Ed., H., "Extensible Authentication Protocol (EAP)", 801 draft-ietf-eap-rfc2284bis-09 (work in progress), February 2004. 803 [10] Mariblanca, D., "EAP lower layer attributes for AAA protocols", 804 draft-mariblanca-aaa-eap-lla-00.txt (work in progress), May 805 2004. 807 [11] Yegin, A., "AAA Mobile IPv6 Application Framework", 808 draft-yegin-mip6-aaa-fwk-00 (work in progress), August 2004. 810 Author's Address 812 Alpesh Patel 813 cisco Systems 814 170 W. Tasman Drive 815 San Jose, CA 95134 816 USA 818 Phone: +1 408 853 9580 819 EMail: alpesh@cisco.com 821 Intellectual Property Statement 823 The IETF takes no position regarding the validity or scope of any 824 Intellectual Property Rights or other rights that might be claimed to 825 pertain to the implementation or use of the technology described in 826 this document or the extent to which any license under such rights 827 might or might not be available; nor does it represent that it has 828 made any independent effort to identify any such rights. Information 829 on the procedures with respect to rights in RFC documents can be 830 found in BCP 78 and BCP 79. 832 Copies of IPR disclosures made to the IETF Secretariat and any 833 assurances of licenses to be made available, or the result of an 834 attempt made to obtain a general license or permission for the use of 835 such proprietary rights by implementers or users of this 836 specification can be obtained from the IETF on-line IPR repository at 837 http://www.ietf.org/ipr. 839 The IETF invites any interested party to bring to its attention any 840 copyrights, patents or patent applications, or other proprietary 841 rights that may cover technology that may be required to implement 842 this standard. Please address the information to the IETF at 843 ietf-ipr@ietf.org. 845 Disclaimer of Validity 847 This document and the information contained herein are provided on an 848 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 849 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 850 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 851 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 852 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 853 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 855 Copyright Statement 857 Copyright (C) The Internet Society (2004). This document is subject 858 to the rights, licenses and restrictions contained in BCP 78, and 859 except as set forth therein, the authors retain all their rights. 861 Acknowledgment 863 Funding for the RFC Editor function is currently provided by the 864 Internet Society.