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

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



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



Follow-Ups: References: