Applicability of Keying Methods for RSVP Security
draft-ietf-tsvwg-rsvp-security-groupkeying-11

[Ballot comment]
(1) If RSVP supported asymmetric authentication of messages then a lot
of this could be easier, or at least different, e.g. for inter-domain,
public key based schemes might be better. It might be good to mention
this possibility here since currently rfc 2747 mandates hmac-md5 and
one would assume that that may be revised in future in which case a
signature based scheme could be a good addition. So, I'd say that a
paragraph mentioning that key management for a putative signature
based RSVP integrity scheme could be relatively simple (compared to
group key management) would be a fine addition. Or, if there are
reasons why key management for a putative signature based RSVP
authentication scheme would be equally hard, that'd be good to add
as well.

(2) Last para of 10.1 - presumably group keying means a subverted node
might be less easily detected/traced if it sends fake RSVP messages to
a non-neighbour (maybe with a fake source address). Per-neighbour or
interface keying would mean that the subverted node has to send the fake
stuff to a nearby non-subverted node and will generally therefore be more
easily traced.

[Ballot comment]
1) Should the reference to 3547 be swapped out for a reference to draft-ietf-msec-gdoi-update?  It's on the same telechat and draft-ietf-msec-gdoi-update obsoletes RFC 3547.  They'd both be published at around the same time assuming all goes smoothly.

2) Expand GKS (group key server) in Section 3.  It'd be best to explain what it is before Figure 2.

3) In Section 6.2, is it worth pointing out that an additional difference is that AH has some kind of algorithm agility while the INTEGRITY object mechanism does not?

[Ballot comment]
I have updated my Comment to include some points raised by Dimitri Papadimitriou in his Routing Directorate review. Please consider a new revision to pick up all of these points.


I support the publication of this document as a useful contribution to
the problem of securing RSVP, RSVP-TE, and GMPLS signaling in a scalable
manner.

There are a few small points that you might like to look at as part of
the general document polishing.

---

Nit:

Section 2

  The trust an RSVP node has to another RSVP node has an explicit and
  an implicit component.  Explicitly the node trusts the other node to
  maintain the RSVP messages intact or confidential, depending on
  whether authentication or encryption (or both) is used.  This means
  only that the message has not been altered or seen by another, non-
  trusted node.  Implicitly each node trusts each other node with which
  it has a trust relationship established via the mechanisms here to
  adhere to the protocol specifications laid out by the various
  standards.

Another explicit element of this trust model is that the peer will have
applied at least the same level of authentication with its next hop
peer. That is, a message that is received by C from B using
authentication, was originated at B, was received by B from A using
authentication, or was triggered at B because of the receipt at B of a
message from A that used authentication.

Without this element of the trust model, the authentication between
B and C is not particularly useful. I think your definition of security
domain (in Section 1.1) could be used in new text to make this point.

---

WIBNI

I might have put the final paragraph of Section 2 into Section 3.2

---

Nit:

Section 3.1

  Most current RSVP authentication implementations support per
  interface RSVP keys.  When the interface is point-to-point (and
  therefore an RSVP router has only a single RSVP neighbor on each
  interface), this is equivalent to per neighbor keys in the sense that
  a different key is used for each neighbor.

This slightly neglects the possibility of parallel interfaces to the
same neighbor.

---

Wrinkle                                   

In Figure 4, isn't it the case that one node, say R3, could be in both
security domains and apply the group key on a per interface / per
neighbor / per IP next hop basis?

---

WIBNI

Section 5.2 is largely dedicated to FRR.
It might be nice to give FRR its own section and leave just the last
two paragraphs (P2MP and hierarchy) in 5.2, perhaps renaming it
"Other RSVP-TE and GMPLS Functions"

---

Smile

Section 10.1

  A subverted node is defined here as an untrusted node, for example
  because an intruder has gained control over it.

If we knew that a subverted node was subverted, it would be untrusted.
And that would be the end of the story. But the problem is that we *do*
trust the subverted node!

---

I wouldn't like to have to argue in a court of law that some of the
references are not normative (e.g. 2205).

===

Comments from Dimitri's review as follows:

A general comment: I've noticed that only "may" (in small letters) is used and the phrasing is sometimes not prescriptive, is it intentional (due to informational status) ?

