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

RE: Phase 1 Re-keying Implementation Identification



It seems to me that one of the reasons we're having problems
here is that we're all trying to define SA management (both
phase 1 and phase 2) to cover all possible applications.

Since we have, in general, different products, we're going
to have different perspectives. It may be that there is
no single method that covers all the possible uses of IKE
as a key exchange protocol, or all possible uses of the
resulting phase 1 SAs.

Perhaps this is what Michael Richardson was trying to say?

In any case, I'd like to continue the discussion below,
just a bit more(?).

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



> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@network-alchemy.com]
> Sent: November 18, 1999 3:14 PM
> To: Tim Jenkins
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Phase 1 Re-keying Implementation Identification 
> 
> 
> On Thu, 18 Nov 1999 09:05:52 EST you wrote

...

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

Indefinite re-keying of phase 2 SAs might occur independent of how
you model your phase 1 re-keying. In other words, the triggers
that require the existence of a specific phase 2 SA (based on
selectors). (See more on this below...)

However, you are right that the continuous channel model will
cause indefinite re-keying of phase 1 SAs. But that's what it's
designed to do: to provide continuously available service if
needed.

It doesn't dis-allow a mechanism to shut everything down between
two peers.

> 
> 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 an IPsec SA is not needed, it can be deleted, by either end.
What I'm suggesting does not mean I will arbitrarily bring phase
2 SAs back up; this continuous channel model applies only to
phase 1 SAs, and only applies to provide a control channel for
any phase 2 SAs that exist.

There seem to be two parts of the proposal that fit your
concerns.

The first part of the continuous channel model that seems to
relate to your concern here is this line from table 1.

        -phase 1 SA deletion   -re-key phase 1 SA (1)

If the action to re-key the phase 1 SA when there is only one
and it is deleted by the peer is removed, then this would
effectively cause a continuous channel model to revert to
a dangling model.

The second is the automatic re-keying of phase 1 SAs. You
seem to object to this under the assumption that the new SA
that is created will never get used.

First, it is assumed that phase 1 SAs lifetimes are longer
than phase 2 SA lifetimes. This assumption was, I believe,
the reason the authorization lifetime argument was decided
to have no significance in determining phase 1 re-keying.
(The argument went that the potential time that the phase
2 SAs could live beyond the authenticated lifetime was
small.)

So, if phase 2 SA lifetimes are smaller than phase 1 SA
lifetimes, then the new phase 1 SA will definitely be
used to re-key the phase 2 SAs. If for some reason the
phase 2 SA is not to be re-keyed, and deleted either
before the end of its lifetime or when it expires, then
the new phase 1 SA is used to send the delete notification
to the peer.

Now, your memory resource issue is valid: Why keep the
phase 1 SA in memory when it may not be needed until
the phase 2 SA needs re-keying or deletion?

If the re-keying line from the table above is removed,
then that could solve the problem. The endpoint that is
running out of resources can delete the phase 1 SA.
Hopefully, it can be re-generated later when it is really
needed.

Would that reduce your concerns about interoperating with
a continuous channel implementation (in the general case;
not the application specific case)?


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

Again, these models don't preclude some sort of over-all
management.

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

Once again, if we're talking about phase 2 SA re-keying, if
you limit yourself to talking with a like implementation,
you might be right. Remember that the phase 2 re-keying
suggestions made are an attempt to cover as many of the
different interpretations out there, and to provide lossless
re-keying of phase 2 SAs under as many different circumstances
as possible.

Since I don't know exactly how your implementation re-keys,
I can't do an analysis of it to suggest where you might have
problems in circumstances that your customers haven't yet
encountered.

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

Again, would removing that one line from the state table help?

> 
...

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

Sorry, I don't understand what characteristics we're ascribing
to an IKE SA that it doesn't have. Doesn't it have the ability
to protect exchanges using packet formats as defined in RFC2408?

Maybe we're running into application specific concepts
here. And it's related to how we want to manage the SAs.


> 

...

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

Again, would the change I'm suggesting remove your concern
about being able to control your SAs in a manner you want?

I'll repeat this: my proposal does not preclude the use
of idle timeouts, or anything like that. In fact, it
suggests that they should be used. Or is that the concern?
That they become necessary?

But if they aren't, how do you losslessly re-key? Do you
drop phase 2 SAs when they expire and wait until traffic
starts up again to re-generate new ones? What if there's
no let up traffic? How do you do this without packet loss?
Or do you really lose a packet here and there, and no one
seems to notice?

In other words, I don't see how you can losslessly re-key
phase 2 SAs without doing it automatically.

This then leads to needed some kind of idle
time-out detection to automatically delete the unused
phase 2 SAs. And all of this is independent of phase 1
re-keying.

> 
>   Dan.
> 

Tim