One document matched: draft-hares-i2nsf-ddos-yang-dm-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2975 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2975.xml">
<!ENTITY RFC3198 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3198.xml">
<!ENTITY RFC3234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3234.xml">
<!ENTITY RFC3539 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3539.xml">
<!ENTITY RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC6421 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6421.xml">
<!ENTITY RFC7297 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7277.xml">
<!ENTITY I-D.ietf-netmod-acl-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netmod-acl-model-06.xml">
<!ENTITY I-D.ietf-opsawg-firewalls SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-opsawg-firewalls-01.xml">
<!ENTITY I-D.hares-i2nsf-capability-yang SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-hares-i2nsf-capability-yang-00.xml">
<!ENTITY I-D.ietf-i2rs-fb-rib-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-i2rs-fb-rib-data-model-00.xml">
<!ENTITY I-D.ietf-i2rs-fb-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-i2rs-fb-rib-info-model-00.xml">
<!ENTITY I-D.ietf-i2rs-pkt-eca-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-i2rs-pkt-eca-data-model-00.xml">
<!ENTITY I-D.ietf-i2nsf-gap-analysis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-i2nsf-gap-analysis-00.xml">
<!ENTITY I-D.ietf-i2nsf-problem-and-use-cases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-i2nsf-problem-and-use-cases-00.xml">
<!ENTITY I-D.ietf-i2nsf-terminology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-i2nsf-terminology-00.xml">
<!ENTITY I-D.xia-i2nsf-capability-interface-im SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-xia-i2nsf-capability-interface-im-05.xml">
<!ENTITY I-D.xia-i2nsf-service-interface-dm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-xia-i2nsf-service-interface-dm-00.xml">
<!ENTITY I-D.fang-i2nsf-inter-cloud-ddos-mitigation-api SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-hares-i2nsf-ddos-yang-dm-00.txt" ipr="trust200902">
<front>
<title abbrev="Inter-Cloud DDoS">Inter-Cloud DDOS API Yang Model </title>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Huawei</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<phone>+1-734-604-0332</phone>
<email>shares@ndzh.com</email>
</address>
</author>
<author fullname="Robert Moskowitz" initials="R." surname="Moskowitz">
<organization>HTT Consulting</organization>
<address>
<postal>
<street> </street>
<city> Oak Park</city>
<region>MI</region>
<code></code>
<country>USA</country>
</postal>
<phone>+1-248-968-9809 </phone>
<email>rgm@htt-consult.com</email>
</address>
</author>
<date year="2016" />
<area>Security Area</area>
<workgroup>I2NSF</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>I2NSF</keyword>
<abstract>
<t> This document defines a yang model that
enables two Cloud providers to exchange DDoS based
on Inter-Cloud DDoS Mitigation API
[draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01].
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="I-D.ietf-i2nsf-problem-and-use-cases"></xref> proposes two
different types of interfaces:
<list style="symbols">
<t>North-bound interface (NBI) provided by the network security
functions (NSFs)
</t>
<t>Interface between I2NSF user/client with network controller:
</t>
</list>
Cloud Providers need to have a NBI to the network security functions
that can share DDoS information.
</t>
<t>
This document defines a yang data models based <xref target="I-D.fang-i2nsf-inter-cloud-ddos-mitigation-api"></xref>
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 <xref target="I-D.xia-i2nsf-capability-interface-im"></xref>,
and initial work done in <xref target="I-D.xia-i2nsf-service-interface-dm"></xref>.
Terms used in document are defined in <xref target="I-D.ietf-i2nsf-terminology"></xref>.
</t>
<t>
This yang data model assumes the inter-cloud interface looks like this:
<figure>
<artwork>
Cloud-Provider-1 Cloud Provider 2
[client-software]<------> [agent software]
[agent-software] <------->[client software]
</artwork>
</figure>
</t>
<t> The client-software reads/writes the data in the remote
cloud environment. The agent software responds with
information on this cloud.
</t>
<t>
<xref target="I-D.xia-i2nsf-capability-interface-im"></xref> defines the following
type of functionality in NSFs.
<list style="symbols">
<t> network security control
</t>
<t> content security control, and
</t>
<t>attack mitigation
control
</t>
</list>
</t>
<t>This document contains high-level yang for each type of control.
The features in each section have been built up from the following sources:
<list style="hanging">
<t hangText="open-source: ">firewalls, IDS, IPS. This includes
ECA policy for
</t>
<t hangText="basic-firewalls: "> in router, switches,
firewalls,
</t>
<t hangText="firewall products"> commercial level
</t>
<t hangText="specialized devices"> IDS, IPS</t>
</list>
</t>
</section>
<section title="Using this Yang module to implement the Inter-Cloud API">
<t>
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.
</t>
<t>
<figure>
<artwork>
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
</artwork>
</figure>
</t>
<t>
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
</t>
<t>
<figure>
<artwork>
Cloud Provider A Cloud Provider B
............................. ...........................
( +--------------+ } ( +-------------+ )
( | Inter-Cloud | consumer } ( | Inter-Cloud | )
( | DDoS Manager +-1---------------------+ DDos Manager | )
( | /cloud- | ) ( provider | /cloud- | )
( | provider | ) ( | provider | )
( | [A][B] | ) ( | [A][B] | )
( +----+--------+ ) ( +-----+--------+ )
( | ) ( | )
( | ) ( | )
............................. .............................
</artwork>
</figure>
</t>
</section>
<section title="Inter-Cloud DDOS Yang Module ">
<t>This section describes the Inter-Cloud DDoS Yang module.
This section includes the following:
<list style="symbols">
<t>high-level yang for ietf-i2nsf-cloud-DDoS yang module, </t>
<t> mapping of Inter-Cloud API (<xref target="I-D.fang-i2nsf-inter-cloud-ddos-mitigation-api"></xref>)
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.
</t>
<t>Overview of module utilized by ietf-i2nsf-cloud-DDoS yang module
</t>
</list>
</t>
<section title="High-level Yang modules">
<t>
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.
</t>
<t> Other data models that this module depends on are described in the next section.
<list style="symbols">
<t>ietf-i2nsf-capability module <xref target="I-D.hares-i2nsf-capability-yang"></xref>
(which is based on the information model in <xref target="I-D.xia-i2nsf-capability-interface-im"></xref>)
</t>
<t>ietf-pkt-eca modulde in <xref target="I-D.ietf-i2rs-pkt-eca-data-model"></xref>, and
</t>
<t>ietf-fb-rib module in <xref target="I-D.ietf-i2rs-fb-rib-data-model"></xref>.
</t>
</list>
</t>
<section title="ietf-i2nsf-cloud-ddos Main module">
<t>
<figure>
<artwork>
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
</artwork>
</figure>
</t>
</section>
<section title="cfg-cfg-cloud-mitigate-policy sub-module ">
<t>
<figure>
<artwork>
+--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
</artwork>
</figure>
</t>
</section>
<section title="Operational state (cloud-mitigation_opstate) ">
<t>
<figure>
<artwork>
+--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
</artwork>
</figure>
</t>
</section>
<section title="Configuring Montoring (cfg-mitigate-monitoring module)">
<t>
<figure>
<artwork>
+--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
</artwork>
</figure>
</t>
</section>
<section title="rpcs for Inter-Cloud Yang Module">
<t>
<figure>
<artwork>
rpc for Inter-Cloud Yang modules
rpc:
+--x start-mitigation
| +--input
| | +--w cloud-name string
| | +--w cloud-api-type identitref
| | +--w cloud-sec-id uint64
| | +--w policy-id uint64
| | +--w request-identifier uint64
| | +--w cfg-mitigation-type
| | +--w params
| +--output
| | +--w cloud-name string
| | +--w cloud-api-type identitref
| | +--w cloud-sec-id uint64
| | +--w policy-id uint64
| | +--w cfg-mitigation boolean
| | +--ro status identityref /reject, started, done
| | +--ro cfg-mitigation-type string
| | +--ro result-params
| | | (choice based on type )
+--x stop-mitigation [policy-id]
| +--input
| | +--w cloud-name string
| | +--w cloud-api-type identitref
| | +--w cloud-sec-id uint64
| | +--w policy-id uint64
| | +--w request-identifier uint64
| | +--w cfg-mitigation-type string
| | +--ro result-params
| | | (choice based on type )s
| +--output
| | +--ro cloud-name string
| | +--ro cloud-api-type identitref
| | +--ro cloud-sec-id uint64
| | +--ro policy-id uint64
| | +--ro cfg-mitigation boolean
| | +--ro status identityref /reject, started, done
| | +--ro cfg-mitigation-type
| | +--ro result-params
+--x reset opstate-counters
| +--input
| | +--w cloud-name string
| | +--w cloud-api-type identitref
| | +--w cloud-sec-id uint64
| | +--w policy-id uint64
| | +--w request-identifier uint64
| +--output
| | +--ro cloud-name string
| | +--ro cloud-api-type identitref
| | +--ro cloud-sec-id uint64
| | +--ro policy-id uint64
| | +--ro request-identifier uint32
| | +--ro stats-reset-id uint64
</artwork>
</figure>
</t>
</section>
<section title="notifications for Inter-Cloud Yang Module">
<t>This section describes the notifications that
will be need to form the DDoS capabilities. However, these
notifications are not yet in the yang module.
</t>
<t>
<figure>
<artwork>
notifications:
+--n inter-cloud-capability-change
| ...
+--n policy-change
| ...
+--n opstate-reset
| ...
+--n mitigation-failure
| ..
</artwork>
</figure>
</t>
</section>
</section>
<section title="Implementing inter-Cloud DDoS API with Yang module">
<t>The implementation of the actions requested in Inter-Cloud DDoS API (<xref target="I-D.fang-i2nsf-inter-cloud-ddos-mitigation-api"></xref>)
are the followingL
<list style="hanging">
<t hangText="query DDoS capabilities: "> API specifies query/response pair
(per <xref target="I-D.fang-i2nsf-inter-cloud-ddos-mitigation-api"></xref> section 4.1)
This is implemented with the GET in Yang module as requested in teh API.
(per <xref target="I-D.fang-i2nsf-inter-cloud-ddos-mitigation-api"></xref> 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.
<list style="symbols">
<t>RESTCONF: GET/GET-response with array of mitigation DDoS mitigation. </t>
<t>NETCONF: GET/GET-response with array of mitigation </t>
<t> Alternative 1: pub/sub subscription for DDoS capabilities after the initial get. </t>
</list>
</t>
<t hangText="Mitigation:" > API specifies specifies action request/response pair on based on a
a pre-arranged agreement that specifies a set of policy rules
(per <xref target="I-D.fang-i2nsf-inter-cloud-ddos-mitigation-api"></xref>, 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:
<list style="numbers">
<t>acknowledge the request
</t>
<t>Execute a particular DDOS capability
</t>
<t>second response with logged actions and mitigation status
</t>
</list>
The implementation of these functions are as follows;
<list style="symbols">
<t>NETCONF/RESTCONF rpc "start-mitigation" provides the two responses based on activity. The
rpc is described in the section below.
</t>
<t>RESTCONF functions of POST, GET, PUT, DELETE provide the add/change/delete
functions for a particular policy cfg-attack-mitigate-policy indexed
policy id.
</t>
<t>NETCONF get, edit-config, and delete provide the add/change/delete
functions for a particular policy cfg-attack-mitigate-policy indexed
policy id.
</t>
<t>Addition 1: Allow pub/sub as a mechanism for a Cloud provider to
provide notifications for policy opstate to remote Cloud provider
I2NSF consumer. </t>
<t>Addition 2: Allow pub/sub as a mechanism for Cloud provider
to report changes in policy to remote cloud provicer
</t>
</list>
</t>
<t hangText="Monitor and Report Mitigation:" > The feature provides for the
monitoring and reporting of the a particular DDOS mitigation
(per <xref target="I-D.fang-i2nsf-inter-cloud-ddos-mitigation-api"></xref> 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:
<list style="symbols">
<t>RESTCONF POST, GET, PUT, and DELETE,
</t>
<t>NETCONF get, edit-config, and delete</t>
<t>NETCONF pub/sub that indicate if the remote
side has add/changed/deleted monitoring policy.</t>
</list>
The operations to pull large amounts of monitoring data should utilize the
pub/sub push facilities.
</t>
<t hangText="Knowledge sharing:" > 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.
</t>
</list>
</t>
</section>
</section>
<section title="Oveview of Other Yang Modules referenced">
<t>
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.
</t>
<section title="Filter-Based RIB data model">
<t>
The filter-based RIB <xref target="I-D.ietf-i2rs-fb-rib-data-model"></xref>
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.
</t>
<t>Note: This section is provided for informational purposes.
In the final revision of this yang model this section should be removed
</t>
<t>
<figure>
<artwork>
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;
</artwork>
</figure>
</t>
</section>
<section title="Packet ECA Policy">
<t> The packet eca policy yang model
<xref target="I-D.ietf-i2rs-pkt-eca-data-model"></xref> is used by the filter-based RIB
and the I2NSF capability model. The high level yang for this model is described below.
</t>
<t>
<figure>
<artwork>
module ietf-pkt-eca-policy
+--rw pkt-eca-policy-cfg
| +--rw pkt-eca-policy-set
| +--rw groups* [group-name]
| | +--rw group-name string
| | +--rw vrf-name string
| | +--rw address-family
| | +--rw group-rule-list* [rule-name]
| | | +--rw rule-name
| | | +--rw rule-order-id
| | | +--rw default-action-id integer
| | | +--rw default-resolution-strategy-id integer
| +--rw rules* [order-id rule-name]
| +--rw order-id
| +--rw rule-name
| +--rw cfg-rule-conditions [cfgr-cnd-id]
| | +--rw cfgr-cnd-id integer
| | +--rw eca-event-match
| | | +--rw time-event-match*
| | | | .. (time of day)
| | +--rw eca-condition-match
| | | +--rw eca-pkt-matches*
| | | | ... (L1-L4 matches)
| | | +--rw eca-user-matches*
| | | | (user, schedule, region, target,
| | | | state, direction)
| +--rw cfg-rule-actions [cfgr-action-id]
| | +--rw cfgr-action-id
| | +--rw eca-actions* [action-id]
| | | +--rw action-id uint32
| | | +--rw eca-ingress-act*
| | | | ... (permit, deny, mirror)
| | | +--rw eca-fwd-actions*
| | | | ... (invoke, tunnel encap, fwd)
| | | +--rw eca-egress-act*
| | | | .. .
| | | +--rw eca-qos-actions*
| | | | ...
| | | +--rw eca-security-actions*
| +--rw pc-resolution-strategies* [strategy-id]
| | +--rw strategy-id integer
| | +--rw filter-strategy identityref
| | | .. FMR, ADTP, Longest-match
| | +--rw global-strategy identityref
| | +--rw mandatory-strategy identityref
| | +--rw local-strategy identityref
| | +--rw resolution-fcn uint32
| | +--rw resolution-value uint32
| | +--rw resolution-info string
| | +--rw associated-ext-data*
| | | +--rw ext-data-id integer
| +--rw cfg-external-data* [cfg-ext-data-id]
| | +--rw cfg-ext-data-id integer
| | +--rw data-type integer
| | +--rw priority uint64
| | | uses external-data-forms
| | ... (other external data)
+--rw pkt-eca-policy-opstate
+--rw pkt-eca-opstate
+--rw groups* [group-name]
| +--rw rules-installed;
| +--rw rules_status* [rule-name]
| +--rw strategy-used [strategy-id]
| +--rw
+--rw rule-group-link* [rule-name]
| +--rw group-name
+--rw rules_opstate* [rule-order rule-name]
| +--rw status
| +--rw rule-inactive-reason
| +--rw rule-install-reason
| +--rw rule-installer
| +--rw refcnt
+--rw rules_op-stats* [rule-order rule-name]
| +--rw pkts-matched
| +--rw pkts-modified
| +--rw pkts-forward
+--rw op-external-data [op-ext-data-id]
| +--rw op-ext-data-id integer
| +--rw type identityref
| +--rw installed-priority integer
| | (other details on external data )
</artwork>
</figure>
</t>
</section>
<section title="Capability high level model">
<t>
The following yang model is available in
<xref target="I-D.hares-i2nsf-capability-yang"></xref>
and references
<xref target="I-D.ietf-i2rs-pkt-eca-data-model"></xref>.
</t>
<t>
The High level yang for the data moel
<figure>
<artwork>
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
</artwork>
</figure>
</t>
</section>
</section>
<section title="YANG Modules">
<t>TBD </t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>TBD. This model will require URN assignment for yang module.
</t>
</section>
<section title="Security Considerations">
<t>Security concerns across-domain need to be
discussed here.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC6421;
&I-D.hares-i2nsf-capability-yang;
&I-D.ietf-i2rs-fb-rib-data-model;
&I-D.ietf-i2rs-pkt-eca-data-model;
&I-D.fang-i2nsf-inter-cloud-ddos-mitigation-api;
</references>
<references title="Informative References">
&RFC2975;
&RFC3198;
&RFC3234;
&RFC3539;
&RFC4949;
&RFC7297;
&I-D.ietf-i2nsf-problem-and-use-cases;
&I-D.ietf-i2nsf-gap-analysis;
&I-D.ietf-i2nsf-terminology;
&I-D.xia-i2nsf-capability-interface-im;
&I-D.xia-i2nsf-service-interface-dm;
&I-D.ietf-i2rs-fb-rib-info-model;
&I-D.ietf-netmod-acl-model;
&I-D.ietf-opsawg-firewalls;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 04:28:04 |