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

Tero Kivinen write:
> 
> [email protected] writes:
> > > > Hmm... it seems the issue of a separate path test message
> > > > vs. using normal informational exchange for path testing 
> > > > depends a lot on how we handle changes in NAT mappings (if 
> > > > e.g. NAT is rebooted or keepalive interval is too long).
> > > 
> > > Not really. The problem only occurs if we want to use the path
> > > test to test previously broken path without affecting the
> > > currect path and there is NAT-T between. If we use path test
> > > only when the operational address pair has already broken down
> > > then we do not need to modify dynamic address updates of the
> > > NAT-T.
> > 
> > This was discussed already in May 2005... At least some people
> > thought that it would be useful to allow path testing even when
> > the current path is working (and without disrupting ongoing
> > communication).
> 
> Yes, I know it was discussed earlier, but simply pointed it out here
> to explain why we need to do things here like I explained. So now
> people can really decide wheather they want that complication to the
> protocol for that feature. 

Hmm, actually it might be that having a separate exchange for
*path testing* isn't the real issue; the real issue might be
that informational exchange might be unsuitable for changing
the path...

Informational exchange requires us to keep retransmitting the
same request until we get an response; or in other words, it
assumes that once we decide to do something, we won't change our
mind.  This applies pretty well to things informational exchange
is used currently in IKEv2, but it does not apply that well to
changing addresses: if we get new information, insisting that we
continue with something we already know to be wrong just causes
problems (for instance, issue 36 with UNACCEPTABLE_PATH that
looks quite tricky... and a similar issue probably exists
with NAT prevention).

How about if we instead create a separate ADDRESS_UPDATE exchange 
with slightly different semantics: the initiator is not required
to retransmit a message forever, but can instead decide to stop
and send a new message instead? (The messages would be
encrypted and integrity protected, but they probably would have
a different Message ID space or something..)

As someone who's been involved in implementing IKEv2, I know
that adding this kind of new exchange would require some work.
But we're talking about days here; in designing a MOBIKE
protocol that actually works properly with informational
exchange in all cases, we've already spent more than 1.5 years.
So it might be a very good tradeoff (and would probably simplify
other parts of the protocol).

Any comments?

Best regards,
Pasi