idnits 2.17.1 draft-ietf-ipsecme-ikev2-ipv6-config-02.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 (August 20, 2009) is 5362 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'CERTREQ' is mentioned on line 154, but not defined == Missing Reference: 'IDr' is mentioned on line 154, 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: February 21, 2010 Qualcomm Inc. 6 C. Madson 7 Cisco Systems 8 August 20, 2009 10 IPv6 Configuration in IKEv2 11 draft-ietf-ipsecme-ikev2-ipv6-config-02 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 February 21, 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 . . . . . . . . . . . . 13 85 4.5. Relationship to Existing IKEv2 Payloads . . . . . . . . . 14 86 5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 15 87 5.1. INTERNAL_IP6_LINK Configuration Attribute . . . . . . . . 15 88 5.2. INTERNAL_IP6_PREFIX Configuration Attribute . . . . . . . 15 89 5.3. LINK_ID Notify Payload . . . . . . . . . . . . . . . . . . 16 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 92 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 95 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 96 Appendix A. Design Rationale (Non-Normative) . . . . . . . . . . 23 97 A.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . . 23 98 A.2. Distributing Prefix Information . . . . . . . . . . . . . 24 99 A.3. Unique Address Allocation . . . . . . . . . . . . . . . . 24 100 A.4. Layer 3 Access Control . . . . . . . . . . . . . . . . . . 25 101 A.5. Other Considerations . . . . . . . . . . . . . . . . . . . 26 102 A.6. Alternative Solution Sketches . . . . . . . . . . . . . . 28 103 A.6.1. Version -00 Sketch . . . . . . . . . . . . . . . . . . 28 104 A.6.2. Router Aggregation Sketch #1 . . . . . . . . . . . . . 29 105 A.6.3. Router Aggregation Sketch #2 . . . . . . . . . . . . . 30 106 A.6.4. IPv4-like Sketch . . . . . . . . . . . . . . . . . . . 32 107 A.6.5. Sketch Based on RFC 3456 . . . . . . . . . . . . . . . 33 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 110 1. Introduction and Problem Statement 112 In typical remote access VPN use (client to VPN gateway), the client 113 needs an IP address in the network protected by the security gateway. 114 IKEv2 includes a feature called "configuration payloads" that allows 115 the gateway to dynamically assign a temporary address to the client 116 [IKEv2]. 118 For IPv4, the message exchange would look as follows: 120 Client Gateway 121 -------- --------- 123 HDR(IKE_SA_INIT), SAi1, KEi, Ni --> 125 <-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ] 127 HDR(IKE_AUTH), 128 SK { IDi, CERT, [CERTREQ], AUTH, [IDr], 129 CP(CFG_REQUEST) = 130 { INTERNAL_IP4_ADDRESS(), 131 INTERNAL_IP4_DNS() }, SAi2, 132 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255), 133 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } --> 135 <-- HDR(IKE_AUTH), 136 SK { IDr, CERT, AUTH, 137 CP(CFG_REPLY) = 138 { INTERNAL_IP4_ADDRESS(192.0.2.234), 139 INTERNAL_IP4_DNS(10.11.22.33) }, 140 SAr2, 141 TSi = (0, 0-65535, 192.0.2.234-192.0.2.234), 142 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } 144 Figure 1: IPv4 configuration 146 The IPv4 case has been implemented by various vendors, and in general 147 works well. IKEv2 also defines almost identical configuration 148 payloads for IPv6: 150 Client Gateway 151 -------- --------- 153 HDR(IKE_AUTH), 154 SK { IDi, CERT, [CERTREQ], AUTH, [IDr], 155 CP(CFG_REQUEST) = 156 { INTERNAL_IP6_ADDRESS(), 157 INTERNAL_IP6_DNS() }, SAi2, 158 TSi = (0, 0-65535, 159 0:0:0:0:0:0:0:0 - 160 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF), 161 TSr = (0, 162 0-65535, 0:0:0:0:0:0:0:0 - 163 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) } --> 165 <-- HDR(IKE_AUTH), 166 SK { IDr, CERT, AUTH, 167 CP(CFG_REPLY) = 168 { INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5, 169 64), 170 INTERNAL_IP6_DNS(2001:DB8:9:8:7:6:5:4) }, 171 SAr2, 172 TSi = (0, 0-65535, 173 2001:DB8:0:1:2:3:4:5 - 174 2001:DB8:0:1:2:3:4:5), 175 TSr = (0, 0-65535, 176 0:0:0:0:0:0:0:0: - 177 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) } 179 Figure 2: IPv6 configuration 181 In other words, IPv6 is basically treated as IPv4 with larger 182 addresses. As noted in [RFC4718], this does not fully follow the 183 "normal IPv6 way of doing things", and it complicates or prevents 184 using certain features of IPv6. Section 3 describes the limitations 185 in detail. 187 This document specifies new configuration attributes for IKEv2 that 188 allows the VPN gateway to assign IPv6 prefixes to clients, enabling 189 all features of IPv6 to be used with the client-gateway "virtual 190 link". 192 2. Terminology 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in [KEYWORDS]. 198 When messages containing IKEv2 payloads are described, optional 199 payloads are shown in brackets (for instance, "[FOO]"), and a plus 200 sign indicates that a payload can be repeated one or more times (for 201 instance, "FOO+"). 203 This document uses the term "virtual interface" when describing how 204 the client uses the IPv6 address(es) assigned by the gateway. While 205 existing IPsec documents do not use this term, it is not a new 206 concept. In order to use the address assigned by the VPN gateway, 207 current VPN clients already create a local "virtual interface", as 208 only addresses assigned to interfaces can be used, e.g., as source 209 addresses for TCP connections. Note that this definition of 210 "interface" is not necessarily identical with what some particular 211 implementation calls "interface". 213 3. Current Limitations and Goals 215 This section describes the limitations of the current IPv6 216 configuration mechanism, and requirements for the new solution. 218 3.1. Multiple Prefixes 220 In Figure 2 only a single IPv6 address (from a single prefix) is 221 assigned. The specification does allow the client to include 222 multiple INTERNAL_IP6_ADDRESS attributes in its request, but the 223 gateway cannot assign more addresses than the client requested. 225 Multiple prefixes are useful for site renumbering, host-based site 226 multihoming [SHIM6], and unique local IPv6 addresses [RFC4193]. In 227 all of these cases, the gateway has better information on how many 228 different addresses (from different prefixes) the client should be 229 assigned. 231 The solution should support assigning address from multiple prefixes, 232 without requiring the client to know beforehand how many prefixes are 233 needed. 235 3.2. Link-Local Addresses 237 The IPv6 addressing architecture [IPv6Addr] specifies that "IPv6 238 addresses of all types are assigned to interfaces, not nodes. [..] 239 All interfaces are required to have at least one Link-Local unicast 240 address". 242 Currently, the virtual interface created by IKEv2 configuration 243 payloads does not have link-local addresses. This violates the 244 requirements in [IPv6Addr] and prevents the use of protocols that 245 require link-local addresses, such as [MLDv2] and [DHCPv6]. 247 The solution should assign link-local addresses to the virtual 248 interfaces, and allow them to be used for protocols between the VPN 249 client and gateway. 251 3.3. Interface Identifier Selection 253 In the message exchange shown in Figure 2, the gateway chooses the 254 interface ID used by the client. It is also possible for the client 255 to request a specific interface ID; the gateway then chooses the 256 prefix part. 258 This approach complicates the use of Cryptographically Generates 259 Addresses [CGA]. With CGAs, the interface ID cannot be calculated 260 before the prefix is known. The client could first obtain a non-CGA 261 address to determine the prefix, and then send a separate CFG_REQUEST 262 to obtain a CGA address with the same prefix. However, this approach 263 requires that the IKEv2 software component provides an interface to 264 the component managing CGAs; an ugly implementation dependency that 265 would be best avoided. 267 Similar concerns apply to other cases where the client has some 268 interest in what interface ID is being used, such as Hash-Based 269 Addresses [HBA] and privacy addresses [RFC4941]. 271 Without CGAs and HBAs, VPN clients are not able to fully use IPv6 272 features such as [SHIM6] or enhanced Mobile IPv6 route optimization 273 [RFC4866]. 275 The solution should allow the VPN client to easily obtain several 276 addresses from a given prefix, where the interface IDs are selected 277 by the client, and may depend on the prefix. 279 3.4. Sharing VPN Access 281 Some VPN clients may want to share the VPN connection with other 282 devices (e.g., from a cell phone to a laptop, or vice versa) via some 283 local area network connection (such as Wireless LAN or Bluetooth), if 284 allowed by the security policy. 286 Quite obviously sharing of VPN access requires more than one address 287 (unless NAT is used). However, the current model where each address 288 is requested separately is probably complex to integrate with a local 289 area network that uses stateless address autoconfiguration 290 [AUTOCONF]. Thus, obtaining a whole prefix for the VPN client, and 291 advertising that to the local link (something resembling [NDProxy]) 292 would be preferable. With DHCPv6 prefix delegation [RFC3633], even 293 [NDProxy] and associated multi-link subnet issues would be avoided. 295 The solution should support sharing the VPN access over a local area 296 network connection when the other hosts are using stateless address 297 autoconfiguration. 299 3.5. General Goals 301 o The solution should avoid periodic messages over the VPN tunnel. 303 o Re-authentication works: the client can start a new IKE SA and 304 continue using the same addresses as before. 306 o Compatibility with other IPsec uses: Configuring a virtual IPv6 307 link (with addresses assigned in IKEv2) should not prevent the 308 same peers from using IPsec/IKEv2 for other uses (with other 309 addresses). In particular, the peers may have SPD entries and PAD 310 Child SA Authorization Data entries that are not related to the 311 virtual link; when a CHILD_SA is created, it should be unambigous 312 which entries are used. 314 o Compatibility with current IPv6 configuration: Although the 315 current IPv6 mechanism is not widely implemented, new solutions 316 should not preclude its use (e.g., by defining incompatible 317 semantics for the existing payloads). 319 o The solution should have clean implementation dependencies. In 320 particular, it should not require significant modifications to the 321 core IPv6 stack (typically part of the operating system), or 322 require the IKEv2 implementor to re-implement parts of the IPv6 323 stack (to, e.g., have access or control to functionality that is 324 currently not exposed by interfaces of the IPv6 stack). 326 o Re-use existing mechanisms as much as possible, as described in 327 [IPConfig]. Appendix A describes the rationale why this document 328 nevertheless uses IKEv2 Configuration Payloads for configuring the 329 addresses. However, Section 4.1 recommends using DHCPv6 330 Information-Request message for obtaining other configuration 331 information (such as DNS server addresses). 333 3.6. Non-Goals 335 Mobile IPv6 already defines how it interacts with IPsec/IKEv2 336 [RFC4877], and the intent of this document is not to change that 337 interaction in any way. 339 3.7. Additional Information 341 If the VPN client is assigned IPv6 address(es) from prefix(es) that 342 are shared with other VPN clients, this results in some kind of 343 multi-link subnet. [Multilink] describes issues associated with 344 multi-link subnets, and recommends that they should be avoided. 346 The original 3GPP standards for IPv6 assigned a single IPv6 address 347 to each mobile phone, resembling current IKEv2 payloads. [RFC3314] 348 described the problems with this approach, and caused 3GPP to change 349 the specifications to assign unique /64 prefix(es) for each phone. 351 Due to similar concerns, the IEEE 802.16 IPv6 Convergence Sublayer 352 [RFC5121] and Proxy Mobile IPv6 [RFC5213] also assign unique 353 prefixes. 355 4. Solution Details 357 4.1. Initial Exchanges 359 1) During IKE_AUTH, the client sends a new configuration attribute, 360 INTERNAL_IP6_LINK, which requests a virtual link to be configured. 361 The attribute contains the client's interface ID for the link-local 362 address (other addresses may use other interface IDs). Typically, 363 the client would also ask for DHCPv6 server address; this is used 364 only for configuration (such as DNS server addresses), not address 365 assignment. 367 CP(CFG_REQUEST) = 368 { INTERNAL_IP6_LINK(Client's Link-Local Interface ID) 369 INTERNAL_IP6_DHCP() } 370 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 371 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 372 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 373 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 375 If the client has sent the INTERNAL_IP6_LINK configuration attribute, 376 the VPN gateway SHOULD ignore any INTERNAL_IP6_ADDRESS configuration 377 attribute present in the request. 379 The VPN gateway MUST choose for itself a link-local interface 380 identifier different than the client's one, i.e., accept the link- 381 local interface identifier proposed by the client. In case the VPN 382 gateway cannot accept the link-local interface identifier the client 383 proposed, the VPN gateway MUST fail the IPv6 address assignment by 384 including a NOTIFY payload with the INTERNAL_ADDRESS_FAILURE message. 386 The VPN Gateway then replies with an INTERNAL_IP6_LINK configuration 387 attribute that contains the IKEv2 Link ID (an identifier selected by 388 the VPN gateway, treated as an opaque octet string by the client -- 389 this will be used for reauthentication and CREATE_CHILD_SA messages), 390 the gateway's link local interface identier, and zero or more 391 INTERNAL_IP6_PREFIX attributes. The traffic selectors proposed by 392 the initiator are also narrowed to contain only the assigned 393 prefixes, and the client link-local address (FE80::)identifier. 396 CP(CFG_REPLY) = 397 { INTERNAL_IP6_LINK(Gateway's Link-Local Interface ID, 398 IKEv2 Link ID) 399 INTERNAL_IP6_PREFIX(Prefix1/64), 400 [INTERNAL_IP6_PREFIX(Prefix2/64),...], 401 [INTERNAL_IP6_DHCP(Address) ] 402 TSi = ((0, 0-65535, 403 FE80:: - 404 FE80::) 405 (0, 0-65535, 406 Prefix1::0 - 407 Prefix1::FFFF:FFFF:FFFF:FFFF), 408 [(0, 0-65535, 409 Prefix2::0 - 410 Prefix2::FFFF:FFFF:FFFF:FFFF), ...]) 411 TSr = (0, 0-65535, 412 0:0:0:0:0:0:0:0 - 413 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 415 At this point, the client can configure its link-local address 416 (FE80::), and other non-link-local unicast 417 addresses from the assigned prefixes (with any proper interface 418 identifier [IPv6Addr]). The VPN gateway MUST NOT simultaneously 419 assign the same prefixes to any other client, and MUST NOT itself 420 configure addresses from these prefixes. Thus, the client does not 421 have to perform Duplicate Address Detection (DAD). (This approach is 422 based on [IPv6PPP].) 424 The prefixes remain valid through the lifetime of the IKE SA (and its 425 continuations via rekeying). If the VPN gateway needs to remove a 426 prefix it has previously assigned, or assign a new prefix, it can do 427 so with reauthentication (either starting reauthentication itself, or 428 requesting the client to reauthenticate using [RFC4478]). 430 2) The client also contacts the DHCPv6 server. This is the 431 RECOMMENDED way to obtain additional configuration parameters (such 432 as DNS server addresses), as it allows easier extensibility and more 433 options (such as the domain search list for DNS). 435 4.2. Reauthentication 437 When the client performs reauthentication (and wants to continue 438 using the same "virtual link"), it includes the IKEv2 Link ID given 439 by the gateway in the INTERNAL_IP6_LINK attribute. 441 CP(CFG_REQUEST) = 442 { INTERNAL_IP6_LINK(Client's Link Local Interface ID, 443 IKEv2 Link ID) 444 INTERNAL_IP6_DHCP() } 445 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 446 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 447 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 448 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 450 The gateway uses the Link ID to look up relevant local state, 451 verifies that the authenticated peer identity associated with the 452 link is correct, and continues the handshake as usual. 454 4.3. Creating CHILD_SAs 456 When a CHILD_SA is created, the peers need to determine which SPD 457 entries and PAD Child SA Authorization Data entries are used for this 458 CHILD_SA. In the basic client-to-VPN-gateway uses, the situation is 459 simple: all the matching SPD entries and Child SA Authorization Data 460 entries are related to the "virtual link" between the VPN client and 461 the VPN gateway. However, if the same peers are also using IPsec/ 462 IKEv2 for other uses (with addresses not assigned inside IKEv2), they 463 would also have SPD entries and PAD Child SA Authorization Data that 464 is not related to the virtual link. 466 If one of the peers requests a CHILD_SA and proposes traffic 467 selectors covering everything (like in Figure 2), should those be 468 narrowed to the prefixes configured with INTERNAL_IP6_PREFIX, or to 469 the other SPD/PAD entries? While some kind of heuristics are 470 possible (see Appendix A for discussion), this document specifies an 471 explicit solution: 473 The peers MUST include a LINK_ID notification, containing the IKEv2 474 Link ID, in all CREATE_CHILD_SA requests (including rekeys) that are 475 related to the virtual link. The LINK_ID notification is not 476 included in the CREATE_CHILD_SA response, or when doing IKE_SA 477 rekeying. 479 4.4. Relationship to Neighbor Discovery 481 Neighbor Discovery [IPv6ND] specifies the following mechanisms: 483 Router Discovery, Prefix Discovery, Parameter Discovery, and Address 484 Autoconfiguration are not used, as the necessary functionality is 485 implemented in IKEv2. 487 Address Resolution, Next-hop Determination, and Redirect are not 488 used, as the virtual link does not have link-layer addresses, and is 489 a point-to-point link. 491 Neighbor Unreachability Detection could be used, but is a bit 492 redundant given IKEv2 Dead Peer Detection. 494 Duplicate Address Detection is not needed, because this is a point- 495 to-point link, where the VPN gateway does not assign any addresses 496 from the global unicast prefixes, and link-local interface identifier 497 is negotiated separately. 499 4.5. Relationship to Existing IKEv2 Payloads 501 The mechanism described in this document is not intended to be used 502 at the same time as the existing INTERNAL_IP6_ADDRESS attribute. For 503 compatibility with gateways implementing only INTERNAL_IP6_ADDRESS, 504 the VPN client MAY include attributes for both mechanisms in 505 CFG_REQUEST. The capabilities and preferences of the VPN gateway 506 will then determine which is used. 508 All other attributes except INTERNAL_IP6_ADDRESS (and 509 INTENAL_ADDRESS_EXPIRY) from [IKEv2] remain valid, including the 510 somewhat confusingly named INTERNAL_IP6_SUBNET (see Section 6.3 of 511 [RFC4718] for discussion). 513 5. Payload Formats 515 5.1. INTERNAL_IP6_LINK Configuration Attribute 517 The INTERNAL_IP6_LINK configuration attribute is formatted as 518 follows: 520 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 !R| Attribute Type ! Length | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Link-Local | 526 | Interface ID | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | | 529 ~ IKEv2 Link ID ~ 530 | | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 o Reserved (1 bit) - See [IKEv2]. 535 o Attribute Type (15 bits) - INTERNAL_IP6_LINK (TBD1). 537 o Length (2 octets) - Length in octets of the Value field ( Link- 538 Local Interface ID and IKEv2 Link ID); 8 or more. 540 o Link-Local Interface ID (8 octets) - The Interface ID used for 541 link-local address (by the party that sent this attribute). 543 o IKEv2 Link ID (variable length) - The link ID (may be empty when 544 the client does not yet know the link ID). The link ID is 545 selected by the VPN gateway, and is treated as an opaque octet 546 string by the client. 548 5.2. INTERNAL_IP6_PREFIX Configuration Attribute 550 The INTERNAL_IP6_PREFIX configuration attribute is formatted as 551 follows: 553 1 2 3 554 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 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 !R| Attribute Type ! Length | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | | 559 | Prefix | 560 | | 561 | | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Prefix Length | 564 +-+-+-+-+-+-+-+-+ 566 o Reserved (1 bit) - See [IKEv2]. 568 o Attribute Type (15 bits) - INTERNAL_IP6_PREFIX (TBD2). 570 o Length (2 octets) - Length in octets of the Value field; in this 571 case, 17. 573 o Prefix (16 octets) - An IPv6 prefix assigned to the virtual link. 574 The low order bits of the prefix field which are not part of the 575 prefix MUST be set to zero by the sender and MUST be ignored by 576 the receiver. 578 o Prefix Length (1 octets) - The length of the prefix in bits; 579 usually 64. 581 5.3. LINK_ID Notify Payload 583 The LINK_ID notification is included in CREATE_CHILD_SA requests to 584 indicate that the SA being created is related to the virtual link. 585 If this notification is not included, the CREATE_CHILD_SA requests is 586 related to the real interface. 588 The Notify Message Type for LINK_ID is TBD3. The Protocol ID and SPI 589 Size fields are set to zero. The data associated with this 590 notification is the IKEv2 Link ID returned in the INTERNAL_IP6_LINK 591 configuration attribute. 593 6. IANA Considerations 595 This document defines two new IKEv2 configuration attributes, whose 596 values are to be allocated (have been allocated) from the "IKEv2 597 Configuration Payload Attribute Types" namespace [IKEv2]: 599 Multi- 600 Value Attribute Type Valued Length Reference 601 ------ ---------------------- ------ ------------- --------- 602 TBD1 INTERNAL_IP6_LINK NO 8 or more [this doc] 603 TBD2 INTERNAL_IP6_PREFIX YES 17 octets [this doc] 605 This document also defines one new IKEv2 notification, whose value is 606 to be allocated (has been allocated) from the "IKEv2 Notify Message 607 Types - Status Types" namespace [IKEv2]: 609 Value Notify Messages - Status Types Reference 610 ------ ------------------------------- --------- 611 TBD3 LINK_ID [this doc] 613 This document does not create any new namespaces to be maintained by 614 IANA. 616 7. Security Considerations 618 Assigning each client a unique prefix makes using randomized 619 interface identifiers [RFC4941] ineffective from privacy point of 620 view: the client is still uniquely identified by the prefix. In some 621 environments, it may be preferable to assign a VPN client the same 622 prefix each time a VPN connection is established; other environments 623 may prefer assigning a different prefix every time for privacy 624 reasons. (This is basically a similar trade-off as in Mobile IPv6 -- 625 using the same Home Address forever is simpler than changing it 626 often, but has privacy implications.) 628 8. Acknowledgments 630 The author would like to thank Patrick Irwin, Tero Kivinen, Chinh 631 Nguyen, Mohan Parthasarathy, Yaron Sheffer, Hemant Singh, Dave 632 Thaler, Yinghzhe Wu, and Fan Zhao for their valuable comments. 634 Many of the challenges associated with IPsec-protected "virtual 635 interfaces" have been identified before: for example, in the context 636 of protecting IPv6-in-IPv4 tunnels with IPsec [RFC4891], Provider 637 Provisioned VPNs [VLINK] [RFC3884], and Mobile IPv6 [RFC4877]. Some 638 of the limitations of assigning a single IPv6 address were identified 639 in [RFC3314]. 641 9. References 643 9.1. Normative References 645 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 646 RFC 4306, December 2005. 648 [IPv6Addr] 649 Hinden, R. and S. Deering, "IP Version 6 Addressing 650 Architecture", RFC 4291, February 2006. 652 [KEYWORDS] 653 Bradner, S., "Key words for use in RFCs to Indicate 654 Requirement Levels", RFC 2119, March 1997. 656 9.2. Informative References 658 [AUTOCONF] 659 Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 660 Address Autoconfiguration", RFC 4862, September 2007. 662 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 663 RFC 3972, March 2006. 665 [DHCPv6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 666 and M. Carney, "Dynamic Host Configuration Protocol for 667 IPv6 (DHCPv6)", RFC 3315, July 2003. 669 [HBA] Bagnulo, M., "Hash Based Addresses (HBA)", 670 draft-ietf-shim6-hba-05 (work in progress), December 2007. 672 [IPConfig] 673 Aboba, B., Thaler, D., Andersson, L., and S. Cheshire, 674 "Principles of Internet Host Configuration", RFC 5505, 675 May 2009. 677 [IPv6ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 678 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 679 September 2007. 681 [IPv6PPP] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over 682 PPP", RFC 5072, September 2007. 684 [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery 685 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 687 [MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 688 (MOBIKE)", RFC 4555, June 2006. 690 [Multilink] 691 Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 692 June 2007. 694 [NDProxy] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 695 Proxies (ND Proxy)", RFC 4389, April 2006. 697 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 698 Generation Partnership Project 3GPP) Standards", RFC 3314, 699 September 2002. 701 [RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic 702 Host Configuration Protocol (DHCPv4) Configuration of 703 IPsec Tunnel Mode", RFC 3456, January 2003. 705 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 706 Host Configuration Protocol (DHCP) version 6", RFC 3633, 707 December 2003. 709 [RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec 710 Transport Mode for Dynamic Routing", RFC 3884, 711 September 2004. 713 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 714 Addresses", RFC 4193, October 2005. 716 [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange 717 (IKEv2) Protocol", RFC 4478, April 2006. 719 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 720 Implementation Guidelines", RFC 4718, October 2006. 722 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 723 Optimization for Mobile IPv6", RFC 4866, May 2007. 725 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 726 IKEv2 and the Revised IPsec Architecture", RFC 4877, 727 April 2007. 729 [RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. 730 Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 731 RFC 4891, May 2007. 733 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 734 Extensions for Stateless Address Autoconfiguration in 735 IPv6", RFC 4941, September 2007. 737 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 739 Madanapalli, "Transmission of IPv6 via the IPv6 740 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 741 February 2008. 743 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdury, 744 K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, 745 August 2008. 747 [SHIM6] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 748 Shim Protocol for IPv6", draft-ietf-shim6-proto-12 (work 749 in progress), February 2009. 751 [VLINK] Duffy, M., "Framework for IPsec Protected Virtual Links 752 for PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00 (work in 753 progress), October 2002. 755 Appendix A. Design Rationale (Non-Normative) 757 This appendix describes some of the reasons why the solution in 758 Section 4 was selected, and lists some alternative designs that were 759 considered, but ultimately rejected. 761 Assigning a new IPv6 address to the client creates a new "virtual 762 IPv6 interface", and "virtual link" between the client and the 763 gateway. We will assume that the virtual link has the following 764 properties: 766 o The link and its interfaces are created and destroyed by the IKEv2 767 process. 769 o The link is not an IPsec SA; at any time, there can be zero or 770 more IPsec SAs covering traffic on this link. 772 o The link is not a single IKE SA; to support reauthentication, it 773 must be possible to identify the same link in another IKE SA. 775 o Not all IPsec-protected traffic between the peers is necessarily 776 related to the virtual link (although in the simplest VPN client- 777 to-gateway scenario it will be). 779 Given these assumptions and the goals described in Section 3, it 780 seems that the most important design choices to be made are the 781 following: 783 o What link/subnet model is used: in other words, the relationships 784 between VPN clients, IPv6 subnet prefixes, and link-local traffic 785 (especially link-local multicast). 787 o How information about the IPv6 prefix(es) is distributed from the 788 gateway to the clients. 790 o How to ensure unique IPv6 addresses for each client, and keep 791 forwarding state up-to-date accordingly. 793 o How layer 3 access control is done; in other words, where the 794 mechanisms for preventing address spoofing by clients are placed 795 architecturally. 797 Each of these is discussed next in turn. 799 A.1. Link Model 801 There are at least three main choices how to organize the 802 relationships between VPN clients, IPv6 subnet prefixes, and link- 803 local traffic: 805 o Point-to-point link model: each VPN client is assigned one or more 806 IPv6 prefixes; these prefixes are not shared with other clients, 807 and there is no link-local traffic between different VPN clients 808 connected to the same gateway. 810 o Multi-access link model: multiple VPN clients share the same IPv6 811 prefix. Link-local multicast packets sent by one VPN client will 812 be received by other VPN clients (VPN gateway will forward the 813 packets, possibly with MLD snooping to remove unnecessary 814 packets). 816 o "Router aggregation" link model: one form of "multi-link" subnet 817 [Multilink] where multiple VPN clients share the same IPv6 prefix. 818 Link-local multicast will not be received by other VPN clients. 820 In the multi-access link model, VPN clients who are idle (i.e., not 821 currently sending or receiving application traffic) could receive 822 significant amounts of multicast packets from other clients 823 (depending on how many other clients are connected). This is 824 especially undesirable when the clients are battery-powered; for 825 example, a PDA which keeps the VPN connection to corporate intranet 826 active 24/7. For this reason, using the multi-access link model was 827 rejected. 829 The configuration attributes specified in Section 4 use the point-to- 830 point link model. 832 A.2. Distributing Prefix Information 834 Some types of addresses, such as CGAs, require knowledge about the 835 prefix before an address can be generated. The prefix information 836 could be distributed to clients in the following ways: 838 o IKEv2 messages (Configuration Payloads). 840 o Router Advertisement messages (sent over the IPsec tunnel). 842 o DHCPv6 messages (sent over the IPsec tunnel). 844 In Section 4, the prefix information is distributed in IKEv2 845 messages. 847 A.3. Unique Address Allocation 849 In the "multi-access" and "router aggregation" link models (where a 850 single IPv6 prefix is shared between multiple VPN clients) mechanisms 851 are needed to ensure that one VPN client does not use an address 852 already used by some other client. Also, the VPN gateway has to know 853 which client is using which addresses in order to correctly forward 854 traffic. 856 The main choices seem to be the following: 858 o Clients receive the address(es) they are allowed to use in IKEv2 859 messages (Configuration Payloads). In this case, keeping track of 860 which client is using which address is trivial. 862 o Clients receive the address(es) they are allowed to use in DHCPv6 863 messages sent over the IPsec tunnel. In case the DHCPv6 server is 864 not integrated with the VPN gateway, the gateway may need to work 865 as a relay agent to keep track of which client is using which 866 address (and update its forwarding state accordingly). 868 o Clients can use stateless address autoconfiguration to configure 869 addresses and perform Duplicate Address Detection (DAD). This is 870 easy to do in multi-access link model, and can be made to work 871 with router aggregation link model if the VPN gateway traps 872 Neighbor Solicitation (NS) messages and spoofs Neighbor 873 Advertisement (NA) replies. The gateway keeps track of which 874 client is using which address (and updates its forwarding state 875 accordingly) by trapping these NS/NA messages. 877 In the point-to-point link model, the client can simply use any 878 address from the prefix, and the VPN gateway only needs to know which 879 client is using which prefix in order to forward packets correctly. 881 A.4. Layer 3 Access Control 883 It is almost always desirable to prevent one VPN client from sending 884 packets with a source address that is used by another VPN client. In 885 order to correctly forward packets destined to clients, the VPN 886 gateway obviously has to know which client is using which address; 887 the question is therefore where, architecturally, the mechanisms for 888 ingress filtering are placed. 890 o Layer 3 access control enforced by IPsec SAD/SPD: the addresses/ 891 prefixes assigned to a VPN client are reflected in the traffic 892 selectors used in IPsec Security Association and Security Policy 893 Database entries, as negotiated in IKEv2. 895 o The ingress filtering capability could be placed outside IPsec; 896 the traffic selectors in SAD/SPD entries would cover traffic that 897 would be dropped later by ingress filtering. 899 The former approach is used by the current IPv4 solution, and the 900 mechanism specified in Section 4. 902 A.5. Other Considerations 904 VPN gateway state 906 In some combinations of design choices, the amount of state 907 information required in the VPN gateway depends not only on the 908 number of clients, but also on the number of addresses used by one 909 client. With privacy addresses and potentially some uses of 910 Cryptographically Generated Addresses (CGAs), a single client 911 could have a large number of different addresses (especially if 912 different privacy addresses are used with different destinations). 914 Virtual link identifier 916 Reauthentication requires a way to uniquely identify the virtual 917 link when a second IKE SA is created. Some possible alternatives 918 are the IKE SPIs of the IKE SA where the virtual link was 919 "created" (assuming we can't have multiple virtual links within 920 the same IKE SA), a new identifier assigned when the link is 921 created, or any unique prefix or address that remains assigned to 922 the link for its entire lifetime. Section 4 specifies that the 923 gateway assigns a new IKEv2 Link ID when the link is created. The 924 client treats the Link ID as an opaque octet string; the gateway 925 uses it to identify relevant local state when reauthentication is 926 done. 928 Note that the link is not uniquely identified by the IKE peer 929 identities (because IDi is often a user identity that can be used 930 on multiple hosts at the same time), or the outer IP addresses of 931 the peers (due to NAT Traversal and [MOBIKE]). 933 Prefix lifetime 935 Prefixes could remain valid either for the lifetime of the IKE SA, 936 until explicitly cancelled, or for an explicitly specified time. 937 In Section 4 the prefixes remain valid for the lifetime of the IKE 938 SA (and its continuations via rekeying, but not reauthentication). 939 If necessary, the VPN gateway can thus add or remove prefixes by 940 triggering reauthentication. It is assumed that adding or 941 removing prefixes is a relatively rare situation, and thus this 942 document does not specify more complex solutions (such as explicit 943 prefix lifetimes, or use of CFG_SET/CFG_ACK). 945 Compatibility with other IPsec uses 947 Compatibility with other IPsec uses probably requires that when a 948 CHILD_SA is created, both peers can determine whether the CHILD_SA 949 applies to the virtual interface (at the end of the virtual link), 950 or the real interfaces IKEv2 messages are being sent over. This 951 is required to select the correct SPD to be used for traffic 952 selector narrowing and SA authorization in general. 954 One straight-forward solution is to add an extra payload to 955 CREATE_CHILD_SA requests, containing the virtual link identifier. 956 Requests not containing this payload would refer to the real link 957 (over which IKEv2 messages are being sent). 959 Another solution is to require that the peer requesting a CHILD_SA 960 proposes traffic selectors that identify the link. For example, 961 if TSi includes the peer's "outer" IP address, it's probably 962 related to the real interface, not the virtual one. Or if TSi 963 includes any of the prefixes assigned by the gateway (or the link- 964 local or multicast prefix), it is probably related to the virtual 965 interface. 967 These heuristics can work in many situations, but have proved 968 inadequate in the context of IPv6-in-IPv4 tunnels [RFC4891] and 969 Provider Provisioned VPNs [VLINK] [RFC3884], and Mobile IPv6 970 [RFC4877]. Thus, Section 4 includes the virtual link identifier 971 in all CREATE_CHILD_SA requests that apply to the virtual 972 interface. 974 Example about other IPsec uses: 976 If a VPN gateway receives a CREATE_CHILD_SA request associated 977 with a physical Ethernet interface, requesting SA for (TSi=FE80:: 978 something, dst=*), it would typically reject the request (or in 979 other words, narrow it to an empty set) because it doesn't have 980 SPD/PAD entries that would allow joe.user@example.com to request 981 such CHILD_SAs. 983 (However, it might have SPD/PAD entries that would allow 984 "neighboring-router.example.com" to create such SAs, for 985 protecting e.g. some routing protocol that uses link-local 986 addresses.) 988 However, the virtual interface created when joe.user@example.com 989 authenticated and sent INTERNAL_IP6_LINK would have a different 990 SPD/PAD, which would allow joe.user@example.com to create this SA. 992 A.6. Alternative Solution Sketches 994 A.6.1. Version -00 Sketch 996 The -00 version of this draft contained the following solution 997 sketch, which is basically a combination of (1) point-to-point link 998 model, (2) prefix information distributed in Neighbor Advertisements, 999 and (3) access control enforced outside IPsec. 1001 1) During IKE_AUTH, client sends a new configuration attribute, 1002 INTERNAL_IP6_LINK, which requests a virtual link to be created. The 1003 attribute contains the client's interface ID for link-local address 1004 (other addresses may use other interface IDs). 1006 CP(CFG_REQUEST) = 1007 { INTERNAL_IP6_LINK(Link-Local Interface ID) } 1008 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1009 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1010 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1011 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1013 The VPN gateway replies with its own link-local interface ID (which 1014 has to be different from the client's) and an IKEv2 Link ID (which 1015 will be used for reauthentication). 1017 CP(CFG_REPLY) = 1018 { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) } 1019 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1020 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1021 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1022 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1024 At this point, both peers configure the virtual interface with the 1025 link-local addresses. 1027 2) The next step is IPv6 stateless address autoconfiguration; that 1028 is, Router Solicitation and Router Advertisement messages sent over 1029 the IPsec SA. 1031 ESP(Router Solicitation: 1032 src=::, 1033 dst=FF02:0:0:0:0:0:0:2) --> 1035 <-- ESP(Router Advertisement: 1036 src=FE80:: 1037 dst=FF02:0:0:0:0:0:0:1, 1038 Prefix1, [Prefix2...]) 1040 After receiving the Router Advertisement, the client can configure 1041 unicast addresses from the advertised prefixes, using any proper 1042 interface ID. The VPN gateway does not simultaneously assign the 1043 same prefixes to any other client, and does not itself configure 1044 addresses from these prefixes. Thus, the client does not have to 1045 perform Duplicate Address Detection (DAD). 1047 3) Reauthentication works basically the same way as in Section 4; the 1048 client includes the IKEv2 Link ID in the INTERNAL_IP6_LINK attribute. 1050 4) Creating and rekeying IPsec SAs works basically the same way as in 1051 Section 4.3; the client includes the IKEv2 Link ID in those CHILD_SA 1052 requests that are related to the virtual link. 1054 Comments: This was changed in -01 draft based on feedback from VPN 1055 vendors: while the solution looks nice on paper, it is claimed to be 1056 unneccessarily complex to implement when the IKE implementation and 1057 IPv6 stack are from different companies. Furthermore, enforcing 1058 access control outside IPsec is a significant architectural change 1059 compared to current IPv4 solutions. 1061 A.6.2. Router Aggregation Sketch #1 1063 The following solution was sketched during the IETF 70 meeting in 1064 Vancouver together with Hemant Singh. It combines the (1) router 1065 aggregation link model, (2) prefix information distributed in IKEv2 1066 messages, (3) unique address allocation with stateless address 1067 autoconfiguration (with VPN gateway trapping NS messages and spoofing 1068 NA replies), and (4) access control enforced (partly) outside IPsec. 1070 1) During IKE_AUTH, the client sends a new configuration attribute, 1071 INTERNAL_IP6_LINK, which requests a virtual link to be created. The 1072 attribute contains the client's interface ID for link-local address 1073 (other addresses may use other interface IDs). 1075 CP(CFG_REQUEST) = 1076 { INTERNAL_IP6_LINK(Link-Local Interface ID) } 1077 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1078 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1079 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1080 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1082 The VPN gateway replies with its own link-local interface ID (which 1083 has to be different from the client's), an IKEv2 Link ID (which will 1084 be used for reauthentication and CREATE_CHILD_SA messages), and zero 1085 or more INTERNAL_IP6_PREFIX attributes. The traffic selectors 1086 proposed by the initiator are also narrowed to contain only the 1087 assigned prefixes (and the link-local prefix). 1089 CP(CFG_REPLY) = 1090 { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID), 1091 INTERNAL_IP6_PREFIX(Prefix1/64), 1092 [INTERNAL_IP6_PREFIX(Prefix2/64),...], 1093 INTERNAL_IP6_DHCP(Address) ] 1094 TSi = ((0, 0-65535, 1095 FE80:: - 1096 FE80::) 1097 (0, 0-65535, 1098 Prefix1::0 - 1099 Prefix1::FFFF:FFFF:FFFF:FFFF), 1100 [(0, 0-65535, 1101 Prefix2::0 - 1102 Prefix2::FFFF:FFFF:FFFF:FFFF), ...]) 1103 TSr = (0, 0-65535, 1104 0:0:0:0:0:0:0:0 - 1105 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1107 2) The client now configures tentative unicast addresses from the 1108 prefixes given by the gateway, and performs Duplicate Address 1109 Detection (DAD) for them. 1111 The Neighbor Solicitation messages are processed by the VPN gateway: 1112 if the target address is already in use by some other VPN client, the 1113 gateway replies with a Neighbor Advertisement. If the target address 1114 is not already in use, the VPN gateway notes that it is now being 1115 used by this client, and updates its forwarding state accordingly. 1117 Comments: The main disadvantages of this solution are non-standard 1118 processing of NS messages (which are used to update the gateway's 1119 forwarding state), and performing access control partly outside 1120 IPsec. 1122 A.6.3. Router Aggregation Sketch #2 1124 This is basically similar to the version -00 sketch described with 1125 above, but uses router aggregation link model. In other words, it 1126 combines (1) router aggregation link model, (2) prefix information 1127 distributed in Neighbor Advertisements, (3) unique address allocation 1128 with stateless address autoconfiguration (with VPN gateway trapping 1129 NS messages and spoofing NA replies), and (4) access control enforced 1130 outside IPsec. 1132 1) During IKE_AUTH, client sends a new configuration attribute, 1133 INTERNAL_IP6_LINK, which requests a virtual link to be created. The 1134 attribute contains the client's interface ID for link-local address 1135 (other addresses may use other interface IDs). 1137 CP(CFG_REQUEST) = 1138 { INTERNAL_IP6_LINK(Link-Local Interface ID) } 1139 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1140 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1141 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1142 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1144 The VPN gateway replies with its own link-local interface ID (which 1145 has to be different from the client's) and an IKEv2 Link ID (which 1146 will be used for reauthentication). 1148 CP(CFG_REPLY) = 1149 { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) } 1150 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1151 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1152 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1153 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1155 At this point, both peers configure the virtual interface with the 1156 link-local addresses. 1158 2) The next step is IPv6 stateless address autoconfiguration; that 1159 is, Router Solicitation and Router Advertisement messages sent over 1160 the IPsec SA. 1162 ESP(Router Solicitation: 1163 src=::, 1164 dst=FF02:0:0:0:0:0:0:2) --> 1166 <-- ESP(Router Advertisement: 1167 src=FE80:: 1168 dst=FF02:0:0:0:0:0:0:1, 1169 Prefix1, [Prefix2...]) 1171 3) The client now configures tentative unicast addresses from the 1172 prefixes given by the gateway, and performs Duplicate Address 1173 Detection (DAD) for them. 1175 The Neighbor Solicitation messages are processed by the VPN gateway: 1176 if the target address is already in use by some other VPN client, the 1177 gateway replies with a Neighbor Advertisement. If the target address 1178 is not already in use, the VPN gateway notes that it is now being 1179 used by this client, and updates its forwarding state accordingly. 1181 Comments: The main disadvantages of this solution are non-standard 1182 processing of NS messages (which are used to update the gateway's 1183 forwarding state), and performing access control outside IPsec. 1185 A.6.4. IPv4-like Sketch 1187 This sketch resembles the current IPv4 configuration payloads, and it 1188 combines (1) router aggregation link model, (2) prefix information 1189 distributed in IKEv2 messages, (3) unique address allocation with 1190 IKEv2 messages, and (4) access control enforced by IPsec SAD/SPD. 1192 1) During IKE_AUTH, the client sends a new configuration attribute, 1193 INTERNAL_IP6_LINK, which requests a virtual link to be created. The 1194 attribute contains the client's interface ID for link-local address 1195 (other addresses may use other interface IDs). 1197 CP(CFG_REQUEST) = 1198 { INTERNAL_IP6_LINK(Link-Local Interface ID) } 1199 TSi = (0, 0-65535, 1200 0:0:0:0:0:0:0:0 - 1201 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1202 TSr = (0, 0-65535, 1203 0:0:0:0:0:0:0:0 - 1204 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1206 The VPN gateway replies with its own link-local interface ID (which 1207 has to be different from the client's), an IKEv2 Link ID (which will 1208 be used for reauthentication and CREATE_CHILD_SA messages), and zero 1209 or more INTERNAL_IP6_ADDRESS2 attributes. Each attribute contains 1210 one address from a particular prefix. 1212 CP(CFG_REPLY) = 1213 { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID), 1214 INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID1), 1215 [INTERNAL_IP6_ADDRESS2(Prefix2+Client's Interface ID2),...], 1216 TSi = ((0, 0-65535, 1217 FE80:: - 1218 FE80::) 1219 (0, 0-65535, 1220 Prefix1:: - 1221 Prefix1::), 1222 [(0, 0-65535, 1223 Prefix2:: - 1224 Prefix2::), ...]) 1225 TSr = (0, 0-65535, 1226 0:0:0:0:0:0:0:0 - 1227 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1229 Since the VPN gateway keeps track of address uniqueness, there is no 1230 need to perform Duplicate Address Detection. 1232 2) If the client wants additional addresses later (for example, with 1233 specific interface ID), it requests them in a separate 1234 CREATE_CHILD_SA exchange. For example: 1236 CP(CFG_REQUEST) = 1237 { INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID3) } 1238 TSi = (0, 0-65535, 1239 Prefix1::0 - 1240 Prefix1::FFFF:FFFF:FFFF:FFFF>), 1241 TSr = (0, 0-65535, 1242 0:0:0:0:0:0:0:0 - 1243 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1245 If the requested address is not currently in use by some other 1246 client, the VPN gateway simply returns the same address, and traffic 1247 selectors narrowed appropriately. 1249 CP(CFG_REQUEST) = 1250 { INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID3) } 1251 TSi = ((0, 0-65535, 1252 Prefix1:: - 1253 Prefix1::), 1254 TSr = (0, 0-65535, 1255 0:0:0:0:0:0:0:0 - 1256 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1258 Comments: The main advantage of this solution is that it's quite 1259 close to the current IPv4 way of doing things. By adding explicit 1260 link creation (with Link ID for reauthentication/SPD selection, and 1261 link-local addresses), and slightly changing the semantics (and also 1262 name) of INTERNAL_IP6_ADDRESS attribute (can return more attributes 1263 than was asked), we get much of the needed functionality. 1265 The biggest disadvantages are probably potentially complex 1266 implementation dependency for interface ID selection (see 1267 Section 3.3), and the multi-link subnet model. 1269 A.6.5. Sketch Based on RFC 3456 1271 For completeness: a solution modeled after [RFC3456] would combine 1272 (1) router aggregation link model, (2) prefix information 1273 distribution and unique address allocation with DHCPv6, and (3) 1274 access control enforced by IPsec SAD/SPD. 1276 Authors' Addresses 1278 Pasi Eronen 1279 Nokia Research Center 1280 P.O. Box 407 1281 FIN-00045 Nokia Group 1282 Finland 1284 Email: pasi.eronen@nokia.com 1286 Julien Laganier 1287 Qualcomm Incorporated 1288 5775 Morehouse Drive 1289 San Diego, CA 92121 1290 USA 1292 Phone: +1 858 858 3538 1293 Email: julienl@qualcomm.com 1295 Cheryl Madson 1296 Cisco Systems, Inc. 1297 510 MacCarthy Drive 1298 Milpitas, CA 1299 USA 1301 Email: cmadson@cisco.com