Re: AD review: draft-ietf-tsvwg-rsvp-security-groupkeying-09

[Michael Behringer <[e-mail]>]

Thank you David for your AD review. In version 10 (just posted) we 
address your comments. The IDnits check shows no issues. We believe that 
the document is now ready for publication.

Thanks for your help!
Michael


On 19/04/2011 23:21, David Harrington wrote:
> Hi,
>
> I have performed an AD review of this document.
>
> Overall, I found the content of this document well written, but have a
> few concerns.
> I believe these should be fairly easy to resolve.
>
> -- Technical and Process concerns:
> 1) section 2 last paragraph
> "... the RSVP router that
>     receives the Path message will be able to authenticate it
>     successfully using the group key."
> It is important to be consistent in specifying what is being
> authenticated. Here "it" appears to refer to a message. Earlier text
> in section 2 says "If a group key is used, the authentication
> granularity becomes group membership of devices, not (individual) peer
> authentication between devices", which seems to indicate a device (or
> peer) is being authenticated (or a group of devices).
>
> 2) I am concerned with the number of "should" and "should not"
> recommendations, using non-RFC2119 keywords in an Informational
> document. This feels like you are trying to define a standard or BCP
> without using the standards track process. I think the usage of
> "should" should be eliminated from an Informational document.
>
> 3) Has the WG explicitly discussed acceptability of the IPR terms
> related to this document? The RAND terms apply for compliance to the
> standard, but this is not being submitted as a standards-track
> document. As noted in 2), there are a number of shoulds in this
> Informational document. The terms in the IPR declaration do not seem
> to provide non-assert status for implementing an Informational
> document. Has the WG discussed this?
>
> Comments (mainly suggestions for improving the text):
> 1) The text is made much harder to read because there are a bunch of
> unnecesary lead-in phrases. You do not need a lead-in phrase for most
> sentences.
> Sentences that start with "Note that" generally don't need the "Note
> that".
> Sentences that start with "This implies that" generally don't need the
> "This implies that".
> Sentences that start with "We observe that" generally don't need the
> "We observe that".
> Sentences that start with "As observed in the security considerations
> section of RFCXXXX," generally don't need the introductory lead-in,
> just a simple reference after the stated content.
>
> These superfluous phrases obscure the real content of the text.
>
> 2) [I-D.weis-gdoi-mac-tek] is referenced informationally. I generally
> prefer to avoid referencing IDs; they are an unstable thing to
> reference, and can delay document publication.
>
> 3) The next-to-last paragraph of section2 (starting with "This means
> that") could benefit from rephrasing. The first sentence seems to
> belong to the preceding paragraph (the challenge), while the rest of
> this paragraph is about the impact of handshakes. I think the
> paragraph could be more succinct:
> OLD:
>   Section 4.3 of [RFC2747] states that "... the
>     receiver MAY initiate an integrity handshake with the sender."  We
>     note that if this handshake is taking place, it can be used to
>     determine the identity of the next RSVP hop.  In this case,
> non-RSVP
>     hops can be traversed also using per interface or per neighbor
> keys.
> NEW:
>   Section 4.3 of [RFC2747] states that "... the
>     receiver MAY initiate an integrity handshake with the sender."
> Non-RSVP hops can be traversed more easily using per interface or per
> neighbor keys if an integrity handshake is used to determine the
> identity of the next RSVP hop.
>
> (The ease is impacted; are the security properties impacted at all?)
>
> 4) section 3.1 defines "security domain". I think the definition is
> not clear and unambiguous. I think if you are going to define a term,
> it should not be buried in the fourth sentence of a paragraph. Put it
> in a terminology section, and make sure it is clear and unambiguous.
> If the term is already clearly defined in another document, please
> reference the normative document.
>
> 5) please ask the RFC editor whether they would prefer that "per
> interface" and "per neighbor" be hyphenated.
>
> 6) "per interface" should be "Per interface" when it starts a
> sentence.
>
> 7) please run id-nits and correct the problems it finds. I ran it and
> it complains about copyright year, lack of an RFC2119 reference, and
> the IPR disclaimer. Some complaints are caused by crossing a year-end
> during processing and are easy fixes.
>
> 8) I found section 3.1 a bit confusing on first read. The problem is
> the repetition using different words:
> "However, when the
>     interface is multipoint, all RSVP speakers on a given subnet have
> to
>     share the same key in this model.  This makes it unsuitable for
>     deployment scenarios where nodes from different security domains
> are
>     present on a subnet"
> and
> "As mentioned above, per interface keys are only
>     applicable when all the nodes reachable on the specific interface
>     belong to the same security domain."
> and
> "Again, interface
>     level keys can be deployed safely only when all the reachable
>     neighbors on the interface belong to the same security domain."
>
> What happens if interpretatiosn of the wording differ because your
> wording differs? State it once clearly, so you don't have to keep
> repeating it in different language.
>
> 9) s/We observe that, alternatively, in some
>     environments, //
>
> 10) The sentence starting "Group keying may allow" might be better as
> the start of the next paragraph.
>
> 11) section 5.2
> OLD:
> In its Security Considerations section,
>     [RFC4875] points out that RSVP message integrity mechanisms for
> hop-
>     by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE
> signaling.
> Suggested:
>     RSVP message integrity mechanisms for hop-
>     by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE
> signaling
>     (see [RFC4875] Security Considerations).
>
> 12) s/In turn, we observe that the analyses in this document of keying
>     methods apply equally to P2MP RSVP-TE for the hop-by-hop signaling.
> /analyses in this document apply to P2MP RSVP-TE hop-by-hop
> signaling./
>
> But after cutting away the excess words, does this sentence actually
> say anything?
>
> Is it the analyses in this document that apply to P2MP signalling, or
> is it the RSVP integrity mechanism that applies?
> Or are you saying that the analysis of keying methods for RSVP apply
> to the keying for P2MP signalling?
>
> 13) "We note that the observation in Section 3.1 of this
>     document about use of group keying for protection of non-hop-by-hop
>     messages apply to protection of non-hop-by-hop signaling for LSP
>     Hierarchy and P2MP RSVP- TE."
>
> What does this sentence actually say? Please be clear and unambiguous
> in your wording.
>
> Let me see if I can understand what you are trying to say here.
> a) section 3.1 discusses per-interface and per-neighbor keying, not
> group keying. and doesn't even mention non-hop-by-hop messages.
> b) If I assume you meant 3.2, not 3.1, then I find that 3.2 says "As
> discussed in Section 2, group keying can be used in the presence of
> non-RSVP hops."
> So to understand 5.2, I should read 3.2, which says I should read
> section 2.
>
> and the message is ... "group keying can simplify protection of
> non-hop-by-hop signaling for LSP Hierarchy and P2MP RSVP- TE."
> Is that what you are trying to say?
>
> 14) please expand all acronyms on first usage.
>
>
> David Harrington
> Director, IETF Transport Area
> [e-mail] (preferred for ietf)
> [e-mail]
> [phone] (cell)
>
>
>