RE: MOPO and the 'ping' probes

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

Tim

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Tuesday, March 08, 2005 10:13 AM
> To: Timothy Liu; [email protected]
> Subject: RE: [Mobike] 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