RE: issue 3: nat traversal

hi mohan, 

please see my comment below: 

> > Mohan Parthasarathy wrote:
> > 
> > >>>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).
> > >>
> > >>what is a "secure" nat traversal solution for you? 
> > >>
> > > 
> > > The one that does not have the 3rd party bombing attack 
> :-) To put 
> > > in a different way, MOBIKE's security should not be altered, when 
> > > moving behind a NAT. As we are at the design stage, it might make 
> > > sense to understand what sort of NAT traversal solution 
> we are going 
> > > to have.
> > 
> > Right. And I want MOBIKE to be secure in this fashion.
> > However, if we move behind a NAT, and our configuration allows such 
> > move, I think we pretty much have to downgrade the security to what 
> > NAT-T offers. Or do you see a way around that?

it is true that you can certainly do better than nat-t. i remember your
proposal and it has certainly some drawbacks as well. 

in fact i was asking my questions in such a way to see this answer from you:
this is not an advertisement but nsis is currently the only protocol that
allows you to securely obtain a nat binding in arbitrary complex network
topologies. you could also use stun (or turn) to learn your publically
visible ip address (and port).  

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 or even based
on the usage of a signaling protocol (such as nsis, midcom or stun). 


> > 
> There may be a way around that. The node that moved behind 
> the NAT should include the NAT public address in the address 
> change message sent to the other end. Then the other end can 
> know what to expect in the IP headers. This is what i 
> presented in IETF 60. There are two ssues here (Perhaps there 
> are more).
> 
> 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.


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

> 
> Let us assume that the NAT discovered the public address 
> securely (either physical security or DHCP security etc.). If 
> not, the attacker can attack anything he wants, not just MOBIKE.
> 
> In some environments (1) may be easy e.g. i know what public 
> address my NAT uses at home. Or perhaps DHCP can be used to 
> convey this information in a secure way. Perhaps there are 
> others which i am not aware of. Would it make sense to 
> provide a mechanism in MOBIKE to carry the NAT public address 
> assuming it was discovered outside ? If the address is not 
> discovered securely, then it boils down to the same level of 
> security as the current IKEv2 NAT-T.

(1) is not entirely easy as various work in the ietf shows. 
there is plenty of literature on this issue. nsis is a good place to start
reading. 

ciao
hannes

> 
> -mohan
> 
> 
> 
>  > --Jari
> > _______________________________________________
> > Mobike mailing list
> > [email protected]
> > https://www.machshav.com/mailman/listinfo.cgi/mobike
>