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

Linda Dunbar <linda.dunbar@huawei.com> Sat, 16 August 2014 13:25 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 A0E5F1A879A for <nsaas@ietfa.amsl.com>; Sat, 16 Aug 2014 06:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.869
X-Spam-Level:
X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 n5YB0ND1sS9G for <nsaas@ietfa.amsl.com>; Sat, 16 Aug 2014 06:25:15 -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 C89301A8795 for <nsaas@ietf.org>; Sat, 16 Aug 2014 06:25:14 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIH65734; Sat, 16 Aug 2014 13:25:13 +0000 (GMT)
Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 16 Aug 2014 14:25:12 +0100
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm.china.huawei.com ([169.254.4.217]) with mapi id 14.03.0158.001; Sat, 16 Aug 2014 06:24:58 -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+CUUkiepBZ4APAupJvTDEAAgAAmWaA=
Date: Sat, 16 Aug 2014 13:24:57 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645DB5837@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> <4A95BA014132FF49AE685FAB4B9F17F645DB5514@dfweml701-chm.china.huawei.com> <53EED368.20305@gmail.com>
In-Reply-To: <53EED368.20305@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.148.89]
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/_j62Hto3pg211prYayH2JflVbU0
Subject: Re: [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: Sat, 16 Aug 2014 13:25:19 -0000

Melinda, 

Thanks for the additional analysis of NSIS. 

You said " NSIS provides a signaling *model*" that the industry didn't find it useful. 

Let's look at the recent strong industry initiative: NFV (with 38 operators participating and wanting the service). In order for NFV to be deployed in network, it is very essential to have common protocols for "Controller (or Orchestrator)" to 

- create client specific Virtual Firewall with the needed rules & policies over physical appliances from different vendors, very much how routers being partitioned for VPNs.

- 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.

Take Firewall as an example, the rules for a specific client vFW can include:
- a 5-tuple and an action such as allow or deny. The information contained in the tuple
includes source/destination IP addresses, transport protocol, and source/destination port numbers (RFC5973).

- The policy rules also require order context. Since firewalls operate in a top-down first-match order, a set of policy rules without order context is insufficient (new).

- The RFC5973’s definition implicitly assumes that the firewall has the intelligence to recognize related traffic that may not match the original 5-tuple. The perfect example is FTP, which consists of control and data connections. The firewall needs to recognize and permit the data connection which isn’t defined in the original rule, which covers only the control channel. (The actual process is a bit more complicated—depending on whether it’s active or passive mode FTP).

Most, if not all, firewalls today have protocol-specific ALGs (app layer gateways) that support more complicated protocols like FTP and SIP. NSIS is to remove the need of ALG (RFC5973). NSaaS is to develop a protocol to ALG. 

The protocol semantics should at least include "request from client to provider", "negotiation of the supported rules between provider and clients", and "verify". 

It is also necessary to have common representation for vFW. Very much like VPN Identifier. 

Linda

-----Original Message-----
From: Melinda Shore [mailto:melinda.shore@gmail.com] 
Sent: Friday, August 15, 2014 10:44 PM
To: Linda Dunbar; nsaas@ietf.org
Subject: Re: Comparing NSIS and the work to be done by NSaaS

On 8/15/14 1:19 PM, Linda Dunbar wrote:
> - Differences between NSIS and NSaaS:

I think the most salient issue is that because NSIS is path-coupled, it's possible to message every participating device along a path without having to know its location, or its location relative to other devices (this is particularly a pressing issue when you've got one or more NATs present in the network, or when trying to locate appropriate tunnel endpoints).  NSIS provides a signaling *model* that may or may not be useful.  I'd say that industry did not find it useful except that other security device signaling models haven't been implemented and deployed, either, so the issue appears to be with the general class of solution rather than with this individual, particular solution.


Getting these questions answered is not a hoop to jump through, but rather, I think, a very serious issue with the work going forward.

Melinda