RE: Issue: NAT-T interaction (#3)

Jing Xiang writes:
> I would say any solution we come up MUST work with NAT, maybe not
> all types of NATs but at least basic NAT environment.

The problem is that NAT-T does allow 3rd party bombing, and there is
no way to prevent it, because we cannot authenticate the IP-address.
Actually there is several different levels of 3rd party bombing. The
first is one which can be done from anywhere from the net, simply by
sending few faked packets. This can be prevented by return routability
checks, i.e we verify that sender of the update packet can see packets
destioned to the IP-address he gave.

The next level is where the attacker is along the path to the party to
be bombed. In this case return routability checks will not prevent the
attack, as the attacker can reply to those checks, or forward them to
the correct node, which will then answer to them.

Only way to prevent 3rd party bombing is to require the other party
authenticating the IP-address change, meaning it needs to know the
IP-address seen by the other end and put it inside the payload. In
this case the NAT is considered as an attacker along the path (it
modified the packets), thus the checks will fail, and the address
update is not done.

So if we want to have full protection from 3rd party bombing (also
those attackers who are along the path), we cannot use NAT-T. If we do
not care about the 3rd party bombing, we can use NAT-T all the time. 

> Rather than testing NAT existance after each address change I would
> recommend us consider forcing UDP wrapper on for all mobile cases.

UDP wrapper is not really an issue here. We can negotiate that
separately. The bigger issue is what we do for the 3rd party bombing. 

> The pro is that the connection will be re-established with no
> additional signaling and it will work even if NAT is added after
> address change without peers being aware of it.

I cannot really see how there can be NAT coming along the path unless
the peer notices it. If you had globally routable IP-address, why
would you suddenly start NATing that to some other globally routable
IP-address. In normal cases the peer who moves behind NAT, will notice
that its IP-address change at the same time.

> Of course the drawback is that we add extra 8 bytes to the data.

My proposal would be to keep NAT-T and MOBIKE separate and you use one
of them at time. If you are moved inside the NAT, and your policy
allows NAT-T, then you move from MOBIKE to NAT-T. There is no need to
send any address update notifications etc, as the NAT-T have built-in
automatic IP-address change.
-- 
[email protected]