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

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 9 Dec 2004 13:50:28 +0100

hi francis, 

~snip~

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

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. 

detecting only that you are behind a nat is insufficient to address all
scenarios people are looking at. 

ciao
hannes
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Fri, 10 Dec 2004 10:36:41 +0100

=> it depends of your meaning of "solve" as with NAT prevention you
can't get a NAT traversal problem...

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

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 14 Dec 2004 16:25:57 +0200

> can't get a NAT traversal problem...

Right.

> 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