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

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 ? 

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

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