Subject: [IPsec] FW: New Version Notification for draft-suram-dynamic-nat-traversal-00.txt

From: "[email-masked]" <[email-masked]>
Date: Sat, 28 Mar 2015 06:25:53 +0000

Hi,
A new Internet Draft is posted to the working group.
The draft addresses a problem where NAT is enabled dynamically (after IPsec SA is created) because of which traffic stops.
The draft uses the existing IKEv2 framework (without defining any new payloads) and maintains backward compatibility with older implementations of IKEv2 that does not support this draft.

We request your feedback on the same.

Thanking you.

Regards
suram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 25, 2015 10:08 PM
To: Batchu Rampullaiah-B38526; Vemulapalli Jyothi-B37784; Batchu Rampullaiah-B38526; Suram Chandra Sekhar-B38523; Vemulapalli Jyothi-B37784; Suram Chandra Sekhar-B38523
Subject: New Version Notification for draft-suram-dynamic-nat-traversal-00.txt

A new version of I-D, draft-suram-dynamic-nat-traversal-00.txt
has been successfully submitted by Suram Chandra Sekhar and posted to the IETF repository.

Name:		draft-suram-dynamic-nat-traversal
Revision:	00
Title:		IPsec traversal in Dynamic NAT
Document date:	2015-03-25
Group:		Individual Submission
Pages:		6
URL:            http://www.ietf.org/internet-drafts/draft-suram-dynamic-nat-traversal-00.txt
Status:         https://datatracker.ietf.org/doc/draft-suram-dynamic-nat-traversal/
Htmlized:       http://tools.ietf.org/html/draft-suram-dynamic-nat-traversal-00

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.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: [email-masked]
Date: Sat, 28 Mar 2015 13:15:42 -0400 (EDT)

> The draft uses the existing IKEv2 framework (without defining any new payloads) and maintains backward compatibility with older implementations of IKEv2 that does not support this draft.

I was not aware this was a problem. So we should really support the use
case. I'm not sure yet if this is the right approach.

Does this typically happen "once" to a user, or these type of gateways
keep switching the NATing on and off?

If I'm correct, IKEv2 already requires peers to accept ESPinUDP even
without NAT, and so an IKE peer could just enable that, upon which
for at least tunnel mode, everything should keep on working.

Detection of this based on ESP packets is a little tricky. It requires
that the kernel makes a decision based on src/dst IP and existing
policy to inform the IKE daemon in userland.

Maybe this would be better attached to a liveness probe? There the IKE
daemon itself becomes aware of the changed src/dst IP and could enable
ESPinUDP. I think that would not even require a protocol change?

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 30 Mar 2015 16:16:23 +0300

[email-masked] writes:
> The draft addresses a problem where NAT is enabled dynamically
> (after IPsec SA is created) because of which traffic stops. 

This is already supported when MOBIKE is used, and without MOBIKE the
IP-addresses cannot change, thus NAT cannot suddenly appear in the
middle.

Can you explain in which situations the NAT will be enbled after the
IKEv2 connection has been creteated in such way that IP-addresses of
both end points stay same?

If the IP-addresses change, then to be able to keep the same IKEv2
connection you need to use MOBIKE and MOBIKE will already
automatically enable NAT if it detects NAT while moving traffic from
one IP-address to another.

> The draft uses the existing IKEv2 framework (without defining any
> new payloads) and maintains backward compatibility with older
> implementations of IKEv2 that does not support this draft.
> 

Can you explain what is problem with the already standardized solution
to this problem, and why do you think it does not solve the issue?
-- 
[email-masked]