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

RE: problems with draft-jenkins-ipsec-rekeying-06.txt



> > Internet drafts are written in a mix of English and jargon;
> sometimes the
> > two languages overlap and it confuses people.
>
> I don't actually think that's an issue here...

I think it is. There is a mathematical/logical definition of "unique" which
goes something like:

a is unique in Z if for all b in (Z exclude a) a is not equal to b.

And then there is the dictionary entry I posted earlier which shows that the
English word "unique" has more than one meaning.


> The problem with standards which rely on "well, everybody
> knows that where
> it says WX_Z it really means WXQZ" is precisely that not
> everybody *does*
> know.

I only said that most of us knew.


> 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. Ambiguities should be resolved
according to the intent of the clause and the way most people interpreted
it.

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.


> We contend that our interpretation is *superior*.  It improves the
> protocol's robustness, and permits solving certain vexing
> problems in a
> much simpler way than Tim Jenkins proposes, and does this (as
> verified by
> both analysis and practical experience) without introducing
> significant
> implementation difficulties or interoperability problems.

I'm not sure that's true. I can think of a few problems off the top of my
head:

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?

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

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.
(Can you give an example of elsewhere in IPsec where this is true?)

Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.


> -----Original Message-----
> From: Henry Spencer [mailto:henry@spsystems.net]
> Sent: Monday, July 17, 2000 6:36 PM
> To: Andrew Krywaniuk
> Cc: hugh@mimosa.com; 'Tim Jenkins'; 'IPsec List'; 'Hugh Daniel'; 'John
> Gilmore'
> Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt
>
>
> On Mon, 17 Jul 2000, Andrew Krywaniuk wrote:
> > Internet drafts are written in a mix of English and jargon;
> sometimes the
> > two languages overlap and it confuses people.
>
> I don't actually think that's an issue here...
>
> > Obviously, Dan knows what the
> > intent of the wording in the IKE RFC is; I don't see how
> you can argue with
> > that.  Most of the rest of us figured it out as well.
>
> The problem with standards which rely on "well, everybody
> knows that where
> it says WX_Z it really means WXQZ" is precisely that not
> everybody *does*
> know.  Dan surely knows what the RFC was supposed to say, but
> that's not
> what it actually says.
>
> Moreover, I think this has slightly missed our point.  We are not just
> arguing that there is a different interpretation possible
> here, or that it
> is the preferred interpretation in the absence of
> supplementary folklore
> (although we do make both those claims).
>
> We contend that our interpretation is *superior*.  It improves the
> protocol's robustness, and permits solving certain vexing
> problems in a
> much simpler way than Tim Jenkins proposes, and does this (as
> verified by
> both analysis and practical experience) without introducing
> significant
> implementation difficulties or interoperability problems.
>
> The primary criterion for choice when resolving ambiguities should be
> technical merit, not closeness to the original intent.
>
>
> Henry Spencer
>
> henry@spsystems.net
>
>



Follow-Ups: References: