Subject: Re: [Nsaas] Existing work, other things

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Sun, 7 Sep 2014 11:40:44 +0000

Hi,

I think the radical difference when considering NSaaS does not lie on the particular protocols to be used for controlling the security appliances, but with how these security virtual appliances are instantiated. We are talking about security services running in a virtualized platform not necessarily running on the user premises, so stronger a newer mechanisms to establish trust are needed.

NSaaS will need to consider at least:

1) Mechanisms for assessing the trustworthiness of the platform the virtualized security functions are going to run, including the links with them

2) Methods for querying and verifying the applicable functions to be deployed on the platform

3) Control protocols for those functions once deployed

The two first steps are essential to a virtualized environment and related to platform and function attestation. The third one is common to virtualized and not virtualized functions, though I think some aspects (scaling events, for example) could need to be considered as well in a virtualized environment.

Be goode,
On 12 Aug 2014, at 19:57 , Linda Dunbar <[email-masked]> wrote:

> 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
>
> On 8/12/14 9:08 AM, Linda Dunbar wrote:
>> 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.
>
> 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
>
>
> _______________________________________________
> Nsaas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nsaas

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Melinda Shore <[email-masked]>
Date: Sun, 07 Sep 2014 11:42:19 -0800

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.

Melinda

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 8 Sep 2014 17:09:27 +0000

Melinda,

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.

Linda

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Sunday, September 07, 2014 2:42 PM
To: DIEGO LOPEZ GARCIA; Linda Dunbar
Cc: [email-masked]
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.

Melinda

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 10 Sep 2014 18:43:27 +0000

Via the offline discussion with Melinda, I learned that many people may think that NSaaS is more like Marketing slogan. 

Since the goal is to define a common interface for network security functions (like what I2RS has done for routers), so that Service Providers or 3rd party operators can offer Network Security Functions that may not physically present in the client premises. 

Is  "I2NSF" (Open Interface to Network Security functions) a more appropriate name? Any more suggestions? 

Linda

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Sunday, September 07, 2014 2:42 PM
To: DIEGO LOPEZ GARCIA; Linda Dunbar
Cc: [email-masked]
Subject: Re: [Nsaas] Existing work, other things

Melinda

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 10 Sep 2014 20:13:20 +0000

I am aware of what NEA did (I was somehow involved with the people working there) but let me say that their problem space is different: NEA was dealing with the conditions for allowing endpoint attachment to a network, while NSaaS is intended precisely to deal with mediator (or middlebox if you like) functions. This said, it is very likely that many of the NEA results can be applicable one way or another to NSaaS, as well as many of the other results mentioned in this thread, and possibly together with others we will notice in the future.

I fully agree with your statement of trying to narrow the scope and identify the piece(s) of technical work to be solved. With that in mind I suggested the three aspects to be considered, intended as a first step to concrete the goals for a future group. For sure we need to refine them but I can tell you that we are seriously considering the provision of this kind of security services to our customers. So I guess we can consider the request to bring our "product managers" to the process fulfilled from our side...

Be goode,

Dr Diego R. Lopez
Telefonica I+D

---

From: Melinda Shore <[email-masked]>
Date: Wed, 10 Sep 2014 19:08:43 -0800

On 9/10/14 12:13 PM, DIEGO LOPEZ GARCIA wrote:
> I fully agree with your statement of trying to narrow the scope and
> identify the piece(s) of technical work to be solved. With that in
> mind I suggested the three aspects to be considered, intended as a
> first step to concrete the goals for a future group. For sure we need
> to refine them but I can tell you that we are seriously considering
> the provision of this kind of security services to our customers. So
> I guess we can consider the request to bring our "product managers"
> to the process fulfilled from our side...

Well, yes and no.

To back up a little bit, the IETF has not historically hewn to the
problem statement->framework->whatever process.  Work used to be
brought in more fully considered, and I think it does not represent
progress that we're now seeing a lot of problem statements.  To me,
it suggests that the work that's being proposed isn't really work
per se - someone's got some ideas about an interesting problem but
hasn't really worked out the details, whether the problem can (or
should) be solved in the IETF at all, and so on.  It seems to me that
from an organizational perspective, the problem statements have
turned into an unproductive time sink.  Work really needs to be
more mature before a BOF is approved.

On the other hand, people who are writing drafts and advocating
for particular pieces of work should not be in a particular hurry
to have a BOF.  It is not in the interest of people advocating a
piece of work to have an unsuccessful BOF.  It hurts your case.
Second, it's also important to keep in mind that the work of the
IETF is done primarily on mailing lists and through the document
process, not at meetings.  It's possible (and has been done a
number of times) to form a working group without ever having held
a BOF.

This is not ETSI and it's not the ITU-T.  The best way to move
work along is to have a technically credible proposal that's
reasonably mature, and to have some people who want to build it
and some other people who want to deploy it.  Support from other
people who write standards is shallow if there's no institutional
commitment to the technology on the parts of their employers.

I don't know where this cloud security stuff is going to go.  It
looks like there are a few specific technical problems that need
to be solved.  I think the best way forward it to tease out
some specific problems, and try to develop technical proposals
around those problems.  Don't rush towards a BOF but rather have
some solid, credible technical work done first.  Demonstrate that
it's a problem that needs to be solved, that the participants are
capable of solving it, that somebody's going to actually build it,
and someone else is going to actually deploy it, and your chances of
the work going forward in the IETF have just skyrocketed.

Melinda

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Sun, 28 Sep 2014 12:32:59 +0000

Hi,

This may come a little bit late for the nsaas list, so I am using the new i2nsf as well...

> more mature before a BOF is approved.

I fully agree with you. As I said, we are engaged in a project that is already producing results in the direction of NSaaS/I2NSF (whatever we call it at the end) and I saw this proposal as an interesting opportunity to standardize some of them. The problem statement->framework->whatever process may have not been the IETF style to proceed (and I praise that!) but I am afraid that this is becoming commonplace, hence my statement above...

> number of times) to form a working group without ever having held

Agreed as well. In fact, I am under the impression that a group-forming BoF at IETF91 would be premature.

> commitment to the technology on the parts of their employers.

Not sure about the ITU-T, but to be fair to ETSI I must say that their flexibility when it came to NFV was more than remarkable...

Be goode,

Dr Diego R. Lopez
Telefonica I+D