Subject: [i2rs] revised charter for I2NSF

From: Linda Dunbar <[email-masked]>
Date: Tue, 3 Feb 2015 00:08:40 +0000

Based on the recent discussion on the I2NSF list, here is the revised charter for I2NSF. Copied to I2RS group to get wider review because I2NSF is related to I2RS in such a way that  I2RS provides the interface to Router whereas I2NSF provides the interfaces to security functions.

In a nutshell, The Interface to Network Security Functions (I2NSF) is to discuss interfaces for clients or application gateways to communicate their specific security policies (request/monitor/report) with security controller and security functions.  I2NSF will specify the information model, along with adequate data models, and protocols required for the Operation, Administration, Maintenance and Provisioning (OAM) for the following security functions:

*       Firewall

*       DDOS/Anti-DOS

*       Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)

*       Access control/Authorization/Authentication

There are two distinct interfaces for I2NSF:

-          Capability (or Functional) Layer interface between Security Controller, which could be embedded in a network controller, and Security devices (virtual & physical), which focuses more on the functional aspects of the functions listed above.

-          Service Layer Interface between Clients (or App Gateway) and the Security Controller,  which is for clients or App Gateway to express/monitor the needed security policies (e.g. develop a security policy language based on NIST endorsed Role Based Access Control.)

I2NSF WG Deliverables for the Functional/Capability Layer Interface include:

-          Develop a comprehensive set of informational Models for the following functions with regard to different aspects of OAM (Operations/Administration/Maintenance). For example: extending the ACL data model to be more comprehensive, e.g.  including multiple actions and policies.

o   Firewall

o   DDOS/Anti-DOS

o   Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)

-          Develop the corresponding Data Models, e.g. YANG model.

-          Specify the secure mechanisms to carry the content identified by the informational/data models. E.g. TLS to carry the information.

I2NSF WG Deliverables for the Service Layer Interface include:
*       Develop policy description (or language) for clients or App Gateway to express/monitor the needed security policies (e.g. develop a security policy language based on NIST endorsed Role Based Access Control.)
-      E.g. Develop comprehensive set of "TARGETs" for the Security Intent.   Security Target in Data Centers network, in Access Network, in Wide Area network, etc
-      Develop descriptors for "Users", "Roles", "Permissions"

*       Develop the corresponding information or Data Models, e.g. YANG model.
*       Compare with existing IETF protocols for "Roles", "Users", "Permissions", etc.

In addition, the I2NSF working group will
*        Document a high-level I2NSF framework that describes Services and Capability layers interfaces and defines a reference model along with functional components at each layer.
-      Terminology draft may be included in the framework or becomes a standalone draft.
*       Document small and well-scoped use cases to constrain the scope of the work and achieve sufficient focus for the working group to deliver successful outcomes. And

*        Analyze candidate protocols that may carry the information to be exchanged through the various interfaces.

-      E.g. Compare with existing IETF protocols for "OBJECTs, ACTIONs, FILTERING, etc" (e.g. PCP, Radius, etc) .

Looking for comments and suggestions.

Linda Dunbar

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 3 Feb 2015 07:31:36 -0500

Linda: 

Thank you for your encouragement to send comments on the gap-analysis and
the use cases to the list.   A few suggestions for the sequences of your
charter events: 

I think that getting use cases, framework and protocol requirements is
critical.  Since the security area has a strong terminology draft, maybe you
can just create an online update to that one.  

IMHO, I think it is important to have a goal of using existing protocols or
extending these protocols.   Adjusting your charter to indicate this at
every step would prevent duplication of IETF work and increase the speed of
development of your protocol. 

The capability (or functional) layer between controller and network devices
may be able to leverage existing protocols in SACM, AAA, rtgwg, netmod,
netconf/restconf, or other protocols.  Or it may be able to be a combination
of these protocols.  Instead of in addition, the WG should consider this at
the beginning.   

Making a decision on what type of service-based interface is important
during the framework.  If you wish an intent-based application driven
interface, this may be different than the intent based or comprehensive API.

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, February 02, 2015 7:09 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [i2rs] revised charter for I2NSF

Based on the recent discussion on the I2NSF list, here is the revised
charter for I2NSF. Copied to I2RS group to get wider review because I2NSF is
related to I2RS in such a way that  I2RS provides the interface to Router
whereas I2NSF provides the interfaces to security functions.

In a nutshell, The Interface to Network Security Functions (I2NSF) is to
discuss interfaces for clients or application gateways to communicate their
specific security policies (request/monitor/report) with security controller
and security functions.  I2NSF will specify the information model, along
with adequate data models, and protocols required for the Operation,
Administration, Maintenance and Provisioning (OAM) for the following
security functions:

.         Firewall

.         DDOS/Anti-DOS 

.         Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)

.         Access control/Authorization/Authentication

-          Capability (or Functional) Layer interface between Security
Controller, which could be embedded in a network controller, and Security
devices (virtual & physical), which focuses more on the functional aspects
of the functions listed above. 

-          Service Layer Interface between Clients (or App Gateway) and the
Security Controller,  which is for clients or App Gateway to express/monitor
the needed security policies (e.g. develop a security policy language based
on NIST endorsed Role Based Access Control.)

-          Develop a comprehensive set of informational Models for the
following functions with regard to different aspects of OAM
(Operations/Administration/Maintenance). For example: extending the ACL data
model to be more comprehensive, e.g.  including multiple actions and
policies.

o   Firewall 

o   DDOS/Anti-DOS 

-          Specify the secure mechanisms to carry the content identified by
the informational/data models. E.g. TLS to carry the information. 

.       Develop policy description (or language) for clients or App Gateway
to express/monitor the needed security policies (e.g. develop a security
policy language based on NIST endorsed Role Based Access Control.)

-      E.g. Develop comprehensive set of "TARGETs" for the Security Intent.
Security Target in Data Centers network, in Access Network, in Wide Area
network, etc

.       Develop the corresponding information or Data Models, e.g. YANG
model. 

.       Compare with existing IETF protocols for "Roles", "Users",
"Permissions", etc. 

.        Document a high-level I2NSF framework that describes Services and
Capability layers interfaces and defines a reference model along with
functional components at each layer. 

-      Terminology draft may be included in the framework or becomes a
standalone draft.

.       Document small and well-scoped use cases to constrain the scope of
the work and achieve sufficient focus for the working group to deliver
successful outcomes. And

.        Analyze candidate protocols that may carry the information to be
exchanged through the various interfaces. 

-      E.g. Compare with existing IETF protocols for "OBJECTs, ACTIONs,
FILTERING, etc" (e.g. PCP, Radius, etc) . 

Linda Dunbar

---

From: "Russ White" <[email-masked]>
Date: Tue, 3 Feb 2015 08:34:31 -0500

Interesting concept. One thought that might be helpful -- 

> *         Access control/Authorization/Authentication

I think I would try to frame things in terms of services, rather than
devices, or a mix of the two. For instance -- what does a "firewall" really
do? Stateful packet inspection, deep packet inspection, and... ?? So maybe a
list something like this might make sense -- (and remember, this is
brainstorming, nothing more) --

- Stateful packet inspection
- Deep packet inspection
- Packet/flow/stream filtering (remote and local)
- Packet/flow/stream redirect (remote and local)
- Intrusion detection (or perhaps flow/stream pattern matching?)
- AAA

Don't know if this is a useful line of thought or not.

:-)

Russ

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 3 Feb 2015 09:36:05 -0500

Sorry for the top-post. I am not subscribed to the i2nsf list.  Some comments inline below.

	In general my comment on the latest charter are that I am puzzled as the point of this proposed WG charter is.   Anyone working in the controller space these days will be scratching their head as I have been after reading this charter just now.  My suggestion is that if you indeed want to embark on the work described below, that you do it within the context of some reference implementation (most of the popular ones will suffice) which may reveal some of the points I am raising below.

