Re: dynamic ports vs. rekeying

[Jan Vilhuber <vilhuber@cisco.com>]

On 5 Apr 2002, Andrew Krywaniuk wrote:

> I think dynamic selectors are different from rekeying. Not only does
> updating the selectors of the existing SA save bits on the wire, but from a
> robustness point of view, it means that to any synchronization errors
> between the peers will only affect the new traffic.
>
> Imagine there is a race condition between the QM3 (or Create_Child_Sa2) and
> the data traffic. The most reliable thing to do is to send the old traffic
> on the old SA for a short while and send the new traffic on the new SA
> (since the selectors won't match the old SA). Wouldn't it be easier to send
> send all traffic on the new SA automatically because the new SA is the old
> SA? If the selectors haven't been updated yet then new traffic will be
> dropped for a short while.
>
> On the subject of rekeying, I agree that using the old phase 1s until they
> expired (as specified in draft-jenkins) didn't work, but the immediate
> switch-over in draft-specncer is too hasty. I recommend that an
> implementation should continue to use its old SA for a short time (e.g. 30
> seconds) after the new one is negotiated to account for any lost packets. It
> should also wait a short time after that before deleting the old SA.
>

Is this still an issue in ikev2? Quick mode is no longer 3 messages,
so the responder can immediately install all SA's and the initiator
can start sending when he receives the reply...

jan


> -------------------------------------------
> There are no rules, only regulations. Luckily,
> history has shown that with time, hard work,
> and lots of love, anyone can be a technocrat.
>
>
>
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Bill Sommerfeld
> > Sent: Friday, April 05, 2002 2:29 PM
> > To: Jan Vilhuber
> > Cc: Bill Sommerfeld; Paul Hoffman / VPNC; Tero Kivinen;
> > ipsec@lists.tislabs.com
> > Subject: Re: Do we actually need dynamic ports?
> >
> >
> > > Well the draft that Pyda wrote changes the payload so that it's NOT
> > > ambiguous (it tags each SA with a policy ID, so you always know
> > > exactly which traffic-policy you're talking about (even if
> > your SPI's
> > > may change), and added an add/remove flag).
> >
> > I wasn't thinking of reordering within the KM protocol, but rather
> > reordering between the KM protocol and AH/ESP traffic, especially in
> > the case of selector deletion.
> >
> > If the SPI changes, we reduce selector-set changes to the same
> > [un]solved problem as graceful rekeying ;-)
> >
> > 					- Bill
> >
>

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847