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

RE: IPSec SA DELETE in "dangling" implementation



Andrew

As long as there is no guarantee of delivery of the DELETE notification, we
still have to handle the case were there is no delete. I agree that the
attempt must be made though.

Scott


> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Andrew Krywaniuk
> Sent: Friday, December 03, 1999 6:06 AM
> To: Jan Vilhuber; Dan Harkins
> Cc: Markku Savela; srao@ibondinc.com; ipsec@lists.tislabs.com
> Subject: RE: IPSec SA DELETE in "dangling" implementation
>
>
> That's probably a good idea. Change them to a MUST.
>
> <Begin game theory analysis>
>
> My point here was that this is essentially a tragedy of the commons.
> Processing the peer's lifetime notify and ensuring that *his* security
> policy is enforced is a losing move (it provides no benefit to you and you
> have to spend time implementing it). But if the peer parses *my* lifetime
> notifies and enforces *my* security policy then I gain.
>
> The best way to solve a tragedy of the commons is to make the feature a
> MUST. This provides a tangible penalty for failure to cooperate
> (you are not
> standards compliant) and benefits everyone.
>
> On the other hand, processing deletes is not a tragedy of the commons. The
> peer has no way to determine whether you sent a delete because
> you detected
> a potential security violation or simply because you are
> enforcing your own
> SA lifetime rules, so he has a clear incentive to cooperate. Therefore, I
> believe that every vendor will process deletes, even if we don't
> make them a
> MUST (although there is no good reason not to).
>
> That's why I suggested that you always send the delete. When you
> are relying
> on the peer to help you enforce your security policy you have to
> trust them
> not to be malicious, but you can't assume that they will be
> altruistic. The
> fact is, enforcing this aspect of your security policy has nothing to do
> with what *you* implement; it's what everyone else implements that counts.
>
> <End game theory analysis>
>
> Andrew
> _______________________________________________
>  Beauty without truth is insubstantial.
>  Truth without beauty is unbearable.
>
>
> > -----Original Message-----
> > From: Jan Vilhuber [mailto:vilhuber@cisco.com]
> > Sent: Thursday, December 02, 1999 5:58 PM
> > To: Dan Harkins
> > Cc: Markku Savela; srao@ibondinc.com; ipsec@lists.tislabs.com
> > Subject: Re: IPSec SA DELETE in "dangling" implementation
> >
> >
> > So if both responder lifetime and delete notifications are
> > something anyone
> > in their right minds would implement, why don't we solve this
> > whole debate by
> > changing them to MUST in the new version?
> >
> > If they remain SHOULD, then you can't assume that the remote
> > has implemented
> > this. Despite it being common-sense, there's still
> > implementors out there
> > that implement the bare necessities, i.e. only the MUSTs. If
> > we really think
> > this is common-sense to implement, then what's the objection
> > to making thing
> > like that a MUST?
> >
> > jan
> >
> >
> > On Thu, 2 Dec 1999, Dan Harkins wrote:
> >
> > > On Thu, 02 Dec 1999 22:33:56 +0200 you wrote
> > > >
> > > > > Since life times may not be same on both ends, I also
> > feel that we need
> > > > > to send Deletes to other end when IPSEC SA hard life
> > time expires.
> > > >
> > > > I claim:
> > > >
> > > > An IPSEC SA is a unidirectional entity between two end points:
> > > >
> > > >          (SA)
> > > >     A ----------> B
> > > >
> > > > There is no such thing as one SA on A, and a different SA
> > on B. SA's
> > > > on both ends are just internal representation of the same logical
> > > > SA. They *MUST* have all parameters equal, including
> > lifetimes. Any
> > > > other situation should be considered as error or undefined state.
> > > >
> > > > I hope above will be kept in the name of predictability and
> > > > simplicity!
> > >
> > > Yes, me too.
> > >
> > > > If implementations want to break this "rule", they should
> > be prepared
> > > > to handle the "side effects" of the breaking without
> > requiring changes
> > > > to the other valid implementations (I guess the problem
> > of lifetimes
> > > > arises from the IKE omission that the responder does not have
> > > > guaranteed way to communicate to the other end that it
> > wants to change
> > > > the proposed lifetimes -- conforming implementation can
> > either accept
> > > > them as is or reject. Right?)
> > >
> > > No it can use the responder-lifetime message if it doesn't
> > want to accept
> > > the offer as is. But your absolutely right that implementations that
> > > break this rule suffer undesirable side effects and need some other
> > > mechanism like always keeping an IKE SA around, and always
> > sending delete
> > > messages, and alway assuming that the other party processes
> > deletes, and
> > > binding the IPSec SA to the IKE SA in a manner which is not
> > inferred by
> > > any of the relevant RFCs.
> > >
> > >   Dan.
> > >
> > >
> > >
> >
> >  --
> > Jan Vilhuber
> > vilhuber@cisco.com
> > Cisco Systems, San Jose
> > (408) 527-0847
> >
>
>



References: