[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

dynamic ports vs. rekeying



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.

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