Telechat Review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07
review-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07-secdir-telechat-kent-2015-03-12-00
| Request | Review of | draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp |
|---|---|---|
| Requested revision | No specific revision (document currently at 07) | |
| Type | Telechat Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2015-03-10 | |
| Requested | 2015-03-05 | |
| Authors | Fei Zhang , Ruiquan Jing , Rakesh Gandhi | |
| Draft last updated | 2015-03-12 | |
| Completed reviews |
Genart Last Call review of -01
by
Russ Housley
(diff)
Genart Telechat review of -07 by Russ Housley Secdir Telechat review of -07 by Stephen Kent Opsdir Last Call review of -01 by Sheng Jiang (diff) Rtgdir Early review of -01 by Lizhong Jin (diff) |
|
| Assignment | Reviewer | Stephen Kent |
| State | Completed | |
| Review |
review-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07-secdir-telechat-kent-2015-03-12
|
|
| Reviewed revision | 07 | |
| Result | Ready | |
| Completed | 2015-03-12 |
review-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07-secdir-telechat-kent-2015-03-12-00
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 the
Security 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.