Subject: [IPsec] #40: Floating to port 4500 'by default', and use of UDP when no NAT detected

From: Yaron Sheffer <[email-masked]>
Date: Sun, 7 Dec 2008 17:09:22 +0200

Tero: We should also list whether it is allowed to float to port 4500 even
when no NAT is detected (I think the answer is yes). And even if we float to
port 4500, the UDP encapsulation should not be enabled or expected unless
NAT between is really detected.

Discussion: IKEv1 NAT traversal is a mess, but widely deployed as
inter-vendor interoperability is not widely relied upon.  mobike floats to
port #4500 if the implementation supports NAT-T, even if it doesn't detect a
NAT.
 
Yaron Sheffer: if floating to port #4500, do UDP, even if there's no NAT
detected. [Yaron: I wish to retract this opinion, given that reality is
different. This should not be taken as a precedent.]
 
Tero Kivinen: mobike only turns on UDP if it finds a NAT, but always floats
to port #4500 if it has NAT-T support.
 
Greg Lebovitz: May need to do this with asymmetric paths, one of which is
not NAT'ed (e.g., multiple exit points).
 
UDP encap is prohibited on port #500.
 
Ok to have a port #4500-only implementation (e.g., client that expects
        NATs).
 
UDP encap can get IKEv2 through a firewall that only allows UDP and TCP.
        This is a reason to always use UDP encap, even if no NAT detected.
        This has to start on port #4500.

Summary of open questions:

1.	Do we allow to float immediately into port 4500, e.g. to have port
4500-only originators?
2.	Do we always require UDP encapsulation when using port 4500 (the
scope here does NOT include MOBIKE).
3.	Do we care about asymmetric paths, where NAT only happens in one
direction? If so, what is the correct behavior?

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Dec 2008 19:39:42 +0200

>         This has to start on port #4500.

Note, that client (or server) can trivially fake NAT to be on the
path, by just sending incorrect NAT_DETECTION_*_IP payloads. This will
cause both ends to enable UDP encapsulation. 

> 1.	Do we allow to float immediately into port 4500, e.g. to have port

I would say yes.

> scope here does NOT include MOBIKE).

I would say no (especially if the first question is allowed, as client
might want to start at port 4500, but still might not want to waste
extra bytes for UDP encapsulation if it is needed)

> direction? If so, what is the correct behavior?

Can someone tell me any reason to someone to have asymmetric NAT, and
how it is supposed to work. It does not work with TCP for example, as
the incoming IP-addresses do not match. 

Other questions:

4. If other end does not support NAT-T, do we allow other end still
   sending UDP encapsulated packets.

(My answer would be NO)

5. If both ends do support NAT-T, but no NAT is detected, is the other
   end still allowed to send UDP encapsulated packets (MOBIKE mandates
   this). This is regardless whether we have floated to port 4500 or
   not. 

(My answer would be YES)

6. If the answer to 5 is YES, then how are reply packets sent out,
   plain ESP, or UDP encapsulated ESP, or either way (if the answer to
   question 5 is YES, then other end must accept them in either way
   anyways).

(My answer would be SHOULD ESP or either way, as that is what MOBIKE
assumes, as after the IP-address change from behind NAT to address not
behind NAT, we still might receive few UDP encapsulated packets before
the other end realizes the situation, but if we make both ends to
reply using same encapsulation this will not be resolved, but we keep
on going with UDP encapsulation forever.)

In summary my answers would be:

Initiator can float to port 4500, regardless whether there is NAT or
not, and he can also do that from the beginning. If NAT-T is
supported, all devices MUST be able to receive both UDP encapsulated
and non-UDP encapsulated packets at any time, and process them both.
Encapsulation of incoming packets do not affect the encapsulation of
the sent packets, all devices decide sending format independly. If NAT
is detected all devices MUST enable sending UDP encapsulated packets.
As all devices must be able to receive and process both formats at any
time, the sender can change the encapsulation based on local
implementation matters (unless there is NAT detected, in which case
they MUST send packets UDP encapsulated).
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Scott C Moonen <[email-masked]>
Date: Mon, 8 Dec 2008 14:50:38 -0500

Some replies to Yaron and Tero:

> cause both ends to enable UDP encapsulation. 

True, but I think we should strongly recommend against that practice, 
because there can be subtle problems in some cases (especially double NATs 
or gateways located behind NATs).  For example, if a security gateway 
falsely represents itself as being behind a NAT, it is implying that the 
entire address space behind it is private, which is not the case.  A peer 
initiating to it then has a dilemma in choosing which address to place in 
TSr, or even wondering whether it has enough information to choose an 
appropriate TSr at all.

> 1.             Do we allow to float immediately into port 4500, e.g. to 
have port

I think that is ok.  Should we clarify that once you receive a message on 
port 4500, even if you do not detect a NAT, you must send messages from 
port 4500?

> extra bytes for UDP encapsulation if it is needed)

I agree with Tero -- I prefer that we do not require UDP encap whenever 
floated.

>    sending UDP encapsulated packets.

I agree with Tero -- I prefer that we do not use UDP-encap if no NAT 
notify payloads were exchanged.

>    this). This is regardless whether we have floated to port 4500 or

I disagree with Tero.  I would prefer that we do not allow UDP-encap if no 
NAT was detected.  The biggest concern that I have is that implementations 
may have built UDP-encap support only into IPv4 paths, whereas this is a 
statement that seems to apply to both IPv4 and IPv6.  This is true in our 
implementation; our IPv6 header processing does not support IPv6 
UDP-encap.  So I would prefer to allow UDP-encap only when a NAT was 
actually detected.

> (My answer would be SHOULD ESP or either way, ...

While my answer to #5 is no, if the group consensus is yes, then my answer 
to #6 is to agree with Tero -- I prefer SHOULD ESP and MAY UDP-encap.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Tero Kivinen <[email-masked]>
To:
Yaron Sheffer <[email-masked]>
Cc:
IPsecme WG <[email-masked]>
Date:
12/08/2008 12:40 PM
Subject:
[IPsec]  #40: Floating to port 4500 'by default', and use of UDP when no 
NAT detected

I would say yes.

Other questions:

(My answer would be NO)

(My answer would be YES)

---

From: Dan McDonald <[email-masked]>
Date: Mon, 8 Dec 2008 15:06:03 -0500

> Some replies to Yaron and Tero:

Likewise.

> port 4500, even if you do not detect a NAT, you must send messages from 

Start at 4500, stay at 4500?  Why not?  (I'm also assuming this is IKEv2
only, not needed for retrofitting onto IKEv1...)

> I agree with Tero -- I prefer that we do not require UDP encap whenever 

Add me to that list.  I prefer to avoid the extra bytes if possible.

> notify payloads were exchanged.

Again, add me to that list.

> UDP-encap.  So I would prefer to allow UDP-encap only when a NAT was 

I agree with Scott.  I know MOBIKE mandates UDP encapsulation, but IIRC,
MOBIKE has its own signalling/indicators for this as well, so just make the
odd behavior happen only when indicated.

> to #6 is to agree with Tero -- I prefer SHOULD ESP and MAY UDP-encap.

Agreed, but I'm opposed enough to a YES in #5 that I'd be writing my code
with one hand, while the other holds my nose closed.

Dan

---

From: Yoav Nir <[email-masked]>
Date: Tue, 9 Dec 2008 00:01:49 +0200

>   sending UDP encapsulated packets.

I agree, sort of.

>   this). This is regardless whether we have floated to port 4500 or

I don't see the point of going to the trouble of detecting whether or  
not the NAT device is there, if you're going to do the UDP  
encapsulation anyway. If the implementation wants to use UDP  
encapsulation anyway, it can force NAT detection, for example by  
sending a string of zeros instead of a SHA-1 hash of its addresses and  
ports. I don't know if we want to document something like this in an  
RFC, as it would definitely cause Dan to hold his nose, but such an  
implementation would not need to actually support NAT detection, and  
would still traverse a NAT device.

