RE: Issue: NAT-T interaction (#3)

Tero,

You are right NAT-T automatically changes the address when it receives an
authenticated
IKE or ESP packet. With authenticated I thought it means the hash
payload(for IKE) & the  HMAC(for ESP) check is ok. I don't think it includes
address in the payload matches the outer
address. So MOBIKE should do the same thing. The address in the
ADDRESS_UPDATE
payload mismatches outer ip address is an indication of NAT or an attack. I
think it
should depends on policy one way or the other. Besides, if NAT-T is on,
maybe we shouldn't even include address in ADDRESS_UPDATE payload for some
cases. 

Rather than changing the NAT-T section, I would rather us make MOBIKE work
in NAT-T cases

Best Regards!
/Jing


-----Original Message-----
From: Tero Kivinen [mailto:[email protected]]
Sent: Wednesday, June 30, 2004 4:42 AM
To: Xiang, Jing [BL60:437:EXCH]
Cc: MOBIKE Mailing List
Subject: RE: [Mobike] Issue: NAT-T interaction (#3)


Jing Xiang writes:
> I don't see why we have to make MOBIKE & NAT-T mutually exclusive. e.g.
> In your just updated draft-ietf-mobike-design-00.txt, it says:
> 
> "If NAT is detected in the IKE SA creation, that should automatically
>    disable the MOBIKE extensions and use NAT-T."
> 
> However, currently NAT-T does not provide mechanism for signalling address
> change.

Actually it does. It automatically changes the address whenever it
changes. There is no authentication on the change, but it is there. 

> Does that mean we limit MOBIKE to non-NAT environment?

If we want to completely protect agains the 3rd party bombing, we have
not other choise. We cannot really reliably authenticate some
attackers (NATs) and not authenticate others (real attackers).

If we do not care about 3rd party bombing then we can use NAT-T all
the time, only thing MOBIKE in that case offers is the multihoming.

> If a connection is established using NAT-T, doesn't IKEv2 already
> specify that "Any authenticated IKE packet or any authenticated UDP
> encapsulated ESP packet can be used to detect that the IP address or
> the port has changed."? Since ADDRESS_UPDATE message is
> authenticated why it can't be used for roaming from NAT cases?

Because the ADDRESS_UPDATE packet specifically FAILS the
authentication. The ADDRESS_UPDATE packet contains the IP numbers, and
those IP numbers DO NOT match the outer IP-address of the packet,
thus it fails. The NAT-T takes address updates from the outer
IP-address, in the MOBIKE we take it from inside the packet. The NAT
can modify the outer IP-addresses, and there is no way for us to
authenticate those changes (unless we change NATs), but NAT cannot
modify the IP-address inside the IKE packets, thus the checks for them
will fail.

We can make transition from NAT-T to MOBIKE and vice versa to work
somehow, and we can probably even extend the NAT-T to support
multihoming for the IP-addresses not behind the NAT. If we want to
complete protection against 3rd party bombing, then we cannot add
NAT-T support to MOBIKE (they will be separate protocols).

I do not see why we have to combine NAT-T and MOBIKE, I think it is
better to keep them separate and make the transtions from one to
another work. It is simplier and also offers clear point for the
policy decision.

These are of course only my own opininons, I know there are people who
think otherwise, and I can modify the NAT-T section in the design
draft if given actual text. It is very hard for me to try to write
something from that point of view, so it would be better to get also
some text from someone else...
-- 
[email protected]

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