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: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 4 Mar 2015 11:46:37 +0000

Hi,

Thinking about it, it seems to me that we must define an entity that it is in charge of:

1) Registering the appropriate functions and the policies they support (the interface A you mention)

2) Associating some of those functions to certain user profiles (a limited version of the interface B you mention)

3) Reconciling the different policy sources (the operator, the user, the enterprise...) and translate the outcome into a series of actual control requests to the function(s) (part of the interface B and the interface C you mention)

We can call it a vNSFM, though I cannot see why it should be vendor specific by any reason. At least one should exist per operator providing a i2nsf policy decision point.

And I'd not try to make a taxonomy of security functions by any means. The registration in the first interface above (1 or A) would define the policies available to be set for a certain function, irrespectively of any general category it may belong to. So the gist of the process is not classifying the functions, but identifying a comprehensive set of security policies that they can support. I believe this is a much more open and future-proof approach, leaving vNSF providers total freedom on how they implemente the policies they commit to support at each function.

Be goode,

On 27 Feb 2015, at 19:32 , Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

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 Policies

Layer 2
Layer 3,
TCP/UDP layer
HTTP Layer

Pass/
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]<mailto:[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]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

--
"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: Linda Dunbar <[email-masked]>
Date: Thu, 5 Mar 2015 22:02:05 +0000

Diego,

Questions and clarification are inserted below:

From: DIEGO LOPEZ GARCIA [mailto:[email-masked]]
Sent: Wednesday, March 04, 2015 5:47 AM
To: Linda Dunbar
Cc: Yoav Nir; [email-masked]; Edward Lopez
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

Hi,

[Linda] We learned from our multi-vendor PoC project that only a limited number of attributes (or Service Profiles) of security devices that are allowed by vendors to be dynamically configured by the Operators. Many basic configuration of the security devices are managed by the vendor specific management system.
Is it what you mean "limited version" of the interface B?
The Interface B should be only the limited "Service Profile" or "allowed configurable attributes" to the security functions.

[Linda] The interface C is intended to App Gateway or your customers who need the security functions managed by the operators.

[Linda] One operator can have security functions from different vendors. A FW by Vendor A can be different from FW by Vendor B.

If IETF can define some basic security objects for each vendor to register. Each vendor has its own vendor specific features that can be configured by its unique interface.

And I'd not try to make a taxonomy of security functions by any means. The registration in the first interface above (1 or A) would define the policies available to be set for a certain function, irrespectively of any general category it may belong to.

[Linda] Good.

So the gist of the process is not classifying the functions, but identifying a comprehensive set of security policies that they can support.

[Linda] Do you think that we can start with the following basic "flow based security policies" that can be IANA registered (in the future) for each vendor to declare when registering their security functions to the operator's OSS?

Layer 2
Layer 3,
TCP/UDP layer
HTTP Layer

Time:
Start/end/duration

Zone

Tenant ID

I believe this is a much more open and future-proof approach, leaving vNSF providers total freedom on how they implemente the policies they commit to support at each function.

Be goode,

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:

Attribute

Actions

CRUD

Description

Vendor

SF Name

 SF Type

Layer 2
Layer 3,
TCP/UDP layer
HTTP Layer

Pass/
drop/
mirror/
Statistics (report  Destination)
Function call (IPS/IDS/AV/URL filter/...)

Time:
Start/end/duration

Zone

Service layer attributes

Tenant ID

IETF PCP?

TCP/UDP port

Open/Close

IETF TRAM

Mgmt Address

MAC/IPv4/IPv6

Linda

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

Dr Diego R. Lopez
Telefonica I+D

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

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Sat, 7 Mar 2015 17:57:31 +0000

Hi,

A few reflections inline: I have edited the rest of the message to ease reading...

On 5 Mar 2015, at 23:02 , Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
2) Associating some of those functions to certain user profiles (a limited version of the interface B you mention)

[Linda] We learned from our multi-vendor PoC project that only a limited number of attributes (or Service Profiles) of security devices that are allowed by vendors to be dynamically configured by the Operators. Many basic configuration of the security devices are managed by the vendor specific management system.
Is it what you mean “limited version” of the interface B?
The Interface B should be only the limited “Service Profile” or “allowed configurable attributes” to the security functions.

DRL> First of all, I am precisely trying to think in terms of *functions* and not *devices*. A current device may implement several of these functions, and in the future I hope we'll see software-based, virtualized versions of those functions.
DRL> What I try to mean is that the service provider should be able to associate certain management actions on the functions to different user profiles, so it would become possible for different users to perform different actions, independently of what are the limitations imposed by the function provider.

