idnits 2.17.1 draft-ietf-ipsecme-ikev2-ipv6-config-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 14 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2009) is 5289 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'CERTREQ' is mentioned on line 155, but not defined == Missing Reference: 'IDr' is mentioned on line 155, but not defined ** Obsolete normative reference: RFC 4306 (ref. 'IKEv2') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. 'DHCPv6') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4718 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Eronen 3 Internet-Draft Nokia 4 Intended status: Experimental J. Laganier 5 Expires: April 29, 2010 QUALCOMM Inc. 6 C. Madson 7 Cisco Systems 8 October 26, 2009 10 IPv6 Configuration in IKEv2 11 draft-ietf-ipsecme-ikev2-ipv6-config-03 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on April 29, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 When IKEv2 is used for remote VPN access (client to VPN gateway), the 60 gateway assigns the client an IP address from the internal network 61 using IKEv2 configuration payloads. The configuration payloads 62 specified in RFC 4306 work well for IPv4, but make it difficult to 63 use certain features of IPv6. This document specifies new 64 configuration attributes for IKEv2 that allows the VPN gateway to 65 assign IPv6 prefixes to clients, enabling all features of IPv6 to be 66 used with the client-gateway "virtual link". 68 Table of Contents 70 1. Introduction and Problem Statement . . . . . . . . . . . . . . 5 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3. Current Limitations and Goals . . . . . . . . . . . . . . . . 8 73 3.1. Multiple Prefixes . . . . . . . . . . . . . . . . . . . . 8 74 3.2. Link-Local Addresses . . . . . . . . . . . . . . . . . . . 8 75 3.3. Interface Identifier Selection . . . . . . . . . . . . . . 8 76 3.4. Sharing VPN Access . . . . . . . . . . . . . . . . . . . . 9 77 3.5. General Goals . . . . . . . . . . . . . . . . . . . . . . 9 78 3.6. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.7. Additional Information . . . . . . . . . . . . . . . . . . 10 80 4. Solution Details . . . . . . . . . . . . . . . . . . . . . . . 11 81 4.1. Initial Exchanges . . . . . . . . . . . . . . . . . . . . 11 82 4.2. Reauthentication . . . . . . . . . . . . . . . . . . . . . 12 83 4.3. Creating CHILD_SAs . . . . . . . . . . . . . . . . . . . . 13 84 4.4. Relationship to Neighbor Discovery . . . . . . . . . . . . 14 85 4.5. Relationship to Existing IKEv2 Payloads . . . . . . . . . 14 86 5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 16 87 5.1. INTERNAL_IP6_LINK Configuration Attribute . . . . . . . . 16 88 5.2. INTERNAL_IP6_PREFIX Configuration Attribute . . . . . . . 16 89 5.3. LINK_ID Notify Payload . . . . . . . . . . . . . . . . . . 17 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 92 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 95 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 96 Appendix A. Design Rationale (Non-Normative) . . . . . . . . . . 24 97 A.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . . 24 98 A.2. Distributing Prefix Information . . . . . . . . . . . . . 25 99 A.3. Unique Address Allocation . . . . . . . . . . . . . . . . 25 100 A.4. Layer 3 Access Control . . . . . . . . . . . . . . . . . . 26 101 A.5. Other Considerations . . . . . . . . . . . . . . . . . . . 27 102 A.6. Alternative Solution Sketches . . . . . . . . . . . . . . 29 103 A.6.1. Version -00 Sketch . . . . . . . . . . . . . . . . . . 29 104 A.6.2. Router Aggregation Sketch #1 . . . . . . . . . . . . . 30 105 A.6.3. Router Aggregation Sketch #2 . . . . . . . . . . . . . 31 106 A.6.4. IPv4-like Sketch . . . . . . . . . . . . . . . . . . . 33 107 A.6.5. Sketch Based on RFC 3456 . . . . . . . . . . . . . . . 34 108 Appendix B. Evaluation (Non-Normative) . . . . . . . . . . . . . 35 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 111 1. Introduction and Problem Statement 113 In typical remote access VPN use (client to VPN gateway), the client 114 needs an IP address in the network protected by the security gateway. 115 IKEv2 includes a feature called "configuration payloads" that allows 116 the gateway to dynamically assign a temporary address to the client 117 [IKEv2]. 119 For IPv4, the message exchange would look as follows: 121 Client Gateway 122 -------- --------- 124 HDR(IKE_SA_INIT), SAi1, KEi, Ni --> 126 <-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ] 128 HDR(IKE_AUTH), 129 SK { IDi, CERT, [CERTREQ], AUTH, [IDr], 130 CP(CFG_REQUEST) = 131 { INTERNAL_IP4_ADDRESS(), 132 INTERNAL_IP4_DNS() }, SAi2, 133 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255), 134 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } --> 136 <-- HDR(IKE_AUTH), 137 SK { IDr, CERT, AUTH, 138 CP(CFG_REPLY) = 139 { INTERNAL_IP4_ADDRESS(192.0.2.234), 140 INTERNAL_IP4_DNS(10.11.22.33) }, 141 SAr2, 142 TSi = (0, 0-65535, 192.0.2.234-192.0.2.234), 143 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } 145 Figure 1: IPv4 configuration 147 The IPv4 case has been implemented by various vendors, and in general 148 works well. IKEv2 also defines almost identical configuration 149 payloads for IPv6: 151 Client Gateway 152 -------- --------- 154 HDR(IKE_AUTH), 155 SK { IDi, CERT, [CERTREQ], AUTH, [IDr], 156 CP(CFG_REQUEST) = 157 { INTERNAL_IP6_ADDRESS(), 158 INTERNAL_IP6_DNS() }, SAi2, 159 TSi = (0, 0-65535, 160 0:0:0:0:0:0:0:0 - 161 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF), 162 TSr = (0, 163 0-65535, 0:0:0:0:0:0:0:0 - 164 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) } --> 166 <-- HDR(IKE_AUTH), 167 SK { IDr, CERT, AUTH, 168 CP(CFG_REPLY) = 169 { INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5, 170 64), 171 INTERNAL_IP6_DNS(2001:DB8:9:8:7:6:5:4) }, 172 SAr2, 173 TSi = (0, 0-65535, 174 2001:DB8:0:1:2:3:4:5 - 175 2001:DB8:0:1:2:3:4:5), 176 TSr = (0, 0-65535, 177 0:0:0:0:0:0:0:0: - 178 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) } 180 Figure 2: IPv6 configuration 182 In other words, IPv6 is basically treated as IPv4 with larger 183 addresses. As noted in [RFC4718], this does not fully follow the 184 "normal IPv6 way of doing things", and it complicates or prevents 185 using certain features of IPv6. Section 3 describes the limitations 186 in detail. 188 This document specifies new configuration attributes for IKEv2 that 189 allows the VPN gateway to assign IPv6 prefixes to clients, enabling 190 all features of IPv6 to be used with the client-gateway "virtual 191 link". 193 2. Terminology 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in [KEYWORDS]. 199 When messages containing IKEv2 payloads are described, optional 200 payloads are shown in brackets (for instance, "[FOO]"), and a plus 201 sign indicates that a payload can be repeated one or more times (for 202 instance, "FOO+"). 204 This document uses the term "virtual interface" when describing how 205 the client uses the IPv6 address(es) assigned by the gateway. While 206 existing IPsec documents do not use this term, it is not a new 207 concept. In order to use the address assigned by the VPN gateway, 208 current VPN clients already create a local "virtual interface", as 209 only addresses assigned to interfaces can be used, e.g., as source 210 addresses for TCP connections. Note that this definition of 211 "interface" is not necessarily identical with what some particular 212 implementation calls "interface". 214 3. Current Limitations and Goals 216 This section describes the limitations of the current IPv6 217 configuration mechanism, and requirements for the new solution. 219 3.1. Multiple Prefixes 221 In Figure 2 only a single IPv6 address (from a single prefix) is 222 assigned. The specification does allow the client to include 223 multiple INTERNAL_IP6_ADDRESS attributes in its request, but the 224 gateway cannot assign more addresses than the client requested. 226 Multiple prefixes are useful for site renumbering, host-based site 227 multihoming [SHIM6], and unique local IPv6 addresses [RFC4193]. In 228 all of these cases, the gateway has better information on how many 229 different addresses (from different prefixes) the client should be 230 assigned. 232 The solution should support assigning address from multiple prefixes, 233 without requiring the client to know beforehand how many prefixes are 234 needed. 236 3.2. Link-Local Addresses 238 The IPv6 addressing architecture [IPv6Addr] specifies that "IPv6 239 addresses of all types are assigned to interfaces, not nodes. [..] 240 All interfaces are required to have at least one Link-Local unicast 241 address". 243 Currently, the virtual interface created by IKEv2 configuration 244 payloads does not have link-local addresses. This violates the 245 requirements in [IPv6Addr] and prevents the use of protocols that 246 require link-local addresses, such as [MLDv2] and [DHCPv6]. 248 The solution should assign link-local addresses to the virtual 249 interfaces, and allow them to be used for protocols between the VPN 250 client and gateway. 252 3.3. Interface Identifier Selection 254 In the message exchange shown in Figure 2, the gateway chooses the 255 interface ID used by the client. It is also possible for the client 256 to request a specific interface ID; the gateway then chooses the 257 prefix part. 259 This approach complicates the use of Cryptographically Generated 260 Addresses [CGA]. With CGAs, the interface ID cannot be calculated 261 before the prefix is known. The client could first obtain a non-CGA 262 address to determine the prefix, and then send a separate CFG_REQUEST 263 to obtain a CGA address with the same prefix. However, this approach 264 requires that the IKEv2 software component provides an interface to 265 the component managing CGAs; an ugly implementation dependency that 266 would be best avoided. 268 Similar concerns apply to other cases where the client has some 269 interest in what interface ID is being used, such as Hash-Based 270 Addresses [HBA] and privacy addresses [RFC4941]. 272 Without CGAs and HBAs, VPN clients are not able to fully use IPv6 273 features such as [SHIM6] or enhanced Mobile IPv6 route optimization 274 [RFC4866]. 276 The solution should allow the VPN client to easily obtain several 277 addresses from a given prefix, where the interface IDs are selected 278 by the client, and may depend on the prefix. 280 3.4. Sharing VPN Access 282 Some VPN clients may want to share the VPN connection with other 283 devices (e.g., from a cell phone to a laptop, or vice versa) via some 284 local area network connection (such as Wireless LAN or Bluetooth), if 285 allowed by the security policy. 287 Quite obviously sharing of VPN access requires more than one address 288 (unless NAT is used). However, the current model where each address 289 is requested separately is probably complex to integrate with a local 290 area network that uses stateless address autoconfiguration 291 [AUTOCONF]. Thus, obtaining a whole prefix for the VPN client, and 292 advertising that to the local link (something resembling [NDProxy]) 293 would be preferable. With DHCPv6 prefix delegation [RFC3633], even 294 [NDProxy] and associated multi-link subnet issues would be avoided. 296 The solution should support sharing the VPN access over a local area 297 network connection when the other hosts are using stateless address 298 autoconfiguration. 300 3.5. General Goals 302 o The solution should avoid periodic messages over the VPN tunnel. 304 o Re-authentication works: the client can start a new IKE SA and 305 continue using the same addresses as before. 307 o Compatibility with other IPsec uses: Configuring a virtual IPv6 308 link (with addresses assigned in IKEv2) should not prevent the 309 same peers from using IPsec/IKEv2 for other uses (with other 310 addresses). In particular, the peers may have SPD entries and PAD 311 Child SA Authorization Data entries that are not related to the 312 virtual link; when a CHILD_SA is created, it should be unambigous 313 which entries are used. 315 o Compatibility with current IPv6 configuration: Although the 316 current IPv6 mechanism is not widely implemented, new solutions 317 should not preclude its use (e.g., by defining incompatible 318 semantics for the existing payloads). 320 o The solution should have clean implementation dependencies. In 321 particular, it should not require significant modifications to the 322 core IPv6 stack (typically part of the operating system), or 323 require the IKEv2 implementor to re-implement parts of the IPv6 324 stack (to, e.g., have access or control to functionality that is 325 currently not exposed by interfaces of the IPv6 stack). 327 o Re-use existing mechanisms as much as possible, as described in 328 [IPConfig]. Appendix A describes the rationale why this document 329 nevertheless uses IKEv2 Configuration Payloads for configuring the 330 addresses. However, Section 4.1 recommends using DHCPv6 331 Information-Request message for obtaining other configuration 332 information (such as DNS server addresses). 334 3.6. Non-Goals 336 Mobile IPv6 already defines how it interacts with IPsec/IKEv2 337 [RFC4877], and the intent of this document is not to change that 338 interaction in any way. 340 3.7. Additional Information 342 If the VPN client is assigned IPv6 address(es) from prefix(es) that 343 are shared with other VPN clients, this results in some kind of 344 multi-link subnet. [Multilink] describes issues associated with 345 multi-link subnets, and recommends that they should be avoided. 347 The original 3GPP specifications for IPv6 assigned a single IPv6 348 address to each mobile phone, resembling current IKEv2 payloads. 349 [RFC3314] described the problems with this approach, and caused 3GPP 350 to change the specifications to assign unique /64 prefix(es) for each 351 phone. 353 Due to similar concerns, the IEEE 802.16 IPv6 Convergence Sublayer 354 [RFC5121] and Proxy Mobile IPv6 [RFC5213] also assign unique 355 prefixes. 357 4. Solution Details 359 4.1. Initial Exchanges 361 1) During IKE_AUTH, the client sends a new configuration attribute, 362 INTERNAL_IP6_LINK, which requests a virtual link to be configured. 363 The attribute contains the client's interface ID for the link-local 364 address (other addresses may use other interface IDs). Typically, 365 the client would also ask for DHCPv6 server address; this is used 366 only for configuration (such as DNS server addresses), not address 367 assignment. 369 CP(CFG_REQUEST) = 370 { INTERNAL_IP6_LINK(Client's Link-Local Interface ID) 371 INTERNAL_IP6_DHCP() } 372 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 373 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 374 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 375 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 377 If the client has sent the INTERNAL_IP6_LINK configuration attribute, 378 the VPN gateway SHOULD ignore any INTERNAL_IP6_ADDRESS configuration 379 attribute present in the request. 381 The VPN gateway MUST choose for itself a link-local interface 382 identifier different than the client's one, i.e., accept the link- 383 local interface identifier proposed by the client. In case the VPN 384 gateway cannot accept the link-local interface identifier the client 385 proposed, the VPN gateway MUST fail the IPv6 address assignment by 386 including a NOTIFY payload with the INTERNAL_ADDRESS_FAILURE message. 388 The VPN Gateway then replies with an INTERNAL_IP6_LINK configuration 389 attribute that contains the IKEv2 Link ID (an identifier selected by 390 the VPN gateway, treated as an opaque octet string by the client -- 391 this will be used for reauthentication and CREATE_CHILD_SA messages), 392 the gateway's link local interface identier, and zero or more 393 INTERNAL_IP6_PREFIX attributes. The traffic selectors proposed by 394 the initiator are also narrowed to contain only the assigned 395 prefixes, and the client link-local address (FE80::)identifier. 398 CP(CFG_REPLY) = 399 { INTERNAL_IP6_LINK(Gateway's Link-Local Interface ID, 400 IKEv2 Link ID) 401 INTERNAL_IP6_PREFIX(Prefix1/64), 402 [INTERNAL_IP6_PREFIX(Prefix2/64),...], 403 [INTERNAL_IP6_DHCP(Address) ] 404 TSi = ((0, 0-65535, 405 FE80:: - 406 FE80::) 407 (0, 0-65535, 408 Prefix1::0 - 409 Prefix1::FFFF:FFFF:FFFF:FFFF), 410 [(0, 0-65535, 411 Prefix2::0 - 412 Prefix2::FFFF:FFFF:FFFF:FFFF), ...]) 413 TSr = (0, 0-65535, 414 0:0:0:0:0:0:0:0 - 415 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 417 At this point, the client can configure its link-local address 418 (FE80::), and other non-link-local unicast 419 addresses from the assigned prefixes (with any proper interface 420 identifier [IPv6Addr]). The VPN gateway MUST NOT simultaneously 421 assign the same prefixes to any other client, and MUST NOT itself 422 configure addresses from these prefixes. Thus, the client does not 423 have to perform Duplicate Address Detection (DAD). (This approach is 424 based on [IPv6PPP].) 426 The prefixes remain valid through the lifetime of the IKE SA (and its 427 continuations via rekeying). If the VPN gateway needs to remove a 428 prefix it has previously assigned, or assign a new prefix, it can do 429 so with reauthentication (either starting reauthentication itself, or 430 requesting the client to reauthenticate using [RFC4478]). 432 2) The client also contacts the DHCPv6 server. This is the 433 RECOMMENDED way to obtain additional configuration parameters (such 434 as DNS server addresses), as it allows easier extensibility and more 435 options (such as the domain search list for DNS). 437 4.2. Reauthentication 439 When the client performs reauthentication (and wants to continue 440 using the same "virtual link"), it includes the IKEv2 Link ID given 441 by the gateway in the INTERNAL_IP6_LINK attribute. 443 CP(CFG_REQUEST) = 444 { INTERNAL_IP6_LINK(Client's Link Local Interface ID, 445 IKEv2 Link ID) 446 INTERNAL_IP6_DHCP() } 447 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 448 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 449 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 450 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 452 At this point, the gateway MUST verify that the client is indeed 453 allowed to use the link identified by the IKEv2 Link ID. The same 454 situation occurs in [IKEv2] when the client wants to continue using 455 the same IPv4 address with the INTERNAL_IP4_ADDRESS configuration 456 attribute. Typically, the gateway would use the Link ID to look up 457 relevant local state, and compare the authenticated peer identity of 458 the IKE_SA with the local state. 460 If the client is allowed to continue using this link, the gateway 461 replies (see Section 4.1) with the same Gateway's Link-Local 462 Interface ID and IKEv2 Link ID as used earlier, and sends the IPv6 463 prefix(es) associated with this link. Usually, the IPv6 prefix(es) 464 will also be the same as earlier, but this is not required. 466 If the client is not allowed to continue using this link, the gateway 467 treats it as a request for a new virtual link, selects a different 468 IKEv2 Link ID value, and replies as in Section 4.1. 470 4.3. Creating CHILD_SAs 472 When a CHILD_SA is created, the peers need to determine which SPD 473 entries and PAD Child SA Authorization Data entries are used for this 474 CHILD_SA. In the basic client-to-VPN-gateway uses, the situation is 475 simple: all the matching SPD entries and Child SA Authorization Data 476 entries are related to the "virtual link" between the VPN client and 477 the VPN gateway. However, if the same peers are also using IPsec/ 478 IKEv2 for other uses (with addresses not assigned inside IKEv2), they 479 would also have SPD entries and PAD Child SA Authorization Data that 480 is not related to the virtual link. 482 If one of the peers requests a CHILD_SA and proposes traffic 483 selectors covering everything (like in Figure 2), should those be 484 narrowed to the prefixes configured with INTERNAL_IP6_PREFIX, or to 485 the other SPD/PAD entries? While some kind of heuristics are 486 possible (see Appendix A for discussion), this document specifies an 487 explicit solution: 489 The peers MUST include a LINK_ID notification, containing the IKEv2 490 Link ID, in all CREATE_CHILD_SA requests (including rekeys) that are 491 related to the virtual link. The LINK_ID notification is not 492 included in the CREATE_CHILD_SA response, or when doing IKE_SA 493 rekeying. 495 4.4. Relationship to Neighbor Discovery 497 Neighbor Discovery [IPv6ND] specifies the following mechanisms: 499 Router Discovery, Prefix Discovery, Parameter Discovery, and Address 500 Autoconfiguration are not used, as the necessary functionality is 501 implemented in IKEv2. 503 Address Resolution, Next-hop Determination, and Redirect are not 504 used, as the virtual link does not have link-layer addresses, and is 505 a point-to-point link. 507 Neighbor Unreachability Detection could be used, but is a bit 508 redundant given IKEv2 Dead Peer Detection. 510 Duplicate Address Detection is not needed, because this is a point- 511 to-point link, where the VPN gateway does not assign any addresses 512 from the global unicast prefixes, and link-local interface identifier 513 is negotiated separately. 515 Duplicate Address Detection is not needed for global unicast 516 addresses formed from the global unicast prefix(es) configured as 517 part of the IKEv2 exchange, because this is a point-to-point link, 518 where the VPN gateway does not assign any addresses from the global 519 unicast prefixes. Duplicate Address Detection may be needed for 520 link-local addresses, e.g., when the client configures a link-local 521 address as per [RFC4941]. 523 Thus, Duplicate Address Detection MAY be skipped for global unicast 524 addresses formed from the global unicast prefix(es) configured as 525 part of the IKEv2 exchange. However, Duplicate Address Detection for 526 link-local unicast addresses MUST be performed as required per some 527 other specifications, e.g., [RFC4941]. 529 4.5. Relationship to Existing IKEv2 Payloads 531 The mechanism described in this document is not intended to be used 532 at the same time as the existing INTERNAL_IP6_ADDRESS attribute. For 533 compatibility with gateways implementing only INTERNAL_IP6_ADDRESS, 534 the VPN client MAY include attributes for both mechanisms in 535 CFG_REQUEST. The capabilities and preferences of the VPN gateway 536 will then determine which is used. 538 All other attributes except INTERNAL_IP6_ADDRESS (and 539 INTENAL_ADDRESS_EXPIRY) from [IKEv2] remain valid, including the 540 somewhat confusingly named INTERNAL_IP6_SUBNET (see Section 6.3 of 541 [RFC4718] for discussion). 543 5. Payload Formats 545 5.1. INTERNAL_IP6_LINK Configuration Attribute 547 The INTERNAL_IP6_LINK configuration attribute is formatted as 548 follows: 550 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 !R| Attribute Type ! Length | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Link-Local | 556 | Interface ID | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | | 559 ~ IKEv2 Link ID ~ 560 | | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 o Reserved (1 bit) - See [IKEv2]. 565 o Attribute Type (15 bits) - INTERNAL_IP6_LINK (TBD1). 567 o Length (2 octets) - Length in octets of the Value field ( Link- 568 Local Interface ID and IKEv2 Link ID); 8 or more. 570 o Link-Local Interface ID (8 octets) - The Interface ID used for 571 link-local address (by the party that sent this attribute). 573 o IKEv2 Link ID (variable length) - The link ID (may be empty when 574 the client does not yet know the link ID). The link ID is 575 selected by the VPN gateway, and is treated as an opaque octet 576 string by the client. 578 5.2. INTERNAL_IP6_PREFIX Configuration Attribute 580 The INTERNAL_IP6_PREFIX configuration attribute is formatted as 581 follows: 583 1 2 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 !R| Attribute Type ! Length | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | | 589 | Prefix | 590 | | 591 | | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Prefix Length | 594 +-+-+-+-+-+-+-+-+ 596 o Reserved (1 bit) - See [IKEv2]. 598 o Attribute Type (15 bits) - INTERNAL_IP6_PREFIX (TBD2). 600 o Length (2 octets) - Length in octets of the Value field; in this 601 case, 17. 603 o Prefix (16 octets) - An IPv6 prefix assigned to the virtual link. 604 The low order bits of the prefix field which are not part of the 605 prefix MUST be set to zero by the sender and MUST be ignored by 606 the receiver. 608 o Prefix Length (1 octets) - The length of the prefix in bits; 609 usually 64. 611 5.3. LINK_ID Notify Payload 613 The LINK_ID notification is included in CREATE_CHILD_SA requests to 614 indicate that the SA being created is related to the virtual link. 615 If this notification is not included, the CREATE_CHILD_SA requests is 616 related to the real interface. 618 The Notify Message Type for LINK_ID is TBD3. The Protocol ID and SPI 619 Size fields are set to zero. The data associated with this 620 notification is the IKEv2 Link ID returned in the INTERNAL_IP6_LINK 621 configuration attribute. 623 6. IANA Considerations 625 This document defines two new IKEv2 configuration attributes, whose 626 values are to be allocated (have been allocated) from the "IKEv2 627 Configuration Payload Attribute Types" namespace [IKEv2]: 629 Multi- 630 Value Attribute Type Valued Length Reference 631 ------ ---------------------- ------ ------------- --------- 632 TBD1 INTERNAL_IP6_LINK NO 8 or more [this doc] 633 TBD2 INTERNAL_IP6_PREFIX YES 17 octets [this doc] 635 This document also defines one new IKEv2 notification, whose value is 636 to be allocated (has been allocated) from the "IKEv2 Notify Message 637 Types - Status Types" namespace [IKEv2]: 639 Value Notify Messages - Status Types Reference 640 ------ ------------------------------- --------- 641 TBD3 LINK_ID [this doc] 643 This document does not create any new namespaces to be maintained by 644 IANA. 646 7. Security Considerations 648 Since this document is an extension to IKEv2, the security 649 considerations in [IKEv2] apply here as well. 651 The mechanism described in this document assigns each client a unique 652 prefix, which makes using randomized interface identifiers [RFC4941] 653 ineffective from privacy point of view: the client is still uniquely 654 identified by the prefix. In some environments, it may be preferable 655 to assign a VPN client the same prefix each time a VPN connection is 656 established; other environments may prefer assigning a different 657 prefix every time for privacy reasons. (This is basically a similar 658 trade-off as in Mobile IPv6 -- using the same Home Address forever is 659 simpler than changing it often, but has privacy implications.) 661 8. Acknowledgments 663 The author would like to thank Patrick Irwin, Tero Kivinen, Chinh 664 Nguyen, Mohan Parthasarathy, Yaron Sheffer, Hemant Singh, Dave 665 Thaler, Yinghzhe Wu, and Fan Zhao for their valuable comments. 667 Many of the challenges associated with IPsec-protected "virtual 668 interfaces" have been identified before: for example, in the context 669 of protecting IPv6-in-IPv4 tunnels with IPsec [RFC4891], Provider 670 Provisioned VPNs [VLINK] [RFC3884], and Mobile IPv6 [RFC4877]. Some 671 of the limitations of assigning a single IPv6 address were identified 672 in [RFC3314]. 674 9. References 676 9.1. Normative References 678 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 679 RFC 4306, December 2005. 681 [IPv6Addr] 682 Hinden, R. and S. Deering, "IP Version 6 Addressing 683 Architecture", RFC 4291, February 2006. 685 [KEYWORDS] 686 Bradner, S., "Key words for use in RFCs to Indicate 687 Requirement Levels", RFC 2119, March 1997. 689 9.2. Informative References 691 [AUTOCONF] 692 Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 693 Address Autoconfiguration", RFC 4862, September 2007. 695 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 696 RFC 3972, March 2006. 698 [DHCPv6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 699 and M. Carney, "Dynamic Host Configuration Protocol for 700 IPv6 (DHCPv6)", RFC 3315, July 2003. 702 [HBA] Bagnulo, M., "Hash Based Addresses (HBA)", 703 draft-ietf-shim6-hba-05 (work in progress), December 2007. 705 [IPConfig] 706 Aboba, B., Thaler, D., Andersson, L., and S. Cheshire, 707 "Principles of Internet Host Configuration", RFC 5505, 708 May 2009. 710 [IPv6ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 711 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 712 September 2007. 714 [IPv6PPP] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over 715 PPP", RFC 5072, September 2007. 717 [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery 718 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 720 [MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 721 (MOBIKE)", RFC 4555, June 2006. 723 [Multilink] 724 Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 725 June 2007. 727 [NDProxy] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 728 Proxies (ND Proxy)", RFC 4389, April 2006. 730 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 731 Generation Partnership Project 3GPP) Standards", RFC 3314, 732 September 2002. 734 [RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic 735 Host Configuration Protocol (DHCPv4) Configuration of 736 IPsec Tunnel Mode", RFC 3456, January 2003. 738 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 739 Host Configuration Protocol (DHCP) version 6", RFC 3633, 740 December 2003. 742 [RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec 743 Transport Mode for Dynamic Routing", RFC 3884, 744 September 2004. 746 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 747 Addresses", RFC 4193, October 2005. 749 [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange 750 (IKEv2) Protocol", RFC 4478, April 2006. 752 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 753 Implementation Guidelines", RFC 4718, October 2006. 755 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 756 Optimization for Mobile IPv6", RFC 4866, May 2007. 758 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 759 IKEv2 and the Revised IPsec Architecture", RFC 4877, 760 April 2007. 762 [RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. 763 Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 764 RFC 4891, May 2007. 766 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 767 Extensions for Stateless Address Autoconfiguration in 768 IPv6", RFC 4941, September 2007. 770 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 772 Madanapalli, "Transmission of IPv6 via the IPv6 773 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 774 February 2008. 776 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdury, 777 K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, 778 August 2008. 780 [SHIM6] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 781 Shim Protocol for IPv6", draft-ietf-shim6-proto-12 (work 782 in progress), February 2009. 784 [VLINK] Duffy, M., "Framework for IPsec Protected Virtual Links 785 for PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00 (work in 786 progress), October 2002. 788 Appendix A. Design Rationale (Non-Normative) 790 This appendix describes some of the reasons why the solution in 791 Section 4 was selected, and lists some alternative designs that were 792 considered, but ultimately rejected. 794 Assigning a new IPv6 address to the client creates a new "virtual 795 IPv6 interface", and "virtual link" between the client and the 796 gateway. We will assume that the virtual link has the following 797 properties: 799 o The link and its interfaces are created and destroyed by the IKEv2 800 process. 802 o The link is not an IPsec SA; at any time, there can be zero or 803 more IPsec SAs covering traffic on this link. 805 o The link is not a single IKE SA; to support reauthentication, it 806 must be possible to identify the same link in another IKE SA. 808 o Not all IPsec-protected traffic between the peers is necessarily 809 related to the virtual link (although in the simplest VPN client- 810 to-gateway scenario it will be). 812 Given these assumptions and the goals described in Section 3, it 813 seems that the most important design choices to be made are the 814 following: 816 o What link/subnet model is used: in other words, the relationships 817 between VPN clients, IPv6 subnet prefixes, and link-local traffic 818 (especially link-local multicast). 820 o How information about the IPv6 prefix(es) is distributed from the 821 gateway to the clients. 823 o How to ensure unique IPv6 addresses for each client, and keep 824 forwarding state up-to-date accordingly. 826 o How layer 3 access control is done; in other words, where the 827 mechanisms for preventing address spoofing by clients are placed 828 architecturally. 830 Each of these is discussed next in turn. 832 A.1. Link Model 834 There are at least three main choices how to organize the 835 relationships between VPN clients, IPv6 subnet prefixes, and link- 836 local traffic: 838 o Point-to-point link model: each VPN client is assigned one or more 839 IPv6 prefixes; these prefixes are not shared with other clients, 840 and there is no link-local traffic between different VPN clients 841 connected to the same gateway. 843 o Multi-access link model: multiple VPN clients share the same IPv6 844 prefix. Link-local multicast packets sent by one VPN client will 845 be received by other VPN clients (VPN gateway will forward the 846 packets, possibly with MLD snooping to remove unnecessary 847 packets). 849 o "Router aggregation" link model: one form of "multi-link" subnet 850 [Multilink] where multiple VPN clients share the same IPv6 prefix. 851 Link-local multicast will not be received by other VPN clients. 853 In the multi-access link model, VPN clients who are idle (i.e., not 854 currently sending or receiving application traffic) could receive 855 significant amounts of multicast packets from other clients 856 (depending on how many other clients are connected). This is 857 especially undesirable when the clients are battery-powered; for 858 example, a PDA which keeps the VPN connection to corporate intranet 859 active 24/7. For this reason, using the multi-access link model was 860 rejected. 862 The configuration attributes specified in Section 4 use the point-to- 863 point link model. 865 A.2. Distributing Prefix Information 867 Some types of addresses, such as CGAs, require knowledge about the 868 prefix before an address can be generated. The prefix information 869 could be distributed to clients in the following ways: 871 o IKEv2 messages (Configuration Payloads). 873 o Router Advertisement messages (sent over the IPsec tunnel). 875 o DHCPv6 messages (sent over the IPsec tunnel). 877 In Section 4, the prefix information is distributed in IKEv2 878 messages. 880 A.3. Unique Address Allocation 882 In the "multi-access" and "router aggregation" link models (where a 883 single IPv6 prefix is shared between multiple VPN clients) mechanisms 884 are needed to ensure that one VPN client does not use an address 885 already used by some other client. Also, the VPN gateway has to know 886 which client is using which addresses in order to correctly forward 887 traffic. 889 The main choices seem to be the following: 891 o Clients receive the address(es) they are allowed to use in IKEv2 892 messages (Configuration Payloads). In this case, keeping track of 893 which client is using which address is trivial. 895 o Clients receive the address(es) they are allowed to use in DHCPv6 896 messages sent over the IPsec tunnel. In case the DHCPv6 server is 897 not integrated with the VPN gateway, the gateway may need to work 898 as a relay agent to keep track of which client is using which 899 address (and update its forwarding state accordingly). 901 o Clients can use stateless address autoconfiguration to configure 902 addresses and perform Duplicate Address Detection (DAD). This is 903 easy to do in multi-access link model, and can be made to work 904 with router aggregation link model if the VPN gateway traps 905 Neighbor Solicitation (NS) messages and spoofs Neighbor 906 Advertisement (NA) replies. The gateway keeps track of which 907 client is using which address (and updates its forwarding state 908 accordingly) by trapping these NS/NA messages. 910 In the point-to-point link model, the client can simply use any 911 address from the prefix, and the VPN gateway only needs to know which 912 client is using which prefix in order to forward packets correctly. 914 A.4. Layer 3 Access Control 916 It is almost always desirable to prevent one VPN client from sending 917 packets with a source address that is used by another VPN client. In 918 order to correctly forward packets destined to clients, the VPN 919 gateway obviously has to know which client is using which address; 920 the question is therefore where, architecturally, the mechanisms for 921 ingress filtering are placed. 923 o Layer 3 access control enforced by IPsec SAD/SPD: the addresses/ 924 prefixes assigned to a VPN client are reflected in the traffic 925 selectors used in IPsec Security Association and Security Policy 926 Database entries, as negotiated in IKEv2. 928 o The ingress filtering capability could be placed outside IPsec; 929 the traffic selectors in SAD/SPD entries would cover traffic that 930 would be dropped later by ingress filtering. 932 The former approach is used by the current IPv4 solution, and the 933 mechanism specified in Section 4. 935 A.5. Other Considerations 937 VPN gateway state 939 In some combinations of design choices, the amount of state 940 information required in the VPN gateway depends not only on the 941 number of clients, but also on the number of addresses used by one 942 client. With privacy addresses and potentially some uses of 943 Cryptographically Generated Addresses (CGAs), a single client 944 could have a large number of different addresses (especially if 945 different privacy addresses are used with different destinations). 947 Virtual link identifier 949 Reauthentication requires a way to uniquely identify the virtual 950 link when a second IKE SA is created. Some possible alternatives 951 are the IKE SPIs of the IKE SA where the virtual link was 952 "created" (assuming we can't have multiple virtual links within 953 the same IKE SA), a new identifier assigned when the link is 954 created, or any unique prefix or address that remains assigned to 955 the link for its entire lifetime. Section 4 specifies that the 956 gateway assigns a new IKEv2 Link ID when the link is created. The 957 client treats the Link ID as an opaque octet string; the gateway 958 uses it to identify relevant local state when reauthentication is 959 done. 961 Note that the link is not uniquely identified by the IKE peer 962 identities (because IDi is often a user identity that can be used 963 on multiple hosts at the same time), or the outer IP addresses of 964 the peers (due to NAT Traversal and [MOBIKE]). 966 Prefix lifetime 968 Prefixes could remain valid either for the lifetime of the IKE SA, 969 until explicitly cancelled, or for an explicitly specified time. 970 In Section 4 the prefixes remain valid for the lifetime of the IKE 971 SA (and its continuations via rekeying, but not reauthentication). 972 If necessary, the VPN gateway can thus add or remove prefixes by 973 triggering reauthentication. It is assumed that adding or 974 removing prefixes is a relatively rare situation, and thus this 975 document does not specify more complex solutions (such as explicit 976 prefix lifetimes, or use of CFG_SET/CFG_ACK). 978 Compatibility with other IPsec uses 980 Compatibility with other IPsec uses probably requires that when a 981 CHILD_SA is created, both peers can determine whether the CHILD_SA 982 applies to the virtual interface (at the end of the virtual link), 983 or the real interfaces IKEv2 messages are being sent over. This 984 is required to select the correct SPD to be used for traffic 985 selector narrowing and SA authorization in general. 987 One straight-forward solution is to add an extra payload to 988 CREATE_CHILD_SA requests, containing the virtual link identifier. 989 Requests not containing this payload would refer to the real link 990 (over which IKEv2 messages are being sent). 992 Another solution is to require that the peer requesting a CHILD_SA 993 proposes traffic selectors that identify the link. For example, 994 if TSi includes the peer's "outer" IP address, it's probably 995 related to the real interface, not the virtual one. Or if TSi 996 includes any of the prefixes assigned by the gateway (or the link- 997 local or multicast prefix), it is probably related to the virtual 998 interface. 1000 These heuristics can work in many situations, but have proved 1001 inadequate in the context of IPv6-in-IPv4 tunnels [RFC4891] and 1002 Provider Provisioned VPNs [VLINK] [RFC3884], and Mobile IPv6 1003 [RFC4877]. Thus, Section 4 includes the virtual link identifier 1004 in all CREATE_CHILD_SA requests that apply to the virtual 1005 interface. 1007 Example about other IPsec uses: 1009 If a VPN gateway receives a CREATE_CHILD_SA request associated 1010 with a physical Ethernet interface, requesting SA for (TSi=FE80:: 1011 something, dst=*), it would typically reject the request (or in 1012 other words, narrow it to an empty set) because it doesn't have 1013 SPD/PAD entries that would allow joe.user@example.com to request 1014 such CHILD_SAs. 1016 (However, it might have SPD/PAD entries that would allow 1017 "neighboring-router.example.com" to create such SAs, for 1018 protecting e.g. some routing protocol that uses link-local 1019 addresses.) 1021 However, the virtual interface created when joe.user@example.com 1022 authenticated and sent INTERNAL_IP6_LINK would have a different 1023 SPD/PAD, which would allow joe.user@example.com to create this SA. 1025 A.6. Alternative Solution Sketches 1027 A.6.1. Version -00 Sketch 1029 The -00 version of this draft contained the following solution 1030 sketch, which is basically a combination of (1) point-to-point link 1031 model, (2) prefix information distributed in Neighbor Advertisements, 1032 and (3) access control enforced outside IPsec. 1034 1) During IKE_AUTH, client sends a new configuration attribute, 1035 INTERNAL_IP6_LINK, which requests a virtual link to be created. The 1036 attribute contains the client's interface ID for link-local address 1037 (other addresses may use other interface IDs). 1039 CP(CFG_REQUEST) = 1040 { INTERNAL_IP6_LINK(Link-Local Interface ID) } 1041 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1042 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1043 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1044 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1046 The VPN gateway replies with its own link-local interface ID (which 1047 has to be different from the client's) and an IKEv2 Link ID (which 1048 will be used for reauthentication). 1050 CP(CFG_REPLY) = 1051 { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) } 1052 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1053 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1054 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1055 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1057 At this point, both peers configure the virtual interface with the 1058 link-local addresses. 1060 2) The next step is IPv6 stateless address autoconfiguration; that 1061 is, Router Solicitation and Router Advertisement messages sent over 1062 the IPsec SA. 1064 ESP(Router Solicitation: 1065 src=::, 1066 dst=FF02:0:0:0:0:0:0:2) --> 1068 <-- ESP(Router Advertisement: 1069 src=FE80:: 1070 dst=FF02:0:0:0:0:0:0:1, 1071 Prefix1, [Prefix2...]) 1073 After receiving the Router Advertisement, the client can configure 1074 unicast addresses from the advertised prefixes, using any proper 1075 interface ID. The VPN gateway does not simultaneously assign the 1076 same prefixes to any other client, and does not itself configure 1077 addresses from these prefixes. Thus, the client does not have to 1078 perform Duplicate Address Detection (DAD). 1080 3) Reauthentication works basically the same way as in Section 4; the 1081 client includes the IKEv2 Link ID in the INTERNAL_IP6_LINK attribute. 1083 4) Creating and rekeying IPsec SAs works basically the same way as in 1084 Section 4.3; the client includes the IKEv2 Link ID in those CHILD_SA 1085 requests that are related to the virtual link. 1087 Comments: This was changed in -01 draft based on feedback from VPN 1088 vendors: while the solution looks nice on paper, it is claimed to be 1089 unneccessarily complex to implement when the IKE implementation and 1090 IPv6 stack are from different companies. Furthermore, enforcing 1091 access control outside IPsec is a significant architectural change 1092 compared to current IPv4 solutions. 1094 A.6.2. Router Aggregation Sketch #1 1096 The following solution was sketched during the IETF 70 meeting in 1097 Vancouver together with Hemant Singh. It combines the (1) router 1098 aggregation link model, (2) prefix information distributed in IKEv2 1099 messages, (3) unique address allocation with stateless address 1100 autoconfiguration (with VPN gateway trapping NS messages and spoofing 1101 NA replies), and (4) access control enforced (partly) outside IPsec. 1103 1) During IKE_AUTH, the client sends a new configuration attribute, 1104 INTERNAL_IP6_LINK, which requests a virtual link to be created. The 1105 attribute contains the client's interface ID for link-local address 1106 (other addresses may use other interface IDs). 1108 CP(CFG_REQUEST) = 1109 { INTERNAL_IP6_LINK(Link-Local Interface ID) } 1110 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1111 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1112 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1113 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1115 The VPN gateway replies with its own link-local interface ID (which 1116 has to be different from the client's), an IKEv2 Link ID (which will 1117 be used for reauthentication and CREATE_CHILD_SA messages), and zero 1118 or more INTERNAL_IP6_PREFIX attributes. The traffic selectors 1119 proposed by the initiator are also narrowed to contain only the 1120 assigned prefixes (and the link-local prefix). 1122 CP(CFG_REPLY) = 1123 { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID), 1124 INTERNAL_IP6_PREFIX(Prefix1/64), 1125 [INTERNAL_IP6_PREFIX(Prefix2/64),...], 1126 INTERNAL_IP6_DHCP(Address) ] 1127 TSi = ((0, 0-65535, 1128 FE80:: - 1129 FE80::) 1130 (0, 0-65535, 1131 Prefix1::0 - 1132 Prefix1::FFFF:FFFF:FFFF:FFFF), 1133 [(0, 0-65535, 1134 Prefix2::0 - 1135 Prefix2::FFFF:FFFF:FFFF:FFFF), ...]) 1136 TSr = (0, 0-65535, 1137 0:0:0:0:0:0:0:0 - 1138 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1140 2) The client now configures tentative unicast addresses from the 1141 prefixes given by the gateway, and performs Duplicate Address 1142 Detection (DAD) for them. 1144 The Neighbor Solicitation messages are processed by the VPN gateway: 1145 if the target address is already in use by some other VPN client, the 1146 gateway replies with a Neighbor Advertisement. If the target address 1147 is not already in use, the VPN gateway notes that it is now being 1148 used by this client, and updates its forwarding state accordingly. 1150 Comments: The main disadvantages of this solution are non-standard 1151 processing of NS messages (which are used to update the gateway's 1152 forwarding state), and performing access control partly outside 1153 IPsec. 1155 A.6.3. Router Aggregation Sketch #2 1157 This is basically similar to the version -00 sketch described with 1158 above, but uses router aggregation link model. In other words, it 1159 combines (1) router aggregation link model, (2) prefix information 1160 distributed in Neighbor Advertisements, (3) unique address allocation 1161 with stateless address autoconfiguration (with VPN gateway trapping 1162 NS messages and spoofing NA replies), and (4) access control enforced 1163 outside IPsec. 1165 1) During IKE_AUTH, client sends a new configuration attribute, 1166 INTERNAL_IP6_LINK, which requests a virtual link to be created. The 1167 attribute contains the client's interface ID for link-local address 1168 (other addresses may use other interface IDs). 1170 CP(CFG_REQUEST) = 1171 { INTERNAL_IP6_LINK(Link-Local Interface ID) } 1172 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1173 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1174 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1175 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1177 The VPN gateway replies with its own link-local interface ID (which 1178 has to be different from the client's) and an IKEv2 Link ID (which 1179 will be used for reauthentication). 1181 CP(CFG_REPLY) = 1182 { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) } 1183 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1184 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1185 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1186 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1188 At this point, both peers configure the virtual interface with the 1189 link-local addresses. 1191 2) The next step is IPv6 stateless address autoconfiguration; that 1192 is, Router Solicitation and Router Advertisement messages sent over 1193 the IPsec SA. 1195 ESP(Router Solicitation: 1196 src=::, 1197 dst=FF02:0:0:0:0:0:0:2) --> 1199 <-- ESP(Router Advertisement: 1200 src=FE80:: 1201 dst=FF02:0:0:0:0:0:0:1, 1202 Prefix1, [Prefix2...]) 1204 3) The client now configures tentative unicast addresses from the 1205 prefixes given by the gateway, and performs Duplicate Address 1206 Detection (DAD) for them. 1208 The Neighbor Solicitation messages are processed by the VPN gateway: 1209 if the target address is already in use by some other VPN client, the 1210 gateway replies with a Neighbor Advertisement. If the target address 1211 is not already in use, the VPN gateway notes that it is now being 1212 used by this client, and updates its forwarding state accordingly. 1214 Comments: The main disadvantages of this solution are non-standard 1215 processing of NS messages (which are used to update the gateway's 1216 forwarding state), and performing access control outside IPsec. 1218 A.6.4. IPv4-like Sketch 1220 This sketch resembles the current IPv4 configuration payloads, and it 1221 combines (1) router aggregation link model, (2) prefix information 1222 distributed in IKEv2 messages, (3) unique address allocation with 1223 IKEv2 messages, and (4) access control enforced by IPsec SAD/SPD. 1225 1) During IKE_AUTH, the client sends a new configuration attribute, 1226 INTERNAL_IP6_LINK, which requests a virtual link to be created. The 1227 attribute contains the client's interface ID for link-local address 1228 (other addresses may use other interface IDs). 1230 CP(CFG_REQUEST) = 1231 { INTERNAL_IP6_LINK(Link-Local Interface ID) } 1232 TSi = (0, 0-65535, 1233 0:0:0:0:0:0:0:0 - 1234 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1235 TSr = (0, 0-65535, 1236 0:0:0:0:0:0:0:0 - 1237 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1239 The VPN gateway replies with its own link-local interface ID (which 1240 has to be different from the client's), an IKEv2 Link ID (which will 1241 be used for reauthentication and CREATE_CHILD_SA messages), and zero 1242 or more INTERNAL_IP6_ADDRESS2 attributes. Each attribute contains 1243 one address from a particular prefix. 1245 CP(CFG_REPLY) = 1246 { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID), 1247 INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID1), 1248 [INTERNAL_IP6_ADDRESS2(Prefix2+Client's Interface ID2),...], 1249 TSi = ((0, 0-65535, 1250 FE80:: - 1251 FE80::) 1252 (0, 0-65535, 1253 Prefix1:: - 1254 Prefix1::), 1255 [(0, 0-65535, 1256 Prefix2:: - 1257 Prefix2::), ...]) 1258 TSr = (0, 0-65535, 1259 0:0:0:0:0:0:0:0 - 1260 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1262 Since the VPN gateway keeps track of address uniqueness, there is no 1263 need to perform Duplicate Address Detection. 1265 2) If the client wants additional addresses later (for example, with 1266 specific interface ID), it requests them in a separate 1267 CREATE_CHILD_SA exchange. For example: 1269 CP(CFG_REQUEST) = 1270 { INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID3) } 1271 TSi = (0, 0-65535, 1272 Prefix1::0 - 1273 Prefix1::FFFF:FFFF:FFFF:FFFF>), 1274 TSr = (0, 0-65535, 1275 0:0:0:0:0:0:0:0 - 1276 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1278 If the requested address is not currently in use by some other 1279 client, the VPN gateway simply returns the same address, and traffic 1280 selectors narrowed appropriately. 1282 CP(CFG_REQUEST) = 1283 { INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID3) } 1284 TSi = ((0, 0-65535, 1285 Prefix1:: - 1286 Prefix1::), 1287 TSr = (0, 0-65535, 1288 0:0:0:0:0:0:0:0 - 1289 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1291 Comments: The main advantage of this solution is that it's quite 1292 close to the current IPv4 way of doing things. By adding explicit 1293 link creation (with Link ID for reauthentication/SPD selection, and 1294 link-local addresses), and slightly changing the semantics (and also 1295 name) of INTERNAL_IP6_ADDRESS attribute (can return more attributes 1296 than was asked), we get much of the needed functionality. 1298 The biggest disadvantages are probably potentially complex 1299 implementation dependency for interface ID selection (see 1300 Section 3.3), and the multi-link subnet model. 1302 A.6.5. Sketch Based on RFC 3456 1304 For completeness: a solution modeled after [RFC3456] would combine 1305 (1) router aggregation link model, (2) prefix information 1306 distribution and unique address allocation with DHCPv6, and (3) 1307 access control enforced by IPsec SAD/SPD. 1309 Appendix B. Evaluation (Non-Normative) 1311 Section 3described the goals and requirements for IPv6 configuration 1312 in IKEv2. This appendix briefly summarizes how the solution 1313 specified in Section 4 and Section 5 meets these goals. 1315 o (3.1) Assigning addresses from multiple prefixes is supported, 1316 without requiring the client to know beforehand how many prefixes 1317 are needed. 1319 o (3.2) Link-local addresses are assigned, and can be used for 1320 protocols between the VPN client and gateway. 1322 o (3.3) The entire prefix is assigned to a single client, so the 1323 client can freely select any number of interface IDs (which may 1324 depend on the prefix.) 1326 o (3.4) This document does not specify how the VPN client would 1327 share the VPN connection with other devices. However, since the 1328 entire prefix is assigned to a single client, the client could 1329 further assign addresses from it without requiring coordination 1330 with the VPN gateway. 1332 o (3.5) The solution does not add any new periodic messages over the 1333 VPN tunnel. 1335 o (3.5) Re-authentication works (see Section 4.2.) 1337 o (3.5) The solution is compatible with other IPsec uses, since the 1338 LINK_ID notification makes it unambiguous which CHILD_SAs are 1339 related to the virtual link and which are not (see Section 4.3 and 1340 Section 5.3.) 1342 o (3.5) The new mechanisms do not prevent the VPN client and/or 1343 gateway from implementing the INTERNAL_IP6_ADDRESS configuration 1344 attribute as well; however, the two mechanisms are not intended to 1345 be used simultaneously (see Section 4.5.) 1347 o (3.5) Implementation dependencies are, obviously, implementation 1348 dependant (and their cleanliness somewhat subjective.) Possible 1349 drawbacks of some alternative solutions are discussed in 1350 Appendix A.6. 1352 o (3.5) The mechanism for configuring the prefixes (configuration 1353 payloads) is specific to IKEv2, for reasons described in 1354 Appendix A. However, Section 4.1 recommends using DHCPv6 1355 Information-Request message for obtaining other configuration 1356 information (such as DNS server addresses.) 1358 Authors' Addresses 1360 Pasi Eronen 1361 Nokia Research Center 1362 P.O. Box 407 1363 FIN-00045 Nokia Group 1364 Finland 1366 Email: pasi.eronen@nokia.com 1368 Julien Laganier 1369 QUALCOMM Incorporated 1370 5775 Morehouse Drive 1371 San Diego, CA 92121 1372 USA 1374 Phone: +1 858 858 3538 1375 Email: julienl@qualcomm.com 1377 Cheryl Madson 1378 Cisco Systems, Inc. 1379 510 MacCarthy Drive 1380 Milpitas, CA 1381 USA 1383 Email: cmadson@cisco.com