Subject: [I2nsf] I2NSF charter for IESG Review

From: Linda Dunbar <[email-masked]>
Date: Fri, 6 Feb 2015 16:43:47 +0000

Enterprises, residential, and mobile customers are increasingly consuming network functions, especially network security related functions that are not running on their premises.  In addition, the ETSI Network Function Virtualization (NFV) initiative creates new management challenges for security policies to be enforced by distributed, virtual, network security functions (vNSF). These trends require a standard interface to express, monitor, and manage security policies for physical and virtual distributed security functions that may be running on different premises.

In order to address the above challenges, vNSF devices may include two functional layers:
  - Security Service and Policy Layer
  - Capability (or Functional) Layer

The Security Service and Policy Layer is for clients to express and monitor security policies for their specific flows. This layer will leverage existing protocols, such as those defined in Netconf, AAA, and SACM, to carry new abstractions that support Discretionary Access Control, Mandatory Access Control, Role Based Access Control, Attribute-Based Access Control, Policy-Based Access Control, or combinations of these.

The Capability (or Functional) Layer specifies how client security policies can request the capabilities of security devices, and then map security policies to a form that security devices can use. This requires the definition of an information model, along with one or more data models, to represent virtual and physical security functions and devices. This layer will leverage the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

The Interface to Network Security Functions (I2NSF) enables clients to communicate their specific security services and policies (request/monitor/report) to a system, and map these security policies to the security functions present in security devices in that system.  I2NSF will specify a set of standardized mechanisms for clients and applications to request, negotiate, manage, and validate security functions using a declarative programmatic interface to physical and virtual devices. In order to support this programmatic interface, an Information Model will be defined to serve as a common vocabulary of security policy concepts and security device capabilities; associated Data Models will be derived from this Information Model to support Operation, Administration, Maintenance and Provisioning (OAMP) functions for security policies and security device capabilities.  The models will include at least the services provided by the following security functions:

  - Firewall, and its associated services
  - Intrusion Detection System / Intrusion Prevention System (IDS/IPS)

Exemplar services associated with a firewall include stateful or deep packet inspection, packet/flow/stream filtering, and redirection (remote and local). Exemplar IDS/IDP functions includes flow/stream pattern matching and remediation, respectively.

It is a non-goal to create new protocols or data modeling languages for I2NSF interfaces.

I2NSF WG Deliverables include:

  - Use Case document.
  - Framework Document.
  - Requirement for extensions (if there are any) to existing protocols used by the WG.
  - Gap analysis of existing protocols and modeling languages
  - A single, unified, Information Model for the security functions listed above and associated capabilities.
  - Corresponding Data Models (e.g. YANG models) derived from the above Information Model.
  - (Optionally) Applicability Statements on how to use I2RS, Netconf, and NETMOD to carry the content of the specified information/data models.

[The WG may decide that the Use cases, Framework, and Requirement are Informational documents or simply reference documents during the lifetime of the WG]

Suggested Milestones
  - Use Case Document:  Charter time + 1 month to WG Document
  - Framework: Charter time + 4 months to WG Document
  - Requirements for extensions to protocols:  Charter time + 6 months to WG document
  - Info model: Charter time + 7 months to WG Document
  - All Early Drafts to IESG: 10 months

[decision point - +10 months]
  - Data Models: Charter + 9 Months to WG Document
  - Applicability Statements: 10 months to WG Document
  - Data Models and Applicability Statements to IESG  - 16 months

The WG will work closely with I2RS, Netconf and Netmod WGs.

The framework, that describes the reference points and functional components, is to make the discussion more focused.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 6 Feb 2015 11:48:24 -0500

Hi Linda,

A few people mentioned getting rid of mention of specific devices like
firewalls and IDS and to focus more on the interactions.  I see they are
still in the charter, are they necessary?

Thanks.

On Fri, Feb 6, 2015 at 11:43 AM, Linda Dunbar <[email-masked]>
wrote:

>
>
> Enterprises, residential, and mobile customers are increasingly consuming
> network functions, especially network security related functions that are
> not running on their premises.  In addition, the ETSI Network Function
> Virtualization (NFV) initiative creates new management challenges for
> security policies to be enforced by distributed, virtual, network security
> functions (vNSF). These trends require a standard interface to express,
> monitor, and manage security policies for physical and virtual distributed
> security functions that may be running on different premises.
>
>
>
> The Security Service and Policy Layer is for clients to express and
> monitor security policies for their specific flows. This layer will
> leverage existing protocols, such as those defined in Netconf, AAA, and
> SACM, to carry new abstractions that support Discretionary Access Control,
> Mandatory Access Control, Role Based Access Control, Attribute-Based Access
> Control, Policy-Based Access Control, or combinations of these.
>
>
>
> The Capability (or Functional) Layer specifies how client security
> policies can request the capabilities of security devices, and then map
> security policies to a form that security devices can use. This requires
> the definition of an information model, along with one or more data models,
> to represent virtual and physical security functions and devices. This
> layer will leverage the existing protocols and data models defined by I2RS,
> Netconf, and NETMOD.
>
>
>
> The Interface to Network Security Functions (I2NSF) enables clients to
> communicate their specific security services and policies
> (request/monitor/report) to a system, and map these security policies to
> the security functions present in security devices in that system.  I2NSF
> will specify a set of standardized mechanisms for clients and applications
> to request, negotiate, manage, and validate security functions using a
> declarative programmatic interface to physical and virtual devices. In
> order to support this programmatic interface, an Information Model will be
> defined to serve as a common vocabulary of security policy concepts and
> security device capabilities; associated Data Models will be derived from
> this Information Model to support Operation, Administration, Maintenance
> and Provisioning (OAMP) functions for security policies and security device
> capabilities.  The models will include at least the services provided by
> the following security functions:
>
>
>
> Exemplar services associated with a firewall include stateful or deep
> packet inspection, packet/flow/stream filtering, and redirection (remote
> and local). Exemplar IDS/IDP functions includes flow/stream pattern
> matching and remediation, respectively.
>
>
>
>   - (Optionally) Applicability Statements on how to use I2RS, Netconf, and
> NETMOD to carry the content of the specified information/data models.
>
>
>
> [The WG may decide that the Use cases, Framework, and Requirement are
> Informational documents or simply reference documents during the lifetime
> of the WG]
>
>
>
> Suggested Milestones
>
> [decision point – +10 months]
>
> The framework, that describes the reference points and functional
> components, is to make the discussion more focused.
>
>
>
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>

-- 

Best regards,
Kathleen

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 6 Feb 2015 16:52:44 +0000

Kathleen,

Without mentioning FW and IDS/IPS, the scope can be too wide.
We change the wording to make I2NSF focus on the security services that are provided by traditional FW and IPS/IDS functions.

Linda

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Friday, February 06, 2015 10:48 AM
To: Linda Dunbar
Cc: [email-masked]
Subject: Re: [I2nsf] I2NSF charter for IESG Review

Hi Linda,

A few people mentioned getting rid of mention of specific devices like firewalls and IDS and to focus more on the interactions.  I see they are still in the charter, are they necessary?

Thanks.

On Fri, Feb 6, 2015 at 11:43 AM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

  - Use Case document.
  - Framework Document.

Suggested Milestones

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

--

Best regards,
Kathleen

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 8 Feb 2015 09:36:12 +0000

Hi,

I agree with Linda here. I believe that mentioning (at most) two specific security functions helps to better focus the more generic work on interfaces, and defines clear targets of the IMs and DMs.

