[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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:
References: