[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dangling SA Summary
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.
Follow-Ups:
References: