Last Call Review of draft-ietf-pce-stateful-sync-optimizations-09
review-ietf-pce-stateful-sync-optimizations-09-secdir-lc-franke-2017-03-15-00

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.