[Nsaas] Comparing NSIS and the work to be done by NSaaS

Linda Dunbar <linda.dunbar@huawei.com> Fri, 15 August 2014 21:20 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 D808E1A066D for <nsaas@ietfa.amsl.com>; Fri, 15 Aug 2014 14:20:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.868
X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2hU5th0t8YEo for <nsaas@ietfa.amsl.com>; Fri, 15 Aug 2014 14:19:53 -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 C7CA31A066F for <nsaas@ietf.org>; Fri, 15 Aug 2014 14:19:52 -0700 (PDT)
Received: from (EHLO lhreml404-hub.china.huawei.com) ([]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLH79162; Fri, 15 Aug 2014 21:19:51 +0000 (GMT)
Received: from DFWEML703-CHM.china.huawei.com ( by lhreml404-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Fri, 15 Aug 2014 22:19:49 +0100
Received: from DFWEML701-CHM.china.huawei.com ([]) by dfweml703-chm.china.huawei.com ([]) with mapi id 14.03.0158.001; Fri, 15 Aug 2014 14:19:37 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Melinda Shore <melinda.shore@gmail.com>, "nsaas@ietf.org" <nsaas@ietf.org>
Thread-Topic: Comparing NSIS and the work to be done by NSaaS
Thread-Index: AQHPuM6emKLMM+CUUkiepBZ4APAupA==
Date: Fri, 15 Aug 2014 21:19:37 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645DB5514@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> <4A95BA014132FF49AE685FAB4B9F17F645DB2420@dfweml701-chm.china.huawei.com> <53EA4704.2090401@gmail.com>
In-Reply-To: <53EA4704.2090401@gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645DB5514dfweml701chmchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/nsaas/pOLXqkEcxN7UNepA1laxUlP38TU
Subject: [Nsaas] Comparing NSIS and the work to be done by 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: Fri, 15 Aug 2014 21:20:02 -0000


Thank you for listing those related exiting work by IETF for NSaaS. I did some study on NSIS. Here is my finding, please let me know if my findings miss anything:

- Differences between NSIS and NSaaS:

      NSIS is for standardizing an IP signaling protocol (RSVP) along data path for end points to request its unique QoS characteristics, unique FW policies or NAT needs (RFC5973) that are different from the FW/NAT original setting. The requests are communicated directly to the FW/NAT devices. NSIS is like east-west protocols that requires all involved devices to fully comply to make it work.

      NSaaS has three potential aspects:
      - Define the standard mechanisms for clients (applications) to request/negotiate/validate security functions that are not physically located on the local premises. It is more than SFC that treats all “Functions” as black box. NSaaS is targeted to define the semantics (the actual rules & policies) of the security functions needed and the negotiation scheme.  The requests don’t usually goes to FW devices, but instead to controller that can disseminate to the involved devices in the interface that they support.

      - Define the mechanism for formulating virtual security functions on physical appliances ( in a similar way to how VPN virtualizes the carrier network)

      - Specify concrete rules (policies or attributes) for instantiating VMs for virtual security functions (NFV initiative).   This is on the service fulfillment side.

- Why we believe NSaaS has higher chance to be deployed than NSIS:

1.      OpenStack already has preliminary implementation, but the specification is not complete. IETF can play an active role to make the specification complete. Extend what OpenStack has to a more comprehensive specifications that can meet operators requirement, and then have operators encourage their suppliers to contribute open source per IETF specifications to the OpenStack community. As the software development cycle: Architecture, Design specification, and coding: IETF can take the ownership of the first two steps.

2.      The requests are to controllers, instead of to devices. It doesn’t require all middle boxes to be changed to make it work. The security can be better controlled by the controllers.

3.      There is very strong momentum to make virtualized network functions to be deployed by operators (NFV initiative).


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

On 8/12/14 8:51 AM, Linda Dunbar wrote:
> [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.

midcom, nsis, pcp, (arguably) SOCKS.