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] Cc: [email protected]; [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 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. - 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.) 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. - Specify the secure mechanisms to carry the content identified by the informational/data models. E.g. TLS to carry the information. 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. 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. . 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] https://www.ietf.org/mailman/listinfo/i2rs
