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

Re: IPSec SA DELETE in "dangling" implementation



  Actually, no. Different definitions of "in use" would just cause one
side to renegotiate when the other would not have but it will not cause
the problem being inferred here: a "blackhole" can happen if I don't send
a delete message when I delete phase 2 SAs.

  The notion was whether to decide to rekey the SAs or not. If they aren't
"in use" (open to interpretation and implementations may vary but common 
sense should rule) then don't rekey them; if they are then do. It doesn't 
refer to the notion of unilaterally deleting SAs that you feel are not 
being used.

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


Follow-Ups: References: