Rakesh, Your description is good.
Suggest avoid using the word “intent” so that people won’t mistake it as part of “Intent Based Networking” initiatives. The policies you described in your draft are more on client-oriented expression for the policies , i.e. the clients can create policy rules without having to know actual tags or addresses in the packets. Linda From: Rakesh Kumar [mailto:[email protected]] Sent: Friday, July 08, 2016 4:58 PM To: Linda Dunbar; [email protected] Cc: Dave Qi; Anil Lohiya; Xiaobo Long; Adrian Farrel; Rakesh Kumar Subject: Re: [I2nsf] A New I-D on Northbound Interfaces for Security Policy Controllers : A Framework and Information Model Hi Linda, You are absolutely correct about assumption sometime made that “user-intent” means some kind of natural language input (just the way you mentioned below). This point was also raised by Adrian during my discussion with him. But we don’t mean that, what we mean is that when client express policy, they would use the object defined in the draft such as “user-group” instead of using L3-L4 information which is not very intuitive approach. I would appreciate if you are Adrian can help us put some clarification in the draft with regards to this. If you are okay with above explanation, I can add this as well. Please let me know your thoughts. Regards, Rakesh From: Linda Dunbar <[email protected]<mailto:[email protected]>> Date: Friday, July 8, 2016 at 2:47 PM To: Rakesh Kumar <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: Dave Qi <[email protected]<mailto:[email protected]>>, Anil Lohiya <[email protected]<mailto:[email protected]>>, Xiaobo Long <[email protected]<mailto:[email protected]>>, Adrian Farrel <[email protected]<mailto:[email protected]>> Subject: RE: [I2nsf] A New I-D on Northbound Interfaces for Security Policy Controllers : A Framework and Information Model Rakesh, Absolutely, “user-group”, “application-group” etc, should be included for client facing interface. There are several “Intent” initiatives in the industry. We want to make it clear that abstract “intent” will not be in the scope, such as “I want my traffic secure”, or “I don’t want DDoS attacks” etc. The Flow Security Policies on the Service Facing Interface should be able to be converted to flow policies to NSFs with deterministic logics Linda From: Rakesh Kumar [mailto:[email protected]] Sent: Friday, July 08, 2016 3:51 PM To: Linda Dunbar; [email protected]<mailto:[email protected]> Cc: Dave Qi; Anil Lohiya; Xiaobo Long; Adrian Farrel; Rakesh Kumar Subject: Re: [I2nsf] A New I-D on Northbound Interfaces for Security Policy Controllers : A Framework and Information Model Hi Linda, I appreciate your comment. Please see response below. Regards, Rakesh From: Linda Dunbar <[email protected]<mailto:[email protected]>> Date: Friday, July 8, 2016 at 11:14 AM To: Rakesh Kumar <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: Dave Qi <[email protected]<mailto:[email protected]>>, Anil Lohiya <[email protected]<mailto:[email protected]>>, Xiaobo Long <[email protected]<mailto:[email protected]>>, Adrian Farrel <[email protected]<mailto:[email protected]>> Subject: RE: [I2nsf] A New I-D on Northbound Interfaces for Security Policy Controllers : A Framework and Information Model Rakesh, Thank you very much for contributing the draft. Finally got chance to read through. Your draft has described very good requirement for Customer Facing interface. It seems more reasonable to call the draft as i2nsf-customer-facing-req than “framework”. What do you think? [rakesh] This is fine with me if you think this reflects the content more accurately. We wanted to show what information model need to be considered for the Customer Facing Interface. “user-intent” is brought up in your draft. Since there could be many depths or types of customer facing policies, I2NSF Charter has the following bullets further clarify the scope of I2NSF: · Only the simple Service Layer policies that are modeled as closely as possible on the Capability Layer are within the scope. Simple Service Layer policies can be directly translated to capability layer rules with a direct mapping that might include a customer ID to be translated to tags carried by packets, but might not specify the NSF. This flexibility in the simple Service Layer enables a security controller to handle issues like multi-tenancy and the choice between available NSFs for a given policy. [rakesh] We should discuss this topic more in Berlin. But here is our thought process. 1. We can not just translate/expose I2NSF southbound/NSF interface as northbound/client interface from security controller. There has to be some abstraction. In that case, security controller would just become a API proxy agent. 2. The “user-intent” means the interface should abstraction as defined in our draft such as “user-group”, “application-group” when expressing northbound/client policy interface. 3. The whole idea behind defining/using “security policy controller” is to make security deployment less complex otherwise one can directly use I2NSF southbound/NSF interface without a need for controller. Thanks, Linda From: Rakesh Kumar [mailto:[email protected]] Sent: Wednesday, July 06, 2016 8:28 PM To: [email protected]<mailto:[email protected]> Cc: Dave Qi; Anil Lohiya; Rakesh Kumar; Xiaobo Long; Adrian Farrel; Linda Dunbar Subject: [I2nsf] A New I-D on Northbound Interfaces for Security Policy Controllers : A Framework and Information Model Hi, I posted a new draft that proposes a framework for northbound interfaces (whatever terminology we finally agree on) from Security Policy Controller. We would like to solicit feedback and start discussion within the I2NSF group to see how to carry this effort forward. The security is very complex and mostly device/vendor/feature centric but It would be great to come up with a policy framework which can work across wide spectrum of use-cases and also extensible. Our goal is to push this framework in SUPA as well so that “Service Layer” generic policy framework could be easily adopted for security functions. I want to thank Adrian Farrel and Linda Dunbar for all the help they extended to new comers. I am looking forward to discussion at Berlin meeting. We can also discuss before/at/after the meeting (1:1) if needed. I have also requested I2NSF chairs for 15-30 mins power point presentation on this at Berlin meeting. Regards Rakesh A new version of I-D, draft-kumar-i2nsf-controller-northbound-framework-00.txt has been successfully submitted by Rakesh Kumar and posted to the IETF repository. Name: draft-kumar-i2nsf-controller-northbound-framework Revision: 00 Title: Northbound Interfaces for Security Policy Controllers : A Framework and Information Model Document date: 2016-07-06 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-kumar-i2nsf-controller-northbound-framework-00.txt Status: https://datatracker.ietf.org/doc/draft-kumar-i2nsf-controller-northbound-framework/ Htmlized: https://tools.ietf.org/html/draft-kumar-i2nsf-controller-northbound-framework-00 Abstract: This document provides a framework and information model for the definition of northbound interfaces for a security policy controller. The interfaces are based on user-intent instead of vendor-specific or device-centric approaches that would require deep knowledge of vendor products and their security features. The document identifies the common interfaces needed to enforce the user-intent-based policies onto network security functions (NSFs) irrespective of how those functions are realized. The function may be physical or virtual in nature and may be implemented in networking or dedicated appliances.
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
