Subject: Re: [I2nsf] Is it possible to normalize some basic configurable objects for Flow Based Security Functions? (was: RE: Many aspects are needed to seamlessly integrate vNSF to network

From: "Dacheng Zhang" <[email-masked]>
Date: Wed, 04 Mar 2015 00:22:24 +0800

Maybe it is important for us to discuss how the different security functions
could be presented in a unique way in our work so as not to cause
confusions. 

发件人:  Linda Dunbar <[email-masked]>
日期:  2015年2月28日 星期六 上午2:32
至:  Yoav Nir <[email-masked]>, "[email-masked]" <[email-masked]>,
Edward Lopez <[email-masked]>
主题:  [I2nsf] Is it possible to normalize some basic configurable objects
for Flow Based Security Functions? (was: RE: Many aspects are needed to
seamlessly integrate vNSF to network

Through our 9-vendor joined Service Graph Forwarding Proof of Concept
project for NFV-ONF, we learned that each security function vendor has to
register its security functions & capability to the Network Operator
Management System in order to achieve the desired result for the use case
described by draft-pastor-i2nsf-access-usecases. Actually there are three
interfaces needed: 

 
Interface A: 
For Security Function vendor to register their available security functions
& instances, and set of policies (or policy profiles) that can be
dynamically set by Operators (e.g. Operator’s OSS or management system).
- vNSF manager could be vendor specific. Vendor A could provide 10 NSF,
Vendor B could provide 5 NSF.  They need a common mechanism to inform the
Network Operator Mgmt Sys what they offer and what attributes (or profile)
that can be dynamically configurable or monitored
Interface B: 
For Operator Management system to configure the profiles/attributes that
have been registered by Security Function Vendor.
 
Interface C:
For App Gateway or Clients to express and monitor security policies for
their specific flows, which is security service oriented.

Since different vendors have different features for their security
functions, can we use the following table to normalize the configurable
attributes or profile of Flow Based Security Functions ? (i.e. the security
functions that apply security policies to packets flows traversing through.
)
 
Attribute Object (potentially IANA registered) Actions CRUD Description
Vendor 
SF Name 
 SF Type 
Configurable Flow  Based Security PoliciesLayer 2Layer 3, TCP/UDP layerHTTP
LayerPass/drop/mirror/Statistics (report  Destination)Function call
(IPS/IDS/AV/URL filter/…)Name-value pairs that describe Service capability,
or the URL of a Heat template that describes the SF.
Time: Start/end/duration
Zone( corresponding header bits in the packets) Service layer attributes
Tenant ID(corresponding header bits in the packets)
Application ID (corresponding header bits in the packets)
IETF PCP? TCP/UDP port Open/Close
IETF TRAM 
Mgmt Address MAC/IPv4/IPv6 Management address for SF

Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Saturday, February 14, 2015 6:03 AM
To: [email-masked]
Subject: Re: [I2nsf] Many aspects are needed to seamlessly integrate vNSF to
network (was RE: [Newsletter] Re: I2NSF charter for IESG Review

Hi

I agree with Ed that this statement is problematic: "Since there could be
many types of intents, the I2NSF will focus on the intents that are
traditionally provided by FW/IPS/IDS”, but for another reason.

FW/IPS/IDS are being used for a lot of kinds of policy enforcement that are
not related to security. The example “my son can access *.facebook.com
<http://facebook.com>  only between 18:30 and 20:00” is a perfect example.
It’s policy, but it’s not security policy. I guess most firewalls can
enforce this particular intent, but how about “my son can play Farmville
between 18:30 and 20:00”? Some firewalls can do that, but that can’t be
taken separately from “deep packet inspection”, because without it the
firewall can’t tell farmville apart from just reading statuses on Facebook.

Just as “deep packet inspection” is a technology rather than an intent,
there is also “URL filtering”. An “intent” might be “no access to
pornographic material”, but can a firewall enforce this? It depends, because
filtering pornography, blasphemy, and other types of undesirable material is
often done using URL filtering. A firewall might have the technology, but is
entirely dependent on being provided with a database of objectionable URLs,
and such a database may or may not be provided by the firewall vendor,
especially when the definition of “pornographic”, “blasphemy”, or even
“NSFW” is location and culture specific.

I’m wondering how an API could reflect this, considering that every firewall
has different APIs for both vendor-provided databases and external
databases. So how do we communicate to the NSF that it should filter
according to the “Hacking & Warez” database from URLfilterDB, and how can
the NSF communicate back to the controller if that format is supported?

Yoav

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