[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Latest Re-keying Draft
Hi Mike,
I'm not sure if you would like to see these addressed in the document, so
I'll comment as though you don't, since the original intent of the phase 2
part of the document was really how to transfer traffic from the old to the
new SA. It was not intended to handle SA management as a whole, although it
does touch on some of those issues.
Comments below.
Tim
> -----Original Message-----
> From: Mike Carney [mailto:carney@securecomputing.com]
> Sent: February 8, 2000 10:23 AM
> To: Tim Jenkins
> Cc: ipsec@lists.tislabs.com; carney@jumpsrv.stp.securecomputing.com
> Subject: Re: Latest Re-keying Draft
>
>
> A couple of thing related to rekeying that I must have missed
> elsewhere in
> the drafts/RFC related to rekeying in regards to Kilobyte Lifetimes.
>
> If the phase 2 SA's have unlimited time lifetime and fixed KB
> lifetime,
> it is very easy to run into key proliferation problems where old key's
> never go away.
>
> In order to prevent key proliferation it appears that the
> implementation must:
> 1) Use all keys until they hard expire.
> Reason: Otherwise after a new key pair negotiated because
> the soft lifetime
> was hit and the new key pair is used, the old
> keys never hit their
> hard limit and go away.
In the re-keying document this is covered by the requirement that a re-keyed
SA have its lifetime set to 30 seconds after the new SA is up (unless it
will already expire sooner than that).
> 2) Make sure to use every key pair negotiated
> Reason: Due to QM collisions extra key pairs can be negotiated.
I assume you're talking about a case where you get two pairs of SAs with
traffic lifetimes only.
In this case, if the endpoints behave the same, they will likely end up
using different pairs for transmission. What I means is that if SA pairs A
and B are created, one end will use A for outbound traffic and the other
will use B. This means that one half of the two key pairs gets used. Then,
use your rule three below.
However, if this doesn't happen, it does look like proliferation of the SAs
could be possible, but only if re-keying again happens simultaneously.
Obviously, things like inactivity detection can help mitigate this
situation.
> 3) Expire keys in pairs.
> Reason: Because keys are negotiated in pairs, and traffic
> across a VPN
> can be very asymetrical (witness large FTP's), and
> if 1 and 2 are
> implemented the queue of key pairs can grow very large.
I think this is normal practise anyway. IKE negotiates a pair, so I think
they're normally deleted in pairs. Our implementation does this anyway.
>
> Is there an easier way to avoid key proliferation with KB
> lifetimes without
> adding the implementation complexity detailed above?
>
> Regards,
> Michael Carney
>
>
Tim