Tom, Thank you for the link to OpenDayLight and OpenStack on the intent driven open source initiatives. We contribute to OpenStack and ODL as well. That was very drive that started I2NSF initiative at IETF. Open source projects like OpenStack and CloudStack have begun to tackle the interfaces to security functions but much work remains. There are many pieces of open sourced code, and there are a lot of areas not covered. The combined contributed source code are not comprehensive.
OpenStack completed the Firewall as a Service project and specified the set of APIs for Firewall services: http://docs.openstack.org/admin-guide-cloud/content/fwaas_api_abstractions.html OpenStack has defined the APIs for managing Security Groups: http://docs.openstack.org/admin-guide-cloud/content/securitygroup_api_abstractions.html The attributes defined by OpenStack Firewall/Security as a Service are very primitive. they can be the basis for the I2NSF IETF initiative. Our goal is to form a Collaborative Loop from IETF to Industry Open Source Communities (as Dave Ward said at Nov IETF Lunch session). This is Diego Lopez (ETSI NFV Technical Committee chair) said about IETF and Open Source initiatives: Open-source initiatives are not to be considered as an alternative to formal standardization processes. On the contrary, they are complementary, with the former acting as an enabler and accelerator of the latter. Open-source provides an ideal mechanism to quick prototyping and validating contending proposals, and demonstrating the feasibility of disruptive ideas that could otherwise not be considered. In this respect, open-source facilitates the engagement in the standardization process of small (and typically more dynamic) players such as start-ups and research groups, that would see better opportunities of being heard and a clearer rewards to their efforts. An open-source approach is extremely useful as well for the production of open reference implementations of the standards at the same (or even faster) pace they are defined. The availability of such reference implementations translate into much simpler interoperability and conformance assessments for both providers and users, an d can become the basis for incremental differentiation of a common solution, thus allowing a cooperative competition ("coopetition") model. Linda -----Original Message----- From: Thomas D. Nadeau [mailto:[email protected]] https://wiki.opendaylight.org/view/Network_Intent_Composition:Main https://wiki.openstack.org/wiki/Congress Based on that, I really don't see any need to do any of this work in a new WG. Not only will it be a duplicate of a lot of actual work already being done elsewhere, as far as I can tell, it will not be doing so based on any real implementations/deployments (i.e.: "running code" from the IETF's mantra). Or have I missed something? > Those WGs charters don't have those objectives. That doesn't mean they couldn't be added to existing ones. I'd also bet that is easier than lifting off a new WG to accomplish these goals and will be more efficient as we won't be adding the extra management/processing overhead to the already heavy load at the IETF. --Tom > > Thanks, Linda > > -----Original Message----- > From: Thomas D. Nadeau [mailto:[email protected]] > Sent: Wednesday, February 04, 2015 2:37 PM > To: Romascanu, Dan (Dan) > Cc: Linda Dunbar; Russ White; [email protected]; Susan Hares; > [email protected]; [email protected] > Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF > > > They certainly could, without the added management overhead of a new WG. > > --Tom > >> On Feb 4, 2015:3:02 PM, at 3:02 PM, Romascanu, Dan (Dan) >> <[email protected]> wrote: >> >> Tom, >> >> I2NSF in its most recent (and better focused) charter includes IMs and DMs >> for firewalls and IDSs, as well as a framework to manage virtualized >> security services. Does LIME or other WG in the IETF do any of these? >> >> Regards, >> >> Dan >> >> >>> -----Original Message----- >>> From: I2nsf [mailto:[email protected]] On Behalf Of Thomas D. >>> Nadeau >>> Sent: Wednesday, February 04, 2015 9:50 PM >>> To: Linda Dunbar >>> Cc: Russ White; [email protected]; Susan Hares; [email protected]; >>> [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://urldefense.proofpoint.com/v2/url?u=https- >>> 3A__www.ietf.org_mailman_listinfo_i2rs&d=AwICAg&c=BFpWQw8bsuKpl1S >>> giZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=ZXR0kNB >>> 30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=YlZUo4btDn8UA3sAV2F_rWaL >>> TDFHlxo1ys_wiueV8NI&e= >>>>> >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> [email protected] >>>>> https://urldefense.proofpoint.com/v2/url?u=https- >>> 3A__www.ietf.org_mailman_listinfo_i2rs&d=AwICAg&c=BFpWQw8bsuKpl1S >>> giZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=ZXR0kNB >>> 30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=YlZUo4btDn8UA3sAV2F_rWaL >>> TDFHlxo1ys_wiueV8NI&e= >>>>> >>>> >>>> _______________________________________________ >>>> I2nsf mailing list >>>> [email protected] >>>> https://urldefense.proofpoint.com/v2/url?u=https- >>> 3A__www.ietf.org_mailman_listinfo_i2nsf&d=AwICAg&c=BFpWQw8bsuKpl1 >>> SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=ZXR0kN >>> B30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=Aag4Z_qnWDkR36ft_q- >>> U7rpbPenEFmJgJ11F9yjW29E&e= >>>> >>> >>> _______________________________________________ >>> I2nsf mailing list >>> [email protected] >>> https://urldefense.proofpoint.com/v2/url?u=https- >>> 3A__www.ietf.org_mailman_listinfo_i2nsf&d=AwICAg&c=BFpWQw8bsuKpl1 >>> SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=ZXR0kN >>> B30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=Aag4Z_qnWDkR36ft_q- >>> U7rpbPenEFmJgJ11F9yjW29E&e= >> > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
