[Nsaas] Comparing the IETF existing SACM work with NSaaS

[Linda Dunbar <[e-mail]>]

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:[e-mail]]
Sent: Sunday, September 07, 2014 2:42 PM
To: DIEGO LOPEZ GARCIA; Linda Dunbar
Cc: [e-mail]
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