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

 In your previous mail you wrote:

   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.

=> this is the transient pseudo-NAT attack (cf. my I-D about this
problem in MIPv4 and IKE). NAT-T mitigates it by its keep-alive
mechanism: when the attacker goes outside the path (cf. the "transient"
key word) the peer not behind a NAT will receive a packet with the
right source address and stop the spurious redirect.

   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.
   
=> this attack doesn't work with NAT-T IPsec (but the next one does).

   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.
   
=> in fact the attacker must be along the path between the two parties
too because IPsec packets are protected (unfortunately not their headers,
and of course one has again the choice between either header protection
or NAT traversal).
This attack works well without any direct defense...

   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.
   
=> this is my "either NAT-T or security" argument with other words.

   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. 
   
=> please note that the 3rd party bombing can (and should!) be
easily mitigated in this case (IPsec NAT traversal).

   > 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.

=> I fully agree!

   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.

=> same!

BTW we have here both a MOBIKE justification and the answer to
the implicit/explicit issue:
 - NAT-T must be implicit (there is no choice)
 - MOBIKE must be explicit (there is a choice but explicit is strictly
   better).
Perhaps we should keep these messages for a MOBIKE vs NAT-T document?

Thanks

[email protected]