Sue, Thank you very much for the detailed analysis, and linking with the relevant Flow Filter YANG models developed by I2RS and BGP flow spec.
To answer your questions, I think that we need to make the terminology less confusing. The I2NSF framework specified two interfaces : - Service Layer Interface: between client and controller - Capability layer interface: between Controller and NSF functions. So the Capability layer is the south bound interface between Controller and NSF functions. https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-mitigation-api/ introduces a requirement for one domain to query the Flow Security Policy enforcement "capability" from another domain over the "I2NSF Service Layer Interface"". Therefore, I think we need to differentiate the two. For ease of discussion, Let's use the term "NSF Flow Policy" for the Flow Security Policies over the Controller <-> NSF interface (waiting for WG to finalize the terminology), and use the "Capability" as used by https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-mitigation-api/ for one domain to inquire the "capability" of the other domain of enforcing the Flow Security Policy. Your question: "how does an I2NSF manager engage the packet security policies? Answer: I think "I2NSF Controller" is a more accurate term. The I2NSF Controller converts the Flow Security Policies from the Service Layer Interface to implementable policies to the NSFs. I2NSF charter says: " 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." Your question: Does putting a policy in the network security control means it gets transmitted to the NSF device, Answer: Yes. Your question: and installed? Answer: the NSF needs to install the policies. But not the controller Your question: Does the capability model provide both the way to list the functions (security content and mitigation) and a way to engage these functions? Answer: if we use the new terms, the "Capability Model" specified by the https://datatracker.ietf.org/doc/draft-xia-i2nsf-capability-interface-im/ is the Flow Security Polices that controller can pass down to NSF. The "capability" inquiry is over the "I2NSF Service layer interface" If my explanation is still not clear, please ask more questions. Thank you very much. Linda From: Susan Hares [mailto:[email protected]] Sent: Wednesday, June 08, 2016 12:23 PM To: [email protected] Cc: Linda Dunbar; [email protected] Subject: Help on turning I2NSF Information Models to Data Models I'm working on some data models for I2NSF that intersect with I2RS Filter-Based RIB Models and BGP Flow Specification Data models. I could use some advice from the authors of the following information models. My focus is to be able to drive the use the flow filter Yang models (I2NSF packet-filters, Filter-Based RIB (config, I2RS, BGP input), and BGP Flow Specification transmission of filters) to drive the simple firewall rules found in the Linux iptables user program (netfilter kernel module). I am trying to get a set of Yang data models that can interact with a process (e.g. iptable++ user program named flow-filters) that communicates with a confd (cisco netconf deamon set) that handles NETCONF/RESTCONF and uses Yang to create the data base. I am creating prototype Data models that mirror the following drafts: * Capability model for South Bound interface (I2NSF manager to NSF device) https://datatracker.ietf.org/doc/draft-xia-i2nsf-capability-interface-im/ * Inter-Cloud DDoS Mitigation API - https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-mitigation-api/ * An Information Model for the Monitoring of Network Security Functions - https://tools.ietf.org/html/draft-zhang-i2nsf-info-model-monitoring-00 My understanding is the I2NSF capability interface focus on the south-bound interface to the NSF. To start out a Yang data model, I have created high-level Yang structures for these three models. I'll be asking questions about each model in a separate email thread, but answer me in any email thread. First on the capability model, network security control is a list of ECA policies, network security content capability is a list of security content capabilities, and attack mitigation is a list of attack mitigation capabilities. A suggested Yang High-level model structure is below. My question is how does an I2NSF manager engage the packet security policies? Does putting a policy in the network security control means it gets transmitted to the NSF device, and installed? Does the capability model provide both the way to list the functions (security content and mitigation) and a way to engage these functions? Sue Hares Initial Yang models ---------- ietf-i2nsf-capability-SBI +--rw i2nsf-policy-list +--rw policy-list-name string - name of policy list +--rw i2nsf-policy-rule* [name] +--rw name string - name of policy rule +--rw net-sec-ctl-rules uses ietf-pkt-eca-sec-policy // packet ECA security policy +--rw net-sec-content // list of content security capabilities uses i2nsf-sec-content // grouping of security capabilities +--rw net-attack-mitigate // list of mitigation capabilities / uses i2nsf-mitigate-rules //grouping of mitigation capabilities Is this a good way to start the capabilities structure? I have definitions for each of the "uses" statements in different models, but I need help understanding if this structure is correct. ietf-pkt-eca-sec-policy can be an extension of the I2RS/Configuration filters for packet Filter-Based RIBS. For the i2nsf-sec-content-capbility, does this form make sense: +--i2nsf-sec-content +--rw i2nsf-sec-content-cap* [order-id function-set-name] +--rw order-id // order # if in ordered list +--rw function-set-name string // name for function +--rw anti-virus // basic security content action | +--rw public-anti-virus [name] // anti-virus capability from public sources | ... // (yang structure details) | +--rw vendor-anti-virus [vendor] // anti-virus capability from vendor | | .... The mitigation has a similar structure to the i2nsf-sec-content. +--i2nsf-attack-mitigation +--rw i2nsf-attack-mitigate-fcn* [order-id, fcn-name] +--rw order-id +--rw fcn-name +--rw syn-flood | +--rw public-syn-flood* [name] | | ... | +--rw vendor-syn-flood* [vendor] | | ... +--rw UDP flood
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
