[secdir] secdir last call review of draft-ietf-mpls-sfc-04

Russ Mundy <mundy@tislabs.com> Wed, 30 January 2019 22:10 UTC

Return-Path: <mundy@tislabs.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 66B02130EB2; Wed, 30 Jan 2019 14:10:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8Y1eT2X6_V-D; Wed, 30 Jan 2019 14:10:41 -0800 (PST)
Received: from walnut.tislabs.com (walnut.tislabs.com []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8FB1130EBD; Wed, 30 Jan 2019 14:10:40 -0800 (PST)
Received: from nova.tislabs.com (unknown []) by walnut.tislabs.com (Postfix) with ESMTP id AAF6F28B0043; Wed, 30 Jan 2019 17:10:39 -0500 (EST)
Received: from [] (nova.tislabs.com []) by nova.tislabs.com (Postfix) with ESMTP id 740FA1F804E; Wed, 30 Jan 2019 17:10:39 -0500 (EST)
From: Russ Mundy <mundy@tislabs.com>
Content-Type: text/plain; charset=utf-8
X-Mao-Original-Outgoing-Id: 570579038.0771509-849baa518c5707c2f5c8c95ed554aaa0
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <5920C065-DDDB-4C1A-83FB-E0436C467D3B@tislabs.com>
Date: Wed, 30 Jan 2019 17:10:39 -0500
Cc: Russ Mundy <mundy@tislabs.com>, draft-ietf-mpls-sfc.all@ietf.org, ietf@ietf.org
To: secdir@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Ai_M4Pdve9Gy3BoyUdu4QWrho-k>
Subject: [secdir] secdir last call review of draft-ietf-mpls-sfc-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jan 2019 22:10:42 -0000

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


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.


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.