Reviewer: Russ Mundy
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.

Document: draft-ietf-mpls-sfc-04
Reviewer: Russ Mundy
Review Date: 2019-01-30
IETF LC End Date: 2019-01-31

Summary:

This document defines defines a methods to achieve Service Function Chaining (SFC) using Network Service Header (NSH) in Multiprotocol Label Switching (MPLS) networks.  An architecture for SFC is defined in RFC7665 and NSH is defined in RFC8300.

This document has issues that should be addressed before it is ready to be published as a Proposed Standard.

Issues:

First, the document and in particular the Security Considerations section points to published RFCs for discussions of the security properties. In particular, RFC7665 and RFC8300 are referenced however each of these documents left some significant security descriptions & definitions to be addressed by implementation documents such as this one.  Additionally, the SECDIR reviews of the IDs prior to publication of these RFCs point out several security related issues that, as far as I could tell, were primarily addressed by saying that future implementation specifications will address them.  Since this ID is such an implementation specification, referring to the earlier RFCs for the security properties results in essentially no security properties provided in either the earlier RFCs or this  implementation document - security properties need to be identified avoided via circular referendes.

Next, the Security Considerations section identifies that the certain elements of the design must be a ‘trusted resource’ and that some functions must also be trusted.  The term “trusted” in relationship to computing and software has a wide range of different meanings (as shown by many years of research in the CS field).  In the context of this document, my guess is that it means that some unidentified (but not defined) entity believes (“trusts”) that the software will do the “right thing” - to me (from a security perspective) it also means trusting that the software will not do the wrong thing.  All of this is very abstract (both the Security Considerations text & this critique) which in my view is why the 'trust' section is very inadequate for an implementation document.

Additionally, the last paragraph of the Security Considerations section asserts:

Thus the security vulnerabilities are addressed (or should be
  addressed) in all the underlying technologies used by this design,
  which itself does not introduce any new security vulnerabilities.

As far as I could see, the assertion is not supported anywhere in the document itself or other referenced documents, i.e., what vulnerabilities should the implementation be concerned with (e.g. passive monitoring, active attacks on metadata, etc??) that result from this implementation.  Since the document does not provide a clear identification of it's security requirement, any security services it does (or might) provide nor require from underlying technologies, the assertion should be clarified, supported by additional information or removed from the section.