Re: [secdir] Review of draft-ietf-sfc-architecture-08
Benjamin Kaduk <kaduk@MIT.EDU> Mon, 01 June 2015 17:29 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 D07331B2F80; Mon, 1 Jun 2015 10:29:47 -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 gKMtLfGnHMUX; Mon, 1 Jun 2015 10:29:43 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF78E1B2F8C; Mon, 1 Jun 2015 10:29:42 -0700 (PDT)
X-AuditID: 12074423-f79496d000000d43-b6-556c96853581
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id EA.55.03395.5869C655; Mon, 1 Jun 2015 13:29:41 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t51HTeCV008714; Mon, 1 Jun 2015 13:29:40 -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 t51HTbIg011132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Jun 2015 13:29:38 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t51HTaqi003812; Mon, 1 Jun 2015 13:29:36 -0400 (EDT)
Date: Mon, 01 Jun 2015 13:29:36 -0400
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
In-Reply-To: <5C38EDAD-2CAC-485B-B488-51819FAAFC81@cisco.com>
Message-ID: <alpine.GSO.1.10.1506011324460.22210@multics.mit.edu>
References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> <alpine.GSO.1.10.1505252257290.22210@multics.mit.edu> <2DB7995B-8AF1-4EEE-971E-40A1A6294461@cisco.com> <alpine.GSO.1.10.1505261917240.22210@multics.mit.edu> <53F5D306-5860-4415-8AA4-390882ED94AB@cisco.com> <alpine.GSO.1.10.1505271355150.22210@multics.mit.edu> <F5E7E866-FB1C-48C0-8306-33579AE856CB@cisco.com> <alpine.GSO.1.10.1505280005040.22210@multics.mit.edu> <5C38EDAD-2CAC-485B-B488-51819FAAFC81@cisco.com>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-568848066-1433179776=:22210"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsUixG6nots6LSfUYOF0VYtP73awWNz4dJvZ YsaficwWHxY+ZLG4t+USuwOrx5TfG1k9liz5yeQx88xFdo8vlz+zBbBEcdmkpOZklqUW6dsl cGVsW7GFtWCWSsWOJYuZGxgvy3QxcnJICJhIXH3xmQXCFpO4cG89WxcjF4eQwGImiY3HNrNC OBsYJaZvn8oM4Rxkkrj46D4TSIuQQL3E31UtYO0sAloSTW9XgNlsAioSM99sZAOxRQTMJBof T2ICaWYWeMIocbrvCGMXIweHsICdxPcJKiA1nAK2Ei1vpoDV8wo4Ssyb8YYdYlkHi8StSy2M IAlRAR2J1funsEAUCUqcnPkEzGYWCJD4M+UF2wRGwVlIUrOQpCBsdYnGB2ehbG2J+zfb2BYw sqxilE3JrdLNTczMKU5N1i1OTszLSy3SNdPLzSzRS00p3cQIjgcX5R2Mfw4qHWIU4GBU4uHN 6M4OFWJNLCuuzD3EKMnBpCTKazApJ1SILyk/pTIjsTgjvqg0J7X4EKMEB7OSCK9sE1CONyWx siq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mCN3AqUKNgUWp6akVaZk4JQpqJ gxNkOA/Q8BiQGt7igsTc4sx0iPwpRkUpcV5BkIQASCKjNA+uF5auXjGKA70izJsMUsUDTHVw 3a+ABjMBDW4XABtckoiQkmpgNDnN/jtINXN31M+FUnP6GbIVxZsyvlbyzQtcrr3+y9UuGQ1J 2TPXYh34eb6Xf2u24dO4+82V4Wu3mZ9Iqf+upEWBU4t4r/xfKVQ4+8BTQbVPV6tfabb6hEzv Cbr+PvMF36UPcYyX7X4ESaclGcsFL5AMP5V58lXxcSkll0SVjavjsjk3SAQosRRnJBpqMRcV JwIAa7LzBDIDAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/9RbLxUaK-po7kU-eJueuI8Ozsjk>
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: Mon, 01 Jun 2015 17:29:48 -0000
Hi Carlos, Sorry for the delayed reply. On Thu, 28 May 2015, Carlos Pignataro (cpignata) wrote: > Ben, > > > On May 28, 2015, at 12:24 AM, Benjamin Kaduk <kaduk@MIT.EDU> wrote: > > > > On Wed, 27 May 2015, Carlos Pignataro (cpignata) wrote: > > > >> Ben, > >> > >>> On May 27, 2015, at 2:16 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote: > >> > >> What changes the flow of data in the network (i.e., direct user traffic > >> to the ‘remote machine’ (as you called it) is the overlay — that is why > >> in the “Service Overlay” section of the Security Considerations we have: > >> > >> and can also include authenticity and integrity checking, and/or > >> confidentiality provisions. > >> > >> The use of the SFC Encapsulation is for SFP encapsulation and metadata sharing. > > > > Now that you have pointed me at it, I do see how you feel that the issue > > is already covered. Let me see if I have any suggestions for new text > > that would not have required you to point me at it in order for me to see > > it. > > > > OK. > > > One thing that comes to mind would be to add a clause at the end of the > > sentence to reiterate what data is being protected. It is late here, so I > > have confused myself as to whether that should be "for both the traffic > > being forwarded and its encapsulation" or just "for the traffic being > > forwarded”. > > I can add “, for both the network overlay transport and traffic it > encapsulates” at the end of that sentence? Or "for both the traffic > being forwarded and its encapsulation” as well. I thought this was > understood, however. I think that either of those would improve the clarity, thank you. > > It seems like it would also be helpful to spend another clause or sentence > > expounding how the security requirements of the specific SFC deployment > > are determined -- perhaps, "These security requirements will depend both > > on the structure of the network where SFC is being deployed and the > > details of the protocol implementing the SFC architecture; the security > > assessment should consider potential threats from both inside and outside > > the network." That's probably overkill, but is perhaps illustrative. > > To me, it is closer to overkill, but I would not oppose if you very > strongly feel it adds value, even if merely illustrative. I do not feel very strongly. This was just me attempting to brainstorm for places that new text could have made the document more clear; I wanted to include some concrete text as part of the brainstorming, to help make clear my thought process. I was definitely not expecting you to include the whole thing verbatim -- maybe some pieces of it, or maybe none of it at all, if you don't think it is needed (which seems to be the case). > >>>> “Reevaluated” is significantly better, of course. Here’s another proposal: > >>>> > >>>> "The architecture described here is different from the current model, and > >>>> moving to the new model could lead to different security arrangements and > >>>> modeling. In the SFC architecture, a relatively static topologically-dependent > >>>> deployment model is replaced with the chaining of sets of service functions. > >>>> This can change the flow of data through the network, and the security and > >>>> privacy considerations of the protocol and deployment will need to be > >>>> reevaluated in light of the model.” > >>> > >>> I might add in "new" or "chained" before the very last "model", but this > >>> seems to catch the sentiment I was going for. > >> > >> Either ‘chain’ or ‘new’ univocally disambiguates ‘model’ — sure. > >> > >>> The idea would be to insert > >>> this as a new paragraph after the first paragraph of section 6? > >>> > >> > >> Yes, or as the first paragraph of Section 6, as a preamble to the section. Either. > > > > Sounds good. > > Done. Thanks. Thanks for all these updates; I think they go a long way to addressing the concerns that were raised during the secdir review. -Ben
- 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)