Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-pce-pceps-12 Reviewer: Dan Frost Review Date: 2017-05-11 IETF LC End Date: Intended Status: Standards Track Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Comments: This document proposes to add a STARTTLS mechanism to the PCE protocol. If this basic approach is accepted, then the document is in good shape. It's clear, complete, and straightforward. The question is whether mandating STARTTLS is actually a good idea. Major Issues: My main concern with this document is that it takes as given that STARTTLS is the right way to secure PCEP with TLS. Perhaps this argument was already had at some point and this draft is the result, but if so then at a bare minimum it needs rationale explaining why STARTTLS was chosen over alternatives, and text that addresses weaknesses and mitigations associated with STARTTLS processing, in particular the possibility and relative ease of downgrade attacks. The obvious alternative would be to not use STARTTLS and simply allocate another TCP port for PCEP-over-TLS. This avoids complicating the PCE protocol and introducing the potential for downgrade attacks based on STARTTLS. PCE is used to convey critical path-determination information in carrier networks, among other things. That it's not fully authenticated and encrypted in all cases already is an unfortunate legacy of a bygone era. Ideally operators should move as quickly as possible to secure PCEP and aim to entirely remove the unsecure form. STARTTLS serves a weaker goal of "opportunistic" security, which, while it has its uses, makes little sense for PCE compared to simply deprecating the unsecured version. Minor Issues: * Section 3.3: "A RECOMMENDED value for StartTLSWait timer is 60 seconds." This seems like a very long time to wait for an initial reply on an already-established TCP connection. * Section 3.2, fifth paragraph (beginning with "A PCEP speaker receiving..."): This paragraph states: "A PCEP speaker receiving any other message apart from StartTLS, open, or PCErr MUST treat it as an unexpected message..." As written this is confusing and seems to imply that no other PCEP messages can ever be sent. It looks like this is meant to be scoped to the context of the first message sent/received on session initiation? * Section 8.6 The subsection titles of Section 8 have been taken from Section 8 of RFC 5440, but Section 8.6 here is called "Impact on Network Operations" while in RFC 5440 it's called "Impact on Network Operation". Funnily enough, that final "s" makes a difference. Without it, the section refers to an impact on the functioning of the network itself. With it, it would usually be taken to refer to impact on human operations and management procedures. It looks correct to say that the mechanism of this draft should not significantly impact the functioning of the network. On the other hand, it certainly does impact operations and management procedures, as staff have to develop policies around security requirements for PCEP within the organization, methods for verifying whether device security parameters are configured correctly, checking for unexpected downgrades to insecure sessions, etc. It would be an improvement for the document to address the impact of PCEPS on operational processes. Nits: Sec 3.1, first paragraph: OLD The steps involved in the PCEPS establishment consists of following successive steps: NEW The steps involved in establishing a PCEPS session are as follows: END Sec 3.4, Step 3: s/Any attempt of initiate a TLS/Any attempt to initiate a TLS/ Cheers, -d