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