Re: [secdir] Review of draft-ietf-sfc-architecture-08

Benjamin Kaduk <kaduk@MIT.EDU> Tue, 26 May 2015 03:02 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F12C1AD2F2; Mon, 25 May 2015 20:02:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Level:
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 3V8zSDm73_KO; Mon, 25 May 2015 20:02:04 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C939F1AD2EE; Mon, 25 May 2015 20:02:03 -0700 (PDT)
X-AuditID: 1209190c-f792b6d000000d1f-8c-5563e22aefd8
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 9A.62.03359.A22E3655; Mon, 25 May 2015 23:02:02 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t4Q321nJ019832; Mon, 25 May 2015 23:02:01 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4Q31wmc019916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 May 2015 23:02:00 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t4Q31v6L006861; Mon, 25 May 2015 23:01:57 -0400 (EDT)
Date: Mon, 25 May 2015 23:01:57 -0400
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
In-Reply-To: <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com>
Message-ID: <alpine.GSO.1.10.1505252257290.22210@multics.mit.edu>
References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IRYrdT19V6lBxqsOikssWndztYLG58us1s MePPRGaLDwsfsljc23KJ3YHVY8rvjaweS5b8ZPKYeeYiu8eXy5/ZAliiuGxSUnMyy1KL9O0S uDKeL9jNWHCZu2LBzf0sDYwnOLsYOTkkBEwktsw+ygZhi0lcuLceyObiEBJYzCRxruEgI0hC SGAjo0TDcSGIxCEmiWvvV7FDJBoYJU6cEwSxWQS0JV7OPwLWwCagIjHzzUawqSICZhKNjycx gTQzCzxhlDjdB1LEwSEsYCfxfYIKSA2ngK3E2mWrmUFsXgFHiW2t/1gh5mdJzO+eAhYXFdCR WL1/CgtEjaDEyZlPwGxmAS2J5dO3sUxgFJyFJDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8 vNQiXUO93MwSvdSU0k2MoNDmlOTZwfjmoNIhRgEORiUeXovDyaFCrIllxZW5hxglOZiURHlZ rwGF+JLyUyozEosz4otKc1KLDzFKcDArifDOvQuU401JrKxKLcqHSUlzsCiJ8276wRciJJCe WJKanZpakFoEk5Xh4FCS4N3wAKhRsCg1PbUiLTOnBCHNxMEJMpwHaPhqkBre4oLE3OLMdIj8 KUZFKXHeRSAJAZBERmkeXC8s9bxiFAd6RZh3JUgVDzBtwXW/AhrMBDT4SnMiyOCSRISUVANj lqP3/or/E/8kufKzHuRZt+qzVJXXitcsJfWrJ9dsnL7647HAp+enfVp4bI/GyyUfUoMDBFR3 Msg4T+laf2DDzxSX0997JsccXRX3wz5wz5QAZybhMONE9v6sxNM266aFves7+fX++fvtqzed XREarcp2IJ79sOvcCYe/lGpLctXOfhwq+uKUgxJLcUaioRZzUXEiAMbqa08YAwAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/XmyyNUV0mZ94Yost3oFzyawob4A>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-sfc-architecture.all@tools.ietf.org" <draft-ietf-sfc-architecture.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 26 May 2015 03:02:09 -0000

On Sun, 24 May 2015, Carlos Pignataro (cpignata) wrote:

> It is true that this new architecture introduces a model in which there
> is a more dynamic service application, decoupling it from network
> topology path; however, there is no administrative domain changes or
> admin fragmentation. In other words, taking it very concrete, there is
> no change in expectations regarding for example encryption. The service
> is potentially applied in another part of the network and a chain can be
> created dynamically, but all within the same admin domain as before.

As I attemted to say in my secdir review of the sfc-problem-statement
document
(http://www.ietf.org/mail-archive/web/secdir/current/msg05351.html), it is
not clear that being within the same administrative domain excuses one
from considering whether encryption is necessary.  I seem to recall that,
e.g., Google is encrypting all inter-datacenter traffic (I don't remember
about intra-datacenter traffic, though).

I do not think it is realistic to think that one can protect a network at
the boundary -- there are always ways for sufficiently advanced attackers
to get in, and some form of defense in depth is needed.  Now, I grant that
encryption may not always be needed, and it is not the place of SFC to
insist that encryption always be used, but please do not claim that being
in a single administrative domain excuses the operator from considering
whether encryption is necessary.

-Ben Kaduk