Skip to main content

Last Call Review of draft-ietf-pce-pcep-service-aware-12
review-ietf-pce-pcep-service-aware-12-secdir-lc-huitema-2016-09-15-00

Request Review of draft-ietf-pce-pcep-service-aware
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-09-13
Requested 2016-08-25
Authors Dhruv Dhody , Qin Wu , Vishwas Manral , Zafar Ali , Kenji Kumaki
I-D last updated 2016-09-15
Completed reviews Secdir Last Call review of -12 by Christian Huitema (diff)
Opsdir Last Call review of -12 by Jouni Korhonen (diff)
Rtgdir Early review of -11 by Christian Hopps (diff)
Assignment Reviewer Christian Huitema
State Completed
Request Last Call review on draft-ietf-pce-pcep-service-aware by Security Area Directorate Assigned
Reviewed revision 12 (document currently at 13)
Result Ready
Completed 2016-09-15
review-ietf-pce-pcep-service-aware-12-secdir-lc-huitema-2016-09-15-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 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 draft is ready.

The draft (draft-ietf-pce-pcep-service-aware-12), as the title indicates,
describes "Extensions to the Path Computation Element Communication
Protocol (PCEP) to compute service aware Label Switched Path (LSP)."
The extensions include to the path metric object and to the bandwidth 
Utilization The enable computation of latency, delay variation, packet loss 
and bandwidth utilization constraints for a path, and the selection of 
paths accordingly. The draft defines code points for various types of
computations, as well as new error types.

The security section states that these extensions do "not add any new 
security concerns beyond those discussed in [RFC5440] and [RFC5541] 
in itself." That's a true statement. This draft does not change the problem 
much, except for the addition of more and more potentially sensitive data 
in the routing messages. We could have a long and heated
discussion on the appropriateness of the mitigations described in the
security sections of these [RFC5440] and [RFC5541], such as TCP MD5, 
an optional use of IPSEC and IKE, and some forms of access control. In fact,

we could have that discussion for most routing related drafts. I am not
suggesting that we have this discussion right now.

-- Christian Huitema