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

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



Follow-Ups: References: