Re: [Pce] RtgDir review: draft-ietf-pce-pceps-12

Hi Dan, 

Thanks for your review. Please see inline... 

> -----Original Message-----
> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dan Frost
> Sent: 11 May 2017 19:01
> To: rtg-ads@ietf.org
> Cc: rtg-dir@ietf.org; draft-ietf-pce-pceps.all@ietf.org; pce@ietf.org
> Subject: [Pce] RtgDir review: draft-ietf-pce-pceps-12
> 
> 
> 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.
> 
[Dhruv] Yes, this has been discussed in the WG. 
The individual draft in fact asked for another port no, and during the WG adoption process, it was discussed in the WG as well as with security experts, and concluded that we should use STARTTLS. 
As far as I am aware, use of different port for secured version of a protocol has not been followed by IETF for some time now.   

> 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.
> 
[Dhruv] I see the benefit of adding text, something in line of - 

"As per the recommendation from [RFC7525], PCEP peers that support PCEPS, SHOULD prefer strict TLS configuration i.e. do not allow non-TLS PCEP sessions to be established."

I will discuss further with my co-authors/chairs/AD, if we also need to spell out the full rationale here.  

> 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.
> 
[Dhruv] We saw a benefit in keeping this same as the OpenWait time in the PCEP session establishment.  

> * 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?
> 
[Dhruv] Yes. I will add clarification that this is for the first message. 

> * 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.
> 
[Dhruv] Agreed. I will work on text in this section, along these lines. 

> Nits:
[Dhruv] Ack for all. 

Thanks for your review. 

Regards,
Dhruv

> 
> 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
> 
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce