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

 

> In your previous mail you wrote:
> 
>    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

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.

> the beginning with hopefully NAT detection and NAT-T support.
> 
>    At some point in time, there was a discussion about adding NAT-D payloads
>    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.
> 
That does not mean we cannot explore a similar thing in this WG :-)
MOBIKE is about mobility unlike NAT-T.  

-mohan

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