Re: [I2nsf] Many aspects are needed to seamlessly integrate vNSF to network (was RE: [Newsletter] Re: I2NSF charter for IESG Review

[Linda Dunbar <[e-mail]>]

Yoav,

Does it mean that you also agree with Ed's suggestion that I2NSF can start with Flow Based Security Functions (instead of specific security devices because different vendors have different features on their devices)? AD Kathleen asked this question on the I2NSF list.

I had a face to face discussion with Ed again during ONF meeting last week. He pointed out that  all those security devices, such as FW/WebFilter/DPI/IPS/IDS/DPI.., are for enforcing some type of security policies to packets traversing through. They are just in different form factor (or device type) by today's vendors. Those device names & functions can change in the future.

Flow Based Security Functions provide treatment to packets/flows, such as IPS/IDS, Web filter, and Stateless flow filter. (They are different from Application layer security functions, such as email filter, virus treatment, etc. They are also different from policies to specify what types of encryption for certain traffic).

I2NSF can focus on specifying a mechanism to express "Flow Based Security Policies", as specified by the drafts: http://datatracker.ietf.org/doc/draft-strassner-i2nfs-info-model/
http://datatracker.ietf.org/doc/draft-xia-i2nsf-service-interface-dm/


I2NSF should not target at specifying entire configuration for a specific device, such as FW. As you said different vendors have different features.

I2NSF is only targeted at the "Flow based security policies", which is a subset of features provided by Security Devices.  Those policies can be requested by application gateways or clients for their specific need. Each vendor has its own "Adaptor" to convert those policies to its own specific command.


Linda


From: I2nsf [mailto:[e-mail]] On Behalf Of Yoav Nir
Sent: Saturday, February 14, 2015 6:03 AM
To: [e-mail]
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