[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:
>   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 stability
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



> Doing a gratuitous negotiation here would be something a naughty 
> net-citizen would do.
> 
>   This can happen though if you did (your syntax may vary):
> 
>        prompt# crypto clear ike
>        prompt# crypto clear ipsec
> 
> And the traffic was strictly unidirectional and these commands were entered 
> on the sink (as opposed to the source).
> 
> But this requires 1) operator intervention; and some unique traffic (maybe
> multicast?). Given that certain must-audit events would start happening if
> this problem occured the operator who caused them would most likely 
> immediately see the error in his ways. Of all the loaded weapons we're
> putting in the hands of the net admin guy this one seems to be of a 
> particularly small caliber and would not cause pain if used to shoot oneself 
> in the foot. In other words, I still don't see the problem with non-continuous 
> phase 1 SAs. 
> 
>   Dan.
> 
> On Tue, 30 Nov 1999 16:16:20 PST you wrote
> > On Tue, 30 Nov 1999, Slava Kavsan wrote:
> > > The issue still remains, though:
> > > 
> > > "When deleting all SAs - in order to delete "orphan" IPSec SAs  - starting
> > > re-negotiation of IKE SA seems kinda silly when the goal is to kill all
> > > SAs."
> > > 
> > If you want to be a nice net-citizen, and interoprate cleanly and robustly,
> > then you should renegotiate the phase 1 to securely let the other end know
> > that it should delete it's phase2's also. You can then proceed to also delete
> > your phase1 (after sending a delete for the same ;). Thus, you now have a
> > clean ending of all connections.
> > 
> > I don't really see a problem with this.
> > 
> > jan
> 

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