[I2nsf] Question about the wording used in I2NSF Q&A WIKI for NSF examples

[Linda Dunbar <[e-mail]>]

Over the course of I2NSF process, many people have asked very good questions about various aspects of I2NSF on the mailing list, and many people have given good answers to the questions. Those good questions and answers have been captured in I2NSF Q&A Wiki: https://sites.google.com/site/interface2nsf/i2nsf-q-a/i2nsfqa

Does anyone remember why we had this clause for  the examples of NSFs

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).

Maybe the phrase “without …” should actually be “with some NSFs making modification to the packets due to ..”?  (the latest Wiki has removed the last clause).

Linda


From: Linda Dunbar
Sent: Thursday, August 27, 2015 3:27 PM
To: 'Flemming Andreasen'; Kathleen Moriarty; Joseph Salowey
Cc: [e-mail]
Subject: RE: Further clarification and explanations to I2NSF charter has been added to the I2NSF Wiki Q&A (was RE: [I2nsf] Consensus call on I2NSF Charter

Flemming,

Comments are inserted below:


From: Flemming Andreasen [mailto:[e-mail]]
Sent: Thursday, August 27, 2015 2:53 PM
To: Linda Dunbar; Kathleen Moriarty; Joseph Salowey
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: Further clarification and explanations to I2NSF charter has been added to the I2NSF Wiki Q&A (was RE: [I2nsf] Consensus call on I2NSF Charter

Thanks Linda

Taking a quick look at the Wiki:
- I noticed that your definition of an NSF explicitly prohibits any packet modification such as NAT or MAC rewrite; this will exclude a large portion of current NSFs (e.g. it's commonly used by FWs and ADCs) - is that intentional ?

[Linda] This is not my intention. I don’t remember who put the last clause in (i.e. without modification to the packet due to the inspection process (MAC rewrites, TTL decrement action; even NAT would be outside the inspection process).. I can pull the mailing list if it ok to remove the last clause.



- You mention that "logging" is out of scope, yet in other places you refer to reporting, analytics, etc., and the charter talks about monitoring. Can you clarify ?
[Linda] Yes, “logging” is referring to analytics, such algorithms, benchmark, etc.

Also, a couple of my questions below still seem to be open, but there is a parallel exchange with Kathleen on some of those, so maybe we can resolve them there.
[Linda] do you mean the questions like “why framework, use cases may not be published as RFCs”? Can you help me out with the questions?


Cheers

-- Flemming
On 8/27/15 12:29 PM, Linda Dunbar wrote:
Flemming,

I have updated the Q&A on the I2NSF Wiki to clarify the questions you have:  https://sites.google.com/site/interface2nsf/i2nsf-q-a/i2nsfqa

Hope it helps. Please let me know if you have more questions or suggestions for I2NSF charter.

Thanks,
Linda
From: Flemming Andreasen [mailto:[e-mail]]
Sent: Wednesday, August 26, 2015 9:01 PM
To: Linda Dunbar; Kathleen Moriarty; Joseph Salowey
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [I2nsf] Consensus call on I2NSF Charter


On 8/26/15 7:31 PM, Linda Dunbar wrote:
Flemming,

Thank you very much for the detailed comments. Thank you for catching those typos (corrected on the I2NSF wiki now). We really need the fresh set of eyes to look at it.

You stated:
- The third paragraph says that "The NSFs can be monitored by multiple entities..."; does this imply a 1:N (direct) monitoring relationship ?
If so, that seems to get to a design decision that may be premature.

[Linda] The intent is to describe a scenario that a NSF may send different outputs to different entities. For example, some statistics report to “Analytics system”, “rule query” to management entity. Can you suggest a better wording for this?

I see. I'm not sure I would get into that level of detail in the charter, but since you introduce the notion of "features and functions", you could for example say

"The NSFs may contain a multitude of features and functions, each of which can be monitored by a different entity"

or something like that.




Other Replies are inserted below:



-----Original Message-----
From: Flemming Andreasen [mailto:[e-mail]]
Sent: Wednesday, August 26, 2015 5:46 PM
To: Linda Dunbar; Kathleen Moriarty; Joseph Salowey
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [I2nsf] Consensus call on I2NSF Charter

Apologies for joining the discussion late - just got back from PTO. In any case, please find some additional comments on the proposed charter below (some more substantial than others):

- The first paragraph starts out by defining what an NSF is, and we can argue about some of the points in there for various security functions (e.g. I may want to detect normal network behavior to establish a baseline, which does not seem to be covered by the current definition).
[Linda] Over the course of I2NSF (about a year), we have gone through a long debate on what NSFs should be considered by IETF I2NSF. As the result of the long debate, we use the definition to classify a set of functions to be considered for IETF I2NSF (then further narrowing down to Flow-based NSFs).
The function you described, i.e. detecting normal network behavior to establish a baseline is not in the scope of I2NSF, even though this function can also be "provided and consumed in increasingly diverse environments".

Ok - the part about "detect unwanted network activity" is fairly broad though, and I'm not sure how you detect unwanted activity without looking at all activity (which is what triggered my original question).



I don't think that will be a productive discussion though, nor is it necessary. Instead, I'd suggest we are not overly prescriptive, but rather view these as possible NSF features, and supplement them with some actual product examples (e.g. FW, NGFW, IPS, etc.). Similarly, since we limit our scope to "flow-based NSFs", we may want to make that clear here. An example of a security function that would *not* be in scope may be helpful too.

[Linda] All the NSFs in I2NSF context are “features”, whose form factor can be provided physical box or virtualized format. Some form factors, i.e. devices or VM, can provide multiple “functions”. Do you think the sentences in the third paragraph is good enough to describe what you want?

“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.”


The examples here are clear; I'm less clear on what else might be in scope. For example, would a DDoS detection and mitigation system be in scope (keeping in mind it may use a combination of packet inspection and telemetry-based detection and mitigation and that establishing a "normal" baseline is often part of the operation) ?




- The charter seems to operate with the notion of a "security controller" that interacts with the "NSF". If I understand correctly, the security controller implements the "Service Layer" and the NSF implements the "Capability Layer". Furthermore, we have "clients" that interact with the security controller to implement policies (by leveraging the service layer). If so, it would be good to clarify this taxonomy earlier in the charter. If not, then I probably need some clarifications in the text.

[Linda] “Security controller” is a conceptual entity, meaning an entity to send implementable rules (capability layer) to the NSFs. There could be multiple of them, each responsible for one type of NSF (i.e. managing the instances of the NSFs).
I2NSF includes “Simple Service Layer” that models closely to the “Capability Layer”. For example: client can specify the rules without specify which instances of the NSF. The “Controller” manage the instances, as described by The figure in I2NSF Framework document:

+ - - - - - - - - - - - - - - - +  + - - - - - - - - - - - - - - - +
|  NSF-A  +--------------+      |  |  NSF-B  +--------------+      |
|         |   Controller|      |  |         |   Controller|      |
|         +--------------+      |  |         +--------------+      |
| + - - - - - - - - - - - - - + |  | + - - - - - - - - - - - - - + |
| |+---------+     +---------+| |  | |+---------+     +---------+| |
| || NSF-A#1 | ... |  NSF-A#n|| |  | ||  NSF-B#1| ... |  NSF-B#m|| |
| |+---------+     +---------+| |  | |+---------+     +---------+| |
| |         NSF-A cluster     | |  | |          NSF-B cluster    | |
| + - - - - - - - - - - - - - + |  | + - - - - - - - - - - - - - + |
+ - - - - - - - - - - - - - - - +  + - - - - - - - - - - - - - - - +

Ok - this basic framework seems to be foundational to the structure of the work the group is doing. If so, I think it would be helpful to outline it (verbally) in the charter.



- In the definition of the "Capability Layer", there is a statement about "rules...of NSFs have to be implementable by most NSFs". Do you mean all NSFs or NSFs of a given type (I assume we have different types of NSFs) ?
[Linda] yes.

- Policies are labeled as "simple" or "abstract or sophisticated"
without further definition; I'm not sure where we draw that line or how to do that in the charter; maybe clarifying that part needs to be a deliverable ?
[Linda] “simple” means that they can be directly translated to capability layer rules with simple mapping, e.g. without explicit stating which instantiation, may have customer ID that can be translated to some tags carried by packets

Ok - if that's the definition we want to use, can we clarify it in the charter ?


- A number of deliverables may not be published as an RFC; why not (they seem to set the stage for several other deliverables and hence are relevant for consumers of the information and data models later on) ?

[Linda] The WG group may decide to publish them as RFC or not later. But the charter doesn’t specify which way. That is how IESG wanted.

Ok.

- The part about I2NSF providing a "discussion forum for Informational drafts on.....[more complex Service Layer policies]..." is confusing to me. The work seems to be pursued outside the WG, so there are no deliverables and presumably no agenda time will be allocated either.
[Linda] this is to address the information documents that describe the I2NSF demo, open source or interoperability initiatives that are conducted outside the WG. E.g https://datatracker.ietf.org/doc/draft-xie-i2nsf-demo-outline-design/

Ok - thanks for the pointer, however from a WG point of view, I'm not clear on what it means to have a discussion forum and what, if anything, the WG will do with it (e.g. discuss such drafts as part of meetings, etc) ?




It's also not clear to me that we can/should state that such documents would be Informational. We may decide that we need some procedures for how to define such documents, have designated experts, a directorate, etc. to review them etc. I'm guessing this is all a bit premature though, but again, we may want to note that as an issue in the charter that the WG needs to resolve at some point.

[Linda] Agree with you. I will see how AD wants to address this suggestion .
Ok



Nits:
- first paragraph:
s/the mitigate/mitigate the/

- second last paragraph:
s/RFCs of/RFCs or

[Linda] Thank you for the catch. They are corrected on the I2NSF wiki now.

Thanks for the quick response and updates.

-- Flemming


Thanks

-- Flemming


On 8/26/15 5:38 PM, Linda Dunbar wrote:
> Kathleen,
>
> Thank you very much for the editorial changes. The charter description
> on the I2NSF Wiki has been updated to reflect your suggested changes:
> https://sites.google.com/site/interface2nsf/home
>
>
> Linda
>
>
> -----Original Message-----
> From: I2nsf [mailto:[e-mail]] On Behalf Of Kathleen
> Moriarty
> Sent: Wednesday, August 26, 2015 2:29 PM
> To: Joseph Salowey
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: Re: [I2nsf] Consensus call on I2NSF Charter
>
> I have a few editorial changes in the following text that does not change the meaning of the charter text:
>
> A Network Security Function (NSF) is a function used to ensure integrity, confidentiality, and availability of network communications, to detect unwanted network activity, and to block or at least the mitigate effects of unwanted activity. NSFs are provided and consumed in increasingly diverse environments. Users of NSFs could consume network security services 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 and/or functions from different vendors. 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. 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.
>
> 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. As there are many different security vendors 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.
>
> 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.
>
> 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.
> Such a Simple Service Layer will enable 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 comments 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 WGs responsible for the protocols.
>
> The I2NSF WG’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 WG 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 WG. This document will also be a reference text to guide the main work and the WG 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 Requests to the IANA for the creation of a registry that enables the characteristics and behavior of NSFs to be specified using a vendor-neutral vocabulary without requiring the NSFs themselves to be standardized. The registry enables various mechanisms, including policy rules, to be used to match monitor and control functions to the needs of an application and/or environment.
> 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 WG may additionally choose to develop documents to describe requirements for extensions (if any) to existing protocols used by the WG, 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 of may be working documents that are discarded once they have triggered the necessary work.
>
> The WG will work closely with the I2RS, NETCONF, and NETMOD WGs. The WG will communicate with external SDOs like ETSI NFV and will encourage open source code development related to the WG scope in organizations like ONF, OpenStack, ODL, and OPNFV.
>
>
> On Wed, Aug 26, 2015 at 1:44 AM, Joseph Salowey <[e-mail]<mailto:[e-mail]>> wrote:
>> Thanks to everyone who has contributed towards developing the charter.
>> I believe we are close to consensus so this is a consensus call for the I2NSF
>> charter.   The charter text is located at
>> https://sites.google.com/site/interface2nsf/home.  Please send
>> comments on this charter to the I2NSF list by September 2, 2015.
>>
>> Thank you,
>>
>> Joe
>>
>> _______________________________________________
>> I2nsf mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/i2nsf
>>
>
>