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

From: "Jing Xiang" <[email-masked]>
Date: Mon, 21 Jun 2004 12:55:03 -0400

I would say any solution we come up MUST work with NAT, maybe not
all types of NATs but at least basic NAT environment.

Rather than testing NAT existance after each address change I would
recommend us
consider forcing UDP wrapper on for all mobile cases. The pro is that the
connection
will be re-established with no additional signaling and it will work even
if NAT is added after address change without peers being aware of it. 
Of course the drawback is that we add extra 8 bytes to the data.

Regards!

/Jing

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: Monday, June 21, 2004 11:20 AM
To: MOBIKE Mailing List
Cc: Paul Hoffman / VPNC
Subject: [Mobike] Issue: NAT-T interaction (#3)

This is about the interaction with NAT traversal:
does the MOBIKE protocol work one one party goes behind NAT,
comes from behind NAT, or goes from one NAT to another?
There was a lot of discussion about this at Seoul, so it
is clearly an issue of concern to many people. Is limiting
our protocol to only working if there is no NAT might be
too restrictive because most users don't know when they
are behind a NAT, or are about to move to behind a NAT?

Or should MOBIKE and NAT-T be seen as alternative
solutions; if you enable NAT-T then you use just
that and live with its limitations & if you use
MOBIKE then you don't have a NAT?

In Seoul it seemed that the WG wanted MOBIKE and
NAT-T to work together. If so, would testing for
NATs occur after each address change?

[Reminder: our charter says we shall not replace
or modify NAT traversal, and that we should not
integrate the protocol tightly with NAT traversal.
However, we need to document how (and when) they
work together.]

_______________________________________________
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: Tero Kivinen <[email-masked]>
Date: Tue, 22 Jun 2004 12:48:57 +0300

> all types of NATs but at least basic NAT environment.

The problem is that NAT-T does allow 3rd party bombing, and there is
no way to prevent it, because we cannot authenticate the IP-address.
Actually there is several different levels of 3rd party bombing. The
first is one which can be done from anywhere from the net, simply by
sending few faked packets. This can be prevented by return routability
checks, i.e we verify that sender of the update packet can see packets
destioned to the IP-address he gave.

The next level is where the attacker is along the path to the party to
be bombed. In this case return routability checks will not prevent the
attack, as the attacker can reply to those checks, or forward them to
the correct node, which will then answer to them.

Only way to prevent 3rd party bombing is to require the other party
authenticating the IP-address change, meaning it needs to know the
IP-address seen by the other end and put it inside the payload. In
this case the NAT is considered as an attacker along the path (it
modified the packets), thus the checks will fail, and the address
update is not done.

So if we want to have full protection from 3rd party bombing (also
those attackers who are along the path), we cannot use NAT-T. If we do
not care about the 3rd party bombing, we can use NAT-T all the time. 

> recommend us consider forcing UDP wrapper on for all mobile cases.

UDP wrapper is not really an issue here. We can negotiate that
separately. The bigger issue is what we do for the 3rd party bombing. 

> The pro is that the connection will be re-established with no
> additional signaling and it will work even if NAT is added after
> address change without peers being aware of it.

I cannot really see how there can be NAT coming along the path unless
the peer notices it. If you had globally routable IP-address, why
would you suddenly start NATing that to some other globally routable
IP-address. In normal cases the peer who moves behind NAT, will notice
that its IP-address change at the same time.

> Of course the drawback is that we add extra 8 bytes to the data.

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

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 22 Jun 2004 14:04:15 -0700

Tero,

> automatic IP-address change.

So, you are saying that when you move behind NAT (the way you detect this is
by sending address update with your address behind NAT, RR fails, the peer does
not know how to reach you anymore, timeout and then detect NAT), negotiate
a new SA (with NAT-T) ? Is that right ? 

At some point in time, there was a discussion about adding NAT-D payloads
in mobike itself. I am not sure whether it was explored or not. If i move behind
a NAT and if i can find what the public address that my NAT uses (a priori knowledge
or some signalling), then it is possible to include it in mobike address change packets
for it to work. There is no 3rd party bombing attack as your RR would succeed if the address
used is a proper address or it would fail if the attacker used some random address.
This assumes that Mobike exchange is using UDP for it to go through NAT.
I agree that this is lot of work and not in scope. But at least wanted to understand
what the real reason why we are not going forward with it.

Note that if you move out of NAT, mobike still works but you have extra encapsulation for
packets always.

-mohan

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Jun 2004 12:12:28 +0300

> automatic IP-address change.

I agree. But this would still leave some corner cases to worry about,
such as having a multihomed scenario with one side having a NAT and
the other not. Of course, you can move to NAT-T even on that case,
but then you won't be able to let the peer know your two addresses;
NAT-T only remembers the latest address. This may have an impact
if we want the peer to attempt failover based on a communication
problem with the current address.

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 23 Jun 2004 14:11:45 +0300

Mohan Parthasarathy writes:
> So, you are saying that when you move behind NAT (the way you detect
> this is by sending address update with your address behind NAT, RR
> fails, the peer does not know how to reach you anymore, timeout and
> then detect NAT), negotiate a new SA (with NAT-T) ? Is that right ?

No.

The detection goes so that you send address update to the address you
have behind the NAT, and the other end see that the outer IP-address
of the address update packet differes from the contents of address
update. It will now know that :

	1) There is attacker between modifying the packet outer
           headers
	2) There is NAT between.

