RE: Phase 1 Re-keying Implementation Identification
Andrew Krywaniuk <akrywaniuk@TimeStep.com> Thu, 18 November 1999 02:17 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA24660; Wed, 17 Nov 1999 18:17:36 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01279 Wed, 17 Nov 1999 19:46:41 -0500 (EST)
Message-Id: <319A1C5F94C8D11192DE00805FBBADDFF7B2D8@exchange>
From: Andrew Krywaniuk <akrywaniuk@TimeStep.com>
To: ipsec@lists.tislabs.com
Subject: RE: Phase 1 Re-keying Implementation Identification
Date: Wed, 17 Nov 1999 19:52:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I don't think this is really a security issue. If the certificate expires, it doesn't stop the user from being who they were when they negotiated the phase 2s (there's no retroactive MitM attack). The SAs will go away by themselves if the deletes are not sent (and we can't currently guarantee that they get there anyway). Although, the deletes are nice from a recovery perspective (and they are user-friendly). This is more of an issue from a speed/latency vs. memory usage perspective. Some of us would like to have the advantage of being able to send Isakmp packets at any time during the phase 2 lifetime without having to negotiate a new phase 1 (especially if this requires user intervention). And ifo ur products are memory hogs because of this strategy then so be it. There are many reasons for wanting a continuous channel besides for sending deletes: premature phase 2 rekeys (e.g. due to kb lifetime expiry), negotiating different phase 2 SAs with the same endpoints (for whatever conceivable reason), heartbeat/keep-alive protocols, legacy authentication protocols (e.g. periodic reauthentication), configuration protocols (e.g. private address renewal), the ability to carry information across a phase 1 rekey, lifetime notifies or other informational messages, other protocols that we haven't even imagined yet. If you don't want to support continuous channel mode, you don't have to. However, we find it useful. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable.
- Phase 1 Re-keying Implementation Identification Tim Jenkins
- RE: Phase 1 Re-keying Implementation Identificati… Tim Jenkins
- Re: Phase 1 Re-keying Implementation Identificati… Slava Kavsan
- Re: Phase 1 Re-keying Implementation Identificati… Will Price
- RE: Phase 1 Re-keying Implementation Identificati… Tim Jenkins
- Re: Phase 1 Re-keying Implementation Identificati… Ben McCann
- RE: Phase 1 Re-keying Implementation Identificati… Tim Jenkins
- Re: Phase 1 Re-keying Implementation Identificati… Slava Kavsan
- RE: Phase 1 Re-keying Implementation Identificati… Tero Kivinen
- Re: Phase 1 Re-keying Implementation Identificati… Scott G. Kelly
- RE: Phase 1 Re-keying Implementation Identificati… Tim Jenkins
- Re: Phase 1 Re-keying Implementation Identificati… Mike Carney
- RE: Phase 1 Re-keying Implementation Identificati… Saint-Hilaire, Ylian
- Re: Phase 1 Re-keying Implementation Identificati… Paul Koning
- Re: Phase 1 Re-keying Implementation Identificati… Mike Carney
- Re: Phase 1 Re-keying Implementation Identificati… Scott G. Kelly
- RE: Phase 1 Re-keying Implementation Identificati… Andrew Krywaniuk
- RE: Phase 1 Re-keying Implementation Identificati… Tero Kivinen
- Re: Phase 1 Re-keying Implementation Identificati… Michael Richardson
- Re: Phase 1 Re-keying Implementation Identificati… Dan Harkins
- RE: Phase 1 Re-keying Implementation Identificati… Tim Jenkins
- RE: Phase 1 Re-keying Implementation Identificati… Tim Jenkins
- Re: Phase 1 Re-keying Implementation Identificati… Scott G. Kelly
- RE: Phase 1 Re-keying Implementation Identificati… Andrew Krywaniuk
- RE: Phase 1 Re-keying Implementation Identificati… Paul Koning
- Re: Phase 1 Re-keying Implementation Identificati… Dan Harkins
- RE: Phase 1 Re-keying Implementation Identificati… Tero Kivinen
- RE: Phase 1 Re-keying Implementation Identificati… Scott Fanning
- RE: Phase 1 Re-keying Implementation Identificati… Andrew Krywaniuk
- RE: Phase 1 Re-keying Implementation Identificati… Paul Hoffman
- Re: Phase 1 Re-keying Implementation Identificati… Ben McCann
- Re: Phase 1 Re-keying Implementation Identificati… Ben McCann
- RE: Phase 1 Re-keying Implementation Identificati… Tim Jenkins
- RE: Phase 1 Re-keying Implementation Identificati… Tim Jenkins
- RE: Phase 1 Re-keying Implementation Identificati… Paul Koning
- Re: Phase 1 Re-keying Implementation Identificati… tytso
- Re: Phase 1 Re-keying Implementation Identificati… Tero Kivinen
- RE: Phase 1 Re-keying Implementation Identificati… Andrew Krywaniuk
- Re: Phase 1 Re-keying Implementation Identificati… Valery Smyslov
- Re: Phase 1 Re-keying Implementation Identificati… Paul Koning
- Re: Phase 1 Re-keying Implementation Identificati… tytso
- Re: Phase 1 Re-keying Implementation Identificati… Ben McCann
- Re: Phase 1 Re-keying Implementation Identificati… Tero Kivinen
- Re: Phase 1 Re-keying Implementation Identificati… Dan Harkins
- Re: Phase 1 Re-keying Implementation Identificati… Tero Kivinen
- Fixing IKE Phase 1 Authentication HASH Valery Smyslov
- Fixing IKE Phase 1 Authentication HASH Tero Kivinen
- Re: Fixing IKE Phase 1 Authentication HASH Valery Smyslov