[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dangling phase 2 SAs (was RE: issues from the bakeoff)
On Fri, 18 Jun 1999 13:36:46 EDT you wrote
>
> > What if his certificate gets revoked 2 hours into the phase 1
> > lifetime?
> > How do you know? Do you constantly recheck CRLs? How often? What if it
> > expires in between checks? I don't see how your concern is
> > addressed by
> > deleting the IPSec SAs when the IKE SA expires.
>
> The concern is shortening the window of checking. If we assume that the only
> checking of certificates is done is when phase 1 is negotiated, then if
> dangling SAs are allowed, the next check of the certificate will not occur
> until a new phase 1 is generated, which could be as late as just before the
> phase 2 SA is going expire.
>
> >
> > And if this is your concern why not limit this 2nd
> > negotiation to 10 min
> > then and guarantee that the client will not think his IPSec SAs are
> > valid for longer than what you think they are. That would
> > prompt him to...
>
> I don't understand what you're saying here.
What I'm saying is that you're concerned about IPSec SAs being used beyond
the validity period of a certificate used to authenticate the IKE SA. So
when you authenticate with a certificate, note its validity period and
use it to constrain IPSec negotiation. If someone sends you an offer for
a lifetime that is greater than (cert-expiry-time - current-time) or if
they offer no lifetime or a volume-based lifetim then use the RESPONDER-
LIFETIME notify to tell the peer that these SAs are only good for
(cert-expiry-time - current-time) seconds.
> Just because one end limits his
> lifetime to 10 min. doesn't mean the peer will use that lifetime.
If it's pathological it won't but pathological implementations can do all
sorts of things we don't want so let's not get hung up on them here. The
point here is that you're telling the peer what the lifetime is and not
having that be some hidden limit he doesn't know about (you're going to
delete the SA is X seconds but he thinks it's good for X+Y seconds or Z
kilobytes). It will allow him to know when he should delete his SAs and
when he should initiate a re-key. If at that point he doesn't have a
valid cert then don't talk to him.
> What I'm proposing is that when this happens, a phase 1 SA MUST be re-keyed
> such that there is always a valid phase 1 SA underneath. In other words,
> implementations must support overlapping phase 1 SAs. Is that currently
> prohibited? I don't see how it can be, since you don't know you've got
> overlapping phase 1 SAs until they're (almost) completely negotiated anyway
> (yes, it does depend on the mode).
Why should I be required to negotiate an IKE SA simply because a pair of
IPSec SAs exist? Maybe the IPSec SAs are not being used at the time the IKE
SA times out and would not be rekeyed. By imposing this requirement on all
you're making people do expensive public key operations for potentially no
reason. (Where are all those people who don't want to do group 5 when
configured for group 2? How'd you like to do group 2 plus a digital sign
and verify for no reason?).
This would be a bizarre requirement. It basically means that if at anytime
I did an IKE and IPSec exchange with you then I have to keep doing them with
you. "No! Stop! Enough! I don't want to talk to you anymore! Go away!"
> If I understand what you're recommending here, how do you provide a
> continuous "tunnel" of SAs even through phase 1 expirations?
There are some simple rules to follow. One is, don't rekey IPSec SAs if
they're not "being used." "Being used" is open to interpretation but
basically, if it and its pair haven't been used to protect a packet in
some time (N units of something) then let it die a quiet death. When
re-keying IPSec SAs begin the exchange "enough time" before the SAs expire.
"Enough time" is likewise open to interpretation. If you're a 20MHz 680x0
then you should probably give yourself more leeway then if you're a
500 MHz Pentium. When you re-key IPSec SAs do not throw away the old SAs.
Artificially age them if necessary (giving them a lifetime of the minimum of
their current life and "enough time" is a good way to do this). Begin to
use the new IPSec SAs when established but allow traffic in on the old ones.
Also, let IKE SAs just go away. If they're needed in the future they'll be
established.
When you do this the IKE SA dies and the IPSec SAs live on. If they're
"being used" then a new request for SAs will be made "enough time" in
advance of the IPSec SAs expiring. IKE will notice that it has no SA with
the peer and do another exchange. The IPSec SAs will be stuffed in the SADB
before the old ones expire (because it had "enough time") and will be used
to protect traffic. The old SAs will just go away. The whole thing repeats.
That's rekeying in a nutshell.
But if this window of "unauthenticated" IPSec SAs is a problem, one can add
another rule. When an request for IPSec SAs comes up and an IKE SA exists to
the peer in the request then use it unless the lifetime of that SA is "low",
where "low" is like everything else here open to interpretation and dependant
on the implementation and hardward etc. If it's "low" then don't use it,
begin another phase 1 exchange and use that to satisfy the request for IPSec
SAs. The other IKE SA will die a normal death. If the other peer does a QM
for you and the IKE SA is "low" then do a phase 1 exchange with him to get
another IKE SA. But this extra level of complexity is only necessary if
you're concerned about the case of a certificate that was used to
authenticate a peer who currently has an active IPSec session was revoked.
You're free to add this level of complexity to your code if you feel it's a
problem.
> Are you suggesting allowing multiple phase 1 SA with their own set of phase
> 2 SAs that live only within the phase 1 SA, but set up such that the phase 1
> SAs overlap and the phase 2 SAs from the different phase 1 SAs have the same
> selectors????
Yeech! No that's not what I'm suggesting. What I'm suggesting is just some
simple things to do that makes rekeying a non-issue and to point out that
dangling SAs are not a problem. It's really not that complicated.
Dan.
References: