RE: MOPO and the 'ping' probes

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 protected] [mailto:[email protected]]
On Behalf Of Stephane Beaulieu
Sent: Tuesday, March 08, 2005 7:24 AM
To: 'Eric Vyncke'; [email protected]
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 protected] 
> [mailto:[email protected]] On Behalf Of Eric Vyncke
> Sent: Tuesday, March 08, 2005 8:17 AM
> To: [email protected]
> 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 protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
> 
_______________________________________________
Mobike mailing list
[email protected]
https://www.machshav.com/mailman/listinfo.cgi/mobike