idnits 2.17.1 draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 22, 2010) is 5115 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'N' on line 180 -- Looks like a reference, but probably isn't: 'KEi' on line 180 -- Looks like a reference, but probably isn't: 'KEr' on line 184 -- Looks like a reference, but probably isn't: 'IKEv2' on line 329 == Unused Reference: '3' is defined on line 371, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 374, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 377, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 380, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 384, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 394, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4306 (ref. '2') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '3') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. '9') (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSECME WG Jitender Arora 3 Internet Draft Prashant Kumar 4 Intended status: Informational Acme Packet 5 Expires: October 22, 2011 April 22, 2010 7 Alternate Tunnel Addresses for IKEv2 8 draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with 13 the provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 22, 2011. 33 Copyright and License Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. Code Components extracted from this 44 document must include Simplified BSD License text as described in 45 Section 4.e of the Trust Legal Provisions and are provided without 46 warranty as described in the BSD License. 48 Abstract 50 IKEv2 is a protocol for setting up Virtual Private Network (VPN) 51 tunnels from a remote location to a gateway so that the VPN client 52 can access services in the network behind the gateway. Currently the 53 IKE SAs and tunnel mode Ipsec SA's are created implicitly between the 54 IP addresses that are used when the IKE_SA is established. These IP 55 addresses are then used as the outer (tunnel header) addresses 56 for tunnel mode IPSEC packets (transport mode IPsec SAs are beyond 57 the scope of this document). This document defines an IKEv2 extension 58 that allows the outer tunnel header addresses for the tunnel mode 59 IPSEC packets to be different than the IKE peer IP addresses. 61 Table of Contents 63 1. Introduction................................................2 64 2. Terminology.................................................3 65 3. IKEv2 IKE_AUTH exchange with different Tunnel Address.......3 66 4. IKEv2 CREATE_CHILD_SA exchange with different Tunnel Address4 67 5. Usage Scenarios.............................................5 68 5.1. IKEv2 signaling and the IPSEC tunnel mode traffic on 69 different addresses............................................5 70 6. NAT Scenarios and Routing issues............................5 71 7. Alternate Tunnel address messages...........................6 72 7.1. DIFFERENT_TUNNEL_ADDRESS_SUPPORTED.....................6 73 7.2. TUNNEL_ADDRESS.........................................6 74 8. IANA Considerations.........................................7 75 9. Security Considerations.....................................8 76 9.1. Different Tunnel Addresses and Hijacking...............8 77 10. Acknowledgements............................................9 78 11. Informative References......................................9 79 11.1. Normative References...................................9 80 11.2. Informative References.................................9 81 Author's Address.................................................10 83 1. Introduction 85 IKEv2 [2] is used for setting up IPsec [8] based VPNs. Currently the 86 IKE SAs and tunnel mode Ipsec SA's are created implicitly between the 87 IP addresses that are used when the IKE_SA is established. These IP 88 addresses are then used as the outer (tunnel header) addresses 89 for tunnel mode IPSEC packets. This imposes a limitation that all the 90 Ikev2 signaling and the IPSEC traffic needs to go to the same address 91 on the gateway. This document defines an IKEv2 extension that allows 92 the outer tunnel header addresses for the tunnel mode IPSEC packets 93 Arora & Kumar Page 2 4/22/2010 94 to be different than the IKE peer IP addresses. 96 This document proposes an alternate Tunnel address mechanism for 97 IKEv2 that enables a VPN gateway or the VPN client use the different 98 tunnel address for the IPSEC packets than the one which is being 99 used for the IKE negotiation. The tunnel address can be specified 100 during the IKE_AUTH exchange and also during the CREATE_CHILD_SA 101 exchange. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [1]. 109 3. IKEv2 IKE_AUTH exchange with different Tunnel Address 111 This section describes the use of different Tunnel Address mechanism 112 during the IKE_AUTH exchange. The use of different tunnel address 113 during CREATE_CHILD_SA exchange are explained in subsequent 114 sections. 116 The VPN client indicates support for the IKEv2 different tunnel 117 address mechanism and the willingness to send or receive the traffic 118 on tunnel addresses different than the IKE peer addresses by 119 including a DIFFERENT_TUNNEL_ADDRESS_SUPPORTED notification message 120 in the initial IKE_SA_INIT request. If the VPN gateway supports this 121 it will also send the DIFFERENT_TUNNEL_ADDRESS_SUPPORTED message 122 back to the client in the IKE_SA_INIT response. 124 Initiator Responder (VPN GW) 125 --------- ------------------------- 127 (IKE_IP_I:500 -> IKE_IP_R:500) 128 HDR(A,0), SAi1, KEi, Ni, --> 129 N(DIFFERENT_TUNNEL_ADDRESS_SUPPORTED) 131 (IKE_IP_R:500 -> IKE_IP_I:500) 132 <-- HDR(A,0), 133 N(DIFFERENT_TUNNEL_ADDRESS_SUPPORTED) 135 Once the Gateway gets the notification that the different tunnel 136 address is supported by the endpoint, it can choose to assign the 137 Arora & Kumar Page 3 4/22/2010 138 tunnel address which is different than the address which is used for 139 the IKEv2 signaling. Similarly the endpoint on getting the 140 notification that the gateway supports the different tunnel address 141 can chose to assign the different tunnel address. The following 142 IKE_AUTH exchange describes this: 144 Initiator Responder (VPN GW) 145 --------- --------------------------- 146 (IKE_IP_I:500 -> IKE_IP_R:500) 147 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] 148 [IDr,]AUTH, SAi2, TSi, TSr, [N(TUNNEL_ADDRESS)]} --> 150 (IKE_IP_R:500 -> IKE_IP_I:500) 151 <-- HDR(A,B), SK {IDr, [CERT,] AUTH, 152 SAr2, TSi, TSr, [N(TUNNEL_ADDRESS)]} 154 The client will tell the TUNNEL-SRC-ADDRESS (client side) and the 155 Gateway will tell the TUNNEL-DST-ADDRESS (gateway side). If only one 156 side tells the different tunnel address, the IKE-address will be 157 used as the other side's TUNNEL address. 159 4. IKEv2 CREATE_CHILD_SA exchange with different Tunnel Address 161 This section describes the use of different Tunnel Address mechanism 162 during the CREATE_CHILD_SA exchange. 164 Please refer to section 3 for the DIFFERENT_TUNNEL_ADDRESS_SUPPORTED 165 notification message during the IKE_SA_INIT exchange. 167 Once the Gateway gets the notification that the different tunnel 168 address is supported by the endpoint, it can choose to assign the 169 tunnel address which is different than the address which is used for 170 the IKEv2 signaling during the CREATE_CHILD_SA request. Similarly 171 the endpoint on getting the notification that the gateway supports 172 the different tunnel address can chose to assign the different 173 tunnel address. The following CREATE_CHILD_SA exchange describes 174 this: 176 Arora & Kumar Page 4 4/22/2010 177 Initiator Responder (VPN GW) 178 --------- --------------------------- 179 (IKE_IP_I:500 -> IKE_IP_R:500) 180 HDR(A,B), SK {{[N], SA, Ni, [KEi], 181 TSi, TSr, [N(TUNNEL_ADDRESS)]} --> 183 (IKE_IP_R:500 -> IKE_IP_I:500) 184 <-- HDR(A,B), SK {SA, Nr, [KEr], 185 TSi, TSr, [N(TUNNEL_ADDRESS)]} 187 The client will tell the TUNNEL-SRC-ADDRESS (client side) and the 188 Gateway will tell the TUNNEL-DST-ADDRESS (gateway side). If only one 189 side tells the different tunnel address, the IKE-address will be 190 used as the other side's TUNNEL address. 192 5. Usage Scenarios 194 5.1. IKEv2 signaling and the IPSEC tunnel mode traffic on different 195 addresses 197 Currently it is not possible to separate the IKEv2 signaling and the 198 IPSEC traffic on different IP addresses. There are applications 199 where we would like to have different addresses for signaling and 200 the IPSEC traffic coming to the gateway. One of these applications 201 can be load balancing of IPSEC tunnels. In this model, all the IKEv2 202 signaling from the clients will go through the IKEv2 load Balancer 203 to the selected gateway on a particular IP address, where as the 204 IPSEC traffic from clients will go directly to the gateway 205 (bypassing the load balancer) on different address. So in this case 206 the signaling and the traffic will reach the selected Gateway at 207 different addresses. 209 6. NAT Scenarios and Routing issues 211 In some scenarios, the network may contain NATs or stateful packet 212 filters (for brevity, the rest of this document simply describes 213 NATs). The NAT Traversal feature specified in [IKEv2] allows IKEv2 214 to work through NATs in many cases, and this draft will leverage 215 this functionality. 217 If the Gateway or the client determines that there is a NAT in front 218 of them, they will not change the tunnel address and will keep the 219 tunnel address same as the IKE address. If we try to solve this 220 issue, it will add a lot of complexity to the [IKEv2] protocol. 222 Arora & Kumar Page 5 4/22/2010 223 The issues related to the routing of the IPSEC traffic between the 224 negotiated Tunnel Addresses is beyond the scope of this document. 225 The network operators need to take care of the routing between the 226 VPN clients and the Gateway. 228 7. Alternate Tunnel address messages 230 7.1. DIFFERENT_TUNNEL_ADDRESS_SUPPORTED 232 The DIFFERENT_TUNNEL_ADDRESS_SUPPORTED payload is included in the 233 initial IKE_SA_INIT request by the initiator or the 234 IKE_SA_INIT_RESPONSE by responder to indicate support for the IKEv2 235 different tunnel address mechanism described in this document. 237 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Next Payload |C| RESERVED | Payload Length | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and 246 the 'Notify Message Type' fields are the same as described in 247 Section 3.10 of [2]. The 'SPI Size' field MUST be set to 0 to 248 indicate that the SPI is not present in this message. The 'Protocol 249 ID' MUST be set to 0, since the notification is not specific to a 250 particular security association. 252 The 'Payload Length' field is set to the length in octets of the 253 entire payload, including the generic payload header. The 'Notify 254 Message Type' field is set to indicate the 255 DIFFERENT_TUNNEL_ADDRESS_SUPPORTED Payload . 258 7.2. TUNNEL_ADDRESS 260 The TUNNEL_ADDRESS payload is included in an IKE_AUTH request or 261 response and also in the CREATE_CHILD_SA request or response if the 262 initiator or the responder wants to use the different address for 263 the tunnel address (different than the address used for the IKEv2 264 signaling. 266 The message includes the IP address to be used for the tunnel src 267 Arora & Kumar Page 6 4/22/2010 268 (client) or the tunnel destination (gateway). 270 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Next Payload |C| RESERVED | Payload Length | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | IP Type | | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 ~ IPv4 or the IPv6 address ~ 280 | | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and 284 the 'Notify Message Type' fields are the same as described in 285 Section 3.10 of [2]. The 'SPI Size' field MUST be set to 0 to 286 indicate that the SPI is not present in this message. The 'Protocol 287 ID' MUST be set to (2) to indicate AH or (3) to indicate ESP, since 288 the notification is specific to an IPSEC Security Associations. 289 The 'Payload Length' field is set to the length in octets of the 290 entire payload, including the generic payload header. 'Notify 291 Message Type' field is set to indicate the TUNNEL_ADDRESS payload 292 . The IP Type' field indicates the IP 293 address type. The following values are valid in the TUNNEL ADDRESS 294 payload. 296 1 - IPv4 address 297 2 - IPv6 address 299 The IPv4 address, the IPv6 address MUST be encoded as described in 300 section 3.5 of [2]. 302 8. IANA Considerations 304 This document defines two new IKEv2 Notification Message types as 305 described in Section 7. The two Notify Message Types must be 306 assigned values between 16396 and 40959. 308 o DIFFERENT_TUNNEL_ADDRESS_SUPPORTED 309 o TUNNEL_ADDRESS 311 Arora & Kumar Page 7 4/22/2010 312 This document creates a new namespace called the "IP Type". This is 313 used to indicate the type of IP address being used. 315 1 - IPv4 Tunnel address 316 2 - IPv6 Tunnel address 318 Values '0', and 4-240 are reserved. New values can be allocated by 319 Expert Review [9]. Values 241-255 are set aside for private use. A 320 specification that extends this registry MUST also mention which of 321 the new values are valid in which Notification payload. 323 9. Security Considerations 325 The main goals of this specification are to maintain the security 326 offered by usual IKEv2 procedures and to counter any threats 327 introduced by this draft in an appropriate manner. This section 328 describes new security considerations introduced by this draft. See 329 [IKEv2] for security considerations for IKEv2 in general. 331 9.1. Different Tunnel Addresses and Hijacking 333 The payloads relating to different tunnel addresses are encrypted, 334 integrity protected, and replay protected using the IKE_SA. This 335 assures that no one except the participants can, for instance, give 336 a control message to use the different tunnel address. 338 However, as with normal IKEv2, the actual IP addresses in the IP 339 header are not covered by the integrity protection. This means that 340 a NAT between the parties (or an attacker acting as a NAT) can 341 modify the addresses and cause incorrect tunnel header (outer) IP 342 addresses to be used for IPsec SAs. The scope of this attack is 343 limited mainly to denial of service because all traffic is protected 344 using IPsec. 346 This attack can only be launched by on-path attackers that are 347 capable of modifying IKEv2 messages carrying NAT detection 348 indications (such as Dead Peer Detection messages). By modifying 349 the IP header of these packets, the attackers can lead the peers to 350 believe a new NAT or a changed NAT binding exists between them. The 351 attack can continue as long as the attacker is on the path, 352 modifying the IKEv2 messages. 354 Arora & Kumar Page 8 4/22/2010 355 10. Acknowledgements 357 Thanks to Bob Penfield and others for their input. 359 11. Informative References 361 11.1. Normative References 363 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 364 Levels", BCP 14, RFC 2119, March 1997. 366 [2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 367 4306, December 2005. 369 11.2. Informative References 371 [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 372 IPv6", RFC 3775, June 2004. 374 [4] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 375 Bootstrapping in Split Scenario", RFC 5026, October 2007. 377 [5] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility 378 Header Home Agent Switch Message", RFC 5142, January 2008. 380 [6] Eronen, P. and J. Korhonen, "Multiple Authentication Exchanges 381 in the Internet Key Exchange (IKEv2) Protocol", RFC 4739, 382 November 2006. 384 [7] Weniger, K. and F. Dupont, "IKEv2-based Home Agent Assignment 385 In Mobile IPv6/NEMO Bootstrapping", draft-dupont-ikev2- 386 haassign-02 (work in progress), January 2007. 388 [8] Kent, S. and K. Seo, "Security Architecture for the Internet 389 Protocol", RFC 4301, December 2005. 391 [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 392 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 394 [10] V. Devarapalli and K. Weniger, "Redirect Mechanism for the 395 Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685, 396 November 2009 398 Arora & Kumar Page 9 4/22/2010 399 Author's Address 401 Jitender Arora 402 Acme Packet 403 71 Third Ave. 404 Burlington, MA 01803, USA 405 Email: jarora@acmepacket.com 407 Prashant Kumar 408 Acme Packet 409 71 Third Ave. 410 Burlington, MA 01803, USA 411 Email: pkumar@acmepacket.com 413 Arora & Kumar Page 10 4/22/2010