Last Call Review of draft-ietf-mpls-sfc-04
review-ietf-mpls-sfc-04-secdir-lc-mundy-2019-01-30-00

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.