> On Feb 3, 2015:7:31 AM, at 7:31 AM, Susan Hares <[email-masked]> wrote:
> 
> Linda: 
>  
> Thank you for your encouragement to send comments on the gap-analysis and the use cases to the list.   A few suggestions for the sequences of your charter events: 
>  
> I think that getting use cases, framework and protocol requirements is critical.  Since the security area has a strong terminology draft, maybe you can just create an online update to that one.  
>  
> IMHO, I think it is important to have a goal of using existing protocols or extending these protocols.   Adjusting your charter to indicate this at every step would prevent duplication of IETF work and increase the speed of development of your protocol. 
>  
> The capability (or functional) layer between controller and network devices may be able to leverage existing protocols in SACM, AAA, rtgwg, netmod, netconf/restconf, or other protocols.  Or it may be able to be a combination of these protocols.  Instead of in addition, the WG should consider this at the beginning.   
>  
> Making a decision on what type of service-based interface is important during the framework.  If you wish an intent-based application driven interface, this may be different than the intent based or comprehensive API. 
>  
> Sue 
>  
>  
> From: i2rs [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Linda Dunbar
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> In a nutshell, The Interface to Network Security Functions (I2NSF) is to discuss interfaces for clients or application gateways to communicate

	Is the purpose here to "discuss" or to "create" interfaces?  If it is the former, I am not sure what the point of the WG would be. If the latter, those things being done in other WGs across the routing area or outside of the IETF already.

> their specific security policies (request/monitor/report) with security controller and security functions.  I2NSF will specify the information model, along with adequate data models, and protocols required for the Operation, Administration, Maintenance and Provisioning (OAM) for the following security functions:
> ·         Firewall
> ·         DDOS/Anti-DOS 
> ·         Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)
> ·         Access control/Authorization/Authentication
>  

	No such layer is needed. Take a look at the commercial controllers that are out there and you will see that its a part of the protocols already, or people re-use existing (well designed) systems such as RADIUS, etc....

