Re: issue 3: nat traversal

 In your previous mail you wrote:

   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). 
   
=> I can't understand what you want: basic NAT traversal is already
in IKEv2 and advanced NAT traversal is unfeasible in a simple way.
So what do you want to change in NAT traversal?

   >    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. 
   
=> this is exactly what I tried to explain???

   >    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. 
   
=> because it is explicitely written in the charter:

  "In particular, MOBIKE shall not replace or modify IKEv2 NAT traversal
   function."

   could you elaborate a little bit more about (1) to make sure whether we have
   a disagreement here. 
   
=> simple: I propose a configuration "NAT forbidden" bit:
 - if it is on NAT prevention is used and on the detection of a NAT
   IKE/MOBIKE is aborted with an error status.
 - if it is off NAT detection is used and on the detection of a NAT
   the NAT traversal feature of IKE is activated. If a NAT is suspected
   during an active IKE/MOBIKE session (cf previous discussion) then the
   session is aborted and IKE is restarted with NAT detection... Note it is
   possible to enforce the detection of a NAT at the price of a bidding
   down attack issue, and the IPsec WG decided to not support NAT traversal
   detection/activation in the middle of IKE sessions.

Regards

[email protected]