Tom: I'm catching up with emails after a few days of I2RS interims and design teams - so I apologize if this comes out of sequence.
LIME has a solid basis in looking at generic OAM modules. I would not like to see the generic OAM work of LIME defocused by defining the vNSF functions. The two efforts work better in parallel. An example of this is the LIME OAM and the TRILL yang models (oam, fm, pm) with I2RS modules upcoming. You can look at IETF 90 for TIssa's original proposal in TRILL. The presentations and the ETSI work has demonstrated the desire for the vNSF requirements to be standardized. A WG with a short-term focus of defining Security and Networking people to decide what is needed for an interoperable vNSF. This type of effort creates a 12-18 month WG life-cycle that should aid OAM in LIME and the mechanisms in netconf/restconf. Sue -----Original Message----- From: Thomas D. Nadeau [mailto:[email protected]] Sent: Wednesday, February 04, 2015 2:50 PM To: Linda Dunbar Cc: Russ White; [email protected]; [email protected]; Susan Hares; [email protected] Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF > On Feb 4, 2015:2:44 PM, at 2:44 PM, Linda Dunbar <[email protected]> wrote: > > > Thomas, > > Comments inserted below: > > -----Original Message----- > From: I2nsf [mailto:[email protected]] On Behalf Of Thomas D. Nadeau > Sent: Wednesday, February 04, 2015 10:37 AM > To: Linda Dunbar > Cc: Russ White; [email protected]; [email protected]; Susan Hares; [email protected] > Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF > > >> On Feb 4, 2015:11:25 AM, at 11:25 AM, Linda Dunbar <[email protected]> wrote: >> >> Russ, >> >> Thank you very much for the suggestion of framing in terms of services. What do you think with the following changes to the I2NSF charter with your suggestions added? >> >> In a nutshell, The Interface to vNSF (I2NSF) allows clients to communicate their specific security policies (request/monitor/report) to security functions. I2NSF will specify a vNSF framework, requirements for programmatic interface to vNSF devices (configuration and dynamic programmatic) , and Information and Data models for security functions' Operation, Administration, Maintenance and Provisioning (OAM). The information models will include the following security functions: > > Why wouldn't you do the models for those OAM functions where those functions are modeled already? I don't see the need for a special WG that creates a subset of models that can done elsewhere like in LIME, or the Routing Area groups that are already chartered to do this stuff. > > [Linda] LIME addresses OAM for network layer, connectivity (link/port) failures, end to end performances measurement, whereas I2NSF is for security policies to be enforced by distributed (virtual) network security functions (vNSF). I2NSF provides a standard interface to express, monitor, and manage the security policies across distributed security functions that may be running on different premises. [TOM] The salient point I have been trying to make is that i2nsf does not exist; LIME does. Why not just do it there (and other existing places in the IETF)? We seem to be working REALLY hard here to make up reasons why we need to form a new working group. I'd contend that it is not needed and that the management overhead + other overhead of reviewing/processing documents like a new framework, requirements, etc... will unnecessarily spend precious IETF resources. --Tom > This leaves just doing requirements and a framework for this proposed group, which without clear goals to build things from is a WG looking for a reason to exist rather than the other way around. > > --Tom > > > >> >> * Firewall >> including various services associated with FW, such as stateful or deep packet inspection, packet/flow/stream filtering and redirect (remote and local), etc >> >> * Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) >> Including intrusion detection (flow/stream pattern matching) >> >> >> Linda >> >> -----Original Message----- >> From: i2rs [mailto:[email protected]] On Behalf Of Russ White >> Sent: Tuesday, February 03, 2015 7:35 AM >> To: 'Susan Hares'; Linda Dunbar; [email protected] >> Cc: [email protected]; [email protected] >> Subject: Re: [i2rs] revised charter for I2NSF >> >> >> Interesting concept. One thought that might be helpful -- >> >>> * Firewall >>> * DDOS/Anti-DOS >>> * Intrusion Detection System/ Intrusion Prevention System >>> (IDS/IPS) >>> * Access control/Authorization/Authentication >> >> I think I would try to frame things in terms of services, rather than devices, or a mix of the two. For instance -- what does a "firewall" really do? Stateful packet inspection, deep packet inspection, and... ?? So maybe a list something like this might make sense -- (and remember, this is brainstorming, nothing more) -- >> >> - Stateful packet inspection >> - Deep packet inspection >> - Packet/flow/stream filtering (remote and local) >> - Packet/flow/stream redirect (remote and local) >> - Intrusion detection (or perhaps flow/stream pattern matching?) >> - AAA >> >> Don't know if this is a useful line of thought or not. >> >> :-) >> >> Russ >> >> _______________________________________________ >> i2rs mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> i2rs mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i2rs >> > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
