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

RE: Phase 1 Re-keying Implementation Identification

I would look for more examples of the use of continuous
channel model if I wanted to debate it. But I've already
conceded that dangling SAs is not only allowed, but has
to be assumed as the default behaviour. (I've tried again
below, anyway.)

And, as I keep saying, it you don't think it's
important, don't do a continuous channel implementation.
You won't be affected by a continuous channel
implementation because it has to be aware that the peer
may not be.

The reality is, no matter what architectural view you
choose, the phase 1 SAs are the control channel
for the management of the phase 2 SAs. By allowing dangling
phase 2 SAs, you allow for the possibility that the
control channel cannot be used to manage the SAs.

I've tried to illustrate a couple places where this may be
important. And for the umpteenth time, if it's not important
to you, don't worry about it.

The point is that it is useful whenever premature termination
of communications occurs when the phase 1 SAs cannot be
re-created. These conditions occur potentially under the
following conditions (and likely others)
1) A time-based policy that restricts user access to specific
hours of the day.
2) A user's permission are totally revoked.
3) A token card-based user removes the token card from the
system.
4) Some other policy or configuration change.
5) Others that no-one has thought of yet...

Also, if you were the initial responder, and your phase 2 SA
lifetimes are shorter, how do you re-key the phase 2 SAs?
Do you keep enough information about the initiator that you
can initiate back for both phase 1 and phase 2? Or do you
drop the SAs, and the other end figure it out? How did you
send the deletes for them? This case is not uncommon, and
is potentially more normal, since the gate side in a remote
access application would need to defend against dial-up users
using excessively long expiration times. Is it okay to drop
traffic while this situation clears itself up? Perhaps, but
it's easily preventable.

The fact that one of the cases is potentially rare is of
little relevance to me when the additional complexity to
make the whole thing cleaner is so little. It's not like
20% increase in complexity is to gain 1% in usefulness.

And, yet again, if you don't care, don't worry about it, you
won't be affected.

---
Tim Jenkins                       TimeStep Corporation
tjenkins@timestep.com          http://www.timestep.com
(613) 599-3610 x4304               Fax: (613) 599-3617



> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@ssh.fi]
> Sent: November 16, 1999 7:53 PM
> To: Tim Jenkins
> Cc: wprice@cyphers.net; ipsec@lists.tislabs.com
> Subject: RE: Phase 1 Re-keying Implementation Identification
> 
> 
> Tim Jenkins writes:
> > Perhaps not as much. But it doesn't change the fact that 
> there can be
> > distinct advantages in keeping the channel available at all times. 
> 
> Is there? Lets put it this way, the
> draft-jenkins-ipsec-rekeying-02.txt doesn't list any of real
> advantages in keeping the channel available at all times. At least I
> couldn't find them. Only thing I found there was some very special
> case where somebody's credentials are revoked and the phase 2 
> SA cannot
> be deleted because there is no phase 1 SA there.


> 
> In that case I would say "so what". The server will just delete the
> Phase 2 SA which should be deleted because that connection is no
> longer allowed by policy, and if the client continues to send packets
> to it it doesn't matter. Removing somebody's permission to use gateway
> doesn't happen that often, and usually there is good reason that, so
> there is really no need to have very clear error message for that
> (black hole approach is completely valid there). Anyways the user will
> get an error message when he tries to rekey to the server when he
> notices that the gateway doesn't respond at all anymore.
> 
> There are some very good reasons for dangling SAs, because you might
> want to do resource limitations for phase 1 SAs. For example we will
> delete phase 1 SAs if there is too many of those. Phase 1 SAs are just
> needed in the rekeying, we do not need to have one phase 1 SA for each
> phase 2 SA, just in case. We usually need to maximize the number of
> phase 2 SAs we can handle, so we might want to delete phase 1 SAs to
> get more resources for phase 2 SAs.
> 
> I don't relly see any point having phase 1 SA up there for 8 hours,
> just to be able to send again few hundred bytes of traffic for
> rekeying, and then again sitting idle for next 8 hours. If I have cpu
> power to do the DH (quite often we have), I would rather recreate the
> phase 1 SAs every time they are needed.
> 
> So the real question is: Could you please summarize the advantages of
> continuous channel mode? 
> 
> In most cases it seems to be used only in very special cases, where
> you have something completely broken anyways. I think it is not
> usefull to try to optimize the system for those cases happening 0.01%
> of time, but for those happening 99.99% of time. (BTW, I think my
> numbers are way too big, I think it should be something like 0.000001%
> instead of 0.01%)
> 
> > 1) Are other interested in recognizing that the peer is 
> contuous channel?
> > If the answer to 1 is yes, then:
> 
> I am not interested implementing special code for very special cases
> which usually means undebuggable bugs, because those cases are so
> special.
> -- 
> kivinen@iki.fi                               Work : +358-9-4354 3218
> SSH Communications Security                  http://www.ssh.fi/
> SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
>
Follow-Ups: