Subject: [I2nsf] Any feedback on the Protocol Independent Flow Security Policies exchanged over I2NSF service layer interface?

From: Linda Dunbar <[email-masked]>
Date: Wed, 8 Jun 2016 19:11:51 +0000

https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-mitigation-api/ is more about flow security policy between Overlay network and underlay network.

As BGP Flow Specification [exchanged among BGP peers] can been deployed to achieve DDoS mitigation, the Flow Security Policy setting from one domain to another domain is protocol independent. I2NSF focuses on the information/data models, allowing domains using NETCONF or RESTCONF to exchange capability and set up the flow security policies.

"Protocol Independent Flow Security Policies" is for one domain (A) to request another domain (B) to enforce the desired policies for flows destined towards the Domain A. This can be an effective way for Domain A to prevent the unwanted attacks (e.g. DDoS)  from even occupying its links/ports connected to the Domain B.

BGP flow specification is configured in the BGP peers, whereas the I2NSF Protocol Independent Flow Security Policies"  are exchanged between domains, which can be
Enterprise domain <-> Provider domain, Overlay <-> Underlay, Cloud provider <-> Underlay.

Enterprise can have its own DDoS mitigation tools, but those internal DDoS mitigation tools can't effectively prevent the DoS attacks that saturate the access ports and links between Enterprise and the providers.

Same goes for Overlay networks.

Very often, the paths (or links) among nodes of a overlay network are provided by other network operators (a.k.a. "underlay network").  Very much like traditional networks placing FW (Firewall) or IPS (Intrusion Prevention System) on the wire to enforce the flow security rules, I2NSF Protocol Independent Flow Security Policies can be used by overlay networks to request certain flow based security rules to be enforced by its underlay networks, to prevent the unwanted attacks traffic from occupying the physical links and ports to the overlay network nodes, and to avoid the overlay nodes' CPU/Storage/Port utilization being consumed down by the various attacks.  Here is one example of "Overlay Video Communication network" exchange Flow Policies to the Underlay network.

The goal of I2NSF is to specify the common information model and data model for the  Protocol Independent Flow Security Policies which can be queried and set between domains.

https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-mitigation-api/ is just the starting point. (needs more work to improve the clarity). We are asking if people to express their opinion on this work to the [email-masked]<mailto:[email-masked]> list.

Thanks, Linda

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 16 Jun 2016 03:01:31 +0000

HI Linda,
Please see my comments inline:

发件人: I2nsf [mailto:[email-masked]] 代表 Linda Dunbar
发送时间: 2016年6月9日 3:12
收件人: [email-masked]
主题: [I2nsf] Any feedback on the Protocol Independent Flow Security Policies exchanged over I2NSF service layer interface?

“Protocol Independent Flow Security Policies” is for one domain (A) to request another domain (B) to enforce the desired policies for flows destined towards the Domain A. This can be an effective way for Domain A to prevent the unwanted attacks (e.g. DDoS)  from even occupying its links/ports connected to the Domain B.
[Frank]: the term “capability” is more suitable to be used for manage/control the NSF. Meanwhile, I like the new term “Protocol Independent Flow Security Policies” proposed here to exchange flow security policies among different domains. In addition, I think using the term of “DDoS mitigation service” is more appropriate rather than “DDoS mitigation capability” since it works on the service layer.

BGP flow specification is configured in the BGP peers, whereas the I2NSF Protocol Independent Flow Security Policies”  are exchanged between domains, which can be
Enterprise domain <-> Provider domain, Overlay <-> Underlay, Cloud provider <-> Underlay.

Enterprise can have its own DDoS mitigation tools, but those internal DDoS mitigation tools can’t effectively prevent the DoS attacks that saturate the access ports and links between Enterprise and the providers.

Very often, the paths (or links) among nodes of a overlay network are provided by other network operators (a.k.a. “underlay network”).  Very much like traditional networks placing FW (Firewall) or IPS (Intrusion Prevention System) on the wire to enforce the flow security rules, I2NSF Protocol Independent Flow Security Policies can be used by overlay networks to request certain flow based security rules to be enforced by its underlay networks, to prevent the unwanted attacks traffic from occupying the physical links and ports to the overlay network nodes, and to avoid the overlay nodes’ CPU/Storage/Port utilization being consumed down by the various attacks.  Here is one example of “Overlay Video Communication network” exchange Flow Policies to the Underlay network.

Thanks, Linda