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

Re: IPSec SA DELETE in "dangling" implementation



Apart from resource management concerns I do not see any drawbacks for re-keying
IKE SA immediately after it is expired or deleted (assuming that there are active
IPSec SA existed under old IKE SA).

But, I think, this scheme schould not me mandated by the standards - it should be
left to individual implementations or policies.
The benefits of such logic will be ability to send protected Informational
Exchanges at ALL times, including protected keep-alives and DELETEs.

Srinivasa Rao Addepalli wrote:

> Jan Vilhuber wrote:
>
> > 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
>
> Yes. I agree with you and make it MUST to remove any ambiguities.
>
> Regards
> Srini
>
> >
> >
> > 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: