[secdir] Secdir telechat review of draft-ietf-sfc-nsh-25

Christian Huitema <huitema@huitema.net> Thu, 28 September 2017 19:42 UTC

Return-Path: <huitema@huitema.net>
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 4CE571348BF; Thu, 28 Sep 2017 12:42:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Christian Huitema <huitema@huitema.net>
To: secdir@ietf.org
Cc: ietf@ietf.org, sfc@ietf.org, draft-ietf-sfc-nsh.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150662776428.27730.5006539542253170142@ietfa.amsl.com>
Date: Thu, 28 Sep 2017 12:42:44 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/DDXHXVJOEz6oUPFjjJdNX2SLn7c>
Subject: [secdir] Secdir telechat review of draft-ietf-sfc-nsh-25
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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, 28 Sep 2017 19:42:44 -0000

Reviewer: Christian Huitema
Review result: Serious Issues

I have already reviewed previous iterations of this draft (18) and sent
comments on the mailing lists about revisions 20 to 24. The draft has
significantly improved through the revisions, but I still have concerns.

First, it should be clear that standardizing addition of metadata to packet
headers is, from a privacy standpoint, playing with fire. I understand that
many ISP believe that they need to accumulate and use metadata in order to
compete with the large scale tracking performed by some web companies. This
existing competition may well be driving a race to the privacy bottom.
Regardless, the minimum these ISP can do is ensure that the privacy sensitive
metadata that they collect is well protected. Collecting metadata is bad
enough; letting hackers access it would be disastrous, as shown in the Equifax
breach. I would like to see a stronger recognition in the security
consideration that this is indeed playing with fire.

I am also concerned that when writing the security considerations the authors
may be playing with words. Frankly, I do not believe that the data will be
magically protected because they are only transported in a single
administrative domain. As Randy Bush pointed out in an email comment, some of
the service functions are already provided "in the cloud" by third party
contractors to the ISP. This means that in practice, the data will probably not
be confined to a single provider domain. In the email, I listed three threats:

* Whether ISP believe it or not, their links will be snooped by third parties.
We have to assume that adversaries will have access to some of the transmission
equipment, even inside the perimeter.

* We also have to assume that persistent attackers will be able to compromise
some of the devices hosting some of the functions.

* And we have to assume that some third party providers will re-purpose the
metadata that they obtain through various contracts.

What worries me is not so much the inadequacies of the defenses proposed in the
security section as the absence of emphasis on the need to actually deploy
these defenses. Everything seems to be optional, left to the good will of the
ISP. Experience shows that in these conditions deployments use the most
convenient setup, clear text transmission with little defense in depth. The
security section ends up being so much empty talk designed to placate security
reviewers, playing with words for security without recognizing that
standardizing metadata collection is playing with fire.