Subject: [IPsec] Issue #80: UDP encapsulation needs to be negotiated

From: Yaron Sheffer <[email-masked]>
Date: Wed, 1 Apr 2009 23:36:51 +0300

Herbert: 

Recently the statement

"Implementations MUST process received UDP-encapsulated ESP packets even
when no NAT was detected."

was added to the draft. This has the potential to create black holes if
deployed in the field, unless all implementations always use UDP
encapsulation regardless of NAT. The problem is that if a peer behind a
firewall (with no NAT) that only allows inbound packets which are in
response to outbound packets performs UDP encapsulation without NAT, and the
remote peer responds without UDP encapsulation, then all data packets from
the remote peer will be dropped.

Looking at this from the point of view of the remote peer, the only
practical solution would be to always employ UDP encapsulation, regardless
of NAT detection.

Now through discussion on the mailing list it appears that this statement
was motivated by a need in MOBIKE to deploy UDP encapsulation when NAT is
not detected. So assuming that we want to cater for this in IPsec, we should
extend IKE to explicitly negotiate UDP encapsulation, rather than having it
rely on the result of NAT detection.

Not discussed in SF.

Yaron: this looks like an important issue!

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 7 Apr 2009 14:23:12 +0300

Yaron Sheffer writes:
> encapsulation regardless of NAT.

I do not think it creates any more black holes than what is generally
generated by the broken firewalls in the middle.

There is already now black hole generated by IKEv2 implementations
doing NAT detection incorrectly, and enabling NAT-T even when no NAT
is detected (I have seen such implementation).

If you drop all UDP encapsulated ESP packets if no NAT was detected,
then this will cause black hole, as you will not receive any of his
IPsec packets as you drop them, and he might or might not receive your
packets depending whether he requires them to be UDP encapsulated or
not.

In this implementation I have seen this was not really a problem, as
both ends supported MOBIKE, which requires processing both UDP
encapsulated and plain IPsec always, thus both ends were able to
process packets, but UDP encapsulation was used in one direction but
not in other.

> The problem is that if a peer behind a firewall (with no NAT) that
> only allows inbound packets which are in response to outbound
> packets performs UDP encapsulation without NAT, and the remote peer
> responds without UDP encapsulation, then all data packets from the
> remote peer will be dropped.

In normal case this means that the IKE SA will be formed, but no IPsec
traffic will go through in either direction. I.e. neither end will
enable UDP encapsulation as no NAT is detected, thus both ends will
use plain ESP, and those will not go through, so this requirement does
not change the situation.

Note, that the statemenet added does not say anything that SENDING
UDP-encapsulated ESP packets would be required or preferred or even
allowed (it is not forbidden either). The text allows easier
extensibility as now we know that all ends will be able to process
both UDP encapsulated and normal packets always when receiving, so if
we later make extensions which enable sending them, we know that it
will work with old implementations too.

> practical solution would be to always employ UDP encapsulation, regardless

No. There is no way to get IPsec working through that kind of broken
firewall. The firewall policy is clearly saying that IPsec is not
allowed, thus any way of trying to bypass that policy would be bad... 

> rely on the result of NAT detection.

Adding full UDP encapsulation negotiation would be too big protocol
change to the IKEv2, I do not think we can put it to the current
IKEv2bis. It could be added as extension in the future, but I am not
sure if such is really needed. Anyways UDP encapsulation negotation
with backward compatibility is much simplier if you know that IKEv2
implementations can processes either types of packets always.

If you want to force UDP encapsulation, simply fake a NAT on the path
(i.e make NAT DETECTION payloads not to match).

The new text will allow some cases to work where for some reason two
peers do get NAT detection differently. This might be because of bugs
(in NAT detection), or because of attacker modifing packets in one
direction etc.
-- 
[email-masked]