RE: dynamic ports vs. rekeying

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

> I assume you're speaking in the context of rekeying which
> also plays games
> with selectors?  Without that, we have extensive operational
> proof that
> the immediate cutover works just fine...

Not at that point in the message, no. Here I was talking about plain old
IKEv1 rekeying. I am sure that immediate cutover will work just fine in the
vast majority of cases. That's why you have operational evidence to back
this up. The problems happen when QM3 gets dropped or when QoS causes packet
reordering. I'm sure you don't see this happen much because QoS isn't widely
deployed, and QM3 isn't very likely to get dropped in your case (although
the probablility is much higher of QM3 getting dropped by a gateway under
heavy load).

The purpose of rekeying in advance is to avoid traffic loss during the
transition. Immediate cutover avoids the 99% chance of traffic loss while an
SA is renegotiated. The 30 second delay before switchover avoids the 10%
chance of traffic loss when packets get dropped or reordered. (to pull some
numbers out of the air)

Andrew
-------------------------------------------
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 Henry Spencer
> Sent: Saturday, April 06, 2002 12:54 AM
> To: IP Security List
> Subject: Re: dynamic ports vs. rekeying
>
>
> On 5 Apr 2002, Andrew Krywaniuk wrote:
> > 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 assume you're speaking in the context of rekeying which
> also plays games
> with selectors?  Without that, we have extensive operational
> proof that
> the immediate cutover works just fine...
>
>
> Henry Spencer
>
> henry@spsystems.net
>