[secdir] SECDIR review of draft-ietf-sfc-nsh-18

Christian Huitema <huitema@huitema.net> Fri, 11 August 2017 22:21 UTC

Return-Path: <huitema@huitema.net>
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 8A7BE1326AC for <secdir@ietfa.amsl.com>; Fri, 11 Aug 2017 15:21:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id U79_JwbdOZCW for <secdir@ietfa.amsl.com>; Fri, 11 Aug 2017 15:21:12 -0700 (PDT)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99CA1326AE for <secdir@ietf.org>; Fri, 11 Aug 2017 15:21:10 -0700 (PDT)
Received: from xsmtp06.mail2web.com ([]) by mx3.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1dgIIh-0003Gf-3m for secdir@ietf.org; Sat, 12 Aug 2017 00:21:09 +0200
Received: from [] (helo=xmail05.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1dgIIc-0008Is-U8 for secdir@ietf.org; Fri, 11 Aug 2017 18:21:00 -0400
Received: (qmail 14990 invoked from network); 11 Aug 2017 22:20:57 -0000
Received: from unknown (HELO []) (Authenticated-user:_huitema@huitema.net@[]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <ietf@ietf.org>; 11 Aug 2017 22:20:57 -0000
From: Christian Huitema <huitema@huitema.net>
To: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-sfc-nsh.all@ietf.org
Cc: IETF Discussion Mailing List <ietf@ietf.org>
Message-ID: <2ad0274f-3385-136d-794b-082192393ebf@huitema.net>
Date: Fri, 11 Aug 2017 15:20:53 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SpamExperts-Domain: xsmtpout.mail2web.com
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.19)
X-Recommended-Action: accept
X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJackVDEeh/s63C3hq8BP19aND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23Et8EmwAEDHt/bpQlSQ4WzenAK+xr92ZGK1ua sQ+8Dmh3cwQzo/7QWl8r4aborZJuYOEkjsX7F8KmpUaZQHV+ST61TfxIvi8LwOTvVrRIhaC2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpIuW2VxLnS94njDgTNmyTXH6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyb5pE1hv2y98CU17gG3OzcHeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj237jnExji3pN9ZwHGBHd3j58WezJa7xDQcOg5ET5/LmCvakjSWDcjZyDseb0cBFM1p7J 0ZI2Cud2W8ULqpclZpX6+ln3SmdyWNNJvR4I+Hp8ZTqmtKYOlQxywq7X9AiLTGikfdoogjfTpZPs zrPFazX6bpsmzT5sWVD4sfkDnyejRRklgDtVC2Xqa4QCRhTuoCmXPUJkXUk8tGhJsBnmMDbaKcNO SCytRyeT1c4b6jF7f/DKzfOCXnJQjcl9DhaIFtwGXh1z3jjhvha4XAPJdhEh0i13zjCiwPgdt77s k1WBMw==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/UWlAaJ2nbqrSaecrXKCm7h_Br3w>
Subject: [secdir] SECDIR review of draft-ietf-sfc-nsh-18
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 11 Aug 2017 22:21:13 -0000

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.

The summary of this review is a puzzled reviewer. Why was I asked to 
review this? Why is the IETF even working on such specifications? What
does this have to do with the Internet? And why such disregard
for privacy and security? In any case, this document has significant
issues. It does not explaining where exactly the proposed Network
Service Header would be inserted (MPLS or IPv6?). The security
provisions boil down to lip-service mentions of IPSEC, and that's way
insufficient given the nature of the protocol.

Sometimes you read a document and it gives you a glimpse of an alternate
universe in which the Internet has been replaced by a mad pile-up of
middle boxes. Of course, they will not be called that. Instead, we will
speak of "service functions" providing such essential features as NAT
and deep packet inspection. I suppose that censorship and surveillance
are not desirable key words in marketing brochures, and that metadata
collection and the insertion of adverts are better described in yet to
be published extensions.

As far as I can tell, the so called "Service Function Chaining
Architecture" tries to standardize this pile-up of middleboxes, so that
service providers can procure them from multiple vendors. The draft that
I am reviewing, draft-ietf-sfc-nsh-18, defines a clear-text "network
service header" (NSH) that would inserted between the "transport" used
in the domain and the IPv4 or IPv6 packet itself. Boxes could look at
this header, add metadata to it, and forward it to other boxes along a
"service path". I mentioned IPv4 or IPv6, but there are also provisions
for passing pure NSH information, probably for maintaining the "service
path", or passing Ethernet, MPLS or experimental frames, because why not.

The specification itself is appropriately baroque, with the header
composed of three components and multiple options, but the basic idea is
to allow different boxes to see the packet so they can read, update and
process the metadata. As far as I can tell, there are no serious attempt
to provide any kind of security or privacy protection except maybe some
basic ingress filtering, which means that the metadata can be observed
by any entity able to tap the path, or can be spoofed by any system
inserted on the path, such as for example a virus infected box. The only
security reference is a short note that deployments "could use IPSEC",
through a token reference to RFC 6071.

When first reading the document, I was under the impression that the
"transport" used in the domain would be some kind of close layer 2
system, MPLS or maybe Ethernet. That would give some assurance that the
collection of middle boxes would be part of a somewhat controlled
domain. It was only the reference to IPSEC that enlightened me. If IPSEC
is plausible, it probably means that the packet would be composed of an
IP header, the SFH, and the original IP payload. So the proposed usage
implies carrying metadata like subscriber information and identification
of content in clear text  over long distance paths. What could possibly
go wrong? And if that was not enough, imagine what an adversary could
achieve by spoofing the service packets.

Of course, the same threats would still apply if the protocol was
strictly carried over layer 2, as several adversaries are quite capable
of snooping and spoofing layer 2 traffic.

Coming at the end of this review, I hesitate between two options. One
would be to just express my disgust, wash my hands, and hope that the
effort will fail under its own weight, maybe after a couple of
catastrophic security failures. The other option is to provide some
advice on how to solve the most blatant issues. In a spirit of
cooperation, I choose the latter, and here is the two steps advice:

The first step to better security and privacy there would be to present
the practical deployment conditions. I could only make guesses, and
that's silly. There should be some kind of diagram explaining how the
SFH is inserted in packets, and where it sits between Ethernet, MPLS and

The next step is to develop a protection model. Given that the goal of
the architecture is to decorate the packets with sensitive metadata,
there need to be some thinking about who should be able to see it. How
would path encryption like IPSEC be deployed? Should all elements on
path really be able to access all metadata, or should some of it be
further protected?

Please fix that before the document is published.

Christian Huitema