> -          Service Layer Interface between Clients (or App Gateway) and the Security Controller,  which is for clients or App Gateway to express/monitor the needed security policies (e.g. develop a…

	What would a "service layer interface" be?  Today controllers like OpenDaylight use RestConf and NetConf. Those are perfectly well specified interfaces that come with various security mechanisms built-in right out of the box.  What else is needed?  If you claim you want to put RADIUS or AAA or something else in there, that is done as a side action within the context of those things already.  This already works BTW, so again, I am not sure what would be achieved here.

> -          Develop the corresponding Data Models, e.g. YANG model. 

	Again, these are being done in other places already.  What are you trying to accomplish here?

> -          Specify the secure mechanisms to carry the content identified by the informational/data models. E.g. TLS to carry the information. 

	Since we are talking about Yang models, I assume the transport/protocol is Netconf or RestConf. Why would you re-specify that TLS/SSL be used for Netconf or RestConf?  
If you want to change something in those protocols, I suggest you stop by the Netconf WG.  Other options such as SNMP already have this specified too in case you were
thinking of going there.

> •       Develop policy description (or language) for clients or App Gateway to express/monitor the needed security policies (e.g. develop a security policy language based on NIST endorsed Role Based Access Control.)
> –      E.g. Develop comprehensive set of “TARGETs” for the Security Intent.   Security Target in Data Centers network, in Access Network, in Wide Area network, etc
> –      Develop descriptors for “Users”, “Roles”, “Permissions”
>  
> •       Develop the corresponding information or Data Models, e.g. YANG model. 
> •       Compare with existing IETF protocols for “Roles”, “Users”, “Permissions”, etc. 

	What would such a policy description achieve?  There are already policy models out there: Congress from Openstack, GBP/Intent/ODL, op-nfv policy, Op-flex, etc...    Do we need another one?
I'd recommend that you take a look at the significant work (and implementations) that have been done over in those places.

> •        Document a high-level I2NSF framework that describes Services and Capability layers interfaces and defines a reference model along with functional components at each layer. 
> –      Terminology draft may be included in the framework or becomes a standalone draft.

	What would yet another "framework" achieve?  Seriously, we should be worried about building these things rather than documenting all sorts of theoretical scenarios.

	--Tom

> •       Document small and well-scoped use cases to constrain the scope of the work and achieve sufficient focus for the working group to deliver successful outcomes. And
>  
> •        Analyze candidate protocols that may carry the information to be exchanged through the various interfaces. 
> –      E.g. Compare with existing IETF protocols for “OBJECTs, ACTIONs, FILTERING, etc” (e.g. PCP, Radius, etc) . 
>  
> _______________________________________________
> i2rs mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/i2rs <https://www.ietf.org/mailman/listinfo/i2rs>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 3 Feb 2015 20:10:38 +0000

Tom,

Your points taken, there are many types of controllers in SDN paradigm. Throwing one more can be confusing.

The “security controller” in the context of I2NSF can be viewed as an adapter between Security Service Request (e.g. allow traffic with specific fields for specific time span) and the security device specific information model.

Yes, we will have a  “reference implementation” to make the discussion more focused.

Thanks, Linda

From: i2rs [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: Tuesday, February 03, 2015 8:36 AM
To: Susan Hares; Linda Dunbar; [email-masked]; [email-masked]; [email-masked]; Benoit Claise
Subject: Re: [i2rs] revised charter for I2NSF

On Feb 3, 2015:7:31 AM, at 7:31 AM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

Linda:

Sue

From: i2rs [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, February 02, 2015 7:09 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [i2rs] revised charter for I2NSF

their specific security policies (request/monitor/report) with security controller and security functions.  I2NSF will specify the information model, along with adequate data models, and protocols required for the Operation, Administration, Maintenance and Provisioning (OAM) for the following security functions:
•         Firewall
•         DDOS/Anti-DOS
•         Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)
•         Access control/Authorization/Authentication

            --Tom

Linda Dunbar

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

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 4 Feb 2015 16:25:09 +0000

Russ, 

Thank you very much for the suggestion of framing in terms of services. What do you think with the following changes to the I2NSF charter with your suggestions added?

In a nutshell, The Interface to vNSF (I2NSF) allows clients to communicate their specific security policies (request/monitor/report) to security functions.  I2NSF will specify a vNSF framework, requirements for programmatic interface to vNSF devices (configuration and dynamic programmatic)   , and Information and Data models for security functions' Operation, Administration, Maintenance and Provisioning (OAM).  The information models will include the following security functions:

*	Firewall 
	including various services associated with FW, such as stateful or deep packet inspection,  packet/flow/stream filtering and redirect (remote and local), etc

*	Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)
	Including intrusion detection (flow/stream pattern matching)

Linda

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Russ White
Sent: Tuesday, February 03, 2015 7:35 AM
To: 'Susan Hares'; Linda Dunbar; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [i2rs] revised charter for I2NSF

> *         Access control/Authorization/Authentication

I think I would try to frame things in terms of services, rather than devices, or a mix of the two. For instance -- what does a "firewall" really do? Stateful packet inspection, deep packet inspection, and... ?? So maybe a list something like this might make sense -- (and remember, this is brainstorming, nothing more) --

:-)

Russ

[email-masked]

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 4 Feb 2015 11:37:04 -0500

> On Feb 4, 2015:11:25 AM, at 11:25 AM, Linda Dunbar <[email-masked]> wrote:
> 
> Russ, 
> 

	Why wouldn't you do the models for those OAM functions where those functions are modeled already?  I don't see the need for a special WG that creates a subset of models that can done elsewhere like in LIME, or the Routing Area groups that are already chartered to do this stuff.  

	This leaves just doing requirements and a framework for this proposed group, which without clear goals to build things from is a WG looking for a reason to exist rather than the other way around.

	--Tom