Now, it have two options. Either ignore the address update packet it
was modified by the attacker or continue.

Next it does return routability check for the address given in the
address update packet. If that fails, it will know that it either was
malicious client in the other end or there was NAT between.

If the RR check successed, it knows it was probably attacker
modifying the packet.

If the first RR fails, it can try to do RR of the outer IP-address
given in the packet (i.e. the adderss of NAT). If that fails, it was
again attacker. If it succeeds then it knows it is either attacker
along the path towards the outer IP, or there was NAT between.

After that it can do policy decision whether to enable NAT-T or not,
and if it decides it is allowed, it will send packet to the other end
(to the outer IP-address) requesting NAT-T to be enabled. Once the
NAT-T is enabled we might keep that enabled for ever, meaning we will
not move back from there.

One think that needs to be done is to define who how the multihoming
features work with NAT-T. This needs some more protocol work, as
currently NAT-T only uses one address (the address last seen in the
outer IP-header). 

> At some point in time, there was a discussion about adding NAT-D
> payloads in mobike itself. I am not sure whether it was explored or
> not.

Address update packets are in the sense of NAT-D packets, as they
contain the IP-addresses inside. 

> If i move behind a NAT and if i can find what the public
> address that my NAT uses (a priori knowledge or some signalling),
> then it is possible to include it in mobike address change packets
> for it to work.

That would require that our address update packets also include the
port numbers for the IKEv2 traffic. Also securely finding out the
external IP address of NAT is impossible with the normal NATs out
there. 

> There is no 3rd party bombing attack as your RR
> would succeed if the address used is a proper address or it would
> fail if the attacker used some random address. This assumes that

The attacker can modify the packets source IP (just like NAT), and it
can then grab those RR packets from the net (it needs to be along the
path towards the 3rd party victim, he is attacking), and forward them
to the authenticated user. The user will then reply to those RRs to
the attacker, and attacker can then send them back to the server, thus
the RR will succeed. Only way to fix that is to include the IP-packets
inside the packet authenticated with IKE SA, in which case attacker
cannot forward them, but on the other hand that also makes the NAT-T
impossible, as it is considered attacker there. 

> Mobike exchange is using UDP for it to go through NAT. I agree that
> this is lot of work and not in scope. But at least wanted to
> understand what the real reason why we are not going forward with
> it.

There is lots of things we still need to think about the NAT-T and
MOBIKE, that is the reason it is here as an item. There is no point
wasting our time to it, if we then later decide that no, we do not
even want it. If we now decide yes, we want it, we might still later
change our mind, and say "it is too hard"...

> Note that if you move out of NAT, mobike still works but you have
> extra encapsulation for packets always.

Or, you can simply still use NAT-T.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 23 Jun 2004 10:06:27 -0700

> > then detect NAT), negotiate a new SA (with NAT-T) ? Is that right ?
I should not have asked two questions in the same place.
I am not sure to which you said "No" :-)   I guess you were
refering to the process to detect that you are behind NAT..

> If the RR check successed, it knows it was probably attacker
Ah! I missed this part.

> currently NAT-T only uses one address (the address last seen in the
Ok.

> external IP address of NAT is impossible with the normal NATs out
I at least know the external IP address of my NAT at home :-) It seems
to be reasonably stable. Assume i am reading my company email on the way
home (connected to my company through the IPsec tunnel) and i get into my
house where there is a NAT, but still would like to read my email without
disruption/packet-loss :-) 

> can then grab those RR packets from the net (it needs to be along the

If the attacker modifies the source address on the address-update packet
before it reaches the other end, then the peer will detect that the source
IP does not match the address (the public address of NAT)
contained in the payload (which is protected) and hence can decide either
to drop the packet or do RR on the address contained in the payload. So, i am missing
something..

> change our mind, and say "it is too hard"...
I agree that there are some hard issues to think about. If we can at least
discuss all the issues, we can avoid the same question
repeated again by someone or me again in the future :-)

> Or, you can simply still use NAT-T.

Yes.

-mohan

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 24 Jun 2004 14:14:06 +0300

> refering to the process to detect that you are behind NAT..

My answer was mostly saying that there are all kind of options. 

> > If the RR check successed, it knows it was probably attacker

This wasn't really explained anywhere, I was just thinking the things
at the same tiem I wrote the message.

> disruption/packet-loss :-) 

True. I have similar setup in my home, and the NAT is actually
configured to be static for my laptop (it will always get the same
external IP, only allocated for it). Perhaps we need to think whether
the protocol should take account those things too... 

