idnits 2.17.1 draft-ietf-ipsecme-ikev2-ipv6-config-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1390. 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 16 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 Copyright Line does not match the current year -- The document date (November 18, 2008) is 5635 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CERTREQ' is mentioned on line 141, but not defined == Missing Reference: 'IDr' is mentioned on line 141, 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) == Outdated reference: A later version (-11) exists of draft-iab-ip-config-04 -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4294 (Obsoleted by RFC 6434) -- Obsolete informational reference (is this intentional?): RFC 4718 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-10 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 11 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: Standards Track J. Laganier 5 Expires: May 22, 2009 DOCOMO Euro-Labs 6 C. Madson 7 Cisco Systems 8 November 18, 2008 10 IPv6 Configuration in IKEv2 11 draft-ietf-ipsecme-ikev2-ipv6-config-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 22, 2009. 38 Abstract 40 When IKEv2 is used for remote VPN access (client to VPN gateway), the 41 gateway assigns the client an IP address from the internal network 42 using IKEv2 configuration payloads. The configuration payloads 43 specified in RFC 4306 work well for IPv4, but make it difficult to 44 use certain features of IPv6. This document describes the 45 limitations of current IKEv2 configuration payloads for IPv6, and 46 explores possible solutions that would allow IKEv2 to set up full- 47 featured virtual IPv6 interfaces. 49 Table of Contents 51 1. Introduction and Problem Statement . . . . . . . . . . . . . . 4 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 3. Current Limitations . . . . . . . . . . . . . . . . . . . . . 7 54 3.1. Multiple Prefixes . . . . . . . . . . . . . . . . . . . . 7 55 3.2. Link-Local Addresses . . . . . . . . . . . . . . . . . . . 7 56 3.3. Receiving Multicast Traffic . . . . . . . . . . . . . . . 7 57 3.4. Interface Identifier Selection . . . . . . . . . . . . . . 7 58 3.5. Sharing VPN Access . . . . . . . . . . . . . . . . . . . . 8 59 3.6. Additional Information . . . . . . . . . . . . . . . . . . 8 60 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 4.1. Main Requirements . . . . . . . . . . . . . . . . . . . . 9 62 4.2. Desirable Non-Functional Properties . . . . . . . . . . . 10 63 4.3. Implementation Considerations . . . . . . . . . . . . . . 10 64 4.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 65 5. Solution Discussion . . . . . . . . . . . . . . . . . . . . . 11 66 5.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . . 12 67 5.2. Distributing Prefix Information . . . . . . . . . . . . . 12 68 5.3. Unique Address Allocation . . . . . . . . . . . . . . . . 13 69 5.4. Layer 3 Access Control . . . . . . . . . . . . . . . . . . 13 70 5.5. Other Considerations . . . . . . . . . . . . . . . . . . . 14 71 6. Solution Sketch . . . . . . . . . . . . . . . . . . . . . . . 16 72 6.1. Initial Exchanges . . . . . . . . . . . . . . . . . . . . 16 73 6.2. Reauthentication . . . . . . . . . . . . . . . . . . . . . 18 74 6.3. Creating CHILD_SAs . . . . . . . . . . . . . . . . . . . . 18 75 6.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 18 76 6.5. Relationship to Neighbor Discovery . . . . . . . . . . . . 19 77 6.6. Relationship to Existing IKEv2 Payloads . . . . . . . . . 19 78 7. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 21 79 7.1. INTERNAL_IP6_LINK Configuration Attribute . . . . . . . . 21 80 7.2. INTERNAL_IP6_PREFIX Configuration Attribute . . . . . . . 21 81 7.3. LINK_ID Notify Payload . . . . . . . . . . . . . . . . . . 22 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 84 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 86 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 87 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 88 Appendix A. Alternative Solution Sketches . . . . . . . . . . . . 29 89 A.1. Version -00 Sketch . . . . . . . . . . . . . . . . . . . . 29 90 A.2. Router Aggregation Sketch #1 . . . . . . . . . . . . . . . 30 91 A.3. Router Aggregation Sketch #2 . . . . . . . . . . . . . . . 31 92 A.4. IPv4-like Sketch . . . . . . . . . . . . . . . . . . . . . 33 93 A.5. Sketch Based on RFC 3456 . . . . . . . . . . . . . . . . . 34 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 95 Intellectual Property and Copyright Statements . . . . . . . . . . 36 97 1. Introduction and Problem Statement 99 In typical remote access VPN use (client to VPN gateway), the client 100 needs an IP address in the network protected by the security gateway. 101 IKEv2 includes a feature called "configuration payloads" that allows 102 the gateway to dynamically assign a temporary address to the client 103 [IKEv2]. 105 For IPv4, the message exchange would look as follows: 107 Client Gateway 108 -------- --------- 110 HDR(IKE_SA_INIT), SAi1, KEi, Ni --> 112 <-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ] 114 HDR(IKE_AUTH), 115 SK { IDi, CERT, [CERTREQ], AUTH, [IDr], 116 CP(CFG_REQUEST) = 117 { INTERNAL_IP4_ADDRESS(), 118 INTERNAL_IP4_DNS() }, SAi2, 119 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255), 120 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } --> 122 <-- HDR(IKE_AUTH), 123 SK { IDr, CERT, AUTH, 124 CP(CFG_REPLY) = 125 { INTERNAL_IP4_ADDRESS(192.0.2.234), 126 INTERNAL_IP4_DNS(10.11.22.33) }, 127 SAr2, 128 TSi = (0, 0-65535, 192.0.2.234-192.0.2.234), 129 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } 131 Figure 1: IPv4 configuration 133 The IPv4 case has been implemented by various vendors, and in general 134 works well. IKEv2 also defines almost identical configuration 135 payloads for IPv6: 137 Client Gateway 138 -------- --------- 140 HDR(IKE_AUTH), 141 SK { IDi, CERT, [CERTREQ], AUTH, [IDr], 142 CP(CFG_REQUEST) = 143 { INTERNAL_IP6_ADDRESS(), 144 INTERNAL_IP6_DNS() }, SAi2, 145 TSi = (0, 0-65535, 146 0:0:0:0:0:0:0:0 - 147 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF), 148 TSr = (0, 149 0-65535, 0:0:0:0:0:0:0:0 - 150 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) } --> 152 <-- HDR(IKE_AUTH), 153 SK { IDr, CERT, AUTH, 154 CP(CFG_REPLY) = 155 { INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5, 156 64), 157 INTERNAL_IP6_DNS(2001:DB8:9:8:7:6:5:4) }, 158 SAr2, 159 TSi = (0, 0-65535, 160 2001:DB8:0:1:2:3:4:5 - 161 2001:DB8:0:1:2:3:4:5), 162 TSr = (0, 0-65535, 163 0:0:0:0:0:0:0:0: - 164 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) } 166 Figure 2: IPv6 configuration 168 In other words, IPv6 is basically treated as IPv4 with larger 169 addresses. As noted in [RFC4718], this does not fully follow the 170 "normal IPv6 way of doing things". The IPsec tunnels are not full- 171 featured "interfaces" in the IPv6 addressing architecture [IPv6Addr] 172 sense. For example, they do not necessarily have link-local 173 addresses, and this may complicate the use of protocols that assume 174 them. 176 This document describes what exactly are the limitations of current 177 IKEv2 configuration payloads for IPv6, and explores possible 178 solutions that would allow IKEv2-based VPNs to set up full-featured 179 virtual IPv6 interfaces. 181 2. Terminology 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [KEYWORDS]. 187 When messages containing IKEv2 payloads are described, optional 188 payloads are shown in brackets (for instance, "[FOO]"), and a plus 189 sign indicates that a payload can be repeated one or more times (for 190 instance, "FOO+"). 192 This document uses the term "virtual interface" when describing how 193 the client uses the IPv6 address(es) assigned by the gateway. While 194 existing IPsec documents do not use this term, it is not a new 195 concept. In order to use the address assigned by the VPN gateway, 196 current VPN clients already create a local "virtual interface" (as 197 only addresses assigned to interfaces can be used, e.g., as source 198 addresses for TCP connections). Note that this definition of 199 "interface" is not necessarily identical with what some particular 200 implementation calls "interface". 202 3. Current Limitations 204 This section explores the limitations of the current IPv6 205 configuration mechanism. 207 The IKEv2 specification does not always fully describe the semantics 208 associated with configuration payloads, only their on-the-wire 209 format. This section assumes the semantics implied by Figure 2. It 210 is possible that many of the limitations described here could be 211 solved by specifying additional semantics for these configuration 212 payloads. 214 3.1. Multiple Prefixes 216 In Figure 2 only a single IPv6 address (from a single prefix) is 217 assigned. The specification does allow the client to include 218 multiple INTERNAL_IP6_ADDRESS attributes in its request, but the 219 gateway cannot assign more addresses than the client requested. 221 Multiple prefixes are useful for site renumbering, host-based site 222 multihoming [SHIM6], and unique local IPv6 addresses [RFC4193]. In 223 all of these cases, the gateway has better information on how many 224 different addresses (from different prefixes) the client should be 225 assigned. 227 3.2. Link-Local Addresses 229 The IPv6 addressing architecture [IPv6Addr] specifies that "IPv6 230 addresses of all types are assigned to interfaces, not nodes. [..] 231 All interfaces are required to have at least one Link-Local unicast 232 address". 234 Currently, the virtual interface created by IKEv2 configuration 235 payloads does not have link-local addresses. This violates 236 [IPv6Addr] and prevents the use of protocols that require link-local 237 addresses, such as [MLDv2] and [DHCPv6] 239 3.3. Receiving Multicast Traffic 241 Even if MLD would work, the traffic selectors negotiated in Figure 2 242 do not allow receiving multicast traffic. 244 3.4. Interface Identifier Selection 246 In the message exchange shown in Figure 2, the gateway chooses the 247 interface ID used by the client. It is also possible for the client 248 to request a specific interface ID; the gateway then chooses the 249 prefix part. 251 This approach complicates the use of Cryptographically Generates 252 Addresses [CGA]. With CGAs, the interface ID cannot be calculated 253 before the prefix is known. The client could first obtain a non-CGA 254 address to determine the prefix, and then send a separate CFG_REQUEST 255 to obtain a CGA address with the same prefix. However, this approach 256 requires that the IKEv2 software component provides an interface to 257 the component managing CGAs; an ugly implementation dependency that 258 would be best avoided. 260 Similar concerns apply to other cases where the client has some 261 interest in what interface ID is being used, such as Hash-Based 262 Addresses [HBA] and privacy addresses [RFC4941]. 264 Without CGAs and HBAs, VPN clients are not able to fully use IPv6 265 features such as [SHIM6] or enhanced Mobile IPv6 route optimization 266 [RFC4866]. 268 3.5. Sharing VPN Access 270 Some VPN clients may want to share the VPN connection with other 271 devices (e.g., from a cell phone to a laptop, or vice versa) via some 272 local area network connection (such as Wireless LAN or Bluetooth). 274 It is to be determined how common this use case would actually be; 275 e.g., how likely it is that security policies would allow this. 277 Quite obviously sharing of VPN access requires more than one address 278 (unless NAT is used). However, the current model where each address 279 is requested separately is probably complex to integrate with a local 280 area network that uses stateless address autoconfiguration. Thus, 281 obtaining a whole prefix for the VPN client, and advertising that to 282 the local link (something resembling [NDProxy]) would be preferable. 283 With DHCPv6 prefix delegation [RFC3633], even [NDProxy] and 284 associated multi-link subnet issues would be avoided. 286 3.6. Additional Information 288 The original 3GPP standards for IPv6 assigned a single IPv6 address 289 to each mobile phone, resembling current IKEv2 payloads. [RFC3314] 290 describes the problems with this approach, and caused 3GPP to change 291 the specifications to assign unique /64 prefix(es) for each phone. 293 If the VPN client is assigned IPv6 address(es) from prefix(es) that 294 are shared with other VPN clients, this results in some kind of 295 multi-link subnet. [Multilink] describes issues associated with 296 multi-link subnets, and recommends that they should be avoided. 298 4. Design Goals 300 4.1. Main Requirements 302 o A VPN client can obtain several addresses from a given prefix; the 303 interface IDs can be selected by the client, and may depend on the 304 prefix. 306 o A VPN client can be assigned multiple prefixes for use on the 307 client-gateway link. The client does not have to know beforehand 308 how many prefixes are needed. 310 o The solution should avoid periodic messages over the VPN tunnel. 312 o The solution should avoid Duplicate Address Detection (DAD) over 313 the VPN tunnel. 315 o Multicast works. That is, the client is able to send multicast 316 packets (tunneled to the gateway via unicast), join multicast 317 groups using [MLDv2], and receive multicast packets (tunneled from 318 the gateway to the client via unicast). 320 o It should be possible to share the VPN access over a local area 321 network connection, without requiring anything special from other 322 hosts in the local network (beyond minimal IPv6 node requirements 323 specified in [RFC4294]). 325 o Re-authentication works: the client can start a new IKE SA and 326 continue using the same "virtual link" (with same addresses, 327 etc.). 329 o Compatibility with other IPsec uses: Configuring a virtual IPv6 330 link should not prevent the peers from using IPsec/IKEv2 for other 331 uses. 333 o Compatibility with current IPv6 configuration: Although the 334 current IPv6 mechanism is not widely implemented, new solutions 335 should not preclude its use (e.g., by defining incompatible 336 semantics for the existing payloads). 338 o Compatibility with current IPv4 configuration: it should be 339 possible to use the existing IPv4 configuration mechanism within 340 the same IKE SA. 342 o (Optional/To be determined) When the client is also a router (to 343 some local network), it should be able to use DHCPv6 prefix 344 delegation [RFC3633] over the virtual link. 346 4.2. Desirable Non-Functional Properties 348 Note that the following desirable properties may be somewhat 349 conflicting. 351 o Re-use existing mechanisms, such as [AUTOCONF] and [DHCPv6] as 352 much as possible; as explained in [IPConfig], creating IKEv2- 353 specific mechanisms should be avoided. 355 o Avoid the Not Invented Here (NIH) syndrome: There were several 356 proposals how to do IP address configuration in IKEv2, and the 357 IPsec WG chose one of them. Any significant changes should be 358 motivated by real technical needs, not by dislike of the proposal 359 that was chosen. 361 4.3. Implementation Considerations 363 The solution should have clean implementation dependencies. In 364 particular, it should not require significant modifications to the 365 core IPv6 stack (typically part of the operating system), or require 366 the IKE implementor to re-implement parts of the IPv6 stack (to, 367 e.g., have access or control to functionality that is currently not 368 exposed by public interfaces of the IPv6 stack). 370 4.4. Non-Goals 372 Mobile IPv6 already defines how it interacts with IPsec/IKEv2 373 [RFC4877], and the intent of this document is not to change that 374 interaction in any way. 376 5. Solution Discussion 378 Assigning a new IPv6 address to the client creates a new "virtual 379 IPv6 interface", and "virtual link" between the client and the 380 gateway. We will assume that the virtual link has the following 381 properties: 383 o The link and its interfaces are created and destroyed by the IKEv2 384 process. 386 o The IPv6 addresses and prefixes are assigned to the link and its 387 interfaces by IKEv2 messages, and are removed once they are no 388 longer used by any IKE SA. An IKEv2 implementation may delay 389 removal of the IPv6 addresses and prefixes for a period of time to 390 allow upper layer protocol communications (e.g., a TCP connection) 391 to survive an IKE SA re-authentication that would use the same 392 addresses and prefixes. 394 o The link is not an IPsec SA; at any time, there can be zero or 395 more IPsec SAs covering traffic on this link. 397 o The link is not a single IKE SA; to support reauthentication, it 398 must be possible to identify the same link in another IKE SA. 400 o It is TBD whether a single IKE SA needs to support multiple 401 virtual links. (Possibly not; if multiple virtual links are 402 needed, multiple IKE_SAs could be used.) 404 o Not all IPsec-protected traffic between the peers is necessarily 405 related to the virtual link (although in the simplest VPN client- 406 to-gateway scenario it will be). 408 Given these assumptions and the goals described in the previous 409 section, it seems that the most important design choices to be made 410 are the following: 412 o What link/subnet model is used: in other words, the relationships 413 between VPN clients, IPv6 subnet prefixes, and link-local traffic 414 (especially link-local multicast). 416 o How information about the IPv6 prefix(es) is distributed from the 417 gateway to the clients. 419 o How to ensure unique IPv6 addresses for each client, and keep 420 forwarding state up-to-date accordingly.. 422 o How layer 3 access control is done; in other words, where the 423 mechanisms for preventing address spoofing by clients are placed 424 architecturally. 426 Each of these is discussed next in turn. 428 5.1. Link Model 430 There are at least three main choices how to organize the 431 relationships between VPN clients, IPv6 subnet prefixes, and link- 432 local traffic: 434 o Point-to-point link model: each VPN client is assigned one or more 435 IPv6 prefixes; these prefixes are not shared with other clients, 436 and there is no link-local traffic between different VPN clients 437 connected to the same gateway. 439 o Multi-access link model: multiple VPN clients share the same IPv6 440 prefix. Link-local multicast packets sent by one VPN client will 441 be received by other VPN clients (VPN gateway will forward the 442 packets, possibly with MLD snooping to remove unnecessary 443 packets). 445 o "Router aggregation" link model: one form of "multi-link" subnet 446 [Multilink] where multiple VPN clients share the same IPv6 prefix. 447 Link-local multicast will not be received by other VPN clients. 449 In the multi-access link model, VPN clients who are idle (i.e., not 450 currently sending or receiving application traffic) could receive 451 significant amounts of multicast packets from other clients 452 (depending on how many other clients are connected). This is 453 especially undesirable when the clients are battery-powered; for 454 example, a PDA which keeps the VPN connection to corporate intranet 455 active 24/7. For this reason, we will not consider the multi-access 456 link model in the rest of this document. 458 5.2. Distributing Prefix Information 460 Some types of addresses, such as CGAs, require knowledge about the 461 prefix before an address can be generated. The prefix information 462 could be distributed to clients in the following ways: 464 o IKEv2 messages (Configuration Payloads). 466 o Router Advertisement messages (sent over the IPsec tunnel). 468 o DHCPv6 messages (sent over the IPsec tunnel). 470 5.3. Unique Address Allocation 472 In the "multi-access" and "router aggregation" link models (where a 473 single IPv6 prefix is shared between multiple VPN clients) mechanisms 474 are needed to ensure that one VPN client does not use an address 475 already used by some other client. Also, the VPN gateway has to know 476 which client is using which addresses in order to correctly forward 477 traffic. 479 The main choices seem to be the following: 481 o Clients receive the address(es) they are allowed to use in IKEv2 482 messages (Configuration Payloads). In this case, keeping track of 483 which client is using which address is trivial. 485 o Clients receive the address(es) they are allowed to use in DHCPv6 486 messages sent over the IPsec tunnel. In case the DHCPv6 server is 487 not integrated with the VPN gateway, the gateway may need to work 488 as a relay agent to keep track of which client is using which 489 address (and update its forwarding state accordingly). 491 o Clients can use stateless address autoconfiguration to configure 492 addresses and perform Duplicate Address Detection (DAD). This is 493 easy to do in multi-access link model, and can be made to work 494 with router aggretation link model if the VPN gateway traps NS 495 messages and spoofs NA replies. The gateway keeps track of which 496 client is using which address (and updates its forwarding state 497 accordingly) by trapping these NS/NA messages. 499 In the point-to-point link model, the client can simply use any 500 address from the prefix, and the VPN gateway only needs to know which 501 client is using which prefix in order to forward packets correctly. 503 5.4. Layer 3 Access Control 505 It is almost always desirable to prevent one VPN client from sending 506 packets with a source address that is used by another VPN client. In 507 order to correctly forward packets destined to clients, the VPN 508 gateway obviously has to know which client is using which address; 509 the question is therefore where, architecturally, the mechanisms for 510 ingress filtering are placed. 512 o Layer 3 access control enforced by IPsec SAD/SPD: the addresses/ 513 prefixes assigned to a VPN client are reflected in the traffic 514 selectors used in IPsec Security Association and Security Policy 515 Database entries, as negotiated in IKEv2. 517 o The ingress filtering capability could be placed outside IPsec; 518 the traffic selectors in SAD/SPD entries would cover traffic that 519 would be dropped later by ingress filtering. 521 The former approach is used by the current IPv4 solution. 523 5.5. Other Considerations 525 VPN gateway state 527 In some combinations of design choices, the amount of state 528 information required in the VPN gateway depends not only on the 529 number of clients, but also on the number of addresses used by one 530 client. With privacy addresses and potentially some uses of 531 Cryptographically Generated Addresses (CGAs), a single client 532 could have a large number of different addresses (especially if 533 different privacy addresses are used with different destinations). 535 Virtual link identifier 537 Reauthentication requires a way to uniquely identify the virtual 538 link when a second IKE SA is created. Some possible alternatives 539 are the IKE SPIs of the IKE SA where the virtual link was 540 "created" (assuming we can't have multiple virtual links within 541 the same IKE SA), a new identifier assigned when the link is 542 created, or any unique prefix or address that remains assigned to 543 the link for its entire lifetime. Currently, Section 6 proposes 544 that the gateway assigns a new IKEv2 Link ID when the link is 545 created. The client treats the Link ID as an opaque octet string; 546 the gateway uses it to identify relevant local state when 547 reauthentication is done. 549 Note that the link is not uniquely identified by the IKE peer 550 identities (because IDi is often a user identity that can be used 551 on multiple hosts at the same time), or the outer IP addresses of 552 the peers (due to NAT Traversal and [MOBIKE]). 554 Prefix lifetime 556 Prefixes could remain valid either for the lifetime of the IKE SA, 557 until explicitly cancelled, or for an explicitly specified time. 558 Currently, Section 6 proposes that prefixes remain valid for the 559 lifetime of the IKE SA (and its continuations via rekeying, but 560 not reauthentication). If necessary, the VPN gateway can thus add 561 or remove prefixes by triggering reauthentication. It is assumed 562 that adding or removing prefixes is a relatively rare situation, 563 and thus this draft does not currently specify more complex 564 solutions (such as explicit prefix lifetimes, or use of CFG_SET/ 565 CFG_ACK). 567 Compatibility with other IPsec uses 569 Compatibility with other IPsec uses probably requires that when a 570 CHILD_SA is created, both peers can determine whether the CHILD_SA 571 applies to the virtual interface (at the end of the virtual link), 572 or the real interfaces IKEv2 messages are being sent over. This 573 is required to select the correct SPD to be used for traffic 574 selector narrowing and SA authorization in general. 576 One straight-forward solution would be to add an extra payload to 577 CREATE_CHILD_SA requests, containing the virtual link identifier. 578 Requests not containing this payload would refer to the real link 579 (over which IKEv2 messages are being sent). 581 Another solution is to require that the peer requesting a CHILD_SA 582 proposes traffic selectors that identify the link. For example, 583 if TSi includes the peer's "outer" IP address, it's probably 584 related to the real interface, not the virtual one. Or if TSi 585 includes any of the prefixes assigned by the gateway (or the link- 586 local or multicast prefix), it is probably related to the virtual 587 interface. 589 These heuristics can work in many situations, but have proved 590 inadequate in the context of IPv6-in-IPv4 tunnels [RFC4891] and 591 Provider Provisioned VPNs [VLINK] [RFC3884], and Mobile IPv6 592 [RFC4877]. Thus, currently Section 6 proposes including the 593 virtual link identifier in all CREATE_CHILD_SA requests that apply 594 to the virtual interface. 596 Example about other IPsec uses: 598 If a VPN gateway receives a CREATE_CHILD_SA request associated 599 with a physical Ethernet interface, requesting SA for (TSi=FE80:: 600 something, dst=*), it would typically reject the request (or in 601 other words, narrow it to an empty set) because it doesn't have 602 SPD/PAD entries that would allow joe.user@example.com to request 603 such CHILD_SAs. 605 (However, it might have SPD/PAD entries that would allow 606 "neighboring-router.example.com" to create such SAs, for 607 protecting e.g. some routing protocol that uses link-local 608 addresses.) 610 However, the virtual interface created when joe.user@example.com 611 authenticated and sent INTERNAL_IP6_LINK would have a different 612 SPD/PAD, which would allow joe.user@example.com to create this SA. 614 6. Solution Sketch 616 This solution is basically a combination of (1) point-to-point link 617 model, (2) prefix information distributed in IKEv2 messages, and (3) 618 access control enforced by IPsec SAD/SPD. 620 (Second preliminary version, based on discussions with Tero Kivinen.) 622 6.1. Initial Exchanges 624 1) During IKE_AUTH, the client sends a new configuration attribute, 625 INTERNAL_IP6_LINK, which requests a virtual link to be configured. 626 The attribute contains the client's interface ID for link-local 627 address (other addresses may use other interface IDs). Typically, 628 the client would also ask for DHCPv6 server address; this is used 629 only for configuration, not address assignment. 631 To handle backward compatibility between a client that supports the 632 extended address configuration mechanism hereby specified and a VPN 633 gateway that does not, this specification RECOMMENDS that the VPN 634 client includes as well the INTERNAL_IP6_ADDRESS configuration 635 attribute to allow graceful fallback to the existing address 636 configuration mechanism specified in the IKEv2 specification [IKEv2], 637 unless it knows for sure that the VPN gateway supports the extended 638 mechanism hereby specified (e.g., via configuration.) 640 CP(CFG_REQUEST) = 641 { INTERNAL_IP6_LINK(Client's Link-Local Interface ID) 642 INTERNAL_IP6_ADDRESS() 643 INTERNAL_IP6_DHCP() } 644 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 645 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 646 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 647 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 649 To handle backward compatibility between a VPN gateway that supports 650 the extended address configuration mechanism hereby specified and a 651 client that does not, if the client has not sent the 652 INTERNAL_IP6_LINK configuration attribute the VPN gateway MUST NOT 653 include the INTERNAL_IP6_LINK configuration attribute in its reply 654 and should fallback to the address configuration mechanism specified 655 in the IKEv2 specification [IKEv2]. 657 If the client has sent the INTERNAL_IP6_LINK configuration attribute, 658 the VPN gateway SHOULD ignore any INTERNAL_IP6_ADDRESS configuration 659 attribute present in the request. 661 The VPN gateway MUST choose for itself a link-local interface 662 identifier different than the client's one, i.e., accept the link- 663 local interface identifier proposed by the client. In case the VPN 664 gateway cannot accept the link-local interface identifier the client 665 proposed, the VPN gateway MUST fail the IPv6 address assignment by 666 including a NOTIFY payload with the INTERNAL_ADDRESS_FAILURE message, 667 i.e., the IKE_SA can be created but no CHILD_SA will be created. 669 The VPN Gateway then replies with an INTERNAL_IP6_LINK configuration 670 attribute that contains the IKEv2 Link ID (which will be used for 671 reauthentication and CREATE_CHILD_SA messages), the client's link 672 local interface identier, and zero or more INTERNAL_IP6_PREFIX 673 attributes. The traffic selectors proposed by the initiator are also 674 narrowed to contain only the assigned prefixes, and the client link- 675 local address formed from the well-known link-local subnet prefix and 676 the client link-local interface identifier. 678 CP(CFG_REPLY) = 679 { INTERNAL_IP6_LINK(Client's Link-Local Interface ID, 680 IKEv2 Link ID) 681 INTERNAL_IP6_PREFIX(Prefix1/64), 682 [INTERNAL_IP6_PREFIX(Prefix2/64),...], 683 [INTERNAL_IP6_DHCP(Address) ] 684 TSi = ((0, 0-65535, 685 FE80:: - 686 FE80::) 687 (0, 0-65535, 688 Prefix1::0 - 689 Prefix1::FFFF:FFFF:FFFF:FFFF), 690 [(0, 0-65535, 691 Prefix2::0 - 692 Prefix2::FFFF:FFFF:FFFF:FFFF), ...]) 693 TSr = (0, 0-65535, 694 0:0:0:0:0:0:0:0 - 695 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 697 At this point, the client can configure 1) its link-local address 698 from the well-known link-local subnet prefix (FE80::/64) and the 699 assigned client's link-local interface identifier, and 2) other non- 700 link-local unicast addresses from the assigned prefixes and any 701 proper interface identifier [IPv6Addr]. The VPN gateway MUST NOT 702 simultaneously assign the same prefixes to any other client, and MUST 703 NOT itself configure addresses from these prefixes. Thus, the client 704 does not have to perform Duplicate Address Detection (DAD). (This 705 approach is based on [IPv6PPP].) 707 The prefixes remain valid through the lifetime of the IKE SA (and its 708 continuations via rekeying). If the VPN gateway needs to remove a 709 prefix it has previously assigned, or assign a new prefix, it can do 710 so by triggering reauthentication. 712 2) The client also contacts the DHCPv6 server. This is the 713 RECOMMENDED way to obtain additional configuration parameters (such 714 as the DNS server), as it allows easier extensibility and more 715 options (such as the domain search list for DNS). 717 6.2. Reauthentication 719 When the client performs reauthentication (and wants to continue 720 using the same "virtual link"), it includes the IKEv2 Link ID given 721 by the gateway in the INTERNAL_IP6_LINK attribute. 723 CP(CFG_REQUEST) = 724 { INTERNAL_IP6_LINK(Client's Link Local Interface ID, 725 IKEv2 Link ID) 726 INTERNAL_IP6_DHCP() } 727 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 728 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 729 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 730 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 732 The gateway uses the Link ID to look up relevant local state, 733 verifies that the authenticated peer identity associated with the 734 link is correct, and continues the handshake as usual. 736 6.3. Creating CHILD_SAs 738 As described in the previous section, both peers need to be able to 739 determine whether a CHILD_SA applies to the virtual interfaces, or 740 the real interfaces IKEv2 messages are being sent over. 742 Currently, this document proposes using an explicit indication 743 instead of relying on heuristics: the peers MUST include a LINK_ID 744 notification, containing the IKEv2 Link ID, in all CREATE_CHILD_SA 745 requests, including rekeys, that are related to the virtual link. 746 The LINK_ID notification is not included in the CREATE_CHILD_SA 747 response, or when doing IKE_SA rekeying. 749 6.4. Multicast 751 (The details of multicast use are to-be-determined.) 753 One way would be to create an SA for receiving multicast packets: 755 TSi = (0, 0-65535, 756 FF00:0:0:0:0:0:0:0 - 757 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 758 TSr = (0, 0-65535, 759 0:0:0:0:0:0:0:0 - 760 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 762 <-- 763 TSi = (0, 0-65535, 764 FF00:0:0:0:0:0:0:0 - 765 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 766 TSr = (0, 0-65535, 767 0:0:0:0:0:0:0:0 - 768 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 770 ...and then use MLD as usual. 772 6.5. Relationship to Neighbor Discovery 774 Neighbor Discovery [IPv6ND] specifies the following mechanisms: 776 Router Discovery, Prefix Discovery, Parameter Discovery,and Address 777 Autoconfiguration are not used, as the necessary functionality is 778 implemented in IKEv2 layer. 780 Address Resolution, Next-hop Determination, and Redirect are not 781 used, as the virtual link does not have link-local addresses, and is 782 a point-to-point link. 784 Neighbor Unreachability Detection could be used, but is a bit 785 redundant given IKEv2 Dead Peer Detection. 787 Duplicate Address Detection is not needed, because this is a point- 788 to-point link, where the VPN gateway does not assign any addresses 789 from the global unicast prefixes, and link-local interface identifier 790 is negotiated separately. 792 6.6. Relationship to Existing IKEv2 Payloads 794 The mechanism described in this document is not intended to be used 795 at the same time as the existing INTERNAL_IP6_ADDRESS attribute. For 796 compatibility with gateways implementing only INTERNAL_IP6_ADDRESS, 797 the VPN client MAY include attributes for both mechanisms in 798 CFG_REQUEST. The capabilities and preferences of the VPN gateway 799 will then determine which is used. 801 All other attributes except INTERNAL_IP6_ADDRESS (and 802 INTENAL_ADDRESS_EXPIRY) from [IKEv2] remain valid, including the 803 somewhat confusingly named INTERNAL_IP6_SUBNET (see Section 6.3 of 804 [RFC4718] for discussion). 806 7. Payload Formats 808 7.1. INTERNAL_IP6_LINK Configuration Attribute 810 The INTERNAL_IP6_LINK configuration attribute is formatted as 811 follows: 813 1 2 3 814 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 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 !R| Attribute Type ! Length | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Client's Link-Local | 819 | Interface ID | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | | 822 ~ IKEv2 Link ID ~ 823 | | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 o Reserved (1 bit) - See [IKEv2]. 828 o Attribute Type (15 bits) - INTERNAL_IP6_LINK (TBD1). 830 o Length (2 octets) - Length in octets of the Value field (Client's 831 Link-Local Interface ID and IKEv2 Link ID); 8 or more. 833 o Link-Local Interface ID (8 octets) - The Interface ID used for 834 link-local address (by the party that sent this attribute). 836 o IKEv2 Link ID (variable length) - The link ID (may be empty when 837 the client does not yet know the link ID). 839 7.2. INTERNAL_IP6_PREFIX Configuration Attribute 841 The INTERNAL_IP6_PREFIX configuration attribute is formatted as 842 follows: 844 1 2 3 845 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 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 !R| Attribute Type ! Length | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | | 850 | Prefix | 851 | | 852 | | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Prefix Length | 855 +-+-+-+-+-+-+-+-+ 857 o Reserved (1 bit) - See [IKEv2]. 859 o Attribute Type (15 bits) - INTERNAL_IP6_PREFIX (TBD2). 861 o Length (2 octets) - Length in octets of the Value field; in this 862 case, 17. 864 o Prefix (16 octets) - An IPv6 prefix assigned to the virtual link. 865 The low order bits of the prefix field which are not part of the 866 prefix MUST be set to zero by the sender and MUST be ignored by 867 the receiver. 869 o Prefix Length (1 octets) - The length of the prefix in bits; 870 usually 64. 872 7.3. LINK_ID Notify Payload 874 The LINK_ID notification is included in CREATE_CHILD_SA requests to 875 indicate that the SA being created is related to the virtual link. 876 If this notification is not included, the CREATE_CHILD_SA requests is 877 related to the physical interface. 879 The Notify Message Type for LINK_ID is TBD3. The Protocol ID and SPI 880 Size fields are set to zero. The data associated with this 881 notification is the IKEv2 Link ID returned in the 882 INTERNAL_IP6_LINK_ID configuration attribute. 884 8. IANA Considerations 886 This document defines two new IKEv2 configuration attributes, whose 887 values are to be allocated (have been allocated) from the "IKEv2 888 Configuration Payload Attribute Types" namespace [IKEv2]: 890 Multi- 891 Value Attribute Type Valued Length Reference 892 ------ ---------------------- ------ ------------- --------- 893 TBD1 INTERNAL_IP6_LINK NO 8 or more [this doc] 894 TBD2 INTERNAL_IP6_PREFIX YES 17 octets [this doc] 896 This document also defines one new IKEv2 notification, whose value is 897 to be allocated (has been allocated) from the "IKEv2 Notify Message 898 Types - Status Types" namespace [IKEv2]: 900 Value Notify Messages - Status Types Reference 901 ------ ------------------------------- --------- 902 TBD3 LINK_ID [this doc] 904 This document does not create any new namespaces to be maintained by 905 IANA. 907 9. Security Considerations 909 To be written. (The security consideration should be pretty much the 910 same as for current configuration payloads.) 912 Assigning each client a unique prefix makes using randomized 913 interface identifiers [RFC4941] ineffective from privacy point of 914 view: the client is still uniquely identified by the prefix. In some 915 environments, it may be preferable to assign a VPN client the same 916 prefixes each time a VPN connection is established; other 917 environments may prefer assigning a different prefix every time for 918 privacy reasons. (This is basically a similar trade-off as in Mobile 919 IPv6 -- using the same Home Address forever is simpler than changing 920 it often, but has privacy implications.) 922 10. Acknowledgments 924 The author would like to thank Patrick Irwin, Tero Kivinen, Julien 925 Laganier, Chinh Nguyen, Mohan Parthasarathy, Yaron Sheffer, Hemant 926 Singh, Dave Thaler, Yinghzhe Wu, and Fan Zhao for their valuable 927 comments. 929 Many of the challenges associated with IPsec-protected "virtual 930 interfaces" have been identified before: for example, in the context 931 of protecting IPv6-in-IPv4 tunnels with IPsec [RFC4891], Provider 932 Provisioned VPNs [VLINK] [RFC3884], and Mobile IPv6 [RFC4877]. Some 933 of the limitations of assigning a single IPv6 address were identified 934 in [RFC3314]. 936 11. References 938 11.1. Normative References 940 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 941 RFC 4306, December 2005. 943 [IPv6Addr] 944 Hinden, R. and S. Deering, "IP Version 6 Addressing 945 Architecture", RFC 4291, February 2006. 947 [KEYWORDS] 948 Bradner, S., "Key words for use in RFCs to Indicate 949 Requirement Levels", RFC 2119, March 1997. 951 11.2. Informative References 953 [AUTOCONF] 954 Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 955 Address Autoconfiguration", RFC 4862, September 2007. 957 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 958 RFC 3972, March 2006. 960 [DHCPv6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 961 and M. Carney, "Dynamic Host Configuration Protocol for 962 IPv6 (DHCPv6)", RFC 3315, July 2003. 964 [HBA] Bagnulo, M., "Hash Based Addresses (HBA)", 965 draft-ietf-shim6-hba-05 (work in progress), December 2007. 967 [IPConfig] 968 Aboba, B., Thaler, D., and L. Andersson, "Principles of 969 Internet Host Configuration", draft-iab-ip-config-04 (work 970 in progress), May 2008. 972 [IPv6ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 973 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 974 September 2007. 976 [IPv6PPP] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over 977 PPP", RFC 5072, September 2007. 979 [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery 980 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 982 [MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 983 (MOBIKE)", RFC 4555, June 2006. 985 [Multilink] 986 Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 987 June 2007. 989 [NDProxy] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 990 Proxies (ND Proxy)", RFC 4389, April 2006. 992 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 993 Generation Partnership Project 3GPP) Standards", RFC 3314, 994 September 2002. 996 [RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic 997 Host Configuration Protocol (DHCPv4) Configuration of 998 IPsec Tunnel Mode", RFC 3456, January 2003. 1000 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1001 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1002 December 2003. 1004 [RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec 1005 Transport Mode for Dynamic Routing", RFC 3884, 1006 September 2004. 1008 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1009 Addresses", RFC 4193, October 2005. 1011 [RFC4294] Loughney, J., Ed., "IPv6 Node Requirements", RFC 4294, 1012 April 2006. 1014 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 1015 Implementation Guidelines", RFC 4718, October 2006. 1017 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 1018 Optimization for Mobile IPv6", RFC 4866, May 2007. 1020 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1021 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1022 April 2007. 1024 [RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. 1025 Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 1026 RFC 4891, May 2007. 1028 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1029 Extensions for Stateless Address Autoconfiguration in 1030 IPv6", RFC 4941, September 2007. 1032 [SHIM6] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1033 Shim Protocol for IPv6", draft-ietf-shim6-proto-10 (work 1034 in progress), February 2008. 1036 [VLINK] Duffy, M., "Framework for IPsec Protected Virtual Links 1037 for PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00 (work in 1038 progress), October 2002. 1040 Appendix A. Alternative Solution Sketches 1042 A.1. Version -00 Sketch 1044 The -00 version of this draft contained the following solution 1045 sketch, which is basically a combination of (1) point-to-point link 1046 model, (2) prefix information distributed in Neighbor Advertisements, 1047 and (3) access control enforced outside IPsec. 1049 1) During IKE_AUTH, client sends a new configuration attribute, 1050 INTERNAL_IP6_LINK_ID, which requests a virtual link to be created. 1051 The attribute contains the client's interface ID for link-local 1052 address (other addresses may use other interface IDs). 1054 CP(CFG_REQUEST) = 1055 { INTERNAL_IP6_LINK_ID(Link-Local Interface ID) } 1056 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1057 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1058 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1059 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1061 The VPN gateway replies with its own link-local interface ID (which 1062 MUST be different from the client's) and an IKEv2 Link ID (which will 1063 be used for reauthentication). 1065 CP(CFG_REPLY) = 1066 { INTERNAL_IP6_LINK_ID(Link-Local Interface ID, IKEv2 Link ID) } 1067 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1068 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1069 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1070 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1072 At this point, both peers configure the virtual interface with the 1073 link-local addresses. 1075 2) The next step is IPv6 stateless address autoconfiguration; that 1076 is, Router Solicitation and Router Advertisement messages sent over 1077 the IPsec SA. 1079 ESP(Router Solicitation: 1080 src=: 1081 dst=FF02:0:0:0:0:0:0:2) --> 1083 <-- ESP(Router Advertisement: 1084 src=FE80:: 1085 dst=FF02:0:0:0:0:0:0:1, 1086 Prefix1, [Prefix2...]) 1088 After receiving the Router Advertisement, the client can configure 1089 unicast addresses from the advertised prefixes, using any interface 1090 ID. The VPN gateway MUST NOT simultaneously assign the same prefixes 1091 to any other client, and MUST NOT itself configure addresses from 1092 these prefixes. Thus, the client does not have to perform Duplicate 1093 Address Detection (DAD). 1095 3) Reauthentication works basically the same way as in Section 6.2; 1096 the client includes the IKEv2 Link ID in the INTERNAL_IP6_LINK_ID 1097 attribute. 1099 4) Creating and rekeying IPsec SAs works basically the same way as in 1100 Section 6.3; the client includes the IKEv2 Link ID in those CHILD_SA 1101 requests that are related to the virtual link. 1103 Comments: This was changed in -01 draft based on feedback from VPN 1104 vendors: while the solution looks nice on paper, it is claimed to be 1105 unneccessarily complex to implement when the IKE implementation and 1106 IPv6 stack are from different companies. Furthermore, enforcing 1107 access control outside IPsec is a significant architectural change 1108 compared to current IPv4 solutions. 1110 A.2. Router Aggregation Sketch #1 1112 The following solution was sketched during the IETF 70 meeting in 1113 Vancouver together with Hemant Singh. It combines the (1) router 1114 aggregation link model, (2) prefix information distributed in IKEv2 1115 messages, (3) unique address allocation with stateless address 1116 autoconfiguration (with VPN gateway trapping NS messages and spoofing 1117 NA replies), and (4) access control enforced (partly) outside IPsec. 1119 1) During IKE_AUTH, the client sends a new configuration attribute, 1120 INTERNAL_IP6_LINK_ID, which requests a virtual link to be created. 1121 The attribute contains the client's interface ID for link-local 1122 address (other addresses may use other interface IDs). 1124 CP(CFG_REQUEST) = 1125 { INTERNAL_IP6_LINK_ID(Link-Local Interface ID) } 1126 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1127 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1128 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1129 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1131 The VPN gateway replies with its own link-local interface ID (which 1132 MUST be different from the client's), an IKEv2 Link ID (which will be 1133 used for reauthentication and CREATE_CHILD_SA messages), and zero or 1134 more INTERNAL_IP6_PREFIX attributes. The traffic selectors proposed 1135 by the initiator are also narrowed to contain only the assigned 1136 prefixes (and the link-local prefix). 1138 CP(CFG_REPLY) = 1139 { INTERNAL_IP6_LINK_ID(Link-Local Interface ID, IKEv2 Link ID), 1140 INTERNAL_IP6_PREFIX(Prefix1/64), 1141 [INTERNAL_IP6_PREFIX(Prefix2/64),...], 1142 INTERNAL_IP6_DHCP(Address) ] 1143 TSi = ((0, 0-65535, 1144 FE80:: - 1145 FE80::) 1146 (0, 0-65535, 1147 Prefix1::0 - 1148 Prefix1::FFFF:FFFF:FFFF:FFFF), 1149 [(0, 0-65535, 1150 Prefix2::0 - 1151 Prefix2::FFFF:FFFF:FFFF:FFFF), ...]) 1152 TSr = (0, 0-65535, 1153 0:0:0:0:0:0:0:0 - 1154 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1156 2) The client now configures tentative unicast addresses from the 1157 prefixes given by the gateway, and performs Duplicate Address 1158 Detection (DAD) for them. 1160 The Neighbor Solicitation messages are processed by the VPN gateway: 1161 if the target address is already in use by some other VPN client, the 1162 gateway replies with a Neighbor Advertisement. If the target address 1163 is not already in use, the VPN gateway notes that it is now being 1164 used by this client, and updates its forwarding state accordingly. 1166 Comments: The main disadvantages of this solution are non-standard 1167 processing of NS messages (which are used to update the gateway's 1168 forwarding state), and performing access control partly outside 1169 IPsec. 1171 A.3. Router Aggregation Sketch #2 1173 This is basically similar to the version -00 sketch described with 1174 above, but uses router aggregation link model. In other words, it 1175 combines (1) router aggregation link model, (2) prefix information 1176 distributed in Neighbor Advertisements, (3) unique address allocation 1177 with stateless address autoconfiguration (with VPN gateway trapping 1178 NS messages and spoofing NA replies), and (4) access control enforced 1179 outside IPsec. 1181 1) During IKE_AUTH, client sends a new configuration attribute, 1182 INTERNAL_IP6_LINK_ID, which requests a virtual link to be created. 1183 The attribute contains the client's interface ID for link-local 1184 address (other addresses may use other interface IDs). 1186 CP(CFG_REQUEST) = 1187 { INTERNAL_IP6_LINK_ID(Link-Local Interface ID) } 1188 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1189 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1190 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1191 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1193 The VPN gateway replies with its own link-local interface ID (which 1194 MUST be different from the client's) and an IKEv2 Link ID (which will 1195 be used for reauthentication). 1197 CP(CFG_REPLY) = 1198 { INTERNAL_IP6_LINK_ID(Link-Local Interface ID, IKEv2 Link ID) } 1199 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1200 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1201 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1202 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1204 At this point, both peers configure the virtual interface with the 1205 link-local addresses. 1207 2) The next step is IPv6 stateless address autoconfiguration; that 1208 is, Router Solicitation and Router Advertisement messages sent over 1209 the IPsec SA. 1211 ESP(Router Solicitation: 1212 src=: 1213 dst=FF02:0:0:0:0:0:0:2) --> 1215 <-- ESP(Router Advertisement: 1216 src=FE80:: 1217 dst=FF02:0:0:0:0:0:0:1, 1218 Prefix1, [Prefix2...]) 1220 3) The client now configures tentative unicast addresses from the 1221 prefixes given by the gateway, and performs Duplicate Address 1222 Detection (DAD) for them. 1224 The Neighbor Solicitation messages are processed by the VPN gateway: 1225 if the target address is already in use by some other VPN client, the 1226 gateway replies with a Neighbor Advertisement. If the target address 1227 is not already in use, the VPN gateway notes that it is now being 1228 used by this client, and updates its forwarding state accordingly. 1230 Comments: The main disadvantages of this solution are non-standard 1231 processing of NS messages (which are used to update the gateway's 1232 forwarding state), and performing access control outside IPsec. 1234 A.4. IPv4-like Sketch 1236 This sketch resembles the current IPv4 configuration payloads, and it 1237 combines (1) router aggregation link model, (2) prefix information 1238 distributed in IKEv2 messages, (3) unique address allocation with 1239 IKEv2 messages, and (4) access control enforced by IPsec SAD/SPD. 1241 1) During IKE_AUTH, the client sends a new configuration attribute, 1242 INTERNAL_IP6_LINK_ID, which requests a virtual link to be created. 1243 The attribute contains the client's interface ID for link-local 1244 address (other addresses may use other interface IDs). 1246 CP(CFG_REQUEST) = 1247 { INTERNAL_IP6_LINK_ID(Link-Local Interface ID) } 1248 TSi = (0, 0-65535, 1249 0:0:0:0:0:0:0:0 - 1250 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1251 TSr = (0, 0-65535, 1252 0:0:0:0:0:0:0:0 - 1253 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1255 The VPN gateway replies with its own link-local interface ID (which 1256 MUST be different from the client's), an IKEv2 Link ID (which will be 1257 used for reauthentication and CREATE_CHILD_SA messages), and zero or 1258 more INTERNAL_IP6_ADDRESS2 attributes. Each attribute contains one 1259 address from a particular prefix. 1261 CP(CFG_REPLY) = 1262 { INTERNAL_IP6_LINK_ID(Link-Local Interface ID, IKEv2 Link ID), 1263 INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID1), 1264 [INTERNAL_IP6_ADDRESS2(Prefix2+Client's Interface ID2),...], 1265 TSi = ((0, 0-65535, 1266 FE80:: - 1267 FE80::) 1268 (0, 0-65535, 1269 Prefix1:: - 1270 Prefix1::), 1271 [(0, 0-65535, 1272 Prefix2:: - 1273 Prefix2::), ...]) 1274 TSr = (0, 0-65535, 1275 0:0:0:0:0:0:0:0 - 1276 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1278 Since the VPN gateway keeps track of address uniqueness, there is no 1279 need to perform Duplicate Address Detection. 1281 2) If the client wants additional addresses later (for example, with 1282 specific interface ID), it requests them in a separate 1283 CREATE_CHILD_SA exchange. For example: 1285 CP(CFG_REQUEST) = 1286 { INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID3) } 1287 TSi = (0, 0-65535, 1288 Prefix1::0 - 1289 Prefix1::FFFF:FFFF:FFFF:FFFF>), 1290 TSr = (0, 0-65535, 1291 0:0:0:0:0:0:0:0 - 1292 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1294 If the requested address is not currently in use by some other 1295 client, the VPN gateway simply returns the same address, and traffic 1296 selectors narrowed appropriately. 1298 CP(CFG_REQUEST) = 1299 { INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID3) } 1300 TSi = ((0, 0-65535, 1301 Prefix1:: - 1302 Prefix1::), 1303 TSr = (0, 0-65535, 1304 0:0:0:0:0:0:0:0 - 1305 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1307 Comments: The main advantage of this solution is that it's quite 1308 close to the current IPv4 way of doing things. By adding explicit 1309 link creation (with Link ID for reauthentication/SPD selection, and 1310 link-local addresses), and slightly changing the semantics (and also 1311 name) of INTERNAL_IP6_ADDRESS attribute (can return more attributes 1312 than was asked), we get much of the needed functionality. 1314 The biggest disadvantages are probably potentially complex 1315 implementation dependency for interface ID selection (see 1316 Section 3.4), and the multi-link subnet model. 1318 A.5. Sketch Based on RFC 3456 1320 For completeness: a solution modeled after [RFC3456] would combine 1321 (1) router aggregation link model, (2) prefix information 1322 distribution and unique address allocation with DHCPv6, and (3) 1323 access control enforced by IPsec SAD/SPD. 1325 Authors' Addresses 1327 Pasi Eronen 1328 Nokia Research Center 1329 P.O. Box 407 1330 FIN-00045 Nokia Group 1331 Finland 1333 Email: pasi.eronen@nokia.com 1335 Julien Laganier 1336 DOCOMO Communications Laboratories Europe GmbH 1337 Landsberger Strasse 312 1338 Munich D-80687 1339 Germany 1341 Phone: +49 89 56824 231 1342 Email: julien.laganier.IETF@googlemail.com 1344 Cheryl Madson 1345 Cisco Systems, Inc. 1346 510 MacCarthy Drive 1347 Milpitas, CA 1348 USA 1350 Email: cmadson@cisco.com 1352 Full Copyright Statement 1354 Copyright (C) The IETF Trust (2008). 1356 This document is subject to the rights, licenses and restrictions 1357 contained in BCP 78, and except as set forth therein, the authors 1358 retain all their rights. 1360 This document and the information contained herein are provided on an 1361 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1362 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1363 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1364 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1365 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1366 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1368 Intellectual Property 1370 The IETF takes no position regarding the validity or scope of any 1371 Intellectual Property Rights or other rights that might be claimed to 1372 pertain to the implementation or use of the technology described in 1373 this document or the extent to which any license under such rights 1374 might or might not be available; nor does it represent that it has 1375 made any independent effort to identify any such rights. Information 1376 on the procedures with respect to rights in RFC documents can be 1377 found in BCP 78 and BCP 79. 1379 Copies of IPR disclosures made to the IETF Secretariat and any 1380 assurances of licenses to be made available, or the result of an 1381 attempt made to obtain a general license or permission for the use of 1382 such proprietary rights by implementers or users of this 1383 specification can be obtained from the IETF on-line IPR repository at 1384 http://www.ietf.org/ipr. 1386 The IETF invites any interested party to bring to its attention any 1387 copyrights, patents or patent applications, or other proprietary 1388 rights that may cover technology that may be required to implement 1389 this standard. Please address the information to the IETF at 1390 ietf-ipr@ietf.org.