Inter-Cloud DDOS API Yang Model

proposes two different types of interfaces: North-bound interface (NBI) provided by the network security functions (NSFs) Interface between I2NSF user/client with network controller: Cloud Providers need to have a NBI to the network security functions that can share DDoS information. This document defines a yang data models based using the Yang model to provide the interface. This yang data module uses the ietf-i2nsf-capability model found in [draft-hres-i2nsf-capability-yang] which is based on the informational model found in on the , and initial work done in . Terms used in document are defined in . This yang data model assumes the inter-cloud interface looks like this:

Cloud-Provider-1 Cloud Provider 2 [client-software]<------> [agent software] [agent-software] <------->[client software] The client-software reads/writes the data in the remote cloud environment. The agent software responds with information on this cloud. defines the following type of functionality in NSFs. network security control content security control, and attack mitigation control This document contains high-level yang for each type of control. The features in each section have been built up from the following sources: firewalls, IDS, IPS. This includes ECA policy for in router, switches, firewalls, commercial level IDS, IPS

This yang module can be used by a clouder provider to consume another cloud provider's services, or to provide services for another cloud provider. For example, Cloud Provider A can be a consumer of Cloud Provider B via logical interface link 1 (shown in figure 1 below). Cloud Provider B can be a consumer of Cloud Provider A via logical link 2.

Cloud Provider A Cloud Provider B ............................. ........................... ( +--------------+ } ( +-------------+ ) ( | Inter-Cloud | consumer } ( | Inter-Cloud | ) ( | DDoS Manager +-1---------------------+ DDos Manager | ) ( | | ) ( provider | | ) ( | | ) ( consumer | | ) ( | +-2 --------------------+ | ) ( | | provider ) ( | | ) ( +----+--------+ ) ( +-----+--------+ ) ( | ) ( | ) ( | ) ( | ) ( +----+-------+ ) ( +---------+---+ ) ( | I2NSF | ) ( | I2NSF | ) ( | controller | ) ( | controller | ) ( +----+-------+ ) ( +---------+---+ ) ( | ) ( | ) ( -+---------+-------+-- ) ( --+-------+------- ) ( | | | ) ( | | ) ( +-----+ +--+--+ +--+--+ ) ( +-----+ +-----+ ) ( | NSF | | NSF | | NSF | ) ( | NSF | | NSF | ) ( +-----+ +-----+ +-----+ ) ( +-----+ +-----+ ) .............................. ........................... Figure 1: Two cloud providers using Inter-Cloud DDoS API via yang module The yang module provides a list of cloud-provider structures indexed by name. Within the cloud-provider structure there is a name (e.g. Cloud Provider A), and API types (consumer or provider or both), and security identity key. These features allow the

This section describes the Inter-Cloud DDoS Yang module. This section includes the following: high-level yang for ietf-i2nsf-cloud-DDoS yang module, mapping of Inter-Cloud API () to specific Yang structures and NETCONF/RESTCONF function. The NETCONF/RESTCONF functions include NETCONF/RESTCONF calls, publication/subscription (pub/sub) push functional (I2RS requires pub/sub), and opstate. Overview of module utilized by ietf-i2nsf-cloud-DDoS yang module

The this section has the high-level yang for ietf-i2nsf-cloud-ddos module. This module references the following submodules contained in this draft: cfg-cloud-mitigate-policy, cfg-mitigate-monitoring, i2nsf-capabilities, and cloud-mitigate-opstate. Other data models that this module depends on are described in the next section. ietf-i2nsf-capability module (which is based on the information model in ) ietf-pkt-eca modulde in , and ietf-fb-rib module in .

ietf-i2nsf-cloud-ddos +--rw i2nsf-intercloud-ddos +--rw cloud-provider* [name] +--rw cloud-name string; +--rw cloud-api-type identitref +--rw cloud-sec-id uint64 +--rw Inter-Cloud-DDoS-capabilities | +--rw capability-query boolean | +--rw mitigation-req boolean | +--rw monitor-report boolean | +--rw monitor-parms boolean | +--rw knowledge-share boolean +--rw cfg-attack-mitigate-policy* [policy-id] +--rw policy-id uint64 +--rw policy-name string +--rw cfg-active boolean //policy cfg active +--rw cfg-mitigate-policy | uses cfg-cloud-mitigate-policy +--rw cfg-monitoring-policy* [mon-policy-id] | +--rw mon-policy-id uint64 | uses cfg-mitigate-monitoring +--rw opstate-exists boolean +--rw cfg-cloud-capabilities | uses i2nsf-capabilities +--ro mitigation-opstate | +--ro mitigation-policy* [policy-id] | | +--ro policy-id uint32 | | +--ro status | | | uses cloud-mitigate_opstate rpc: +--x start-mitigation | ... +--x stop-mitigation [policy-id] | ... +--x reset opstate-counters | ... notifications: +--n inter-cloud-capability-change | ... +--n policy-change | ... +--n opstate-reset | ... +--n mitigation-failure | .. Figure 1: ietf-i2nsf-cloud-DDos Model High level yang structure

