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

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.) ?