RE: RE: issue 34 -- ESP vs. IKE based NAT reboot detection

 > Stephane Beaulieu \(stephane\) writes:
> > I would prefer to avoid sending periodic probes
> (option 3).
> 
> We are sending them anyways if there is no traffic
> (IKE SA dead peer
> detection).
>
Hmm.. with MOBIKE, you might also send to detect new
paths or previously failed cheap-paths etc. So, if my
current path is working, i might still send probes
(not in the sense of DPD because the peer is not dead)
to find out *good* path. Perhaps, this won't be sent
at the frequency of DPD i guess. 

Note that there is a pontential for the information to
become stale if you constantly probe so that you can
be ready with the new path information when the next
failure happens. But if you know a priori that you
want to use a particular path and that path is not
working currently, you switch immediately. Would this
be more frequent than DPD ? Depends on the traffic
pattern i guess.

-mohan


>The difference is that in option 1 those
> probes are only
> used to detect if the other peer is alive, and in
> option 3 they also
> make sure that the other end the correct NAT-T
> mapping in addition to
> test that the other peer is alive. The amount and
> timers for those
> packets should be same, but Pasi was little bit
> concerned that some
> adminstrators might want to configure the timers
> shorter in case we
> select option 3 to allow faster recovery of lost NAT
> mappings. I
> myself thing that this is such corner case that I do
> not think anybody
> will configure the timers shorter because of that.
> 
> The option 3 packets will be few bytes bigger than
> the option 1
> packets, but actually the size difference is lost in
> the padding (at
> least for AES cipher). Both of them are small, i.e.
> about 100 bytes
> (ip 20 + udp 8 + ike 28 + encr header 4 + iv 16 +
> empty or 8 byte
> notify plus padding 16 + 12).
> 
> In addition to that IKE SA dead peer detection
> payloads, there is the
> normal NAT-T keepalive packets going on, which are
> again same in both
> option 1 and 3.
> -- 
> [email protected]
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>