Tom, Your points taken, there are many types of controllers in SDN paradigm. Throwing one more can be confusing.
The “security controller” in the context of I2NSF can be viewed as an adapter between Security Service Request (e.g. allow traffic with specific fields for specific time span) and the security device specific information model. Yes, we will have a “reference implementation” to make the discussion more focused. Thanks, Linda From: i2rs [mailto:[email protected]] On Behalf Of Thomas D. Nadeau Sent: Tuesday, February 03, 2015 8:36 AM To: Susan Hares; Linda Dunbar; [email protected]; [email protected]; [email protected]; Benoit Claise Subject: Re: [i2rs] revised charter for I2NSF Sorry for the top-post. I am not subscribed to the i2nsf list. Some comments inline below. In general my comment on the latest charter are that I am puzzled as the point of this proposed WG charter is. Anyone working in the controller space these days will be scratching their head as I have been after reading this charter just now. My suggestion is that if you indeed want to embark on the work described below, that you do it within the context of some reference implementation (most of the popular ones will suffice) which may reveal some of the points I am raising below. On Feb 3, 2015:7:31 AM, at 7:31 AM, Susan Hares <[email protected]<mailto:[email protected]>> wrote: Linda: Thank you for your encouragement to send comments on the gap-analysis and the use cases to the list. A few suggestions for the sequences of your charter events: I think that getting use cases, framework and protocol requirements is critical. Since the security area has a strong terminology draft, maybe you can just create an online update to that one. IMHO, I think it is important to have a goal of using existing protocols or extending these protocols. Adjusting your charter to indicate this at every step would prevent duplication of IETF work and increase the speed of development of your protocol. The capability (or functional) layer between controller and network devices may be able to leverage existing protocols in SACM, AAA, rtgwg, netmod, netconf/restconf, or other protocols. Or it may be able to be a combination of these protocols. Instead of in addition, the WG should consider this at the beginning. Making a decision on what type of service-based interface is important during the framework. If you wish an intent-based application driven interface, this may be different than the intent based or comprehensive API. Sue From: i2rs [mailto:[email protected]] On Behalf Of Linda Dunbar Sent: Monday, February 02, 2015 7:09 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [i2rs] revised charter for I2NSF Based on the recent discussion on the I2NSF list, here is the revised charter for I2NSF. Copied to I2RS group to get wider review because I2NSF is related to I2RS in such a way that I2RS provides the interface to Router whereas I2NSF provides the interfaces to security functions. In a nutshell, The Interface to Network Security Functions (I2NSF) is to discuss interfaces for clients or application gateways to communicate Is the purpose here to "discuss" or to "create" interfaces? If it is the former, I am not sure what the point of the WG would be. If the latter, those things being done in other WGs across the routing area or outside of the IETF already. their specific security policies (request/monitor/report) with security controller and security functions. I2NSF will specify the information model, along with adequate data models, and protocols required for the Operation, Administration, Maintenance and Provisioning (OAM) for the following security functions: • Firewall • DDOS/Anti-DOS • Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) • Access control/Authorization/Authentication There are two distinct interfaces for I2NSF: - Capability (or Functional) Layer interface between Security Controller, which could be embedded in a network controller, and Security devices (virtual & physical), which focuses more on the functional aspects of the functions listed above. No such layer is needed. Take a look at the commercial controllers that are out there and you will see that its a part of the protocols already, or people re-use existing (well designed) systems such as RADIUS, etc.... - Service Layer Interface between Clients (or App Gateway) and the Security Controller, which is for clients or App Gateway to express/monitor the needed security policies (e.g. develop a security policy language based on NIST endorsed Role Based Access Control.) What would a "service layer interface" be? Today controllers like OpenDaylight use RestConf and NetConf. Those are perfectly well specified interfaces that come with various security mechanisms built-in right out of the box. What else is needed? If you claim you want to put RADIUS or AAA or something else in there, that is done as a side action within the context of those things already. This already works BTW, so again, I am not sure what would be achieved here. I2NSF WG Deliverables for the Functional/Capability Layer Interface include: - Develop a comprehensive set of informational Models for the following functions with regard to different aspects of OAM (Operations/Administration/Maintenance). For example: extending the ACL data model to be more comprehensive, e.g. including multiple actions and policies. o Firewall o DDOS/Anti-DOS o Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) - Develop the corresponding Data Models, e.g. YANG model. Again, these are being done in other places already. What are you trying to accomplish here? - Specify the secure mechanisms to carry the content identified by the informational/data models. E.g. TLS to carry the information. Since we are talking about Yang models, I assume the transport/protocol is Netconf or RestConf. Why would you re-specify that TLS/SSL be used for Netconf or RestConf? If you want to change something in those protocols, I suggest you stop by the Netconf WG. Other options such as SNMP already have this specified too in case you were thinking of going there. I2NSF WG Deliverables for the Service Layer Interface include: • Develop policy description (or language) for clients or App Gateway to express/monitor the needed security policies (e.g. develop a security policy language based on NIST endorsed Role Based Access Control.) – E.g. Develop comprehensive set of “TARGETs” for the Security Intent. Security Target in Data Centers network, in Access Network, in Wide Area network, etc – Develop descriptors for “Users”, “Roles”, “Permissions” • Develop the corresponding information or Data Models, e.g. YANG model. • Compare with existing IETF protocols for “Roles”, “Users”, “Permissions”, etc. What would such a policy description achieve? There are already policy models out there: Congress from Openstack, GBP/Intent/ODL, op-nfv policy, Op-flex, etc... Do we need another one? I'd recommend that you take a look at the significant work (and implementations) that have been done over in those places. In addition, the I2NSF working group will • Document a high-level I2NSF framework that describes Services and Capability layers interfaces and defines a reference model along with functional components at each layer. – Terminology draft may be included in the framework or becomes a standalone draft. What would yet another "framework" achieve? Seriously, we should be worried about building these things rather than documenting all sorts of theoretical scenarios. --Tom • Document small and well-scoped use cases to constrain the scope of the work and achieve sufficient focus for the working group to deliver successful outcomes. And • Analyze candidate protocols that may carry the information to be exchanged through the various interfaces. – E.g. Compare with existing IETF protocols for “OBJECTs, ACTIONs, FILTERING, etc” (e.g. PCP, Radius, etc) . Looking for comments and suggestions. Linda Dunbar _______________________________________________ i2rs mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