Regards,

Dan

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Friday, February 06, 2015 6:53 PM
To: Kathleen Moriarty
Cc: [email-masked]
Subject: Re: [I2nsf] I2NSF charter for IESG Review

Kathleen,

Linda

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Friday, February 06, 2015 10:48 AM
To: Linda Dunbar
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [I2nsf] I2NSF charter for IESG Review

Hi Linda,

Thanks.

  - Use Case document.
  - Framework Document.

Suggested Milestones

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i2nsf&d=AwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Nc9ckBdOaTTxu0o1HEzR7OUj8H3RzVu6pjtcwc7vICo&s=xc1E83x9xZQzPsOovUegJzvYeKC2I6mkxRoJ_wTZmBk&e=>

--

Best regards,
Kathleen

---

From: Edward Lopez <[email-masked]>
Date: Mon, 9 Feb 2015 16:43:06 +0000

I must strongly disagree with Linda on this point.  As I mentioned in another thread I started, the likelihood of standardization amongst the security vendor space, much less the differentiation of NSF in relation to changing paradigms of growth and endpoint diversity (such as the seen in BYOD and IoT),  make simplistic concepts as a firewall or IPS far less useful as charter targets.

This is not to say we can't glean useful information in studying how to interface with existing NSFs.  My point is that by their explicit inclusion within the charter, we are inherently making a statement on security best practices.  That should not be our intent.  Our charter should not:

- Narrowly define NSF categories or their roles ... Unfortunately, this is rampant throughout this proposed charter
- Attempt to impose functional constraints either directly or indirectly upon NSF creators.  For example, proposing a standard of what a firewall management interface should not result in a de-facto definition of what a firewall is.  Ultimately, network security is harmed by such constraints
- Should not be a limited lowest-common denominator approach, which is not at all useful in approaching network security.  For example, while creating a five-tuple firewall policy or ACL entry may be considered a reasonable universal methodology (and there are exceptions to this!), creating a limited interface and relying on external/proprietary APIs to cover the details will be worse than the situation we have now.

The real issue is how to seamlessly integrate NSFs onto networks.  There are so many WGs where the complaints on how middleboxes break end-to-end architectures, or themselves capitalize on vulnerabilities within standards (TLS interception is a noted example) that there are now I-Ds that propose their eradication, which I feel is a very naive concept.  The real benefit is when we can define how the NSF interacts with the network, what parameters we can pass to it, and what operational data we can get from it.

Our focus needs to be more on the network and how to create an open interface for integrating NSFs, than fall into the rathole of trying to define the NSF functionality and how we can get a genie back in its bottle

Regards,
Ed Lopez

Sent from my iPhone ... Sorry for any auto-correct errors

On Feb 8, 2015, at 3:36 AM, Romascanu, Dan (Dan) <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Dan

Kathleen,

Linda

Hi Linda,

Thanks.

  - Use Case document.
  - Framework Document.

Suggested Milestones

--

Best regards,
Kathleen

***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are hereby 
notified that any review, use, disclosure, dissemination, distribution or copying 
of this message and any attachments is strictly prohibited. If you have received 
this email in error, please immediately notify the sender and destroy this e-mail 
and any attachments and all copies, whether electronic or printed.
Please also note that any views, opinions, conclusions or commitments expressed 
in this message are those of the individual sender and do not necessarily reflect 
the views of Fortinet, Inc., its affiliates, and emails are not binding on 
Fortinet and only a writing manually signed by Fortinet's General Counsel can be 
a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 9 Feb 2015 18:06:31 +0000

Hi,

While I fully agree with Ed in that we must not restrict the scope to a particular set of (current or foreseen) NSF I don't see this goal conflicting with Dan's point of including a couple of NSFs as targets to be used as examples of the applicability of the interfaces we intend to define. Probably the charter needs a carefully wording to make this clear...

Be goode,

On 9 Feb 2015, at 17:43 , Edward Lopez <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Ed Lopez

Hi,

Regards,

Dan

Kathleen,

Linda

Hi Linda,

Thanks.

  - Use Case document.
  - Framework Document.

Suggested Milestones

--

Best regards,
Kathleen

________________________________
*** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***
________________________________
_______________________________________________
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: Mon, 9 Feb 2015 18:58:44 +0000

Ed,

There are many aspects to be developed to achieve seamlessly integrating NSFs onto networks.  The problem you described seems very broad, may require multiple IETF WGs to tackle.

I2NSF will focus on the use case described by http://datatracker.ietf.org/doc/draft-pastor-i2nsf-access-usecases/:

       Customer   +     Access     +     Core
                  |                |     +--------+
                  |          ,-----+--.  |Network |
                  |        ,'      |   `-|Operator|
    +-----------+ |       /+----+  |     |Mgmt Sys|
    |Residential|-+------/-+vCPE+----+   +--------+
    +-----------+ |     /  +----+  |  \           :
                  |    /           |   \          |
                  |   ;            |    +----+    |
                  |   |            |    |vNSF|    |
                  |   :            |    +----+    |
                  |    :           |   /          |
       +--------+ |    :   +----+  |  /           ;
       |Mobile  |-+-----\--+vEPC+----+           /
       +--------+ |      \ +----+  |      ISP ,-'
                  |       `--.     |      _.-'
                  |           `----+----''
                  +                +

                     Figure 1: Customer Access Network

