Re: [Nsaas] Existing work, other things

DIEGO LOPEZ GARCIA <> Sun, 07 September 2014 11:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CD6501A0267 for <>; Sun, 7 Sep 2014 04:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.853
X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yd5KXWK7Bj7L for <>; Sun, 7 Sep 2014 04:40:50 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 227A31A0204 for <>; Sun, 7 Sep 2014 04:40:49 -0700 (PDT)
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 8C35D2D01C8; Sun, 7 Sep 2014 13:40:46 +0200 (CEST)
Received: from (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 731CA2D011E; Sun, 7 Sep 2014 13:40:46 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Sun, 7 Sep 2014 13:40:45 +0200
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1024.12; Sun, 7 Sep 2014 11:40:44 +0000
Received: from ([]) by ([]) with mapi id 15.00.1024.012; Sun, 7 Sep 2014 11:40:44 +0000
To: Linda Dunbar <>
Thread-Topic: [Nsaas] Existing work, other things
Thread-Index: AQHPypCPySVSqwQ6nUK+NTz8crQ5YQ==
Date: Sun, 7 Sep 2014 11:40:44 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;
x-forefront-prvs: 0327618309
x-forefront-antispam-report: SFV:NSPM; SFS:(10019017)(6009001)(24454002)(199003)(13464003)(189002)(51704005)(377454003)(479174003)(252514010)(99396002)(86362001)(46102001)(92726001)(92566001)(54356999)(76176999)(95666004)(50986999)(83716003)(79102001)(2656002)(80022001)(64706001)(20776003)(81542001)(66066001)(81342001)(31966008)(97736003)(76482001)(15975445006)(82746002)(74662001)(106116001)(74502001)(105586002)(106356001)(19580395003)(19580405001)(83322001)(107046002)(15202345003)(36756003)(110136001)(87936001)(85852003)(33656002)(101416001)(83072002)(77982001)(21056001)(4396001)(85306004)(93886004)(90102001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR06MB252;; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: Melinda Shore <>, "" <>
Subject: Re: [Nsaas] Existing work, other things
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "*NSaaS: Network Security as a Service mailing list*" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 07 Sep 2014 11:40:54 -0000


I think the radical difference when considering NSaaS does not lie on the particular protocols to be used for controlling the security appliances, but with how these security virtual appliances are instantiated. We are talking about security services running in a virtualized platform not necessarily running on the user premises, so stronger a newer mechanisms to establish trust are needed.

NSaaS will need to consider at least:

1) Mechanisms for assessing the trustworthiness of the platform the virtualized security functions are going to run, including the links with them

2) Methods for querying and verifying the applicable functions to be deployed on the platform

3) Control protocols for those functions once deployed

The two first steps are essential to a virtualized environment and related to platform and function attestation. The third one is common to virtualized and not virtualized functions, though I think some aspects (scaling events, for example) could need to be considered as well in a virtualized environment.

Be goode,
On 12 Aug 2014, at 19:57 , Linda Dunbar <> wrote:

> Melinda,
> Answers are inserted below:
> -----Original Message-----
> From: Melinda Shore []
> Sent: Tuesday, August 12, 2014 12:23 PM
> To: Linda Dunbar;
> Subject: Re: [Nsaas] 答复: Existing work, other things
> On 8/12/14 9:08 AM, Linda Dunbar wrote:
>> Thank you for the listing. There is also SACM.
>> I will include those IETF initiatives in the existing work of IETF. Gap analysis will be needed.
> I think a gap analysis is premature, given the lack of a sense of overall direction.  And my question really is *not* about why these protocols may not be applicable.  My question is why you feel that new work would be successful given the lack of implementation and deployment of previous efforts (and also given that OpenStack has an implementation of their own design).
> [Linda] There is already wide acceptance of security functions that are not running on customer/enterprise premises. Numerous security vendors are now leveraging cloud based models to deliver security solutions. According to [Gartner-2013], the demand for cloud-based security services is growing. Small and medium-sized businesses (SMBs) are increasingly adopting cloud-based security services to replace on-premises security tools, while larger enterprises are deploying a mix of traditional and cloud-based security services.
> In addition, NSaaS is very different from all those listed initiatives.
> There are three aspects to NSaaS:
> - Define the mechanism for creating virtual security functions on physical appliances,
> - Specify concrete rules (or attributes) for instantiating VMs for virtual security functions (NFV initiative), and
> - Define the mechanisms for clients (applications) to request/negotiate/validate security functions that are not physically located on the local premises.
> All those aspects share a common need: Attributes for the needed virtual security functions, the request/negotiate mechanism for virtual functions (on physical appliances, from remote domains, or others).
> Linda
> _______________________________________________
> Nsaas mailing list

"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

Tel:    +34 913 129 041
Mobile: +34 682 051 091


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição