idnits 2.17.1 draft-ietf-mip6-bootstrapping-split-04.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1340. ** 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. 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 36 longer pages, the longest (page 36) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1155 has weird spacing: '...iaretta gerar...' == Line 1157 has weird spacing: '...j Patil basa...' == Line 1165 has weird spacing: '...ro Ohba yoh...' == Line 1173 has weird spacing: '...howdury kcho...' == Line 1177 has weird spacing: '...urnelle julie...' -- 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 (December 19, 2006) is 6338 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. '2') (Obsoleted by RFC 6275) == Outdated reference: A later version (-05) exists of draft-ietf-mip6-bootstrap-ps-04 ** Downref: Normative reference to an Informational draft: draft-ietf-mip6-bootstrap-ps (ref. '4') == Outdated reference: A later version (-08) exists of draft-ietf-mip6-ikev2-ipsec-04 ** Obsolete normative reference: RFC 4306 (ref. '7') (Obsoleted by RFC 5996) == Outdated reference: A later version (-05) exists of draft-ietf-ipv6-privacy-addrs-v2-04 == Outdated reference: A later version (-03) exists of draft-ietf-mip6-aaa-ha-goals-01 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-00 -- Obsolete informational reference (is this intentional?): RFC 2845 (ref. '19') (Obsoleted by RFC 8945) == Outdated reference: A later version (-03) exists of draft-ietf-mip6-ro-sec-02 == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-05 Summary: 6 errors (**), 0 flaws (~~), 15 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 WG G. Giaretta, Editor 3 Internet Draft Telecom Italia 4 Expires: June 19, 2007 J. Kempf 5 DoCoMo Labs USA 6 V. Devarapalli 7 Azaire Networks 8 December 19, 2006 10 Mobile IPv6 bootstrapping in split scenario 11 draft-ietf-mip6-bootstrapping-split-04.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that 16 any applicable patent or other IPR claims of which he or she is 17 aware have been or will be disclosed, and any of which he or she 18 becomes aware will be disclosed, in accordance with Section 6 of 19 BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet-Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on June 19, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 A Mobile IPv6 node requires a Home Agent address, a home address, 47 and IPsec security associations with its Home Agent before it can 48 start utilizing Mobile IPv6 service. RFC 3775 requires that some 49 or all of these are statically configured. This document defines 50 how a Mobile IPv6 node can bootstrap this information from non- 51 topological information and security credentials preconfigured on 52 the Mobile Node. The solution defined in this document solves the 53 bootstrapping problem from draft-ietf-mip6-bootstrapping-ps-02 54 when the Mobile Node's mobility service is authorized by a 55 different service provider than basic network access, and is 56 therefore generically applicable to any bootstrapping case. 58 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 61 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 62 in this document are to be interpreted as described in RFC-2119 63 [1]. 65 Table of Contents 67 1. Introduction...................................................4 68 2. Terminology....................................................5 69 3. Split scenario.................................................6 70 4. Components of the solution.....................................9 71 5. Protocol Operations...........................................11 72 5.1. Home Agent Address Discovery.............................11 73 5.1.1. DNS lookup by Home Agent Name.......................11 74 5.1.2. DNS lookup by service name..........................12 75 5.1.3. Anycast Address for Home Agent Assignment...........13 76 5.2. IPsec Security Associations setup........................13 77 5.2.1. IKEv2 Transaction With Anycast Home Agent Assignment14 78 5.3. Home Address assignment..................................15 79 5.3.1. Home Address assignment by the Home Agent...........15 80 5.3.2. Home Address auto-configuration by the Mobile Node..15 81 5.4. Authorization and Authentication with MSA................17 82 6. Home Address registration in the DNS..........................19 83 7. Summary of Bootstrapping Protocol Flow........................21 84 8. Option and Attribute Format...................................23 85 8.1. DNS Update mobility option...............................23 86 8.2. MIP6_HOME_PREFIX attribute...............................24 87 9. Security Considerations.......................................26 88 9.1. HA Address Discovery.....................................26 89 9.2. Home Address Assignment through IKEv2....................27 90 9.3. SA Establishment Using EAP Through IKEv2.................28 91 9.4. Back End Security Between the HA and AAA Server..........28 92 9.5. Dynamic DNS Update.......................................28 93 10. IANA Considerations..........................................30 94 11. Contributors.................................................31 95 12. Acknowledgments..............................................32 96 13. References...................................................33 97 13.1. Normative References....................................33 98 13.2. Informative References..................................33 99 Authors' Addresses...............................................35 101 1. Introduction 103 Mobile IPv6 [2] requires the Mobile Node to know its Home Agent 104 Address, its own Home Address and the cryptographic materials 105 (e.g. shared keys or certificates) needed to set up IPsec security 106 associations with the Home Agent in order to protect Mobile IPv6 107 signaling. This is generally referred to as the Mobile IPv6 108 bootstrapping problem [4]. 110 Mobile IPv6 base protocol does not specify any method to 111 automatically acquire this information, which means that network 112 administrators are normally required to manually set configuration 113 data on Mobile Nodes and HAs. However, in real deployments, manual 114 configuration does not scale as the Mobile Nodes increase in 115 number. 117 As discussed in [4], several bootstrapping scenarios can be 118 identified depending on the relationship between the network 119 operator that authenticates a mobile node for granting network 120 access service (Access Service Authorizer, ASA) and the service 121 provider that authorizes Mobile IPv6 service (Mobility Service 122 Authorizer, MSA). This document describes a solution to the 123 bootstrapping problem that is applicable in a scenario where the 124 MSA and the ASA are different entities (i.e. split scenario). 126 2. Terminology 128 General mobility terminology can be found in [10]. The following 129 additional terms are used here: 131 ASA 132 Access Service Authorizer. A network operator that 133 authenticates a mobile node and establishes the mobile node's 134 authorization to receive Internet service. 136 ASP 137 Access Service Provider. A network operator that provides 138 direct IP packet forwarding to and from the end host. 140 MSA 141 Mobility Service Authorizer. A service provider that 142 authorizes Mobile IPv6 service. 144 MSP 145 Mobility Service Provider. A service provider that provides 146 Mobile IPv6 service. In order to obtain such service, the 147 mobile node must be authenticated and prove authorization to 148 obtain the service. 150 Split scenario 151 A scenario where mobility service and network access service 152 are authorized by different entities. This implies that MSA is 153 different from ASA. 155 3. Split scenario 157 In the problem statement description [4] there is a clear 158 assumption that mobility service and network access service can be 159 separate. This assumption implies that mobility service and 160 network access service may be authorized by different entities. As 161 an example, the service model defined in [4] allows an enterprise 162 network to deploy a Home Agent and offer Mobile IPv6 service to a 163 user, even if the user is accessing the Internet independent of 164 its enterprise account (e.g., by using his personal WiFi hotspot 165 account at a coffee shop). 167 Therefore, in this document it is assumed that network access and 168 mobility service are authorized by different entities, which means 169 that authentication and authorization for mobility service and 170 network access will be considered separately. This scenario is 171 called split scenario. 173 Moreover, the model defined in [4] separates the entity providing 174 the service from the entity that authenticates and authorizes the 175 user. This is similar to the roaming model for network access. 176 Therefore, in the split scenario, two different cases can be 177 identified depending on the relationship between the entity that 178 provides the mobility service (i.e. Mobility Service Provider, 179 MSP) and the entity that authenticates and authorizes the user 180 (i.e. Mobility Service Authorizer, MSA). 182 Figure 1 depicts the split scenario when the MSP and the MSA are 183 the same entity. This means that the network operator that 184 provides the Home Agent authenticates and authorizes the user for 185 mobility service.. 187 Mobility Service 188 Provider and Authorizer 189 +-------------------------------------------+ 190 | | 191 | +-------------+ +--+ | 192 | | MSA/MSP AAA | <-------------> |HA| | 193 | | server | AAA protocol +--+ | 194 | +-------------+ | 195 | | 196 +-------------------------------------------+ 198 +--+ 199 |MN| 200 +--+ 202 Figure 1 - Split Scenario (MSA == MSP) 204 Figure 2 shows the split scenario in case the MSA and the MSP are 205 two different entities. This might happen if the Mobile Node is 206 far from its MSA network and is assigned a closer HA to optimize 207 performance or if the MSA cannot provide any Home Agent and relies 208 on a third party (i.e. the MSP) to grant mobility service to its 209 users. Notice that the MSP might be or might not also be the 210 network operator that is providing network access (i.e. ASP, 211 Access Service Provider). 213 Mobility Service 214 Authorizer 215 +-------------+ 216 | MSA AAA | 217 | server | 218 +-------------+ 219 ^ 220 | 221 AAA protocol | 222 | Mobility Service 223 | Provider 224 +--------|----------------------------------+ 225 | V | 226 | +-------------+ +--+ | 227 | | MSP AAA | <-------------> |HA| | 228 | | server | AAA protocol +--+ | 229 | +-------------+ | 230 | | 231 +-------------------------------------------+ 233 +--+ 234 |MN| 235 +--+ 237 Figure 2 - Split Scenario (MSA != MSP) 239 Note that Figure 1 and Figure 2 assume the use of an AAA protocol 240 to authenticate and authorize the Mobile Node for mobility 241 service. However, since IKEv2 allows EAP client authentication 242 only and the server authentication needs to be performed based on 243 certificates or public keys, the Mobile Node potentially requires 244 a certificate revocation list check (CTL check) even though an AAA 245 potocol is used to authenticate and authorize the Mobile Node for 246 mobility service. 248 If, instead, a PKI is used, the Mobile Node and HA exchange 249 certificates and there is no AAA server involved [23]. This is 250 conceptually similar to Figure 1, since the MSP == MSA, except the 251 Home Agent, and potentially the Mobile Node, may require a 252 certificate revocation list check (CRL check) with the Certificate 253 Authority (CA). The CA may be either internal or external to the 254 MSP. Figure 3 illustrates. 256 Certificate 257 Authority 258 +-------------+ 259 | CA | 260 | server | 261 +-------------+ 262 ^ 263 | 264 CRL Check | 265 | Mobility Service 266 | Provider and Authorizer 267 +--------|----------+ 268 | V | 269 | +-------------+ | 270 | | HA | | 271 | | | | 272 | +-------------+ | 273 | | 274 +-------------------+ 276 +--+ 277 |MN| 278 +--+ 280 Figure 3 - Split Scenario with PKI 282 The split scenario is the simplest model that can be identified, 283 since no assumptions about the access network are made. This 284 implies that the mobility service is bootstrapped independently 285 from the authentication protocol for network access used (e.g. 286 PANA, EAP). For this reason, the solution described in this 287 document and developed for this scenario could also be applied to 288 the integrated access network deployment model [4], even if it 289 might not be optimized. 291 4. Components of the solution 293 The bootstrapping problem is composed of different sub-problems 294 that can be solved independently in a modular way. The components 295 identified and a brief overview of their solution follow. 297 o HA address discovery. The Mobile Node needs to discover the 298 address of its Home Agent. The main objective of a 299 bootstrapping solution is to minimize the data pre-configured 300 on the Mobile Node. For this reason, the DHAAD defined in [2] 301 may not be applicable in real deployments since it is required 302 that the Mobile Node is pre-configured with the home network 303 prefix and it does not allow an operator to load balance by 304 having Mobile Nodes dynamically assigned to Home Agents located 305 in different subnets. This document defines a solution for Home 306 Agent address discovery that is based on Domain Name Service 307 (DNS), introducing a new DNS SRV record [5]. The unique 308 information that needs to be pre-configured on the Mobile Node 309 is the domain name of the MSP. 311 o IPsec Security Associations setup. Mobile IPv6 requires that a 312 Mobile Node and its Home Agent share an IPsec SA in order to 313 protect binding updates and other Mobile IPv6 signaling. This 314 document provides a solution that is based on IKEv2 and follows 315 what is specified in [6]. The IKEv2 peer authentication can be 316 performed both using certificates and using EAP, depending on 317 the network operator's deployment model. 319 o Home Address (HoA) assignment. The Mobile Node needs to know 320 its Home Address in order to bootstrap Mobile IPv6 operation. 321 The Home Address is assigned by the Home Agent during the IKEv2 322 exchange (as described in [6]). The solution defined in this 323 document also allows the Mobile Node to auto-configure its Home 324 Address based on stateless auto-configuration ([22]), 325 Cryptographically Generated Addresses ([11]) or privacy 326 addresses ([12]). 328 o Authentication and Authorization with MSA. The user must be 329 authenticated in order for the MSP to grant the service. Since 330 the user credentials can be verified only by the MSA, this 331 authorization step is performed by the MSA. Moreover, the 332 mobility service must be explicitly authorized by the MSA based 333 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 341 this service, many networking applications use the FQDN to obtain 342 an 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 351 the previous section. 353 5.1. Home Agent Address Discovery 355 Once a Mobile Node has obtained network access, it can perform 356 Mobile IPv6 bootstrapping. For this purpose, the Mobile Node 357 queries the DNS server to request information on Home Agent 358 service. As mentioned before in the document, the only information 359 that needs to be pre-configured on the Mobile Node is the domain 360 name of the 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 364 the Mobile Node or obtained through DHCPv6 from the visited link 365 [13]. In any case, it is assumed that there is some kind of 366 mechanism by which the Mobile Node is configured with a DNS server 367 since a DNS server is needed for many other reasons. 369 Two options for DNS lookup for a Home Agent address are identified 370 in 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 374 balance different Mobile Nodes among Home Agents. It is possible 375 for an MSP to achieve coarse-grained load balancing by dynamically 376 updating the SRV RR priorities to reflect the current load on the 377 MSP's collection of Home Agents. Mobile Nodes then use the 378 priority mechanism to preferentially select the least loaded HA. 379 The effectiveness of this technique depends on how much of a load 380 it will place on the DNS servers, particularly if dynamic DNS is 381 used for frequent updates. 383 While this document specifies a Home Agent Address Discovery 384 solution based on DNS, when the ASP and the MSP are the same 385 entity DHCP may be used. See [17] for details. 387 5.1.1. DNS lookup by Home Agent Name 389 In this case, the Mobile Node is configured with the Fully 390 Qualified Domain Name of the Home Agent. As an example, the Mobile 391 Node could be configured with the name "ha1.example.com", where 392 "example.com" is the domain name of the MSP granting the mobility 393 service. 395 The Mobile Node constructs a DNS request, by setting the QNAME to 396 the name of the Home Agent. The request has QTYPE set to 'AAAA', 397 so that the DNS server sends the IPv6 address of the Home Agent. 398 Once the DNS server replies to this query, the Mobile Node knows 399 its Home Agent address and can run IKEv2 in order to set up the 400 IPsec SAs and get a Home Address. 402 Additionally, the ability to provide a mobile node with a 403 localized home agent (e.g. on the visited link) can help to 404 optimize handover signaling and improve routing efficiency in bi- 405 directional tunneling mode. There are a variety of ways this can 406 be achieved in an interoperable way. One way is to provision the 407 mobile node with an FQDN for a local home agent when it configures 408 for the local link. Another way is to specify an interoperable 409 naming convention for constructing home agent FQDNs based on 410 location. For example, an operator might assign the FQDN 411 "ha.locationA.operator.com" to the Home Agent located in "location 412 A" and the FQDN "ha.locationB.operator.com" to the Home Agent 413 located in "location B". If the Mobile Node wants to use a Home 414 Agent located in "location A", it will set the QNAME to 415 "ha.locationA.operator.com" in the DNS request. The exact way in 416 which localized Home Agents are configured is out of scope for 417 this draft. 419 5.1.2. DNS lookup by service name 421 RFC 2782 [5] defines the service resource record (SRV RR) that 422 allows an operator to use several servers for a single domain, to 423 move services from host to host, and to designate some hosts as 424 primary servers for a service and others as backups. Clients ask 425 for a specific service/protocol for a specific domain and get back 426 the names of any available servers. 428 RFC 2782[5] also describes the policies to choose a service agent 429 based on the preference and weight values. The DNS SRV record may 430 contain the preference and weight values for multiple Home Agents 431 available to the Mobile Node in addition to the Home Agent FQDNs. 432 If multiple Home Agents are available in the DNS SRV record then 433 Mobile Node is responsible for processing the information as per 434 policy and for picking one Home Agent. If the Home Agent of choice 435 does not respond for some reason or the IKEv2 authentication 436 fails, the Mobile Node SHOULD try other Home Agents on the list. 438 The service name for Mobile IPv6 Home Agent service as required by 439 RFC 2782 is "mip6" and the protocol name is "ipv6". Note that a 440 transport name cannot be used here because Mobile IPv6 does not 441 run over a transport protocol. 443 The SRV RR has a DNS type code of 33. As an example, the Mobile 444 constructs a request with QNAME set to "_mip6._ipv6.example.com" 445 and QTYPE to SRV. The reply contains the FQDNs of one or more 446 servers, that can then be resolved in a separate DNS transaction 447 to the IP addresses. However, if there is room in the SRV reply, 448 it is RECOMMENDED that the DNS server also return the IP addresses 449 of the Home Agents in AAAA records as part of the additional data 450 section (in order to avoid requiring an additional DNS round trip 451 to resolve the FQDNs). 453 5.1.3. Anycast Address for Home Agent Assignment 455 A FQDN MAY be bound to an IPv6 anycast address rather than to a 456 unicast address for a Home Agent. Since anycast addresses are 457 indistinguishable from unicast addresses, there is no distinction 458 in the AAAA record between a unicast address and an anycast 459 address. The anycast address allows the home network to assign a 460 Home Agent to a Mobile Node on a case by case basis at the time 461 that the Mobile Node bootstraps, rather than having the Mobile 462 Node select the Home Agent address. Section 5.2.1. below describes 463 how the IKEv2 transaction is modified by anycast Home Agent 464 assignment. A FQDN bound to an anycast address MAY be returned by 465 a SRV RR query. Mobile Nodes that implement this specification 466 MUST be prepared to handle an anycast address for Home Agent 467 assignment. 469 The anycast address reserved by RFC 2526 [8] for Home Agents on 470 the same link MAY be used for bootstrapping. Other deployment- 471 specific anycast addresses, spanning a wider topology, MAY also be 472 used. 474 Note that anycast forwarding as specified in RFC 4291 [9] allows 475 the node which has the anycast address assigned to one of its 476 network interfaces to make the decision about to which address 477 forwarding should occur based only on routing metric information. 478 Use of any other criteria, such as load balancing or service 479 profile offered by the Home Agent, in a standardized way is 480 currently unsupported. Assignment based on other criteria than 481 routing metrics can be achieved by having the home agent receiving 482 the forwarded message perform the home agent selection based on 483 other critera, but the mechanism for this is out of scope of this 484 draft. 486 5.2. IPsec Security Associations setup 488 As soon as the Mobile Node has discovered the Home Agent Address, 489 it establishes an IPsec Security Association with the Home Agent 490 itself through IKEv2. The detailed description of this procedure 491 is provided in [6]. If the Mobile Node wants the HA to register 492 the Home Address in the DNS, it MUST use the FQDN as the initiator 493 identity in IKE_AUTH step of the IKEv2 exchange (IDi). This is 494 needed because the Mobile Node has to provide it is the owner of 495 the FQDN provided in the subsequent DNS Update Option. See section 496 6 and section 9 for a more detailed analysis on this issue. 498 The IKEv2 Mobile Node to Home Agent authentication can be 499 performed using either IKEv2 public key signatures or the 500 Extensible Authentication Protocol (EAP). The details about how to 501 use IKEv2 authentication are described in [6] and [7]. Choice of 502 an IKEv2 peer authentication method depends on the deployment. 503 However, IKEv2 restricts the Home Agent to Mobile Node 504 authentication to use public key signature-based authentication. 506 5.2.1. IKEv2 Transaction With Anycast Home Agent Assignment 508 If an anycast address is returned in response to DNS resolution of 509 an FQDN, the IKEv2 transaction between the Mobile Node and Home 510 Agent is slightly modified. The Mobile Node sends the IKE_SA_INIT 511 request to the anycast address. The node which has the anycast 512 address assigned to one of its network interfaces selects a Home 513 Agent address from the set of Home Agents managed by the node, and 514 forwards the IKE_SA_INIT. If the set of Home Agents is empnty, the 515 node simply drops the packet. The Home Agent answers using its own 516 address, and includes an "under attack" cookie, in accordance with 517 RFC 4306 [7]. The Mobile Node notes the Home Agent address and 518 resends the IKE_SA_INIT message to the Home Agent, along with the 519 cookie. 521 The resulting IKE_SA_INIT transaction is the following: 523 Initiator Responder ("best" HA) 524 ----------- --------------------- 526 (IP_I:500 -> ANYCAST:500) 527 HDR(A,0), SAi1, KEi, Ni --> 529 (IP_R:500 -> IP_I:500) 530 <-- HDR(A,0), N(COOKIE) 532 (IP_I:500 -> IP_R:500) 533 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 535 (IP_R:500 -> IP_I:500) 536 <-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ] 538 (IP_I:500 -> IP_R:500) 539 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] 540 [IDr,]AUTH, SAi2, TSi, TSr} --> 542 (IP_R:500 -> IP_I:500) 543 <-- HDR(A,B), SK {IDr, [CERT,] AUTH, 544 SAr2, TSi, TSr} 546 Note that this procedure requires the implementation of anycast 547 forwarding in such a way that the Home Agent can distinguish 548 between an IKE_SA_INIT forwarded through an anycast address and 549 one sent directly from the Mobile Node. Home Agents SHOULD NOT 550 include an "under attack" cookie unless the IKE_SA_INIT was 551 forwarded through an anycast address or the Home Agent believes 552 that it is, in fact, under attack, in order to maintain 553 conformance with RFC 4306 for other applications. 555 5.3. Home Address assignment 557 Home Address assignment is performed during the IKEv2 exchange. 558 The Home Address can be assigned directly by the Home Agent or can 559 be auto-configured by the Mobile Node. 561 5.3.1. Home Address assignment by the Home Agent 563 When the Mobile Node runs IKEv2 with its Home Agent, it can 564 request a HoA through the Configuration Payload in the IKE_AUTH 565 exchange by including an INTERNAL_IP6_ADDRESS attribute. When the 566 Home Agent processes the message, it allocates a HoA and sends it 567 a CFG_REPLY message. The Home Agent could consult a DHCP server on 568 the home link for the actual home address allocation. This is 569 explained in detail in [6]. 571 5.3.2. Home Address auto-configuration by the Mobile Node 573 With the type of assignment described in the previous section, the 574 Home Address cannot be generated based on Cryptographically 575 Generated Addresses (CGAs) [11] or based on the privacy extensions 576 for stateless auto-configuration [12]. However, the Mobile Node 577 might want to have an auto-configured HoA based on these 578 mechanisms. It is worthwhile to mention that the auto- 579 configuration procedure described in this section cannot be used 580 in some possible deployments, since the Home Agents might be 581 provisioned with pools of allowed Home Addresses. 583 In the simplest case, the Mobile Node is provided with a pre- 584 configured home prefix and home prefix length. In this case the 585 Mobile Node creates a Home Address based on the pre-configured 586 prefix and sends it to the Home Agent including an 587 INTERNAL_IP6_ADDRESS attribute in a Configuration Payload of type 588 CFG_REQUEST. If the Home Address is valid, the Home Agent replies 589 with a CFG_REPLY, including an INTERNAL_IP6_ADDRESS with the same 590 address. If the Home Address provided by the Mobile Node is not 591 valid, the Home Agent assigns a different Home Address including 592 an INTERNAL_IP6_ADDRESS attribute with a new value. According to 593 [7] the Mobile Node MUST use the address sent by the Home Agent. 594 Later, if the Mobile Node wants to use an auto-configured Home 595 Address (e.g. based on CGA), it can run Mobile Prefix Discovery, 596 obtain a prefix, auto-configure a new Home Address and then 597 perform a new CREATE_CHILD_SA exchange. 599 If the Mobile Node is not provided with a pre-configured Home 600 Prefix, the Mobile cannot simply propose an auto-configured HoA in 601 the Configuration Payload since the Mobile Node does not know the 602 home prefix before the start of the IKEv2 exchange. The Mobile 603 Node must obtain the home prefix and the home prefix length before 604 it can configure a home address. 606 One simple solution would be for the Mobile Node to just assume 607 that the prefix length on the home link is 64 bits and extract the 608 home prefix from the Home Agent's address. The disadvantage with 609 this solution is that the home prefix cannot be anything other 610 than /64. Moreover, this ties the prefix on the home link and the 611 Home Agent's address, but, in general, a Home Agent with a 612 particular address should be able to serve a number of prefixes on 613 the home link, not just the prefix from which its address is 614 configured. 616 Another solution would be for the Mobile Node to assume that the 617 prefix length on the home link is 64 bits and send its interface 618 identifier to the Home Agent in the INTERNAL_IP6_ADDRESS attribute 619 within the CFG_REQ payload. Even though this approach does not tie 620 the prefix on the home link and the Home Agent's address, it still 621 requires that the home prefix length is 64 bits. 623 For this reason the Mobile Node needs to obtain the home link 624 prefixes through the IKEv2 exchange. In the Configuration Payload 625 during the IKE_AUTH exchange, the Mobile Node includes the 626 MIP6_HOME_PREFIX attribute in the CFG_REQUEST message. The Home 627 Agent, when it processes this message, should include in the 628 CFG_REPLY payload prefix information for one prefix on the home 629 link. This prefix information includes the prefix length (see 630 section 8.2). The Mobile Node auto-configures a Home Address from 631 the prefix returned in the CFG_REPLY message and runs a 632 CREATE_CHILD_SA exchange to create security associations for the 633 new Home Address. 635 As mentioned before in this document, there are deployments where 636 auto-configuration of the Home Address cannot be used. In this 637 case, when the Home Agent receives a CFG_REQUEST including a 638 MIP6_HOME_PREFIX attribute, in the subsequent IKE response it 639 includes a Notify Payload type "USE_ASSIGNED_HoA" and the related 640 Home Address in a INTERNAL_IP6_ADDRESS attribute. If the Mobile 641 Node gets a "USE_ASSIGNED_HoA" Notify Payload in response to the 642 Configuration Payload containing the MIP6_HOME_PREFIX attribute, 643 it looks for an INTERNAL_IP6_ADDRESS attribute and MUST use the 644 address contained in it in the subsequent CREATE_CHILD_SA 645 exchange. 647 When the Home Agent receives a Binding Update for the Mobile Node, 648 it performs proxy DAD for the auto-configured Home Address. If DAD 649 fails, the Home Agent rejects the Binding Update. If the Mobile 650 Node receives a Binding Acknowledgement with status 134 (DAD 651 failed), it MUST stop using the current Home Address, configure a 652 new HoA, and then run IKEv2 CREATE_CHILD_SA exchange to create 653 security associations based on the new HoA. The Mobile Node does 654 not need to run IKE_INIT and IKE_AUTH exchanges again. Once the 655 necessary security associations are created, the Mobile Node sends 656 a Binding Update for the new Home Address. 658 It is worth noting that with this mechanism, the prefix 659 information carried in MIP6_HOME_PREFIX attribute includes only 660 one prefix and does not carry all the information that is 661 typically present when received through a IPv6 router 662 advertisement. Mobile Prefix Discovery, specified in RFC 3775 [2], 663 is the mechanism through which the Mobile Node can get all 664 prefixes on the home link and all related information. That means 665 that MIP6_HOME_PREFIX attribute is only used for Home Address 666 auto-configuration and does not replace the usage of Mobile Prefix 667 Discovery for the purposes detailed in RFC 3775. 669 5.4. Authorization and Authentication with MSA 671 In a scenario where the Home Agent is discovered dynamically by 672 the Mobile Node, it is very likely that the Home Agent is not able 673 to verify by its own the credentials provided by the Mobile Node 674 during the IKEv2 exchange. Moreover, the mobility service needs to 675 be explicitly authorized based on the user's profile. As an 676 example, the Home Agent might not be aware of whether the mobility 677 service can be granted at a particular time of the day or when the 678 credit of the Mobile Node is going to expire. 680 Due to all these reasons, the Home Agent may need to contact the 681 MSA in order to authenticate the Mobile Node and authorize 682 mobility service. This can be accomplished based on a Public Key 683 Infrastructure if certificates are used and a PKI is deployed by 684 the MSP and MSA. On the other hand, if the Mobile Node is provided 685 with other types of credentials, the AAA infrastructure must be 686 used. 688 The definition of this backend communication is out of the scope 689 of this document. In [14] a list of goals for such a communication 690 is provided. 692 6. Home Address registration in the DNS 694 In order that the Mobile Node is reachable through its dynamically 695 assigned Home Address, the DNS needs to be updated with the new 696 Home Address. Since applications make use of DNS lookups on FQDN 697 to find a node, the DNS update is essential for providing IP 698 reachability to the Mobile Node, which is the main purpose of the 699 Mobile IPv6 protocol. The need for DNS updating is not discussed 700 in RFC 3775 since it assumes that the Mobile Node is provisioned 701 with a static Home Address. However, when a dynamic Home Address 702 is assigned to the Mobile Node, any existing DNS entry becomes 703 invalid and the Mobile Node becomes unreachable unless a DNS 704 update is performed. 706 Since the DNS update must be performed securely in order to 707 prevent attacks or modifications from malicious nodes, the node 708 performing this update must share a security association with the 709 DNS server. Having all possible Mobile Nodes sharing a security 710 association with the DNS servers of the MSP might be cumbersome 711 from an administrative perspective. Moreover, even if a Mobile 712 Node has a security association with a DNS server of its MSP, an 713 address authorization issue comes into the picture. A detailed 714 analysis of possible threats against DNS update is provided in 715 section 9.5. 717 Therefore, due to security and administrative reasons, it is 718 RECOMMENDED that the Home Agent perform DNS entry updates for the 719 Mobile Node. For this purpose the Mobile Node MAY include a new 720 mobility option in the Binding Update, the DNS Update option, with 721 the flag R not set in the option. This option is defined in 722 section 8 and includes the FQDN that needs to be updated. After 723 receiving the Binding Update, the Home Agent MUST update the DNS 724 entry with the identifier provided by the Mobile Node and the Home 725 Address included in the Home Address Option. The procedure for 726 sending a dynamic DNS update message is specified in [16]. The 727 dynamic DNS update SHOULD be performed in a secure way; for this 728 reason, the usage of TKEY and TSEC or DNSSEC is recommended (see 729 section 9.5. for details). As soon as the Home Agent has updated 730 the DNS, it MUST send a Binding Acknowledgement message to the 731 Mobile Node including the DNS Update mobility option with the 732 correct value in the Status field (see section 8.1). 734 This procedure can be performed directly by the Home Agent if the 735 Home Agent has a security association with the domain specified in 736 the Mobile Node's FQDN. 738 On the other hand, if the Mobile Node wants to be reachable 739 through a FQDN that belongs to the MSA, the Home Agent and the DNS 740 server that must be updated belong to different administrative 741 domains. In this case the Home Agent may not share a security 742 association with the DNS server and the DNS entry update can be 743 performed by the AAA server of the MSA. In order to accomplish 744 this, the Home Agent sends to the AAA server the FQDN-HoA pair 745 through the AAA protocol. This message is proxied by the AAA 746 infrastructure of the MSP and is received by the AAA server of the 747 MSA. The AAA server of the MSA perform the DNS update based on 748 [16]. Notice that, even in this case, the Home Agent is always 749 required to perform a DNS update for the reverse entry, since this 750 is always performed in the DNS server of the MSP. The detailed 751 description of the communication between Home Agent and AAA is out 752 of the scope of this document. More details are provided in [14]. 754 A mechanism to remove stale DNS entries is needed. A DNS entry 755 becomes stale when the related Home Address is no longer used by 756 the Mobile Node. To remove a DNS entry, the Mobile Node includes 757 in the Binding Update the DNS Update mobility option, with the 758 flag R set in the option. After receiving the Binding Update, the 759 Home Agent MUST remove the DNS entry identified by the FQDN 760 provided by the Mobile Node and the Home Address included in the 761 Home Address Option. The procedure for sending a dynamic DNS 762 update message is specified in [16]. As mentioned above, the 763 dynamic DNS update SHOULD be performed in a secure way; for this 764 reason, the usage of TKEY and TSEC or DNSSEC is recommended (see 765 section 9.5. for details). 767 If there is no explicit de-registration BU from the Mobile Node, 768 then the HA MAY use the binding cache entry expiration as a 769 trigger to remove the DNS entry. 771 7. Summary of Bootstrapping Protocol Flow 773 The message flow of the whole bootstrapping procedure when the 774 dynamic DNS update is performed by the Home Agent is depicted in 775 Figure 4. 777 +----+ +----+ +-----+ 778 | MN | | HA | | DNS | 779 +----+ +----+ +-----+ 781 IKEv2 exchange 782 (HoA configuration) 783 <======================> 785 BU (DNS update option) 786 -----------------------> 787 DNS update 788 <-------------------> 789 BA (DNS update option) 790 <----------------------- 792 Figure 4 - Dynamic DNS update by the HA 794 Figure 5 shows the message flow of the whole bootstrapping 795 procedure when the dynamic DNS update is performed by the AAA 796 server of the MSA. 798 +----+ +----+ +---+ +---+ 799 | MN | | HA | |AAA| |DNS| 800 +----+ +----+ +---+ +---+ 802 IKEv2 exchange 803 (HoA configuration) 804 <======================> 806 BU (DNS update option) 807 -----------------------> 809 AAA request 810 (FQDN, HoA) 811 <--------------> 813 DNS update 814 <-----------> 815 AAA answer 816 (FQDN, HoA) 817 <--------------> 818 BA (DNS update option) 819 <----------------------- 821 Figure 5 - Dynamic DNS update by the AAA 823 Notice that, even in this last case, the Home Agent is always 824 required to perform a DNS update for the reverse entry, since this 825 is always performed in the DNS server of the MSP. This is not 826 depicted in Figure 5. 828 8. Option and Attribute Format 830 8.1. DNS Update mobility option 832 0 1 2 3 833 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 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Option Type | Option Length | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Status |R| Reserved | MN identity (FQDN) ... 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 o Option Type - DNS-UPDATE-TYPE to be defined by IANA 842 o Option Length - 8 bit unsigned integer indicating the length of 843 the option excluding the type and length fields 845 o Status - 8 bit unsigned integer indicating the result of the 846 dynamic DNS update procedure. This field MUST be set to 0 and 847 ignored by the receiver when the DNS Update mobility option is 848 included in a Binding Update message. When the DNS Update 849 mobility option is included in the Binding Acknowledgement 850 message, values of the Status field less than 128 indicate that 851 the dynamic DNS update was performed successfully by the Home 852 Agent. Values greater than or equal to 128 indicate that the 853 dynamic DNS update was not completed by the HA. The following 854 Status values are currently defined: 856 0 DNS update performed 858 128 Reason unspecified 860 129 Administratively prohibited 862 130 DNS Update Failed 864 o R flag - if set the Mobile Node is requesting the HA to remove 865 the DNS entry identified by the FQDN specified in this option 866 and the HoA of the Mobile Node. If not set, the Mobile Node is 867 requesting the HA to create or update a DNS entry with its HoA 868 and the FQDN specified in the option. 870 o Reserved - these bits are reserved for future purposes and MUST 871 be set to 0. 873 o MN identity - the identity of the Mobile Node to be used by the 874 Home Agent to send a Dynamic DNS update. It is a variable 875 length field. 877 8.2. MIP6_HOME_PREFIX attribute 879 The MIP6_HOME_PREFIX attribute is included in the IKEv2 880 CFG_REQUEST by the Mobile Node to ask the Home Agent for the home 881 prefix and is included in the CFG_REPLY by the Home Agent to 882 provide the Mobile Node with home prefix and home prefix length. 883 The format of this attribute is equal to the format of the 884 Configuration Attributes defined in [7] and is depicted below. 886 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 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 902 ignored on receipt. 904 o Attribute Type (15 bits) - A unique identifier for the 905 MIP6_HOME_PREFIX attribute. To be assigned by IANA. 907 o Length (2 octets) - Length in octets of Value field (home 908 prefix and Prefix Length). This is multi-valued and can be 0 or 909 17. 911 o Prefix Length (2 octets) - The length in bits of the home 912 prefix specified in the field Home Prefix. 914 o Home Prefix (16 octets) - The prefix of the home link through 915 which the Mobile Node must auto-configure its Home Address. 917 o Prefix Lifetime (4 octets) - The lifetime of the Home Prefix. 919 When the MIP6_HOME_PREFIX attribute is included by the Mobile Node 920 in the CFG_REQUEST payload, the value of the Length field is 0. On 921 the other hand, when the MIP6_HOME_PREFIX attribute is included in 922 the CFG_REPLY payload by the Home Agent, the value of the Length 923 field is 17 and the attribute contains also the Home Prefix and 924 the Prefix Length fields. 926 9. Security Considerations 928 9.1. HA Address Discovery 930 Use of DNS for address discovery carries certain security risks. 931 DNS transactions in the Internet are typically done without any 932 authentication of the DNS server by the client or of the client by 933 the server. There are two risks involved: 935 1) A legitimate client obtains a bogus Home Agent address from a 936 bogus DNS server. This is sometimes called a "pharming" attack, 938 2) An attacking client obtains a legitimate Home Agent address 939 from a legitimate server. 941 The risk in Case 1 is mitigated because the Mobile Node is 942 required to conduct an IKE transaction with the Home Agent prior 943 to performing a Binding Update to establish Mobile IPv6 service. 944 According to the IKEv2 specification [7], the responder must 945 present the initiator with a valid certificate containing the 946 responder's public key, and the responder to initiator IKE_AUTH 947 message must be protected with an authenticator calculated using 948 the public key in the certificate. Thus, an attacker would have to 949 set up both a bogus DNS server and a bogus Home Agent, and 950 provision the Home Agent with a certificate that a victim Mobile 951 Node could verify. If the Mobile Node can detect that the 952 certificate is not trustworthy, the attack will be foiled when the 953 Mobile Node attempts to set up the IKE SA. 955 The risk in Case 2 is limited for a single Mobile Node to Home 956 Agent transaction if the attacker does not possess proper 957 credentials to authenticate with the Home Agent. The IKE SA 958 establishment will fail when the attacking Mobile Node attempts to 959 authenticate itself with the Home Agent. Regardless of whether the 960 Home Agent utilizes EAP or host-side certificates to authenticate 961 the Mobile Node, the authentication will fail unless the Mobile 962 Node has valid credentials. 964 Another risk exists in Case 2 because the attacker may be 965 attempting to propagate a DoS attack on the Home Agent. In that 966 case, the attacker obtains the Home Agent address from the DNS, 967 then propagates the address to a network of attacking hosts that 968 bombard the Home Agent with traffic. This attack is not unique to 969 the bootstrapping solution, however, it is actually a risk that 970 any Mobile IPv6 Home Agent installation faces. In fact, the risk 971 is faced by any service in the Internet that distributes a unicast 972 globally routable address to clients. Since Mobile IPv6 requires 973 that the Mobile Node communicate through a globally routable 974 unicast address of a Home Agent, it is possible that the Home 975 Agent address could be propagated to an attacker by various means 976 (theft of the Mobile Node, malware installed on the Mobile Node, 977 evil intent of the Mobile Node owner him/herself, etc.) even if 978 the home address is manually configured on the Mobile Node. 979 Consequently, every Mobile IPv6 Home Agent installation will 980 likely be required to mount anti-DoS measures. Such measures 981 include overprovisioning of links to and from Home Agents and of 982 Home Agent processing capacity, vigilant monitoring of traffic on 983 the Home Agent networks to detect when traffic volume increases 984 abnormally indicating a possible DoS attack, and hot spares that 985 can quickly be switched on in the event an attack is mounted on an 986 operating collection of Home Agents. DoS attacks of moderate 987 intensity should be foiled during the IKEv2 transaction. IKEv2 988 implementations are expected to generate their cookies without any 989 saved state, and to time out cookie generation parameters 990 frequently, with the timeout value increasing if a DoS attack is 991 suspected. This should prevent state depletion attacks, and should 992 assure continued service to legitimate clients until the practical 993 limits on the network bandwith and processing capacity of the Home 994 Agent network are reached. 996 Explicit security measures between the DNS server and host, such 997 DNSSEC [18] or TSIG/TKEY [19] [20] can mitigate the risk of 1) and 998 2), but these security measures are not widely deployed on end 999 nodes. These security measures are not sufficient to protect the 1000 Home Agent address against DoS attack, however, because a node 1001 having a legitimate security association with the DNS server could 1002 nevertheless intentionally or inadvertently cause the Home Agent 1003 address to become the target of DoS. 1005 Finally notice that assignment of an home agent from the serving 1006 network access provider's (local home agent) or a home agent from 1007 a nearby network (nearby home agent) may set up the potential to 1008 compromise a mobile node's location privacy. However, since a 1009 standardized mechanism of assigning local or nearby home agents is 1010 out of scope for this document, it is not possible to present 1011 detailed security considerations. Please see other drafts that 1012 contain detailed mechanisms for localized home agent assignment, 1013 such as [17], for information on the location privacy properties 1014 of particular home agent assignment mechanisms. 1016 Security considerations for discovering HA using DHCP are covered 1017 in draft-jang-dhc-haopt-01 [15]. 1019 9.2. Home Address Assignment through IKEv2 1021 Mobile IPv6 bootstrapping assigns the home address through the 1022 IKEv2 transaction. The Mobile Node can either choose to request an 1023 address, similar to DHCP, or the Mobile Node can request a prefix 1024 on the home link then auto-configure an address. 1026 RFC 3775 [2] and 3776 [3] require that a Home Agent check 1027 authorization of a home address received during a Binding Update. 1029 The Home Agent MUST set up authorization by linking the home 1030 address to the identity of the IPsec SAs used to authenticate the 1031 Binding Update message. The linking MUST be done either during the 1032 IKE_AUTH phase or CREATE_CHILD_SA phase when the IPsec SAs are 1033 constructed. 1035 If the address is auto-configured, RFC 3775 requires the Home 1036 Agent to proxy-defend the address on the home link after the 1037 Mobile Node performs the initial Binding Update. Since it is not 1038 currently possible to securely proxy CGAs using SEND, attacks on 1039 address resolution for Neighbor Discovery listed in RFC 3756 are 1040 possible on dynamically assigned home addresses that are proxied 1041 by the Home Agent. 1043 9.3. SA Establishment Using EAP Through IKEv2 1045 Security considerations for authentication of the IKE transaction 1046 using EAP are covered in draft-ietf-mip6-ikev2-ipsec [6]. 1048 9.4. Back End Security Between the HA and AAA Server 1050 Some deployments of Mobile IPv6 bootstrapping may use an AAA 1051 server to handle authorization for mobility service. This process 1052 has its own security requirements, but the back end protocol for 1053 Home Agent to AAA server interface is not covered in this draft. 1054 Please see draft-ietf-mip6-aaa-ha-goals [14] for a discussion of 1055 this interface. 1057 9.5. Dynamic DNS Update 1059 Mobile IPv6 bootstrapping recommends the Home Agent to update the 1060 Mobile Node's FQDN with a dynamically assigned home address rather 1061 than have the Mobile Node itself do it (see Section 6 above). This 1062 choice was motivated by a concern for preventing redirection-based 1063 flooding attacks (see draft-ietf-mip6-ro-sec [21] for more 1064 information about redirection-based flooding attacks and the role 1065 preventing them played in the design of Mobile IPv6 route 1066 optimization security). Exactly as for route optimization, it is 1067 possible for a node that is the legitimate owner of a DNS FQDN - 1068 in the sense that it has a security association with the DNS 1069 server allowing it to perform dynamic DNS update of its FQDN - to 1070 bind its FQDN to the address of a victim, then redirect large 1071 volumes of traffic at the victim. The attack may be propagated 1072 without the owner's knowledge, for example, if the node is 1073 compromised by malware, or it may be intentional if the node 1074 itself is the attacker. 1076 While it is possible to prevent redirection attacks through 1077 ingress filtering on access routers, ISPs have little or no 1078 incentive to deploy ingress filtering. In some cases, if an attack 1079 could result in substantial financial gain, it is even possible 1080 that a corrupt ISP may have an incentive not to deploy ingress 1081 filters such as has been the case for spam. Consequently, the 1082 security for dynamic Mobile Node FQDN update has been assigned to 1083 the Home Agent, where active network administration and vigilant 1084 defense measures are more likely to (but are not assured of) 1085 mitigating problems, and the owner of the Mobile Node is more 1086 likely to detect a problem if it occurs. 1088 If a Home Agent performs dynamic DNS update on behalf of the 1089 Mobile Node directly with the DNS server, the Home Agent MUST have 1090 a security association of some type with the DNS server. The 1091 security association MAY be established either using DNSSEC [18] 1092 or TSIG/TKEY [19][20]. A security association is required even if 1093 the DNS server is in the same administrative domain as the Home 1094 Agent. The security association SHOULD be separate from the 1095 security associations used for other purposes, such as AAA. 1097 In the case where the Mobility Service Provider is different from 1098 the Mobility Service Authorizer, the network administrators may 1099 want to limit the number of cross-administrative domain security 1100 associations. If the Mobile Node's FQDN is in the Mobility Service 1101 Authorizer's domain, since a security association for AAA 1102 signaling involved in mobility service authorization is required 1103 in any case, the Home Agent can send the Mobile Node's FQDN to the 1104 AAA server under the HA-AAA server security association, and the 1105 AAA server can perform the update. In that case, a security 1106 association is required between the AAA server and DNS server for 1107 the dynamic DNS update. See draft-ietf-mip6-aaa-ha-goals [14] for 1108 a deeper discussion of the Home Agent to AAA server interface. 1110 Regardless of whether the AAA server or Home Agent performs DNS 1111 update, the authorization of the Mobile Node to update a FQDN MUST 1112 be checked prior to the performance of the update. It is an 1113 implementation issue as to how authorization is determined. 1114 However, in order to allow this authorization step, the Mobile 1115 Node MUST use a FQDN as the IDi in IKE_AUTH step of the IKEv2 1116 exchange. The FQDN MUST be the same that will be provided by the 1117 Mobile Node in the DNS Update Option. This allows the Home Agent 1118 to get authorization information about the Mobile Node's FQDN via 1119 the AAA back end communication performed during IKEv2 exchange. 1120 The outcome of this step will give the Home Agent the necessary 1121 information to authorize the DNS update request of the Mobile 1122 Node. See draft-ietf-mip6-aaa-ha-goals [14] for details about the 1123 communication between the AAA server and the Home Agent needed to 1124 perform the authorization. Notice that if certificates are used in 1125 IKEv2, the authorization information about the FQDN for DNS update 1126 MUST be present in the certificate provided by the Mobile Node. 1128 10. IANA Considerations 1130 This document defines a new Mobility Option and a new IKEv2 1131 Configuration Attribute Type. 1133 The following values should be assigned: 1135 o from "Mobility Option" namespace ([2]): DNS-UPDATE-TYPE 1136 (section 8.1) 1138 o from "IKEv2 Configuration Payload Attribute Types" namespace 1139 ([7]): MIP6_HOME_PREFIX attribute (section 8.2) 1141 o from "IKEv2 Notify Payload Error Types" namespace ([7]): 1142 USE_ASSIGNED_HoA error type (section 5.3.2) 1144 11. Contributors 1146 This contribution is a joint effort of the bootstrapping solution 1147 design team of the MIP6 WG. The contributors include Basavaraj 1148 Patil, Alpesh Patel, Jari Arkko, James Kempf, Yoshihiro Ohba, 1149 Gopal Dommety, Alper Yegin, Junghoon Jee, Vijay Devarapalli, 1150 Kuntal Chowdury, Julien Bournelle. Francis Dupont and Kilian 1151 Weniger have contributed on the anycast HA assignment procedure. 1153 The design team members can be reached at: 1155 Gerardo Giaretta gerardo.giaretta@telecomitalia.it 1157 Basavaraj Patil basavaraj.patil@nokia.com 1159 Alpesh Patel alpesh@cisco.com 1161 Jari Arkko jari.arkko@kolumbus.fi 1163 James Kempf kempf@docomolabs-usa.com 1165 Yoshihiro Ohba yohba@tari.toshiba.com 1167 Gopal Dommety gdommety@cisco.com 1169 Alper Yegin alper.yegin@samsung.com 1171 Vijay Devarapalli vijay.devarapalli@azairenet.com 1173 Kuntal Chowdury kchowdury@starentnetworks.com 1175 Junghoon Jee jhjee@etri.re.kr 1177 Julien Bournelle julien.bournelle@int-evry.fr 1179 12. Acknowledgments 1181 The authors would like to thank Rafa Lopez, Francis Dupont, Jari 1182 Arkko, Kilian Weniger, Vidya Narayanan, Ryuji Wakikawa, Michael Ye 1183 for their valuable comments. 1185 13. References 1187 13.1. Normative References 1189 [1] Bradner, S., "Key words for use in RFCs to Indicate 1190 Requirement Levels", BCP 14, RFC 2119, March 1997. 1192 [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 1193 in IPv6", RFC 3775, June 2004. 1195 [3] Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec to 1196 Protect Mobile IPv6 Signaling between Mobile Nodes and 1197 Home Agents", RFC 3776, June 2004 1199 [4] Patel, A., "Problem Statement for bootstrapping Mobile 1200 IPv6", Internet-Draft draft-ietf-mip6-bootstrap-ps-04, 1201 February 2006. 1203 [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 1204 specifying the location of services (DNS SRV)", RFC 2782, 1205 February 2000. 1207 [6] Devarapalli, V., " Mobile IPv6 Operation with IKEv2 and the 1208 revised IPsec Architecture", Internet-Draft draft-ietf-mip6- 1209 ikev2-ipsec-04, October 2005. 1211 [7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1212 RFC 4306, December 2005. 1214 [8] Johnson, D., and Deering, S., "Reserved IPv6 Subnet Anycast 1215 Addresses", RFC 2526, March 1999 1217 [9] Hinden, R., and Deering, S., "IP Version 6 Addressing 1218 Architecture", RFC 4291, Feburary, 2006. 1220 13.2. Informative References 1222 [10] Manner, J., Kojo, M. "Mobility Related Terminology", RFC 1223 3753, June 2004. 1225 [11] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 1226 3972, March 2005. 1228 [12] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions 1229 for Stateless Address Autoconfiguration in IPv6", Internet- 1230 Draft draft-ietf-ipv6-privacy-addrs-v2-04, May 2005. 1232 [13] Droms, R., Ed., "DNS Configuration options for Dynamic Host 1233 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1234 December 2003. 1236 [14] Giaretta, G., Ed. "Goals for AAA-HA interface", Internet- 1237 Draft draft-ietf-mip6-aaa-ha-goals-01, February 2006. 1239 [15] Koodli, R., Devarapalli, V., Perkins, C., Flinck, H., 1240 "Solutions for IP Address Location Privacy in the presence 1241 of IP Mobility", Internet-Draft, draft-koodli-mip6-location- 1242 privacy-solutions-00, February 2005. 1244 [16] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. 1245 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1246 RFC 2136, April 1997. 1248 [17] Chowdhury, K., Yegin, A., Choi, J., "MIP6-bootstrapping via 1249 DHCPv6 for the Integrated Scenario", Internet-Draft, draft- 1250 ietf-mip6-bootstrapping-integrated-dhc-00, October 2005. 1252 [18] Arends, R., Austein, R., Larson, M., Massey, D., Rose, S., 1253 "DNS Security Introduction and Requirements", RFC 4033, 1254 March 2005. 1256 [19] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., Wellington, 1257 B., "Secret Key Transaction Authentication for DNS (TSIG)", 1258 RFC 2845, May 2000. 1260 [20] Eastlake 3rd, D., " Secret Key Establishment for DNS (TKEY 1261 RR)", RFC 2930, September 2000. 1263 [21] Nikander, P., Arkko, J., Aura, T., Montenegro, G., 1264 Nordmark, E., "Mobile IP version 6 Route Optimization 1265 Security Design Background", Internet-Draft, draft-ietf- 1266 mip6-ro-sec-02, October 2004. 1268 [22] Narten, T., Nordmark, E., Simpson, W., Soliman, H., 1269 "Neighbor Discovery for IP version 6 (IPv6)", Internet- 1270 Draft, draft-ietf-ipv6-2461bis-05, October 2005. 1272 [23] Adams, C., et al., "Internet X.509 Public Key Infrastructure 1273 Certificate Management Protocol (CMP)", RFC 4210, September 1274 2005. 1276 Authors' Addresses 1278 Gerardo Giaretta 1279 Telecom Italia 1280 via Reiss Romoli 274 1281 10148 Torino 1282 Italy 1284 Phone: +39 011 228 6904 1285 Email: gerardo.giaretta@telecomitalia.it 1287 James Kempf 1288 DoCoMo Labs USA 1289 181 Metro Drive 1290 Suite 300 1291 San Jose, CA, 95110 1292 USA 1294 Phone: +1 408 451 4711 1295 Email: kempf@docomolabs-usa.com 1297 Vijay Devarapalli 1298 Azaire Networks 1300 Email: vijay.devarapalli@azairenet.com 1302 Full Copyright Statement 1304 Copyright (C) The Internet Society (2006). 1306 This document is subject to the rights, licenses and restrictions 1307 contained in BCP 78, and except as set forth therein, the authors 1308 retain all their rights. 1310 This document and the information contained herein are provided on an 1311 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1312 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1313 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1314 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1315 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1316 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1318 Intellectual Property 1320 The IETF takes no position regarding the validity or scope of any 1321 Intellectual Property Rights or other rights that might be claimed to 1322 pertain to the implementation or use of the technology described in 1323 this document or the extent to which any license under such rights 1324 might or might not be available; nor does it represent that it has 1325 made any independent effort to identify any such rights. Information 1326 on the procedures with respect to rights in RFC documents can be 1327 found in BCP 78 and BCP 79. 1329 Copies of IPR disclosures made to the IETF Secretariat and any 1330 assurances of licenses to be made available, or the result of an 1331 attempt made to obtain a general license or permission for the use of 1332 such proprietary rights by implementers or users of this 1333 specification can be obtained from the IETF on-line IPR repository at 1334 http://www.ietf.org/ipr. 1336 The IETF invites any interested party to bring to its attention any 1337 copyrights, patents or patent applications, or other proprietary 1338 rights that may cover technology that may be required to implement 1339 this standard. Please address the information to the IETF at 1340 ietf-ipr@ietf.org. 1342 Acknowledgment 1344 Funding for the RFC Editor function is provided by the IETF 1345 Administrative Support Activity (IASA).