Last Call Review of draft-ietf-pce-hierarchy-extensions-10
review-ietf-pce-hierarchy-extensions-10-secdir-lc-rose-2019-04-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.

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.