[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSec SA DELETE in "dangling" implementation
On Tue, 30 Nov 1999, Dan Harkins wrote:
> Making it a "known" protocol instead of an "inferred" protocol is a
> problem for the editors of the relevant documents. The documents should
> make problematic issues clear and if a firm definition of "in use" or
> when to rekey an SA or what to do in some situation is needed to nip
> some problem in the bud then suggested text goes a long way. But I'm
> still having trouble seeing what the problem is. If it requires manual
> intervention on a particular end of the session and a certain form of
> traffic and is easily identified when it occurs then I don't think that's
> a problem. If a "blackhole" could happen without manual intervention, on
> either end of the session, and with any traffic then that would be a
> problem.
Well, we've certainly had reports of exactly that, although I'm not currently
sure why or how. But it does happen (whether as a bug in our implementation
or a bug in the protocol remains to be proven, of course).
jan
> Everyone wants stability and customer acceptance but establishing
> a phase 1 SA for the sole purpose of sending a delete message, and then
> deleteing the phase 1 SA would not make this any more stable or acceptable
> to the customer.
>
> Dan.
>
> On Tue, 30 Nov 1999 17:45:45 PST you wrote
> > On Tue, 30 Nov 1999, Dan Harkins wrote:
> > > Well the problem is that this is sort of like waking up someone to
> > > tell them to go to sleep. There's wasted work (trying to get back to
> > > sleep/public key operations) for what probably wouldn't pass the "duh!"
> > > test (already sleeping/was gonna delete that anyway).
> > >
> > > In normal operation I don't see this happening. Assuming that lifetimes
> > > are respected then the phase 1's will expire pretty much at the same time.
> > > Either or both can send deletes and no problem. Then when the phase 2s
> > > get around to being deleted they will either need to be rekeyed (if either
> > > is "in use") in which a phase 1 will have to be re-established anyway or
> > > they will just be deleted (if neither are "in use") in which case the
> > > other guy will just be deleteing them anyway and there's no need to send
> > > a delete.
> >
> > That's assuming that both sides have the same definition of 'in use'. I can
> > imagine two different definitions, which would result in deleting an SA
> > earlier than the other.
> >
> > Granted, in that case the one with the more lax definition of 'in use' will
> > try to rekey with us (and we'll presumably let him), so it's still not a
> > problem.
> >
> > Experience so far, however, leads me to believe that anything that will make
> > this a more 'known' protocol as opposed to 'inferred' the better the stabilit
> >y
> > and therefore customer acceptance. Therefore, I'm all in favor of some
> > gratuitous re-establishements, if they aid in making both sides communicate
> > better.
> >
> > No, I don't have any concrete examples, unfortunately..
> >
> > jan
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
References: