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

RE: Notify SPI field specifications

> Which group of documents were both consolidated and split up
> to "clarify
> things"? It would be very interesting to compare the
> outcomes. A hint on
> the mindset ("reactionary and/or idealistic") for both
> outcomes would also
> be quite interesting. Please provide pointers to these documents.

I'm not talking specifically about IETF RFCs here. The document that was
both consolidated and split up wasn't an IETF RFC. I was merely commenting
that this was a fairly universal problem. There are always competing
motivations. If a document is too long then it can be hard to find the
pertinent information amidst all the clutter. On the other hand, if you
create too many small documents, then you can spend a lot of time flipping
back and forth between them. Another solution is to just make the document
shorter, in which case it is also likely to be vague.

Despite the fact that KINK was a reaction to IKE, remember that the original
charter specified that they would in effect support multiple DOIs. BTW, I
believe that the SASL charter says that they will split up the RFC into
multiple documents. And while the IPSP WG is espousing the dogma that they
can't change IKE because IKE is too complicated, they are themselves
developing two instantiations of a framework which is built upon yet another
framework.

As we know, prevailing attitudes can be very fickle. It is human nature to
believe that the grass really is greener on the other side. People tend to
upplay the problems they have right now and downplay the problems that
others had in the past. It is a well known fact that every programmer who
takes over a project always believes that the existing codebase needs to be
redesigned from scratch. And after he does this, the next programmer who
comes along believes the exact same thing. There is always a tradeoff; you
have to pick your poison. If you make a protocol too flexible, it can be
hard to implement. If you make it too specific, you will find yourself
reimplementing the same thing over and over again. Given the similarity of
the problems, I think it would be ridiculous if MSec didn't reuse most of
the existing IKE specifications.

I think if there is a single best way to organize a set of documents, it is
by target audience. I think the existing set of documents does that pretty
well, for the most part, although there is still room for improvement.
[ISAKMP] is an explanatory document which is of interest to someone who
wants to know how to design a security protocol. [DOI] takes care of some
bland housekeeping stuff that would only be of interest to an implementer.
My comment was that [IKE] does not appear to be focused on a particular
audience. It ought to be readable by someone who merely wants to use IKE and
not implement it. Merging all the documents together doesn't solve that
problem.

This philosophical discussion is a bit off-topic for the list. I don't want
to start a big debate about it. We can discuss it offline if you like.


> I don't think you understand....
>
> IKE was supposed to be a generic exchange under which
> multiple DOIs could
> be implemented. It has to create its own SA which is
> different than the
> DOI-defined SA and therefore has to be able to do this
> independent of any
> DOI. The DH groups are critical to establishing the IKE SA!
> They cannot
> just be referenced in a DOI! If there were copied from
> anywhere they were
> copied from Oakley, not ISAKMP (or even [ISAKMP]). Similarly
> the ciphers
> necessary to construct the IKE SA are defined in IKE. They
> are not "just
> referenced in the DOI".

Yes, the DH groups are copied from Oakley. But the assigned numbers in IKE
are merely distractions. I often wondered why there wasn't an ISAKMP DOI
document (or why this wasn't just a section in the IPsec DOI RFC).

The fact is, no one really wants to define a new DOI just to define a
different numbering scheme for the cryptographic algorithms. The main
benefit is the ability to add selectors or transport for non-IP packets.
Some might argue that we are the IETF, so why should we help people in
defining non-IP security, but I think that's being overly zealous.

Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.


> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@lounge.org]
> Sent: Tuesday, September 04, 2001 1:32 PM
> To: andrew.krywaniuk@alcatel.com
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Notify SPI field specifications
>
>
> On Tue, 04 Sep 2001 11:07:05 EDT you wrote
> >
> > I've seen documentation split up in order to "clarify
> things," and I've seen
> > the same documents consolidated in order to "clarify
> things." The second
> > generation of documents is rarely any better than the
> first, usually because
> > it was written with a reactionary and/or idealistic
> mindset. The same result
> > usually applies to second generation code as well, mostly
> for the same
> > reasons.
>
> Which group of documents were both consolidated and split up
> to "clarify
> things"? It would be very interesting to compare the
> outcomes. A hint on
> the mindset ("reactionary and/or idealistic") for both
> outcomes would also
> be quite interesting. Please provide pointers to these documents.
>
> > Instead of being a focused protocol description, [IKE] is
> more of a mishmash
> > of all the bits and pieces that were left open by [ISAKMP].
> Why are the DH
> > groups copied here, and not just referenced in the DOI like
> the ciphers?
>
> I don't think you understand....
>
> IKE was supposed to be a generic exchange under which
> multiple DOIs could
> be implemented. It has to create its own SA which is
> different than the
> DOI-defined SA and therefore has to be able to do this
> independent of any
> DOI. The DH groups are critical to establishing the IKE SA!
> They cannot
> just be referenced in a DOI! If there were copied from
> anywhere they were
> copied from Oakley, not ISAKMP (or even [ISAKMP]). Similarly
> the ciphers
> necessary to construct the IKE SA are defined in IKE. They
> are not "just
> referenced in the DOI".
>
> I think it is safe to say that there are more people than
> just you who did
> not or do not understand how these things were done so let me
> point out
> again that if these layers go away these misunderstandings
> about the layers
> do too.
>
>   Dan.
>
> "I personally think it is very dangerous to organize
>  referendums when you're not sure to win them"
>    -- Louis Michel, President of the European Union
>
>