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

From: Tero Kivinen <[email-masked]>
Date: Thu, 1 Sep 2005 11:35:37 +0300

Mohan Parthasarathy writes:
> > 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.
> > 
> If you do IKEv2 like updates, then you need a separate PATH_TEST
> message (outside the SA) so that PATH_TEST does not cause updates
> to SA. By requiring an explicit update, we avoid a separate PATH_TEST
> message. Is that an advantage ?

I think it is advantage, if we do not need to implement separate
PATH_TEST. It makes the protocol cleaner. The separate PATH_TEST has a
feeling of a hack for me. 

Also it will localize the policy decisions on the IP-address changes
to one place, so the policy will be same regardless why we change the
address.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: <[email-masked]>
Date: Thu, 1 Sep 2005 16:05:34 +0300

Stephane Beaulieu wrote:
> 
> I would prefer to avoid sending periodic probes (option 3).

Note that these periodic probes are already present in normal
IKEv2; option 3 just piggy-backs additional information (NAT
detection payloads) to the same messages.
 
> 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.

Since the same messages are sent in normal IKEv2 as well, 
option 3 has a performance hit (on gateway load) only if 
choosing it causes the users to change the timer values
for DPD ("X" in my IETF63 slides; essentially how long to
accept a situation where we have only outgoing traffic before
getting suspicious and starting DPD). 

This is what I was initially worried about as well (choosing 
option 3 would lead to users choosing significantly smaller 
values for X), but I'm not so sure anymore this would happen...

Best regards,
Pasi

---

From: "Stephane Beaulieu (stephane)" <[email-masked]>
Date: Fri, 2 Sep 2005 07:55:54 -0400

OK.  Sounds like we are in agreement.

If a host suspects that his peer is dead (or the path is dead), then he
sends a DPD/mobike probe.

It's worth noting that a host MAY use the arrival of a packet which
seems to have wrong IP or port (due to possible NAT mapping change) to
trigger this process.  This IMO, is the best of both worlds.

Stephane.

> -----Original Message-----
> From: Tero Kivinen [mailto:[email-masked]] 
> Sent: Friday, September 02, 2005 3:50 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:
> > 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
> 
> 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.
> 
> > 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).
> 
> 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.
> 
> > 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.
> 
> 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]
>