DRL> I think we are understanding the same function for the interface C (a control interface for users and/or management systems). My point here is that it should be required to align the potentially conflicting policies expressed by the different actors.

DRL> Sure! But first we should be talking functions (filtering, forwarding, logging...) not devices (firewalls or IDS or...) A service provider could certainly use security functions from different function providers.
And second, those functions should announce which are the policy enforcement operations they support.

DRL> As long as it is possible to register those features, I think we agree on this...

[Linda] Do you think that we can start with the following basic “flow based security policies” that can be IANA registered (in the future) for each vendor to declare when registering their security functions to the operator’s OSS?

Layer 2
Layer 3,
TCP/UDP layer
HTTP Layer

Time:
Start/end/duration

Zone

Tenant ID

DRL> I agree we could attempt a policy classification, but I am not sure what you mean with the above list: some are very general (like "layer 2") or very particular to a certain protocol ("HTTP layer"), or not clear to me where they can be applied (as the case of tenant or application IDs...)

Be goode,

Dr Diego R. Lopez
Telefonica I+D

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 9 Mar 2015 02:42:41 +0000

Diego,

Thank you very much for the comments.

The List of "Third Party Configurable Policies" (potentially to be normalized by IETF I2NSF) given at last email was only the title. There are more detailed policies (described in the draft-merged-i2nsf-framework). Basically let vendors to register which "policies" can be supported to be configurable by the 3rd party (operator management) for their flow based security functions.

+---------------+----------+--------------------------------+--------+
|   Category    |    Third Party Configurable Policies      |   ID   |
+---------------+----------+--------------------------------+--------+
| Layer 2       | Layer 2 header fields:                    |        |
|               | Source/Destination/s-VID/c-VID/EtherType/.|        |
|               |                                           |        |
|---------------+-------------------------------------------+ ------ +
| Layer 3       | Layer  header fields:                     |        |
|               |            protocol                       |        |
| IPv4 objects  |            port                           |        |
|               |            src port                       |        |
|               |            dscp                           |        |
|               |            length                         |        |
|               |            flags                          |        |
|               |            ttl                            |        |
|               |                                           |        |
| IPv6 Object   |                                           |        |
|               |            addr                           |        |
|               |            protocol/nh                    |        |
|               |            src port                       |        |
|               |            length                         |        |
|               |            traffic class                  |        |
|               |            hop limit                      |        |
|               |            flow label                     |        |
|               |                                           |        |
| TCP           |            Port                           |        |
| SCTP          |            syn                            |        |
| DCCP          |            ack                            |        |
|               |            fin                            |        |
|               |            rst                            |        |
|               |          ? psh                            |        |
|               |          ? urg                            |        |
|               |          ? window                         |        |
|               |          ? sockstress                     |        |
| UDP           |                                           |        |
|               |            Port                           |        |
|               |          ? fragment abuse                 |        |
|               |                                           |        |
| HTTP layer    |                                           |        |
|               |          | hash collision                 |        |
|               |          | http - get flood               |        |
|               |          | http - post flood              |        |
|               |          | http - random/invalid url      |        |
|               |          | http - slowloris               |        |
|               |          | http - slow read               |        |
|               |          | http - r-u-dead-yet (rudy)     |        |
|               |          | http - malformed request       |        |
|               |          | http - xss                     |        |
|               |          | https - ssl session exhaustion |        |
+---------------+----------+--------------------------------+--------+
| IETF PCP      | Configurable                              |        |
|               | Ports                                     |        |
|               |                                           |        |
+---------------+-------------------------------------------+--------+
| IETF TRAM     | profile                                   |        |
|               |                                           |        |
|               |                                           |        |
|---------------+-------------------------------------------+ ------ +

Thanks, Linda
From: DIEGO LOPEZ GARCIA [mailto:[email-masked]]
Sent: Saturday, March 07, 2015 11:58 AM
To: Linda Dunbar
Cc: Yoav Nir; [email-masked]; Edward Lopez
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

Hi,

[Linda]

[Linda] Do you mean that "Operator" can select the appropriate  functions from a pool of functions by different vendor to meet its use need?

[Linda] good point.

[Linda] "vNSFM" is controlled by the operators.  In addition the 3rd party configurable security policies, there will be some basic settings that can be statically configured ahead of time by vendor provided "image", or "script" that operators don't know details of. That is what I meant "Vendor specific Management"

Layer 2
Layer 3,
TCP/UDP layer
HTTP Layer

Time:
Start/end/duration

Zone

Tenant ID

Be goode,

Dr Diego R. Lopez
Telefonica I+D