Subject: [I2nsf] WG Action: Formed Interface to Network Security Functions (i2nsf)

From: The IESG <[email-masked]>
Date: Fri, 18 Sep 2015 08:24:29 -0700

A new IETF working group has been formed in the Security Area. For
additional information please contact the Area Directors or the WG
Chairs.

Interface to Network Security Functions (i2nsf)
------------------------------------------------
Current Status: Proposed WG

Chairs:
  Adrian Farrel <[email-masked]>
  Linda Dunbar <[email-masked]>

Assigned Area Director:
  Kathleen Moriarty <[email-masked]>

Mailing list
  Address: [email-masked]
  To Subscribe: https://www.ietf.org/mailman/listinfo/i2nsf 
  Archive: https://mailarchive.ietf.org/arch/browse/i2nsf/

Charter:

A Network Security Function (NSF) is a function used to ensure integrity,
confidentiality, or availability of network communications, to detect
unwanted network activity, or to block or at least mitigate the effects
of unwanted activity. NSFs are provided and consumed in increasingly
diverse environments. Users could consume network security services
enforced by NSFs hosted by one or more providers, which may be their own
enterprise, service providers, or a combination of both.  Similarly,
service providers may offer their customers network security services
that are enforced by multiple security products, functions from different
vendors, or open source technologies. NSFs may be provided by physical
and/or virtualized infrastructure. Without standard interfaces to control
and monitor the behavior of NSFs, it has become virtually impossible for
providers of security services to automate service offerings that utilize
different security functions from multiple vendors.

The goal of I2NSF is to define a set of software interfaces and data
models for controlling and monitoring aspects of physical and virtual
NSFs, enabling clients to specify rulesets. If the working group finds it
necessary to work on an information model before the data models, to help
provide guidance and derive the data models, it may do so. The working
group will decide later whether the information model needs to be
published as an RFC. Other aspects of NSFs, such as device or network
provisioning and configuration, are out of scope.  As there are many
different security vendors or open source technologies supporting
different features and functions on their devices, I2NSF will focus on
flow-based NSFs that provide treatment to packets/flows, such as
Intrusion Protection/Detection System (IPS/IDS), web filtering, flow
filtering, deep packet inspection, or pattern matching and remediation.

Controlling and monitoring aspects of NSFs include the ability to specify
rules (by a single controller at the first phase), query, and monitor
NSFs by one or more management entities.  The initial phase of I2NSF will
only consider one single controller that can specify or change rules to
NSFs because multi-headed control requires the coordination to avoid
potential conflict of rules. The NSFs can be monitored by multiple
entities, but the database update and synchronization among multiple
management entities are out of scope for I2NSF. 

I2NSF will specify interfaces at two functional levels for the control
and monitoring of network security functions:

The I2NSF Capability Layer specifies how to control and monitor NSFs at a
functional implementation level.  The term "Functional Implementation" is
used to emphasize that the rules (for control and monitor) of NSFs have
to be implementable by most NSFs. I2NSF will standardize a set of
interfaces by which a security controller can invoke, operate, and
monitor NSFs.
 
The I2NSF Service Layer defines how clients' security policies may be
expressed to a security controller. The controller implements its
policies according to the various capabilities provided by the I2NSF
Capability Layer.  The I2NSF Service Layer also allows the client to
monitor the client specific policies.

A client may leverage the I2NSF Service Layer interface to express
security policies to a security controller, which in turn interacts with
one or more NSFs through the I2NSF Capability Layer interface. 
Alternatively, a client may interact with one or more NSFs directly
through the I2NSF Capability Layer interface.
 
Since there could be many depths or types of Service Layer policies, the
following bullets further clarify the scope of I2NSF:
    o Only the simple Service Layer policies that are modeled as closely
as possible on the Capability Layer are within the scope.
Simple Service Layer policies can be directly translated to capability
layer rules with a direct mapping that might include a customer ID to be
translated to tags carried by packets, but might not specify the NSF. 
This flexibility in the simple Service Layer enables a security
controller to handle issues like multi-tenancy and the choice between
available NSFs for a given policy.
    o I2NSF will not specify abstract or sophisticated policies from
clients. Expressing policies in ways other than the model used by the
Capability Layer is out of scope.
    o The translation mechanism/methods from Service Layer policies to
Capability layer commands are out of scope for I2NSF.
However, I2NSF will provide a discussion forum for Informational drafts
on data models, APIs, etc. that demonstrate how more complex Service
Layer policies and formats may be translated to Capability Layer
functions.  Such documents would be pursued outside the WG.

Standard interfaces for monitoring and controlling the behavior of NSFs
are essential building blocks for providers of security service to
automate the use of different NSFs from multiple vendors. This work will
leverage the existing protocols and data models defined by the I2RS,
NETCONF, and NETMOD working groups. If extensions to these protocols or
data models are needed, requirements will be developed by this WG, and
the extensions will be developed in cooperation with the working groups
responsible for the protocols.
 
The I2NSF working group's deliverables include:
 
    o A single document covering use cases, problem statement, and gap
analysis document. This document will initially be produced for reference
as a living list to track and record discussions: the working group may
decide to not publish this document as an RFC.
    o A framework document, presenting an overview of the use of NSFs and
the purpose of the models developed by the working group. This document
will also be a reference text to guide the main work and the working
group may decide to not publish this document as an RFC.
    o If the working group considers it necessary, a single, unified,
Information Model to describe the control and monitoring of flow-based
NSFs.
    o YANG data models for the control and monitoring of NSFs.
    o A vendor-neutral vocabulary  to enable the characteristics and
behavior of NSFs to be specified without requiring the NSFs themselves to
be standardized, so that "security controller" or "manager" have a common
base to choose the appropriate NSFs (by different vendors) that can
fulfill the requests requested by clients.
    o An examination of existing secure communication mechanisms to
identify the appropriate ones for carrying the controlling and monitoring
information between the NSFs and their management entities. This document
may also be produced as a working document that is not published as an
RFC.
 
The working group may additionally choose to develop documents to
describe requirements for extensions (if any) to existing protocols used
by the working group, to explain how the data models are used to monitor
and control flow-based NSFs, and to describe how to use I2RS and NETCONF
to carry the content of the data models. These documents may be published
as Informational RFCs or may be working documents that are discarded once
they have triggered the necessary work.
 
The working group will work closely with the I2RS, NETCONF, and NETMOD
WGs. The working group will communicate with external SDOs like ETSI NFV
and will encourage open source code development related to the working
group scope in organizations like ONF, OpenStack, ODL, and OPNFV.

The working group must have the above deliverables completed within 24
months.  The responsible AD will close the working group at that time if
they are not completed or close to completion.  The working group may be
closed earlier if substantial progress is not being made.

Milestones:
  Nov 2015 - Adopt use Cases, problem statement, and gap analysis as WG
document
  Feb 2016 - Adopt framework as WG document
  Jun 2016 - Adopt requirements for extensions to protocols as WG
document
  Jun 2016 - Adopt examination of existing secure communication
mechanisms as WG document
  Jun 2016 - Adopt info model as WG document (if desired)
  Jul 2016 - Adopt data models as WG document
  Aug 2016 - WG decides whether to progress adopted drafts for
publication as RFCs (use cases, framework, information model, and
examination of existing secure communication mechanisms) 
  Aug 2016 - Adopt applicability statements as WG Document
  Oct 2016 - Adopt IANA registry consideration as WG document
  Apr 2017 - All early drafts to IESG for publication (if WG decided to
proceed): use cases, problem statement, and gap analysis document;
framework document; information model requirements for extensions to
protocols document; examination of existing secure communication
mechanisms document
  Apr 2017 - Data Models and Applicability Statements to IESG for
publication
  Oct 2017 -  Working group re-charter or close

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 18 Sep 2015 11:51:42 -0400

Congratulations to the WG members and a big thank you for your work to make this happen.

The milestones are aggressive, but achievable and I look forward to seeing continued success!

Best regards,
Kathleen 

Sent from my iPhone

> On Sep 18, 2015, at 11:24 AM, The IESG <[email-masked]> wrote:
> 
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 18 Sep 2015 17:14:04 +0100

Kathleen,

Thanks for all of your work helping get this formed, and our thanks to you for
persuading Dan and Joe to run the BoF and drive it to completion.

Adrian

