RE: issue 3: nat traversal

hi francis, 

please see my comments below: 

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

my impression so far was that we cannot assume that there are some protocols
which allow to securely obtain a nat binding. if we manage it to update
existing nats to provide this type of protocol support then i would be very
happy. however, we would liket to have a protocol which can be deployed
today (even if there are some limitations). 

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

that's the place where a number of folks disagree with you. 
the mobike working group is not inventing a new nat traversal mechanism. we
just use what we have in ikev2. 


> 
>    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 don't see why nat traversal is outside the scope of the mobike charter. 

could you elaborate a little bit more about (1) to make sure whether we have
a disagreement here. 

ciao
hannes

> 
> Regards
> 
> [email protected]
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>