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

From: <[email-masked]>
Date: Wed, 23 Jun 2004 14:02:23 +0300

Tero Kivinen wrote:
>
> My proposal would be to keep NAT-T and MOBIKE separate and you
> use one of them at time. If you are moved inside the NAT, and
> your policy allows NAT-T, then you move from MOBIKE to NAT-T.
> There is no need to send any address update notifications etc,
> as the NAT-T have built-in automatic IP-address change.

Here's another way to look at this issue: an implementation 
that supports NAT-T has some additional information in 
outbound security associations (conceptually speaking; an
implementation could store this information in some other
way as well):

- UDP encapsulation on/off flag
- keepalive sending on/off flag
- "automatically update peer address and port" on/off flag
- peer port

Normally these are set when the SA is created, and never updated 
after that (except the port). 

IMHO it does not make much sense to say that NAT-T and MOBIKE 
should be kept separate, or that you move from MOBIKE to NAT-T.
The question should be whether something MOBIKE does can cause 
this data to be changed after the SA was created, and I think the
answer should be "yes" (taking into account e.g. possible 
restrictions of local policy)

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

---

From: "Jing Xiang" <[email-masked]>
Date: Wed, 23 Jun 2004 10:47:12 -0400

I agree with Pasi's summary here.
I think MOBIKE will definitely cause those NAT related SA info to change. 
Even if we use Address Update as NAT detection, we will probably 
still have to use the Address Update Ack to signal 
whether to turn UDP encap on or off, right?

/Jing

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 23, 2004 7:02 AM
To: [email-masked]; [email-masked]
Subject: RE: [Mobike] Issue: NAT-T interaction (#3)

Best regards,
Pasi

---

From: <[email-masked]>
Date: Wed, 30 Jun 2004 13:32:16 +0300

Tero Kivinen wrote:

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

Note that we have not yet decided (as far as I have understood) 
that the ADDRESS_UPDATE packet will even contain the IP number
(I know it does in your proposal). And even if it does, we have 
not decided what happens if it does not match the outer IP address..

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

I'm still a bit confused by what you mean by "transitions from 
one to another" and keeping them separate. 

If you can do this transition without creating a new IKEv2 SA, 
then it implies that MOBIKE and NAT-T will not be 100% separate, 
since some IKEv2 message added by MOBIKE will modify state used 
by NAT-T. 

Or do you perhaps mean that the initiator has to decide before
opening an IKEv2 SA which will be used? Or decide after the
first two messages? (This would IMHO be a totally unnecessary 
restriction.)

Best regards,
Pasi

---

From: "Jing Xiang" <[email-masked]>
Date: Wed, 30 Jun 2004 10:37:38 -0400

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

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.

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