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

 In your previous mail you wrote:
   
   This is about the interaction with NAT traversal:
   does the MOBIKE protocol work one one party goes behind NAT,
   comes from behind NAT, or goes from one NAT to another?

=> please note there is far more than one question in this statement!

The first one is "one party goes behind NAT": IMHO this is more
an IKEv2 question and the IPsec WG already decided to not support
directly this case, i.e., the IKE SA is broken and everything restart
from the beginning.
MOBIKE is like IKEv2: peer address "floating" is accepted only from
a peer known to be behind a NAT, so there is no detection issue
and we can go to the last case.

The last one is "one party goes from one NAT to another": IMHO
we should not try to handle this case and leave it to NAT-T itself.
The real question is whether is one party using NAT-T (and behind
a NAT) with the other party using MOBIKE a real world case?
Without a concrete example of such a situation I propose to not
require the support of this case.

The second one is "one party comes from behind NAT": IMHO this is
more a NAT-T issue and the real question is the opposite of
the first one: NAT-T to no-NAT-T transition.
The simplest answer is just to keep the NAT-T mode but there is
a bidding down attack on this (bidding down because NAT-T has a
larger overhead and provides less security than "plain" IPsec).
My proposal is to accept this possible attack but to require
a per peer configuration switch which enables or disables NAT-T
(note this is a different switch than NAT-T support itself. for
instance NAT detection can (should!) be performed even when the
switch is on "disabled").

Regards

[email protected]