Re: [Nsaas] 答复: Existing work, other things

Linda Dunbar <linda.dunbar@huawei.com> Tue, 12 August 2014 16:51 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: nsaas@ietfa.amsl.com
Delivered-To: nsaas@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9201A030B for <nsaas@ietfa.amsl.com>; Tue, 12 Aug 2014 09:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.569
X-Spam-Level:
X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 WH1SbJBLNX5I for <nsaas@ietfa.amsl.com>; Tue, 12 Aug 2014 09:51:24 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494221A0302 for <nsaas@ietf.org>; Tue, 12 Aug 2014 09:51:24 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIE21979; Tue, 12 Aug 2014 16:51:22 +0000 (GMT)
Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Aug 2014 17:51:20 +0100
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Tue, 12 Aug 2014 09:51:17 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Melinda Shore <melinda.shore@gmail.com>, "nsaas@ietf.org" <nsaas@ietf.org>
Thread-Topic: =?utf-8?B?W05zYWFzXSDnrZTlpI06ICBFeGlzdGluZyB3b3JrLCBvdGhlciB0aGluZ3M=?=
Thread-Index: AQHPtdma4rlWSy/aBkSWnwoV1iexc5vMvPyAgABc2FCAAIJpAP//i1lA
Date: Tue, 12 Aug 2014 16:51:17 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645DB2420@dfweml701-chm.china.huawei.com>
References: <53E97DB5.3040106@gmail.com> <B0D29E0424F2DE47A0B36779EC666779661978DE@nkgeml501-mbs.china.huawei.com> <53E98377.1030902@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645DB236D@dfweml701-chm.china.huawei.com> <53EA3EBE.50200@gmail.com>
In-Reply-To: <53EA3EBE.50200@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.144.204]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/nsaas/uGprjz3g3MUbTjpy2z3an-6bxG4
Subject: Re: [Nsaas] =?utf-8?b?562U5aSNOiAgRXhpc3Rpbmcgd29yaywgb3RoZXIgdGhp?= =?utf-8?q?ngs?=
X-BeenThere: nsaas@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "*NSaaS: Network Security as a Service mailing list*" <nsaas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsaas>, <mailto:nsaas-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsaas/>
List-Post: <mailto:nsaas@ietf.org>
List-Help: <mailto:nsaas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsaas>, <mailto:nsaas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Aug 2014 16:51:27 -0000

Melinda, 

Thanks for the suggested wording for IETF. 
Answers to your other questions are inserted below:

-----Original Message-----
From: Melinda Shore [mailto:melinda.shore@gmail.com] 
Sent: Tuesday, August 12, 2014 11:20 AM
To: Linda Dunbar; nsaas@ietf.org
Subject: Re: [Nsaas] 答复: Existing work, other things

I'm finding the discussion to be a little bit difficult to follow, to be honest.  Maybe it would be helpful to break things down
point-by-point:

1) The IETF has had considerable experience standardizing
   protocols between some sort of agent or controller and a
   network security device.  These have largely been
   unsuccessful, in the sense that they haven't been implemented
   and deployed.  I think any new effort in this area needs
   to make a case for why it will be successful, given that
   history.

[Linda] I've seen IETF work on general control <-> agent, but not specifically to Security functions, like FW policies, negotiations, and validations of security functions that are not physically located in the customer premises but accessed via remotely. 
There are many network functions being deployed and new ones are popping up with business and application demands. It is difficult specify concrete protocols for all network functions. Just to specify FW files alone is a big task. 

NSaaS focuses on the network security related functions because the 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. This shift has occurred for a variety of reasons including greater economies of scale, streamlined delivery mechanisms, and the demand of business and applications for more sophisticated security functions that they do not have. Consumers, enterprise clients as well as applications are embracing the business model of requesting for security functions that do not run on their own premises on demand, also known as Security as a Service.


2) If OpenStack is producing work that's being implemented,
   that's a good thing.  It is unclear to me why you would
   bring work "fixing" shortcomings in OpenStack to the IETF,
   rather than to OpenStack

[Linda] Apology for my improper wording. I didn't mean to "fix shortcomings of OpenStack". I want to advocate a productive eco-system for IETF to be plugged in to this uptrend Open Source initiatives in our industry. IETF can play a very active role in this initiative, e.g. leveraging its experience in specifying comprehensive specification that can be used as input to Open Source communities. 



3) I'm not at all clear on why this work is not being discussed
   in the context of sfc, while we're at it.  Why would it not
   fit there - that is to say, why is it a different problem?

[Linda] SFC doesn't cover in-depth specification (e.g. rules for the requested FW) for clients to request its needed functions. In SFC, FW function is a black box, that is treated in same way as Video Optimization function. SFC doesn't cover the negotiation part, e.g. Client needs Rule x/y/z for FW, but the Provider can only offer x/z. 

 
Melinda