Among the 3 actions listed in the Use Case draft, #1 & #3 don't have to be limited to specific security functions. But the #2 below has to start from somewhere.  The FW/IPS/IDS in the charter are specifically for the #2 below.

   1.  Customer enrollment and cancellation of the subscription to a
      vNSF. (

   2.  Configuration of the vNSF, based on specific configurations or
      derived from common security policies defined by the operator.

   3.  Retrieve and list of the vNSF functionalities, extracted from a
      manifest or a descriptor.  The network operator management systems
      can demand this information to offer detailed information through
      the commercial channels to the customer.

Linda

From: DIEGO LOPEZ GARCIA [mailto:[email-masked]]
Sent: Monday, February 09, 2015 12:07 PM
To: [email-masked]
Cc: Romascanu, Dan (Dan); Kathleen Moriarty; Linda Dunbar; Edward Lopez
Subject: Re: [I2nsf] [Newsletter] Re: I2NSF charter for IESG Review

Hi,

Be goode,

Regards,
Ed Lopez

Regards,

Dan

Kathleen,

Linda

Hi Linda,

Thanks.

  - Use Case document.
  - Framework Document.

Suggested Milestones

--

Best regards,
Kathleen

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: Kathleen Moriarty <[email-masked]>
Date: Mon, 9 Feb 2015 14:09:20 -0500

Hello,

The charter could start off with a small scope, complete that work and add
in other related work as a strategy to keep the charter small, prioritized,
and manageable.

Opportunities to leverage similar groups for some of the work, as it
applies, may be another good strategy to pull in the scope, yet accomplish
the breadth of work.  I'll look for this as I review materials and hope
others do as well.  You may have a lower barrier to getting the work
accomplished by reducing the scope of I2NSF and getting some of the items
started in I2RS, SACM, or other working groups that are already established
(as appropriate).

Thanks,
Kathleen

On Mon, Feb 9, 2015 at 1:06 PM, DIEGO LOPEZ GARCIA <
[email-masked]> wrote:

>  Hi,
>
>  While I fully agree with Ed in that we must not restrict the scope to a
> particular set of (current or foreseen) NSF I don't see this goal
> conflicting with Dan's point of including a couple of NSFs as targets to be
> used as examples of the applicability of the interfaces we intend to
> define. Probably the charter needs a carefully wording to make this clear...
>
>  Be goode,
>
>   On 9 Feb 2015, at 17:43 , Edward Lopez <[email-masked]> wrote:
>
>  I must strongly disagree with Linda on this point.  As I mentioned in
> another thread I started, the likelihood of standardization amongst the
> security vendor space, much less the differentiation of NSF in relation to
> changing paradigms of growth and endpoint diversity (such as the seen in
> BYOD and IoT),  make simplistic concepts as a firewall or IPS far less
> useful as charter targets.
>
>  This is not to say we can't glean useful information in studying how to
> interface with existing NSFs.  My point is that by their explicit inclusion
> within the charter, we are inherently making a statement on security best
> practices.  That should not be our intent.  Our charter should not:
>
>  - Narrowly define NSF categories or their roles ... Unfortunately, this
> is rampant throughout this proposed charter
> - Attempt to impose functional constraints either directly or indirectly
> upon NSF creators.  For example, proposing a standard of what a firewall
> management interface should not result in a de-facto definition of what a
> firewall is.  Ultimately, network security is harmed by such constraints
> - Should not be a limited lowest-common denominator approach, which is not
> at all useful in approaching network security.  For example, while creating
> a five-tuple firewall policy or ACL entry may be considered a reasonable
> universal methodology (and there are exceptions to this!), creating a
> limited interface and relying on external/proprietary APIs to cover the
> details will be worse than the situation we have now.
>
>  The real issue is how to seamlessly integrate NSFs onto networks.  There
> are so many WGs where the complaints on how middleboxes break end-to-end
> architectures, or themselves capitalize on vulnerabilities within standards
> (TLS interception is a noted example) that there are now I-Ds that propose
> their eradication, which I feel is a very naive concept.  The real benefit
> is when we can define how the NSF interacts with the network, what
> parameters we can pass to it, and what operational data we can get from it.
>
>  Our focus needs to be more on the network and how to create an open
> interface for integrating NSFs, than fall into the rathole of trying to
> define the NSF functionality and how we can get a genie back in its bottle
>
>  Regards,
>  Ed Lopez
>
> On Feb 8, 2015, at 3:36 AM, Romascanu, Dan (Dan) <[email-masked]>
> wrote:
>
>   Hi,
>
>  I agree with Linda here. I believe that mentioning (at most) two
> specific security functions helps to better focus the more generic work on
> interfaces, and defines clear targets of the IMs and DMs.
>
>  Regards,
>
>  Dan
>
>
>   *From:* I2nsf [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Linda Dunbar
> *Sent:* Friday, February 06, 2015 6:53 PM
> *To:* Kathleen Moriarty
> *Cc:* [email-masked]
> *Subject:* Re: [I2nsf] I2NSF charter for IESG Review
>
>  Kathleen,
>
>  We change the wording to make I2NSF focus on the security services that
> are provided by traditional FW and IPS/IDS functions.
>
>  Linda
>
>  *From:* Kathleen Moriarty [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Friday, February 06, 2015 10:48 AM
> *To:* Linda Dunbar
> *Cc:* [email-masked]
> *Subject:* Re: [I2nsf] I2NSF charter for IESG Review
>
>  Hi Linda,
>
>    - A single, unified, Information Model for the security functions
> listed above and associated capabilities.
>    - (Optionally) Applicability Statements on how to use I2RS, Netconf,
> and NETMOD to carry the content of the specified information/data models.
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i2nsf&d=AwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Nc9ckBdOaTTxu0o1HEzR7OUj8H3RzVu6pjtcwc7vICo&s=xc1E83x9xZQzPsOovUegJzvYeKC2I6mkxRoJ_wTZmBk&e=>
>
>
>
>  --
>
>  Best regards,
>   Kathleen
>
> * ------------------------------ *** Please note that this message and any
> attachments may contain confidential and proprietary material and
> information and are intended only for the use of the intended recipient(s).
> If you are not the intended recipient, you are hereby notified that any
> review, use, disclosure, dissemination, distribution or copying of this
> message and any attachments is strictly prohibited. If you have received
> this email in error, please immediately notify the sender and destroy this
> e-mail and any attachments and all copies, whether electronic or printed.
> Please also note that any views, opinions, conclusions or commitments
> expressed in this message are those of the individual sender and do not
> necessarily reflect the views of Fortinet, Inc., its affiliates, and emails
> are not binding on Fortinet and only a writing manually signed by
> Fortinet's General Counsel can be a binding commitment of Fortinet to
> Fortinet's customers or partners. Thank you. ***
> ------------------------------ *
> ------------------------------
>
> 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
>

-- 

Best regards,
Kathleen

---

From: Edward Lopez <[email-masked]>
Date: Mon, 9 Feb 2015 19:47:15 +0000

Actually, I very much like this draft.  But what I'm not seeing is how that statement #2 distills to the explicit terms FW/IPS/IDS in the charter.

For example, I would argue that for many carriers, there is a focus on web filtering as a service.  For others it's about DDoS defense.  Many have to deal with traffic inspection differently based on geocentric policies associated with its source and/or destination.

I'm not trying to boil the ocean here.  My point is to treat the NSF as a black box then ask yourself how am I going to integrate this thing onto my network, rather than targeting a particular type of NSF, and resulting in a limited solution.

Which by the way is what I extracted from the draft.

Regards,
Ed Lopez

On Feb 9, 2015, at 12:59 PM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

Ed,

       Customer   +     Access     +     Core
                  |                |     +--------+
                  |          ,-----+--.  |Network |
                  |        ,'      |   `-|Operator|

Among the 3 actions listed in the Use Case draft, #1 & #3 don’t have to be limited to specific security functions. But the #2 below has to start from somewhere.  The FW/IPS/IDS in the charter are specifically for the #2 below.

Linda

To: [email-masked]<mailto:[email-masked]>

Hi,

Be goode,

Regards,
Ed Lopez

Regards,

Dan

Kathleen,

Linda

Hi Linda,

Thanks.

  - Use Case document.
  - Framework Document.

Suggested Milestones

--

Best regards,
Kathleen

Dr Diego R. Lopez
Telefonica I+D

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 9 Feb 2015 15:14:07 -0500

On Mon, Feb 9, 2015 at 2:47 PM, Edward Lopez <[email-masked]> wrote:

>   Actually, I very much like this draft.  But what I'm not seeing is how
> that statement #2 distills to the explicit terms FW/IPS/IDS in the charter.
>
>  For example, I would argue that for many carriers, there is a focus on
> web filtering as a service.  For others it's about DDoS defense.  Many have
> to deal with traffic inspection differently based on geocentric policies
> associated with its source and/or destination.
>
>  I'm not trying to boil the ocean here.  My point is to treat the NSF as
> a black box then ask yourself how am I going to integrate this thing onto
> my network, rather than targeting a particular type of NSF, and resulting
> in a limited solution.
>

What would this look like if the NSF were a black box?  What specific
problems would be solved?  What is accomplished by I2NSF in that model?
Would this eliminate the vendor differentiation issue raised in another
comment (all firewalls and IDS/IPS systems don't have the same feature
sets)?

Thanks,
Kathleen

> On Feb 9, 2015, at 12:59 PM, Linda Dunbar <[email-masked]> wrote:
>
>   Ed,
>
>
>
> There are many aspects to be developed to achieve seamlessly integrating
> NSFs onto networks.  The problem you described seems very broad, may
> require multiple IETF WGs to tackle.
>
>
>
>
>
> I2NSF will focus on the use case described by
> http://datatracker.ietf.org/doc/draft-pastor-i2nsf-access-usecases/:
>
>
>
>
>
>
>
>
>
>        Customer   +     Access     +     Core
>
>                   |                |     +--------+
>
>                   |          ,-----+--.  |Network |
>
>                   |        ,'      |   `-|Operator|
>
> Among the 3 actions listed in the Use Case draft, #1 & #3 don’t have to be
> limited to specific security functions. But the #2 below has to start from
> somewhere.  The FW/IPS/IDS in the charter are specifically for the #2
> below.
>
>
>
>
>
> *From:* DIEGO LOPEZ GARCIA [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Monday, February 09, 2015 12:07 PM
> *To:* [email-masked]
> *Cc:* Romascanu, Dan (Dan); Kathleen Moriarty; Linda Dunbar; Edward Lopez
> *Subject:* Re: [I2nsf] [Newsletter] Re: I2NSF charter for IESG Review
>
>
>
> Hi,
>
>
>
> I agree with Linda here. I believe that mentioning (at most) two specific
> security functions helps to better focus the more generic work on
> * ------------------------------ *
>
> **** Please note that this message and any attachments may contain
> confidential and proprietary material and information and are intended only
> for the use of the intended recipient(s). If you are not the intended
> recipient, you are hereby notified that any review, use, disclosure,
> dissemination, distribution or copying of this message and any attachments
> is strictly prohibited. If you have received this email in error, please
> immediately notify the sender and destroy this e-mail and any attachments
> and all copies, whether electronic or printed. Please also note that any
> views, opinions, conclusions or commitments expressed in this message are
> those of the individual sender and do not necessarily reflect the views of
> Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and
> only a writing manually signed by Fortinet's General Counsel can be a
> binding commitment of Fortinet to Fortinet's customers or partners. Thank
> you. *** *
> * ------------------------------ *
>
> *------------------------------ *** Please note that this message and any
> ------------------------------*
>

-- 

Best regards,
Kathleen

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 9 Feb 2015 22:42:52 +0000

Kathleen,

Here are the answers your questions.

What would this look like if the NSF were a black box?
[Linda] It would be the Security Intent (or Service Layer) for clients to specify what they desire (e.g. subscribe, query, monitor). Since there could be many types of intents, the I2NSF will focus on the intents that are traditionally provided by FW/IPS/IDS.
For example,
               Client X subscribes to the “enabling web filtering” service with a list of criteria;
              Client Y subscribes to the “deep packet inspection” and specifies the “Actions” for packets  matching the given criteria;
enable basic parental control
enable ”school protection control”
allow Internet traffic from 8:30 to 20:00 [time = 8:30-20:00]
scan email for malware detection [check type = malware] protect traffic to corporate network with integrity and confidentiality [protection type = integrity AND confidentiality]
remove tracking data from Facebook [website = *.facebook.com]
my son is allowed to access facebook from 18:30 to 20:00

What specific problems would be solved?
[Linda] Allow clients (Network Management system, or customer’s own management system) to dynamically request vNSF for their traffic and dynamically configure/monitor the security policies required for their vNSF.

What is accomplished by I2NSF in that model?
[Linda] I2NSF provides the mechanism for clients to query, request, and monitor their desired security policies (or the intent) across vNSF over different premises.

Would this eliminate the vendor differentiation issue raised in another comment (all firewalls and IDS/IPS systems don't have the same feature sets)?
[Linda]I would think so. I2NSF provides the mechanism for vNSF subscription, monitoring, and security policies that are supported by majority vendors.  For vendor specific features, I2NSF only provides the mechanism.

Linda

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Monday, February 09, 2015 2:14 PM
To: Edward Lopez
Cc: Linda Dunbar; [email-masked]; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA
Subject: Re: [I2nsf] Many aspects are needed to seamlessly integrate vNSF to network (was RE: [Newsletter] Re: I2NSF charter for IESG Review

On Mon, Feb 9, 2015 at 2:47 PM, Edward Lopez <[email-masked]<mailto:[email-masked]>> wrote:
Actually, I very much like this draft.  But what I'm not seeing is how that statement #2 distills to the explicit terms FW/IPS/IDS in the charter.

What would this look like if the NSF were a black box?  What specific problems would be solved?  What is accomplished by I2NSF in that model?  Would this eliminate the vendor differentiation issue raised in another comment (all firewalls and IDS/IPS systems don't have the same feature sets)?

Thanks,
Kathleen

Regards,
Ed Lopez

       Customer   +     Access     +     Core
                  |                |     +--------+
                  |          ,-----+--.  |Network |
                  |        ,'      |   `-|Operator|

Linda

Hi,

Be goode,

Regards,
Ed Lopez

Regards,

Dan

Kathleen,

Linda

Hi Linda,

Thanks.

  - Use Case document.
  - Framework Document.

Suggested Milestones

--

Best regards,
Kathleen

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041<tel:%2B34%20913%20129%20041>
Mobile: +34 682 051 091<tel:%2B34%20682%20051%20091>
----------------------------------

--

Best regards,
Kathleen

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 9 Feb 2015 15:09:45 -0800

On Mon, Feb 9, 2015 at 2:42 PM, Linda Dunbar <[email-masked]>
wrote:

> [Linda] It would be the Security Intent (or Service Layer) for clients to
> specify what they desire (e.g. subscribe, query, monitor). Since there
> could be many types of intents, the I2NSF will focus on the intents that
> are traditionally provided by FW/IPS/IDS.
>
> For example,
>
>               Client Y subscribes to the “deep packet inspection” and
> specifies the “Actions” for packets  matching the given criteria;
>
> allow Internet traffic from 8:30 to 20:00 *[time = 8:30-20:00]*
>
> scan email for malware detection *[check type = malware]* protect traffic
> to corporate network with integrity and confidentiality *[protection type
> = integrity AND confidentiality]*
>
> remove tracking data from Facebook *[website = *.facebook.com
> <http://facebook.com>]*
>
> *my son *is allowed to access facebook from 18:30 to 20:00
>
>
>
>
>
>
>
> [Linda] Allow clients (Network Management system, or customer’s own
> management system) to dynamically request vNSF for their traffic and
> dynamically configure/monitor the security policies required for their
> vNSF.
>
>
>
>
>
> [Linda] I2NSF provides the mechanism for clients to query, request, and
> monitor their desired security policies (or the intent) across vNSF over
> different premises.
>
>
>
> [Linda]I would think so. I2NSF provides the mechanism for vNSF
> subscription, monitoring, and security policies that are supported by
> majority vendors.  For vendor specific features, I2NSF only provides the
> mechanism.
>
>
>

[Joe]  I can see how this discussion applies to the "Security Service and
Policy Layer" mentioned in the charter.  This high level interface could
be abstracted from the vendor specific details of the network devices.
Would the "Capability (or Functional) Layer" still have the problem of
different feature sets as this interface is directly with the network
devices with their possible extensions and shortfalls?

>  Linda
>
>
>
> *From:* Kathleen Moriarty [mailto:[email-masked]]
> *Sent:* Monday, February 09, 2015 2:14 PM
> *To:* Edward Lopez
> *Cc:* Linda Dunbar; [email-masked]; Romascanu, Dan (Dan); DIEGO LOPEZ
> GARCIA
> *Subject:* Re: [I2nsf] Many aspects are needed to seamlessly integrate
> vNSF to network (was RE: [Newsletter] Re: I2NSF charter for IESG Review
>
>
>
>
>
>
>
> For example, I would argue that for many carriers, there is a focus on web
> filtering as a service.  For others it's about DDoS defense.  Many have to
> deal with traffic inspection differently based on geocentric policies
> I'm not trying to boil the ocean here.  My point is to treat the NSF as a
> black box then ask yourself how am I going to integrate this thing onto my
> network, rather than targeting a particular type of NSF, and resulting in a
> limited solution.
>
>
>

---

From: Edward Lopez <[email-masked]>
Date: Tue, 10 Feb 2015 01:06:19 +0000

The one statement you're making that I feel is the crux of the problem is:

"Since there could be many types of intents, the I2NSF will focus on the intents that are traditionally provided by FW/IPS/IDS"

I would like to see a statement that says that since there could be many types of intents, we will NOT focus on the characteristics of any specific intent, but focus our efforts on how to integrate any intent within the network.

Vendor differentiation will never be eliminated (and in fact should be encouraged!).  The concept of the so called "majority of vendors" implies two of the three bad ideas we could do: indirectly apply a criteria that defines a function, and seek a lowest common denominator across implementations.  You will in effect be establishing an indirect set of minimum security standards (to those manageable by an i2nsf interface).   From my standpoint this would be an unacceptable result.

An analogy can be made relative to Common Criteria (CC) evaluation and certification.  Originally and international standard,  vendors were at first allowed to be evaluated on their own protection profiles.  You passed evaluation if you did what you said you did.  But then CC changed in that passing governmental generated protection profiles were more important, as if the governments drafting the profiles had better knowledge than the vendors did (it could be argued that relative to the U.S., there was likely an effort by NIAP to keep the bar low).  As a result vendors began publishing bulletins on how to operate their devices in a FIPS/CC mode, which in most cases crippled the utility of the device.

This is the type of thing that I'm trying to avoid from the onset

Ed Lopez

On Feb 9, 2015, at 2:43 PM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

Kathleen,

remove tracking data from Facebook [website = *.facebook.com<http://facebook.com>]

Linda

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Monday, February 09, 2015 2:14 PM
To: Edward Lopez
Cc: Linda Dunbar; [email-masked]<mailto:[email-masked]>; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA
Subject: Re: [I2nsf] Many aspects are needed to seamlessly integrate vNSF to network (was RE: [Newsletter] Re: I2NSF charter for IESG Review

Thanks,
Kathleen

Regards,
Ed Lopez

       Customer   +     Access     +     Core
                  |                |     +--------+
                  |          ,-----+--.  |Network |
                  |        ,'      |   `-|Operator|

Linda

Hi,

Be goode,

Regards,
Ed Lopez

Regards,

Dan

Kathleen,

Linda

Hi Linda,

Thanks.

  - Use Case document.
  - Framework Document.

Suggested Milestones

--

Best regards,
Kathleen

Dr Diego R. Lopez
Telefonica I+D

--

Best regards,
Kathleen

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 10 Feb 2015 11:03:20 +0000

Hi Ed,

How can we verify that the concepts, architecture and interface definitions that we put in place work in the real world? How can we avoid spending time and energy in defining a generic architecture and a generic open interface which cannot be tested in deployment of real security services? I agree that defining what a firewall or IDS  is not in scope, that was never the intent, but I was thinking that taking a couple of the better understood security functions (based on use cases) and defining the associated data and deployment models would be a more constructive way of structuring the work, and would set concrete and measurable objectives for the WG. Maybe I do not fully understand what you are proposing, because this seems more like a list of what not to do, without a clear proposal (scope, deliverables) of what to do. You say 'focus needs to be more on the network and how to create an open interface for integrating NSFs' - OK, but what are the deliverables, when and how will we know that we are done?

Thanks and Regards,

Dan

From: Edward Lopez [mailto:[email-masked]]
Sent: Monday, February 09, 2015 6:43 PM
To: Romascanu, Dan (Dan)
Cc: Linda Dunbar; Kathleen Moriarty; [email-masked]
Subject: Re: [Newsletter] Re: [I2nsf] I2NSF charter for IESG Review

Regards,
Ed Lopez

Regards,

Dan

Kathleen,

Linda

Hi Linda,

Thanks.

  - Use Case document.
  - Framework Document.

Suggested Milestones

--

Best regards,
Kathleen
_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i2nsf&d=AwMF-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=kCCuuzNSHFoHWmY48T1NzfaMUJQkhItWonkhHsDdsiY&s=j-_Y9L91qK6KvtaEdPizDky_F5zmcQW-DqyzFSoJDAs&e=>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 10 Feb 2015 08:37:47 -0500

On Tue, Feb 10, 2015 at 6:03 AM, Romascanu, Dan (Dan) <[email-masked]>
wrote:

>  Hi Ed,
>
>
>
>
>
> How can we verify that the concepts, architecture and interface
> definitions that we put in place work in the real world? How can we avoid
> spending time and energy in defining a generic architecture and a generic
> open interface which cannot be tested in deployment of real security
> services? I agree that defining what a firewall or IDS  is not in scope,
> that was never the intent, but I was thinking that taking a couple of the
> better understood security functions (based on use cases) and defining the
> associated data and deployment models would be a more constructive way of
> structuring the work, and would set concrete and measurable objectives for
> the WG. Maybe I do not fully understand what you are proposing, because
> this seems more like a list of what not to do, without a clear proposal
> (scope, deliverables) of what to do. You say ‘focus needs to be more on
> the network and how to create an open interface for integrating NSFs’ – OK,
> but what are the deliverables, when and how will we know that we are done?
>

I agree with Dan here, hence the questions I asked to the list.  I'd like
to hear more from Ed on what this interface would do as a black box, what
purpose would be served.

Having managed numerous types of firewalls and IDS/IPS systems, the points
you are making about the differences between them is not lost on me.  It's
not entirely clear to me what minimal set of services on a firewall could
be defined and if that would be helpful.  I agree that filtering makes
sense and can be automated (and has in the past - I did it with SNMP, a
script, and routers 20 years ago).

If you could elaborate on Dan's questions and what the interface you
propose would do, that would be helpful.

Thank you,
Kathleen

>
>
> Thanks and Regards,
>
>
>
> Dan
>
>
>
>
>
>
>
> *From:* Edward Lopez [mailto:[email-masked]]
> *Sent:* Monday, February 09, 2015 6:43 PM
> *To:* Romascanu, Dan (Dan)
> *Cc:* Linda Dunbar; Kathleen Moriarty; [email-masked]
> *Subject:* Re: [Newsletter] Re: [I2nsf] I2NSF charter for IESG Review
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i2nsf&d=AwMF-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=kCCuuzNSHFoHWmY48T1NzfaMUJQkhItWonkhHsDdsiY&s=j-_Y9L91qK6KvtaEdPizDky_F5zmcQW-DqyzFSoJDAs&e=>
>
>

-- 

Best regards,
Kathleen

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 10 Feb 2015 16:24:38 -0500

Linda:

Do you think my points below provide additional clarifying detail?  

Sue 

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, February 09, 2015 5:43 PM
To: Kathleen Moriarty; Edward Lopez
Cc: [email-masked]; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA
Subject: Re: [I2nsf] Many aspects are needed to seamlessly integrate vNSF to network (was RE: [Newsletter] Re: I2NSF charter for IESG Review

Kathleen, 

For example, 

 

[sue] You give a good description of the key capability you want to have. 

The key technology problems are:  

Create (or revise an existing architecture) that:

a.        allows customer requests to set/query functions vNSF (virtual function)

b.      allow vNSF to be virtual with distributed set of security functions with appropriate trust model. 

c.       allow vNSF to communicate with distributed security enforcement points in nodes (vCPE, vEPC)

d.      allow vNSF to collect or originate reports in publish or subscriber fashion.

[Sue]:  You have two portions:

                Customer client ---à vNSF ----à (network nodes) vCPE/vECP 

Sue:   This is a good point.  It provides a common set of functions for the vNSF that are interoperable (customer client app  to  vNSF to  network device).   

Linda

 

Thanks,

Kathleen

Regards,

Ed Lopez

Ed, 

 

 

       Customer   +     Access     +     Core

                  |                |     +--------+

                  |          ,-----+--.  |Network |

                  |        ,'      |   `-|Operator|

                  |    /           |   \          |

                  |   ;            |    +----+    |

                  |   |            |    |vNSF|    |

                  |   :            |    +----+    |

                  |    :           |   /          |

                  |       `--.     |      _.-'

                  |           `----+----''

                  +                +

 

 

      vNSF. (

 

Linda

Hi, 

Be goode,

Regards,

Ed Lopez

On Feb 8, 2015, at 3:36 AM, Romascanu, Dan (Dan) < <mailto:[email-masked]> [email-masked]> wrote:

Hi,

Regards,

Dan

From: I2nsf [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Friday, February 06, 2015 6:53 PM
To: Kathleen Moriarty
Cc:  <mailto:[email-masked]> [email-masked]
Subject: Re: [I2nsf] I2NSF charter for IESG Review

Kathleen,

Linda

From: Kathleen Moriarty [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Friday, February 06, 2015 10:48 AM
To: Linda Dunbar
Cc:  <mailto:[email-masked]> [email-masked]
Subject: Re: [I2nsf] I2NSF charter for IESG Review

Hi Linda,

Thanks.

On Fri, Feb 6, 2015 at 11:43 AM, Linda Dunbar < <mailto:[email-masked]> [email-masked]> wrote:

 

  - Use Case document.

  - Framework Document.

Suggested Milestones

_______________________________________________
I2nsf mailing list
 <mailto:[email-masked]> [email-masked]
 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i2nsf&d=AwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Nc9ckBdOaTTxu0o1HEzR7OUj8H3RzVu6pjtcwc7vICo&s=xc1E83x9xZQzPsOovUegJzvYeKC2I6mkxRoJ_wTZmBk&e=> https://www.ietf.org/mailman/listinfo/i2nsf

--

Best regards,

Kathleen

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

  _____  

  _____  

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

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041 <tel:%2B34%20913%20129%20041> 
Mobile: +34 682 051 091 <tel:%2B34%20682%20051%20091> 
----------------------------------

  _____  

  _____  

  _____  

 

-- 

Best regards,

Kathleen

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 10 Feb 2015 17:11:00 -0500

Ed: 

I agree that there can be many types of intent, but I think that integrating
intent within the network takes integrating all the virtual functions of IT
within a network (network, security, storage, and compute). 

To understand intent, you need to understand the virtual functions within
the Network.   The virtual router and virtual switch have been operating in
machines for the last 10+ years.  IETF has standardized L2VPN and L3VPN
protocol and management functions.  Is the vNSF box as well known?  If not,
I would advise splitting this work into two pieces: Defining the vNSF common
functionality, and defining an intent based interface.  

An Intent for a network needs to be coordinated with the intent based
functions in the network of (virtual network, virtual security function,
virtual storage, and virtual compute.) The [email-masked] – is looking into
integrating intent between these virtual functions.  The [email-masked] has
started with the virtual network functions (www.nemo-project.net).  

Sue 

From: I2nsf [mailto:[email-masked]] On Behalf Of Edward Lopez
Sent: Monday, February 09, 2015 8:06 PM
To: Linda Dunbar
Cc: [email-masked]; Romascanu, Dan (Dan); Kathleen Moriarty; DIEGO LOPEZ
GARCIA
Subject: Re: [I2nsf] Many aspects are needed to seamlessly integrate vNSF to
network (was RE: [Newsletter] Re: I2NSF charter for IESG Review

"Since there could be many types of intents, the I2NSF will focus on the
intents that are traditionally provided by FW/IPS/IDS"

I would like to see a statement that says that since there could be many
types of intents, we will NOT focus on the characteristics of any specific
intent, but focus our efforts on how to integrate any intent within the
network.

Vendor differentiation will never be eliminated (and in fact should be
encouraged!).  The concept of the so called "majority of vendors" implies
two of the three bad ideas we could do: indirectly apply a criteria that
defines a function, and seek a lowest common denominator across
implementations.  You will in effect be establishing an indirect set of
minimum security standards (to those manageable by an i2nsf interface).
>From my standpoint this would be an unacceptable result.

An analogy can be made relative to Common Criteria (CC) evaluation and
certification.  Originally and international standard,  vendors were at
first allowed to be evaluated on their own protection profiles.  You passed
evaluation if you did what you said you did.  But then CC changed in that
passing governmental generated protection profiles were more important, as
if the governments drafting the profiles had better knowledge than the
vendors did (it could be argued that relative to the U.S., there was likely
an effort by NIAP to keep the bar low).  As a result vendors began
publishing bulletins on how to operate their devices in a FIPS/CC mode,
which in most cases crippled the utility of the device.

Ed Lopez

On Feb 9, 2015, at 2:43 PM, Linda Dunbar <[email-masked]> wrote:

Kathleen, 

[Linda] It would be the Security Intent (or Service Layer) for clients to
specify what they desire (e.g. subscribe, query, monitor). Since there could
be many types of intents, the I2NSF will focus on the intents that are
traditionally provided by FW/IPS/IDS. 

For example, 

               Client X subscribes to the “enabling web filtering” service
with a list of criteria; 

scan email for malware detection [check type = malware] protect traffic to
corporate network with integrity and confidentiality [protection type =
integrity AND confidentiality] 

 

[Linda] Allow clients (Network Management system, or customer’s own
management system) to dynamically request vNSF for their traffic and
dynamically configure/monitor the security policies required for their vNSF.

[Linda]I would think so. I2NSF provides the mechanism for vNSF subscription,
monitoring, and security policies that are supported by majority vendors.
For vendor specific features, I2NSF only provides the mechanism. 

Linda

From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Monday, February 09, 2015 2:14 PM
To: Edward Lopez
Cc: Linda Dunbar; [email-masked]; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA
Subject: Re: [I2nsf] Many aspects are needed to seamlessly integrate vNSF to
network (was RE: [Newsletter] Re: I2NSF charter for IESG Review

Actually, I very much like this draft.  But what I'm not seeing is how that
statement #2 distills to the explicit terms FW/IPS/IDS in the charter.

Thanks,

Kathleen

Regards,

Ed Lopez

Ed, 

There are many aspects to be developed to achieve seamlessly integrating
NSFs onto networks.  The problem you described seems very broad, may require
multiple IETF WGs to tackle. 

 

       Customer   +     Access     +     Core

                  |                |     +--------+

                  |          ,-----+--.  |Network |

                  |        ,'      |   `-|Operator|

                  |    /           |   \          |

                  |   ;            |    +----+    |

                  |   |            |    |vNSF|    |

                  |   :            |    +----+    |

                  |    :           |   /          |

                  |       `--.     |      _.-'

                  |           `----+----''

                  +                +

 

Among the 3 actions listed in the Use Case draft, #1 & #3 don’t have to be
limited to specific security functions. But the #2 below has to start from
somewhere.  The FW/IPS/IDS in the charter are specifically for the #2 below.

      vNSF. (

 

Linda

Hi, 

While I fully agree with Ed in that we must not restrict the scope to a
particular set of (current or foreseen) NSF I don't see this goal
conflicting with Dan's point of including a couple of NSFs as targets to be
used as examples of the applicability of the interfaces we intend to define.
Probably the charter needs a carefully wording to make this clear...

Be goode,

- Narrowly define NSF categories or their roles ... Unfortunately, this is
rampant throughout this proposed charter

The real issue is how to seamlessly integrate NSFs onto networks.  There are
so many WGs where the complaints on how middleboxes break end-to-end
architectures, or themselves capitalize on vulnerabilities within standards
(TLS interception is a noted example) that there are now I-Ds that propose
their eradication, which I feel is a very naive concept.  The real benefit
is when we can define how the NSF interacts with the network, what
parameters we can pass to it, and what operational data we can get from it.

Regards,

Ed Lopez

On Feb 8, 2015, at 3:36 AM, Romascanu, Dan (Dan) <
<mailto:[email-masked]> [email-masked]> wrote:

Hi,

Regards,

Dan

From: I2nsf [ <mailto:[email-masked]> mailto:[email-masked]]
On Behalf Of Linda Dunbar
Sent: Friday, February 06, 2015 6:53 PM
To: Kathleen Moriarty
Cc:  <mailto:[email-masked]> [email-masked]
Subject: Re: [I2nsf] I2NSF charter for IESG Review

Kathleen,

We change the wording to make I2NSF focus on the security services that are
provided by traditional FW and IPS/IDS functions.

Linda

From: Kathleen Moriarty [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Friday, February 06, 2015 10:48 AM
To: Linda Dunbar
Cc:  <mailto:[email-masked]> [email-masked]
Subject: Re: [I2nsf] I2NSF charter for IESG Review

Hi Linda,

Thanks.

On Fri, Feb 6, 2015 at 11:43 AM, Linda Dunbar <
<mailto:[email-masked]> [email-masked]> wrote:

In order to address the above challenges, vNSF devices may include two
functional layers:

The Security Service and Policy Layer is for clients to express and monitor
security policies for their specific flows. This layer will leverage
existing protocols, such as those defined in Netconf, AAA, and SACM, to
carry new abstractions that support Discretionary Access Control, Mandatory
Access Control, Role Based Access Control, Attribute-Based Access Control,
Policy-Based Access Control, or combinations of these.

The Capability (or Functional) Layer specifies how client security policies
can request the capabilities of security devices, and then map security
policies to a form that security devices can use. This requires the
definition of an information model, along with one or more data models, to
represent virtual and physical security functions and devices. This layer
will leverage the existing protocols and data models defined by I2RS,
Netconf, and NETMOD.

The Interface to Network Security Functions (I2NSF) enables clients to
communicate their specific security services and policies
(request/monitor/report) to a system, and map these security policies to the
security functions present in security devices in that system.  I2NSF will
specify a set of standardized mechanisms for clients and applications to
request, negotiate, manage, and validate security functions using a
declarative programmatic interface to physical and virtual devices. In order
to support this programmatic interface, an Information Model will be defined
to serve as a common vocabulary of security policy concepts and security
device capabilities; associated Data Models will be derived from this
Information Model to support Operation, Administration, Maintenance and
Provisioning (OAMP) functions for security policies and security device
capabilities.  The models will include at least the services provided by the
following security functions:

 

Exemplar services associated with a firewall include stateful or deep packet
inspection, packet/flow/stream filtering, and redirection (remote and
local). Exemplar IDS/IDP functions includes flow/stream pattern matching and
remediation, respectively.

It is a non-goal to create new protocols or data modeling languages for
I2NSF interfaces.

  - Use Case document.

  - Framework Document.

  - Requirement for extensions (if there are any) to existing protocols used
by the WG.

  - A single, unified, Information Model for the security functions listed
above and associated capabilities.

  - Corresponding Data Models (e.g. YANG models) derived from the above
Information Model.

[The WG may decide that the Use cases, Framework, and Requirement are
Informational documents or simply reference documents during the lifetime of
the WG]

Suggested Milestones

  - Requirements for extensions to protocols:  Charter time + 6 months to WG
document

 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_l
istinfo_i2nsf&d=AwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfu
cBXRucPvdrphpBsFA&m=Nc9ckBdOaTTxu0o1HEzR7OUj8H3RzVu6pjtcwc7vICo&s=xc1E83x9xZ
QzPsOovUegJzvYeKC2I6mkxRoJ_wTZmBk&e=>
https://www.ietf.org/mailman/listinfo/i2nsf

--

Best regards,

Kathleen

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

  _____  

*** Please note that this message and any attachments may contain
you. *** 

  _____  

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

Dr Diego R. Lopez
Telefonica I+D

 

  _____  

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.

  _____  

*** Please note that this message and any attachments may contain
you. *** 

  _____  

 

-- 

Best regards,

Kathleen

  _____  

*** Please note that this message and any attachments may contain
you. *** 

  _____

---

From: Yoav Nir <[email-masked]>
Date: Sat, 14 Feb 2015 14:02:37 +0200

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

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 18 Feb 2015 17:44:39 +0000

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:[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

---

From: John Strassner <[email-masked]>
Date: Thu, 19 Feb 2015 22:12:23 +0000

Sorry for the delay…I’ve been out of the country and sick.

I think that Ed seems concerned that identifying a few specific security functions, which could be implemented as stand-alone devices, gives the impression that I2NSF is trying to model (or worse, focus) on those few functions. He said, “…proposing a standard of what a firewall management interface [is] should not result in a de-facto definition of what a firewall is.”

I agree with this, and want to point out that in a true information model, that shouldn’t happen anyway. For example, I would **never** model a switch as a subclass of a Device. Worse would be to model it as a subclass of an L2Device. Not that I’m a big fan of marketing terms, like an L4Switch, but the fact remains that a switch nowadays is, in its most generic form, a chassis that can hold a set of Cards, and each Card can provide one or more functions (e.g., firewall, load balancing, encryption, yada yada yada). Cards could even work together to provide a function. Given this flexibility, a much more robust way to model this is by modeling a set of **roles** that these functions play, and then associating the roles with the managed object (i.e., the switch in this example). That way, if I yank out one Card and put in a different Card, we don’t have to remodel the device, we instead just change the role(s) that it can play.

I also think that Ed’s suggestion of modeling the NSF as a black box, and defining how to integrate it into the network, is the right thing to do.

Now, to be honest, I didn’t draw the same conclusions as Ed did in reading the charter, but then I again, I edited the charter. So of course it makes sense to me. ☺

If incorporating (a much slimmed down) version of what I said above helps, great. If not, I’d suggest that we have a con call to discuss it and then propose it back to the group.

regards,
John

Dr. John Strassner, Ph.D.
CTO, Software Laboratory, CRD

Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050

  Office:  +1.408.330.4923
  Email:   [email-masked]

From: I2nsf [mailto:[email-masked]] On Behalf Of Edward Lopez
Sent: Monday, February 09, 2015 11:47 AM
To: Linda Dunbar
Cc: [email-masked]; Romascanu, Dan (Dan); Kathleen Moriarty; DIEGO LOPEZ GARCIA
Subject: Re: [I2nsf] Many aspects are needed to seamlessly integrate vNSF to network (was RE: [Newsletter] Re: I2NSF charter for IESG Review

Regards,
Ed Lopez

       Customer   +     Access     +     Core
                  |                |     +--------+
                  |          ,-----+--.  |Network |
                  |        ,'      |   `-|Operator|

Linda

Hi,

Be goode,

Regards,
Ed Lopez

Regards,

Dan

Kathleen,

Linda

Hi Linda,

Thanks.

  - Use Case document.
  - Framework Document.

Suggested Milestones

--

Best regards,
Kathleen

Dr Diego R. Lopez
Telefonica I+D

---

From: John Strassner <[email-masked]>
Date: Thu, 19 Feb 2015 22:49:23 +0000

Linda wrote:

I agree that there could be many types of intents. Look at the Open Source world: you have Congress, GBP, NIC, and several others. All claim to be intent-based, but your mileage will vary depending on your definition of intent.

To me, "intent" is declarative programming - say what you want to do, not how to do it.

The basic problem that we have in networking is that it has been assumed that it is "OK" to directly write to the device. Amusing, since most people would shudder at not using getters and setters in programming, and instead manipulating bits directly, but I digress. So, if any entity can write to the device, you have chaos, and neither intent nor unicorns will not, in and of themselves, solve this problem.

There seems to be an implied thesis here: if everyone just expresses intent, and then a mystical magical Unicorn-box can translate everyone's intent into commands each device can handle.

That won't work, even if there was **one** intent-based language, and even if we ignore nasty things like bugs and side effects, because most of the time, developers express syntax and forget about semantics.

Plus, conflict detection is **much harder** when expressed declaratively. You have to weed through (possibly multiple levels of) indirection in order to figure out that two intent-based policies do different things to the same object at the same time.

This is why, **I think**, Linda (and others) want to focus on a few small examples.

To which Ed wrote:
"I would like to see a statement that says that since there could be many types of intents, we will NOT focus on the characteristics of any specific intent, but focus our efforts on how to integrate any intent within the network."

It would be great to be able to design a box that could take routing intent, and QoS intent, and security intent, and others, make sense out of them all, and do the Right Thing. I think that this is too broad. However, I do agree with the spirit of what Ed wrote, but it needs to be constrained to at least a few (one?) types of **security** intent. This also helps differentiate our work from the work of other WGs.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: I2nsf [mailto:[email-masked]] On Behalf Of Edward Lopez
Sent: Monday, February 09, 2015 5:06 PM
To: Linda Dunbar
Cc: [email-masked]; Romascanu, Dan (Dan); Kathleen Moriarty; DIEGO LOPEZ GARCIA
Subject: Re: [I2nsf] Many aspects are needed to seamlessly integrate vNSF to network (was RE: [Newsletter] Re: I2NSF charter for IESG Review

Ed Lopez

What would this look like if the NSF were a black box?
[Linda] It would be the Security Intent (or Service Layer) for clients to specify what they desire (e.g. subscribe, query, monitor). Since there could be many types of intents, the I2NSF will focus on the intents that are traditionally provided by FW/IPS/IDS.
For example,
               Client X subscribes to the "enabling web filtering" service with a list of criteria;
              Client Y subscribes to the "deep packet inspection" and specifies the "Actions" for packets  matching the given criteria;
enable basic parental control
enable "school protection control"
allow Internet traffic from 8:30 to 20:00 [time = 8:30-20:00]
scan email for malware detection [check type = malware] protect traffic to corporate network with integrity and confidentiality [protection type = integrity AND confidentiality]
remove tracking data from Facebook [website = *.facebook.com<http://facebook.com>]
my son is allowed to access facebook from 18:30 to 20:00

What specific problems would be solved?
[Linda] Allow clients (Network Management system, or customer's own management system) to dynamically request vNSF for their traffic and dynamically configure/monitor the security policies required for their vNSF.

Linda

Thanks,
Kathleen

Regards,
Ed Lopez

       Customer   +     Access     +     Core
                  |                |     +--------+
                  |          ,-----+--.  |Network |
                  |        ,'      |   `-|Operator|

Linda

Hi,

Be goode,

Regards,
Ed Lopez

Regards,

Dan

Kathleen,

Linda

Hi Linda,

Thanks.

  - Use Case document.
  - Framework Document.

Suggested Milestones

--

Best regards,
Kathleen

Dr Diego R. Lopez
Telefonica I+D

--

Best regards,
Kathleen

---

From: John Strassner <[email-masked]>
Date: Thu, 19 Feb 2015 23:05:40 +0000

Please see inline...

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: I2nsf [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, February 10, 2015 2:11 PM
To: 'Edward Lopez'; Linda Dunbar
Cc: [email-masked]; 'Romascanu, Dan (Dan)'; 'Kathleen Moriarty'; 'DIEGO LOPEZ GARCIA'
Subject: Re: [I2nsf] Many aspects are needed to seamlessly integrate vNSF to network (was RE: [Newsletter] Re: I2NSF charter for IESG Review

Ed:

I agree that there can be many types of intent, but I think that integrating intent within the network takes integrating all the virtual functions of IT within a network (network, security, storage, and compute).
<js>
I'm not sure I follow. First, why only virtual? If legacy can't use this, I don't think we will have a good deployment case.

Second, this seems to assume that each of these virtual functions is orthogonal and easily categorized. I don't agree. A simple firewall appliance has all four of these.
</js>

To understand intent, you need to understand the virtual functions within the Network.
<js>
Why? Intent should not have to know how the functions work. Intent should just declaratively specify what it wants. Now, this is very hard to program, so it does make sense to constrain this somehow. For example, if the NSF was associated with a set of capabilities, then the intent-based language could work against just those capabilities to specify what it needs. Even in this case, however, I don't see why intent should understand anything more than what capabilities are available.
</js>

   The virtual router and virtual switch have been operating in machines for the last 10+ years.  IETF has standardized L2VPN and L3VPN protocol and management functions.  Is the vNSF box as well known?  If not, I would advise splitting this work into two pieces: Defining the vNSF common functionality, and defining an intent based interface.
<js>
Absolutely. I thought that this was what people meant when they said "service" vs. "function".
</js>

An Intent for a network needs to be coordinated with the intent based functions in the network of (virtual network, virtual security function, virtual storage, and virtual compute.) The [email-masked]<mailto:[email-masked]> - is looking into integrating intent between these virtual functions.  The [email-masked]<mailto:[email-masked]> has started with the virtual network functions (www.nemo-project.net<http://www.nemo-project.net>).
<js>
I don't see how you can do this without a much more robust information model and language
</js>

Sue

Ed Lopez

Linda

Thanks,
Kathleen

Regards,
Ed Lopez

       Customer   +     Access     +     Core
                  |                |     +--------+
                  |          ,-----+--.  |Network |
                  |        ,'      |   `-|Operator|

Linda

Hi,

Be goode,

Regards,
Ed Lopez

Regards,

Dan

Kathleen,

Linda

Hi Linda,

Thanks.

  - Use Case document.
  - Framework Document.

Suggested Milestones

--

Best regards,
Kathleen

Dr Diego R. Lopez
Telefonica I+D

--

Best regards,
Kathleen

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 27 Feb 2015 18:32:30 +0000

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

Hi

Yoav