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

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Thu, 07 September 2017 16:06 UTC

Return-Path: <cpignata@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08993132F49; Thu, 7 Sep 2017 09:06:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knhwMPO9LMo6; Thu, 7 Sep 2017 09:06:03 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC35132ECA; Thu, 7 Sep 2017 09:06:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13100; q=dns/txt; s=iport; t=1504800363; x=1506009963; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qpEdPNwYpHK3eFolOsMc4dBkbzyJYMqZLYyK1AEwnEM=; b=VHnxSVGoYle6RFjYkQsZ/4ee/SD+EdUEGuKsOZ7tQgK1HANCmuTm1xdh MIQnRuBESr4KVFZ9BsVWBbFwwmcynwIcO17jsjfxnOwmGVi1bmgkzjw/t q2DJnNdZk5SXAaEalRl5SKFgd2SPnTaiNqu1bi8wgj5zFnktEwCFeNq2n c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AQCDbbFZ/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbicHg3CKIZAggU8id5UxghIKJYUZAhqDaT8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQECAQwXETMEBAoFCwIBCBIGAgImAgICMBUCDgIEDgUbig4IEK06g?= =?us-ascii?q?ieLRQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ2CHYICgU6BYysLgWVYNYMmgSg?= =?us-ascii?q?ngxMwgjEFiX+JEIUliEACh1mMdoIThWeDfoZ5iXyLAgIRGQGBOAEfOIENdxVbA?= =?us-ascii?q?YcIdohJgTKBDwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,359,1500940800"; d="scan'208";a="482739075"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2017 16:06:02 +0000
Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v87G61W2015763 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Sep 2017 16:06:02 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 7 Sep 2017 12:06:01 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1263.000; Thu, 7 Sep 2017 12:06:01 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Christian Huitema <huitema@huitema.net>
CC: The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-sfc-nsh.all@ietf.org" <draft-ietf-sfc-nsh.all@ietf.org>, "IETF Discussion Mailing List" <ietf@ietf.org>
Thread-Topic: SECDIR review of draft-ietf-sfc-nsh-18
Thread-Index: AQHTEvC/pwAKmK7nuE+363G/TDu7PaKqA5CA
Date: Thu, 7 Sep 2017 16:06:00 +0000
Message-ID: <C53DE35A-4043-46A5-8525-FF273F205971@cisco.com>
References: <2ad0274f-3385-136d-794b-082192393ebf@huitema.net>
In-Reply-To: <2ad0274f-3385-136d-794b-082192393ebf@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.116.133]
Content-Type: text/plain; charset="utf-8"
Content-ID: <665FCFB3124B2B4C802FA976B54D1E56@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/rvSHPq-zJTlfZv2sXxvwUMd0iaQ>
Subject: Re: [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: Thu, 07 Sep 2017 16:06:06 -0000

Christian,

Thanks for taking time to review this document. The net-result of addressing them will be an improved specification.

We took some additional time before responding, because some of your comments are very likely addressed (or partially addressed at least) in the current revision -20. 

You raise some very general broadly-scoped questions, such as “Why is the IETF even working on such specifications?” Those are probably beyond the scope of a SecDir review, but nonetheless, important LC comments. As those are beyond the technology specifics of draft-ietf-sfc-nsh, I can (and I do) share my perspective, but I will let others (responsible AD, sfc chairs, doc shepherd) add on more authoritatively.

Please find some responses and observations inline.

> On Aug 11, 2017, at 6:20 PM, Christian Huitema <huitema@huitema.net> wrote:
> 
> 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?

The direct answer to that question is because there is an IETF WG chartered to do so.

There is a contract (borrowing BCP 25’s definition of “Charter”) between the Service Function Chaining (sfc) working group and the IETF to work on such specs.

https://datatracker.ietf.org/wg/sfc/about/

From that contract, deliverables #1 and #2 are fulfilled as RFC 7498 and RFC 7665, respectively. The spec draft-ietf-sfc-nsh is the SFC WG target for deliverable #3, “Generic SFC Encapsulation”.

But, if you knew all this, I am not sure what is the question behind your question… 

I can offer that there’s market demand for interoperable implementations of service function chaining solutions...

> What
> does this have to do with the Internet?

I’ll just share that, just like RFC 7665, this specification narrowscopes itself to a single provider’s operational domain. 

Relevant text from revision -20, that was not there on the revision -18 you reviewed, includes:

   The intended scope of the NSH is for use within a single provider's
   operational domain.  This deployment scope is deliberately
   constrained, as explained also in [RFC7665], and limited to a single
   network administrative domain.  In this context, a "domain" is a set
   of network entities within a single administration.  For example, a
   network administrative domain can include a single data center, a
   campus physical network, or an overlay domain using virtual
   connections and tunnels.  A corollary is that a network
   administrative domain has a well defined perimeter.

> 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?).

This is another good comment, we believe is already addressed in rev -20 with the additions to the Introduction and Figure 1, among others.

> The security
> provisions boil down to lip-service mentions of IPSEC, and that's way
> insufficient given the nature of the protocol.
> 

More below.

> 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.
> 

Do these comments target the sfc charter, RFC 7498, or RFC 7665?

> 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.

I agree with the fact that draft-ietf-sfc-nsh-18 left much assumed in the Security Considerations section.

One such assumptions is that the security considerations of RFC 7665 apply to this document. In particular, the “SFC Encapsulation” heading of https://tools.ietf.org/html/rfc7665#section-6, which was worked with the Security ADs.

Revision -20 is a first take at correcting that assumption and corresponding omissions:
https://www.ietf.org/rfcdiff?url1=draft-ietf-sfc-nsh-18&url2=draft-ietf-sfc-nsh-20#diff0125

> 
> 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.

It is constrained to a single admin domain not because of the underlying technology of choice (IP vs. MPLS vs. Ethernet), but rather by deployment and applicability considerations.
>  

> 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.

No. Although that was carrying over from RFC 7665, we are making it clear and explicit in the document. MPLS or Ethernet or something “close layer 2 system” would not give those assurances. It is an applicability.

> 
> 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.

I believe one source of confusion here is the extrapolation of carrying privacy-sensitive metadata across the Internet. That is not the case.

The so-called "RFC 7665" defined the applicability scope, but we the NSH specification has failed to make that clear. This is a good point, and one that needs text changes. We took initial steps in -20 to correct that and be clear and explicit.

> 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
> IP.
> 
> 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.
> 

A lot of this conversation is déjà vu of the RFC 7665 WG, LC, and ballot discussions. Those discussions resulted in significant work with the Security ADs, security-focused SFC experts, and SFC-focused security experts; those in turn are codified in the text of RFC 7665’s security considerations.

> 
> -- 
> Christian Huitema
> 

Best,

—
Carlos Pignataro, carlos@cisco.com

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."


>