Internet DRAFT - draft-suram-dynamic-nat-traversal
draft-suram-dynamic-nat-traversal
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]
