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

["David Harrington" <[e-mail]>]

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)