Subject: [Nsaas] Existing work, other things

From: Melinda Shore <[email-masked]>
Date: Mon, 11 Aug 2014 18:36:37 -0800

I was a little (okay, a lot) surprised to see this work
proposed without referencing prior IETF work in this space,
including (but not limited to) midcom, nsis, and pcp.
Ideally any new work proposed on this topic would include
an explanation of why it would succeed where previous
efforts haven't.  It's certainly possible that this might
succeed where others have failed, but some explanation
of why its proponents think this time things are different
would be helpful.  Some discussion of what distinguishes
"security" from other service functions would also be useful.

Also, the open source vs. standards discussion is overly
argumentative and likely to produce more heat than light,
and fails to acknowledge the complementary nature of the
two types of effort.  We certainly do not need more
unimplemented standards (see previous paragraph).

Melinda

---

From: Zongning <[email-masked]>
Date: Tue, 12 Aug 2014 02:45:45 +0000

Hi, Melinda,

I agree that clearly listing existing work in IETF and making a check list on gap would be very helpful for this initiative.
I guess Linda can post a brief summary of bar BoF discussion in Toronto to enlight us more...

Thanks.

-Ning

-----邮件原件-----
发件人: Nsaas [mailto:[email-masked]] 代表 Melinda Shore
发送时间: 2014年8月12日 10:37
收件人: [email-masked]
主题: [Nsaas] Existing work, other things

I was a little (okay, a lot) surprised to see this work proposed without referencing prior IETF work in this space, including (but not limited to) midcom, nsis, and pcp.
Ideally any new work proposed on this topic would include an explanation of why it would succeed where previous efforts haven't.  It's certainly possible that this might succeed where others have failed, but some explanation of why its proponents think this time things are different would be helpful.  Some discussion of what distinguishes "security" from other service functions would also be useful.

Also, the open source vs. standards discussion is overly argumentative and likely to produce more heat than light, and fails to acknowledge the complementary nature of the two types of effort.  We certainly do not need more unimplemented standards (see previous paragraph).

Melinda

_______________________________________________
Nsaas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsaas

---

From: Melinda Shore <[email-masked]>
Date: Mon, 11 Aug 2014 19:01:11 -0800

On 8/11/14 6:45 PM, Zongning wrote:
> I agree that clearly listing existing work in IETF and making a check
> list on gap would be very helpful for this initiative.

I think that what really needs to be addressed is that these previous
efforts have been unsuccessful.  If the OpenStack project is seeing
uptake, that's a big deal.

Melinda

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 12 Aug 2014 15:56:19 +0000

Melinda, 

You have brought up a very important aspect of NSaaS that needs to be addressed. 

OpenStack completed the Firewall as a Service project and specified the set of APIs for Firewall services: http://docs.openstack.org/admin-guide-cloud/content/fwaas_api_abstractions.html

OpenStack has also defined the APIs for managing Security Groups: http://docs.openstack.org/admin-guide-cloud/content/securitygroup_api_abstractions.html. 

In addition, there is a "Security as a service by Cloud Security Alliance (": https://cloudsecurityalliance.org/research/secaas/#_get-involved 
SaaS by CSA is at the initial stage of defining the scope of work.

OpenStack, as it is an open source community, its contributions are like IETF's individual submissions. While IETF's individual submissions require some levels of expert review before RFC can be published, OpenStack doesn't have this system. Basically, it is not required to have validation on correctness and completeness of the submissions. 

As the result, the attributes defined by OpenStack Firewall/Security as a Service are very primitive, e.g. only say "firewall rules" without explicit specification of what. In addition, 

One of the goals of NSaaS in IETF is to create a productive eco-system with OpenStack and other Open Source communities, with IETF defining specifications/protocols, Open Source communities contributing source code based on IETF initial specifications (potentially with enhancement), which in turn augment IETF specification, and then back to Open Source communities. 

The NSaaS can start with will the OpenStack defined interface, and move on to make them more complete and useable.  

Linda

-----Original Message-----
From: Nsaas [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Monday, August 11, 2014 10:01 PM
To: Zongning; [email-masked]
Subject: Re: [Nsaas] 答复: Existing work, other things

> list on gap would be very helpful for this initiative.

I think that what really needs to be addressed is that these previous efforts have been unsuccessful.  If the OpenStack project is seeing uptake, that's a big deal.

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Tue, 12 Aug 2014 08:20:14 -0800

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.

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

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?

Melinda

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 12 Aug 2014 16:51:17 +0000

Melinda, 

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

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Tuesday, August 12, 2014 11:20 AM
To: Linda Dunbar; [email-masked]
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:

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

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

[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

---

From: Melinda Shore <[email-masked]>
Date: Tue, 12 Aug 2014 08:55:32 -0800

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.

Melinda

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 12 Aug 2014 17:08:50 +0000

Melinda, 

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. 

Linda

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Tuesday, August 12, 2014 11:56 AM
To: Linda Dunbar; [email-masked]
Subject: Re: [Nsaas] 答复: Existing work, other things

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Tue, 12 Aug 2014 09:22:38 -0800

> 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).
We pretty clearly do not want to sink time and effort into yet
another unimplemented protocol.

Melinda

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 12 Aug 2014 17:57:44 +0000

Melinda, 

Answers are inserted below:

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Tuesday, August 12, 2014 12:23 PM
To: Linda Dunbar; [email-masked]
Subject: Re: [Nsaas] 答复: Existing work, other things

> 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

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 15 Aug 2014 21:19:37 +0000

Melinda,

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

Linda

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Tuesday, August 12, 2014 11:56 AM
To: Linda Dunbar; [email-masked]
Subject: Re: [Nsaas] 答复: Existing work, other things

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Fri, 15 Aug 2014 19:43:36 -0800

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

---

From: Linda Dunbar <[email-masked]>
Date: Sat, 16 Aug 2014 13:24:57 +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.

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:[email-masked]] 
Sent: Friday, August 15, 2014 10:44 PM
To: Linda Dunbar; [email-masked]
Subject: Re: Comparing NSIS and the work to be done by NSaaS

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

---

From: Melinda Shore <[email-masked]>
Date: Sat, 16 Aug 2014 10:06:25 -0800

On 8/16/14 5:24 AM, Linda Dunbar wrote:
> 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).

You might want to check out the midcom protocol semantics RFC.

Melinda