Re: issue 3: nat traversal

 In your previous mail you wrote:

   > => NAT prevention is important for security as I explained in 
   > a previous message, and it "solves" the NAT traversal problem too.
   > IMHO we should only give the choice between NAT traversal and 
   > MOBIKE, i.e., MOBIKE should only detect the "just move behind 
   > a NAT" case, and should *not* try to handle it (i.e., the 
   > case will be considered as misconfiguration).
   
   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...

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

Regards

[email protected]