RE: MOPO and the 'ping' probes

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