[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Phase 1 Re-keying Implementation Identification
On Thu, 18 Nov 1999 09:05:52 EST you wrote
> > 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.
>
> What are you talking about? Where does it say that?
>
> Once the phase 2 SAs are up, they get re-keyed independently
> of phase 1. The only that might change is which phase 1 SA was
> used to protect the quick mode.
OK, that was my mistake. That text was under "Initial Phase 1 Negotiation"
from a previous page.
> That was badly phrased. It should have said:
>
> In other words, SAs that are no longer necessary may continue
> to be re-keyed indefinitely.
>
> But I think you knew that.
But that text isn't any better. Re-keying an SA indefinitely is definitely
a problem. This is an example of how a non-continuous channel mode
implementation will have to change because of the existance of continuous
channel mode implementations.
Basically, if someone initiates IKE with me I think he does so for a reason.
This being IPSec the reason is that he wants to negotiate IPSec SAs. If you
just negotiate an IKE SA and do nothing or negotiate IPSec SAs that are not
used that is a problem for me. I will now have to take into account the
possibility that someone will unnecessarily negotiate with me ad nauseum.
If the possibility of talking to you is that you will never shut up then I
will have to decide whether I ever want to talk to you. That is a problem
from an interoperability point of view.
> Further, it doesn't case this problem. This problem could exist
> with any phase 1 re-keying model except for the one you seemed
> to think that it proposed when you thought it said that the
> phase 2 SAs should go away.
No. This problem doesn't exist in my rekeying model. There are plenty of
fielded implementations that do not follow your document but don't have
the problems you describe nor do they suffer from the problems which arise
if they did follow your document. There are lots of people that are very
happy with the rekeying done by our product. No loss of packets for tunnels
which are long-term (up always, continuously rekeyed, both the IPSec SAs and,
independently, the IKE SAs) nor for tunnels which are short-term (on demand,
when the demand stops the tunnel goes away and we don't continue to negotiate
things that will not be used).
So the issue now is what do I have to do to make sure that things will
continue to work the same way if a continuous channel mode implementation
is on the other end?
> > > 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.
>
> So, you're saying that a phase 1 SA should be used to protect
> key exchanges only. So, we should outlaw the New Group exchange
> and no other exchanges?
I'm saying nothing as hyperbolic as that. What I'm saying is that when you
ascribe certain characteristics to an IKE SA that it was not designed to
have then you have problems. If you stopped ascribing those characteristics
to the IKE SA then the problems would go away. If you want to continue to
ascribe characteristics for future, as yet unknown, protocols then you'll
continue to have problems. And several of these wheels you're inventing have
been invented before (e.g. DHCP) so welding them onto IKE might not
necessarily be the wisest thing to do. Since this seems to be the genesis
of rekeying problems I think it absolutely is not the wisest thing to do.
> > 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.
>
> I don't agree with this. If this was correct, it would mean
> the continuous channel model violates the protocol. Can you
> point out where it violates the protocol?
It doesn't violate the protocol but it requires internal bookeeping that
forces the protocol to behave in a way that it naturally does not behave
and implementations that do not behave that way will have to take such
behavior into account.
Just because something does not violate a protocol does not mean that
it is not pathologic.
> The resources argument is valid, but that means it's related to
> implementation and application.
Yes it is. And the issue is does my implementation have to change because
of the way you're behaving. It looks like the answer is yes and that's a
problem. Some very legitimate behavior that I may want to do-- clean up
unneeded IKE SAs for instance-- can result in temporary blackholes and,
more egregiously, exacerbate the situation that caused my behavior! In
other words, I'm trying to conserve resources and every attempt I make to
conserve resources causes you to make me chew up more resources.
Dan.
Follow-Ups:
References: