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

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 9 Dec 2004 13:03:16 +0100

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-masked]
> > > > https://www.machshav.com/mailman/listinfo.cgi/mobike
> > > 
> > _______________________________________________
> > 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: Tschofenig Hannes <[email-masked]>
Date: Mon, 20 Dec 2004 09:25:04 +0100

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