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

 

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

> 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.
> 
Ah! I missed this part.

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

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

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

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

> 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"...
> 
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 :-)

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

Yes.

-mohan

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