Subject: RE: [Mobike] Issue 34: Separate path test, handling changes in NAT mappings

From: <[email-masked]>
Date: Fri, 15 Jul 2005 11:44:15 +0300

Tero Kivinen write:
> 
> [email-masked] 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
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 15 Jul 2005 13:29:49 +0300

> that informational exchange might be unsuitable for changing

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. 

> mind.

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

> This applies pretty well to things informational exchange

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.

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

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

> 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-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike