Reviewer: Dale Worley
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
Reviewer: Dale R. Worley
Review Date: 2017-07-11
IETF LC End Date: 2017-07-12
IESG Telechat date: 2017-08-03
This draft is basically ready for publication, but has nits
that should be fixed before publication.
A few of these may rise to the level of minor technical issues,
section 3.2: whether error TBA2/2 is distinct from error 1/1
section 3.2: the receipt of an PCErr during the failure of TLS
section 3.3: the distinction between StartTLSWait and OpenWait
section 5: a full discussion of backward compatibility considerations
section 8.2: MIB extension
This document describes a security container for the transport of
PCEP messages, and therefore they do not affect the flexibility and
extensibility of PCEP.
There is no plural antecedent for "they" to reference. I think you
could use "it", but the Editor may have better suggestions.
3.2. Initiating the TLS Procedures
with a PCErr message with Error-Type set to [TBA2 by IANA] (PCEP
It seems that we shouldn't use this Error-Type to object to the use of
a message other than Open and StartTLS as an initial message, as that
error isn't a misuse of StartTLS per se and is only incidentally
related to StartTLS. Indeed, isn't there already an Error-Type for
this error (unexpected initial message), since two RFC 5440
implementations can commit/detect it? Looking at RFC 5440 section
7.15, I see:
1 PCEP session establishment failure
Error-value=1: reception of an invalid Open message or
a non Open message.
It seems to me that this document is adjusting the meaning of error
1/1, rather than defining a new error situation.
If the PCEP speaker that does not support PCEPS, receives a StartTLS
message, it MUST behave according to the existing error mechanism
described in section 6.2 of [RFC5440] (in case message is received
prior to an Open message) or section 6.9 of [RFC5440] (for the case
of reception of unknown message).
I think you want s/MUST/will/, since the described behavior isn't
specified by this document, but rather by RFC 5440.
In any case, this paragraph might want to reference the
backward-compatibility consideration that I would expect to appear in
section 5 -- How does the PCEPS-supporting element deal with the
non-PCEPS-supporting element after the connection attempt with
After the exchange of startTLS messages, if a PCEP speaker cannot
establish a TLS connection for some reason (e.g. the required
mechanisms for certificate revocation checking are not available), it
MUST return a PCErr message (in clear) with Error-Type set to [TBA2
by IANA] (PCEP StartTLS failure) and Error-value set to:
Is there a well-defined way for a participant in a TLS connection
start to receive *either* a PCErr message in the clear *or* whatever
comes next in TLS setup -- and know which case has happened? Is there
a way to use popular modular TLS libraries and have the application
above the library receive such a PCErr message? I don't understand
TLS nearly well enough to know the answer to this, but it would
probably help implementors if answers were given to these questions.
The peer MAY choose to re-establish the PCEP session
without TLS next.
I think you mean "The peer that initiated the connection MAY choose to
re-establish ...". As written, "the peer" seems to refer to the peer
that generated the PCErr, but if it was the receiving peer that
generated the PCErr, you probably don't want it to attempt to
re-establish the session but rather wait for the initiating peer to do
Given the asymmetric nature of TLS for connection establishment it is
relevant to identify the roles of each of the PCEP peers in it. The
PCC SHALL act as TLS client, and the PCE SHALL act as TLS server,
according to [RFC5246].
See comments re section 4 about terminology. I think you need to have
terms for the element that is initiating the connection (either a PCC
or a PCE) and the element that is receiving the connection (always a
3.3. The StartTLS Message
Once the TCP connection has been successfully established and the
StartTLS message sent, the sender MUST start a timer called
StartTLSWait timer, after the expiration of which, if no StartTLS
message has been received, it MUST send a PCErr message and releases
the TCP connection with Error-Type set to [TBA2 by IANA] and Error-
value set to 5 (no StartTLS message received before the expiration of
the StartTLSWait timer). A RECOMMENDED value for StartTLSWait timer
is 60 seconds.
Really, the timer is the time to wait for *any* message to received.
Open messages will cause start of upward-compatibility mechanisms (if
any); any other message will be immediately rejected as an error.
Indeed, isn't there already a timer which a peer uses to wait for the
other peer to send a message? Isn't StartTLSWait functionally the
same as OpenWait (RFC 5440 section 6.2)?
... it MUST send a PCErr message and releases ...
This sentence is grammatically interesting. One part is logically "it
MUST send a PCErr message". The second part might be "it MUST release
the TCP connection", or "it releases the TCP connection". Strictly
speaking, the rules of English grammar cause the release/releases
distinction to disambiguate whether MUST applies to both parts or only
to the first part. But I don't think you want to rely on that, and
you want to say "... and MUST release the TCP connection ...".
3.4. TLS Connection Establishment
1. Immediately negotiate TLS sessions according to [RFC5246].
In this case, you'd say "Immediately negotiate a TLS session ...".
3.5. Peer Identity
At least the following parameters of the X.509 certificate SHOULD
o Peer's IP address
o Peer's fully qualified domain name (FQDN)
To the naive (me), these two items seem to refer to the TCP connection
that was established. But I suspect that they're intended to refer to
the IP address and FQDN that might be encoded in the certificate (as
in, "The following precedence applies: for DNS name validation,
subjectAltName:DNS has precedence over CN; for IP address validation,
subjectAltName:iPAddr has precedence over CN.")
And it seems that the actual remote IP address of the TCP connection
and whatever remote FQDN or IP address was used to initiate the
connection should also be exposed to the administrative system.
So I think there's room to expand on and clarify exactly the data
items that are intended here.
4. Discovery Mechanisms
A PCE can advertise its capability to support PCEPS using the IGP
advertisement and discovery mechanism.
If I understand this correctly, IGP is "Interior Gateway Protocol",
and it's a category of protocols, not a specific protocol. And what
you're saying is that a PCE can advertise using the relevant IGP's
mechanism. In that case, I think you'd say "the IGP's advertisement
and discovery mechanism". (Unless somehow IS-IS and OSPF are seen as
variants of the same protocol, which can generically be called IGP.)
capability flag bit for the PCE-CAP-FLAGS sub-TLV that can be
announced as attribute to distribute PCEP security support
information is proposed in [I-D.wu-pce-discovery-pceps-support]
s/announced as attribute/announced as an attribute/.
But you don't want to say "is proposed in ..." because that suggests
that the proposal might not be approved, and you've already positively
stated "A PCE can advertise ...". So you want to say "A new
capability flag ... is defined in ..." -- and raise
draft-wu-pce-discovery-pceps-support to a normative reference.
Similar considerations apply to discovery via DNS
(draft-wu-pce-dns-pce-discovery) -- you want to mention it here and
consider it a normative reference.
-- Unless you choose to make this part of the section clearly
hypothetical by starting "This document does not specify any method a
PCE can advertise that it supports (or requires) PCEPS, but two
mechanisms have been proposed:"
When DNS is used by a PCC (or a PCE acting as a client, for the rest
of the section, PCC refers to both) willing to use PCEPS to locate an
appropriate PCE [I-D.wu-pce-dns-pce-discovery], the PCC as an
initiating entity, chooses at least one of the returned FQDNs to
resolve, which it does by performing DNS "A" or "AAAA" lookups on the
This one sentence uses the terms "acting as a client" and "as an
initiating entity" to mean the same thing. You should fix on one
term. And given that the same concept arises in the discussion of TLS
initiation (section 3.2), you probably want to define the term for "a
PCC (or a PCE acting as a client)" near the beginning as document-wide
terminology. Once you've got names for the concepts of the initiating
entity and the receiving entity, a number of things in the document
can then be stated more clearly.
If the PCC receives a response to its SRV query but it is not able to
establish a PCEPS connection using the data received in the response,
as initiating entity it MAY fall back to lookup a PCE that uses TCP
This is unclear -- if the process of resolving the original FQDN into
addresses fails to produce an address that can be contacted, how can
the PCC "fall back to lookup a PCE that uses TCP as transport" -- it has
already done the looking up, and that failed.
I suspect you mean that the PCC is required to first attempt to
contact each address using TLS, and then only if all of those attempts
fail is it then permitted to fall back to using TCP. But you don't
actually say that.
5. Backward Compatibility
It would help if this section gave a more comprehensive discussion of
how PCEPS-supporting PCEs/PCCs and non-PCEPS-supporting PCEs/PCCs can
interwork, i.e., how to incrementally deploy PCEPS into an AS. The
two major points seem to be (1) arranging that any two elements will
communicate with the highest level of security that they both
implement, and (2) any system of PCEPS-supporting and
non-PCEPS-supporting elements can interwork successfully. There
probably are some "interesting" management and security issues
involved in this.
6.2. New Error-Values
I've noted above that the function of Error-Type=TBA2/Error-Value=2
seems to duplicate that of Error-Type=1/Error-Value=1.
The meaning of Error-Type=TBA2 is named "StartTLS Failure" here, but
the rest of the text uses "StartTLS failure". The table given in RFC
5440 section 7.15 is not consistent about capitalization in the names
of Error-Types, but most entries do not capitalize non-initial words.
That suggests "StartTLS failure" should be used here.
7. Security Considerations
There needs to be some consideration of interoperation of mixed
PCEPS-capable and non-PCEPS-capable elements (unless such mixtures are
8.1. Control of Function and Policy
A PCEP implementation SHOULD allow configuring the following PCEP
o StartTLSWait timer value
PCEPS implementations MAY provide ...
If I read this correctly, there is only one security parameter in this
list. But since the text says "the following PCEP security
parameters:", on my first reading, I assumed that "PCEPS
implementation MAY provide ..." was the beginning of a second item
(with the initial "o" omitted).
provide ways for the operator to complete the following tasks:
It looks like all of the following tasks are with regard to a selected
PCEP session, though only the first task is labeled as such, whereas
the 2nd through 4th are not. It seems like you want to say "to
complete the following tasks in regard to any PCEP session:" and
change the 1st to "Determine if the session is protected via PCEPS."
8.2. Information and Data Models
The PCEP MIB module SHOULD be extended to include PCEPS capabilities,
information, and status.
This isn't a "SHOULD" because it isn't a constraint on
implementations, it's a statement of what would be a desirable action
by the IETF. -- Unless the idea is that the implementor SHOULD add a
(necessarily proprietary) extension to the MIB. In any case, RFC 7420
should be referenced.)
8.4. Verify Correct Operations
This section title is a verb phrase while the rest of the titles are
noun phrases. Perhaps "Verification of Correct Operations".
8.5. Requirements on Other Protocols
Mechanisms defined in this document do not imply any new requirements
on other protocols.
There is a correlated discovery mechanism:
draft-wu-pce-discovery-pceps-support defines a correlated change to
OSPF and IS-IS. I suppose that isn't *required* by this document, as
draft-wu-pce-dns-pce-discovery or configuration might be used. But
conceptually, the two discovery mechanisms are implied by this
10.1. Normative References
It seems to me that draft-wu-pce-discovery-pceps-support and
draft-wu-pce-dns-pce-discovery should be considered normative