Skip to main content

Last Call Review of draft-ietf-teas-rsvp-te-domain-subobjects-03
review-ietf-teas-rsvp-te-domain-subobjects-03-secdir-lc-xia-2015-11-12-00

Request Review of draft-ietf-teas-rsvp-te-domain-subobjects
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-11-09
Requested 2015-10-29
Authors Dhruv Dhody , Udayasree Palle , Venugopal Reddy Kondreddy , Ramon Casellas
Draft last updated 2015-11-12
Completed reviews Genart Last Call review of -03 by Brian E. Carpenter (diff)
Genart Telechat review of -03 by Brian E. Carpenter (diff)
Secdir Last Call review of -03 by Liang Xia (diff)
Opsdir Telechat review of -03 by Victor Kuarsingh (diff)
Rtgdir Early review of -03 by Tomonori Takeda (diff)
Assignment Reviewer Liang Xia
State Completed
Review review-ietf-teas-rsvp-te-domain-subobjects-03-secdir-lc-xia-2015-11-12
Reviewed revision 03 (document currently at 05)
Result Has Nits
Completed 2015-11-12
review-ietf-teas-rsvp-te-domain-subobjects-03-secdir-lc-xia-2015-11-12-00

Hello,



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 primarily for the benefit of the security area
 directors.  Document editors and WG chairs should treat these comments just
 like any other last call comments.



This experimental ID specifies new subobjects for RSVP-TE and GMPLS extensions
to RSVP-TE to include or exclude 4-Byte Autonomous System (AS) and Interior
Gateway Protocol (IGP) area during path setup.



The document appears in reasonably good shape.

Based on good existing security works on the RSVP-TE and GMPLS, such as
[RFC3209], [RFC3473], [RFC4874] and [RFC5920], as well as only introducing some
new subobjects for LSP path setup using the same process as before,
 this document does not introduce new risks in theory.

There are still several open issues (TBDs) in the document that need to be
completed before publication.



Below a series of my own comments, questions for your consideration.



Comment:

One side effect from the misbehaviors of trusted LSR I would suggest you to
consider:

If the LSR includes the new defined subobjects with right AS-ID/IGP area id but
still using the already existed Types, the legacy nodes will process its
content wrongly, and vice versa. In this condition, the length filed
 checking is sometimes useful although not always;



Question:

For the inter-domain scenarios, is it possible that there is not authentication
and data protection mechanisms between the two boundary nodes? Furthermore, if
the connection between these two nodes are not hop-by-hop,
 how to guarantee the data integrity and mutual trust?



Editorial changes:

Section 6: the first sentence “

Security considerations for MPLS-TE and GMPLS signaling are covered in
[RFC3209] and [RFC3473].

”, using the phrases like “MPLS-TE” and “GMPLS signaling” is not very accurate,
suggesting
 to change to “

Security considerations for RSVP-TE and GMPLS signaling RSVP-TE extensions are
covered in [RFC3209] and [RFC3473].

 ”



Thank you.



B.R.

Frank