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

From: <[email-masked]>
Date: Tue, 8 Mar 2005 17:50:36 +0200

Hi,

Perhaps my presentation was a bit unclear on this, but MOPO-IKE does
not use ICMP (which would not really work, due to the reasons you
mentioned).  Instead, it adds a new message type to IKEv2 (somewhat
similar to the IKEv1 R-U-THERE/R-U-THERE-ACK messages).

Best regards,
Pasi

> -----Original Message-----
> From: Eric Vyncke
> Sent: Tuesday, March 08, 2005 3:17 PM
> 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

---

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

>similar to the IKEv1 R-U-THERE/R-U-THERE-ACK messages).

Thanks for the clarification.

-eric

---

From: "Timothy Liu" <[email-masked]>
Date: Tue, 8 Mar 2005 09:34:59 -0800

> From: Bill Sommerfeld [mailto:[email-masked]]
> Sent: Tuesday, March 08, 2005 8:22 AM
> To: Timothy Liu
> Cc: [email-masked]; Eric Vyncke; [email-masked]
> Subject: RE: [Mobike] MOPO and the 'ping' probes
> 
> On Tue, 2005-03-08 at 10:06, Timothy Liu wrote:
> > 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.
> 
> 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..

Good point.

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

How about this for a path test: cycle through the non-primary paths you
want to test, use the last request message sent to the peer. (Does not
matter whether this request has already got a reply or not). To the peer
it is going to look like a new request, which it is going to process and
respond anyway, or a retransmission, for which it is going to retransmit
the last response.

The exception is if the last message is PATH_CHANGE. Here to avoid out
of order arrival and change to a wrong path, you just have to wait for
it to complete. If PATH_CHANGE fails, we would need to tear down the SA.
But to recover from it we may need window size > 1 anyway.
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Timothy Liu" <[email-masked]>
Date: Tue, 8 Mar 2005 11:00:57 -0800

The reason you can not transmit PATH_CHANGE message along another path
is because there maybe NAT detection payload inside.

Tim

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 08, 2005 10:13 AM
> To: Timothy Liu; [email-masked]
> Timothy Liu writes:
> > How about this for a path test: cycle through the non-primary
> > paths you want to test, use the last request message sent to
> > the peer. (Does not matter whether this request has already
> > got a reply or not).  To the peer it is going to look like a
> > new request, which it is going to process and respond anyway,
> > or a retransmission, for which it is going to retransmit the
> > last response.
> 
> Yes. This would work perfectly if the peer never uses the
> src/dst addresses from the IP header for anything else except
> transmitting the reply.
> 
> However, the MOBIKE protocol will use them, in some cases at
> least (and other IKEv2 extensions defined in the future might,
> too)....and thus there are some complications (in case the
> peer actually had not received the last message yet).
> 
> > The exception is if the last message is PATH_CHANGE. Here to
> > avoid out of order arrival and change to a wrong path, you
> > just have to wait for it to complete. If PATH_CHANGE fails, we
> > would need to tear down the SA.  But to recover from it we may
> > need window size > 1 anyway.
> 
> I think this situation is actually quite important: usually you
> change paths because something just went down or something new
> came up, and this is precisely the time when it's most likely
> that other things go wrong, too.
> 
> MOPO-IKE tries to recover from this situation even with window
> size 1 by adding a new IKEv2 message that is not constrained by
> the window size (since it's not part of any particular IKE_SA).
> 
> Thus, we can use the new PATH_TEST message to find a working
> path even if the window was "full". After that, we of course
> have to retransmit the last message (if we had not received a
> reply to it yet), but if it was CHANGE_PATH message, then it
> will actually cause the traffic to be moved to the right path!
> (However, since we don't know whether it was the request or the
> reply that got lost, we have to send another CHANGE_PATH message
> to be sure.)
> 
> There's also a second case when a separate PATH_TEST message is
> useful: when the current path works just fine, but it's not the
> path we'd actually like to use. We can use the PATH_TEST message
> to easily check whether the "preferred path" has become operational
> again without worrying about possibly disrupting anything happening
> on the current path. For instance, if the preferred path for some
> strange reason (e.g., asymmetric routing combined with failure
> somewhere, malfunctioning filtering device) works only in the
> A-to-B direction, then just sending a DPD might cause B to move
> the traffic there is NAT Traversal is enabled (which would
> break things that were working just fine).
> 
> Best regards,
> Pasi

---

From: <[email-masked]>
Date: Wed, 9 Mar 2005 00:28:43 +0200

Tero Kivinen writes:
>
> [email-masked] writes:
> I disagree on that. 

Perhaps saying "works perfectly" is exaggarating slightly,
but using the latest request for path testing would certainly
be easier if the src/dst address from IP header was not
used for anything else than the reply.

> There is no MOBIKE protocol yet. Your MOPO might be using them, 
> and it must be doing things that way, but do not generalize that 
> to MOBIKE protocol which is not yet even defined. 

This is not a feature of just MOPO, but any MOBIKE protocol that 
works with NATs (and does not do Unilateral Self-Address Fixing).

And yes, I know we still have not formally decided whether the
MOBIKE protocol will work with NATs. But I don't think we should 
even consider doing UNSAF, because that would certainly amount to 
changing how IKEv2/IPsec NAT Traversal works. 

Best regards,
Pasi

---

From: <[email-masked]>
Date: Wed, 9 Mar 2005 00:37:46 +0200

Hmm, you're right, retransmitting the PATH_CHANGE message 
along another path may lead to unnecessarily enabling NAT 
Traversal for a short period (before the second PATH_CHANGE 
message disables it again, if in fact it's not needed).

I'll mention this in the next version of MOPO-IKE draft.

Best regards,
Pasi

> From: [email-masked]
> Sent: Tuesday, March 08, 2005 9:01 PM
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> The reason you can not transmit PATH_CHANGE message along another 
> path is because there maybe NAT detection payload inside.
> 
> Tim
>