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

Re: Agenda for the Minneapolis meeting



On Thu, Mar 15, 2001 at 01:53:15PM -0800, Dan Harkins wrote:
>   It is the critical question. It's something the working group has to
> decide upon too. My preference is to bump the major version number in the
> header and change the bits on the wire where needed. I don't think a
> pure clarification step is really necessary as the documents aren't
> so bad as to prevent implementation and the steps you suggest could
> drag on for years. But, as I said, it's up to the working group whether
> we're changing bits on the wire and if so how and to what extent.

This question has come up before, when Tero was presenting his
proposals for ways of fixing the hash so that it covered the entire
IKE exchange.  (Right now certain fields are not protected by the
hash, and this could be a potential vulnerability, although no one has
come up with an actual attack based on being able to modify the
unprotected fields).

There are ways we could fix this and still retain backwards
compatibility --- or we could just bump the major version number and
make the change.  When the straw poll was done, to my surprise most
folks were in favor of simply making a clean break as opposed to doing
the backwards compatibility kludgery.

That being said, I believe that if we did do a poll, we would see a
strong mandate for something which is "implementation preserving".
That is, it must be fairly easy (for most implementations) to be able
to create an implementation which can simultaneously support IKE and
IKE-bis without major code bloat.  This is a somewhat imprecise
metric, and so there is the possibility that this might get us into
trouble.  Still, certain changes such as "remove this exchange",
should be fairly obviously "implementation preserving".

Still, for the most part, the number of things which are actually
*modifications* should be kept to an absolute minimum.  And I believe
the burden of proof should be *not* to make a modification.  A
modification should onle be done to fix a pre-existing bug or (maybe)
if it significantly simplifies the protocol.  We should *not* add new
features during this exercise, or we'll never get done.  Hopefully,
though, most of the changes will be subtractions, not
additions/modifications.

							- Ted


Follow-Ups: References: