[Nsaas] Comparing the IETF existing SACM work with NSaaS

Linda Dunbar <linda.dunbar@huawei.com> Mon, 08 September 2014 17:10 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 68B321A894E for <nsaas@ietfa.amsl.com>; Mon, 8 Sep 2014 10:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.852
X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id b4MQj5HR35o9 for <nsaas@ietfa.amsl.com>; Mon, 8 Sep 2014 10:10:18 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6431A8908 for <nsaas@ietf.org>; Mon, 8 Sep 2014 10:09:34 -0700 (PDT)
Received: from (EHLO lhreml402-hub.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJE85063; Mon, 08 Sep 2014 17:09:32 +0000 (GMT)
Received: from DFWEML706-CHM.china.huawei.com ( by lhreml402-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Mon, 8 Sep 2014 18:09:32 +0100
Received: from DFWEML701-CHM.china.huawei.com ([]) by dfweml706-chm ([]) with mapi id 14.03.0158.001; Mon, 8 Sep 2014 10:09:28 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Melinda Shore <melinda.shore@gmail.com>, DIEGO LOPEZ GARCIA <diego.r.lopez@telefonica.com>
Thread-Topic: Comparing the IETF existing SACM work with NSaaS
Thread-Index: AQHPy4elmZSgxWVzWkmc5KmqKII7Gg==
Date: Mon, 8 Sep 2014 17:09:27 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645DE7E4A@dfweml701-chm>
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> <4A95BA014132FF49AE685FAB4B9F17F645DB2420@dfweml701-chm.china.huawei.com> <53EA4704.2090401@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645DB2460@dfweml701-chm.china.huawei.com> <53EA4D5E.70303@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645DB24CD@dfweml701-chm.china.huawei.com> <F786A82C-976A-44F5-8832-ACA12CD2477B@telefonica.com> <540CB51B.7010204@gmail.com>
In-Reply-To: <540CB51B.7010204@gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645DE7E4Adfweml701chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/nsaas/d8AYOAGzAbpUCgsXTThmd2uVYPc
Cc: "nsaas@ietf.org" <nsaas@ietf.org>
Subject: [Nsaas] Comparing the IETF existing SACM work with NSaaS
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: Mon, 08 Sep 2014 17:10:22 -0000


During NSaaS informal gathering in 90th IETF, it was brought up that there might be some  work done by SACM that can be used by NSaaS. We did some study, and here is the comparison:

SACM: Security Assessment of End Points:
•       End points can be routers, switches, clustered DB, installed piece of software
•       How to encode policies in a manner where assessment can be automated
•       Example:
o       a Solaris 10 SPARC or Window 7 system used in a environment that requires adherence to a policy of Mission Critical Classified.
o       rules like "The maximum password age must be 30 days" and "The minimum password age must be 1 day"

NSaaS: Network Security as a Service (about the interface)
•       Protocols for clients to request/query/verify Security related functions from Network Providers
o       Firewall
o       DDOS/Anti-DOS
o       Access control/Authorization/Authentication
o       Secure Key management
o       Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)
o       Threat detection: Eavesdropping, Trojans, viruses and worms, Malware, etc.
•       Example:
o       vCPE needs vFW that are hosted in the network.
o       vCPE provides the “Group Policies” for the vFW, like A can talk to B & C, but B can’t talk to C.

Appreciate more comments and suggestions.


-----Original Message-----
From: Melinda Shore [mailto:melinda.shore@gmail.com]
Sent: Sunday, September 07, 2014 2:42 PM
Cc: nsaas@ietf.org
Subject: Re: [Nsaas] Existing work, other things

Again, there's been work done in the IETF on some of this (for example, network endpoint assessment (http://datatracker.ietf.org/wg/nea/charter/),
tunnel endpoint discovery, ipsp, and so on.  I think my more general concern is that recently there's been a great deal of work being brought into the IETF that's not product-driven and doesn't have "organic"
support, and it turns out to chew up a lot of IETF resources and frustrate the heck out of its proponents.  No technical work comes out of it and nobody's happy.  Because it's not product-driven there tends not to be a clear, existing framework to slip it into along with real-world requirements and expectations for how it might work.
I don't think the problem statement/framework/requirements process that's developed is working well for the organization, IETF participants, or the industry, and I think that it might be time to take lessons learned about process and apply them here.

That is to say, rather than getting mired in the same old unsuccessful process, it might be a better idea to identify a narrowly-scoped piece of work that *needs* to be done and focus on that.  Talk to product people before bringing a proposal in and asking for a BOF.  I tend to see this effort as going the way of the "cloud" effort, and so on, but it's early enough that it doesn't have to proceed down that same path.  Talk to product people *NOW*, and identify why this work belongs in the IETF.  It should never be the case that the problem you're trying to solve is how to create an IETF working group, but rather how to accomplish a specific piece of technical work that improves networks and networking.

That is to say, talk to people who build products and talk to people who run networks, see what they need.  Bring your product managers into the process.