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

Re: Phase 1 Re-keying Implementation Identification

On Wed, 17 Nov 1999 19:52:09 EST you wrote
> 
> 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.

No it's not just speed/latency vs. memory usage it's complexity, and from
the perspective of quite a few people it's unnecessary complex. 

This document does not prevent packet loss-- one of its stated goals-- 
because it requires the responder to delete all phase 2 SAs created with 
the "old" phase 1 SA upon a phase 1 "rekey". That means that packets will
be dropped while a Quick Mode is done on the new IKE SA.

It also causes more problems that it does not attempt to solve. The 
description of the "Continuous Channel Implementations" says:

  "Note that this automatic re-keying of phase 1 SAs means that SAs
   could live independent of traffic, since re-keying of both phase 1
   and phase 2 SAs takes place with no traffic triggers (if they expire
   by time). In other words, SAs that are no longer necessary may never
   disappear.

   This suggests that a traffic monitoring capability should be part of
   implementations that need to delete idle or unused SAs. As such, it
   is not given further consideration, since it is beyond the scope of
   this document."

SAs that never disappear?! 

> 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.

IKE is a session establishment and key exchange protocol, it is not a 
catch-all transport for "other protocols that we haven't even imagined yet."
This may be part of the problem: you have a hammer and now everything looks
like a nail.

> If you don't want to support continuous channel mode, you don't have to.
> However, we find it useful.

The issue is whether those of us who do not want to implement "continuous
channel mode" will have to take certain precautions for those of you who do.
If a side effect of doing "continuous channel mode" is that you will 
continue to re-key an SA which should be deleted, and unnecessarily use up
resources on my box, then I'm going to have to take that into account and 
take some different behavior when I notice the vendor ID payload (or 
whatever mechanism you decide to use) indicating a "continuous channel mode" 
implementation. 

Also, Kivinen noted a good reason why one might want to do "dangling SA
mode": resource concerns. What would you, as a "continuous channel mode"
implementation do in this case? He would delete the IKE SA as it is not
necessary to keep around. You would then delete your phase 2 SAs, causing
a temporary blackhole, and re-negotiate. Then, some time later, he would
again delete the IKE SA and the whole blackhole would repeat. This would not
happen if you did the "dangling SA mode".

It seems to me that you can't just say "if you don't want to do it you don't
have to". Everybody will have to implement some portion of this Rube Goldberg
machine just to remain interoperable.

  Dan.
References: