Subject: [Mobike] issue 3: nat traversal

From: Tschofenig Hannes <[email-masked]>
Date: Mon, 6 Dec 2004 12:02:44 +0100

hi all, 

let us try to close the nat traversal issue (issue 3) from 
http://www.vpnc.org/ietf-mobike/issue3.txt

here is what we currently have: 

- charter says that we should not modify the ikev2 nat traversal mechanism.
none of the proposal tries to todo that. 
- draft <draft-eronen-mobike-simple-00.txt> addresses nat traversal. 
- draft <draft-eronen-mobike-mopo-01.txt> and
<draft-dupont-ikev2-addrmgmt-06.txt> additionally add a mechanism to
indicate nat traversal prevention.

a number of people pointed to the need to support nat traversal. 

hence, i think that we could have support for
- nat traversal and
- a nat traversal prevention (if you think you don't need it)
without conflicting with the charter.  

to address the scenarios there also needs to support for an end host moving
from not-behind a nat to behind a nat.  

ciao
hannes

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

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 6 Dec 2004 10:05:21 -0800

Hannes,

> a number of people pointed to the need to support nat traversal. 
The issue is a bit confusing to me. I agree that we don't want to modify
the IKEv2 NAT traversal as specified in the IKEv2 draft. But do we want
MOBIKE to work when moving behind NATs ? I am not sure which
question is being asked here. Could you clarify ? I see this as two separate
things. If we want to track this as two separate issues, i am fine with that.

-mohan

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Dec 2004 21:56:38 +0200

I agree. The conclusion is that

- we need to support MOBIKE in a NAT traversal situation
- we need to support MOBIKE moving in and out of a NAT
   traversal situation
- NAT prevention can be provided by MOBIKE if people
   want to put that in (but that seems to be outside the
   original scope of this issue)

However, I believe part of the reason for the original
issue was the "how" part -- the above addresses only
the "what" part. I guess one of the questions going
forward is whether people think draft-eronen-mobike-mopo-01.txt
and draft-dupont-ikev2-addrmgmt-06.txt provide a sufficient
coverage of the "what" part and a sufficient answer to the
"how" part.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Dec 2004 21:59:28 +0200

Mohan Parthasarathy wrote:

> question is being asked here.

I think the key question is what do we want MOBIKE to do,
i.e., does it need to work when moving behind a NAT? And
then answer seems to be yes.

Its true that the we have a restriction that we should not modify
IKEv2 NAT traversal. My advice is not to focus too much on this
question. Lets do what it makes technical sense. I do not think
any of the current proposals modify NAT-T, even if we can perhaps
provide a new stage in the protocol when it is turned on (not just
in the initial contact). So lets not worry about this part.

--Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 6 Dec 2004 13:14:34 -0800

> then answer seems to be yes.
Okay. Do we want to add the qualifier that MOBIKE needs to work
in a "secure" fashion when moving behind a NAT  ? (unlike IKEv2 
which also supports NAT traversal but susceptible to 3rd
party bombing attacks). 

> in the initial contact). So lets not worry about this part.
Note that none of the current proposals support NAT traversal. 
>From what i have read, they only have a prevention mechanism.

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Dec 2004 12:03:41 +0100

In your previous mail you wrote:

=> NAT prevention is very useful by its side effect: protect
the peer addresses by reflecting them in the content of IKE messages.
So this is more important than one can believe reading your mail...

Regards

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