[Pce] Review of draft-ietf-pce-stateful-sync-optimizations-09

[Daniel Franke <[e-mail]>]

Reviewer: Daniel Franke
Review result: Has Issues

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

I believe this document is READY WITH a minor ISSUE addressed below.
The Security Considerations section of this document, along with its
companion draft-ietf-pce-stateful-pce-18, appears to do a thorough job
of enumerating the ways in which the newly-introduced message types
can contribute to the ability of misbehaving PCCs and PCEs to disrupt
each other, with consequences that generally strike me as acceptable.
It duly recommends that PCEP be run over an authenticated channel to
prevent these messages from being spoofed by a third party.

I am unsure how this final recommendation is going to be implemented
in practice. RFC 5440 characterizes channel security for PCEP as a
work-in-progress as of 2009, and I lack sufficient familiarity with
this area to know if the status quo has improved since then in
practice. The TCP authentication option, cited in RFC 5440 as WIP, is
now RFC 5925, but I don't know whether anyone actually uses it for
this application. TLS is mentioned as another alternative, but
existing standards documents give insufficient instruction on how to
implement this interoperably, since there is no mention of port
allocations, a STARTTLS scheme, an ALPN identification sequence, or
anything else that would explain how to go about initiating the TLS
session. It looks like draft-ietf-pce-pceps intends to rectify this.

Addressing whatever deficiencies exist in PCEP security mechanisms
obviously falls well outside the scope of this particular document to
address. Even if the administrator fails to provide channel security
for PCEP as recommended, adding support for stateful sync
optimizations will not leave the network meaningfully worse-off than
it was already. However -- and here's the ISSUE -- as Alvaro Retana
already sort of touched on, the introduction of the Speaker Entity ID
TLV means that implementation of stateful sync optimizations can't be
entirely agnostic with respect to the choice of channel security
mechanism. Implementations need to verify that the Speaker Entity ID
is consistent with the cryptographic identity of the channel peer in
order to prevent one PCC from spoofing the identity of another. Until
PCEP channel security matures a bit I'm not how much concrete advice
we can give implementers on how to do this properly, but somewhere in
the document there should at least be an observation that this check
should be present.

I also second Retana's desire for greater consistency between this
document, draft-ietf-pce-stateful-pce, and RFC 5440 as to which
channel security mechanisms are recommended and/or required.

PS - sorry about the last minute review.