Re: issue 3: nat traversal

Francis Dupont wrote:

>    nat prevention does not solve the nat traversal problem, obviously. 
>    
> => it depends of your meaning of "solve" as with NAT prevention you
> can't get a NAT traversal problem...

Right.

>    we should give people the possibility to 
>    (a) allow the responder to use the ip address contained in the ike message
>    AND
>    (b) allow the responder to use ip address information in the header 
>    to derive some decisions. 
>    
> => my opinion is than (b) is restricted to detect spurious NATs in the path:
> either we use NAT prevention and MOBIKE or we use NAT traversal.
> I don't believe the MOBIKE WG should invent a new NAT traversal mechanism
> (note that I am not against the idea of a new and more secure NAT traversal,
> just that this is not in the scope of the MOBIKE WG).
> 
>    detecting only that you are behind a nat is insufficient to address all
>    scenarios people are looking at. 
>    
> => we have to decide one day if NAT traversal is in the scope:
>  1- just make NAT traversal and MOBIKE two separate solutions
>  2- include a new NAT traversal in the charter
>  3- try to merge current NAT traversal with MOBIKE
> My opinion is 1- is fine and NAT prevention makes the choice clear,
> 2- is currently out of the charter and 3- can't work without 2-,
> so the best solution is 1-. Note that if NAT traversal is not very
> secure it is reasonably secure when implicit SA update is supported
> and it was already accepted...

I believe we have consensus in the WG that there has to be some
level of interworking with MOBIKE and NAT-T beyond complete
separation. I wouldn't necessarily worry too much about the
charter. It only says that we should not modify NAT-T. We
can still work with it. But yes, a new more secure NAT-T is
probably outside the charter.

As a practical suggestion, MOBIKE could use either NAT-D (NAT
Detection) or NAT-P (NAT Prevention) upon attempting to use
a new address and if a NAT is detected in the former case,
downgrades security (for that movement) to NAT-T. What else
do we need?

--Jari