RE: problems with draft-jenkins-ipsec-rekeying-06.txt
Henry Spencer <henry@spsystems.net> Tue, 18 July 2000 04:30 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA17110; Mon, 17 Jul 2000 21:30:22 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA17268 Mon, 17 Jul 2000 23:17:56 -0400 (EDT)
Date: Mon, 17 Jul 2000 23:26:03 -0400
From: Henry Spencer <henry@spsystems.net>
To: andrew.krywaniuk@alcatel.com
cc: hugh@mimosa.com, 'Tim Jenkins' <TJenkins@Catena.com>, 'IPsec List' <ipsec@lists.tislabs.com>, 'Hugh Daniel' <hugh@toad.com>, 'John Gilmore' <gnu@toad.com>
Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt
In-Reply-To: <002101bff062$c1335010$d23e788a@andrewk3.ca.newbridge.com>
Message-ID: <Pine.BSI.3.91.1000717230619.23232C-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Mon, 17 Jul 2000 andrew.krywaniuk@alcatel.com wrote: > And then there is the dictionary entry I posted earlier which shows that the > English word "unique" has more than one meaning. Only one of those seemed applicable... unless you "know what it means" and thus aren't really looking at the dictionary at all. > > The primary criterion for choice when resolving ambiguities should be > > technical merit, not closeness to the original intent. > > I disagree here. The time to weigh technical merit is BEFORE the protocol is > standardized and everyone has implemented it. IKE is only a Proposed Standard at this time. To quote RFC 2026: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. That is, we're still at the stage where technical considerations found by experience can legitimately result in changes. "Internet Standard" is two steps farther along the process. Implementors are supposed to be aware of this. > If it turns out that the protocol is actually lacking in technical merit, > then it is time to change the protocol. But that should be done in a > backwards compatible way that does not break all existing implementations. As we have pointed out -- repeatedly -- our interpretation has demonstrated interoperability with a wide variety of existing implementations. This is not theory, but established fact. > I've often you heard you say (or maybe it was Hugh) that an implementation > should be allowed to ignore notify and delete messages since there is no > guarantee of delivery. Is the implementation required to keep track of of > the message ids from packets it may never receive? It keeps track of the ones it receives, and not the ones it doesn't receive. Can we try to keep this discussion serious? > I also claim that the storage/processing requirements are worse than you > claim. Do you store the message ids in an array/list (in which case search > time is slow) or a hash table (in which case memory consumption is high) or > a tree (bit of both). Given the length of the lists involved -- tiny -- either approach will be totally dominated by fixed overhead anyway, unless you're doing something very strange. Remember that those message IDs come attached to messages, which typically involve the creation of much larger structures and the expenditure of much greater amounts of processing time. As we have pointed out -- repeatedly -- this has been a non-issue in practice in all experience to date. > I also believe that this violates the design principle which mandates that > Alice should not be able to force unbounded state creation on Bob's machine. Your belief is incorrect. As we have pointed out -- repeatedly -- if too much state accumulates, Bob rekeys (that is, replaces) the ISAKMP SA, at which point all saved state related to the old one can be discarded. > (Can you give an example of elsewhere in IPsec where this is true?) If Bob makes no attempt to control resource consumption -- the assumption required for the above belief to be true -- then the creation of ISAKMP and IPsec SAs is far more state-intensive. Henry Spencer henry@spsystems.net
- problems with draft-jenkins-ipsec-rekeying-06.txt D. Hugh Redelmeier
- RE: problems with draft-jenkins-ipsec-rekeying-06… Tim Jenkins
- procedural RE: problems with draft-jenkins-ipsec-… Henry Spencer
- RE: problems with draft-jenkins-ipsec-rekeying-06… D. Hugh Redelmeier
- Re: procedural RE: problems with draft-jenkins-ip… Paul Koning
- RE: problems with draft-jenkins-ipsec-rekeying-06… Andrew Krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… Mason, David
- Re: problems with draft-jenkins-ipsec-rekeying-06… Dan Harkins
- Re: problems with draft-jenkins-ipsec-rekeying-06… Dan Harkins
- RE: problems with draft-jenkins-ipsec-rekeying-06… D. Hugh Redelmeier
- RE: problems with draft-jenkins-ipsec-rekeying-06… Andrew Krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… Henry Spencer
- Re: problems with draft-jenkins-ipsec-rekeying-06… Dan Harkins
- RE: problems with draft-jenkins-ipsec-rekeying-06… andrew.krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… Henry Spencer
- RE: problems with draft-jenkins-ipsec-rekeying-06… Paul Koning
- RE: problems with draft-jenkins-ipsec-rekeying-06… Andrew Krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… andrew.krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… Paul Koning
- RE: problems with draft-jenkins-ipsec-rekeying-06… D. Hugh Redelmeier
- RE: problems with draft-jenkins-ipsec-rekeying-06… Andrew Krywaniuk