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

RE: Dangling SA Summary



Yes, and no.

If an implementation that itself does not allow dangling phase 2 SAs is
connected with an implementation that does allows allow it, if the phase 1
on the latter expires first, and it sends a delete, the former would end up
deleting all SAs so there would be a black out.

However, if the former implementation allowed that it could be talking to an
implementation that allowed dangling SAs, it would use only the delete that
it received and not delete the phase 2 SAs.

The bottom line is that since dangling phase 2 SAs is allowed, all
implementation must be able to support it.


---
Tim Jenkins                       TimeStep Corporation
tjenkins@timestep.com          http://www.timestep.com
(613) 599-3610 x4304               Fax: (613) 599-3617



> -----Original Message-----
> From: bkavsan [mailto:bkavsan@ire-ma.com]
> Sent: June 18, 1999 10:15 PM
> To: Dan Harkins
> Cc: Tim Jenkins; ipsec@lists.tislabs.com
> Subject: Re: Dangling SA Summary
> 
> 
> is there a problem in allowing co-existence of both dangling 
> and non-dangling
> implementations?
> 
> Dan Harkins wrote:
> 
> > On Fri, 18 Jun 1999 14:04:19 EDT you wrote
> > >
> > > > This is large club used to kill a small ant. The window only
> > > > happens when
> > > > you 1) are using certs; and, 2) have a case where the
> > > > certificate expires
> > > > while IPSec SAs exist. The CRL example is not convincing
> > > > because there is
> > > > no way to notice the second a cert has been revoked unless
> > > > you spend 100%
> > > > of your time doing LDAP queries for active sessions. That's
> > > > not realistic..
> > >
> > > I know. That's what my assumptions were in the first place.
> > >
> > > > ... and as Brian Korver noted yesterday this window 
> approximates roundoff
> > > > error for all the other windows.
> > >
> > > And as I replied to Brian the round off effect is only 
> small if the phase 2
> > > SA lifetime is small compared to the phase 1 SA lifetime. 
> Did you see my
> > > summary page?
> >
> > No it's small due to the other things that are not easy to 
> quantify like
> > how long does it take someone to realize their private key has been
> > compromized? That's probably going to be big compared to 
> the time an SA
> > can dangle.
> >
> > > Let's turn this around. What are your objections to *not* 
> allowing dangling
> > > phase 2 SAs?
> >
> > Because not everyone feels that dangling SAs are a problem. 
> Because your
> > concern about making this window as small as possible can 
> be taken care of
> > in ways that only impact your implementation and not 
> everyone else's. Because
> > I don't want to have to do unnecessary and expensive public 
> key operations
> > which would arise if the IPSec SAs would not be rekeyed 
> when they expire but
> > the IKE SA which established them has timed out. Because it 
> causes temporary
> > blackouts. Because this problem happens very, very, very 
> infrequently and to
> > burden everyone to do something when 99.99% (or more) of 
> the time the
> > "problem" isn't even there and when it is alot of people 
> don't view it as a
> > problem is alot to require. It's an unnecessary burden. 
> This protocol is
> > already too complicated.
> >
> >   Dan.
> 
> 
> 
> 

Unrecognized Data: application/ms-tnef