1. Requirements for Client-facing Interface to Security controller draft-ietf-i2nsf-client-facing-interface-req-00
Rakesh Kumar Juniper networks
Anil Lohiya Juniper networks
Dave Qi Bloomberg
Nabll Bitar Nokia
Senand Palislamovic Nokia
Liang Xia Huawei
IETF-97, Seoul
November 14, 2016

2. Agenda Draft history Draft overview WG discussions
Next steps and plans

3. Draft history I2NSF client-facing interface requirements
First proposed as individual draft
Presented in IETF-96
draft-kumar-i2nsf-controller-northbound-framework-00
Change the name as per WG chair suggestion
draft-kumar-i2nsf-client-facing-interface-req
Adopted as WG draft post IETF-96
WG decided to use this draft after some discussion
Adopted draft-kumar-i2nsf-client-facing-interface-req-02

4. Client-facing Interface RESTful API
Draft scope – Identify requirements to build I2NSF client-facing Interface
Client-facing Interface RESTful API
( User-construct based, independent of network topology, NSF type and its location in network)
Security Controller
End-user express security policies using client-facing interface
All end-user interaction through an abstraction layer in security controller
End-user security policies enforced on traffic originated and destined to end-points
Security policy deployed in NSF by security controller
NSF-Facing Interface
NSFs
(Routers, Switches, Firewall)
(Virtual & Physical)
I2NSF Agent
End-points
(Applications, Servers, Laptops, Users, Locations)

5. Draft overview – Set of requirements… (1/2)
Interface modeling requirements
Based on user-construct
Easier for end-user to express policy
Not dependent on network topology, NSF
Functional requirements for interface
Multi-tenancy
RBAC
Authentication and authorization
Security policy building blocks
Use ECA model (need to reword existing text in the draft)
Admin-event (manual, threat-level), Calendar-event (time-based), NSF-event (violation)
Policy End-point groups
Defined using meta-data
User-group, device-group, application-group, location-group
Policy Rules
Generic set of match criteria using built-in construct and user-defined end-point groups
Rich set of actions when a rule is matched

6. Draft overview – Set of requirements… (2/2)
Integration with external systems
Threat feeds, Honeypots
Security Information & Event Management (SIEM)
Network and Behavior analytic engines
Telemetry data collection
Get data from NSF such system logs, syslog, NSF logs, security violations
Export data to external systems for monitoring and analytics
Miscellaneous
Notification to end-user based on NSF events and policy violations
Test policies for conflicts before deploying
Affinity to allow end-user so that a policy is enforced on a specific NSF
Need to work on it some more
Operational requirements for interface
Security
Protection from attacks (DoS/DDoS)
Misconfiguration, Input data validation
APIs
API versioning for backward compatibility
API extensibility

7. Next steps and plans for draft draft-ietf-i2nsf-client-facing-interface-req-01
Add examples for requirement
Illustrate each requirement with use-case example for clarity
Expand on requirements based on WG contributions
Look at diverse set of problem and use-cases
Drafts for input
draft-ietf-i2nsf-problem-and-use-cases-02
Incorporate ideas from WG mailing discussions
Few comments received so far
Diego R Lopez
Work on listing the requirement more clearly in the draft
Ed Lopez
Work on the requirement contents
Linda Dunbar
Make policy lifecycle management using ECA model
WG chair suggestion
Think about security for the client-facing interface
Solicit inputs on requirements
Get more use-cases from WG members in different segments
Service providers, Enterprise, cloud operators

8. Thanks!
Rakesh Kumar