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