+--rw cfg-cloud-mitigate-policy* [] +--rw flood-rate-limit | +--rw max-rate integer +--rw syn-flood-mitigation* | +--rw SFM-APP-name string +--rw tcp-flood-protection* | +--rw TFP-APP-name string +--rw udp-flood-mitigation* | +--rw SFM-APP-name string +--rw max-connect-rate | +--rw interval uin632 | +--rw rate uint64 +--rw max-newconnect-rate | +--rw interval uint32 | +--rw rate uint64 +--rw frag-packet-rate | +--rw interval uint32 | +--rw rate uint64 +--rw packet-rate | +--rw interval uint32 | +--rw rate uint64 +--rw max-newconnect-rate | +--rw interval uint32 | +--rw rate uint64 +--rw black-hole-function* | +--rw BPF-AP1-name string +--rw 32-type-rate | +--rw mitigation-type string | +--rw rate uint64 +--rw bgp-signals | +--rw 24-community boolean | +--rw slash-24-removal bpolean +--rw bgp-flowspec-policy | uses fb-rib:ietf-fb-rib:bgp-fb-rib Figure 2: Configured cloud mitigation policy High level yang structure

+--ro cloud-mitigate_opstate +--ro stats-reset-id uint64 +--ro support-opstate [stats-pull-id] | +--ro traffic-cnts boolean | +--ro mitigation-cnts boolean | +--ro sflow-monitoring bollean | +--ro share-blacklist boolean +--ro traffic-cnts | +--ro pkts-matched uint64 | +--ro bytes-matches uint64 +--ro mitigation-cnt +--ro hit-flood-rate-limit uint64 +--ro used-sync-mitigation uint64 +--ro used TCP-flood uint64 +--ro used UDP-flood uint64 +--ro hit-connect-max uint64 +--ro hit-newconnect-max uint64 +--ro hit-frag-packet-rate-max uint64 +--ro hit-packet-rate-max uint64 +--ro hit-newconnect-rate-max uint64 +--ro used-blackhole uint64 +--ro used-bgp-signals uint64 | +--ro used-24-community uint64 | +--ro used-slash-24-removal uint64 +--ro bgpflowspec-stat uint64 | uses fb-rib:ietf-fb-rib:bgp-fb-rib +--ro knowledge-sharing +--ro current-blacklist* [blacklist-id] | +--ro black-list-id uint32 | +--ro ipv4-address ipv4-addr | +--ro ipv6-address ipv6-addr | +--ro transport-port uint16 | (need input on black list or | existing yang model with) Figure x - Operational state

+--rw cfg-mitigate-monitoring +--rw opstate-monitoring | +--rw traffic-stats boolean | +--rw detail-stats boolean | +--rw sflow-stats boolean | +--rw share-blacklist boolean | +--rw pub-sub-retrieve boolean | +--rw get-retrieve boolean +--rw sflow-redirect [endpoint-id] +--rw endpoint-id uint64 +--rw endpoint-name string +--rw sflow-enabled boolean +--rw endpoint-ip ip-addr +--rw start-time-sec uint64 //unix time second +--rw stop-time-sec uint64 //unix time seconds

This section describes the notifications that will be need to form the DDoS capabilities. However, these notifications are not yet in the yang module.

notifications: +--n inter-cloud-capability-change | ... +--n policy-change | ... +--n opstate-reset | ... +--n mitigation-failure | ..

