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

Re: Latest Re-keying Draft

To: Tim Jenkins <tjenkins@TimeStep.com>
Subject: Re: Latest Re-keying Draft
From: Mike Carney <carney@securecomputing.com>
Date: Tue, 08 Feb 2000 09:22:32 -0600
cc: ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com
In-reply-to: Your message of "Tue, 08 Feb 2000 09:19:53 EST." <319A1C5F94C8D11192DE00805FBBADDF01171CF5@exchange>
Sender: owner-ipsec@lists.tislabs.com

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.
2) Make sure to use every key pair negotiated
   Reason:  Due to QM collisions extra key pairs can be negotiated.
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.

Is there an easier way to avoid key proliferation with KB lifetimes without
adding the implementation complexity detailed above?

Regards,
Michael Carney

References:

Latest Re-keying Draft

From: Tim Jenkins <tjenkins@TimeStep.com>

Prev by Date: Re: Proposal for new DH Groups 6, 7, and 8
Next by Date: RE: Latest Re-keying Draft
Prev by thread: Latest Re-keying Draft
Next by thread: RE: Latest Re-keying Draft
Index(es):
- Main
- Thread