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

[email protected] writes:
> 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...

I donot think the informational  exchanges are unsuitable for changing
the path. They are not optimal as we need to get reply back before we
can change the contents, but I still do not think we can work with
those. 

> 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.

Yes. This applies to all IKEv2 packets inside the IKE SA.

> 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).

But we do know something went wrong, so we can simply fix it with next
exchange, which we can start immediately when this one ends.

> 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..)

And the responder needs to process them all, and it needs to know
which one of the retransmits is the most authorative, and which one it
should skip, because the information is not up to date anymore (or
actually it can be up to date, but the initiator might not know it is
up to date, as there was some delay in the path etc).

Defining that protocol will take some effort, especially making sure
there is no replay, delayed packets, denial of service etc attacks. 

> As someone who's been involved in implementing IKEv2, I know
> that adding this kind of new exchange would require some work.

That is not a new exchange, as it does not follow IKEv2 windowing,
retransmission, replay prevention, message id etc specifications. It
is completely new protocol.

> 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).

I haven't used 1.5 years to designing or implementing the
protocol using informational exchanges. We have been really talking
about the protocol for few months now, before that we worked in the
design and requirements. We have much better understanding now what
we require from the protocol than when we startted this process.

The current thing I am proposing is about the same than my original
proposal year ago, except it didn't take NAT's in the account (I
considered them out of scope), and it also wasn't initiator decides,
but both end tried to fix situations.

Anyways regardless what we do for the path test and address update, we
need to take care of the situation when the IKE SA ip address pair
changes in the middle of the ongoing IKEv2 exchange. Thus we cannot
get rid of that code.

If we move address update to separate protocol we still need to define
what happens if the address changes in the middle of the exchange, and
the responder might have already processed my previous exchange, and
updated its address pairs, before I modify the packet and start
informing next address pair etc. I actually think that would be more
complicated than any of the proposals we have had before in the
specification point of view, and also probably require more code, as
we cannot necessarely share that much from the IKEv2 code (we need to
rewrite at least the message id, replay prevention, and windowing
code, we probably can reuse the authentication, encryption and packet
format code).

When using information exchanges we need to rwrite the retransmission
code in a such way that it knows that it needs to start trying other
addresses after it does not get reply back.
-- 
[email protected]