Reviewer: Kyle Rose Review result: Has Nits 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.