---

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

Thomas, 

Comments inserted below:

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: Wednesday, February 04, 2015 10:37 AM
To: Linda Dunbar
Cc: Russ White; [email-masked]; [email-masked]; Susan Hares; [email-masked]
Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF

[Linda] LIME addresses OAM for network layer, connectivity (link/port) failures, end to end performances measurement, whereas I2NSF is for security policies to be enforced by distributed (virtual) network security functions (vNSF). I2NSF provides a standard interface to express, monitor, and manage the security policies across distributed security functions that may be running on different premises.

	--Tom

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 4 Feb 2015 14:50:22 -0500

> On Feb 4, 2015:2:44 PM, at 2:44 PM, Linda Dunbar <[email-masked]> wrote:
> 
> 
> Thomas, 
> 
> Comments inserted below:
> 

[TOM] The salient point I have been trying to make is that i2nsf does not exist; LIME does. Why not just do it there (and other existing places in the IETF)?  We seem to be working REALLY hard here to make up reasons why we need to form a new working group. I'd contend that it is not needed and that the management overhead + other overhead of reviewing/processing documents like a new framework, requirements, etc... will unnecessarily spend precious IETF resources.

	--Tom

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 4 Feb 2015 20:02:17 +0000

Tom,

I2NSF in its most recent (and better focused) charter includes IMs and DMs for firewalls and IDSs, as well as a framework to manage virtualized security services. Does LIME or other WG in the IETF do any of these? 

Regards,

Dan

