idnits 2.17.1 draft-ietf-mip6-bootstrapping-split-05.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 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1311. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1324. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (May 25, 2007) is 6181 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) ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4306 (ref. '7') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '13') (Obsoleted by RFC 4941) == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-02 -- Obsolete informational reference (is this intentional?): RFC 2845 (ref. '19') (Obsoleted by RFC 8945) == Outdated reference: A later version (-18) exists of draft-ietf-mip6-hiopt-02 -- Obsolete informational reference (is this intentional?): RFC 3280 (ref. '22') (Obsoleted by RFC 5280) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group G. Giaretta, Ed. 3 Internet-Draft Qualcomm 4 Intended status: Standards Track J. Kempf 5 Expires: November 26, 2007 DoCoMo Labs USA 6 V. Devarapalli 7 Azaire Networks 8 May 25, 2007 10 Mobile IPv6 bootstrapping in split scenario 11 draft-ietf-mip6-bootstrapping-split-05 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 26, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 A Mobile IPv6 node requires a Home Agent address, a home address, and 45 IPsec security associations with its Home Agent before it can start 46 utilizing Mobile IPv6 service. RFC 3775 requires that some or all of 47 these are statically configured. This document defines how a Mobile 48 IPv6 node can bootstrap this information from non-topological 49 information and security credentials preconfigured on the Mobile 50 Node. The solution defined in this document solves the Mobile IPv6 51 bootstrapping problem (RFC4640) when the Mobile Node's mobility 52 service is authorized by a different service provider than basic 53 network access, and is therefore generically applicable to any 54 bootstrapping case. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Split scenario . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Components of the solution . . . . . . . . . . . . . . . . . . 7 62 5. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 9 63 5.1. Home Agent Address Discovery . . . . . . . . . . . . . . . 9 64 5.1.1. DNS lookup by Home Agent Name . . . . . . . . . . . . 9 65 5.1.2. DNS lookup by service name . . . . . . . . . . . . . . 10 66 5.1.3. Anycast Address for Home Agent Assignment . . . . . . 11 67 5.2. IPsec Security Associations setup . . . . . . . . . . . . 11 68 5.2.1. IKEv2 Transaction with anycast Home Agent 69 assignment . . . . . . . . . . . . . . . . . . . . . . 12 70 5.3. Home Address assignment . . . . . . . . . . . . . . . . . 13 71 5.3.1. Home Address assignment by the Home Agent . . . . . . 13 72 5.3.2. Home Address auto-configuration by the Mobile Node . . 14 73 5.4. Authorization and Authentication with MSA . . . . . . . . 16 74 6. Home Address registration in the DNS . . . . . . . . . . . . . 16 75 7. Summary of Bootstrapping Protocol Flow . . . . . . . . . . . . 18 76 8. Option and Attribute Format . . . . . . . . . . . . . . . . . 19 77 8.1. DNS Update mobility option . . . . . . . . . . . . . . . . 19 78 8.2. MIP6_HOME_PREFIX attribute . . . . . . . . . . . . . . . . 21 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 80 9.1. HA Address Discovery . . . . . . . . . . . . . . . . . . . 22 81 9.2. Home Address Assignment through IKEv2 . . . . . . . . . . 24 82 9.3. SA Establishment Using EAP Through IKEv2 . . . . . . . . . 24 83 9.4. Back End Security Between the HA and AAA Server . . . . . 24 84 9.5. Dynamic DNS Update . . . . . . . . . . . . . . . . . . . . 25 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 86 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 87 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 13.1. Normative References . . . . . . . . . . . . . . . . . . . 27 90 13.2. Informative References . . . . . . . . . . . . . . . . . . 27 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 92 Intellectual Property and Copyright Statements . . . . . . . . . . 30 94 1. Introduction 96 Mobile IPv6 [1] requires the Mobile Node to know its Home Agent 97 Address, its own Home Address and the cryptographic materials (e.g. 98 shared keys or certificates) needed to set up IPsec security 99 associations with the Home Agent in order to protect Mobile IPv6 100 signaling. This is generally referred to as the Mobile IPv6 101 bootstrapping problem [8]. 103 Mobile IPv6 base protocol does not specify any method to 104 automatically acquire this information, which means that network 105 administrators are normally required to manually set configuration 106 data on Mobile Nodes and HAs. However, in real deployments, manual 107 configuration does not scale as the Mobile Nodes increase in number. 109 As discussed in [8], several bootstrapping scenarios can be 110 identified depending on the relationship between the network operator 111 that authenticates a mobile node for granting network access service 112 (Access Service Authorizer, ASA) and the service provider that 113 authorizes Mobile IPv6 service (Mobility Service Authorizer, MSA). 114 This document describes a solution to the bootstrapping problem that 115 is applicable in a scenario where the MSA and the ASA are different 116 entities (i.e. split scenario). 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [2]. 124 General mobility terminology can be found in [9]. The following 125 additional terms are used here: 127 Access Service Authorizer (ASA) 129 A network operator that authenticates a mobile node and 130 establishes the mobile node's authorization to receive Internet 131 service. 133 Access Service Provider (ASP) 135 A network operator that provides direct IP packet forwarding to 136 and from the end host. 138 Mobility Service Authorizer (MSA) 140 A service provider that authorizes Mobile IPv6 service. 142 Mobility Service Provider (MSP) 144 A service provider that provides Mobile IPv6 service. In order to 145 obtain such service, the mobile node must be authenticated and 146 prove authorization to obtain the service. 148 Split scenario 150 A scenario where mobility service and network access service are 151 authorized by different entities. This implies that MSA is 152 different from ASA. 154 3. Split scenario 156 In the problem statement description [8] there is a clear assumption 157 that mobility service and network access service can be separate. 158 This assumption implies that mobility service and network access 159 service may be authorized by different entities. As an example, the 160 service model defined in [8] allows an enterprise network to deploy a 161 Home Agent and offer Mobile IPv6 service to a user, even if the user 162 is accessing the Internet independent of its enterprise account 163 (e.g., by using his personal WiFi hotspot account at a coffee shop). 165 Therefore, in this document it is assumed that network access and 166 mobility service are authorized by different entities, which means 167 that authentication and authorization for mobility service and 168 network access will be considered separately. This scenario is 169 called split scenario. 171 Moreover, the model defined in [8] separates the entity providing the 172 service from the entity that authenticates and authorizes the user. 173 This is similar to the roaming model for network access. Therefore, 174 in the split scenario, two different cases can be identified 175 depending on the relationship between the entity that provides the 176 mobility service (i.e. Mobility Service Provider, MSP) and the 177 entity that authenticates and authorizes the user (i.e. Mobility 178 Service Authorizer, MSA). 180 Figure 1 depicts the split scenario when the MSP and the MSA are the 181 same entity. This means that the network operator that provides the 182 Home Agent authenticates and authorizes the user for mobility 183 service. 185 Mobility Service 186 Provider and Authorizer 187 +-------------------------------------------+ 188 | | 189 | +-------------+ +--+ | 190 | | MSA/MSP AAA | <-------------> |HA| | 191 | | server | AAA protocol +--+ | 192 | +-------------+ | 193 | | 194 +-------------------------------------------+ 196 +--+ 197 |MN| 198 +--+ 200 Figure 1 -- Split Scenario (MSA == MSP) 202 Figure 2 shows the split scenario in case the MSA and the MSP are two 203 different entities. This might happen if the Mobile Node is far from 204 its MSA network and is assigned a closer HA to optimize performance 205 or if the MSA cannot provide any Home Agent and relies on a third 206 party (i.e. the MSP) to grant mobility service to its users. Notice 207 that the MSP might be or might not also be the network operator that 208 is providing network access (i.e. ASP, Access Service Provider). 210 Mobility Service 211 Authorizer 212 +-------------+ 213 | MSA AAA | 214 | server | 215 +-------------+ 216 ^ 217 | 218 AAA protocol | 219 | Mobility Service 220 | Provider 221 +--------|----------------------------------+ 222 | V | 223 | +-------------+ +--+ | 224 | | MSP AAA | <-------------> |HA| | 225 | | server | AAA protocol +--+ | 226 | +-------------+ | 227 | | 228 +-------------------------------------------+ 230 +--+ 231 |MN| 232 +--+ 234 Figure 2 -- Split Scenario (MSA != MSP) 236 Note that Figure 1 and Figure 2 assume the use of an AAA protocol to 237 authenticate and authorize the Mobile Node for mobility service. 238 However, since IKEv2 allows EAP client authentication only and the 239 server authentication needs to be performed based on certificates or 240 public keys, the Mobile Node potentially requires a certificate 241 revocation list check (CTL check) even though an AAA potocol is used 242 to authenticate and authorize the Mobile Node for mobility service. 244 If, instead, a PKI is used, the Mobile Node and HA exchange 245 certificates and there is no AAA server involved [10]. This is 246 conceptually similar to Figure 1, since the MSP == MSA, except the 247 Home Agent, and potentially the Mobile Node, may require a 248 certificate revocation list check (CRL check) with the Certificate 249 Authority (CA). The CA may be either internal or external to the 250 MSP. Figure 3 illustrates this. 252 Certificate 253 Authority 254 +-------------+ 255 | CA | 256 | server | 257 +-------------+ 258 ^ 259 | 260 CRL Check | 261 | Mobility Service 262 | Provider and Authorizer 263 +--------|----------+ 264 | V | 265 | +-------------+ | 266 | | HA | | 267 | | | | 268 | +-------------+ | 269 | | 270 +-------------------+ 272 +--+ 273 |MN| 274 +--+ 276 Figure 3 -- Split Scenario with PKI 278 The split scenario is the simplest model that can be identified, 279 since no assumptions about the access network are made. This implies 280 that the mobility service is bootstrapped independently from the 281 authentication protocol for network access used (e.g. EAP or even 282 open access). For this reason, the solution described in this 283 document and developed for this scenario could also be applied to the 284 integrated access network deployment model [8], even if it might not 285 be optimized. 287 4. Components of the solution 289 The bootstrapping problem is composed of different sub-problems that 290 can be solved independently in a modular way. The components 291 identified and a brief overview of their solution follow. 293 HA address discovery 295 The Mobile Node needs to discover the address of its Home Agent. 296 The main objective of a bootstrapping solution is to minimize the 297 data pre-configured on the Mobile Node. For this reason, the 298 DHAAD defined in [1] may not be applicable in real deployments 299 since it is required that the Mobile Node is pre-configured with 300 the home network prefix and it does not allow an operator to load 301 balance by having Mobile Nodes dynamically assigned to Home Agents 302 located in different subnets. This document defines a solution 303 for Home Agent address discovery that is based on Domain Name 304 Service (DNS), introducing a new DNS SRV record [3]. The unique 305 information that needs to be pre-configured on the Mobile Node is 306 the domain name of the MSP. 308 IPsec Security Associations setup 310 Mobile IPv6 requires that a Mobile Node and its Home Agent share 311 an IPsec SA in order to protect binding updates and other Mobile 312 IPv6 signaling. This document provides a solution that is based 313 on IKEv2 and follows what is specified in [4]. The IKEv2 peer 314 authentication can be performed both using certificates and using 315 EAP, depending on the network operator's deployment model. 317 Home Address (HoA) assignment 319 The Mobile Node needs to know its Home Address in order to 320 bootstrap Mobile IPv6 operation. The Home Address is assigned by 321 the Home Agent during the IKEv2 exchange (as described in [4]). 322 The solution defined in this document also allows the Mobile Node 323 to auto-configure its Home Address based on stateless auto- 324 configuration [11], Cryptographically Generated Addresses [12] or 325 privacy addresses [13]. 327 Authentication and Authorization with MSA 329 The user must be authenticated in order for the MSP to grant the 330 service. Since the user credentials can be verified only by the 331 MSA, this authorization step is performed by the MSA. Moreover, 332 the mobility service must be explicitly authorized by the MSA 333 based on the user's profile. These operations are performed in 334 different ways depending on the credentials used by the Mobile 335 Node during the IKEv2 peer authentication and on the backend 336 infrastructure (PKI or AAA). 338 An optional part of bootstrapping involves providing a way for the 339 Mobile Node to have its FQDN updated in the DNS with a dynamically 340 assigned home address. While not all applications will require this 341 service, many networking applications use the FQDN to obtain an 342 address for a node prior to starting IP traffic with it. The 343 solution defined in this document specifies that the dynamic DNS 344 update is performed by the Home Agent or through the AAA 345 infrastructure, depending on the trust relationship in place. 347 5. Protocol Operations 349 This section describes in detail the procedures needed to perform 350 Mobile IPv6 bootstrapping based on the components identified in the 351 previous section. 353 5.1. Home Agent Address Discovery 355 Once a Mobile Node has obtained network access, it can perform Mobile 356 IPv6 bootstrapping. For this purpose, the Mobile Node queries the 357 DNS server to request information on Home Agent service. As 358 mentioned before in the document, the only information that needs to 359 be pre-configured on the Mobile Node is the domain name of the 360 Mobility Service Provider. 362 The Mobile Node needs to obtain the IP address of the DNS server 363 before it can send a DNS request. This can be pre-configured on the 364 Mobile Node or obtained through DHCPv6 from the visited link [14]. 365 In any case, it is assumed that there is some kind of mechanism by 366 which the Mobile Node is configured with a DNS server since a DNS 367 server is needed for many other reasons. 369 Two options for DNS lookup for a Home Agent address are identified in 370 this document: DNS lookup by Home Agent Name and DNS lookup by 371 service name. 373 This document does not provide a specific mechanism to load balance 374 different Mobile Nodes among Home Agents. It is possible for an MSP 375 to achieve coarse-grained load balancing by dynamically updating the 376 SRV RR priorities to reflect the current load on the MSP's collection 377 of Home Agents. Mobile Nodes then use the priority mechanism to 378 preferentially select the least loaded HA. The effectiveness of this 379 technique depends on how much of a load it will place on the DNS 380 servers, particularly if dynamic DNS is used for frequent updates. 382 While this document specifies a Home Agent Address Discovery solution 383 based on DNS, when the ASP and the MSP are the same entity DHCP may 384 be used. See [15] for details. 386 5.1.1. DNS lookup by Home Agent Name 388 In this case, the Mobile Node is configured with the Fully Qualified 389 Domain Name of the Home Agent. As an example, the Mobile Node could 390 be configured with the name "ha1.example.com", where "example.com" is 391 the domain name of the MSP granting the mobility service. 393 The Mobile Node constructs a DNS request, by setting the QNAME to the 394 name of the Home Agent. The request has QTYPE set to 'AAAA', so that 395 the DNS server sends the IPv6 address of the Home Agent. Once the 396 DNS server replies to this query, the Mobile Node knows its Home 397 Agent address and can run IKEv2 in order to set up the IPsec SAs and 398 get a Home Address. 400 Note that the configuration of a fixed home agent FQDN does allow 401 dynamic assignment of a localized home agent. Such dynamic 402 assignment would be useful, however, for instance from the point of 403 view of improving routing efficiency in bidirectional tunneling mode. 404 Enhancements or conventions for dynamic assignment are possible, but 405 are outside the scope of this specification. 407 5.1.2. DNS lookup by service name 409 RFC 2782 [3] defines the service resource record (SRV RR) that allows 410 an operator to use several servers for a single domain, to move 411 services from host to host, and to designate some hosts as primary 412 servers for a service and others as backups. Clients ask for a 413 specific service/protocol for a specific domain and get back the 414 names of any available servers. 416 RFC 2782 [3] also describes the policies to choose a service agent 417 based on the preference and weight values. The DNS SRV record may 418 contain the preference and weight values for multiple Home Agents 419 available to the Mobile Node in addition to the Home Agent FQDNs. If 420 multiple Home Agents are available in the DNS SRV record then Mobile 421 Node is responsible for processing the information as per policy and 422 for picking one Home Agent. If the Home Agent of choice does not 423 respond for some reason or the IKEv2 authentication fails, the Mobile 424 Node SHOULD try other Home Agents on the list. 426 The service name for Mobile IPv6 Home Agent service as required by 427 RFC 2782 is "mip6" and the protocol name is "ipv6". Note that a 428 transport name cannot be used here because Mobile IPv6 does not run 429 over a transport protocol. 431 The SRV RR has a DNS type code of 33. As an example, the Mobile 432 constructs a request with QNAME set to "_mip6._ipv6.example.com" and 433 QTYPE to SRV. The reply contains the FQDNs of one or more servers, 434 that can then be resolved in a separate DNS transaction to the IP 435 addresses. However, if there is room in the SRV reply, it is 436 RECOMMENDED that the DNS server also return the IP addresses of the 437 Home Agents in AAAA records as part of the additional data section 438 (in order to avoid requiring an additional DNS round trip to resolve 439 the FQDNs). 441 5.1.3. Anycast Address for Home Agent Assignment 443 A FQDN MAY be bound to an IPv6 anycast address rather than to a 444 unicast address for a Home Agent. Since anycast addresses are 445 indistinguishable from unicast addresses, there is no distinction in 446 the AAAA record between a unicast address and an anycast address. 447 The anycast address allows the home network to assign a Home Agent to 448 a Mobile Node on a case by case basis at the time that the Mobile 449 Node bootstraps, rather than having the Mobile Node select the Home 450 Agent address. Section 5.2.1 below describes how the IKEv2 451 transaction is modified by anycast Home Agent assignment. A FQDN 452 bound to an anycast address MAY be returned by a SRV RR query. 453 Mobile Nodes that implement this specification MUST be prepared to 454 handle an anycast address for Home Agent assignment. 456 The anycast address reserved by RFC 2526 [5] for Home Agents on the 457 same link MAY be used for bootstrapping. Other deployment-specific 458 anycast addresses, spanning a wider topology, MAY also be used. 460 Note that anycast forwarding as specified in RFC 4291 [6] allows the 461 node which has the anycast address assigned to one of its network 462 interfaces to make the decision about to which address forwarding 463 should occur based only on routing metric information. Use of any 464 other criteria, such as load balancing or service profile offered by 465 the Home Agent, in a standardized way is currently unsupported. 466 Assignment based on other criteria than routing metrics can be 467 achieved by having the home agent receiving the forwarded message 468 perform the home agent selection based on other critera, but the 469 mechanism for this is out of scope of this draft. 471 5.2. IPsec Security Associations setup 473 As soon as the Mobile Node has discovered the Home Agent Address, it 474 establishes an IPsec Security Association with the Home Agent itself 475 through IKEv2. The detailed description of this procedure is 476 provided in [4]. If the Mobile Node wants the HA to register the 477 Home Address in the DNS, it MUST use the FQDN as the initiator 478 identity in IKE_AUTH step of the IKEv2 exchange (IDi). This is 479 needed because the Mobile Node has to provide it is the owner of the 480 FQDN provided in the subsequent DNS Update Option. See section 6 and 481 section 9 for a more detailed analysis on this issue. 483 The IKEv2 Mobile Node to Home Agent authentication can be performed 484 using either IKEv2 public key signatures or the Extensible 485 Authentication Protocol (EAP). The details about how to use IKEv2 486 authentication are described in [4] and [7]. Choice of an IKEv2 peer 487 authentication method depends on the deployment. However, IKEv2 488 restricts the Home Agent to Mobile Node authentication to use public 489 key signature-based authentication. 491 5.2.1. IKEv2 Transaction with anycast Home Agent assignment 493 If an anycast address is returned in response to DNS resolution of an 494 FQDN, the IKEv2 transaction between the Mobile Node and Home Agent is 495 modified. The Mobile Node sends the IKE_SA_INIT request to the 496 anycast address. The node which has the anycast address assigned to 497 one of its network interfaces selects a Home Agent address from the 498 set of Home Agents managed by the node, and forwards the IKE_SA_INIT. 499 If the set of Home Agents is empty, the node simply drops the packet. 500 The Home Agent answers using its own address, and includes an "under 501 attack" cookie, in accordance with RFC 4306 [7]. The Mobile Node 502 notes the Home Agent address and resends the IKE_SA_INIT message to 503 the Home Agent, along with the cookie. 505 The resulting IKE_SA_INIT transaction is the following: 507 Initiator Responder ("best" HA) 508 --------- --------------------- 510 (IP_I:500 -> ANYCAST:500) 511 HDR(A,0), SAi1, KEi, Ni --> 513 (IP_R:500 -> IP_I:500) 514 <-- HDR(A,0), N(COOKIE) 516 (IP_I:500 -> IP_R:500) 517 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 519 (IP_R:500 -> IP_I:500) 520 <-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ] 522 (IP_I:500 -> IP_R:500) 523 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] 524 [IDr,]AUTH, SAi2, TSi, TSr} --> 526 (IP_R:500 -> IP_I:500) 527 <-- HDR(A,B), SK {IDr, [CERT,] AUTH, 528 SAr2, TSi, TSr} 530 Note that the "under attack" cookie is being used to force a new 531 IKE_SA_INIT exchange with the home agent, after the initial 532 IKE_SA_INIT request/response exchange is used to identify the home 533 agent that will be serving the mobile node. 535 When the mobile node sends an IKE_SA_INIT request message to an 536 anycast address, the response comes back from an unicast address. 537 RFC 4306 requires that the responder MUST use the destination address 538 on the request message as the source address on the response message. 539 However, it is assumed that RFC 4306 is talking about unicast 540 addresses in that context. The mobile node implementation compliant 541 to this specification must relax the requirement from RFC 4306 and be 542 willing to process the response from an unicast address when it sends 543 a request to an anycast address. 545 The use of anycast address as specified above requires the 546 implementation of anycast forwarding in such a way that the Home 547 Agent can distinguish between an IKE_SA_INIT forwarded through an 548 anycast address and one sent directly from the Mobile Node. One 549 possible mechanism is to use IP-in-ip tunneling for forwarding the 550 IKE_SA_INIT. In this case, the Home Agent can identify a forwarded 551 IKE_SA_INIT based on the incoming interface or based on the 552 additional IP header. Other mechanisms may be used. 554 Home Agents SHOULD NOT include an "under attack" cookie unless the 555 IKE_SA_INIT was forwarded through an anycast address or the Home 556 Agent believes that it is, in fact, under attack, in order to 557 maintain conformance with RFC 4306 for other applications. 559 A mobile node's security associations with its home agent may expire 560 while it still has a valid binding cache entry at the the home agent. 561 In this case, the mobile node MUST NOT use an anycast address as the 562 destination address in the IKE_SA_INIT exchange to setup new security 563 associations. It MUST try to setup security associations with its 564 existing home agent. 566 5.3. Home Address assignment 568 Home Address assignment is performed during the IKEv2 exchange. The 569 Home Address can be assigned directly by the Home Agent or can be 570 auto-configured by the Mobile Node. 572 5.3.1. Home Address assignment by the Home Agent 574 When the Mobile Node runs IKEv2 with its Home Agent, it can request a 575 HoA through the Configuration Payload in the IKE_AUTH exchange by 576 including an INTERNAL_IP6_ADDRESS attribute. When the Home Agent 577 processes the message, it allocates a HoA and sends it a CFG_REPLY 578 message. The Home Agent could consult a DHCP server on the home link 579 for the actual home address allocation. This is explained in detail 580 in [4]. 582 5.3.2. Home Address auto-configuration by the Mobile Node 584 With the type of assignment described in the previous section, the 585 Home Address cannot be generated based on Cryptographically Generated 586 Addresses (CGAs) [12] or based on the privacy extensions for 587 stateless auto-configuration [13]. However, the Mobile Node might 588 want to have an auto-configured HoA based on these mechanisms. It is 589 worthwhile to mention that the auto-configuration procedure described 590 in this section cannot be used in some possible deployments, since 591 the Home Agents might be provisioned with pools of allowed Home 592 Addresses. 594 In the simplest case, the Mobile Node is provided with a pre- 595 configured home prefix and home prefix length. In this case the 596 Mobile Node creates a Home Address based on the pre-configured prefix 597 and sends it to the Home Agent including an INTERNAL_IP6_ADDRESS 598 attribute in a Configuration Payload of type CFG_REQUEST. If the 599 Home Address is valid, the Home Agent replies with a CFG_REPLY, 600 including an INTERNAL_IP6_ADDRESS with the same address. If the Home 601 Address provided by the Mobile Node is not valid, the Home Agent 602 assigns a different Home Address including an INTERNAL_IP6_ADDRESS 603 attribute with a new value. According to [7] the Mobile Node MUST 604 use the address sent by the Home Agent. Later, if the Mobile Node 605 wants to use an auto-configured Home Address (e.g. based on CGA), it 606 can run Mobile Prefix Discovery, obtain a prefix, auto-configure a 607 new Home Address and then perform a new CREATE_CHILD_SA exchange. 609 If the Mobile Node is not provided with a pre-configured Home Prefix, 610 the Mobile cannot simply propose an auto-configured HoA in the 611 Configuration Payload since the Mobile Node does not know the home 612 prefix before the start of the IKEv2 exchange. The Mobile Node must 613 obtain the home prefix and the home prefix length before it can 614 configure a home address. 616 One simple solution would be for the Mobile Node to just assume that 617 the prefix length on the home link is 64 bits and extract the home 618 prefix from the Home Agent's address. The disadvantage with this 619 solution is that the home prefix cannot be anything other than /64. 620 Moreover, this ties the prefix on the home link and the Home Agent's 621 address, but, in general, a Home Agent with a particular address 622 should be able to serve a number of prefixes on the home link, not 623 just the prefix from which its address is configured. 625 Another solution would be for the Mobile Node to assume that the 626 prefix length on the home link is 64 bits and send its interface 627 identifier to the Home Agent in the INTERNAL_IP6_ADDRESS attribute 628 within the CFG_REQ payload. Even though this approach does not tie 629 the prefix on the home link and the Home Agent's address, it still 630 requires that the home prefix length is 64 bits. 632 For this reason the Mobile Node needs to obtain the home link 633 prefixes through the IKEv2 exchange. In the Configuration Payload 634 during the IKE_AUTH exchange, the Mobile Node includes the 635 MIP6_HOME_PREFIX attribute in the CFG_REQUEST message. The Home 636 Agent, when it processes this message, should include in the 637 CFG_REPLY payload prefix information for one prefix on the home link. 638 This prefix information includes the prefix length (see Section 8.2). 639 The Mobile Node auto-configures a Home Address from the prefix 640 returned in the CFG_REPLY message and runs a CREATE_CHILD_SA exchange 641 to create security associations for the new Home Address. 643 As mentioned before in this document, there are deployments where 644 auto-configuration of the Home Address cannot be used. In this case, 645 when the Home Agent receives a CFG_REQUEST including a 646 MIP6_HOME_PREFIX attribute, in the subsequent IKE response it 647 includes a Notify Payload type "USE_ASSIGNED_HoA" and the related 648 Home Address in a INTERNAL_IP6_ADDRESS attribute. If the Mobile Node 649 gets a "USE_ASSIGNED_HoA" Notify Payload in response to the 650 Configuration Payload containing the MIP6_HOME_PREFIX attribute, it 651 looks for an INTERNAL_IP6_ADDRESS attribute and MUST use the address 652 contained in it in the subsequent CREATE_CHILD_SA exchange. 654 When the Home Agent receives a Binding Update for the Mobile Node, it 655 performs proxy DAD for the auto-configured Home Address. If DAD 656 fails, the Home Agent rejects the Binding Update. If the Mobile Node 657 receives a Binding Acknowledgement with status 134 (DAD failed), it 658 MUST stop using the current Home Address, configure a new HoA, and 659 then run IKEv2 CREATE_CHILD_SA exchange to create security 660 associations based on the new HoA. The Mobile Node does not need to 661 run IKE_INIT and IKE_AUTH exchanges again. Once the necessary 662 security associations are created, the Mobile Node sends a Binding 663 Update for the new Home Address. 665 It is worth noting that with this mechanism, the prefix information 666 carried in MIP6_HOME_PREFIX attribute includes only one prefix and 667 does not carry all the information that is typically present when 668 received through a IPv6 router advertisement. Mobile Prefix 669 Discovery, specified in RFC 3775, is the mechanism through which the 670 Mobile Node can get all prefixes on the home link and all related 671 information. That means that MIP6_HOME_PREFIX attribute is only used 672 for Home Address auto-configuration and does not replace the usage of 673 Mobile Prefix Discovery for the purposes detailed in RFC 3775. 675 5.4. Authorization and Authentication with MSA 677 In a scenario where the Home Agent is discovered dynamically by the 678 Mobile Node, it is very likely that the Home Agent is not able to 679 verify by its own the credentials provided by the Mobile Node during 680 the IKEv2 exchange. Moreover, the mobility service needs to be 681 explicitly authorized based on the user's profile. As an example, 682 the Home Agent might not be aware of whether the mobility service can 683 be granted at a particular time of the day or when the credit of the 684 Mobile Node is going to expire. 686 Due to all these reasons, the Home Agent may need to contact the MSA 687 in order to authenticate the Mobile Node and authorize mobility 688 service. This can be accomplished based on a Public Key 689 Infrastructure if certificates are used and a PKI is deployed by the 690 MSP and MSA. On the other hand, if the Mobile Node is provided with 691 other types of credentials, the AAA infrastructure must be used. 693 The definition of this backend communication is out of the scope of 694 this document. In [16] a list of goals for such a communication is 695 provided. 697 6. Home Address registration in the DNS 699 In order that the Mobile Node is reachable through its dynamically 700 assigned Home Address, the DNS needs to be updated with the new Home 701 Address. Since applications make use of DNS lookups on FQDN to find 702 a node, the DNS update is essential for providing IP reachability to 703 the Mobile Node, which is the main purpose of the Mobile IPv6 704 protocol. The need for DNS updating is not discussed in RFC 3775 705 since it assumes that the Mobile Node is provisioned with a static 706 Home Address. However, when a dynamic Home Address is assigned to 707 the Mobile Node, any existing DNS entry becomes invalid and the 708 Mobile Node becomes unreachable unless a DNS update is performed. 710 Since the DNS update must be performed securely in order to prevent 711 attacks or modifications from malicious nodes, the node performing 712 this update must share a security association with the DNS server. 713 Having all possible Mobile Nodes sharing a security association with 714 the DNS servers of the MSP might be cumbersome from an administrative 715 perspective. Moreover, even if a Mobile Node has a security 716 association with a DNS server of its MSP, an address authorization 717 issue comes into the picture. A detailed analysis of possible 718 threats against DNS update is provided in Section 9.5. 720 Therefore, due to security and administrative reasons, it is 721 RECOMMENDED that the Home Agent perform DNS entry updates for the 722 Mobile Node. For this purpose the Mobile Node MAY include a new 723 mobility option in the Binding Update, the DNS Update option, with 724 the flag R not set in the option. This option is defined in 725 Section 8 and includes the FQDN that needs to be updated. After 726 receiving the Binding Update, the Home Agent MUST update the DNS 727 entry with the identifier provided by the Mobile Node and the Home 728 Address included in the Home Address Option. The procedure for 729 sending a dynamic DNS update message is specified in [17]. The 730 dynamic DNS update SHOULD be performed in a secure way; for this 731 reason, the usage of TKEY and TSEC or DNSSEC is recommended (see 732 Section 9.5 for details). As soon as the Home Agent has updated the 733 DNS, it MUST send a Binding Acknowledgement message to the Mobile 734 Node including the DNS Update mobility option with the correct value 735 in the Status field (see Section 8.1). 737 This procedure can be performed directly by the Home Agent if the 738 Home Agent has a security association with the domain specified in 739 the Mobile Node's FQDN. 741 On the other hand, if the Mobile Node wants to be reachable through a 742 FQDN that belongs to the MSA, the Home Agent and the DNS server that 743 must be updated belong to different administrative domains. In this 744 case the Home Agent may not share a security association with the DNS 745 server and the DNS entry update can be performed by the AAA server of 746 the MSA. In order to accomplish this, the Home Agent sends to the 747 AAA server the FQDN-HoA pair through the AAA protocol. This message 748 is proxied by the AAA infrastructure of the MSP and is received by 749 the AAA server of the MSA. The AAA server of the MSA perform the DNS 750 update based on [17]. Notice that, even in this case, the Home Agent 751 is always required to perform a DNS update for the reverse entry, 752 since this is always performed in the DNS server of the MSP. The 753 detailed description of the communication between Home Agent and AAA 754 is out of the scope of this document. More details are provided in 755 [16]. 757 A mechanism to remove stale DNS entries is needed. A DNS entry 758 becomes stale when the related Home Address is no longer used by the 759 Mobile Node. To remove a DNS entry, the Mobile Node includes in the 760 Binding Update the DNS Update mobility option, with the flag R set in 761 the option. After receiving the Binding Update, the Home Agent MUST 762 remove the DNS entry identified by the FQDN provided by the Mobile 763 Node and the Home Address included in the Home Address Option. The 764 procedure for sending a dynamic DNS update message is specified in 765 [17]. As mentioned above, the dynamic DNS update SHOULD be performed 766 in a secure way; for this reason, the usage of TKEY and TSEC or 767 DNSSEC is recommended (see Section 9.5 for details). 769 If there is no explicit de-registration BU from the Mobile Node, then 770 the HA MAY use the binding cache entry expiration as a trigger to 771 remove the DNS entry. 773 7. Summary of Bootstrapping Protocol Flow 775 The message flow of the whole bootstrapping procedure when the 776 dynamic DNS update is performed by the Home Agent is depicted below. 778 +----+ +----+ +-----+ 779 | MN | | HA | | DNS | 780 +----+ +----+ +-----+ 782 IKEv2 exchange 783 (HoA configuration) 784 <======================> 786 BU (DNS update option) 787 -----------------------> 788 DNS update 789 <-------------------> 790 BA (DNS update option) 791 <----------------------- 793 On the contrary, the figure below shows the message flow of the whole 794 bootstrapping procedure when the dynamic DNS update is performed by 795 the AAA server of the MSA. 797 +----+ +----+ +---+ +---+ 798 | MN | | HA | |AAA| |DNS| 799 +----+ +----+ +---+ +---+ 801 IKEv2 exchange 802 (HoA configuration) 803 <======================> 805 BU (DNS update option) 806 -----------------------> 808 AAA request 809 (FQDN, HoA) 810 <--------------> 812 DNS update 813 <-----------> 814 AAA answer 815 (FQDN, HoA) 816 <--------------> 817 BA (DNS update option) 818 <----------------------- 820 Notice that, even in this last case, the Home Agent is always 821 required to perform a DNS update for the reverse entry, since this is 822 always performed in the DNS server of the MSP. This is not depicted 823 in the figure above. 825 8. Option and Attribute Format 827 8.1. DNS Update mobility option 829 0 1 2 3 830 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Option Type | Option Length | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Status |R| Reserved | MN identity (FQDN) ... 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 Option Type 838 DNS-UPDATE-TYPE to be defined by IANA 840 Option Length 842 8-bit unsigned integer indicating the length of the option 843 excluding the type and length fields 845 Status 847 8-bit unsigned integer indicating the result of the dynamic DNS 848 update procedure. This field MUST be set to 0 and ignored by the 849 receiver when the DNS Update mobility option is included in a 850 Binding Update message. When the DNS Update mobility option is 851 included in the Binding Acknowledgement message, values of the 852 Status field less than 128 indicate that the dynamic DNS update 853 was performed successfully by the Home Agent. Values greater than 854 or equal to 128 indicate that the dynamic DNS update was not 855 completed by the HA. The following Status values are currently 856 defined: 858 0 DNS update performed 860 128 Reason unspecified 862 129 Administratively prohibited 864 130 DNS Update Failed 866 R flag 868 If set the Mobile Node is requesting the HA to remove the DNS 869 entry identified by the FQDN specified in this option and the HoA 870 of the Mobile Node. If not set, the Mobile Node is requesting the 871 HA to create or update a DNS entry with its HoA and the FQDN 872 specified in the option 874 Reserved 876 MUST be set to 0 878 MN identity 880 The identity of the Mobile Node in FQDN format to be used by the 881 Home Agent to send a Dynamic DNS update. It is a variable length 882 field 884 8.2. MIP6_HOME_PREFIX attribute 886 0 1 2 3 887 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 |R| Attribute Type | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Length | Prefix Length | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | | 894 | home prefix | 895 | | 896 | | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Prefix Lifetime | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 Reserved (1 bit) 903 This bit MUST be set to zero and MUST be ignored on receipt 905 Attribute Type (15 bits) 907 A unique identifier for the MIP6_HOME_PREFIX attribute. To be 908 assigned by IANA 910 Length (2 octets) 912 Length in octets of Value field (home prefix and Prefix Length). 913 This is multi-valued and can be 0 or 17 915 Prefix Length (2 octets) 917 The length in bits of the home prefix specified in the field Home 918 Prefix 920 Home Prefix (16 octets) 922 The prefix of the home link through which the Mobile Node may 923 auto-configure its Home Address 925 Prefix Lifetime (4 octets) 927 The lifetime of the Home Prefix 929 When the MIP6_HOME_PREFIX attribute is included by the Mobile Node in 930 the CFG_REQUEST payload, the value of the Length field is 0. On the 931 other hand, when the MIP6_HOME_PREFIX attribute is included in the 932 CFG_REPLY payload by the Home Agent, the value of the Length field is 933 17 and the attribute contains also the Home Prefix and the Prefix 934 Length fields. 936 9. Security Considerations 938 9.1. HA Address Discovery 940 Use of DNS for address discovery carries certain security risks. DNS 941 transactions in the Internet are typically done without any 942 authentication of the DNS server by the client or of the client by 943 the server. There are two risks involved: 945 1. A legitimate client obtains a bogus Home Agent address from a 946 bogus DNS server. This is sometimes called a "pharming" attack, 948 2. An attacking client obtains a legitimate Home Agent address from 949 a legitimate server. 951 The risk in Case 1 is mitigated because the Mobile Node is required 952 to conduct an IKE transaction with the Home Agent prior to performing 953 a Binding Update to establish Mobile IPv6 service. According to the 954 IKEv2 specification [7], the responder must present the initiator 955 with a valid certificate containing the responder's public key, and 956 the responder to initiator IKE_AUTH message must be protected with an 957 authenticator calculated using the public key in the certificate. 958 Thus, an attacker would have to set up both a bogus DNS server and a 959 bogus Home Agent, and provision the Home Agent with a certificate 960 that a victim Mobile Node could verify. If the Mobile Node can 961 detect that the certificate is not trustworthy, the attack will be 962 foiled when the Mobile Node attempts to set up the IKE SA. 964 The risk in Case 2 is limited for a single Mobile Node to Home Agent 965 transaction if the attacker does not possess proper credentials to 966 authenticate with the Home Agent. The IKE SA establishment will fail 967 when the attacking Mobile Node attempts to authenticate itself with 968 the Home Agent. Regardless of whether the Home Agent utilizes EAP or 969 host-side certificates to authenticate the Mobile Node, the 970 authentication will fail unless the Mobile Node has valid 971 credentials. 973 Another risk exists in Case 2 because the attacker may be attempting 974 to propagate a DoS attack on the Home Agent. In that case, the 975 attacker obtains the Home Agent address from the DNS, then propagates 976 the address to a network of attacking hosts that bombard the Home 977 Agent with traffic. This attack is not unique to the bootstrapping 978 solution, however, it is actually a risk that any Mobile IPv6 Home 979 Agent installation faces. In fact, the risk is faced by any service 980 in the Internet that distributes a unicast globally routable address 981 to clients. Since Mobile IPv6 requires that the Mobile Node 982 communicate through a globally routable unicast address of a Home 983 Agent, it is possible that the Home Agent address could be propagated 984 to an attacker by various means (theft of the Mobile Node, malware 985 installed on the Mobile Node, evil intent of the Mobile Node owner 986 him/herself, etc.) even if the home address is manually configured on 987 the Mobile Node. Consequently, every Mobile IPv6 Home Agent 988 installation will likely be required to mount anti-DoS measures. 989 Such measures include overprovisioning of links to and from Home 990 Agents and of Home Agent processing capacity, vigilant monitoring of 991 traffic on the Home Agent networks to detect when traffic volume 992 increases abnormally indicating a possible DoS attack, and hot spares 993 that can quickly be switched on in the event an attack is mounted on 994 an operating collection of Home Agents. DoS attacks of moderate 995 intensity should be foiled during the IKEv2 transaction. IKEv2 996 implementations are expected to generate their cookies without any 997 saved state, and to time out cookie generation parameters frequently, 998 with the timeout value increasing if a DoS attack is suspected. This 999 should prevent state depletion attacks, and should assure continued 1000 service to legitimate clients until the practical limits on the 1001 network bandwith and processing capacity of the Home Agent network 1002 are reached. 1004 Explicit security measures between the DNS server and host, such 1005 DNSSEC [18] or TSIG/TKEY [19] [20] can mitigate the risk of 1) and 1006 2), but these security measures are not widely deployed on end nodes. 1007 These security measures are not sufficient to protect the Home Agent 1008 address against DoS attack, however, because a node having a 1009 legitimate security association with the DNS server could 1010 nevertheless intentionally or inadvertently cause the Home Agent 1011 address to become the target of DoS. 1013 Finally notice that assignment of an home agent from the serving 1014 network access provider's (local home agent) or a home agent from a 1015 nearby network (nearby home agent) may set up the potential to 1016 compromise a mobile node's location privacy. However, since a 1017 standardized mechanism of assigning local or nearby home agents is 1018 out of scope for this document, it is not possible to present 1019 detailed security considerations. Please see other drafts that 1020 contain detailed mechanisms for localized home agent assignment, such 1021 as [15], for information on the location privacy properties of 1022 particular home agent assignment mechanisms. 1024 Security considerations for discovering HA using DHCP are covered in 1025 [21]. 1027 9.2. Home Address Assignment through IKEv2 1029 Mobile IPv6 bootstrapping assigns the home address through the IKEv2 1030 transaction. The Mobile Node can either choose to request an 1031 address, similar to DHCP, or the Mobile Node can request a prefix on 1032 the home link then auto-configure an address. 1034 RFC 3775 [1] requires that a Home Agent check authorization of a home 1035 address received during a Binding Update. Therefore, the home agent 1036 MUST authorize each home address allocation and use. This 1037 authorization is based on linking the mobile node identity used in 1038 the IKEv2 authentication process and the home address. Home agents 1039 MUST support at least the following two modes of authorization: 1041 o Configured home address(es) for each mobile node. In this mode, 1042 the home agent or infrastructure nodes behind it know what 1043 addresses a specific mobile node is authorized to use. The mobile 1044 node is allowed to request these addresses, or if the mobile node 1045 requests any home address, these addresses are returned to it. 1047 o First-come-first-served (FCFS). In this mode, the home agent 1048 maintains a pool of "used" addresses, and allows mobile nodes to 1049 request any address, as long as it is not used by another mobile 1050 node. 1052 Addresses MUST be marked as used for at least as long as the binding 1053 exists, and are associated with the identity of the mobile node that 1054 made the allocation. 1056 In addition, the home agent MUST ensure that the requested address is 1057 not the authorized address of any other mobile node, if both FCFS and 1058 configured modes use the same address space. 1060 9.3. SA Establishment Using EAP Through IKEv2 1062 Security considerations for authentication of the IKE transaction 1063 using EAP are covered in [4] . 1065 9.4. Back End Security Between the HA and AAA Server 1067 Some deployments of Mobile IPv6 bootstrapping may use an AAA server 1068 to handle authorization for mobility service. This process has its 1069 own security requirements, but the back end protocol for Home Agent 1070 to AAA server interface is not covered in this draft. Please see 1071 [16] for a discussion of this interface. 1073 9.5. Dynamic DNS Update 1075 If a Home Agent performs dynamic DNS update on behalf of the Mobile 1076 Node directly with the DNS server, the Home Agent MUST have a 1077 security association of some type with the DNS server. The security 1078 association MAY be established either using DNSSEC [18] or TSIG/TKEY 1079 [19][20]. A security association is required even if the DNS server 1080 is in the same administrative domain as the Home Agent. The security 1081 association SHOULD be separate from the security associations used 1082 for other purposes, such as AAA. 1084 In the case where the Mobility Service Provider is different from the 1085 Mobility Service Authorizer, the network administrators may want to 1086 limit the number of cross-administrative domain security 1087 associations. If the Mobile Node's FQDN is in the Mobility Service 1088 Authorizer's domain, since a security association for AAA signaling 1089 involved in mobility service authorization is required in any case, 1090 the Home Agent can send the Mobile Node's FQDN to the AAA server 1091 under the HA-AAA server security association, and the AAA server can 1092 perform the update. In that case, a security association is required 1093 between the AAA server and DNS server for the dynamic DNS update. 1094 See [16] for a deeper discussion of the Home Agent to AAA server 1095 interface. 1097 Regardless of whether the AAA server or Home Agent performs DNS 1098 update, the authorization of the Mobile Node to update a FQDN MUST be 1099 checked prior to the performance of the update. It is an 1100 implementation issue as to how authorization is determined. However, 1101 in order to allow this authorization step, the Mobile Node MUST use a 1102 FQDN as the IDi in IKE_AUTH step of the IKEv2 exchange. The FQDN 1103 MUST be the same that will be provided by the Mobile Node in the DNS 1104 Update Option. 1106 In case EAP over IKEv2 is used to set-up the IPsec SA, the Home Agent 1107 gets authorization information about the Mobile Node's FQDN via the 1108 AAA back end communication performed during IKEv2 exchange. The 1109 outcome of this step will give the Home Agent the necessary 1110 information to authorize the DNS update request of the Mobile Node. 1111 See [16] for details about the communication between the AAA server 1112 and the Home Agent needed to perform the authorization. 1114 In case certificates are used in IKEv2, the authorization information 1115 about the FQDN for DNS update MUST be present in the certificate 1116 provided by the Mobile Node. Since the IKEv2 specification does not 1117 include a required certificate type, it is not possible to specify 1118 precisely how the Moible Node's FQDN should appear in the 1119 certificate. However, as an example, if the certificate type is 1120 "X.509 Certificate - Signature" (one of the recommended types) then 1121 the FQDN may appear in the subjectAltName attribute extension [22]. 1123 10. IANA Considerations 1125 This document defines a new Mobility Option and a new IKEv2 1126 Configuration Attribute Type. 1128 The following values should be assigned: 1130 o from "Mobility Option" namespace ([1]): DNS-UPDATE-TYPE 1131 (Section 8.1) 1133 o from "IKEv2 Configuration Payload Attribute Types" namespace 1134 ([7]): MIP6_HOME_PREFIX attribute (Section 8.2) 1136 o from "IKEv2 Notify Payload Error Types" namespace ([7]): 1137 USE_ASSIGNED_HoA error type (Section 5.3.2) 1139 11. Contributors 1141 This contribution is a joint effort of the bootstrapping solution 1142 design team of the MIP6 WG. The contributors include Basavaraj 1143 Patil, Alpesh Patel, Jari Arkko, James Kempf, Yoshihiro Ohba, Gopal 1144 Dommety, Alper Yegin, Junghoon Jee, Vijay Devarapalli, Kuntal 1145 Chowdury, Julien Bournelle. Francis Dupont and Kilian Weniger have 1146 contributed on the anycast HA assignment procedure. 1148 The design team members can be reached at: 1150 Gerardo Giaretta gerardog@qualcomm.com 1152 Basavaraj Patil basavaraj.patil@nokia.com 1154 Alpesh Patel alpesh@cisco.com 1156 Jari Arkko jari.arkko@kolumbus.fi 1158 James Kempf kempf@docomolabs-usa.com 1160 Yoshihiro Ohba yohba@tari.toshiba.com 1162 Gopal Dommety gdommety@cisco.com 1164 Alper Yegin alper.yegin@samsung.com 1165 Vijay Devarapalli vijay.devarapalli@azairenet.com 1167 Kuntal Chowdury kchowdury@starentnetworks.com 1169 Junghoon Jee jhjee@etri.re.kr 1171 Julien Bournelle julien.bournelle@gmail.com 1173 12. Acknowledgements 1175 The authors would like to thank Rafa Lopez, Francis Dupont, Jari 1176 Arkko, Kilian Weniger, Vidya Narayanan, Ryuji Wakikawa, Michael Ye 1177 for their valuable comments. 1179 13. References 1181 13.1. Normative References 1183 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1184 IPv6", RFC 3775, June 2004. 1186 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1187 Levels", BCP 14, RFC 2119, March 1997. 1189 [3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1190 specifying the location of services (DNS SRV)", RFC 2782, 1191 February 2000. 1193 [4] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1194 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1195 April 2007. 1197 [5] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 1198 Addresses", RFC 2526, March 1999. 1200 [6] Hinden, R. and S. Deering, "IP Version 6 Addressing 1201 Architecture", RFC 4291, February 2006. 1203 [7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1204 RFC 4306, December 2005. 1206 13.2. Informative References 1208 [8] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 1209 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 1211 [9] Manner, J. and M. Kojo, "Mobility Related Terminology", 1212 RFC 3753, June 2004. 1214 [10] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet 1215 X.509 Public Key Infrastructure Certificate Management Protocol 1216 (CMP)", RFC 4210, September 2005. 1218 [11] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 1219 draft-ietf-ipv6-2461bis-11 (work in progress), March 2007. 1221 [12] Aura, T., "Cryptographically Generated Addresses (CGA)", 1222 RFC 3972, March 2005. 1224 [13] Narten, T. and R. Draves, "Privacy Extensions for Stateless 1225 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1227 [14] Droms, R., "DNS Configuration options for Dynamic Host 1228 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1229 December 2003. 1231 [15] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 1232 Integrated Scenario", 1233 draft-ietf-mip6-bootstrapping-integrated-dhc-02 (work in 1234 progress), February 2007. 1236 [16] Giaretta, G., "AAA Goals for Mobile IPv6", 1237 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 1238 September 2006. 1240 [17] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 1241 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 1242 April 1997. 1244 [18] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1245 "DNS Security Introduction and Requirements", RFC 4033, 1246 March 2005. 1248 [19] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, 1249 "Secret Key Transaction Authentication for DNS (TSIG)", 1250 RFC 2845, May 2000. 1252 [20] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", 1253 RFC 2930, September 2000. 1255 [21] Jang, H., "DHCP Option for Home Information Discovery in 1256 MIPv6", draft-ietf-mip6-hiopt-02 (work in progress), 1257 February 2007. 1259 [22] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 1260 Public Key Infrastructure Certificate and Certificate 1261 Revocation List (CRL) Profile", RFC 3280, April 2002. 1263 Authors' Addresses 1265 Gerardo Giaretta 1266 Qualcomm 1268 Email: gerardog@qualcomm.com 1270 James Kempf 1271 DoCoMo Labs USA 1272 181 Metro Drive 1273 San Jose, CA 95110 1274 USA 1276 Email: kempf@docomolabs-usa.com 1278 Vijay Devarapalli 1279 Azaire Networks 1280 3121 Jay Street 1281 Santa Clara, CA 95054 1282 USA 1284 Email: vijay.devarapalli@azairenet.com 1286 Full Copyright Statement 1288 Copyright (C) The IETF Trust (2007). 1290 This document is subject to the rights, licenses and restrictions 1291 contained in BCP 78, and except as set forth therein, the authors 1292 retain all their rights. 1294 This document and the information contained herein are provided on an 1295 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1296 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1297 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1298 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1299 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1300 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1302 Intellectual Property 1304 The IETF takes no position regarding the validity or scope of any 1305 Intellectual Property Rights or other rights that might be claimed to 1306 pertain to the implementation or use of the technology described in 1307 this document or the extent to which any license under such rights 1308 might or might not be available; nor does it represent that it has 1309 made any independent effort to identify any such rights. Information 1310 on the procedures with respect to rights in RFC documents can be 1311 found in BCP 78 and BCP 79. 1313 Copies of IPR disclosures made to the IETF Secretariat and any 1314 assurances of licenses to be made available, or the result of an 1315 attempt made to obtain a general license or permission for the use of 1316 such proprietary rights by implementers or users of this 1317 specification can be obtained from the IETF on-line IPR repository at 1318 http://www.ietf.org/ipr. 1320 The IETF invites any interested party to bring to its attention any 1321 copyrights, patents or patent applications, or other proprietary 1322 rights that may cover technology that may be required to implement 1323 this standard. Please address the information to the IETF at 1324 ietf-ipr@ietf.org. 1326 Acknowledgment 1328 Funding for the RFC Editor function is provided by the IETF 1329 Administrative Support Activity (IASA).