Last Call Review of draft-ietf-pce-hierarchy-extensions-10
review-ietf-pce-hierarchy-extensions-10-secdir-lc-rose-2019-04-15-00

Request Review of draft-ietf-pce-hierarchy-extensions
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-04-15
Requested 2019-04-01
Authors Fatai Zhang, Quintin Zhao, Oscar de Dios, R. Casellas, Daniel King
Draft last updated 2019-04-15
Completed reviews Rtgdir Last Call review of -09 by Mike McBride (diff)
Secdir Last Call review of -10 by Kyle Rose (diff)
Genart Last Call review of -10 by Roni Even (diff)
Assignment Reviewer Kyle Rose
State Completed
Review review-ietf-pce-hierarchy-extensions-10-secdir-lc-rose-2019-04-15
Reviewed rev. 10 (document currently at 11)
Review result Has Nits
Review completed: 2019-04-15

Review
review-ietf-pce-hierarchy-extensions-10-secdir-lc-rose-2019-04-15

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.

For background, Wikipedia has the following to say about PCE:

q( Routing can be subject to a set of constraints, such as Quality of Service (QoS), policy, or price. Constraint-based path computation is a strategic component of traffic engineering in MPLS, GMPLS and Segment Routing networks. It is used to determine the path through the network that traffic should follow, and provides the route for each Label Switched Path (LSP) that is set up.

Path computation has previously been performed either in a management system or at the head end of each LSP. But path computation in large, multi-domain networks may be very complex and may require more computational power and network information than is typically available at a network element, yet may still need to be more dynamic than can be provided by a management system.

Thus, a PCE is an entity capable of computing paths for a single or set of services. A PCE might be a network node, network management station, or dedicated computational platform that is resource-aware and has the ability to consider multiple constraints for sophisticated path computation. PCE applications compute label switched paths for MPLS and GMPLS traffic engineering. )

The document is nearly ready. In addition to numerous grammatical errors throughout, I see one minor but substantive issue. In section 6.1.2, the last sentence reads:

q( This means
   that a parent PCE must be configured with the identities and security
   credentials of all of its child PCEs, or there must be some form of
   shared secret that allows an unknown child PCE to be authorized by
   the parent PCE. )

A secret shared by more than two parties cannot be used to establish identity. If there are two, then assuming exfiltration and reflection attacks are not part of your threat model, each party knows it is talking to the single other legitimate possessor of the shared secret. If there are more than two, this is no longer the case. That said, in this case it's not clear you need to identify individual child PCEs, and so (notwithstanding potential impersonation attacks in a shared secret scheme) you may wish to shorten this sentence to:

q( This means that a parent PCE MUST* be able to cryptographically authenticate requests from child PCEs. )

The choice of authentication scheme can then be left to implementors, or recommendations to a different document. You might add a sentence to the security considerations section suggesting that multi-party shared key authentication schemes are not recommended for inter-domain relationships because of the potential for impersonation and repudiation and for the operational difficulties should revocation be required.

*Whether this "MUST" should be BCP 14 language or not is unclear to me.