RE: issue 3: nat traversal

hi mohan, 

thanks for your feedback on this isuse. please see my comments inline: 

~snip~

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

please consider the following picture:

    +------------+ private                public    +------------+
    | Initiator  |           *~~~~~~~~~*            | Responder  |
    |            |          *    NAT    *           |            |
    | 192.168.1.2+---------+192.<--->3.1 +--Internet+ 4.2        |
    |            |         |168.         |          |            |
    |            |         | 1.1         |          |            |
    |            |          *           *           |            |
    +------------+           *~~~~~~~~~*            +------------+

if the initiator (who might be behind the nat) has to securely provide the
responder with its IP address then  the initator needs to securely retrieve
its public ip address (and possibly port) from the nat since the initiator
cannot add its private ip address to the ikev2/mobike exchange (for obvious
reasons). this is the reason why we use the outer ip address header to learn
to what ip address the nat has changed the private address of the initiator.


protecting the address as part of the ikev2/mobike exchange is the goal to
ensure that it cannot be modified by a nat along the path. however, this
requires a protocol to securely learn the nat binding from the nat. 
 
this is exactly what nsis tries to provide with the nat/firewall nslp. the
drawback is that you 
a) need another protocol 
b) need the nat to understand nsis (since a regular nat does not provide
this functionality).

if you, however, know that there will be no nat along the path then you can
use the suggested nat prevention mechanism. 

> As we are at the design 
> stage, it might make sense to understand what sort of NAT 
> traversal solution we are going to have. 
> 
certainly. 
i think <draft-eronen-mobike-simple-00.txt> makes a first step into this
direction. 

i agree that we should spend some more lines to explain these issues. 

> > 
> > > 
> > > > 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.
> > > > 
> > > Note that none of the current proposals support NAT traversal. 
> > > From what i have read, they only have a prevention mechanism.
> > > 
> > i got a different impression. see for example,
> > - <draft-eronen-mobike-simple-00.txt>
> 
> This one trivially supports it by the virtue of using IKEv2 NAT-T.

which already provides a lot in my opinion!


> 
> > - <draft-eronen-mobike-mopo-01.txt>
> > 
> I have to read this again. But last time i read it, it was 
> not still not completely secure. Perhaps, it is sufficient. 
> But i am not sure we have a consensus on what level of 
> security we want.
please send comments to the list if you think that something has to be
improved. 


ciao
hannes

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