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

Re: IPSec SA DELETE in "dangling" implementation

On Tue, 30 Nov 1999, Bronislav Kavsan wrote:
> In other words:
> 
> - Dan recommends do not send DELETEs in these situations - it sounds reasonable,
> but IMHO could lead to some "in-limbo" scenarios -  I would call it "medium-rare"
> solution :), while
> - Jan recommends to re-negotiate IKE SA and then send DELETEs - which also sounds
> reasonable - I would call it "well overdone" :) solution and probably could cause
> some catch 22 complications
> 
Actually, I don't recommend anything at all. I merely said I don't really see
a problem with it. I'm not sure what I recommend at this point.

jan



> Therefore, both of you assume that there is no IMMEDIATE IKE SA re-establishment
> after the old IKE SA has expired or deleted - it is not quite the same as so-called
> "continuous" (ala Tim Jenkins proposal), but continuous in the sense that there is
> always IKE SA between peers that have at least one IPSec SA between them. In other
> word - it is true "dangler" implementation.
> 
> (I hate these worms from the re-opened cans, but the issue is still not solved once
> and for all)
> 
> Dan Harkins wrote:
> 
> >   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
> 
> 
> 

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847
References: