Linda:
Thank you for defining the service layer and the capability layer. Let me
see if this picture is right for the simple Linux firewall
User level
| (query on policies)
(NBI) V
I2NSF Controller
(SBI) | per NSF policies (yang data Model)
NSF
| (IP table policies on linux)
Kernel
The Inter-Cloud interface is at the User level
Cloud 1 ------àI2NSF Controller(cloud 2)
Client agent/server
Cloud 2 ß------- Cloud 2
I2NSF client
Controller
Do I understand this correctly?
Sue
From: I2nsf [mailto:[email protected]] On Behalf Of Linda Dunbar
Sent: Wednesday, June 08, 2016 2:02 PM
To: Susan Hares; [email protected]
Cc: [email protected]
Subject: Re: [I2nsf] Help on turning I2NSF Information Models to Data Models
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-mitigatio
n-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, Lets 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-mitigatio
n-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
Im 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-mitigatio
n-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. Ill 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
