[mpls] Secdir last call review of draft-ietf-mpls-flow-ident-06

Daniel Franke <dafranke@akamai.com> Wed, 10 January 2018 21:36 UTC

Return-Path: <dafranke@akamai.com>
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E21AC12E03B; Wed, 10 Jan 2018 13:36:50 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Daniel Franke <dafranke@akamai.com>
To: <secdir@ietf.org>
Cc: draft-ietf-mpls-flow-ident.all@ietf.org, ietf@ietf.org, mpls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.68.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151562021088.5645.6014648171409606834@ietfa.amsl.com>
Date: Wed, 10 Jan 2018 13:36:50 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/_KAf5vbZiLq7Jf_oHTQYIRgehjo>
Subject: [mpls] Secdir last call review of draft-ietf-mpls-flow-ident-06
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jan 2018 21:36:51 -0000

Reviewer: Daniel Franke
Review result: Has Nits

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

I know next to nothing about MPLS. The proposed functionality seems reasonable
and persuasively justified, but it is possible that there are significant
issues I'm overlooking. I have a couple nitpicks about the Security
Considerations section.

The lowercased (i.e., non-RFC-2119) "must"s and "should"s are weasel words when
not connected with a statement of what objective is achieved by following those
recommendations. For example, the sentence "Propagation of identification
information outside the MPLS network imposing it must be disabled by default"
ought to be prefaced or suffixed with something along the lines of "In order to
preserve present assumptions about MPLS privacy properties".

I see a lot of discussion about confidentiality concerns when flow information
is propagated across trust boundaries, but no discussion about the dual
integrity concerns. I suggest including some word of warning that flow
information received from an untrusted LSR cannot be assumed correct, so
caution is advised before relying on it, e.g., to determine for billing
purposes whether SLAs are being met.