Hi.
I somehow missed the genart review and Stewart kindly forwarded me a
copy
I will shortly be publishing a new version that includes fixes discussed
below.
"genart" == Stewart Bryant <stbryant(_at_)cisco(_dot_)com> writes:
genart> Major issues:
genart> None.
genart> Minor issues:
genart> -- This abstract claims that this draft is a discussion of
genart> issues. From that per spective, I don't think the use of
genart> 2119 language is appropriate. There are some specific areas
genart> (mentioned below) where 2119 language is used in imprecise
genart> ways, and may do harm to the reader's understanding. There
genart> are other uses that may be more reasonable. But I think the
genart> draft would be better off dispensing with 2119 language
genart> altogether.
We disagree.
I think that the draft provides requirements that if followed will make
management of the security aspects of routers easier to depend on.
I believe 2119 language is useful in that.
I think this is well within an area where there is no IETF-wide
consessus and the judgment of the individual WGs and to a lesser extent
editors should control.
genart> -- Section 3, paragraph 4:
genart> This seems like a place where descriptive language would be
genart> better than 2119 lan guage. In particular, "and so on"
genart> leaves things too open ended and imprecise. Al so, the use
genart> of 2119 language in an example seems a bit off.
So, the requirement is stated in the first clause using 2119 language:
Operational Requirements: implementations of this model MUST support
configuration of keys at the most general scope for the underlying
protocol;
The sentence goes on to apply that requirement to some common cases:
protocols supporting per-peer keys MUST permit
configuration of per-peer keys, protocols supporting per-interface
keys MUST support configuration of per-interface keys, and so on.
You might prefer different style rules; you might prefer that the
restatements of the general requirement to specific situations not use
2119 language.
I think the right approach for that is to try and build community
consensus on those style rules and not to apply those rules until such a
consensus is achieved.
I do agree that care should be used when using 2119 in a restatement,
but in this instance believe it is OK.
I've removed the 2119 language from the example, although I think it was
harmless.
genart> -- section 3.1, last paragraph:
genart> I'm not sure what guidance is intended in this paragraph. It
genart> offers an example, then refutes it. Are there better
genart> examples to offer? Is the point that one shoul dn't make
genart> such checks?
The point is that we're not recommending such checks here; added text to
clarify. Thanks.
genart> -- section 3.2, paragraph 2:
genart> What distinguishes SHOULD from "desirable" in this context?
genart> That is, why use 211 9 language for one and not the other?
The sentences including desirable are giving motivation for the
sentences including SHOULD.
That is the SHOULDS are the take-aways, the desirables are
expansions/explanations of why the SHOULDS make sense.
genart> -- section 3.2, last paragraph: "Implementations SHOULD
genart> permit a configuration i n which if no unexpired key is
genart> available, existing security associations continu e using
genart> the expired key with which they were established."
genart> This may need further guidance. For example, it seems risky
genart> to do this silently.
I think this was explicitly discussed in the WG and is where we got in
our discussions.
There's discussion of alerts for security events elsewhere.
However I think the current text represents a fairly informed WG
consensus.
genart> -- section 3.3, last paragraph: "... then there is
genart> complexity in key management protocols."
genart> Can you elaborate? Too much complexity? Are there key
genart> management systems that ar e not complex?
Clarified to indicate that there's complexity that can be avoided if you
don't need key IDs to be globally unique.
genart> -- section 4, 2nd to last paragraph:
genart> Seems like other disadvantages are worth mentioning. For
genart> example, the potential impact of a compromised CA.
I spent a few minutes trying to come up with an argument whether CA
compromise was better or worse than other systems compromise profile,
particularly focusing on central management system compromise in the
preshared key case.
I think it's difficult to come up with an argument about whether that's
actually a disadvantage of CAs in this case and I think getting
consensus would be non-trivial.
I also think that managing CA compromise can either be handled on the
cost axis (secure offline CA) or the complexity axis (push out new CA
certs and end-entity certs on compromise).
So, I think the current text is accurate.
If there are specific disadvantages that can easily be verified, I'm
open to revisions.
genart> -- 4.1:
genart> I understand why one might choose not to include a
genart> real-world example here, but is there something that can be
genart> referenced?
Real wmorld example of what?
genart> -- 4.4, 2nd paragraph: "... it will be critical to make sure
genart> that they are not r equired during routine operation or a
genart> cold-start of a network."
genart> Can you elaborate on why?
I've tried to do so, thanks for catching this.
genart> Nits/editorial comments:
genart> Abstract: Might be worth mentioning KARP and how this draft
genart> fits with others.
I think this doesn't belong in the abstract.
I think we do cover this in the body of the document.
genart> -- Section 1, paragraph 1: Please expand KARP on first
genart> mention.
thanks
genart> -- section 3: The text seems to rather abruptly start
genart> talking about key considered actions wit h little
genart> background. A quick summary of how these keys re used would
genart> be helpful.
I've tried to make this more clear.
genart> -- section 3, paragraph 2: "Each OSPF link needs to use the
genart> same authentication configuration, ..."
genart> Same configuration as what? The sentence appears to say keys
genart> must be the same am ong links but can be different.
Thanks, fixed.
genart> -- section 3.2, first 2 paragraphs:
genart> I'm not sure how a configuration management system and a
genart> configuration interface differ for the purposes of this
genart> discussion.
I tried to fix that in a previous revision, but since you were confused,
we're clearly not there yet.
Added additional text, hopefully this will do it.
genart> -- 4.1, paragraph 4: "Preshared keys that are used via
genart> automatic key management have not been specified for KARP."
genart> I'm not sure what's intended here--if they are not specified
genart> why does the paragr aph go on to talk about them?
We're working on specifying them; clarified.
genart> -- 4.4, 1st paragraph: "... like RADIUS or directories."
genart> Is there a word missing?
I don't think so.
genart> -- 5, bullet list of management objects:
genart> There may be management objects implied by the second and
genart> third bullets, but the y are not mentioned as such. Can you
genart> explicitly state them? For example, in bull et 2 is the
genart> "peer" the object being discussed? Or is it the "name or
genart> key". In bu llet 3, is "group" the managed object, rather
genart> than "routing protocol"?
Thanks, fixed.