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