ipsecme Working Group Suram Chandra Sekhar INTERNET-DRAFT Vemulapalli Jyothi Intended Status: Standards Track Rampullaiah Batchu Expires: September 26, 2015 (Freescale) March 25, 2015 IPsec traversal in Dynamic NAT draft-suram-dynamic-nat-traversal-00.txt Abstract NAT can be enabled on a Security Gateway by administrator at any point of time. This can be called as Dynamic NAT. The existing IKEv2 RFC does not address the scenario of NAT being enabled on a security gateway after IKEv2 negotiation. In such a scenario, traffic sent over the IPsec SA will either be dropped or does not reach the peer security gateway. This document defines a method to ensure that IPsec traffic flow seamlessly in such a scenario. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Suram, at el. Expires September 26, 2015 [Page 1] INTERNET DRAFT IPsec traversal in Dynamic NAT March 25, 2015 Copyright and License Notice Copyright (c) 2015 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 Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Roaming user SA establishment in dynamic NAT . . . . . . . . . 3 2. Solution to dynamic NAT problem . . . . . . . . . . . . . . . 4 2.1 Steps for Detection of Dynamic NAT and updating SAs . . . . 4 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Suram, at el. Expires September 26, 2015 [Page 2] INTERNET DRAFT IPsec traversal in Dynamic NAT March 25, 2015 1 Introduction IPsec (Internet Protocol security) protocol is widely used to protect IP (Internet Protocol) packets. IKEv2 (Internet Key Exchange protocol version 2) is an Internet key exchange protocol used to negotiate, establish and maintain IPsec Security Associations (IPsec SA). Remote access VPN is widely used to access corporate networks by roaming users. Administrator can enable/ disable NAT on the edge gateway behind which the roaming user is trying to connect to the corporate network. If NAT is enabled on the edge gateway after roaming user establishes an IPsec SA with a peer security gateway, traffic sent over the IPsec SA will either be dropped or does not reach the peer security gateway. This disrupts the communication of the Roaming user with its corporate security gateway. This document defines a method to ensure that IPsec traffic flow seamlessly in Dynamic NAT scenarios. 1.1 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 RFC 2119 [RFC2119]. 2. Roaming user SA establishment in dynamic NAT Consider the following scenario: Roaming user is behind edge router and has established a secure tunnel with a corporate gateway as shown in Figure 1. +-+-+-+-+ +-+-+-+-+ IPsec +-+-+-+-+ |Roaming| |Edge | tunnel |Corp | Protected | User |<--->|Router |<========>|Gateway|<--> network +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ Figure 1 Remote access scenario Once the IPsec SA is created, roaming user will be able to access the corporate network securely. Suram, at el. Expires September 26, 2015 [Page 3] INTERNET DRAFT IPsec traversal in Dynamic NAT March 25, 2015 After tunnel is established, NAT is enabled on the edge router as shown in Figure 2. NAT enabled +-+-+-+-+ +-+-+-+-+ IPsec +-+-+-+-+ |Roaming| |Edge | tunnel\ /|Corp | Protected |User |<--->|Router |<=======X>|Gateway|<--> network +-+-+-+-+ +-+-+-+-+ / \+-+-+-+-+ Figure 2 Drop in connection when NAT is enabled dynamically Since NAT is enabled on the Edge router, the source IP address in the IPsec (ESP) packet changes. Corporate gateway (VPN server) will simply drop these IPsec packets as there is no SA with the modified source IP address. Due to this the remote user suddenly cannot reach the corporate network. Roaming user will not know about the communication loss as the IPsec SA is already setup. The loss in communication happens until the lifetime of the IPSec and IKEv2 SAs. Dead peer detection (DPD) protocols will not help as IKE communication may happen normally. 2. Solution to dynamic NAT problem The solution to Dynamic NAT problem involves the following: When peer security gateway (Corp gateway) detects the change, it SHOULD communicate the same to the other peer (remote user) using an informational exchange request. Roaming user validates that request and update its SAs as needed and MUST communicate back with an informational exchange response so that the original peer security gateway also validates and updates its SAs accordingly. 2.1 Steps for Detection of Dynamic NAT and updating SAs When a security gateway (Corp gateway) receives an IPsec packet with source IP address not same as the IP address in the negotiated secure tunnel it does the following to ensure that the roaming user detects Dynamic NAT, o Initiate an informational exchange request with two notification payloads (NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP). Construction of the informational exchange message with the notification payloads MUST be done in accordance to IKEv2 RFC [IKEV2]. o When the VPN client receives the message, it validates/ decrypts the message and extracts the notification payloads. It MUST process the notification payloads in accordance to the IKEv2 RFC [IKEV2]. Suram, at el. Expires September 26, 2015 [Page 4] INTERNET DRAFT IPsec traversal in Dynamic NAT March 25, 2015 o If the first notification payload data is not matching, then NAT is detected between the security gateways. o If the second notification payload data is not matching, then NAT is detected and it is behind NAT. If NAT is detected, o Update IKE SA with the received destination IP address and port. o Update IKE SA source port to 4500 and enable UDP encapsulation for IKE packets o Update IPsec SA with the received destination IP address and port and source port to 4500 and enable UDP encapsulation. o Respond to the security gateway with an informational exchange response having two notification payloads each of type NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP respectively. Response SHOULD be sent on updated UDP port (4500). When the security gateway receives the response, it validates/ decrypts the message and processes the notification payloads as follows: o Process and verify the first and second notification payloads. The processing and verification MUST be done in accordance to IKEv2 RFC [IKEV2]. o If the first notification payload data is not matching, then NAT is detected between the security gateways. o If the second notification payload data is not matching, then NAT is detected and it is behind NAT. If NAT is detected, o Update IKE SA with the received destination IP address and port o Update IKE SA source port to 4500 and enable UDP encapsulation for IKE packets o Update IPsec SA with the received destination IP address and port and source port to 4500 and enable UDP encapsulation. Sending of informational exchange messages is depicted in Figure 3. Initiator Responder ------------------------------------------------------------------- <-- HDR, SK {N (NAT_DETECTION_SOURCE_IP), N (NAT_DETECTION_DESTINATION_IP)} HDR, SK {N (NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP)} --> Figure 3 Notification payloads exchange Once the detection and update of SAs is done, traffic flows seamlessly. Suram, at el. Expires September 26, 2015 [Page 5] INTERNET DRAFT IPsec traversal in Dynamic NAT March 25, 2015 3 Security Considerations Since all the exchanges are protected by IKEv2 SA, there are no security considerations. 4 IANA Considerations None 5 References [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 7296, October 2014 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981 [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation NAT Compatibility Requirements", RFC 3715, March 2004 Authors' Addresses Suram Chandra Sekhar Freescale Block #3,1st Floor, DLF cyber city, Opp APHB colony, Gachibowli, Hyderabad Email: suram@freescale.com Jyothi Vemulapalli Freescale Block #3,1st Floor, DLF cyber city, Opp APHB colony, Gachibowli, Hyderabad Email: jyothi.v@freescale.com Rampullaiah Batchu Freescale Block #3,1st Floor, DLF cyber city, Opp APHB colony, Gachibowli, Hyderabad Email: ramu.batchu@freescale.com Suram, at el. Expires September 26, 2015 [Page 6]