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

From: "Stephane Beaulieu (stephane)" <[email-masked]>
Date: Thu, 1 Sep 2005 09:53:26 -0400

Tero, Pasi,

Not really.

DPD's are only sent *if* one suspects that the peer is no longer
receiving pkts.  What we've seen in the real world is that in a span of
a 24 hour VPN RA connection, you'll probably only see about 20-100 DPD
messages (which are usually clustered in groups during high web-usage
times).

So, DPDs are not periodic.

Having said that, I don't see why probes would need to be periodic
either.  If you suspect the pkts aren't getting to your peer, then send
the DPD/mobike probe.  Otherwise, don't send anything.  If we can agree
on this, then I'm OK with probes.

Stephane.

> -----Original Message-----
> From: Tero Kivinen [mailto:[email-masked]] 
> Sent: Thursday, September 01, 2005 9:08 AM
> To: Stephane Beaulieu (stephane)
> Cc: Jari Arkko; [email-masked]; Mohan Parthasarathy; 
> [email-masked]
> Subject: RE: [Mobike] 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). 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: Tero Kivinen <[email-masked]>
Date: Fri, 2 Sep 2005 10:49:58 +0300

> receiving pkts.  What we've seen in the real world is that in a span of

Actually no, it is sent if you suspect the other peer is dead, and you
might suspect it being dead because multiple reasons. One reason is
the lack of packets from the other end. Another reason might be the
ICMP message or some other indication from the network.

So if you suspect the other peer is dead, you test it with DPD packet.
This handling is identical with normal IKEv2, and NAT-T, and both
alternative 1 and 3.

The only difference is that in alternative 3 you notice NAT box
booting (or NAT mapping disappearing) by the lack of packets from the
other end. I.e. you notice that you are not getting any responses back
thus you start DPD as normally, and with this DPD you also request the
other end to make sure that the IP address and port number the other
peer is using matches the ones in the NAT mapping.

> messages (which are usually clustered in groups during high web-usage

If there is traffic going on in both directions then you do not ever
see DPD packets. You only see DPD packets when you do not receive
packets from the other end (either it being dead or it being idle). 

> So, DPDs are not periodic.

True, the original description was misleading because of that.

> on this, then I'm OK with probes.

This is the case with alternative 3. I.e. they are not periodic, they
are only sent when the host behind NAT (initiator) detects that it is
not receiving anything from the other end (perhaps because the NAT
reboot or something), and that DPD will then also be used to fix the
NAT mapping in the other peer (i.e. do the similar update that
alternative 1 does for all packets, here we simply explicitly request
the other end to fix the situation).
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Fri, 02 Sep 2005 11:07:42 +0300

Tero Kivinen wrote:

>not receiving anything (snip)
>
True. But I guess you could say that when your device is
idle, the probes are being sent and are periodic... how much
that matters is a matter of opinion.

--Jari