Subject: Re: [karp] Fwd: Gen-ART LC Review of draft-ietf-karp-ops-model-07

From: Sam Hartman <[email-masked]>
Date: Tue, 17 Sep 2013 14:29:05 -0400

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 <[email-masked]> 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.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 24 Sep 2013 17:46:40 -0500

Hi, thanks for the response. Comments inline. I've removed sections that do not appear to need further comment.

On Sep 17, 2013, at 1:29 PM, Sam Hartman <[email-masked]> wrote:
>    genart> (mentioned below) where 2119 language is used in imprecis

I think that would be true if the intent of this draft was to create a BCP, or something to that effect. That's not what the abstract and intro say. They characterize the draft as "discussing issues" and "begins to develop a model".

If you think 2119 language is appropriate, then it might be helpful to update the abstract and intro to make it more clear that the draft offers normative guidance, and make it clear when and to whom it applies. For example, section 3 says "Implementations of this model MUST..." It's not clear to me what "this model" means when the abstract and intro make it sound like this draft is early work towards eventually developing such a model.

Bottom line is, I think the problem is not with 2119 language in general so much as it is a matter of the draft being inconsistent on whether it is discussing issues that may eventually lead to a model, or actually describing such a model.

> consessus and the judgment of the individual WGs and to a lesser extent

Certainly. All I am doing is offering an opinion.

> I've removed the 2119 language from the example, although I think it was

Ok. 

My concern was that it is open ended. The words  "and so on" tells me that there may be more normative requirements that the reader is left to infer. That could make it hard to know if an implementation fully complies.

[snip]

> expansions/explanations of why the SHOULDS make sense.

On re-reading that paragraph, I see your point and retract the comment.

> However I think the current text represents a fairly informed WG

You are correct that there is separate text on notification of security events (section 6.2), and that even mentions certificate expiration. But it doesn't explicitly mention continuing to use an expired key. I think that's important enough that it should be explicitly considered.

If it was explicitly discussed in the working group, it would be helpful to document the trade-offs that were discussed.

[snip]

> If there are specific disadvantages that can easily be verified, I'm

The previous paragraph listed an advantage that the fact that a server only has it's on key material  limits the scope. The idea of a compromised CA having a potentially very large scope of damage is pretty well known, and it's a very real concern given the news of late. How that compares to the compromise of a central management system depends on whether the CA is a "third party" (or as in the web browser case, many third parties) vs the operator itself. (I guess the central management system could also be a third party, but that may be less typical.)

OTOH, the idea that a PKI is more costly is hard to verify without a cost-benefit analysis about the CA costs compare to the operational savings.

> Real wmorld example of what?

Sorry, that was for section 4.1.2: "This hypothetical example is overly simplistic; real-world attacks exploiting key separation weaknesses tend to be complicated..."

> I think we do cover this in the body of the document.

It's pretty common that when a draft is part of a larger body of work, that it be mentioned in the abstract. People look at abstracts to determine if they need to read the draft in the first place.

[snip]