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

Re: IPSec SA DELETE in "dangling" implementation

  But what if you do always keep up an IKE SA and you just suspend your 
laptop or pull the ethernet cable out and then do a shutdown? Now I've got 
the 2 IPSec SAs and an IKE SA. This problem isn't solvable. And it seems to 
be specific to mobile host implementations with short term SAs. Since IPSec, 
and IKE, are not mobile host-specific I don't think a general purpose rule 
to do this is necessarily needed. And, as you say, no big deal.

  I think a nice generic keep alive function would be more useful to
implement. Why doesn't someone write a draft on this subject?

  Dan.

On Wed, 01 Dec 1999 19:53:19 EST you wrote
> Here the scenario.
> 
> Have some IPSec SAs between my laptop Client and some other site.
> IPSec SAs are alive, but IKE SAs all expired.
> 
> I want to shut down my laptop and as a nice net-citizen I want to send IPSec 
>SA
> DELETEs to the other end.
> If I follow your advice and do not send DELETEs - the other guy will keep the
>se
> stale IPSec SAs for possibly another 8 hours (if he has no inactivity timeout
>, or
> no keep-alive going). No big deal, but not ideal either.
> 
> Dan Harkins wrote:
> 
> > On Wed, 01 Dec 1999 18:45:01 EST you wrote
> > > The question still remains - how to send DELETE notification when deletin
>g IP
> > >Sec
> > > SA while there is no IKE SAs to that peer.
> >
> > No, the question is why do you have to send a DELETE notification when
> > deleting IPSec SAs and you have no IKE SAs to that peer. I don't think you 
>do.
> >
> > > My vote - to re-key IKE SAs as soon as possible after they are expired or
> > > deleted (if there are active IPSec SAs with that peer) - so they will be 
>arou
> > >nd
> > > when I need them, but if for some reason IKE SA cannot be re-keyed - do n
>ot s
> > >end
> > > IPSec SA DELETEs. Also, IMHO - deletion of IKE SA should be just that - n
>o
> > > consequences for any IPSec SAs.
> >
> > I still think that the problem caused by not being able to send a DELETE
> > notification-- namely, a blackhole-- will only happen in edge conditions
> > and even then the problem will be readily noticible because it requires
> > manual intervention and the box on which the manual intervention is done
> > will start filling the event log with messages which should clue in any
> > cluefull operator that that command he just typed is doing something bad.
> > Further manual intervention will rectify the situation; problem solved.
> > In most cases the SAs will naturally be reestablished on their own and no
> > blackhole will happen.
> >
> > Re-establishing an IKE SA for the sole purpose of "so [it] will be around
> > when I need [it]" is not really a reason. It should be established if it
> > really is necessary like having to re-key the IPSec SAs to that peer. And
> > in that case you won't necessarily know that the IPSec SAs will need to
> > be reestablished when the IKE SA dies, you'll only know when the IPSec SAs
> > actually approach expiry. If they do need to be rekeyed an "establish SAs
> > with peer" message will be sent up to IKE who'll notice he has no phase 1
> > SA with that peer and re-establish it then (and then satisfy the request
> > for IPSec SAs). If they don't need to be rekeyed then that is because they'
>re
> > not being used and when they die a quiet death no one will notice.
> >
> > If negotiating an IKE SA simply because one expired and was deleted actuall
>y
> > solves a problem please describe the circumstances to me.
> >
> >   Dan.
> 
>
Follow-Ups: References: