[secdir] Review of draft-ietf-sfc-architecture-08
Simon Josefsson <simon@josefsson.org> Sun, 24 May 2015 19:10 UTC
Return-Path: <simon@josefsson.org>
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 CA1681ACE15; Sun, 24 May 2015 12:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.149
X-Spam-Level: *
X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no
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 Dpi-FND8am4G; Sun, 24 May 2015 12:10:47 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 0C68F1A6F38; Sun, 24 May 2015 12:10:46 -0700 (PDT)
Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4OJAgWa021246 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 24 May 2015 21:10:43 +0200
Date: Sun, 24 May 2015 21:10:41 +0200
From: Simon Josefsson <simon@josefsson.org>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sfc-architecture.all@tools.ietf.org
Message-ID: <20150524211041.52cde768@latte.josefsson.org>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; boundary="Sig_/ptW5nbJ5JQUN/MqNhDLne=9"; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/n908r7NtoSBJiYCl38KefCKR4y4>
Subject: [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: Sun, 24 May 2015 19:10:49 -0000
Hello. 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 is an architectural document, so it doesn't have the usual security impact that you can easily review. The Security Considerations section gently refer any security considerations to the future documents that will actually realize the archicture. The security considerations that you would expect to be discussed in an architecural document are those on an architectural level. The archicture proposed here is to change how network services are delivered. The document doesn't give many examples, but my understanding is that the intended services would include firewalls, NAT, proxies, packet filtering, anti-spam measures, anti-DDOS measure, QoS, and so on. The traditional model is static services coupled to network topology and physical resource. The new model introduced by this document, as far as I understand, is a dynamic model where delivery of these services can be moved around more dynamically, by tunneling traffic to the service and back. I may have missed it, but I feel that the security consequences of moving to this new architecture is not discussed in the document. Some obvious security considerations that are introduced with an architecture like this are: 1) When delivery of a service is moved from an on-network-path machine to a machine sitting somewhere else, there ought to be some consideration to authenticating the involved entities and encrypting the traffic between them. 2) Auditing who has powers over a communication channel will be different -- before you evaluated the wires and who had access to the machines connected to the wires. Now you have to review the policies configured in the machines and what external entities are involved, together with the operational aspects of this boxes that perform the service delivery. 3) Moving traffic around raises the challenge how to achieve that without negatively affecting privacy of the traffic. 4) Protecting the SFC configuration and policies is critical for secure operations. Anyone who gains access may be able to modify traffic. If the above is a bit handwavy, allow me to be more concrete. Adding something like the following to the security considerations would at least acknowledge that there are inherent security considerations with this architecture: The architecture described here is different from the current model, and moving to the new model will lead to different security arrangements and modeling. For example, when service functions are moved from on-path static machines to dynamic remote machines, this introduce security and privacy aspects that needs to be addressed. All this said, I still would classify this document as Ready. It mostly just disappoint me that a new architecture can be introduced without containing a significant discussion of security properties. /Simon
- Re: [secdir] Review of draft-ietf-sfc-architectur… Joel M. Halpern
- [secdir] Review of draft-ietf-sfc-architecture-08 Simon Josefsson
- Re: [secdir] Review of draft-ietf-sfc-architectur… Carlos Pignataro (cpignata)
- Re: [secdir] Review of draft-ietf-sfc-architectur… Benjamin Kaduk
- Re: [secdir] Review of draft-ietf-sfc-architectur… Joel M. Halpern
- Re: [secdir] Review of draft-ietf-sfc-architectur… Carlos Pignataro (cpignata)
- Re: [secdir] Review of draft-ietf-sfc-architectur… Simon Josefsson
- Re: [secdir] Review of draft-ietf-sfc-architectur… Joel M. Halpern
- Re: [secdir] Review of draft-ietf-sfc-architectur… Stephen Farrell
- Re: [secdir] Review of draft-ietf-sfc-architectur… Joel M. Halpern
- Re: [secdir] Review of draft-ietf-sfc-architectur… Stephen Farrell
- Re: [secdir] Review of draft-ietf-sfc-architectur… Benjamin Kaduk
- Re: [secdir] Review of draft-ietf-sfc-architectur… Simon Josefsson
- Re: [secdir] Review of draft-ietf-sfc-architectur… Carlos Pignataro (cpignata)
- Re: [secdir] Review of draft-ietf-sfc-architectur… Carlos Pignataro (cpignata)
- Re: [secdir] Review of draft-ietf-sfc-architectur… Joel M. Halpern
- Re: [secdir] Review of draft-ietf-sfc-architectur… Benjamin Kaduk
- Re: [secdir] Review of draft-ietf-sfc-architectur… Carlos Pignataro (cpignata)
- Re: [secdir] Review of draft-ietf-sfc-architectur… Joel M. Halpern
- Re: [secdir] Review of draft-ietf-sfc-architectur… Benjamin Kaduk
- Re: [secdir] Review of draft-ietf-sfc-architectur… Benjamin Kaduk
- Re: [secdir] Review of draft-ietf-sfc-architectur… Carlos Pignataro (cpignata)
- Re: [secdir] Review of draft-ietf-sfc-architectur… Carlos Pignataro (cpignata)
- Re: [secdir] Review of draft-ietf-sfc-architectur… Benjamin Kaduk
- Re: [secdir] Review of draft-ietf-sfc-architectur… Carlos Pignataro (cpignata)