> -----Original Message-----
> From: I2nsf [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
> Sent: 18 September 2015 16:52
> To: [email-masked]
> Subject: Re: [I2nsf] WG Action: Formed Interface to Network Security Functions
> (i2nsf)
>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 18 Sep 2015 12:31:22 -0400

Kathleen, Dan and Joe:

Thank you for all your hard work to run these BOFs and create the I2NSF WG. 

Sue 

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Friday, September 18, 2015 12:14 PM
To: 'Kathleen Moriarty'; [email-masked]
Subject: Re: [I2nsf] WG Action: Formed Interface to Network Security
Functions (i2nsf)

Kathleen,

Thanks for all of your work helping get this formed, and our thanks to you
for persuading Dan and Joe to run the BoF and drive it to completion.

Adrian

> >  Adrian Farrel <[email-masked]>  Linda Dunbar 
> > <[email-masked]>
> >
> > Assigned Area Director:
> > A Network Security Function (NSF) is a function used to ensure 
> > integrity, confidentiality, or availability of network 
> > communications, to detect unwanted network activity, or to block or 
> > at least mitigate the effects of unwanted activity. NSFs are 
> > provided and consumed in increasingly diverse environments. Users 
> > could consume network security services enforced by NSFs hosted by 
> > one or more providers, which may be their own enterprise, service 
> > providers, or a combination of both.  Similarly, service providers 
> > may offer their customers network security services that are 
> > enforced by multiple security products, functions from different 
> > vendors, or open source technologies. NSFs may be provided by 
> > physical and/or virtualized infrastructure. Without standard 
> > interfaces to control and monitor the behavior of NSFs, it has 
> > become virtually impossible for providers of security services to
automate service offerings that utilize different security functions from
multiple vendors.
> > models for controlling and monitoring aspects of physical and 
> > virtual NSFs, enabling clients to specify rulesets. If the working 
> > group finds it necessary to work on an information model before the 
> > data models, to help provide guidance and derive the data models, it 
> > may do so. The working group will decide later whether the 
> > information model needs to be published as an RFC. Other aspects of 
> > NSFs, such as device or network provisioning and configuration, are 
> > out of scope.  As there are many different security vendors or open 
> > source technologies supporting different features and functions on 
> > their devices, I2NSF will focus on flow-based NSFs that provide 
> > treatment to packets/flows, such as Intrusion Protection/Detection 
> > System (IPS/IDS), web filtering, flow filtering, deep packet inspection,
or pattern matching and remediation.
> >
> > Controlling and monitoring aspects of NSFs include the ability to 
> > specify rules (by a single controller at the first phase), query, 
> > and monitor NSFs by one or more management entities.  The initial 
> > phase of I2NSF will only consider one single controller that can 
> > specify or change rules to NSFs because multi-headed control 
> > requires the coordination to avoid potential conflict of rules. The 
> > NSFs can be monitored by multiple entities, but the database update 
> > and synchronization among multiple management entities are out of scope
for I2NSF.
> >
> > I2NSF will specify interfaces at two functional levels for the 
> > control and monitoring of network security functions:
> >
> > The I2NSF Capability Layer specifies how to control and monitor NSFs 
> > at a functional implementation level.  The term "Functional 
> > Implementation" is used to emphasize that the rules (for control and 
> > monitor) of NSFs have to be implementable by most NSFs. I2NSF will 
> > standardize a set of interfaces by which a security controller can 
> > invoke, operate, and monitor NSFs.
> >
> > The I2NSF Service Layer defines how clients' security policies may 
> > be expressed to a security controller. The controller implements its 
> > security policies to a security controller, which in turn interacts 
> > with one or more NSFs through the I2NSF Capability Layer interface.
> > Since there could be many depths or types of Service Layer policies, 
> > the following bullets further clarify the scope of I2NSF:
> >    o Only the simple Service Layer policies that are modeled as 
> > closely as possible on the Capability Layer are within the scope.
> > Simple Service Layer policies can be directly translated to 
> > capability layer rules with a direct mapping that might include a 
> > customer ID to be translated to tags carried by packets, but might not
specify the NSF.
> > controller to handle issues like multi-tenancy and the choice 
> > between available NSFs for a given policy.
> > clients. Expressing policies in ways other than the model used by 
> > the Capability Layer is out of scope.
> >    o The translation mechanism/methods from Service Layer policies 
> > to Capability layer commands are out of scope for I2NSF.
> > However, I2NSF will provide a discussion forum for Informational 
> > drafts on data models, APIs, etc. that demonstrate how more complex 
> > Service Layer policies and formats may be translated to Capability 
> > Layer functions.  Such documents would be pursued outside the WG.
> >
> >
> > Standard interfaces for monitoring and controlling the behavior of 
> > NSFs are essential building blocks for providers of security service 
> > to automate the use of different NSFs from multiple vendors. This 
> > work will leverage the existing protocols and data models defined by 
> > the I2RS, NETCONF, and NETMOD working groups. If extensions to these 
> > protocols or data models are needed, requirements will be developed 
> > by this WG, and the extensions will be developed in cooperation with 
> > the working groups responsible for the protocols.
> >
> >    o A single document covering use cases, problem statement, and 
> > gap analysis document. This document will initially be produced for 
> > reference as a living list to track and record discussions: the 
> > working group may decide to not publish this document as an RFC.
> >    o A framework document, presenting an overview of the use of NSFs 
> > and the purpose of the models developed by the working group. This 
> > document will also be a reference text to guide the main work and 
> > the working group may decide to not publish this document as an RFC.
> > Information Model to describe the control and monitoring of 
> > flow-based NSFs.
> > behavior of NSFs to be specified without requiring the NSFs 
> > themselves to be standardized, so that "security controller" or 
> > "manager" have a common base to choose the appropriate NSFs (by 
> > different vendors) that can fulfill the requests requested by clients.
> > identify the appropriate ones for carrying the controlling and 
> > monitoring information between the NSFs and their management 
> > entities. This document may also be produced as a working document 
> > that is not published as an RFC.
> >
> > describe requirements for extensions (if any) to existing protocols 
> > used by the working group, to explain how the data models are used 
> > to monitor and control flow-based NSFs, and to describe how to use 
> > I2RS and NETCONF to carry the content of the data models. These 
> > documents may be published as Informational RFCs or may be working 
> > documents that are discarded once they have triggered the necessary
work.
> >
> > The working group will work closely with the I2RS, NETCONF, and 
> > NETMOD WGs. The working group will communicate with external SDOs 
> > like ETSI NFV and will encourage open source code development 
> > related to the working group scope in organizations like ONF, OpenStack,
ODL, and OPNFV.
> >
> > The working group must have the above deliverables completed within 
> > 24 months.  The responsible AD will close the working group at that 
> > time if they are not completed or close to completion.  The working 
> > group may be closed earlier if substantial progress is not being made.
> >
> > Milestones:
> >  Nov 2015 - Adopt use Cases, problem statement, and gap analysis as 
> > WG document  Feb 2016 - Adopt framework as WG document  Jun 2016 - 
> > Adopt requirements for extensions to protocols as WG document  Jun 
> > 2016 - Adopt examination of existing secure communication mechanisms 
> > as WG document  Jun 2016 - Adopt info model as WG document (if 
> > desired)  Jul 2016 - Adopt data models as WG document  Aug 2016 - WG 
> > decides whether to progress adopted drafts for publication as RFCs 
> > (use cases, framework, information model, and examination of 
> > existing secure communication mechanisms)  Aug 2016 - Adopt 
> > applicability statements as WG Document  Oct 2016 - Adopt IANA 
> > registry consideration as WG document  Apr 2017 - All early drafts 
> > to IESG for publication (if WG decided to
> > mechanisms document  Apr 2017 - Data Models and Applicability 
> > Statements to IESG for publication  Oct 2017 -  Working group 
> > re-charter or close
> >
> >

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Sat, 19 Sep 2015 14:55:31 +0000

Thanks Kathleen and you all who have contributed to bringing I2NSF into life.

The schedule is indeed demanding, but I see a group with high motivation and very good proposals already on the table. Let’s go for it!

Be goode,

On 18 Sep 2015, at 17:51 , Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:

Best regards,
Kathleen

Sent from my iPhone

On Sep 18, 2015, at 11:24 AM, The IESG <[email-masked]<mailto:[email-masked]>> wrote:

Chairs:
Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Linda Dunbar <[email-masked]<mailto:[email-masked]>>

Assigned Area Director:
Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>

Mailing list
Address: [email-masked]<mailto:[email-masked]>
To Subscribe: https://www.ietf.org/mailman/listinfo/i2nsf
Archive: https://mailarchive.ietf.org/arch/browse/i2nsf/

Charter:

Milestones:

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

_______________________________________________
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: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sun, 20 Sep 2015 10:01:48 +0900

Hi all,
Congratulations on our new WG, I2NSF.
I hope we will be able to contribute much for the innovation in security
area.

Thanks.

Best Regards,
Paul
-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php

On Sat, Sep 19, 2015 at 11:55 PM, DIEGO LOPEZ GARCIA <
[email-masked]> wrote:

> The schedule is indeed demanding, but I see a group with high motivation
> and very good proposals already on the table. Let’s go for it!
>
> Be goode,
>
>
> On 18 Sep 2015, at 17:51 , Kathleen Moriarty <
> [email-masked]> wrote:
>
> ------------------------------
>
> 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
>