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.
(Or at least so far nobody has described how to do it.)
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"?
(And this does not occur only when unidirectional paths are
present; random packet loss is sufficient.)
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. Otherwise, things get more complicated,
since path testing can't be considered independently of the
rest of the protocol anymore...
(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 :-)
Best regards,
Pasi
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.