> on going with UDP encapsulation forever.)

I agree. If you detected that there is no NAT, don't do it (unless you  
can't do ESP, because you're a user-space client with not enough  
privileges to open a raw socket)

Email secured by Check Point
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 9 Dec 2008 14:41:28 +0200

> TSr, or even wondering whether it has enough information to choose an 

I agree that this is not something that should be encouraged, but
there were some people who said they enabled UDP encapsulation always
as they saw that UDP packets passed firewalls and such better than
plain ESP packets. On the other hand quite a lot of those firewalls
already has NAT.

This is usually something that only the client wants to do, i.e. when
you are initiating and you know you might be behind some firewalls or
such that might stop ESP packets, then you can fake that your are
behind NAT to enable UDP encapsulation. I do not really see reason for
server to fake that he is behind NAT. 

> UDP-encap.  So I would prefer to allow UDP-encap only when a NAT was 

I really didn't think about this for IPv6 address point of view, but I
do not think that changes the situation that much. The MOBIKE already
mandates this so if you ever are going to implement MOBIKE you need to
implement this.

In our case the UDP encpasulation is checked in the generic code, so
it is not IPv4 or IPv6 specific code, but code that is run regardless
of the address family.

The reason for allowing both UDP encapsulated and non-encapsulated
packets when RECEIVING data is that it would be consistent with the be
liberal what you accept principle, and I do not think it adds too much
compexity to the incoming packet processing.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 9 Dec 2008 15:00:01 +0200

> only, not needed for retrofitting onto IKEv1...)

Yes, we are only discussing IKEv2 here (altough IKEv1 RFC3947 did
mandate same thing, i.e. start at 4500 and stay at 4500 at section 4:
"Any implementation that supports NAT traversal MUST support
negotiations that begin on port 4500.").

> odd behavior happen only when indicated.

We did have some support cases related to that, as I think there was
some customer complaining that some other vendor sent them UDP
encapsulated packets even when we didn't detect NAT, and our old
versions (before MOBIKE) dropped those. I think we even backported the
patch to the customer to allow receiving UDP encapsulated packets even
when no NAT was seen.

And yes, MOBIKE do have its own signalling etc thus we do not need
to keep base IKEv2 and MOBIKE IKEv2 identical in this sense, but I
would rather keep the changes as small as possible...
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Martin Willi <[email-masked]>
Date: Tue, 09 Dec 2008 14:29:56 +0100

Hi,

> This is a reason to always use UDP encap, even if no NAT detected.

Yes, I've seen such firewall configurations more than once...

> cause both ends to enable UDP encapsulation. 

... and is the reason I've implemented exactly that. The question is if
we should write this down. We additionally could suggest a fixed value,
so the peer has a hint that we are enforcing UDP encapsulation. But this
probably goes too far.

> 1.	Do we allow to float immediately into port 4500, e.g. to have port

I think this is problematic. Existing implementation might not tolerate
such a behavior, even if they should. We already had interoperability
problems when we introduced MOBIKE and switched to 4500 in the second
exchange.

>    sending UDP encapsulated packets.

I don't see a reason to drop packets depending on their encapsulation
mode.
But without NAT-T support, it makes no sense to encapsulate packets, as
a peer can't enforce me to do the same. So, I would give it a NO.

>    this). This is regardless whether we have floated to port 4500 or

Yes, but

> The biggest concern that I have is that implementations may have built
> UDP-encap support only into IPv4 paths, whereas this is a statement
> that seems to apply to both IPv4 and IPv6.

this is actually a problem (and one I'll have to fix, too). The question
is if "NAT-T support" is family specific (it is not with MOBIKE).
I would go for a YES to have a consistent rule for MOBIKE and non-MOBIKE
implementations.

> on going with UDP encapsulation forever.)

Agree.

Regards
Martin