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

On 8/27/15 4:27 PM, Linda Dunbar wrote:
>
> 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]
> *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.
>
Ok - we should probably change the Q&A on logging then.

> 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?
>
>
I believe Kathleen clarified the RFC publication part.

The main one I'm still not clear on is the types of NSFs that are in/out 
of scope. Providing an exact definition of those is not easy though, 
since the lines are often blurred (per my DDoS example in the e-mail 
below). What may work better is simply listing the ones that are 
explicitly known to be in scope (which the current charter text 
essentially does), but leave it open for further WG discussion as to 
what other ones (if any) may be in scope as well (perhaps with a phased 
approach with additional milestones added for those later on).

The other ones were mainly around calling out the basic framework 
(client/security controller/NSF and the layers between them) as part of 
the charter and clarification of simple vs abstract/sophisticated 
policies. With the current charter text, they are both open to 
interpretation (and hence further debate and subsequent speficiation) 
IMO, but maybe that's not a bad thing and the WG should indeed spend 
more time on that once it's formed ?

Thanks

-- Flemming

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