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

Sam Hartman <hartmans-ietf@mit.edu> Tue, 17 September 2013 18:29 UTC

Return-Path: <hartmans@mit.edu>
X-Original-To: karp@ietfa.amsl.com
Delivered-To: karp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE9B11E82E0; Tue, 17 Sep 2013 11:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level:
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifk2xpbJbuSW; Tue, 17 Sep 2013 11:29:09 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id A27BF11E812B; Tue, 17 Sep 2013 11:29:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id DC82220186; Tue, 17 Sep 2013 14:28:34 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FtdXCAM9QFW; Tue, 17 Sep 2013 14:28:33 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 17 Sep 2013 14:28:33 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1D35E87FA2; Tue, 17 Sep 2013 14:29:05 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: stbryant@cisco.com
References: <F0728D4E-4DEA-47B4-BA75-CCDB9C562924@nostrum.com> <5224A352.6050007@cisco.com>
Date: Tue, 17 Sep 2013 14:29:05 -0400
In-Reply-To: <5224A352.6050007@cisco.com> (Stewart Bryant's message of "Mon, 02 Sep 2013 15:40:18 +0100")
Message-ID: <tsl1u4n9ua6.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: ben@nostrum.com, Sam Hartman <hartmans-ietf@mit.edu>, ietf@ietf.org, karp@ietf.org
Subject: Re: [karp] Fwd: Gen-ART LC Review of draft-ietf-karp-ops-model-07
X-BeenThere: karp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <karp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/karp>, <mailto:karp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/karp>
List-Post: <mailto:karp@ietf.org>
List-Help: <mailto:karp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/karp>, <mailto:karp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Sep 2013 18:29:15 -0000

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@cisco.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.