Subject: Re: [Mobike] issue 3: nat traversal

From: Francis Dupont <[email-masked]>
Date: Mon, 03 Jan 2005 16:48:56 +0100

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-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "James Kempf" <[email-masked]>
Date: Tue, 4 Jan 2005 09:42:28 -0800

Francis,

>    detection/activation in the middle of IKE sessions.

This sounds pretty reasonable to me. I think it should handle the case of
movement from outside a NAT to inside. Though it would require IPsec to be
rerun, I think this is a feature, since, as you mention, it avoids bidding
down.

What about moving from inside to outside?

            jak

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Jan 2005 15:51:16 +0100

=> clearly a problem for the NAT traversal so a bit outside the scope
of the WG...

Thanks