RE: MOPO and the 'ping' probes

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

> -----Original Message-----
> From: [email protected]
> Sent: Tuesday, March 08, 2005 9:01 PM
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email protected]
> Subject: RE: [Mobike] 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
>