Hi All, A new version handling the RTGDIR comments is posted. https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/
See diff at - https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pceps-13 Thanks Dan for the comments. Regards, Dhruv On Thu, May 11, 2017 at 10:07 PM, Dhruv Dhody <[email protected]> wrote: > Hi Dan, > > Thanks for your review. Please see inline... > > > -----Original Message----- > > From: Pce [mailto:[email protected]] On Behalf Of Dan Frost > > Sent: 11 May 2017 19:01 > > To: [email protected] > > Cc: [email protected]; [email protected]; [email protected] > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/pce >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
