Re: [I2nsf] Further clarification and explanations to I2NSF charter has been added to the I2NSF Wiki Q&A (was RE: Consensus call on I2NSF Charter

[Flemming Andreasen <[e-mail]>]

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 ?

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


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.

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]
> *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 
> <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 
> <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 
> <https://www.ietf.org/mailman/listinfo/i2nsf>
>
> >>
>
> >
>
> >
>