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

[email protected] writes:
> BTW, choosing option 2b (disable NAT-T dynamic updates) does not
> really get rid of the need for a separate path test message.
> 
> 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.

The CHANGE_PATH is different as there we MUST use the IP header
information if we want to work with NATs.

If we need to retransmit CHANGE_PATH then it will change the address
pair to something else than what was initially intended, but unless
there is uni-directional problems then the responder will change it to
the working address pair, thus the second CHANGE_PATH done by the
initiator will be simpy no-op for the responder.

If there is uni-directional problems (where responder receives
packets, but cannot send reply), then the responder will always update
the address pair to wrong address pair first, regardless weather we
are using INFORMATIONAL exchanges or completely new protocol to do
that (unless we make the exchange 4 packet exchange or similar).

You can use any non-CHANGE_PATH packet as a path test message, without
any problems, as they do not cause any changes in the other end.

And if you want to send CHANGE_PATH, that normally means that you have
already verified with some other packet that the path already works,
thus if that needs to be retransmitted to another address it means
that the link did broke down between that test and update (again
corner case), thus we are supposed to loos packets in that situation
in all cases.

> Disabling dynamic updates does not radically change the
> situation; we still have the CHANGE_PATH message left.  It seems
> your proposal is "drop the last requirement; it's not a problem
> if path testing might disrupt the communications"?

Path testing will never disrupt communications, as you do not do path
test with CHANGE_PATH packets. I.e. if you have working connection
before, and you want to verify if the other address pair works, you do
that with INFORMATIONAL exchange which do NOT have CHANGE_PATH, thus
it does not cause any disruption to the communcations.

Note, that am talking now about path testing function, i.e. the
operation when you want to test wheather the address pair is working
or not.

I am not talking about the situation when we notice in the middle of
the exchange that the current address pair does not work. That is not
path testing, that is recovering from problem. To do that recovery you
need to find new working address pair, but I and you do that with
testing different addresses, but I do not consider that path testing,
more like searching for working address pair.

> (And this does not occur only when unidirectional paths are
> present; random packet loss is sufficient.)

Random packet loss of half a dozen packets, where all reply packets are
dropped, is called unidirectional path.

For that negotiation that path was unidirectional. It does not matter
for some other traffic or some other exchange it is bi-directional,
but for that exchange it was unidirectional.

> IMHO this would actually complicate the protocol. It's easy
> enough to describe and implement the current PATH_TEST exchange,
> since you can send it at any time, and it doesn't depend on what
> else is going on.

Yes, it is easy to implement, but it does not help at all. You still
need to take care of the IKE SA exchange that is going on while you
loose the connection. I.e. the searching of the new address pair, and
changing to use that.

> Otherwise, things get more complicated,
> since path testing can't be considered independently of the
> rest of the protocol anymore...

I do not agree on that. 

> (Or maybe some lazy implementor would just use IKE_SA_INIT for
> path testing, since it would actually work without disrupting
> anything else that's going on :-)

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?
-- 
[email protected]