Re: [I2nsf] Consensus call on I2NSF Charter

[Flemming Andreasen <[e-mail]>]

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]
> 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
> >>
> >
> >