[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSec SA DELETE in "dangling" implementation
On Thu, 02 Dec 1999 15:05:39 EST you wrote
>
> The lifetime setting stuff can be used to determine who
> initiates and when the re-keying is done. That's a
> different problem than dealt with by the draft. The
> only thing the draft intends to suggest about that is
> that you try avoid simultaneous re-keying in both
> directions. And you're right, if everyone used the
> responder lifetime notification, a simple rule
> could have been that only the initiator initiates re-keys.
But that rule is unnecessary. Just rekey at X% of the lifetime
with some jitter. I may make X=98 and you may make X=97 or
whatever it doesn't matter. And if you talk to your own box
then even if you both have identical values of X the jitter
will make simultaneous rekey very unlikely. And even if it
happens, so what?
> > If people are worried about being nice net citizens then use
> > the responder-
> > lifetime notify. It's very nice.
>
> I agree 100% that it's very nice. But the reality is that
> it is optional, so you cannot know 100% of the time that
> the peer supports it. So, if someone wants to be a nice
> net citizen, why would they say "screw you if you don't
> use the responder lifetime notify"?
But as Kivinen pointed out, deletes are optional too. And
I'm not advocating saying "screw you" I'm saying that your
problems will go away if you just Do The Right Thing. Yes,
doing the right thing is optional but if you don't you have
problems that require a whole bunch of extra work to fix (and
causes other work which requires more fixing) and some of
this work is based on other optional features being implemented
too.
I'll ask again: why wouldn't anyone use the responder-lifetime
notify for lifetimes which are greater than the configured value
and respect the lifetimes of offers which are less than the
configured value?
Dan.
Follow-Ups:
References: