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

From: Eric Vyncke <[email-masked]>
Date: Tue, 08 Mar 2005 14:17:03 +0100

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 08 Mar 2005 17:00:54 +0200

Right, and this would indeed be an issue.

But I think Pasi's intent was to use a new IKEv2 message
instead of ICMP. He just referred to the message as a 'ping'.

His proposed message was indeed outside the normal IKE processing,
but only with regards to the window, not in terms of going outside UDP
and port 500, or the IKEv2 message structure...

--Jari

---

From: "Stephane Beaulieu" <[email-masked]>
Date: Tue, 8 Mar 2005 10:24:24 -0500

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
> 
> 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.
>