RE: Issue 34: Separate path test, handling changes in NAT mappings

Tero Kivinen wrote:
> > As I've repeatedly said before, if we have messages where the
> > addresses from the IP header are used for something else than
> > sending the reply, then just retransmitting the latest IKEv2
> > request cannot be used for path testing, _if_ we want to be 
> > able to do path testing at any time without changing the 
> > addresses currently in use.
> 
> Are you talking about the case where the we need to retransmit 
> the CHANGE_PATH message?
> 
> I do not see any other cases where the IP header is used in 
> any other than just replying to the packet.

Yes, CHANGE_PATH was what I had in mind (the other case is 
NAT-T dynamic update, but here we assumed it's disabled).

<snip>

> Perhaps we need to make the terminology more clear:
> 
> Address pair probe
> 
> 	This is the case when both ends do have working address
> 	pair already established, but initiator wants to test if
> 	some other addtress pair works, to verify if he can
> 	change operational address pair to that by explicit
> 	exchange later. This MUST NOT disrupt the normal packet
> 	processing of the IKE and IPsec SAs.
> 
> Recovering from lost address pair
> 
> 	This is the case when the operational address pair does
> 	not work anymore, and MOBIKE needs to find new address
> 	pair that can be used as new operation address pair. As
> 	there is already packet loss happening when this is
> 	detected, this can cause disruption to packet flow, but
> 	this recovery process will find new working address
> 	pair. Note, that we cannot have this situation ever
> 	unless we already have IKE SA exchange active, as we
> 	only detect the loss of address pair when we do not get
> 	reply back for the other peer. After this state
> 	finishes, then the original initiator will issue address
> 	pair update to move all traffic to that new working
> 	address pair.
> 
> Address pair update
> 
> 	Exchange that updates the operational address pair. The
> 	address pair update can fail in case we need to do recovering
> 	from lost address pair while sending the address pair update.
> 	In that case the address pair update is done again with the
> 	new working address pair found during the recovering from lost
> 	address pair state.
> 
> Your PATH_TEST can be used for both address pair probe, and
> during the recovering from lost address pair. In my case the
> INFORMATIONAL exchange without CHANGE_PATH would be used as a
> address pair probe, and the recovering from lost address pair,
> would use the currently active IKE SA exchange when testing
> different address pairs.
> 
> Does that make things more understandable?

Yes, it does; it also shows what's the main difference between 
a separate PATH_TEST message and your proposal: in your proposal
an "address pair probe" cannot be done while an "address pair
update" is in progress (note that a broken address pair is
not the only possible reason for doing an update).

But perhaps this is not a big problem, since an address pair
update either finishes reasonably quickly (10-20 seconds at
most, a couple of retransmissions), or if those couple of
retransmissions don't work, turns into "recovering from lost
address pair" situation. 

So if we decide to handle NAT mapping changes by sending
CHANGE_PATH messages all the time, we might drop the separate
PATH_TEST exchange.

(Of course, we already send DPD messages if we haven't received
anything for a long time, but the time scales could be quite
different. For DPD, even something like 30 minutes could be a
sufficient value of "a long time"; but to recover decently from
lost NAT mappings we're talking more like 30 seconds...)

(That message would then replace NAT-T keepalives as well,
for most practical purposes...)

Best regards,
Pasi