[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPSec SA DELETE in "dangling" implementation
Until acknowledged delete notifies are deployed you could renegotiate, send
the delete, and still end up with the same situation as if you didn't bother
to renegotiate and send the delete. One possible solution is to only
renegotiate and send a delete if you continue to receive "dead spis" from
the peer (but this has the drawback of having to retain peer information
after the IKE SA is deleted on security gateways for the peer-road-warrior
case - a client would normally not receive traffic from a gateway after it
has stopped sending traffic except for possibly a trailing packet or two
that could just be dropped).
-dave
-----Original Message-----
From: Jan Vilhuber [mailto:vilhuber@cisco.com]
Sent: Tuesday, November 30, 1999 7:16 PM
To: Slava Kavsan
Cc: Paul Koning; ddp@network-alchemy.com; ipsec@lists.tislabs.com
Subject: 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