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

RE: Dangling SA Summary (final comments???)



To all:

I'm going preface this response with the comment that I realize that I've
lost this battle to not allow dangling SAs.

However, I want to make sure that as we move forward from this we understand
where we came from.

Also, obviously, I'm going to have to update the re-keying document to
reflect the fact that systems are free to have dangling phase 2 SAs.
However, I must insist that implementations are also free to have multiple
phase 1 SAs with peers so that they can choose not to have dangling phase 2
SAs.


> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM]
> Sent: June 18, 1999 8:39 PM
> To: Tim Jenkins
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Dangling SA Summary 
> 
> 
> On Fri, 18 Jun 1999 14:04:19 EDT you wrote
> > 
...
> > Let's turn this around. What are your objections to *not* 
> allowing dangling
> > phase 2 SAs?
> 
> Because not everyone feels that dangling SAs are a problem. 
> Because your 
> concern about making this window as small as possible can be 
> taken care of 
> in ways that only impact your implementation and not everyone 
> else's.

Okay, point taken.

> else's. Because 
> I don't want to have to do unnecessary and expensive public 
> key operations 
> which would arise if the IPSec SAs would not be rekeyed when 
> they expire but 
> the IKE SA which established them has timed out. ...

So you aren't going to send a delete? Either in the existing optional
unreliable notification or the new required (?) acknowledged notification?

It seems to me that you will be trying to negotiate a new phase 1 anyway, no
matter what happens.

Say you get a dangling phase 2 SA. The things can happen to it are:

1) It needs to be re-keyed.
2) It needs to be deleted due to expiration.
3) It needs to be deleted due to inactivity (if implemented; this is an
implementation option).
4) It needs to be deleted because the local administrator said so.
5) It needs to be deleted due to authentication failure (system somehow
knows that peer can no longer have access).

In case 1, you have to re-key the phase 1. In cases 2, 3, 4 and 5 you SHOULD
(I would like to see MUST) send deletes. So in every case, the phase 1 SA
has use. Only in case 5 (and maybe case 4), you can't re-key the phase 1, so
you can't send the deletes.

The only time you waste public key operations is if you create a phase 1 SA
that doesn't get used. This implies that (a) the phase 2 lifetime is longer
than the phase 1 lifetime, AND (b) there is no inactivity expiration applied
to the SAs.

I keep being told that (a) is not likely, or otherwise the revocation
detection time difference between dangling SAs and no dangling SAs would not
be like a round-up error.

So then the only waste is perhaps over a year you've created more phase 1
SAs than you needed.

> the IKE SA which established them has timed out. Because it 
> causes temporary 
> blackouts...

Yes, agreed.

> blackouts. Because this problem happens very, very, very 
> infrequently and to 
> burden everyone to do something when 99.99% (or more) of the time the 
> "problem" isn't even there and when it is alot of people 
> don't view it as a 
> problem is alot to require.

Point taken here as well.

> ... It's an unnecessary burden.

A burden? Unnecessary? Okay. Almost anything can be made to work, even
badly.

Whether we like it or not, the phase 1 SAs are the "control channel" for the
phase 2 SAs. They create them and destroy them. By not having them around
when they are needed, for whatever reason, we make the system operate less
smoothly.

Here's another example of a need for them.

A and B have a phase 1 and a phase 2 SA up. A's phase 1 SA expires, so A
sends a delete notification that gets dropped (or doesn't send it at all).
Then B's phase 2 expires or is terminated due to inactivity. B thinks there
still a valid phase 1 SA, so sends a delete using it. A gets it and discards
it with an invalid cookie error. Yes, we can recover from this, and yes,
eventually maybe we'll be using the acknowledged deletes, so that B knows
the SA is gone.

Further, I would argue that it's not a large implementation burden. Since
the possibility exists that either end will have to re-key a phase 1 that
was previously deleted, the work required is similar whether an existing
phase 1 is in place or not.

We still need to support multiple phase 1 SAs between peers anyway.

> ... This 
> protocol is
> already too complicated.

One thing that makes it complicated is the lack of written rules for the
usage of SAs. There is a problem with a protocol when independent
implementations can not break any rules, work with themselves yet not work
with other implementations.

This happened with phase 2 re-keying; we need to make sure this doesn't
happen with phase 1 re-keying.

I would also state that some of the complexity comes from having to handle
all the myriad possibilities of SA handling. So making restrictions may
actually reduce complexity, and not increase it.

> 
>   Dan.
> 
> 

In any case, as I said above, I realize that dangling SAs must be supported.
Choose your method...

Tim

Unrecognized Data: application/ms-tnef


Follow-Ups: