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

Mohan Parthasarathy writes:
> Tero,
> 
>  > > 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.
> 
> 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 protected]