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

From: Tschofenig Hannes <[email-masked]>
Date: Mon, 20 Dec 2004 09:25:04 +0100

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

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 21 Dec 2004 18:50:54 -0500

> today (even if there are some limitations). 

In the meantime, I wonder if we could get any leverage out of a "NAT expected" 
bit -- carried in a secured part of the protocol.  This would need to be
administratively configured.  It would probably have to default to "on".

If both peers have that bit cleared you would do NAT prevention; otherwise, 
you would do NAT traversal if a NAT is detected.

							- Bill

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 21 Dec 2004 16:41:05 -0800

>administratively configured.  It would probably have to default to "on".

How would an administrator know how to set that bit? Is the 
expectation they would do so by testing first?

--Paul Hoffman, Director
--VPN Consortium

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 21 Dec 2004 20:37:41 -0500

On Tue, 2004-12-21 at 19:41, Paul Hoffman / VPNC wrote:
> How would an administrator know how to set that bit? 

First off, it's only interesting to people who want to do (selective) nat prevention.

To clarify, "nat expected" false means "I don't expect *my* address to be rewritten by a NAT".

So an administrator who assigned systems globally unique globally routed ipv4
addresses, who wanted to avoid nat-like attacks when talking to other systems
with globally unique globally routed addresses, could clear the "nat expected"
bit for those addresses on those systems.

						- Bill

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 21 Dec 2004 17:45:05 -0800

>to be rewritten by a NAT".

Ah! That's good, because it is certainly more predictable.

>bit for those addresses on those systems.

That makes it much easier to predict.

--Paul Hoffman, Director
--VPN Consortium