> Sent: Wednesday, February 04, 2015 9:50 PM
> To: Linda Dunbar
> Cc: Russ White; [email-masked]; Susan Hares; [email-masked]; [email-masked]
> >> Thank you very much for the suggestion of framing in terms of services.
> What do you think with the following changes to the I2NSF charter with your
> suggestions added?
> >>
> >> In a nutshell, The Interface to vNSF (I2NSF) allows clients to communicate
> their specific security policies (request/monitor/report) to security functions.
> I2NSF will specify a vNSF framework, requirements for programmatic
> interface to vNSF devices (configuration and dynamic programmatic)   , and
> Information and Data models for security functions' Operation,
> Administration, Maintenance and Provisioning (OAM).  The information
> models will include the following security functions:
> >
> > 	Why wouldn't you do the models for those OAM functions where
> those functions are modeled already?  I don't see the need for a special WG
> that creates a subset of models that can done elsewhere like in LIME, or the
> Routing Area groups that are already chartered to do this stuff.
> >
> > [Linda] LIME addresses OAM for network layer, connectivity (link/port)
> failures, end to end performances measurement, whereas I2NSF is for
> security policies to be enforced by distributed (virtual) network security
> functions (vNSF). I2NSF provides a standard interface to express, monitor,
> and manage the security policies across distributed security functions that
> may be running on different premises.
> 
> [TOM] The salient point I have been trying to make is that i2nsf does not
> exist; LIME does. Why not just do it there (and other existing places in the
> IETF)?  We seem to be working REALLY hard here to make up reasons why
> we need to form a new working group. I'd contend that it is not needed and
> that the management overhead + other overhead of reviewing/processing
> documents like a new framework, requirements, etc... will unnecessarily
> spend precious IETF resources.
> 
> 	--Tom
> 
> 
> > 	This leaves just doing requirements and a framework for this
> proposed group, which without clear goals to build things from is a WG
> looking for a reason to exist rather than the other way around.
> >
> > 	--Tom
> >
> >
> >
> >>
> >> *	Firewall
> >> 	including various services associated with FW, such as stateful or
> deep packet inspection,  packet/flow/stream filtering and redirect (remote
> and local), etc
> >>
> devices, or a mix of the two. For instance -- what does a "firewall" really do?
> Stateful packet inspection, deep packet inspection, and... ?? So maybe a list
> something like this might make sense -- (and remember, this is
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_i2rs&d=AwICAg&c=BFpWQw8bsuKpl1S
> giZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=ZXR0kNB
> 30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=YlZUo4btDn8UA3sAV2F_rWaL
> TDFHlxo1ys_wiueV8NI&e=
> >>
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_i2rs&d=AwICAg&c=BFpWQw8bsuKpl1S
> giZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=ZXR0kNB
> 30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=YlZUo4btDn8UA3sAV2F_rWaL
> TDFHlxo1ys_wiueV8NI&e=
> >>
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_i2nsf&d=AwICAg&c=BFpWQw8bsuKpl1
> SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=ZXR0kN
> B30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=Aag4Z_qnWDkR36ft_q-
> U7rpbPenEFmJgJ11F9yjW29E&e=
> >
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_i2nsf&d=AwICAg&c=BFpWQw8bsuKpl1
> SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=ZXR0kN
> B30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=Aag4Z_qnWDkR36ft_q-
> U7rpbPenEFmJgJ11F9yjW29E&e=

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 4 Feb 2015 15:36:47 -0500

They certainly could, without the added management overhead of a new WG.

	--Tom

> On Feb 4, 2015:3:02 PM, at 3:02 PM, Romascanu, Dan (Dan) <[email-masked]> wrote:
> 
> Tom,
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 4 Feb 2015 22:22:12 +0000

Tom, 

Will those existing WGs you mentioned also do the following?

- a standard interface to express, monitor, and verify the security policies on distributed security functions that may be running on different premises.

This layer will leverage the existing protocols in RESTconf, AAA, SACM, and security policy expression using Role Based Access Control (RBAC), Mandatory Access Control (MAC), or Attribute-based access control (ABAC).

Those WGs charters don't have those objectives. 

Thanks, Linda

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]] 
Sent: Wednesday, February 04, 2015 2:37 PM
To: Romascanu, Dan (Dan)
Cc: Linda Dunbar; Russ White; [email-masked]; Susan Hares; [email-masked]; [email-masked]
Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF

	--Tom

>> What do you think with the following changes to the I2NSF charter 
>> with your suggestions added?
>>>> 
>> those functions are modeled already?  I don't see the need for a 
>> special WG that creates a subset of models that can done elsewhere 
>> like in LIME, or the Routing Area groups that are already chartered to do this stuff.
>>> 
>> security policies to be enforced by distributed (virtual) network 
>> security functions (vNSF). I2NSF provides a standard interface to 
>> express, monitor, and manage the security policies across distributed 
>> security functions that may be running on different premises.
>> 
>> [TOM] The salient point I have been trying to make is that i2nsf does 
>> not exist; LIME does. Why not just do it there (and other existing 
>> places in the IETF)?  We seem to be working REALLY hard here to make 
>> up reasons why we need to form a new working group. I'd contend that 
>> it is not needed and that the management overhead + other overhead of 
>> reviewing/processing documents like a new framework, requirements, 
>> etc... will unnecessarily spend precious IETF resources.
>> 
>> 	--Tom
>> 
>> 
>> proposed group, which without clear goals to build things from is a 
>> WG looking for a reason to exist rather than the other way around.
>>> 
>>> 	--Tom
>>> 
>>> 
>>> 
>>>> 
>>>> *	Firewall
>> deep packet inspection,  packet/flow/stream filtering and redirect 
>> (remote and local), etc
>>>> 
>> Stateful packet inspection, deep packet inspection, and... ?? So 
>> maybe a list something like this might make sense -- (and remember, 
>> this is brainstorming, nothing more) --
>>>>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 4 Feb 2015 20:19:55 -0500