The implementation of the actions requested in Inter-Cloud DDoS API () are the followingL API specifies query/response pair (per section 4.1) This is implemented with the GET in Yang module as requested in teh API. (per section 4.2.11)) The first thing a Cloud provider should query is the variable: Inter-Cloud-DDoS-capabilities/capability-query. If this value is true, then respondent provides cloud-capabilities entry with all the capabilities it will expose. RESTCONF: GET/GET-response with array of mitigation DDoS mitigation. NETCONF: GET/GET-response with array of mitigation Alternative 1: pub/sub subscription for DDoS capabilities after the initial get. API specifies specifies action request/response pair on based on a a pre-arranged agreement that specifies a set of policy rules (per , section 4.1.2 and section 4.2.2). This data model places the policy rules in the cfg-attack-mitigate-policy array indexed by a policy-id. The action request/response need to: acknowledge the request Execute a particular DDOS capability second response with logged actions and mitigation status The implementation of these functions are as follows; NETCONF/RESTCONF rpc "start-mitigation" provides the two responses based on activity. The rpc is described in the section below. RESTCONF functions of POST, GET, PUT, DELETE provide the add/change/delete functions for a particular policy cfg-attack-mitigate-policy indexed policy id. NETCONF get, edit-config, and delete provide the add/change/delete functions for a particular policy cfg-attack-mitigate-policy indexed policy id. Addition 1: Allow pub/sub as a mechanism for a Cloud provider to provide notifications for policy opstate to remote Cloud provider I2NSF consumer. Addition 2: Allow pub/sub as a mechanism for Cloud provider to report changes in policy to remote cloud provicer The feature provides for the monitoring and reporting of the a particular DDOS mitigation (per section 4.1.3 and section 4.2.3). This yang module utilizes the mitigation-opstate which provides a list of operational state per mitigation policy-id. The "cloud-mitigate_opstate" grouping has a "stats-reset-id" that implements an indicator if the stats have been reset. If the stats have not been reset, the counters should be monitonically increasig. The operations to handle add/change/delete for the monitoring polcy are: RESTCONF POST, GET, PUT, and DELETE, NETCONF get, edit-config, and delete NETCONF pub/sub that indicate if the remote side has add/changed/deleted monitoring policy. The operations to pull large amounts of monitoring data should utilize the pub/sub push facilities. Knowledge sharing looks to obtain remote Cloud Providers black list. This remote black list is part of the operational state retrieve (cloud-mitigate_opstate/knowledge-sharing). The knowledge-sharing capabilty indicates if the remote side supports this. The cfg-mitigate-monitoring grouping allows a policy to be configured to share-blacklist the black list.

This section review the other yang modules used by this mode. This section is provided for informational purposes. In the final revision of this yang model this section should be removed.

The filter-based RIB stores policy for flow specification configured in a node, distributed by I2RS, and received or configured by BGP peers and installed in the kernel. It is used by this model to store BGP flow specification policy received or locally configured so that it can be easily compared with other flow specification policy set in NSF devices. Note: This section is provided for informational purposes. In the final revision of this yang model this section should be removed

The High level yang for the filter-based RIB Augments rt:logical-network-elements:\ :logical-network-element:network-instances: \ network-instance ietf-fb-rib module +--rw ietf-fb-rib +--rw default-instance-name string +--rw default-router-id rt:router-id +--rw config-fb-ribs if-feature "config-filter-based-RIB"; uses fb-ribs; +--rw i2rs-fb-ribs if-feature "I2RS-filter-based-RIB"; uses fb-rib-t:fb-ribs; +--rw bgp-fs-fb-ribs if-feature "BGP-FS-filter-based-RIB"; uses fb-rib-t:fb-ribs; ietf-fb-rib module +--rw ietf-fb-rib-opstate +--rw default-instance-name string +--rw default-router-id rt:router-id +--rw config-fb-rib-opstate if-feature "config-filter-based-RIB"; uses fb-rib-t:fb-ribs-oper-status; +--rw i2rs-fb-rib-opstate { if-feature "I2RS-filter-based-RIB"; uses fb-rib-t:fb-ribs-oper-status; +--rw bgp-fs-fb-rib-opstate if-feature "BGP-FS-filter-based-RIB"; uses fb-rib-t:fb-ribs-oper-status;

The packet eca policy yang model is used by the filter-based RIB and the I2NSF capability model. The high level yang for this model is described below.

The following yang model is available in and references . The High level yang for the data moel

ietf-i2nsf-capability +--rw nsf-capabilities +--rw capability* [name] +--rw nsf-name string +--rw cfg-net-secctl-capabilities | uses pkt-eca-policy:pkt-eca-policy-set +--rw cfg-net-sec-content-capabilities | uses i2nsf-content-caps | uses i2nsf-content-sec-actions +--rw cfg-attack-mitigate-capabilities* | uses i2nsf-mitigate-caps +--rw ITResource [ITresource-name] | uses cfg-ITResources Figure 2: ietf-i2nsf-capabilities High level yang structure

TBD

TBD. This model will require URN assignment for yang module.

Security concerns across-domain need to be discussed here.