[secdir] Secdir last call review of draft-ietf-mpls-sfl-framework-08

Tero Kivinen via Datatracker <noreply@ietf.org> Thu, 02 July 2020 22:30 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D4D3A0C53; Thu, 2 Jul 2020 15:30:25 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Tero Kivinen via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: mpls@ietf.org, last-call@ietf.org, draft-ietf-mpls-sfl-framework.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.7.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159372902558.22641.8459872357136850825@ietfa.amsl.com>
Reply-To: Tero Kivinen <kivinen@iki.fi>
Date: Thu, 02 Jul 2020 15:30:25 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/LOwWeXPmkue_ZBcDhAyMpFNT9w4>
Subject: [secdir] Secdir last call review of draft-ietf-mpls-sfl-framework-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 02 Jul 2020 22:30:26 -0000

Reviewer: Tero Kivinen
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.

This document describes a way to make synonyms for MPLS flows so those
flows can be processed differently. It does include privacy considerations
which says that depending on how the synonyms are used there might
be privacy issues. 

It does claim in the security considerations section that there is no new
security issues associated with the MPLS dataplane. I think that is not true.
If there is any kind of different processing depending which synonym
is used that can be used to bypass that processing by using the another
synonym instead of the intended one. For example if attacker knows 
that specific synonym causes deep packet inspection (one of the examples
given), and he might want to use the synonym which bypasses this 
inspection, in case he is sending things he does not want to be 
inspected. This could be some kind of malicious code somehow
loaded to the sending device or something.

On the other hand my understanding that trust model of MPLS
is mostly we blindly trust everything other end says, so someone
able to use different synonyms are most likely also able to do 
other even worse things, but I think there are new things caused
by this addition than what is already present in the MPLS now.