> On Feb 4, 2015:5:22 PM, at 5:22 PM, Linda Dunbar <[email-masked]> wrote:
> 
> Tom, 
> 

	As I've mentioned before, Yang models for any of these things can and are underway today.
I couldn't agree more that they are not needed. 

	However, regarding the other stuff, I invite you to look at just two examples of what is going on outside of the IETF.  
These are real implementations documented publicly in some cases such as Comcast presented at the last Openstack summit.

	https://wiki.opendaylight.org/view/Network_Intent_Composition:Main

	https://wiki.openstack.org/wiki/Congress

	Based on that, I really don't see any need to do any of this work in a new WG. Not only will it be a duplicate of a lot 
of actual work already being done elsewhere, as far as I can tell, it will not be doing so based on any real implementations/deployments 
(i.e.: "running code" from the IETF's mantra). Or have I missed something?

> Those WGs charters don't have those objectives. 
	
	That doesn't mean they couldn't be added to existing ones. I'd also bet that is easier than lifting off a new WG 
to accomplish these goals and will be more efficient as we won't be adding the extra management/processing overhead to
the already heavy load at the IETF.  

	--Tom

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 5 Feb 2015 02:00:34 +0000

Tom, 

Thank you for the link to OpenDayLight and OpenStack on the intent driven open source initiatives. We contribute to OpenStack and ODL as well.
That was very drive that started I2NSF initiative at IETF.  
Open source projects like OpenStack and CloudStack have begun to tackle the interfaces to security functions but much work remains. There are many pieces of open sourced code, and there are a lot of areas not covered. The combined contributed source code are not comprehensive. 

OpenStack completed the Firewall as a Service project and specified the set of APIs for Firewall services: http://docs.openstack.org/admin-guide-cloud/content/fwaas_api_abstractions.html

OpenStack has defined the APIs for managing Security Groups: http://docs.openstack.org/admin-guide-cloud/content/securitygroup_api_abstractions.html

The attributes defined by OpenStack Firewall/Security as a Service are very primitive.  they can be the basis for the I2NSF IETF initiative.

Our goal is to form a Collaborative Loop from IETF to Industry Open Source Communities (as Dave Ward said at Nov IETF Lunch session). 

This is Diego Lopez (ETSI NFV Technical Committee chair) said about IETF and Open Source initiatives:

Open-source initiatives are not to be considered as an alternative to formal standardization processes. On the contrary, they are complementary, with the former acting as an enabler and accelerator of the latter. Open-source provides an ideal mechanism to quick prototyping and validating contending proposals, and demonstrating the feasibility of disruptive ideas that could otherwise not be considered. In this respect, open-source facilitates the engagement in the standardization process of small (and typically more dynamic) players such as start-ups and research groups, that would see better opportunities of being heard and a clearer rewards to their efforts. An open-source approach is extremely useful as well for the production of open reference implementations of the standards at the same (or even faster) pace they are defined. The availability of such reference implementations translate into much simpler interoperability and conformance assessments for both providers and users, and can become the basis for incremental differentiation of a common solution, thus allowing a cooperative competition ("coopetition") model.

Linda
-----Original Message-----

	Based on that, I really don't see any need to do any of this work in a new WG. Not only will it be a duplicate of a lot of actual work already being done elsewhere, as far as I can tell, it will not be doing so based on any real implementations/deployments
(i.e.: "running code" from the IETF's mantra). Or have I missed something?

> Those WGs charters don't have those objectives. 
	
	That doesn't mean they couldn't be added to existing ones. I'd also bet that is easier than lifting off a new WG to accomplish these goals and will be more efficient as we won't be adding the extra management/processing overhead to the already heavy load at the IETF.  

	--Tom

>>> express, monitor, and manage the security policies across 
>>> distributed security functions that may be running on different premises.
>>> 
>>> [TOM] The salient point I have been trying to make is that i2nsf 
>>> does not exist; LIME does. Why not just do it there (and other 
>>> existing places in the IETF)?  We seem to be working REALLY hard 
>>> here to make up reasons why we need to form a new working group. I'd 
>>> contend that it is not needed and that the management overhead + 
>>> other overhead of reviewing/processing documents like a new 
>>> framework, requirements, etc... will unnecessarily spend precious IETF resources.
>>> 
>>> 	--Tom
>>> 
>>>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 5 Feb 2015 07:34:21 -0500

> On Feb 4, 2015:9:00 PM, at 9:00 PM, Linda Dunbar <[email-masked]> wrote:
> 
> Tom, 
> 

	There is no question that collaborative efforts make sense.  However, lets again get back to the specifics of this proposal and
where you would collaborate.  Models can and are being done elsewhere at the IETF and outside of it. Policy is being
done in those organizations just referenced. Why would those organizations need yet another one to be specifying policy constructs?  
What specific value would this new WG add to the equation (or subtract from it)? You have not made a good case as to why in my opinion.

	--Tom

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 6 Feb 2015 13:04:59 -0500

Tom:

I'm catching up with emails after a few days of I2RS interims and design
teams - so I apologize if this comes out of sequence. 

LIME has a solid basis in looking at generic OAM modules.  I would not like
to see the generic OAM work of LIME defocused by defining the vNSF
functions.  The two efforts work better in parallel.  An example of this is
the LIME OAM and the TRILL yang models (oam, fm, pm) with I2RS modules
upcoming.  You can look at IETF 90 for TIssa's original proposal in TRILL. 

The presentations and the ETSI work has demonstrated the desire for the vNSF
requirements to be standardized.  A WG with a short-term focus of defining
Security and Networking people to decide what is needed for an interoperable
vNSF.  This type of effort creates a 12-18 month WG life-cycle that should
aid OAM in LIME and the mechanisms in netconf/restconf. 

Sue  

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]] 
Sent: Wednesday, February 04, 2015 2:50 PM
To: Linda Dunbar
Cc: Russ White; [email-masked]; [email-masked]; Susan Hares; [email-masked]
Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF

