[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSec SA DELETE in "dangling" implementation
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
> (I also assume that there is no "step-parent" IKE SA exists with the same
> peer to "adapt" these "orphans")
>
>
>
>
> Paul Koning wrote:
>
> > >>>>> "Derrell" == Derrell D Piper <ddp@network-alchemy.com> writes:
> >
> > >> b) re-negotiate IKE SA before sending DELETE
> > Derrell> ...which would beg the question of whether or not it's legal
> > Derrell> to send an IPSEC DELETE on an IKE SA that did not originally
> > Derrell> negotiate the IPSEC SA's. Our particular implementation
> > Derrell> would accept that, but I can also see an argument for while
> > Derrell> that's not right.
> >
> > I think it has to be accepted.
> >
> > Reasoning: either phase 2 SAs are bound to phase 1 SAs or they are
> > not.
> >
> > If they are, then the phase 2 SAs go away when the phase 2 SA does,
> > and it is reasonable to require messages relating to the phase 2 SAs
> > to come over the phase 1 SA to which they are bound.
> >
> > If they are not, then the phase 1 SA may disappear without affecting
> > the phase 2 SAs. But also, if they aren't bound, then it is illogical
> > to require messages about the phase 2 SA to arrive via the phase 1 SA
> > that created it, because by definition there wasn't any such binding.
> > And never mind that abstract argument... if you make that restriction
> > then it follows that you can no longer send ANY messages about the
> > phase 2 SA once the original phase 1 SA disappears. That defeats the
> > purpose of the non-binding approach!
> >
> > Since IKE is defined the latter way (no binding) messages such as
> > deletes of a phase 2 SA must be accepted on any phase 1 SA (from the
> > right source, obviously).
> >
> > paul
>
> --
> Bronislav Kavsan
> IRE Secure Solutions, Inc.
> 100 Conifer Hill Drive Suite 513
> Danvers, MA 01923
> voice: 978-539-4816
> http://www.ire.com
>
>
>
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
Follow-Ups:
References: