IPSECME WG Jitender Arora Internet Draft Prashant Kumar Intended status: Informational Acme Packet Expires: October 22, 2011 April 22, 2010 Alternate Tunnel Addresses for IKEv2 draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 22, 2011. Copyright and License Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Arora & Kumar Expires October 18, 2010 [Page 1] Internet-Draft April 2010 Abstract IKEv2 is a protocol for setting up Virtual Private Network (VPN) tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. Currently the IKE SAs and tunnel mode Ipsec SA's are created implicitly between the IP addresses that are used when the IKE_SA is established. These IP addresses are then used as the outer (tunnel header) addresses for tunnel mode IPSEC packets (transport mode IPsec SAs are beyond the scope of this document). This document defines an IKEv2 extension that allows the outer tunnel header addresses for the tunnel mode IPSEC packets to be different than the IKE peer IP addresses. Table of Contents 1. Introduction................................................2 2. Terminology.................................................3 3. IKEv2 IKE_AUTH exchange with different Tunnel Address.......3 4. IKEv2 CREATE_CHILD_SA exchange with different Tunnel Address4 5. Usage Scenarios.............................................5 5.1. IKEv2 signaling and the IPSEC tunnel mode traffic on different addresses............................................5 6. NAT Scenarios and Routing issues............................5 7. Alternate Tunnel address messages...........................6 7.1. DIFFERENT_TUNNEL_ADDRESS_SUPPORTED.....................6 7.2. TUNNEL_ADDRESS.........................................6 8. IANA Considerations.........................................7 9. Security Considerations.....................................8 9.1. Different Tunnel Addresses and Hijacking...............8 10. Acknowledgements............................................9 11. Informative References......................................9 11.1. Normative References...................................9 11.2. Informative References.................................9 Author's Address.................................................10 1. Introduction IKEv2 [2] is used for setting up IPsec [8] based VPNs. Currently the IKE SAs and tunnel mode Ipsec SA's are created implicitly between the IP addresses that are used when the IKE_SA is established. These IP addresses are then used as the outer (tunnel header) addresses for tunnel mode IPSEC packets. This imposes a limitation that all the Ikev2 signaling and the IPSEC traffic needs to go to the same address on the gateway. This document defines an IKEv2 extension that allows the outer tunnel header addresses for the tunnel mode IPSEC packets Arora & Kumar Page 2 4/22/2010 Expires - October 2011 [Page 2] Internet-Draft April 2010 to be different than the IKE peer IP addresses. This document proposes an alternate Tunnel address mechanism for IKEv2 that enables a VPN gateway or the VPN client use the different tunnel address for the IPSEC packets than the one which is being used for the IKE negotiation. The tunnel address can be specified during the IKE_AUTH exchange and also during the CREATE_CHILD_SA exchange. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. 3. IKEv2 IKE_AUTH exchange with different Tunnel Address This section describes the use of different Tunnel Address mechanism during the IKE_AUTH exchange. The use of different tunnel address during CREATE_CHILD_SA exchange are explained in subsequent sections. The VPN client indicates support for the IKEv2 different tunnel address mechanism and the willingness to send or receive the traffic on tunnel addresses different than the IKE peer addresses by including a DIFFERENT_TUNNEL_ADDRESS_SUPPORTED notification message in the initial IKE_SA_INIT request. If the VPN gateway supports this it will also send the DIFFERENT_TUNNEL_ADDRESS_SUPPORTED message back to the client in the IKE_SA_INIT response. Initiator Responder (VPN GW) --------- ------------------------- (IKE_IP_I:500 -> IKE_IP_R:500) HDR(A,0), SAi1, KEi, Ni, --> N(DIFFERENT_TUNNEL_ADDRESS_SUPPORTED) (IKE_IP_R:500 -> IKE_IP_I:500) <-- HDR(A,0), N(DIFFERENT_TUNNEL_ADDRESS_SUPPORTED) Once the Gateway gets the notification that the different tunnel address is supported by the endpoint, it can choose to assign the Arora & Kumar Page 3 4/22/2010 Expires - October 2011 [Page 3] Internet-Draft April 2010 tunnel address which is different than the address which is used for the IKEv2 signaling. Similarly the endpoint on getting the notification that the gateway supports the different tunnel address can chose to assign the different tunnel address. The following IKE_AUTH exchange describes this: Initiator Responder (VPN GW) --------- --------------------------- (IKE_IP_I:500 -> IKE_IP_R:500) HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]AUTH, SAi2, TSi, TSr, [N(TUNNEL_ADDRESS)]} --> (IKE_IP_R:500 -> IKE_IP_I:500) <-- HDR(A,B), SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr, [N(TUNNEL_ADDRESS)]} The client will tell the TUNNEL-SRC-ADDRESS (client side) and the Gateway will tell the TUNNEL-DST-ADDRESS (gateway side). If only one side tells the different tunnel address, the IKE-address will be used as the other side's TUNNEL address. 4. IKEv2 CREATE_CHILD_SA exchange with different Tunnel Address This section describes the use of different Tunnel Address mechanism during the CREATE_CHILD_SA exchange. Please refer to section 3 for the DIFFERENT_TUNNEL_ADDRESS_SUPPORTED notification message during the IKE_SA_INIT exchange. Once the Gateway gets the notification that the different tunnel address is supported by the endpoint, it can choose to assign the tunnel address which is different than the address which is used for the IKEv2 signaling during the CREATE_CHILD_SA request. Similarly the endpoint on getting the notification that the gateway supports the different tunnel address can chose to assign the different tunnel address. The following CREATE_CHILD_SA exchange describes this: Arora & Kumar Page 4 4/22/2010 Expires - October 2011 [Page 4] Internet-Draft April 2010 Initiator Responder (VPN GW) --------- --------------------------- (IKE_IP_I:500 -> IKE_IP_R:500) HDR(A,B), SK {{[N], SA, Ni, [KEi], TSi, TSr, [N(TUNNEL_ADDRESS)]} --> (IKE_IP_R:500 -> IKE_IP_I:500) <-- HDR(A,B), SK {SA, Nr, [KEr], TSi, TSr, [N(TUNNEL_ADDRESS)]} The client will tell the TUNNEL-SRC-ADDRESS (client side) and the Gateway will tell the TUNNEL-DST-ADDRESS (gateway side). If only one side tells the different tunnel address, the IKE-address will be used as the other side's TUNNEL address. 5. Usage Scenarios 5.1. IKEv2 signaling and the IPSEC tunnel mode traffic on different addresses Currently it is not possible to separate the IKEv2 signaling and the IPSEC traffic on different IP addresses. There are applications where we would like to have different addresses for signaling and the IPSEC traffic coming to the gateway. One of these applications can be load balancing of IPSEC tunnels. In this model, all the IKEv2 signaling from the clients will go through the IKEv2 load Balancer to the selected gateway on a particular IP address, where as the IPSEC traffic from clients will go directly to the gateway (bypassing the load balancer) on different address. So in this case the signaling and the traffic will reach the selected Gateway at different addresses. 6. NAT Scenarios and Routing issues In some scenarios, the network may contain NATs or stateful packet filters (for brevity, the rest of this document simply describes NATs). The NAT Traversal feature specified in [IKEv2] allows IKEv2 to work through NATs in many cases, and this draft will leverage this functionality. If the Gateway or the client determines that there is a NAT in front of them, they will not change the tunnel address and will keep the tunnel address same as the IKE address. If we try to solve this issue, it will add a lot of complexity to the [IKEv2] protocol. Arora & Kumar Page 5 4/22/2010 Expires - October 2011 [Page 5] Internet-Draft April 2010 The issues related to the routing of the IPSEC traffic between the negotiated Tunnel Addresses is beyond the scope of this document. The network operators need to take care of the routing between the VPN clients and the Gateway. 7. Alternate Tunnel address messages 7.1. DIFFERENT_TUNNEL_ADDRESS_SUPPORTED The DIFFERENT_TUNNEL_ADDRESS_SUPPORTED payload is included in the initial IKE_SA_INIT request by the initiator or the IKE_SA_INIT_RESPONSE by responder to indicate support for the IKEv2 different tunnel address mechanism described in this document. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and the 'Notify Message Type' fields are the same as described in Section 3.10 of [2]. The 'SPI Size' field MUST be set to 0 to indicate that the SPI is not present in this message. The 'Protocol ID' MUST be set to 0, since the notification is not specific to a particular security association. The 'Payload Length' field is set to the length in octets of the entire payload, including the generic payload header. The 'Notify Message Type' field is set to indicate the DIFFERENT_TUNNEL_ADDRESS_SUPPORTED Payload . 7.2. TUNNEL_ADDRESS The TUNNEL_ADDRESS payload is included in an IKE_AUTH request or response and also in the CREATE_CHILD_SA request or response if the initiator or the responder wants to use the different address for the tunnel address (different than the address used for the IKEv2 signaling. The message includes the IP address to be used for the tunnel src Arora & Kumar Page 6 4/22/2010 Expires - October 2011 [Page 6] Internet-Draft April 2010 (client) or the tunnel destination (gateway). 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Type | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IPv4 or the IPv6 address ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and the 'Notify Message Type' fields are the same as described in Section 3.10 of [2]. The 'SPI Size' field MUST be set to 0 to indicate that the SPI is not present in this message. The 'Protocol ID' MUST be set to (2) to indicate AH or (3) to indicate ESP, since the notification is specific to an IPSEC Security Associations. The 'Payload Length' field is set to the length in octets of the entire payload, including the generic payload header. 'Notify Message Type' field is set to indicate the TUNNEL_ADDRESS payload . The IP Type' field indicates the IP address type. The following values are valid in the TUNNEL ADDRESS payload. 1 - IPv4 address 2 - IPv6 address The IPv4 address, the IPv6 address MUST be encoded as described in section 3.5 of [2]. 8. IANA Considerations This document defines two new IKEv2 Notification Message types as described in Section 7. The two Notify Message Types must be assigned values between 16396 and 40959. o DIFFERENT_TUNNEL_ADDRESS_SUPPORTED o TUNNEL_ADDRESS Arora & Kumar Page 7 4/22/2010 Expires - October 2011 [Page 7] Internet-Draft April 2010 This document creates a new namespace called the "IP Type". This is used to indicate the type of IP address being used. 1 - IPv4 Tunnel address 2 - IPv6 Tunnel address Values '0', and 4-240 are reserved. New values can be allocated by Expert Review [9]. Values 241-255 are set aside for private use. A specification that extends this registry MUST also mention which of the new values are valid in which Notification payload. 9. Security Considerations The main goals of this specification are to maintain the security offered by usual IKEv2 procedures and to counter any threats introduced by this draft in an appropriate manner. This section describes new security considerations introduced by this draft. See [IKEv2] for security considerations for IKEv2 in general. 9.1. Different Tunnel Addresses and Hijacking The payloads relating to different tunnel addresses are encrypted, integrity protected, and replay protected using the IKE_SA. This assures that no one except the participants can, for instance, give a control message to use the different tunnel address. However, as with normal IKEv2, the actual IP addresses in the IP header are not covered by the integrity protection. This means that a NAT between the parties (or an attacker acting as a NAT) can modify the addresses and cause incorrect tunnel header (outer) IP addresses to be used for IPsec SAs. The scope of this attack is limited mainly to denial of service because all traffic is protected using IPsec. This attack can only be launched by on-path attackers that are capable of modifying IKEv2 messages carrying NAT detection indications (such as Dead Peer Detection messages). By modifying the IP header of these packets, the attackers can lead the peers to believe a new NAT or a changed NAT binding exists between them. The attack can continue as long as the attacker is on the path, modifying the IKEv2 messages. Arora & Kumar Page 8 4/22/2010 Expires - October 2011 [Page 8] Internet-Draft April 2010 10. Acknowledgements Thanks to Bob Penfield and others for their input. 11. Informative References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. 11.2. Informative References [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [4] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007. [5] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility Header Home Agent Switch Message", RFC 5142, January 2008. [6] Eronen, P. and J. Korhonen, "Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol", RFC 4739, November 2006. [7] Weniger, K. and F. Dupont, "IKEv2-based Home Agent Assignment In Mobile IPv6/NEMO Bootstrapping", draft-dupont-ikev2- haassign-02 (work in progress), January 2007. [8] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [10] V. Devarapalli and K. Weniger, "Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685, November 2009 Arora & Kumar Page 9 4/22/2010 Expires - October 2011 [Page 9] Internet-Draft April 2010 Author's Address Jitender Arora Acme Packet 71 Third Ave. Burlington, MA 01803, USA Email: jarora@acmepacket.com Prashant Kumar Acme Packet 71 Third Ave. Burlington, MA 01803, USA Email: pkumar@acmepacket.com Arora & Kumar Page 10 4/22/2010 Expires - October 2011 [Page 10]