> If the attacker modifies the source address on the address-update
> packet before it reaches the other end, then the peer will detect
> that the source IP does not match the address (the public address of
> NAT) contained in the payload (which is protected) and hence can
> decide either to drop the packet or do RR on the address contained
> in the payload. So, i am missing something..

The data in the payload is the address behind the NAT, not the exteran
address of the NAT, thus attacker and NAT look identical. In both
cases the outer IP address and the address inside does not match.
There is no way to know wheter it was attacker who modified the packet
or whether it was NAT (which actually is an attacker who modifies the
packets :-)
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Thu, 24 Jun 2004 18:31:35 +0200

In your previous mail you wrote:

   Rather than testing NAT existance after each address change

=> in fact in IKEv2 NAT existence is checked only in the initial
exchange and can be forced by putting junked NAT-D stuff.

   I would recommend us consider forcing UDP wrapper on for all mobile
   cases.

=> IMHO this is not a stupid option when there is likely a NAT on the path.
But as a counterpart one should have a switch to disable NAT-T.

=> NAT-T is also less secure (as Tero explained...)

Regards

[email-masked]

PS: one extra issue is the support of NAT-T when both peers are
behind a NAT. IMHO there is nothing in the protocol against this.
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 24 Jun 2004 09:48:04 -0700

> address of the NAT, thus attacker and NAT look identical. In both

As i mentioned in my first mail, i assume that i can learn the public IP
address of my NAT (which is possible in my home case) and i include that
in the MOBIKE address exchange packet. Yes, it involves more work in
terms of getting the address in most of the cases. Assume i get the public
address of my NAT, wouldn't this work ? 

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Thu, 24 Jun 2004 18:50:40 +0200

=> this is the transient pseudo-NAT attack (cf. my I-D about this
problem in MIPv4 and IKE). NAT-T mitigates it by its keep-alive
mechanism: when the attacker goes outside the path (cf. the "transient"
key word) the peer not behind a NAT will receive a packet with the
right source address and stop the spurious redirect.

=> this attack doesn't work with NAT-T IPsec (but the next one does).

=> in fact the attacker must be along the path between the two parties
too because IPsec packets are protected (unfortunately not their headers,
and of course one has again the choice between either header protection
or NAT traversal).
This attack works well without any direct defense...

=> this is my "either NAT-T or security" argument with other words.

=> please note that the 3rd party bombing can (and should!) be
easily mitigated in this case (IPsec NAT traversal).

   of them at time.

=> I fully agree!

   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.

=> same!

BTW we have here both a MOBIKE justification and the answer to
the implicit/explicit issue:
 - NAT-T must be implicit (there is no choice)
 - MOBIKE must be explicit (there is a choice but explicit is strictly
   better).
Perhaps we should keep these messages for a MOBIKE vs NAT-T document?

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Thu, 24 Jun 2004 18:58:23 +0200

So, you are saying that when you move behind NAT (the way you
  detect this is by sending address update with your address behind NAT,
  RR fails, the peer does not know how to reach you anymore, timeout and
  then detect NAT), negotiate a new SA (with NAT-T) ? Is that right ?

=> your scenario is wrong: when you move behind NAT your peer detect
this at the first IKE packet it receives from you and even knows how
to reach you. Then it will close the IKE SA and let you restart from
the beginning with hopefully NAT detection and NAT-T support.

   in mobike itself.

=> MOBIKE needs something similar and more which can provide as a side
effect NAT detection. But NAT-D itself is not necessary in MOBIKE
and the IPsec WG decided to forbid direct no-NAT-T to NAT-T transition.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 24 Jun 2004 19:06:06 +0200

=> this is somthing that MOBIKE can't solve by itself because of
the way NATs "work". My proposal is to send an informational
message to the peer behind the NAT with the extra other peer addresses,
so it will be able to open parallel IKE and IPsec SAs using these
addresses.

Regards

PS: the issue is the NAT cannot know all the addresses belong to the same
node and may use different mapping for the peer behind it (and will use
if there is more than IPsec node behind it).
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 24 Jun 2004 11:54:51 -0700

> to reach you. Then it will close the IKE SA and let you restart from

It does not know for sure as the address could have been modified by the attacker.
It closes the SA because the address on the IP header is not the same as the
one in the mobike payload ? Then, it is just a policy issue. It can even try to do
RR to see whether it is reachable or not. To avoid 3rd party bombing attack,
you need to be able to communicate the external address in a protected way.

> and the IPsec WG decided to forbid direct no-NAT-T to NAT-T transition.
That does not mean we cannot explore a similar thing in this WG :-)
MOBIKE is about mobility unlike NAT-T.  

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Thu, 24 Jun 2004 23:59:39 +0200

=> I disagree: the difference between NAT-T and MOBIKE is not mobility
but multi-homing, i.e., not address change but the reacher support of
multiple addresses.

Regards