>> 
>> In a nutshell, The Interface to vNSF (I2NSF) allows clients to
communicate their specific security policies (request/monitor/report) to
security functions.  I2NSF will specify a vNSF framework, requirements for
programmatic interface to vNSF devices (configuration and dynamic
programmatic)   , and Information and Data models for security functions'
Operation, Administration, Maintenance and Provisioning (OAM).  The
information models will include the following security functions:
> 
> 	Why wouldn't you do the models for those OAM functions where those
functions are modeled already?  I don't see the need for a special WG that
creates a subset of models that can done elsewhere like in LIME, or the
Routing Area groups that are already chartered to do this stuff.  
> [Linda] LIME addresses OAM for network layer, connectivity (link/port)
failures, end to end performances measurement, whereas I2NSF is for security
policies to be enforced by distributed (virtual) network security functions
(vNSF). I2NSF provides a standard interface to express, monitor, and manage
the security policies across distributed security functions that may be
running on different premises.

[TOM] The salient point I have been trying to make is that i2nsf does not
exist; LIME does. Why not just do it there (and other existing places in the
IETF)?  We seem to be working REALLY hard here to make up reasons why we
need to form a new working group. I'd contend that it is not needed and that
the management overhead + other overhead of reviewing/processing documents
like a new framework, requirements, etc... will unnecessarily spend precious
IETF resources.

	--Tom

---

From: "Russ White" <[email-masked]>
Date: Fri, 6 Feb 2015 17:57:05 -0500

> The presentations and the ETSI work has demonstrated the desire for the
> vNSF requirements to be standardized.  A WG with a short-term focus of
> defining Security and Networking people to decide what is needed for an
> interoperable vNSF.  This type of effort creates a 12-18 month WG
life-cycle
> that should aid OAM in LIME and the mechanisms in netconf/restconf.

I would agree with this assessment... 

:-)

Russ