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

RE: Notify SPI field specifications



> > Merging the documents is not a magic wand you can wave in
> order to make the
> > documents clearer; you actually have to write the text clearly and
> > unambiguously.
>
> I never said it was a magic wand. I said it would clean up
> just the sort
> of confusion that started this thread: one document saying
> one thing and
> another saying something different. If there is one document then that
> problem doesn't happen.

I think that's a rather over-simplified line of reasoning, along the lines
of the prevailing modern attitude that it's usually better to be unambiguous
than correct.

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.


> > Perhaps the problem is that RFC2409 didn't need to be a generic key
> > exchange. Isn't it possible that only one of the 3
> documents is confusing?
> > Criticizing your own document due to circumstances beyond
> your control seems
> > like passing the buck.
>
> No it didn't and no I don't think so. You may be able to
> explain the true
> meaning of the Commit Bit by just reading RFC2408 but no one else can.
> And I don't think anyone can justify the seemingly mandated
> covert channel
> in RFC2408.

The way I read it, [ISAKMP] specifies what the commit bit field is for, but
doesn't say when to set it, or in which message to send the CONNECTED
notify. That seems perfectly reasonable to me. [IKE] could have and should
have constrained this further.

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? The
myriad of implementation hints scattered throughout reads like a list of
things not to do that someone obviously did at a bakeoff at some point.

The problem, in my mind, is that [IKE] wouldn't make any sense to someone
who hasn't read and absorbed [ISAKMP]. That's the wrong order. Instead, the
IKE document would be easier to comprehend if it described the protocol
behaviour, and referred to [ISAKMP] whenever necessary in order to fill in
the details.

It distresses me that you seem intent on a large scale (and slow) complete
revamping of the protocol (with all the arguing and interoperability
problems) when a smaller and quicker tweaking of one aspect of the protocol
would suffice.


> We have payloads being defined in one document and redefined
> in another.

Whole payloads?

> We have overly generic descriptions of things simply because
> there is this
> artificial layering of the documents. That will all go away.

I, for one, happen to not find the distinction between (among other things)
the data model and the protocol details to be an artificial layering. If it
is then someone better go tell IPSP, cuz they're screwing this one up big
time.


> > I keep hearing, without substantiation, that having a DOI
> has greatly
> > complicated IKE. However, I have noticed that 4 other
> groups have exploited
> > this feature to create keying protocols with much reduced
> effort, and all
> > without any extra work by me.

> The artificial layering has creatly complicated the key
> management protocol
> for IPsec. It is completely unnecessary. The problem that the
> DOI adds is
> not only one of added genericicity (the attempt to be vague enough to
> satisfy all sorts of possible key management protocols) but
> it encourages
> people to overload one single port with all sorts of security
> protocols.
> That is A Bad Thing.

It is the generalized concept of a DOI that is useful, not the DOI field in
various payloads or the ability to demultiplex on a single port. Probably
the document should say not to do that.

> Which 4 keying protocols have been created with the DOI
> concept? KINK? No.
> GDOI? Sort of but not really. OSPF DOI? That died. RIP DOI?
> That died too.

Literally using a DOI: OSPF, RIP, MPLS, MAP. Sort of using a DOI: KINK,
GDOI.

In all of these cases, it appeared to me that the work of the protocol
designers was reduced by reusing the ISAKMP framework.


> > > "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
> >
> > You can aways hold another referendum next year, and keep
> holding them once
> > every few years until you win.
>
> You of all people should not be making fun of someone's sig.
> I've left your
> pompous one below for comparison.

For the record, I wasn't actually making fun of your sig. I was merely
commenting that perhaps Louis Michel could learn a thing or two from the
government of Quebec.

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.



Follow-Ups: