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

[Dan Frost <[e-mail]>]

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