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

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

In your previous mail you wrote:

   luckily this issue is orthogonal to the problems addressed in mobike. mobike
   should allow you to communicate (via some message that has to be defined)
   the addresses that are available at a peer. you might obtain these addresses
   by querying your interface cards, based on pre-configuration

=> I agree only until here.

   or even based
   on the usage of a signaling protocol (such as nsis, midcom or stun). 
   
=> but there is a big difference between this and the previous:
with a NAT the peer has no control at all on its addresses, and
you implicitely ask the other peer to trust the NATs!
   
   > 1) How does the end node discover the public address securely ? 
   > 2) If the public address is known, how does the node communicate this
   >     to the other end securely ?

   i agree with your observation.
   
=> note this is explicitly outside the charter of MOBIKE.

   > I am wondering whether these two things can be seen separately.
   i think they are. if they are we can treat them as a separate problem and
   try to move forward within mobike working group. i think that this is good
   news.  
   
=> please don't forget to change the charter before.

Regards

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

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 3 Jan 2005 14:50:50 -0800

> => note this is explicitly outside the charter of MOBIKE.
I am not sure which part you are referring to. MOBIKE is about
exchanging addresses. And i don't know why doing (2) would put it
outside the charter.

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Jan 2005 11:26:08 +0100

=> perhaps I have not the same reading of the charter? Quoting it:

"An explicit non-goal is the construction of a fully fledged mobility
 protocol. In particular, the WG shall NOT develop mechanisms for the
 following functions:

 ...

 o IP address changes done by third parties (NATs, firewalls etc). In
   particular, MOBIKE shall not replace or modify IKEv2 NAT traversal
   function. MOBIKE handles IP address changes initiated by one of the
   endpoints of the security associations. NAT traversal handles other
   address changes. MOBIKE should not be tightly coupled with the NAT
   traversal function, but it is necessary to specify in which cases
   (if any) they can be used together, and how they interact."
   
Regards