Subject: RE: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection

From: "Stephane Beaulieu (stephane)" <[email-masked]>
Date: Thu, 1 Sep 2005 08:50:19 -0400

I would prefer to avoid sending periodic probes (option 3).

Even though the HW may not be capable of detecting and performing
IP/port changes *today*, they will be able to do it in the future
(especially if we make it a requirement for them).

It's not like if Mobike is going to be mass deployed tomorrow.  This is
going to take a long time to bake and test.  Start working with your HW
vendors now, and let's do it right the first time.  Those who ship
before the HW is ready can document this corner case, or solve it via
some less efficient SW workaround (for now).  I'd rather take the
performance hit for BETA than forever...

I vote option 1.
Stephane.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jari Arkko
> Sent: Thursday, August 25, 2005 6:03 AM
> To: Tero Kivinen
> Cc: [email-masked]; Mohan Parthasarathy; [email-masked]
> Subject: Re: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT 
> reboot detection
> 
> Tero Kivinen wrote:
> 
> >Thats why I am saying alternate 3 is better, as it requires less 
> >changes or updates to the hardware.
> >  
> >
> One could also support ESP-based updates on devices that can 
> do this, and say "this feature is not supported"
> on others -- we are still talking about a corner case.
> But people may have different opinions as to how important 
> support for this is under all circumstances.
> 
> --Jari
> 
> _______________________________________________
> Mobike mailing list
> [email-masked]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
> 
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 1 Sep 2005 16:07:58 +0300

> 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). 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-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Mohan Parthasarathy <[email-masked]>
Date: Thu, 1 Sep 2005 09:51:17 -0700 (PDT)

> 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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 2 Sep 2005 10:52:53 +0300

> at the frequency of DPD i guess. 

The actual packets might be identical, but they are not DPD packets,
they are path test packets because of the function they perform is
different...
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike