Subject: RE: [Mobike] Issue: NAT-T interaction (#3)

From: "Jing Xiang" <[email-masked]>
Date: Tue, 29 Jun 2004 17:03:00 -0400

Tero, 
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. Does that mean we limit MOBIKE to non-NAT environment? 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?

Best Regards!
/Jing

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

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 30 Jun 2004 11:41:50 +0300

Jing Xiang writes:
> 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-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike