Subject: RE: [Mobike] MOPO and the 'ping' probes

From: "Timothy Liu" <[email-masked]>
Date: Tue, 8 Mar 2005 08:06:30 -0800

The 'ping' was used to test new paths not the liveness of current path.
On other points I agree with you that we should not use ICMP packets
which can be treated quite differently by firewall devices.

There is an approach base on same idea, I am not sure if this has been
brought up before. Why not send DPD with the same sequence number
(simultaneously?) to all the paths that the peer wants to test? From the
other side it can treat is as retransmission and resend the DPD response
through the different paths. The retransmission policy on the requester
side is only to retry along the primary path.

Tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephane Beaulieu
Sent: Tuesday, March 08, 2005 7:24 AM
To: 'Eric Vyncke'; [email-masked]
Subject: RE: [Mobike] MOPO and the 'ping' probes

Hi All,

Just coming up to speed on Mobike.  I am unable to attend the IETF, so I
apoligize for having to chime in after the fact.

I was just reviewing the slides this morning, when I noticed the
possible
use of ping for reachabiilty.  I don't like this approach for 2 reasons:
1 - From an implementor's standby, ICMP is very detached from IKE, and
I'd
like to leave it that way.  ICMP is often handled by the Network
Processor,
while IKE is handled at the application layer.  While adding hooks
between
the two is not impossible, it is not desireable.
2 - ICMP may be restricted by different ACLs than Ipsec or IKE packets.
So,
an ICMP failure or success wouldn't necessarily match an Ipsec or IKE
failure or success.

I wonder why the simple DPD combined with IKE retransmit mechanism
wouldn't
suffice.

The way I see it, is one of two things is happening where you can decide
that perhaps a peer's interface has gone down.
1 - You've sent ESP packets, but you haven't received any ESP packets
from
the peer in x seconds (triggering DPD) 
2 - You sent an IKE packet (PHASE2, rekey, Ack'd notify, whatever), have
retransmitted a few times, and you are not getting a reply.

Wouldn't these 2 things suffice?  Basically, I tried to send the peer an
IKE
packet (+ a couple of retransmits) and I'm not getting a reply.

If this happens, you could then switch to using the next address in the
list.

Another issue that is bothering me.  Instead of just switching to the
next
address in the list, could we not instead send the peer an
NOTIFY-POSSIBLE-INTERFACE-FAILURE to the peer using all the other
addresses
we know.  The peer could then make an intelligent decision, and perhaps
even
prompt the user.  The peer would send us a CHANGE-PATH message.  This
would
make the implementation simpler as an IP address change would always be
initiated by the peer who is changing addresses.  Also, it would help
avoid
cases where the two peers are using different IP addresses
During a transition.  The cost of doing this, of course, is the extra
latency of an extra notify message exchange.

Thoughts?

Stephane.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eric Vyncke
> Sent: Tuesday, March 08, 2005 8:17 AM
> To: [email-masked]
> Subject: [Mobike] MOPO and the 'ping' probes
> 
> As Paul asked for new voices during yesterday meeting... ;-)
> 
> I just wonder using 'ping' to test the reachability of a peer 
> is correct. 
> 
> Pings will give a good indication in 95% of the use cases, 
> but, due to ICMP rate limiting (to prevent DoS), due some 
> security policy (denying ICMP or IPsec over UDP), ... there 
> will be a disconnect in a couple of use cases between a ping 
> exchange and an IKEv2 exchange.
> 
> In some cases, ping will go back and forth the peers while 
> IKEv2 won't.
> 
> In some other cases, ping will not go back and forth the 
> peers while IKEv2 will.
> 
> In short, use out-of-IKE probes only as a very rough estimate.
> 
> Hope this helps
> 
> -eric
> _______________________________________________
> 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
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 08 Mar 2005 10:21:36 -0600

> side is only to retry along the primary path.

yes, but you also need to handle the case when the sender didn't have enough
window for even one request because all window slots were occupied by messages
which hadn't gone through because the preferred path was broken..

One solution would be to use a real request instead of a DPD ping
when you actually have something real to send.

I'd think simultaneous probes would be considered unfriendly to the network;
non-simulataneous (delay of a large fraction of the RTT or so between each probe)
might be nearly as good at finding a path without generating nearly as much redundant
traffic...

---

From: "Stephane Beaulieu" <[email-masked]>
Date: Tue, 8 Mar 2005 11:39:28 -0500

> > (simultaneously?) to all the paths that the peer wants to 
> test? From 
> > the other side it can treat is as retransmission and resend the DPD 
> > response through the different paths. The retransmission 
> policy on the 
> > requester side is only to retry along the primary path.
> 
> yes, but you also need to handle the case when the sender 
> didn't have enough window for even one request because all 
> window slots were occupied by messages which hadn't gone 
> through because the preferred path was broken..

Agreed.

> 
> One solution would be to use a real request instead of a DPD 
> ping when you actually have something real to send.

That depends on what you define as being 'something real'.  Is a normal DPD
something real?

For example, I notice that some TCP sessions are starting to time out
because the peer isn't ack'ing my packets.  Therefore, I elect to send a DPD
message to check for liveliness.  I would think this would qualify as a
'real' message, but wanted to double-check that we are on the same page.

> 
> I'd think simultaneous probes would be considered unfriendly 
> to the network; non-simulataneous (delay of a large fraction 
> of the RTT or so between each probe) might be nearly as good 
> at finding a path without generating nearly as much redundant 
> traffic...
> 
> 
> 
> 
> 
> 
> 
> 
>