Subject: [I2nsf] FAQs for I2NSF

From: "Susan Hares" <[email-masked]>
Date: Wed, 8 Jul 2015 10:47:27 -0400

In other BOFs, I have found it useful to have a short set of FAQ for new
people. Here's a set of questions that I thought might be helpful for new
people: 

1)      What is NSF?

2)      What problem is I2NSF trying to solve? 

3)      What interface is I2NSF considering? 

4)      Why in IETF? What would IETF lose if I2NSF does not do this work? 

5)      Why is I2NSF focusing on the capability layer? 

Do you think these are appropriate questions? 

Since I2NSF does not have a web site to put the FAQs at, I have created a
website that aids provides a mirror of the BOF information where we can put
our FAQs.  

http://www.hickoryhill-consulting.com/i2nSF/

Is this helpful? 

Sue Hares

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 8 Jul 2015 11:12:59 -0500

Sue,

Thank you very much for reviewing the I2NSF gap analysis with the BOF
chairs today and suggesting for putting those Q&As.

Answers to them are inserted below

On Wed, Jul 8, 2015 at 9:47 AM, Susan Hares <[email-masked]> wrote:

> people. Here’s a set of questions that I thought might be helpful for new
> people:
>
>
>
> 1)      What is NSF?
>

Network Security Function (NSF): functions to ensure integrity,
confidentiality and availability of network communications, to detect
unwanted activity, and to block it or at least mitigate its effects on the
network.

Flow-based Network Security Function (Flow-Based NSF): A NSF that inspects
network flows according to a policy intended for enforcing security
properties.  Flow-based security also means that packets are inspected in
the order they are received, and without modification to the packet due to
the inspection process (MAC rewrites, TTL decrement action; even NAT would
be outside the inspection process).

> 2)      What problem is I2NSF trying to solve?

I2NSF is to facilitate the automation process of controlling, managing and
monitoring the NSFs in network by specifying Common Information & Data
Models for Rules Provisioning of Flow-Based NSFs.

   -

      Specify, Query, Update, Monitor, …

Other aspects of NSFs, such as device or network provisioning and
configuration, are out of scope.

> 3)      What interface is I2NSF considering?

I2NSF only focuses on the interface between controller and NSFs. I2NSF is
the south bound interface of Security controller to the NSFs

> 4)      Why in IETF? What would IETF lose if I2NSF does not do this work?

The trend of multi-vendors & multi types of NSFs being hosted by different
administrative domains & premises requires automation. Open-source
communities have started the process for contributors to contribute the
interface to their NSFs. However, open-source contributions can be subset
of the total solution and can be vendor specific which may not be
comprehensive enough to cover every aspect of provisioning and monitoring
of NSFs.

 IETF has the expertise and is best positioned to be the organization to
specify the comprehensive solutions for interfaces to NSFs. One of the
goals of the I2NSF is to form a collaborative loop from IETF to Industry
Open Source Communities, to provide comprehensive specification for rules
to NSFs.

If IETF doesn’t take up this responsibility, IETF is losing its relevance
in this important trend of automatic control of NSFs.

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,
which 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.

> 5)      Why is I2NSF focusing on the capability layer?

Capability Layer is concrete, suited more to IETF competence.  There are
already various ways to specifying the rules already by different vendors.
The job of IETF I2NSF is to consolidate them. So Capability Layer is the
low hanging fruit in the needed ingredient for automation.

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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 8 Jul 2015 13:23:27 -0400

Linda:

Thank you for the quick answers.   I’ll post these and updated them if others suggest modification.

Sue 

From: Linda Dunbar [mailto:[email-masked]] 
Sent: Wednesday, July 08, 2015 12:13 PM
To: Susan Hares
Cc: [email-masked]; Linda Dunbar
Subject: Re: [I2nsf] FAQs for I2NSF

Sue, 

Thank you very much for reviewing the I2NSF gap analysis with the BOF chairs today and suggesting for putting those Q&As. 

In other BOFs, I have found it useful to have a short set of FAQ for new people. Here’s a set of questions that I thought might be helpful for new people: 

1)      What is NSF?

Network Security Function (NSF): functions to ensure integrity, confidentiality and availability of network communications, to detect unwanted activity, and to block it or at least mitigate its effects on the network.

Flow-based Network Security Function (Flow-Based NSF): A NSF that inspects network flows according to a policy intended for enforcing security properties.  Flow-based security also means that packets are inspected in the order they are received, and without modification to the packet due to the inspection process (MAC rewrites, TTL decrement action; even NAT would be outside the inspection process).

I2NSF is to facilitate the automation process of controlling, managing and monitoring the NSFs in network by specifying Common Information & Data Models for Rules Provisioning of Flow-Based NSFs.

·         Specify, Query, Update, Monitor, …

Other aspects of NSFs, such as device or network provisioning and configuration, are out of scope.

I2NSF only focuses on the interface between controller and NSFs. I2NSF is the south bound interface of Security controller to the NSFs

The trend of multi-vendors & multi types of NSFs being hosted by different administrative domains & premises requires automation. Open-source communities have started the process for contributors to contribute the interface to their NSFs. However, open-source contributions can be subset of the total solution and can be vendor specific which may not be comprehensive enough to cover every aspect of provisioning and monitoring of NSFs.

 IETF has the expertise and is best positioned to be the organization to specify the comprehensive solutions for interfaces to NSFs. One of the goals of the I2NSF is to form a collaborative loop from IETF to Industry Open Source Communities, to provide comprehensive specification for rules to NSFs. 

If IETF doesn’t take up this responsibility, IETF is losing its relevance in this important trend of automatic control of NSFs. 

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, which 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.

Capability Layer is concrete, suited more to IETF competence.  There are already various ways to specifying the rules already by different vendors. The job of IETF I2NSF is to consolidate them. So Capability Layer is the low hanging fruit in the needed ingredient for automation. 

Since I2NSF does not have a web site to put the FAQs at, I have created a website that aids provides a mirror of the BOF information where we can put our FAQs.  

Is this helpful? 

Sue Hares