[secdir] SECDIR review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07

[Stephen Kent <[e-mail]>]

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.These comments were written with the intent of improving security 
requirements and considerations in IETF drafts.Comments not addressed in 
last call may be included in AD reviews during the IESG review.Document 
editors and WG chairs should treat these comments just like any other 
last call comments.

As far as security is concerned, I see no problems with this document. 
Tracing back through the list of Security Consideration sections of 
cited documents in one case leads to a disappointing origin in RFC 2747. 
The other chain is shorter and more relevant, and it provides greater 
confidence that this document yields no new security concerns.

This document describes extensions to RSVP to enable creating a 
bidirectional LSP from two p-t-p unidirectional LSPs.

The security considerations section consists of just two paragraphs. The 
first cites the security considerations section of RFC 6780 (RSVP 
Association Objects) as encompassing any security issues that might 
arise in this context. (The assertion is that this document introduces 
no new signaling information, and thus no new security concerns.)

The Security Considerations section of 6780 is also two paragraphs in 
length. That text states that no new security considerations have been 
introduced, because no new procedures have been defined. Hence it cites 
theSecurity Considerations sections of RFC 4872 and 4873.

RFC 4872 cites RFC 4426 (RFC 4873 cites RFC 4872).

The security considerations section of 4426 is almost a full page. It 
specifies security services that are required to protect the GMPLS 
recovery mechanisms defined in that document, but does not point to ANY 
security mechanisms that should be employed.

RFC 4872 also establishes a few security-relevant requirements for RSVP 
signaling, and cites RFC 2747 as specifying the required security 
mechanisms. (4872 also notes that IPsec could be employed for hop-by-hop 
integrity and authentication, and cites RFC 3473. I note that 3473 is 
from 2003, and thus refers to IPsec and IKE RFCs that have been obsoleted!)

RFC 2747 specifies crypto authentication mechanisms for RSVP, but dates 
from 2000. It anticipates that “ … the IETF will define a standard key 
management protocol” and thus omits specification of such in that 
document. (A fun walk down memory lane …)

The second paragraph of the Security Considerations section of this I-D 
notes that additional information is conveyed in the REVERSE_LSP object, 
but that the information is not fundamentally different from what is 
carried in a bidirectional LSP message. Thus, the argument is that no 
fundamentally different information is being transmitted. This paragraph 
cites RFC 5920 (Security Framework for MPLS and GMPLS Networks) as 
relevant. I agree that 5920 seems to be most appropriate RFC in this 
context.