One document matched: draft-hares-i2rs-dataflow-req-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 RFC2330 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2330.xml">
<!ENTITY RFC3176 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3176.xml">
<!ENTITY RFC5070 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5070.xml">
<!ENTITY RFC5575 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5575.xml">
<!ENTITY RFC6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6536 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6536.xml">
<!ENTITY RFC7011 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7011.xml">
<!ENTITY RFC7312 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7312.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
<!ENTITY I-D.ietf-i2rs-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-info-model.xml">
<!ENTITY I-D.ietf-i2rs-ephemeral-state SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-ephemeral-state.xml">
<!ENTITY I-D.ietf-i2rs-traceability SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-traceability.xml">
<!ENTITY I-D.ietf-i2rs-usecase-reqs-summary SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-usecase-reqs-summary.xml">
<!ENTITY I-D.ietf-i2rs-pub-sub-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-pub-sub-requirements.xml">
<!ENTITY I-D.ietf-i2rs-protocol-security-requirements
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-protocol-security-requirements.xml">
<!ENTITY I-D.ietf-dots-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dots-requirements.xml">
<!ENTITY I-D.ietf-mile-rfc5070-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mile-rfc5070-bis.xml">
<!ENTITY I-D.ietf-i2nsf-problem-and-use-cases
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2nsf-problem-and-use-cases.xml">
<!ENTITY I-D.ietf-netmod-acl-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-acl-model.xml">
<!ENTITY I-D.ietf-netmod-yang-metadata SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-yang-metadata.xml">
<!ENTITY I-D.ietf-netconf-restconf SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-restconf.xml">
<!ENTITY I-D.ietf-netconf-yang-push SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-yang-push.xml">
<!ENTITY I-D.kini-i2rs-fb-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.kini-i2rs-fb-rib-info-model.xml">
<!ENTITY I-D.hares-i2rs-fb-rib-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-fb-rib-data-model.xml">
<!ENTITY I-D.wu-idr-flowspec-yang-cfg SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wu-idr-flowspec-yang-cfg.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-i2rs-dataflow-req-00.txt" ipr="trust200902">
<front>
<title abbrev="I2RS Data Flow">I2RS Data Flow Requirements </title>
<author fullname="Susan Hares" initials="S." surname="Hares">
<organization> Huawei </organization>
<address>
<postal>
<street></street>
<city>Saline</city>
<country>US</country>
</postal>
<email>shares@ndzh.com </email>
</address>
</author>
<date year="2016" />
<area>Routing Area</area>
<workgroup>I2RS working group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>I2RS</keyword>
<abstract>
<t>This document covers requests to the netmod and netconf Working
Groups for functionality to support the data flows described in
the I2RS architecture and the I2RS use cases requirements summary.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Interface to the Routing System (I2RS) Working Group is chartered
with providing architecture and mechanisms to inject into and
retrieve information from the routing system. The I2RS Architecture
document <xref target="I-D.ietf-i2rs-architecture"></xref> abstractly documents a number
of requirements for implementing the I2RS requirements.</t>
<t>
The I2RS Working Group has chosen to use the YANG data modeling
language <xref target="RFC6020"></xref> as the basis to implement its mechanisms.
</t>
<t>
Additionally, the I2RS Working group has chosen to use the NETCONF
<xref target="RFC6241"></xref> and its similar but lighter-weight relative RESTCONF
<xref target="I-D.ietf-netconf-restconf"></xref> as the protocols for carrying I2RS.
NETCONF and RESTCONF are suitable for handling the configuration portion of the
I2RS protocol, but need extensions to handle the I2RS use cases
described in <xref target="I-D.ietf-i2rs-usecase-reqs-summary"></xref>.
The requirements for these functionalities include:
<list style="symbols">
<t>ephemeral state - as defined in
<xref target="I-D.ietf-i2rs-ephemeral-state"></xref></t>
<t>notifications and events - as defined in
<xref target="I-D.ietf-i2rs-pub-sub-requirements"></xref>
</t>
<t>traceability - as defined in
<xref target="I-D.ietf-i2rs-traceability"></xref>
</t>
<t>protocol security - as defined in
<xref target="I-D.ietf-i2rs-protocol-security-requirements">
</xref></t>
<t>Generic interfaces to Protocol Local-RIBs or Policy Data bases, </t>
<t>Large data flows,
</t>
<t>Traffic monitoring data,</t>
<t>Data flows for Action sequences, and </t>
<t>data flows during network outages or attacks</t>
</list>
</t>
<t>This document describes the protocol requirements for these
last five types of requirements. The first section summarizes the
data flow requirements. Section 2 details how the I2RS use case requirements
for Generic interfaces to protocol RIBS or policy data base do not
add any requirements to the I2RS protocol. Section 3 describes how the
describes
</t>
</section>
<section title="Summary of I2RS Data Flow Requirements">
<t>Additional requirements from Generic Interface:None</t>
<t>
The additional Data flow requirements are:
<list>
<t>DF-REQ-01: Pull Publication/subscription mechanism
</t>
<t>DF-REQ-02: The support of large data transfers in
a data format agnostic format. This the I2RS protocol should
support transport of data in any format including: XML, JSON,
MTL (ALias/Waveformat, .mtl), protobufs, and ascii text.
</t>
<t>DF-REQ-03: Support of any transport,</t>
<t>DF-REQ-04 Support for the ability to send information
using IPFIX protocol and IPFIX templates,</t>
<t>DF-REQ-05: Support of traffic statistics for filter-based policies
(BGP-FS, I2RS FB-RIB, policy routing), IPPM, SFLOW, and others in yang data model
format or IPFIX tempalte formats over XML or JSON.
</t>
<t>DF-REQ-06: Ability to carry ALTO protocol objects using ALTO protocol
transport (http) with JSON encodings (GET, POST-PUT) for ALTO codes handling
ALTO data errors, overload codes, and temporary redirects plus
ALTO resource directory requests. ALTO error codes, overload codes,
temporary redirets, and diretory requetss should be transformed to
I2RS events.
</t>
<t> DF-REQ-07: I2RS should be able to support an action
which allocates internal resources for the I2RS agent
(memory, processing time, interrupts) and outbound data flow
bandwidth. It is expected that an action would be
included in a data model in an "rpc"-like format in yang.
</t>
<t>DF-REQ-08: The I2RS should be able to support an action that interacts with
routing OAM functions. </t>
<t>I2RS-DF-09:I2RS Agent must be able signals that it will be using
different protocol with different constraints (security,
priority of data, or transport) or different constraints on the
existing protocol (smaller message sizes, different priorities on
data carried, or different security levels).
</t>
<t>I2RS-DF-10: I2RS Agent-I2RS Client protocol must allow for a common
session level function that supports data flow resilence, "chunking" of data
appropriate sizes for congestion, message integrity and replay protection
so that during periods of DDoS and bursty congestion due to security attacks.
A common "session" function will support an application layer "session" sending
data over multiple transports during periods of outage, network attack or congestion.
</t>
<t>DF-REQ11: The I2RS protocol must allow for security that exist at the
applications' "session" level that spans multiple transports. </t>
<t>DF-REQ-12: Support of the ability to send/receive IPFIX Templates, and
information using IPFIX template formats but use another protocol to
transport the data that can handle congestion and DDoS attacks.
</t>
<t>DF-REQ-13: Yang MUST have a way to
indicate in a data model has actions which allow:
different transports, different resource constraints, or different
security.
</t>
<t>DF-REQ-14: Yang MUST have a way to indicate
a data model has different levels of checking where:
lowest level is message form only, medium level checks
message format plus data syntax, and highest level uses the
message format, data syntax and referential check netconf configuration does.
The default level for I2RS is message format plus data syntax.
</t>
</list>
</t>
</section>
<section title="Generic Interfaces to Routing Functions">
<t>The I2RS use case requirement suggests that a generic interface
be created to protocol local RIBs and a generic interface be available
to configure policies.
</t>
<section title="I2RS-Generic Interface to Local-RIB">
<t>The I2RS requirements (<xref target="I-D.ietf-i2rs-usecase-reqs-summary"></xref>)
require that a generic interface be defined to the local-RIB in
protocols. This type of data flow does not require a new
type of data flow, but the definition of a new data model
that creates a generic local RIB and has operations to funnel
this generic Local-RIB to a specific protocol.
</t>
</section>
<section title="I2RS-Generic interfaces to Policies">
<t>The I2RS requirements suggest that I2RS have a generic
interface to routing policies for protocols, routing distribution,
or routing protocols. This generic interface is currently being
implemented as common definitions for data models. At this time,
This generic interface does not need additional protocol requirements.
</t>
</section>
<section title="I2RS Data Flow Requirements">
<t>These generic interfaces do not have any additional protocol
requirements.
</t>
</section>
</section>
<section title="Large Data Flow Requirements">
<t>This section decribes the data flow requirements
for large data flows, traffic flows measurements,
CDNI traffic flows, OAM and Action rqeuests, data flows during outages
or network attacks (DDoS (Distributed Denial of Service) or
other network attacks), and non-secure data flows.
These data flows are data flows which are not configuration
based data flows.
</t>
<section title="Large Data Flow Use Case Requirements">
<t>The I2RS use case for Large Data Collection systems
<xref target="I-D.ietf-i2rs-usecase-reqs-summary"></xref>
requires the I2RS protocol and data models:
<list style="symbols">
<t>be able to be done
at a high frequency and resolution with minimal impact
to devices memory or CPU (L-Data-REQ-01) ,
</t>
<t>use a data model which allows definition of the form
as part of the data model (L-Data-REQ-02) ,
</t>
<t>support a publication/subscription mechanism with
push/pull mechanism (L-Data-REQ-03), </t>
<t>(supports capability negotiation for
level of transport, security, and error handling as
a general configurations, per I2RS client-agent protocol
for all interfaces and all time instance,
or per I2RS interface client-agent protocol
per specific interface or per time instances.
(L-Data-REQ-04,L-Data-REQ-06, L-Data-REQ-07,
L-Data-REQ-08, and L-Data-REQ-09),
</t>
<t>dynamic subscription model set-up via IPFIX (L-REQ-12c),</t>
<t>support of subscriber and consumer I2RS-Agent pairs (L-REQ-12d),</t>
<t>remapping of Node's databases, </t>
<t>data format agnostic (L-Data-REQ-05),
</t>
<t>data models and I2RS protocol additions
that support of query, introspection
using data-base model that support a set of capabilities, data filters,
and error handling (stale data, repeated
transport failures, and other errors.)
Introspection supports data verification, inclusion of legacy
data, and merging of data flows based on meta-data.
(L-Data-REQ-11, L-Data-REQ-13),</t>
<t>Support of push of data synchronously or asyncronously
via registered subscriptions (L-Data-REQ-12a).</t>
<t>Pull of data in one-shot or multiple sequences (L-Data-REQ-12b), and </t>
<t>dynamic subscription model set-up via IPFIX (L-REQ-12c)</t>
</list>
</t>
<section title="Data Requirements Supported in pub-sub Requirements">
<t>All use case requirements for the publication/subscription service for the push
service from large data requirements 01-04 and 6-12 is found in
<xref target="I-D.ietf-i2rs-pub-sub-requirements"></xref>, and
an example protocol addition to netconf is include in
<xref target="I-D.ietf-netconf-yang-push"></xref>.
</t>
<t>
The requirements for the publication/subscription service for the pull model
are not specified in the <xref target="I-D.ietf-i2rs-pub-sub-requirements"></xref>, but
a majority of the pub-sub requirements and mechanisms can be reused.
In a pull, the publisher prepares the data that is pulled by a few receivers who
then distribute it to the receivers. The pull mechanism would have
a different "pull latency" versus the push latencey, and a set of parameters
which indicate the amount of data stored if receivers did not pull the data within
a certain time. </t>
<t>At this time, the pull-model of the publication/subscription model is
not being requested by vendors or operators.
</t>
</section>
<section title="Data Flow Requirements Outside of Pub/Sub Requirements">
<t>The data flow requirements for large data flows also include
support for data flows outside of publication/subscription
via any transport (L-Dat-REQ-04) and any data format (L-Data-REQ-05).
Support for the IPFIX protocol or just the IPFIX data formats is required.
</t>
</section>
<section title="I2RS Data Flow Requirements">
<t>The following requirements are additional data flow requirements for large data flows.
<list>
<t>(DF-REQ-01): Support of Subscription/publication service in pull model, </t>
<t>(DF-REQ-02): Support of any data format including:
XML, JSON, (MTL (Alias/WaveFormat,.mtl),
protobufs, and ascii,</t>
<t>(DF-REQ-03): Support of any transport, and </t>
<t>(DF-REQ-04): support of the ability send information using
IPFIX templates as a reporting structure over the IPFIX protocol,
or over other data formats.
</t>
</list>
</t>
<t>
<xref target="I-D.ietf-netconf-yang-push"></xref>
supports XML and JSON in its first release, and provides
an ability to register extra formats, but these requirements
should also support large data flows sent outside of the
publication-subscription service.
</t>
</section>
</section>
<section title="Traffic Flow Measurements">
<t>
The I2RS requirements for the Protocol independent use cases
requires the support off interactions with traffic flow and other
network management Protocols (requirements PI-REQ-05, PI-REQ06)
in <xref target="I-D.ietf-i2rs-usecase-reqs-summary"></xref>).
</t>
<t>The following IETF protocol pass traffic related information:
<list style="symbols">
<t>BGP Flow Specification (BGP-FS) (<xref target="RFC5575"></xref></t>
<t>IPFIX - IP Flow Information (<xref target="RFC7011"></xref>)
that reports on a wide variety of routing system statistics, and
</t>
<t>IPPM - IP Performance mangement
(<xref target="RFC2330"></xref>, <xref target="RFC7312"></xref>)
that reports on one-way or two-way end-to-end network performance statistics,
</t>
</list>
In addition the SFLOW(<xref target="RFC3176"></xref>)
of layer 2 devices is supported by many routers. Other
traffic flows may be measured in support of IDS/IPS, but these
will be covered in the section on security flows.
</t>
<t>
Additional traffic flow models are being defined to configure traffic flow policy and
to monitor the statistics on the use of the traffic flow statistics:
<list style="symbols">
<t>BGP Flow Specification (BGP-FS) yang model <xref target="I-D.wu-idr-flowspec-yang-cfg"></xref>
contains flow filter match statistics. </t>
<t>I2RS Filter-Based RIB yang model (<xref target="I-D.kini-i2rs-fb-rib-info-model"></xref>,
<xref target="I-D.hares-i2rs-fb-rib-data-model"></xref>)- yang model contains
ephemeral flow statistics, </t>
<t>Filter-Based RIB (draft-hares-rtgwg-fb-rib-data-model) contains both
flow filter match statistics, </t>
</list>
</t>
<section title="Protocol Requirements based on Traffic Flows">
<t>
Due to the potentially large data flow these statistics should
be handle by push pub-sub model or a pull pub-sub model.
Thresholds for data models may be passed by the event portion of
the push/pull pub-sub model. The pub-sub model will allow the
I2RS client-I2RS Agent to meter the amount of data flow these
statistics carry. The push portion of the pub-sub model is
supported by <xref target="I-D.ietf-netconf-yang-push"></xref>, but
the pull portion of the pub-sub model is not defined.
</t>
<t>Alternatively I2RS can use the the IPFIX protocol (<xref target="RFC7011"></xref>)
as a component protocol. I2RS processes can support an IPFIX exporting
process sendinging dta to a node to a node on a collector process.
The IPFIX templates can be configured as ephemeral state or
configuration state. The IPFIX data flows may run over
SCTP, UDP, or TCP utilizing the congestion services at each time.
The IPFIX connections assumes that: a) congestion is an temporary
anomaly, b) dropping data during a congestion is reported, and
c) for some exporiting process it is acceptable to have
drop data in a reliable protocol. The I2RS protocol must
support the establishment of an IPFIX connection.
</t>
<t>Traffic monitoring can occur in a network under DDoS with high
levels of congestion and loss the use of these protocols which
rely on transport-level retransmission may not be as resilient
as needed for network security functions (NSF). These are considered
in section 5 on operations during network outages or congestoin.
</t>
<t>
The Flow Filtering data models with policy rules (BGP Flow Specification,
I2RS Filter-Based RIB, and n-tuple policy routing RIB) often track
how often these policies are match. These statistics can also be pushed/pulled
in a publication/subscription with yang data-model defined format or an
IPFIX exporting process format. Similarly IPPM statistics or SFLOW data,
be sent via publication/subscription service in
yang data model format or in a IPFIX Template or
as XML or JSON representation of a yang data model.
These additional sources do not change the requirements
for the push publication/subscription or expand the
</t>
<t>Summary: The pub-sub model push or pull may have to support additional formats
(E.g. SFLOW, IPFIX) as well as yang data models.
</t>
</section>
<section title="I2RS Data Flow Requirements">
<t>(DF-REQ-05): Support of traffic statistics for filter-based policies
(BGP-FS, I2RS FB-RIB, policy routing), IPPM, SFLOW, and others in yang data model
format or IPFIX tempalte formats over XML or JSON.
</t>
</section>
</section>
<section title="CDNI Use case requirements">
<t>The CDNI use case has the two requirements for an I2RS
interface:
<list>
<t>interface that allows redirection of
cDNI request via the Alto protocol or query of
ALTO information (CDNI-REQ-01s, CNDI-REQ-02,</t>
<t>interface using I2RS Client-Agent that
allows I2RS agent to redirect content request message
to a downstream agent </t>
<t>CDNI meta data sent with CNDI metadata to determine
how CNDI can deliver or reroute CDNI content (CNDI-REQ-1b,
CDNI-REQ-03.</t>
</list>
</t>
<section title="CNDI Requirements for data flow">
<t>
<list>
<t>Alto protocol objects which include
<list style="symbols">
<t>map-object with request resoponse data that includes:</t>
<t>InfoResourceDirectory,</t>
<t>InfoResourceNetworkMap, </t>
<t> InfoResourceCostMap, </t>
<t>InfoResourceEndpointProperties, and </t>
<t>InfoResourceEndpointCostMap. </t>
</list>
</t>
<t>ALTO transport (http) and JSON encodings (GET, POST, PUT)
for ALTO codes </t>
<t>Receive ALTO Error data with error codes (Code = application/alto-error+json),
or overload (HTTP 503 ("Service Unavailable")), or temporary redirect
(HTTP 307 ("Temporary Redirect")) and re-interpret as Events or responses
on CDNI interface.
</t>
<t>Transfer ALTO Resource directory information to CDNI meta data
( Jason encoded data with: "application/alto-directory+json") </t>
</list>
</t>
</section>
<section title="I2RS Data Flow Requirements">
<t>DF-REQ-06: Support carry ALTO protocol objects using ALTO protocol
transport (http) with JSON encodings (GET, POST-PUT) for ALTO codes handling
ALTO data errors, overload codes, and temporary redirects plus
ALTO resource directory requests. ALTO error codes, overload codes,
temporary redirets, and diretory requetss should be transformed to
I2RS events.
</t>
</section>
</section>
<section title="Action sequences in Data Models ">
<t>Several of the I2RS requirements from the use cases
require a sequence of events with the following actions:
<list style="numbers">
<t>query data in protocol independent model (topology, RIB, Filter-RIB),
or protocol),
</t>
<t>start calculation (or re-calculation) in protocol function,
</t>
<t>Report results, </t>
<t>install topology or RIB calculated,</t>
<t>check results, </t>
<t>recycle.</t>
</list>
</t>
<t> The actions included looking for overlapping BGP routes,
IGP LFA calculation, ECMP load balancing traffic, optimizing
paths via MPLS-TE, CCNE re-optimization, and virtual
topology creation.
</t>
<t>An alternate pattern within the requirements is if the
topology is calculated off-line, and uploaded.
</t>
<t>These action patterns may involve an interaction of
the I2RS action sequences with existing OAM functions
in the routing system.
</t>
<t>NETCONF/RESTCONF have the concepts of an "rpc" for a configuration
enabled action, but these action sequences should have the abilty to have the
following characteristics:
<list style="symbols">
<t>the ability to request a reservation of resources for this
effort so the action sequence does not start unless
there is enough calculation or response bandwidth in a node, </t>
<t>the abilty ability to have validation on off-line calculated
data so this critical data does not have errors </t>
<t>the ability to "prioritize" notification or reports
ahead of other I2RS data streams to allow process to work.</t>
</list>
</t>
<section title="I2RS Data Flow Requirement">
<t>
I2RS-DF-REQ-07: I2RS should be able to support an action
which allocates internal resources for the I2RS agent
(memory, processing time, interrupts) and outbound data flow
bandwidth. It is expected that an action would be
included in a data model in an "rpc"-like format in yang.
</t>
<t>DF-REQ-08: The I2RS should be able to support an action that interacts with
routing OAM functions. </t>
</section>
</section>
<section title="Operation during network outages or attacks ">
<t>The router needs dynamic management during periods of outage
or periods of security attack.
</t>
<section title="Periods of Network Outage">
<t>During periods of
outage, the I2RS protocol must operate when data bandwidth
is reduced and network connectivity fluctuates.
I2RS agents must be able to adjust operation of
event notifications, logging, or data traffic during this period.
Data Models and I2RS agent configuration must allow operator-applied
policy to prioritize data during this period. The I2RS Agent
should be able to signal the I2RS Client that such a time period is occuring.
</t>
</section>
<section title="I2RS used for Security functions in routers (I2NSF requirements)">
<t>For protection, most network devices have basic firewalls and flow filters.
Some network routing devices have more advanced security.
An interface to Network Security Function (I2NSF)
is a new interface being defined by manage network security devices
using the same higher-level protocol concept as I2RS
where the I2NSF will be comprised of component protocols
(see <xref target="I-D.ietf-i2nsf-problem-and-use-cases"></xref> for
a description of the problem space and use cases for I2NSF),
The intent of the I2NSF interface is to utilize the I2RS protocol
as a component protocol which interfaces
routing and forwarding functions in the security devices
or in routing/forwarding devices in the network which include
basic security devices (E.g. NAT firewalls or
traffic filtesr in routing devices). The I2NSF function supports
configuration of security devices as well as providing notification
of events, logging of security action, and reporting of statistics
and traffic flow measurement. The I2RS data functions described above
will support sending information most network conditions
except during the high loss and heavy congestion due DDoS or other
security incidents. This section provides a short review of these
type of streams of data and places to look-up additional input.
</t>
<t>The common need for I2RS (and I2NSF) to support
these functions via an application layer services with
to support data flow resilence, "chunking" of data
appropriate sizes for congestion, mesage integrity and replay protection
during periods of DDoS and bursty congestion due to security attacks.
A common "session" function as an I2RS data flow can provide
these functions.
</t>
<section title="DOTS - DDoS Open Threat Signaling">
<t>Sending information to signal information about DDoS
threats occurs during periods where the DDoS is congesting the
network or causing large packet losses. Management systems
need to configure network security functions (NSFs) on
routers and on security devices to with new filtering policy,
pull events and logs from NSF, and receive traffic monitoring
data and logs regarding network security incidents.
</t>
<t>
These features for routing devices are handled by the existing
I2RS data flow requirements except it does not support the
network resilience in the presence of loss or congestion.
</t>
<t>
The DOTS requirements for messages from devices
with security functions (such as firewalls in routing devices)
are specified in: <xref target="I-D.ietf-dots-requirements"></xref>.
The following are DOTS descriptions of the resiliency needed
by the data
<list style="symbols">
<t>Resilence (DOTS-G-003) in the face of severally constrained
severely constrained network conditions imposed by the attack
traffic. The protocol SHOULD be resilient, that is, continue
operating despite message loss and out-of-order or redundant
signal delivery.
</t>
<t>Small message sizes (DOTS-G-005) to prevent fragmentation so that
all of message goes through in attack, </t>
<t>Message integrity (G-006) and Message level replay protection (G-007)
must exist for data streams even during periods of attack,
</t>
<t>Session-level Health monitoring (aka Heart beats) during
attack (DOTS-OP-003) </t>
<t>Abiilty to request/stop mitigation quickly (DOTS-OP-005)</t>
</list>
</t>
</section>
<section title="MILE - Managed Incident Lightweight Exchange ">
<t>The MILE related protocols (<xref target="RFC5070"></xref> and
<xref target="I-D.ietf-mile-rfc5070-bis"></xref> provide data formats
for reporting network security incidents during time periods of network attack.
Similar to DOTS, the data passed by these protocols
requires resilience, message integrity, message level replay protection,
and session-level health monitoring. During attacks, the use
of small message sizes is necessary.
</t>
</section>
</section>
<section title="I2RS Data Flow Requirements ">
<t>I2RS-DF-09:I2RS Agent must be able signals that it will be using
different protocol with different constraints (security,
priority of data, or transport) or different constraints on the
existing protocol (smaller message sizes, different priorities on
data carried, or different security levels).
</t>
<t>I2RS-DF-10: I2RS Agent-I2RS Client protocol must allow for a common
session level function that supports data flow resilence, "chunking" of data
appropriate sizes for congestion, mesage integrity and replay protection
so that during periods of DDoS and bursty congestion due to security attacks.
A common "session" function will support an application layer "session"
function that serves multiple transports.
</t>
<t>DF-REQ10: The I2RS protocol must allow for security that exist at the
applications' "session" level that spans multiple transports. </t>
<t>DF-REQ-12: Support of the ability to send/receive IPFIX Templates, and
information using IPFIX template formats but use another protocol to
transport the data that can handle congestion and DDoS attacks.
congestion-friendly
</t>
</section>
</section>
</section>
<section title="changes to YANG">
<t>DF-REQ-13: Yang MUST have a way to
indicate in a data model has actions which allow:
different transports, different resource constraints, or different
security.
</t>
<t>DF-REQ-14: Yang MUST have a way to indicate
a data model has different levels of checking where:
lowest level is message form only, medium level checks
message format plus data syntax, and highest level uses the
message format, data syntax and referential check netconf configuration does.
The default level for I2RS is message format plus data syntax.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>There are no IANA requirements for this document.</t>
</section>
<section title="Security Considerations">
<t>The security requirements for the I2RS protocol are
covered in <xref target="I-D.ietf-i2rs-protocol-security-requirements"></xref> document.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
The following people have aided in the discuss
<list style="symbols">
<t>Russ White,and </t>
<t>Robert Moskowitz.</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&RFC2330;
&RFC3176;
&RFC5575;
&RFC5070;
&RFC6020;
&RFC6241;
&RFC6536;
&RFC7011;
&RFC7312;
&I-D.ietf-i2rs-architecture;
&I-D.ietf-i2rs-rib-info-model;
&I-D.ietf-i2rs-traceability;
&I-D.ietf-i2rs-pub-sub-requirements;
&I-D.ietf-i2rs-protocol-security-requirements;
&I-D.ietf-i2rs-ephemeral-state;
&I-D.ietf-i2rs-usecase-reqs-summary;
&I-D.ietf-netconf-yang-push;
&I-D.ietf-netconf-restconf;
&I-D.ietf-dots-requirements;
&I-D.ietf-i2nsf-problem-and-use-cases;
&I-D.ietf-mile-rfc5070-bis;
&I-D.kini-i2rs-fb-rib-info-model;
&I-D.hares-i2rs-fb-rib-data-model;
&I-D.wu-idr-flowspec-yang-cfg;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 04:06:32 |