o) Introduction

. Suggest to add reference after "It is however often necessary to regularly change keys due to network operational requirements." or summarize the "operational requirements"

o) Section 2

. Spell out acronym GDOI

o) Section 3.1

. It may be appropriate to explain where/how are the boundaries of RSVP security domains defined. 

. States "As discussed in the previous section, per neighbor and per interface keys can not be used in the presence of non-RSVP hops." while that Section states "This means that per interface and per neighbor keys cannot easily be used in the presence of non-RSVP routers on the path between senders and receivers." there is a different interpretation one can assume from the term "easily"?

. Any specific scenario where a Single Group Key Server across security domains could be applicable ? How do R3 and R4 determine there are in different domains ? afaik the INTEGRITY object doesn't provide such information.

. States "Because a group key may be used to verify messages from different peers, monotonically increasing sequence number methods are not appropriate." make clear what is actually recommended e.g. Sequence Numbers Based on a Real Time Clock (Section 3.2 of RFC 2747)

o) Section 4.1

. States "Since it is not feasible to carry out a key change at the exact same time in communicating RSVP nodes, some grace period needs to be implemented during which an RSVP node will accept both the old and the new key. " what is recommended/proposed this dual-key temporary state doesn't become permanent and one ends up with a list of keys ?

. States "In this solution, a key server authenticates each of the RSVP nodes independently" explain independently from what ?

o) Section 5.1

Explain use of group keying for Notify messages between "domains" (referring to Fig.4).

o) Section 5.2

. The P2MP case deserves a bit more explanations. In particular, RFC 4875 mentions "An administration may wish to limit the domain over which P2MP TE tunnels can be established. This can be accomplished by setting filters on various ports to deny action on a RSVP path message with a SESSION object of type P2MP_LSP_IPv4 or P2MP_LSP_IPv6." does the present document overrule "filter setting" or complements it when reaching security domain boundaries ?

. For RFC 4206, clarify that non hop-by-hop signaling is used to signal LSP tunneled over an FA.

o) Section 6.1

Spell out acronyms the SPD and SPI

o) Section 6.3

Is the tunnel mode also excluded for hosts attached to the network by a non-RSVP host ?

o) Section 7

What is actually referred as "the network" in the following sentence "If the end systems are part of the same security domain as the network itself, group keying can be extended to include the end systems." i.e. is the network the set of nodes enabling host attachment to the network ?

o) Section 8

Mentions "From the viewpoint of securing end-to-end RSVP, ..." is it securing RSVP end-to-end or edge-to-edge (edge being the end-points of the MPLS-TE tunnels, the edges of the PCN domain, etc.) ?

[Ballot comment]
I support the publication of this document as a useful contribution to
the problem of securing RSVP, RSVP-TE, and GMPLS signaling in a scalable
manner.

There are a few small points that you might like to look at as part of
the general document polishing.

---

Nit:

Section 2

  The trust an RSVP node has to another RSVP node has an explicit and
  an implicit component.  Explicitly the node trusts the other node to
  maintain the RSVP messages intact or confidential, depending on
  whether authentication or encryption (or both) is used.  This means
  only that the message has not been altered or seen by another, non-
  trusted node.  Implicitly each node trusts each other node with which
  it has a trust relationship established via the mechanisms here to
  adhere to the protocol specifications laid out by the various
  standards.

Another explicit element of this trust model is that the peer will have
applied at least the same level of authentication with its next hop
peer. That is, a message that is received by C from B using
authentication, was originated at B, was received by B from A using
authentication, or was triggered at B because of the receipt at B of a
message from A that used authentication.

Without this element of the trust model, the authentication between
B and C is not particularly useful. I think your definition of security
domain (in Section 1.1) could be used in new text to make this point.

---

WIBNI

I might have put the final paragraph of Section 2 into Section 3.2

---

Nit:

Section 3.1

  Most current RSVP authentication implementations support per
  interface RSVP keys.  When the interface is point-to-point (and
  therefore an RSVP router has only a single RSVP neighbor on each
  interface), this is equivalent to per neighbor keys in the sense that
  a different key is used for each neighbor.

This slightly neglects the possibility of parallel interfaces to the
same neighbor.

---

Wrinkle                                   

In Figure 4, isn't it the case that one node, say R3, could be in both
security domains and apply the group key on a per interface / per
neighbor / per IP next hop basis?

---

WIBNI

Section 5.2 is largely dedicated to FRR.
It might be nice to give FRR its own section and leave just the last
two paragraphs (P2MP and hierarchy) in 5.2, perhaps renaming it
"Other RSVP-TE and GMPLS Functions"

---

Smile

Section 10.1

  A subverted node is defined here as an untrusted node, for example
  because an intruder has gained control over it.

If we knew that a subverted node was subverted, it would be untrusted.
And that would be the end of the story. But the problem is that we *do*
trust the subverted node!

---

I wouldn't like to have to argue in a court of law that some of the
references are not normative (e.g. 2205).

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Applicability of Keying Methods for RSVP Security) to Informational RFC


The IESG has received a request from the Transport Area Working Group
(tsvwg) to consider the following document:
- 'Applicability of Keying Methods for RSVP Security'
  as an Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-08-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity
  protection of RSVP neighbors.  This requires messages to be
  cryptographically protected using a shared secret between
  participating nodes.  This document compares group keying for RSVP
  with per neighbor or per interface keying, and discusses the
  associated key provisioning methods as well as applicability and
  limitations of these approaches.  The document also discusses
  applicability of encrypting RSVP messages.

The Responsible AD notes that the IPR declaration terms seem to apply to
standards-track documents, but not necessarily to an Informational document.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-security-groupkeying/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-security-groupkeying/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/988/

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?

-- Editorial 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.

This is a TSVWG request that "Applicability of Keying Methods for
RSVP Security" () be
published as an Informational RFC.

  (1.a) Who is the Document Shepherd for this document? Has the
    Document Shepherd personally reviewed this version of the
    document and, in particular, does he or she believe this
    version is ready for forwarding to the IESG for publication?

James Polk  is the Document Shepherd. I have
reviewed this version of the document, and believe this is ready to
forward to the IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
    and from key non-WG members? Does the Document Shepherd have
    any concerns about the depth or breadth of the reviews that
    have been performed?

Yes, key members of the WG have reviewed this document. Stephen Kent
has also provided a detailed review.

Stephen Kent of the Sec-dir reviewed this document as well, and made
significant comments resulting in a fair amount of rewrite. All of
Stephen's comments and concerns have been addressed to his
satisfaction; therefore, I believe this has received sufficient
reviewing.

There are no concerns with this -08 version of this document.

  (1.c) Does the Document Shepherd have concerns that the document
    needs more review from a particular or broader perspective,
    e.g., security, operational complexity, someone familiar with
    AAA, internationalization, or XML?

No, I do not have concerns about this document progressing forward,
given Mr. Kent's review.

  (1.d) Does the Document Shepherd have any specific concerns or
    issues with this document that the Responsible Area Director
    and/or the IESG should be aware of? For example, perhaps he
    or she is uncomfortable with certain parts of the document, or
    has concerns whether there really is a need for it. In any
    event, if the WG has discussed those issues and has indicated
    that it still wishes to advance the document, detail those
    concerns here. Has an IPR disclosure related to this document
    been filed? If so, please include a reference to the
    disclosure and summarize the WG discussion and conclusion on
    this issue.

No, there are no additional concerns.

There is declared IPR on this document, at
https://datatracker.ietf.org/ipr/search/?option=document_search&docume
nt_search=draft-ietf-tsvwg-rsvp-security-groupkeying
filed in 2008, which no one has mentioned as an issue.

It's transparent to declare that I work for the same organization
that has the IPR claim, so some might consider me biased on the
matter. This can possibly be given less weight since the ID is an
Informational document, and not a standards track, but I do concede
that some on the IESG might take issue with this.

  (1.e) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with
    others being silent, or does the WG as a whole understand and
    agree with it?

There is WG consensus around this document, with otherWG members
being silent. The nature of TSVWG is an open area WG, with now 7
primary topics of interest; very few efforts ever get 'strong' WG
consensus. That said, consensus was solidly behind this document with
no current objections or open comments to this doc. This doc has been
reviewed by many people, including the Sec-dir already.

  (1.f) Has anyone threatened an appeal or otherwise indicated
extreme
    discontent? If so, please summarize the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    entered into the ID Tracker.)

No, there was never any threat of appeal wrt this document.

  (1.g) Has the Document Shepherd personally verified that the
    document satisfies all ID nits? (See
    http://www.ietf.org/ID-Checklist.html and
    http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
    not enough; this check needs to be thorough. Has the document
    met all formal review criteria it needs to, such as the MIB
    Doctor, media type, and URI type reviews? If the document
    does not already indicate its intended status at the top of
    the first page, please indicate the intended status here.


I have verified the 1 error is where this intended-to-be
Informational RFC quotes another RFC, which is the only use of RFC
2119 language. I believe this is fine.

I have verified the 1 warning (lacking a disclaimer for pre-RFC5378
work) is ok with the editors.

I have verified the 1 comment is stating the document is only 7 days
old, and is questioning that - again, which I believe is fine.


  (1.h) Has the document split its references into normative and
    informative? Are there normative references to documents that
    are not ready for advancement or are otherwise in an unclear
    state? If such normative references exist, what is the
    strategy for their completion? Are there normative references
    that are downward references, as described in [RFC3967]? If
    so, list these downward references to support the Area
    Director in the Last Call procedure for them [RFC3967].

The references are not split - and are only informational because
this is an informational document.


  (1.i) Has the Document Shepherd verified that the document's IANA
    Considerations section exists and is consistent with the body
  of the document? If the document specifies protocol
    extensions, are reservations requested in appropriate IANA
    registries? Are the IANA registries clearly identified? If
    the document creates a new registry, does it define the
    proposed initial contents of the registry and an allocation
    procedure for future registrations? Does it suggest a
    reasonable name for the new registry? See [RFC2434]. If the
    document describes an Expert Review process, has the Document
    Shepherd conferred with the Responsible Area Director so that
    the IESG can appoint the needed Expert during IESG Evaluation?


The document states that there are no IANA considerations for this
document as it does not register anything, therefore this section can
be removed by the RFC-Editor during publication processing.


  (1.j) Has the Document Shepherd verified that sections of the
    document that are written in a formal language, such as XML
    code, BNF rules, MIB definitions, etc., validate correctly in
    an automated checker?

Yes, I have verified there is no formal language such as XML
code, BNF rules, MIB definitions, etc. contained within this document.



  (1.k) The IESG approval announcement includes a Document
    Announcement Write-Up. Please provide such a Document
    Announcement Write-Up. Recent examples can be found in the
    "Action" announcements for approved documents. The approval
    announcement contains the following sections:

    Technical Summary

The Resource reSerVation Protocol [RFC2205] allows hop-by-hop
authentication of RSVP neighbors, as specified in [RFC2747].  In this
mode, an integrity object is attached to each RSVP message to
transmit a keyed message digest.  This message digest allows the
recipient to verify the identity of the RSVP node that sent the
message, and to validate the integrity of the message.  Through the
inclusion of a sequence number in the scope of the digest, the digest
also offers replay protection.

This document discusses a variety of keying methods and their
applicability to different RSVP deployment environments, for both
message integrity and encryption.  It is meant as a comparative guide
to understand where each RSVP keying method is best deployed, and the
limitations of each method.  Furthermore, it discusses how RSVP hop
by hop authentication is impacted in the presence of non-RSVP nodes,
or subverted nodes, in the reservation path.

The document "RSVP Security Properties" ([RFC4230]) provides an
overview of RSVP security, including RSVP Cryptographic
Authentication [RFC2747], but does not discuss key management.  It
states that "RFC 2205 assumes that security associations are already
available".  The present document focuses specifically on key
management with different key types, including group keys.  Therefore
this document complements [RFC4230].


    Working Group Summary

Understanding that 'strong' consensus is nearly impossible in an open
area WG such as TSVWG, with 5-6 sub-groups within this WG divided
along technology focuses -- there is unwavering consensus in the WG
amongst interested parties to publish this document. It has been
reviewed by several people in the WG last call. Comments raised have
been addressed, including those from the Sec-dir.

    Document Quality

No, there is no working implementation of this document in a
protocol. The Sec-dir assigned Stephen Kent, who did an exceptional
review of this document.

James Polk is the document Shepherd. David Harrington is the
responsible Area Director. There are no IANA registrations specified
by this document.