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

Re: IPSec SA DELETE in "dangling" implementation

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

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
Follow-Ups: References: