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

Re: IPSec SA DELETE in "dangling" implementation

On Thu, 2 Dec 1999, Bronislav Kavsan wrote:

> You missed to read very first words in my mail  - "Apart from resource management
> concerns.....".
> 
Well, yes, but resource concerns are driving at least part of this
discussion. They are a large concern. If we agree that there may be resource
concerns, then what's the point of the rest of your email? It's not like you
(the peer) can distinguish whether I deleted my SA because I felt like it, or
because or resource concerns. All YOU see is that I deleted it. So why do you
feel the need to continue and state that you want the option to rekey
immediately ANYWAY? You can't tell, so don't do it.

jan



> Jan Vilhuber wrote:
> 
> > On Thu, 2 Dec 1999, Bronislav Kavsan wrote:
> > > 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.
> >
> > Yes and no. As Tero pointed out (or was it Dan? I forget) if someone deleted
> > their IKE SA for resource-recovery reasons (short of memory.. whatever)
> > you're REALLY not doing them a favor by rekeying immediately.
> >
> > One might almost argue that we should add verbiage to the rfc that says
> > something like "MUST not rekey unless the SA is really needed" (for some
> > definition of 'really needed').
> >
> > jan
> >
> > > 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
> > >
> > >
> > >
> >
> >  --
> > Jan Vilhuber                                            vilhuber@cisco.com
> > Cisco Systems, San Jose                                     (408) 527-0847
> 
> 
> 

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847
Follow-Ups: References: