rfc8783xml2.original.xml   rfc8783.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?> <rfc
<?rfc tocompact="yes"?> xmlns:xi="http://www.w3.org/2001/XInclude"
<?rfc tocdepth="3"?> category="std"
<?rfc tocindent="yes"?> consensus="true"
<?rfc symrefs="yes"?> docName="draft-ietf-dots-data-channel-31"
<?rfc sortrefs="yes"?> number="8783"
<?rfc comments="yes"?> ipr="trust200902"
<?rfc inline="yes"?> obsoletes=""
<?rfc compact="yes"?> updates=""
<?rfc subcompact="no"?> submissionType="IETF"
<rfc category="std" docName="draft-ietf-dots-data-channel-31" xml:lang="en"
ipr="trust200902"> tocInclude="true"
tocDepth="3"
symRefs="true"
sortRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 2.40.0 -->
<front> <front>
<title abbrev="DOTS Data Channel Protocol">Distributed Denial-of-Service <title abbrev="DOTS Data Channel Protocol">Distributed Denial-of-Service
Open Threat Signaling (DOTS) Data Channel Specification</title> Open Threat Signaling (DOTS) Data Channel Specification</title>
<seriesInfo name="RFC" value="8783"/>
<author fullname="Mohamed Boucadair" initials="M." role="editor" <author fullname="Mohamed Boucadair" initials="M." role="editor" surname="Bo
surname="Boucadair"> ucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street></street>
<city>Rennes</city> <city>Rennes</city>
<region></region>
<code>35000</code> <code>35000</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Tirumaleswar Reddy.K" initials="T." role="editor" surname=
<author fullname="Tirumaleswar Reddy" initials="T." role="editor" "Reddy.K">
surname="Reddy">
<organization abbrev="McAfee">McAfee, Inc.</organization> <organization abbrev="McAfee">McAfee, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Embassy Golf Link Business Park</street> <street>Embassy Golf Link Business Park</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
<code>560071</code> <code>560071</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>kondtir@gmail.com</email> <email>kondtir@gmail.com</email>
</address> </address>
</author> </author>
<date month="May" year="2020"/>
<date day="22" month="July" year="2019" />
<workgroup>DOTS</workgroup> <workgroup>DOTS</workgroup>
<keyword>Automation</keyword> <keyword>Automation</keyword>
<keyword>Security</keyword> <keyword>Security</keyword>
<keyword>Mitigation</keyword> <keyword>Mitigation</keyword>
<keyword>Scrubbing</keyword> <keyword>Scrubbing</keyword>
<keyword>Anti-DDoS</keyword> <keyword>Anti-DDoS</keyword>
<keyword>Mitigator</keyword> <keyword>Mitigator</keyword>
<keyword>Security Center</keyword> <keyword>Security Center</keyword>
<keyword>Filtering</keyword> <keyword>Filtering</keyword>
<keyword>Resilience</keyword> <keyword>Resilience</keyword>
<keyword>RESTCONF</keyword> <keyword>RESTCONF</keyword>
<abstract> <abstract>
<t>The document specifies a Distributed Denial-of-Service Open Threat <t>The document specifies a Distributed Denial-of-Service Open Threat
Signaling (DOTS) data channel used for bulk exchange of data that cannot Signaling (DOTS) data channel used for bulk exchange of data that cannot
easily or appropriately communicated through the DOTS signal channel easily or appropriately communicated through the DOTS signal channel
under attack conditions.</t> under attack conditions.</t>
<t>This is a companion document to "Distributed Denial-of-Service Open Thr
<t>This is a companion document to the DOTS signal channel eat Signaling (DOTS) Signal Channel Specification" (RFC 8782).</t>
specification.</t>
</abstract> </abstract>
<note title="Editorial Note (To be removed by RFC Editor)">
<t>Please update these statements within the document with the RFC
number to be assigned to this document:<list style="symbols">
<t>"This version of this YANG module is part of RFC XXXX;"</t>
<t>"RFC XXXX: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Data Channel Specification";</t>
<t>reference: RFC XXXX</t>
</list></t>
<t>Please update the "revision" date of the YANG module.</t>
</note>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>A distributed denial-of-service (DDoS) attack is an attempt to make <t>A distributed denial-of-service (DDoS) attack is an attempt to make
machines or network resources unavailable to their intended users. In machines or network resources unavailable to their intended users. In
most cases, sufficient scale can be achieved by compromising enough most cases, sufficient scale can be achieved by compromising enough
end-hosts and using those infected hosts to perpetrate and amplify the end hosts and using those infected hosts to perpetrate and amplify the
attack. The victim of such attack can be an application server, a attack. The victim of such an attack can be an application server, a
router, a firewall, an entire network, etc.</t> router, a firewall, an entire network, etc.</t>
<t>As discussed in <xref target="RFC8612" format="default"/>, the lack of
<t>As discussed in <xref target="RFC8612"></xref>, the lack of a common a common
method to coordinate a real-time response among involved actors and method to coordinate a real-time response among involved actors and
network domains inhibits the speed and effectiveness of DDoS attack network domains inhibits the speed and effectiveness of DDoS attack
mitigation. From that standpoint, DDoS Open Threat Signaling (DOTS) mitigation. From that standpoint, DDoS Open Threat Signaling (DOTS)
defines an architecture that allows a DOTS client to send requests to a defines an architecture that allows a DOTS client to send requests to a
DOTS server for DDoS attack mitigation <xref DOTS server for DDoS attack mitigation
target="I-D.ietf-dots-architecture"></xref>. The DOTS approach is thus <xref target="I-D.ietf-dots-architecture" format="default"/>. The DOTS app
roach is thus
meant to minimize the impact of DDoS attacks, thereby contributing to meant to minimize the impact of DDoS attacks, thereby contributing to
the enforcement of more efficient defensive if not proactive security the enforcement of more efficient defensive if not proactive security
strategies. To that aim, DOTS defines two channels: the signal and the strategies. To that aim, DOTS defines two channels: the signal channel and
data channels (<xref target="channels"></xref>). <figure align="center" the
anchor="channels" title="DOTS Channels"> data channel (<xref target="channels" format="default"/>). </t>
<artwork><![CDATA[+---------------+ +- <figure anchor="channels">
--------------+ <name>DOTS Channels</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---------------+ +---------------+
| | <------- Signal Channel ------> | | | | <------- Signal Channel ------> | |
| DOTS Client | | DOTS Server | | DOTS Client | | DOTS Server |
| | <======= Data Channel ======> | | | | <======= Data Channel ======> | |
+---------------+ +---------------+]]></artwork> +---------------+ +---------------+
</figure></t> ]]></artwork>
</figure>
<t>The DOTS signal channel is used to carry information about a device <t>The DOTS signal channel is used to carry information about a device
or a network (or a part thereof) that is under a DDoS attack. Such or a network (or a part thereof) that is under a DDoS attack. Such
information is sent by a DOTS client to an upstream DOTS server so that information is sent by a DOTS client to an upstream DOTS server so that
appropriate mitigation actions are undertaken on traffic deemed appropriate mitigation actions are undertaken on traffic deemed
suspicious. The DOTS signal channel is further elaborated in <xref suspicious. The DOTS signal channel is further elaborated in <xref target=
target="I-D.ietf-dots-signal-channel"></xref>.</t> "RFC8782" format="default"/>.</t>
<t>The DOTS data channel is used for infrequent bulk data
<t>As for the DOTS data channel, it is used for infrequent bulk data
exchange between DOTS agents to significantly improve the coordination exchange between DOTS agents to significantly improve the coordination
of all the parties involved in the response to the attack. Section 2 of of all the parties involved in the response to the attack.
<xref target="I-D.ietf-dots-architecture"></xref> mentions that the DOTS <xref target="I-D.ietf-dots-architecture" section="2" sectionFormat="of" f
ormat="default"/> mentions that the DOTS
data channel is used to perform the following tasks:</t> data channel is used to perform the following tasks:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Creating aliases for resources for which mitigation may be <t>Creation of aliases for resources for which mitigation may be
requested.<vspace blankLines="1" />A DOTS client may submit to its requested.</t>
DOTS server a collection of prefixes which it would like to refer to <t>A DOTS client may submit to its
DOTS server a collection of prefixes to which it would like to refer
by an alias when requesting mitigation. The DOTS server can respond by an alias when requesting mitigation. The DOTS server can respond
to this request with either a success or failure response (see to this request with either a success or failure response (see
Section 2 in <xref <xref target="I-D.ietf-dots-architecture" section="2" sectionFormat="o
target="I-D.ietf-dots-architecture"></xref>).<vspace f" format="default"/>).</t>
blankLines="1" />Refer to <xref target="identifier"></xref> for more <t>Refer to <xref target="identifier" format="default"/> for more
details.</t> details.</t>
</li>
<li>
<t>Policy management, which enables a DOTS client to request the <t>Policy management, which enables a DOTS client to request the
installation or withdrawal of traffic filters, dropping or installation or withdrawal of traffic filters, the dropping or
rate-limiting unwanted traffic, and permitting accept-listed rate-limiting of unwanted traffic, and the permitting of accept-listed
traffic. A DOTS client is entitled to instruct filtering rules only traffic. A DOTS client is entitled to instruct filtering rules only
on IP resources that belong to its domain.<vspace on IP resources that belong to its domain.</t>
blankLines="1" />Sample use cases for populating drop- or <t>Sample use cases for populating drop- or
accept-list filtering rules are detailed hereafter: <list accept-list filtering rules are detailed hereafter: </t>
style="symbols"> <ul spacing="normal">
<li>
<t>If a network resource (DOTS client) is informed about a <t>If a network resource (DOTS client) is informed about a
potential DDoS attack from a set of IP addresses, the DOTS potential DDoS attack from a set of IP addresses, the DOTS
client informs its servicing DOTS gateway of all suspect IP client informs its servicing DOTS gateway of all suspect IP
addresses that need to be drop-listed for further investigation. addresses that need to be drop-listed for further investigation.
The DOTS client could also specify a list of protocols and port The DOTS client could also specify a list of protocols and port
numbers in the drop-list rule. <vspace blankLines="1" />The DOTS numbers in the drop-list rule. </t>
<t>The DOTS
gateway then propagates the drop-listed IP addresses to a DOTS gateway then propagates the drop-listed IP addresses to a DOTS
server which will undertake appropriate actions so that traffic server, which will undertake appropriate actions so that traffic
originated by these IP addresses to the target network originated by these IP addresses to the target network
(specified by the DOTS client) is blocked.</t> (specified by the DOTS client) is blocked.</t>
</li>
<t>A network, that has partner sites from which only legitimate <li>
traffic arrives, may want to ensure that the traffic from these <t>A network that has partner sites from which only legitimate
traffic arrives may want to ensure that the traffic from these
sites is not subjected to DDoS attack mitigation. The DOTS sites is not subjected to DDoS attack mitigation. The DOTS
client uses the DOTS data channel to convey the accept-listed IP client uses the DOTS data channel to convey the accept-listed IP
prefixes of the partner sites to its DOTS server. <vspace prefixes of the partner sites to its DOTS server. </t>
blankLines="1" />The DOTS server uses this information to <t>The DOTS server uses this information to
accept-list flows originated by such IP prefixes and which reach accept-list flows originated by such IP prefixes and which reach
the network.</t> the network.</t>
</list>Refer to <xref target="filter"></xref> for more </li>
</ul>
<t>Refer to <xref target="filter" format="default"/> for more
details.</t> details.</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="notation" numbered="true" toc="default">
<section anchor="notation" title="Terminology"> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in <xref IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and only NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
when, they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<t>The reader should be familiar with the terms defined in <xref be interpreted as
target="RFC8612"></xref>.</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
<t>The terminology for describing YANG modules is defined in <xref </t>
target="RFC7950"></xref>. The meaning of the symbols in the tree <t>The reader should be familiar with the terms defined in <xref target="R
diagrams is defined in <xref target="RFC8340"></xref>.</t> FC8612" format="default"/>.</t>
<t>The terminology for describing YANG modules is defined in
<xref target="RFC7950" format="default"/>. The meaning of the symbols in t
he tree
diagrams is defined in <xref target="RFC8340" format="default"/>.</t>
<t>This document generalizes the notion of Access Control List (ACL) so <t>This document generalizes the notion of Access Control List (ACL) so
that it is not device-specific <xref target="RFC8519"></xref>. As such, that it is not device specific <xref target="RFC8519" format="default"/>. As such,
this document defines an ACL as an ordered set of rules that is used to this document defines an ACL as an ordered set of rules that is used to
filter traffic. Each rule is represented by an Access Control Entry filter traffic. Each rule is represented by an Access Control Entry
(ACE). ACLs communicated via the DOTS data channel are not bound to a (ACE). ACLs communicated via the DOTS data channel are not bound to a
device interface.</t> device interface.</t>
<t>For the sake of simplicity, the examples in this document use
<t>For the sake of simplicity, all of the examples in this document use "/restconf" as the discovered RESTCONF API root path. Within the examples,
"/restconf" as the discovered RESTCONF API root path. Many protocol many protocol
header lines and message-body text within examples throughout the header lines and message-body text are split into multiple lines for displ
document are split into multiple lines for display purposes only. When a ay purposes only. When a
line ends with backslash ('\') as the last character, the line is line ends with backslash ('\') as the last character, the line is
wrapped for display purposes. It is to be considered to be joined to the wrapped for display purposes. It is to be considered to be joined to the
next line by deleting the backslash, the following line break, and the next line by deleting the backslash, the following line break, and the
leading whitespace of the next line.</t> leading whitespace of the next line.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="DOTS Data Channel"> <name>DOTS Data Channel</name>
<section title="Design Overview"> <section numbered="true" toc="default">
<name>Design Overview</name>
<t>Unlike the DOTS signal channel, which must remain operational even <t>Unlike the DOTS signal channel, which must remain operational even
when confronted with signal degradation due to packets loss, the DOTS when confronted with signal degradation due to packet loss, the DOTS
data channel is not expected to be fully operational at all times, data channel is not expected to be fully operational at all times,
especially when a DDoS attack is underway. The requirements for a DOTS especially when a DDoS attack is underway. The requirements for a DOTS
data channel protocol are documented in <xref data channel protocol are documented in <xref target="RFC8612" format="d
target="RFC8612"></xref>.</t> efault"/>.</t>
<t>This specification does not require an order of DOTS signal and <t>This specification does not require an order of DOTS signal and
data channel creations nor mandates a time interval between them. data channel creation nor does it mandate a time interval between them.
These considerations are implementation- and deployment-specific.</t> These considerations are implementation and deployment specific.</t>
<t>As the primary function of the data channel is data exchange, a <t>As the primary function of the data channel is data exchange, a
reliable transport mode is required in order for DOTS agents to detect reliable transport mode is required in order for DOTS agents to detect
data delivery success or failure. This document uses RESTCONF <xref data delivery success or failure. This document uses RESTCONF <xref targ
target="RFC8040"></xref> over TLS over TCP as the DOTS data channel et="RFC8040" format="default"/> over TLS over TCP as the DOTS data channel
protocol. The abstract layering of DOTS data channel is shown in <xref protocol. The abstract layering of the DOTS data channel is shown in <xr
target="fig_dots2"></xref>.</t> ef target="fig_dots2" format="default"/>.</t>
<figure anchor="fig_dots2">
<t><figure anchor="fig_dots2" <name>Abstract Layering of DOTS Data Channel</name>
title="Abstract Layering of DOTS Data Channel"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[+-------------------+ +-------------------+
| DOTS Data Channel | | DOTS Data Channel |
+-------------------+ +-------------------+
| RESTCONF | | RESTCONF |
+-------------------+ +-------------------+
| TLS | | TLS |
+-------------------+ +-------------------+
| TCP | | TCP |
+-------------------+ +-------------------+
| IP | | IP |
+-------------------+ +-------------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The HTTP POST, PUT, PATCH, and DELETE methods are used to edit data <t>The HTTP POST, PUT, PATCH, and DELETE methods are used to edit data
resources represented by DOTS data channel YANG modules. These basic resources represented by DOTS data channel YANG modules. These basic
edit operations allow the DOTS data channel running configuration to edit operations allow a DOTS client to alter the running configuration
be altered by a DOTS client. Rules for generating and processing of the DOTS data channel. Rules for generating and processing
RESTCONF methods are defined in Section 4 of <xref RESTCONF methods are defined in <xref target="RFC8040" section="4" secti
target="RFC8040"></xref>.</t> onFormat="of" format="default"/>.</t>
<t>DOTS data channel configuration information as well as state <t>DOTS data channel configuration information as well as state
information can be retrieved with the GET method. An HTTP status-line information can be retrieved with the GET method. An HTTP status-line
is returned for each request to report success or failure for RESTCONF is returned for each request to report success or failure for RESTCONF
operations (Section 5.4 of <xref target="RFC8040"></xref>). The operations (<xref target="RFC8040" section="5.4" sectionFormat="of" form
"error-tag" provides more information about encountered errors at="default"/>). The
(Section 7 of <xref target="RFC8040"></xref>).</t> error-tag provides more information about encountered errors
(<xref target="RFC8040" section="7" sectionFormat="of" format="default"/
>).</t>
<t>DOTS clients perform the root resource discovery procedure <t>DOTS clients perform the root resource discovery procedure
discussed in Section 3.1 of <xref target="RFC8040"></xref> to discussed in <xref target="RFC8040" section="3.1" sectionFormat="of" for mat="default"/> to
determine the root of the RESTCONF API. After discovering the RESTCONF determine the root of the RESTCONF API. After discovering the RESTCONF
API root, a DOTS client uses this value as the initial part of the API root, a DOTS client uses this value as the initial part of the
path in the request URI in any subsequent request to the DOTS server. path in the request URI in any subsequent request to the DOTS server.
The DOTS server may support the retrieval of the YANG modules it The DOTS server may support the retrieval of the YANG modules it
supports (Section 3.7 in <xref target="RFC8040"></xref>). For example, supports (<xref target="RFC8040" section="3.7" sectionFormat="of" format ="default"/>). For example,
a DOTS client may use RESTCONF to retrieve the vendor-specific YANG a DOTS client may use RESTCONF to retrieve the vendor-specific YANG
modules supported by its DOTS server.</t> modules supported by its DOTS server.</t>
<t>JavaScript Object Notation (JSON) <xref target="RFC8259" format="defa
<t>JavaScript Object Notation (JSON) <xref target="RFC8259"> </xref> ult"> </xref>
payloads are used to propagate the DOTS data-channel-specific payload payloads are used to propagate the DOTS data-channel-specific payload
messages that carry request parameters and response information, such messages that carry request parameters and response information, such
as errors. This specification uses the encoding rules defined in <xref as errors. This specification uses the encoding rules defined in
target="RFC7951"></xref> for representing DOTS data channel <xref target="RFC7951" format="default"/> for representing DOTS data cha
configuration data using YANG (<xref target="YANG"></xref>) as JSON nnel
configuration data using YANG (<xref target="YANG" format="default"/>) a
s JSON
text.</t> text.</t>
<t>A DOTS client registers itself with its DOTS server(s) in order to
<t>A DOTS client registers itself to its DOTS server(s) in order to set up DOTS data channel-related configuration data and to receive state
set up DOTS data channel-related configuration data and receive state data (i.e., non-configuration data) from the DOTS server(s) (<xref targe
data (i.e., non-configuration data) from the DOTS server(s) (<xref t="registering" format="default"/>).
target="registering"></xref>). Mutual authentication considerations Mutual authentication considerations are specified in
are specified in Section 8 of <xref <xref target="RFC8782" section="8" sectionFormat="of" format="default"/>
target="I-D.ietf-dots-signal-channel"></xref>. The coupling of signal .
and data channels is discussed in Section 4.4.1 of <xref The coupling of signal and data channels is discussed in
target="I-D.ietf-dots-signal-channel"></xref>.</t> <xref target="RFC8782" section="4.4.1" sectionFormat="of" format="defaul
t"/>.</t>
<t>A DOTS client can either maintain a persistent connection or <t>A DOTS client can either maintain a persistent connection or initiate
periodic connections with its DOTS server(s). If the DOTS client needs periodic connections with its DOTS server(s). If the DOTS client needs
to frequently update the drop-list or accept-list filtering rules or to frequently update the drop-list or accept-list filtering rules or
aliases, it maintains a persistent connection with the DOTS server. aliases, it maintains a persistent connection with the DOTS server.
For example, CAPTCHA and cryptographic puzzles can be used by the For example, CAPTCHA and cryptographic puzzles can be used by the
mitigation service in the DOTS client domain to determine whether the mitigation service in the DOTS client domain to determine
IP address is used for legitimate purpose or not, and the DOTS client whether or not the
IP address is used for legitimate purpose, and the DOTS client
can frequently update the drop-list filtering rules. A persistent can frequently update the drop-list filtering rules. A persistent
connection is also useful if the DOTS client subscribes to event connection is also useful if the DOTS client subscribes to event
notifications (Section 6.3 of <xref target="RFC8040"></xref>). notifications (<xref target="RFC8040" section="6.3" sectionFormat="of" f ormat="default"/>).
Additional considerations related to RESTCONF connection management Additional considerations related to RESTCONF connection management
(including, configuring the connection type or the reconnect strategy) (including, configuring the connection type or the reconnect strategy)
can be found in <xref can be found in <xref target="I-D.ietf-netconf-restconf-client-server" f
target="I-D.ietf-netconf-restconf-client-server"></xref>.</t> ormat="default"/>.</t>
<t>A single DOTS data channel between DOTS agents can be used to <t>A single DOTS data channel between DOTS agents can be used to
exchange multiple requests and multiple responses. To reduce DOTS exchange multiple requests and multiple responses. To reduce DOTS
client and DOTS server workload, DOTS clients SHOULD re-use the same client and DOTS server workload, DOTS clients <bcp14>SHOULD</bcp14> reus e the same
TLS session. While the communication to the DOTS server is quiescent, TLS session. While the communication to the DOTS server is quiescent,
the DOTS client MAY probe the server to ensure it has maintained the DOTS client <bcp14>MAY</bcp14> probe the server to ensure it has mai ntained
cryptographic state. Such probes can also keep alive firewall and/or cryptographic state. Such probes can also keep alive firewall and/or
NAT bindings. A TLS heartbeat <xref target="RFC6520"></xref> verifies NAT bindings. A TLS heartbeat <xref target="RFC6520" format="default"/> verifies
that the DOTS server still has TLS state by returning a TLS that the DOTS server still has TLS state by returning a TLS
message.</t> message.</t>
<t>A DOTS server may detect conflicting filtering requests from <t>A DOTS server may detect conflicting filtering requests from
distinct DOTS clients which belong to the same domain. For example, a distinct DOTS clients that belong to the same domain. For example, a
DOTS client could request to drop-list a prefix by specifying the DOTS client could request to drop-list a prefix by specifying the
source prefix, while another DOTS client could request to accept-list source prefix, while another DOTS client could request to accept-list
that same source prefix, but both having the same destination prefix. that same source prefix, but both having the same destination prefix.
DOTS servers SHOULD support a configuration parameter to indicate the DOTS servers <bcp14>SHOULD</bcp14> support a configuration parameter to indicate the
behavior to follow when a conflict is detected (e.g., reject all, behavior to follow when a conflict is detected (e.g., reject all,
reject the new request, notify an administrator for validation). <xref reject the new request, notify an administrator for validation).
target="install"></xref> specifies a default behavior when no <xref target="install" format="default"/> specifies a default behavior w
hen no
instruction is supplied to a DOTS server.</t> instruction is supplied to a DOTS server.</t>
<t>How a DOTS client synchronizes its configuration with the one <t>How a DOTS client synchronizes its configuration with the one
maintained by its DOTS server(s) is implementation-specific. For maintained by its DOTS server(s) is implementation specific. For
example: <list style="symbols"> example: </t>
<t>a DOTS client can systematically send a GET message before <ul spacing="normal">
and/or after a configuration change request.</t> <li>A DOTS client can systematically send a GET message before
and/or after a configuration change request.</li>
<t>a DOTS client can re-establish the disconnected DOTS session <li>A DOTS client can reestablish the disconnected DOTS session
after an attack is mitigated and sends a GET message before a after an attack is mitigated. Then, it sends a GET message before a
configuration change request.</t> configuration change request. </li>
</list></t> </ul>
<t>NAT considerations for the DOTS data channel are similar to those <t>NAT considerations for the DOTS data channel are similar to those
discussed in Section 3 of <xref discussed in <xref target="RFC8782" section="3" sectionFormat="of" forma
target="I-D.ietf-dots-signal-channel"></xref>.</t> t="default"/>.</t>
<t>The translation of filtering rules instantiated on a DOTS server
<t>How filtering rules that are instantiated on a DOTS server are into network configuration actions is out of scope of this
translated into network configurations actions is out of scope of this
specification.</t> specification.</t>
<t>Some of the fields introduced in <xref target="YANG" format="default"
<t>Some of the fields introduced in <xref target="YANG"></xref> are /> are
also discussed in Sections <xref format="counter" also discussed in Sections <xref format="counter" target="registering"/>
target="registering"></xref>, <xref format="counter" ,
target="identifier"></xref>, and <xref format="counter" <xref format="counter" target="identifier"/>, and <xref format="counter"
target="filter"></xref>. These sections are authoritative for these target="filter"/>.
fields.</t> These sections are authoritative for these fields.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="DOTS Server(s) Discovery"> <name>DOTS Server(s) Discovery</name>
<t>This document assumes that DOTS clients are provisioned with a way <t>This document assumes that DOTS clients are provisioned with the
to know how to reach their DOTS server(s), which could occur by a knowledge of how to reach their DOTS server(s), which could occur by a
variety of means (e.g., local configuration, or dynamic means such as variety of means (e.g., local configuration or dynamic means such as
DHCP <xref target="I-D.ietf-dots-server-discovery"></xref>). The DHCP <xref target="I-D.ietf-dots-server-discovery" format="default"/>).
The
specification of such means are out of scope of this document.</t> specification of such means are out of scope of this document.</t>
<t>Likewise, it is out of scope of this document to specify the <t>Likewise, it is out of scope of this document to specify the
behavior to be followed by a DOTS client to send DOTS requests when behavior to be followed by a DOTS client to send DOTS requests when
multiple DOTS servers are provisioned (e.g., contact all DOTS servers, multiple DOTS servers are provisioned (e.g., contact all DOTS servers,
select one DOTS server among the list).</t> select one DOTS server among the list).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="DOTS Gateways"> <name>DOTS Gateways</name>
<t>When a server-domain DOTS gateway is involved in DOTS data channel <t>When a server-domain DOTS gateway is involved in DOTS data channel
exchanges, the same considerations for manipulating the 'cdid' (client exchanges, the same considerations for manipulating the 'cdid' (client
domain identifier) parameter specified in <xref domain identifier) parameter specified in <xref target="RFC8782" format=
target="I-D.ietf-dots-signal-channel"></xref> MUST be followed by DOTS "default"/> <bcp14>MUST</bcp14> be followed by DOTS
agents. As a reminder, 'cdid' is meant to assist the DOTS server to agents. As a reminder, 'cdid' is meant to assist the DOTS server in
enforce some policies (e.g., limit the number of filtering rules per enforcing some policies (e.g., limit the number of filtering rules per
DOTS client or per DOTS client domain). A loop detect mechanism for DOTS client or per DOTS client domain). A loop detection mechanism for
DOTS gateways is specified in <xref target="loops"></xref>.</t> DOTS gateways is specified in <xref target="loops" format="default"/>.</
t>
<t>If a DOTS gateway is involved, the DOTS gateway verifies that the <t>If a DOTS gateway is involved, the DOTS gateway verifies that the
DOTS client is authorized to undertake a data channel action (e.g., DOTS client is authorized to undertake a data channel action (e.g.,
instantiate filtering rules). If the DOTS client is authorized, it instantiate filtering rules). If the DOTS client is authorized, it
propagates the rules to the upstream DOTS server. Likewise, the DOTS propagates the rules to the upstream DOTS server. Likewise, the DOTS
server verifies that the DOTS gateway is authorized to relay data server verifies that the DOTS gateway is authorized to relay data
channel actions. For example, to create or purge filters, a DOTS channel actions. For example, to create or purge filters, a DOTS
client sends its request to its DOTS gateway. The DOTS gateway client sends its request to its DOTS gateway. The DOTS gateway
validates the rules in the request and proxies the requests containing validates the rules in the request and proxies the requests containing
the filtering rules to its DOTS server. When the DOTS gateway receives the filtering rules to its DOTS server. When the DOTS gateway receives
the associated response from the DOTS server, it propagates the the associated response from the DOTS server, it propagates the
response back to the DOTS client.</t> response back to the DOTS client.</t>
</section> </section>
<section anchor="loops" numbered="true" toc="default">
<section anchor="loops" title="Detect and Prevent Infinite Loops"> <name>Detecting and Preventing Infinite Loops</name>
<t>In order to detect and prevent infinite loops, DOTS gateways MUST <t>In order to detect and prevent infinite loops, DOTS gateways <bcp14>M
support the procedure defined in Section 5.7.1 of <xref UST</bcp14>
target="RFC7230"></xref>. In particular, each intermediate DOTS support the procedure defined in <xref target="RFC7230" section="5.7.1"
gateway MUST check that none of its own information (e.g., server sectionFormat="of" format="default"/>.
names, literal IP addresses) is present in the "Via" header field of a In particular, each intermediate DOTS
DOTS message it receives:<list style="symbols"> gateway <bcp14>MUST</bcp14> check that none of its own information (e.g.
<t>If it detects that its own information is present in the "Via" , server
header field, the DOTS gateway MUST NOT forward the DOTS message. names, literal IP addresses) is present in the Via header field of a
Messages that cannot be forwarded because of a loop SHOULD be DOTS message it receives:</t>
logged with a "508 Loop Detected" status-line returned sent back <ul spacing="normal">
<li>
<t>If it detects that its own information is present in the Via
header field, the DOTS gateway <bcp14>MUST NOT</bcp14> forward the D
OTS message.
Messages that cannot be forwarded because of a loop <bcp14>SHOULD</b
cp14> be
logged with a "508 Loop Detected" status-line returned
to the DOTS peer. The structure of the reported error is depicted to the DOTS peer. The structure of the reported error is depicted
in <xref target="looperr"></xref>.<vspace blankLines="1" /><figure in <xref target="looperr" format="default"/>.</t>
align="center" anchor="looperr" title="Loop Detected Error"> <figure anchor="looperr">
<artwork><![CDATA[error-app-tag: loop-detected <name>Loop Detected Error</name>
<sourcecode type=""><![CDATA[
error-app-tag: loop-detected
error-tag: operation-failed error-tag: operation-failed
error-type: transport, application error-type: transport, application
error-info: <via-header> : A copy of the Via header field when error-info: <via-header> : A copy of the Via header field when
the loop was detected. the loop was detected.
Description: An infinite loop has been detected when forwarding Description: An infinite loop has been detected when forwarding
a requests via a proxy. a requests via a proxy.
]]></artwork> ]]></sourcecode>
</figure><vspace blankLines="1" />It is RECOMMENDED that DOTS </figure>
<t>It is <bcp14>RECOMMENDED</bcp14> that DOTS
clients and gateways support methods to alert administrators about clients and gateways support methods to alert administrators about
loop errors so that appropriate actions are undertaken.</t> loop errors so that appropriate actions are undertaken.</t>
</li>
<t>Otherwise, the DOTS agent MUST update or insert the "Via" <li>Otherwise, the DOTS agent <bcp14>MUST</bcp14> update or insert the
header by appending its own information.</t> Via
</list></t> header field by appending its own information.</li>
</ul>
<t>Unless configured otherwise, DOTS gateways at the boundaries of a <t>Unless configured otherwise, DOTS gateways at the boundaries of a
DOTS client domain SHOULD remove the previous "Via" header field DOTS client domain <bcp14>SHOULD</bcp14> remove the previous Via header field
information after checking for a loop before forwarding. This behavior information after checking for a loop before forwarding. This behavior
is required for topology hiding purposes but can also serve to is required for topology hiding purposes but can also serve to
minimize potential conflicts that may arise if overlapping information minimize potential conflicts that may arise if overlapping information
is used in distinct DOTS domains (e.g., private IPv4 addresses, non is used in distinct DOTS domains (e.g., private IPv4 addresses,
globally unique aliases).</t> aliases that are not globally unique).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Stale Entries"> <name>Preventing Stale Entries</name>
<t>In order to avoid stale entries, a lifetime is associated with <t>In order to avoid stale entries, a lifetime is associated with
alias and filtering entries created by DOTS clients. Also, DOTS alias and filtering entries created by DOTS clients. Also, DOTS
servers may track the inactivity timeout of DOTS clients to detect servers may track the inactivity timeout of DOTS clients to detect
stale entries.</t> stale entries.</t>
</section> </section>
</section> </section>
<section anchor="YANG" numbered="true" toc="default">
<name>DOTS Data Channel YANG Module</name>
<section anchor="tree" numbered="true" toc="default">
<section anchor="YANG" title="DOTS Data Channel YANG Module"> <name>Generic Tree Structure</name>
<section anchor="tree" title="Generic Tree Structure"> <t>The DOTS data channel YANG module 'ietf-dots-data-channel' provides
<t>The DOTS data channel YANG module (ietf-dots-data-channel) provides
a method for DOTS clients to manage aliases for resources for which a method for DOTS clients to manage aliases for resources for which
mitigation may be requested. Such aliases may be used in subsequent mitigation may be requested. Such aliases may be used in subsequent
DOTS signal channel exchanges to refer more efficiently to the DOTS signal channel exchanges to refer more efficiently to the
resources under attack.</t> resources under attack.</t>
<t>Note that the full module's tree has been split across several <t>Note that the full module's tree has been split across several
figures to aid the exposition of the various sub-trees.</t> figures to aid the exposition of the various subtrees.</t>
<t>The tree structure for the DOTS alias is depicted in <xref target="ta
<t>The tree structure for the DOTS alias is depicted in <xref lias" format="default"/>.</t>
target="talias"></xref>.</t> <figure anchor="talias">
<name>DOTS Alias Subtree</name>
<t><figure align="center" anchor="talias" title="DOTS Alias Subtree"> <sourcecode type="yangtree"><![CDATA[
<artwork><![CDATA[module: ietf-dots-data-channel module: ietf-dots-data-channel
+--rw dots-data +--rw dots-data
+--rw dots-client* [cuid] +--rw dots-client* [cuid]
| +--rw cuid string | +--rw cuid string
| +--rw cdid? string | +--rw cdid? string
| +--rw aliases | +--rw aliases
| | +--rw alias* [name] | | +--rw alias* [name]
| | +--rw name string | | +--rw name string
| | +--rw target-prefix* inet:ip-prefix | | +--rw target-prefix* inet:ip-prefix
| | +--rw target-port-range* [lower-port] | | +--rw target-port-range* [lower-port]
| | | +--rw lower-port inet:port-number | | | +--rw lower-port inet:port-number
| | | +--rw upper-port? inet:port-number | | | +--rw upper-port? inet:port-number
| | +--rw target-protocol* uint8 | | +--rw target-protocol* uint8
| | +--rw target-fqdn* inet:domain-name | | +--rw target-fqdn* inet:domain-name
| | +--rw target-uri* inet:uri | | +--rw target-uri* inet:uri
| | +--ro pending-lifetime? int32 | | +--ro pending-lifetime? int32
| +--rw acls | +--rw acls
| ... | ...
+--ro capabilities +--ro capabilities
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>Also, the 'ietf-dots-data-channel' YANG module provides a method for
<t>Also, the 'ietf-dots-data-channel' module provides a method for
DOTS clients to manage filtering rules. Examples of filtering DOTS clients to manage filtering rules. Examples of filtering
management in a DOTS context include, but not limited to:</t> management in a DOTS context include, but are not limited to:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Drop-list management, which enables a DOTS client to inform a
<t>Drop-list management, which enables a DOTS client to inform a
DOTS server about sources from which traffic should be DOTS server about sources from which traffic should be
discarded.</t> discarded.</li>
<li>Accept-list management, which enables a DOTS client to inform a
<t>Accept-list management, which enables a DOTS client to inform a
DOTS server about sources from which traffic should always be DOTS server about sources from which traffic should always be
accepted.</t> accepted.</li>
<li>Policy management, which enables a DOTS client to request the
<t>Policy management, which enables a DOTS client to request the installation or withdrawal of traffic filters, the dropping or
installation or withdrawal of traffic filters, dropping or rate-limiting of unwanted traffic, and the allowance of accept-liste
rate-limiting unwanted traffic and permitting accept-listed d
traffic.</t> traffic.</li>
</list></t> </ul>
<t>The tree structure for the DOTS filtering entries is depicted in <t>The tree structure for the DOTS filtering entries is depicted in
<xref target="tacl"></xref>.</t> <xref target="tacl" format="default"/>.</t>
<t>Investigations into the prospect of augmenting <t>Investigations into the prospect of augmenting
'ietf-access-control-list' to meet DOTS requirements concluded that 'ietf-access-control-list' to meet DOTS requirements concluded that
such a design approach did not support many of the DOTS requirements, such a design approach did not support many of the DOTS requirements,
e.g.,</t> for example:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Retrieve a filtering entry (or all entries) created by a DOTS
<t>Retrieve a filtering entry (or all entries) created by a DOTS client.</li>
client.</t> <li>Delete a filtering entry that was instantiated by a DOTS
client.</li>
<t>Delete a filtering entry that was instantiated by a DOTS </ul>
client.</t> <t>Accordingly, new DOTS filtering entries (i.e., ACL) are defined that
</list></t> mimic the structure specified in
<xref target="RFC8519" format="default"/>. Concretely, DOTS agents are a
<t>Accordingly, new DOTS filtering entries (i.e., Access Control List ssumed to
(ACL)) are defined that mimic the structure specified in <xref
target="RFC8519"></xref>. Concretely, DOTS agents are assumed to
manipulate an ordered list of ACLs; each ACL contains a separately manipulate an ordered list of ACLs; each ACL contains a separately
ordered list of Access Control Entries (ACEs). Each ACE has a group of ordered list of ACEs. Each ACE has a group of
match and a group of action criteria.</t> match and a group of action criteria.</t>
<t>Once all of the ACE entries have been iterated though with no match,
<t>Once all the ACE entries have been iterated though with no match, then all of the following ACL's ACE entries are iterated through until
then all the following ACL's ACE entries are iterated through until the first match, at which point the specified action is applied. If
the first match at which point the specified action is applied. If
there is no match during 'idle' time (i.e., no mitigation is active), there is no match during 'idle' time (i.e., no mitigation is active),
then there is no further action to be taken against the packet. If then there is no further action to be taken against the packet. If
there is no match during active mitigation, then the packet will still there is no match during active mitigation, then the packet will still
be scrubbed by the DDoS mitigator.</t> be scrubbed by the DDoS mitigator.</t>
<figure anchor="tacl">
<t><figure align="center" anchor="tacl" title="DOTS ACLs Subtree"> <name>DOTS ACLs Subtree</name>
<artwork><![CDATA[module: ietf-dots-data-channel <sourcecode type="yangtree"><![CDATA[
+--rw dots-data module: ietf-dots-data-channel
+--rw dots-client* [cuid] +--rw dots-data
| +--rw cuid string +--rw dots-client* [cuid]
| +--rw cdid? string | +--rw cuid string
| +--rw aliases | +--rw cdid? string
| | ... | +--rw aliases
| +--rw acls | | ...
| +--rw acl* [name] | +--rw acls
| +--rw name string | +--rw acl* [name]
| +--rw type? ietf-acl:acl-type | +--rw name string
| +--rw activation-type? activation-type | +--rw type? ietf-acl:acl-type
| +--ro pending-lifetime? int32 | +--rw activation-type? activation-type
| +--rw aces | +--ro pending-lifetime? int32
| +--rw ace* [name] | +--rw aces
| +--rw name string | +--rw ace* [name]
| +--rw matches | +--rw name string
| | +--rw (l3)? | +--rw matches
| | | +--:(ipv4) | | +--rw (l3)?
| | | | ... | | | +--:(ipv4)
| | | +--:(ipv6) | | | | ...
| | | ... | | | +--:(ipv6)
| | +--rw (l4)? | | | ...
| | +--:(tcp) | | +--rw (l4)?
| | | ... | | +--:(tcp)
| | +--:(udp) | | | ...
| | | ... | | +--:(udp)
| | +--:(icmp) | | | ...
| | ... | | +--:(icmp)
| +--rw actions | | ...
| | +--rw forwarding identityref | +--rw actions
| | +--rw rate-limit? decimal64 | | +--rw forwarding identityref
| +--ro statistics | | +--rw rate-limit? decimal64
| +--ro matched-packets? yang:counter64 | +--ro statistics
| +--ro matched-octets? yang:counter64 | +--ro matched-packets? yang:counter64
+--ro capabilities | +--ro matched-octets? yang:counter64
... +--ro capabilities
]]></artwork> ...
</figure></t> ]]></sourcecode>
</figure>
<t>Filtering rules instructed by a DOTS client assumes a default <t>Filtering rules instructed by a DOTS client assume a default
direction: the destination is the DOTS client domain.</t> direction: the destination is the DOTS client domain.</t>
<t>DOTS forwarding actions can be 'accept' (i.e., accept matching <t>DOTS forwarding actions can be 'accept' (i.e., accept matching
traffic) or 'drop' (i.e., drop matching traffic without sending any traffic) or 'drop' (i.e., drop matching traffic without sending any
ICMP error message). Accepted traffic can be subject to rate-limiting ICMP error message). Accepted traffic can be subject to rate-limiting
'rate-limit'. Note that 'reject' action (i.e., drop matching traffic 'rate-limit'. Note that 'reject' action (i.e., drop matching traffic
and send an ICMP error message to the source) is not supported in and send an ICMP error message to the source) is not supported in
'ietf-dots-data-channel' because it is not appropriate in the context 'ietf-dots-data-channel' because it is not appropriate in the context
of DDoS mitigation. Generating ICMP messages to notify drops when of DDoS mitigation. Generating ICMP messages to notify of drops when
mitigating a DDoS attack will exacerbate the DDoS attack. Furthermore, mitigating a DDoS attack will exacerbate the DDoS attack. Furthermore,
these ICMP messages will be used by an attacker as an explicit signal these ICMP messages will be used by an attacker as an explicit signal
that the traffic is being blocked.</t> that the traffic is being blocked.</t>
</section> </section>
<section anchor="filf" numbered="true" toc="default">
<section anchor="filf" title="Filtering Fields"> <name>Filtering Fields</name>
<t>The 'ietf-dots-data-channel' module reuses the packet fields module <t>The 'ietf-dots-data-channel' module reuses the packet fields module
'ietf-packet-fields' <xref target="RFC8519"></xref> which defines 'ietf-packet-fields' <xref target="RFC8519" format="default"/>, which de fines
matching on fields in the packet including IPv4, IPv6, and transport matching on fields in the packet including IPv4, IPv6, and transport
layer fields. The 'ietf-dots-data-channel' module can be augmented, layer fields. The 'ietf-dots-data-channel' module can be augmented,
for example, to support additional protocol-specific matching for example, to support additional protocol-specific matching
fields.</t> fields.</t>
<t>This specification defines a new IPv4/IPv6 matching field called <t>This specification defines a new IPv4/IPv6 matching field called
'fragment' to efficiently handle fragment-related filtering rules. 'fragment' to efficiently handle fragment-related filtering rules.
Indeed, <xref target="RFC8519"></xref> does not support such Indeed, <xref target="RFC8519" format="default"/> does not support such
capability for IPv6 but offers a partial support for IPv4 by means of capability for IPv6 but offers a partial support for IPv4 by means of
'flags'. Nevertheless, the use of 'flags' is problematic since it does 'flags'. Nevertheless, the use of 'flags' is problematic since it does
not allow to define a bitmask. For example, setting other bits not not allow a bitmask to be defined. For example, setting other bits not
covered by the 'flags' filtering clause in a packet will allow that covered by the 'flags' filtering clause in a packet will allow that
packet to get through (because it won't match the ACE). Sample packet to get through (because it won't match the ACE).
examples to illustrate how 'fragment' can be used are provided in Examples to illustrate how 'fragment' can be used are provided in
<xref target="frag"></xref>.</t> <xref target="frag" format="default"/>.</t>
<t><xref target="tipv4" format="default"/> shows the IPv4 match subtree.
<t><xref target="tipv4"></xref> shows the IPv4 match subtree.</t> </t>
<figure anchor="tipv4">
<t><figure align="center" anchor="tipv4" <name>DOTS ACLs Subtree (IPv4 Match)</name>
title="DOTS ACLs Subtree (IPv4 Match)"> <sourcecode type="yangtree"><![CDATA[
<artwork><![CDATA[ module: ietf-dots-data-channel module: ietf-dots-data-channel
+--rw dots-data +--rw dots-data
+--rw dots-client* [cuid] +--rw dots-client* [cuid]
| ... | ...
| +--rw acls | +--rw acls
| +--rw acl* [name] | +--rw acl* [name]
| ... | ...
| +--rw aces | +--rw aces
| +--rw ace* [name] | +--rw ace* [name]
| +--rw name string | +--rw name string
| +--rw matches | +--rw matches
| | +--rw (l3)? | | +--rw (l3)?
| | | +--:(ipv4) | | | +--:(ipv4)
| | | | +--rw ipv4 | | | | +--rw ipv4
| | | | +--rw dscp? inet:dscp | | | | +--rw dscp? inet:dscp
| | | | +--rw ecn? uint8 | | | | +--rw ecn? uint8
| | | | +--rw length? uint16 | | | | +--rw length? uint16
| | | | +--rw ttl? uint8 | | | | +--rw ttl? uint8
| | | | +--rw protocol? uint8 | | | | +--rw protocol? uint8
| | | | +--rw ihl? uint8 | | | | +--rw ihl? uint8
| | | | +--rw flags? bits | | | | +--rw flags? bits
| | | | +--rw offset? uint16 | | | | +--rw offset? uint16
| | | | +--rw identification? uint16 | | | | +--rw identification? uint16
| | | | +--rw (destination-network)? | | | | +--rw (destination-network)?
| | | | | +--:(destination-ipv4-network) | | | | | +--:(destination-ipv4-network)
| | | | | +--rw destination-ipv4-network? | | | | | +--rw destination-ipv4-network?
| | | | | inet:ipv4-prefix | | | | | inet:ipv4-prefix
| | | | +--rw (source-network)? | | | | +--rw (source-network)?
| | | | | +--:(source-ipv4-network) | | | | | +--:(source-ipv4-network)
| | | | | +--rw source-ipv4-network? | | | | | +--rw source-ipv4-network?
| | | | | inet:ipv4-prefix | | | | | inet:ipv4-prefix
| | | | +--rw fragment | | | | +--rw fragment
| | | | +--rw operator? operator | | | | +--rw operator? operator
| | | | +--rw type fragment-type | | | | +--rw type fragment-type
| | | +--:(ipv6) | | | +--:(ipv6)
| | | ... | | | ...
| | +--rw (l4)? | | +--rw (l4)?
| | ... | | ...
| +--rw actions | +--rw actions
| | ... | | ...
| +--ro statistics | +--ro statistics
| ... | ...
+--ro capabilities +--ro capabilities
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t><xref target="tipv6" format="default"/> shows the IPv6 match subtree.
<t><xref target="tipv6"></xref> shows the IPv6 match subtree.</t> </t>
<figure anchor="tipv6">
<t><figure align="center" anchor="tipv6" <name>DOTS ACLs Subtree (IPv6 Match)</name>
title="DOTS ACLs Subtree (IPv6 Match)"> <sourcecode type="yangtree"><![CDATA[
<artwork><![CDATA[ module: ietf-dots-data-channel module: ietf-dots-data-channel
+--rw dots-data +--rw dots-data
+--rw dots-client* [cuid] +--rw dots-client* [cuid]
| ... | ...
| +--rw acls | +--rw acls
| +--rw acl* [name] | +--rw acl* [name]
| ... | ...
| +--rw aces | +--rw aces
| +--rw ace* [name] | +--rw ace* [name]
| +--rw name string | +--rw name string
| +--rw matches | +--rw matches
| | +--rw (l3)? | | +--rw (l3)?
| | | +--:(ipv4) | | | +--:(ipv4)
| | | | ... | | | | ...
| | | +--:(ipv6) | | | +--:(ipv6)
| | | +--rw ipv6 | | | +--rw ipv6
| | | +--rw dscp? inet:dscp | | | +--rw dscp? inet:dscp
| | | +--rw ecn? uint8 | | | +--rw ecn? uint8
| | | +--rw length? uint16 | | | +--rw length? uint16
| | | +--rw ttl? uint8 | | | +--rw ttl? uint8
| | | +--rw protocol? uint8 | | | +--rw protocol? uint8
| | | +--rw (destination-network)? | | | +--rw (destination-network)?
| | | | +--:(destination-ipv6-network) | | | | +--:(destination-ipv6-network)
| | | | +--rw destination-ipv6-network? | | | | +--rw destination-ipv6-network?
| | | | inet:ipv6-prefix | | | | inet:ipv6-prefix
| | | +--rw (source-network)? | | | +--rw (source-network)?
| | | | +--:(source-ipv6-network) | | | | +--:(source-ipv6-network)
| | | | +--rw source-ipv6-network? | | | | +--rw source-ipv6-network?
| | | | inet:ipv6-prefix | | | | inet:ipv6-prefix
| | | +--rw flow-label? | | | +--rw flow-label?
| | | | inet:ipv6-flow-label | | | | inet:ipv6-flow-label
| | | +--rw fragment | | | +--rw fragment
| | | +--rw operator? operator | | | +--rw operator? operator
| | | +--rw type fragment-type | | | +--rw type fragment-type
| | +--rw (l4)? | | +--rw (l4)?
| | ... | | ...
| +--rw actions | +--rw actions
| | ... | | ...
| +--ro statistics | +--ro statistics
| ... | ...
+--ro capabilities +--ro capabilities
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t><xref target="ttcp"></xref> shows the TCP match subtree. In <t><xref target="ttcp" format="default"/> shows the TCP match subtree. I
addition to the fields defined in <xref target="RFC8519"></xref>, this n
addition to the fields defined in <xref target="RFC8519" format="default
"/>, this
specification defines a new TCP matching field, called specification defines a new TCP matching field, called
'flags-bitmask', to efficiently handle TCP flags filtering rules. Some 'flags-bitmask', to efficiently handle TCP flags filtering rules. Some
examples are provided in <xref target="flags"></xref>.</t> examples are provided in <xref target="flags" format="default"/>.</t>
<figure anchor="ttcp">
<t><figure align="center" anchor="ttcp" <name>DOTS ACLs Subtree (TCP Match)</name>
title="DOTS ACLs Subtree (TCP Match)">
<artwork><![CDATA[module: ietf-dots-data-channel
+--rw dots-data
+-rw dots-client* [cuid]
| ...
| +-rw acls
| +-rw acl* [name]
| ...
| +-rw aces
| +-rw ace* [name]
| +-rw name string
| +-rw matches
| | +-rw (l3)?
| | | ...
| | +-rw (l4)?
| | +-:(tcp)
| | | +-rw tcp
| | | +--rw sequence-number? uint32
| | | +--rw acknowledgement-number? uint32
| | | +--rw data-offset? uint8
| | | +--rw reserved? uint8
| | | +--rw flags? bits
| | | +--rw window-size? uint16
| | | +--rw urgent-pointer? uint16
| | | +--rw options? binary
| | | +--rw flags-bitmask
| | | | +--rw operator? operator
| | | | +--rw bitmask uint16
| | | +--rw (source-port)?
| | | | +--:(source-port-range-or-operator)
| | | | +--rw source-port-range-or-operator
| | | | +--rw (port-range-or-operator)?
| | | | +--:(range)
| | | | | +--rw lower-port
| | | | | | inet:port-number
| | | | | +--rw upper-port
| | | | | inet:port-number
| | | | +--:(operator)
| | | | +--rw operator?
| | | | | operator
| | | | +--rw port
| | | | inet:port-number
| | | +--rw (destination-port)?
| | | +--:(destination-port-range-or-operator)
| | | +--rw destination-port-range-or-operator
| | | +--rw (port-range-or-operator)?
| | | +--:(range)
| | | | +--rw lower-port
| | | | | inet:port-number
| | | | +--rw upper-port
| | | | inet:port-number
| | | +--:(operator)
| | | +--rw operator?
| | | | operator
| | | +--rw port
| | | inet:port-number
| | +-:(udp)
| | | ...
| | +-:(icmp)
| | ...
| +-rw actions
| | ...
| +-ro statistics
| ...
+-ro capabilities
...
]]></artwork>
</figure></t>
<t><xref target="ttransport"></xref> shows the UDP and ICMP match <sourcecode type="yangtree"><![CDATA[
+--rw matches
| +--rw (l3)?
| | ...
| +--rw (l4)?
| +--:(tcp)
| | +--rw tcp
| | +--rw sequence-number? uint32
| | +--rw acknowledgement-number? uint32
| | +--rw data-offset? uint8
| | +--rw reserved? uint8
| | +--rw flags? bits
| | +--rw window-size? uint16
| | +--rw urgent-pointer? uint16
| | +--rw options? binary
| | +--rw flags-bitmask
| | | +--rw operator? operator
| | | +--rw bitmask uint16
| | +--rw (source-port)?
| | | +--:(source-port-range-or-operator)
| | | +--rw source-port-range-or-operator
| | | +--rw (port-range-or-operator)?
| | | +--:(range)
| | | | +--rw lower-port
| | | | | inet:port-number
| | | | +--rw upper-port
| | | | inet:port-number
| | | +--:(operator)
| | | +--rw operator?
| | | | operator
| | | +--rw port
| | | inet:port-number
| | +--rw (destination-port)?
| | +--:(destination-port-range-or-operator)
| | +--rw destination-port-range-or-operator
| | +--rw (port-range-or-operator)?
| | +--:(range)
| | | +--rw lower-port
| | | | inet:port-number
| | | +--rw upper-port
| | | inet:port-number
| | +--:(operator)
| | +--rw operator?
| | | operator
| | +--rw port
| | inet:port-number
| +--:(udp)
| | ...
| +--:(icmp)
| ...
+--rw actions
| ...
]]></sourcecode>
</figure>
<t><xref target="ttransport" format="default"/> shows the UDP and ICMP m
atch
subtrees. The same structure is used for both ICMP and ICMPv6. The subtrees. The same structure is used for both ICMP and ICMPv6. The
indication whether an ACL is about ICMP or ICMPv6 is governed by the indication whether an ACL is about ICMP or ICMPv6 is governed by the
'l3' match or the ACL type.</t> 'l3' match or the ACL type.</t>
<figure anchor="ttransport">
<name>DOTS ACLs Subtree (UDP and ICMP Match)</name>
<t><figure align="center" anchor="ttransport" <sourcecode type="yangtree"><![CDATA[
title="DOTS ACLs Subtree (UDP and ICMP Match)"> +--rw matches
<artwork><![CDATA[module: ietf-dots-data-channel | +--rw (l3)?
+-rw dots-data | | ...
+-rw dots-client* [cuid] | +--rw (l4)?
| ... | +--:(tcp)
| +-rw acls | | ...
| +-rw acl* [name] | +--:(udp)
| ... | | +--rw udp
| +-rw aces | | +--rw length? uint16
| +-rw ace* [name] | | +--rw (source-port)?
| +--rw name string | | | +--:(source-port-range-or-operator)
| +--rw matches | | | +--rw source-port-range-or-operator
| | +--rw (l3)? | | | +--rw (port-range-or-operator)?
| | | ... | | | +--:(range)
| | +--rw (l4)? | | | | +--rw lower-port
| | +--:(tcp) | | | | | inet:port-number
| | | ... | | | | +--rw upper-port
| | +--:(udp) | | | | inet:port-number
| | | +--rw udp | | | +--:(operator)
| | | +--rw length? uint16 | | | +--rw operator?
| | | +--rw (source-port)? | | | | operator
| | | | +--:(source-port-range-or-operator) | | | +--rw port
| | | | +--rw source-port-range-or-operator | | | inet:port-number
| | | | +--rw (port-range-or-operator)? | | +--rw (destination-port)?
| | | | +--:(range) | | +--:(destination-port-range-or-operator)
| | | | | +--rw lower-port | | +--rw destination-port-range-or-operator
| | | | | | inet:port-number | | +--rw (port-range-or-operator)?
| | | | | +--rw upper-port | | +--:(range)
| | | | | inet:port-number | | | +--rw lower-port
| | | | +--:(operator) | | | | inet:port-number
| | | | +--rw operator? | | | +--rw upper-port
| | | | | operator | | | inet:port-number
| | | | +--rw port | | +--:(operator)
| | | | inet:port-number | | +--rw operator?
| | | +--rw (destination-port)? | | | operator
| | | +--:(destination-port-range-or-operator) | | +--rw port
| | | +--rw destination-port-range-or-operator | | inet:port-number
| | | +--rw (port-range-or-operator)? | +--:(icmp)
| | | +--:(range) | +--rw icmp
| | | | +--rw lower-port | +--rw type? uint8
| | | | | inet:port-number | +--rw code? uint8
| | | | +--rw upper-port | +--rw rest-of-header? binary
| | | | inet:port-number +--rw actions
| | | +--:(operator) | ...
| | | +--rw operator? ]]></sourcecode>
| | | | operator </figure>
| | | +--rw port <t>DOTS implementations <bcp14>MUST</bcp14> support the following matchi
| | | inet:port-number ng
| | +--:(icmp) criteria:</t>
| | +--rw icmp <ul empty="true" spacing="normal">
| | +--rw type? uint8 <li>Match based on the IP header (IPv4 and IPv6), match based on
| | +--rw code? uint8 the transport header (TCP, UDP, and ICMP), and match based
| | +--rw rest-of-header? binary on any combination
| +--rw actions
| | ...
| +--ro statistics
| ...
+-ro capabilities
...
]]></artwork>
</figure></t>
<t>DOTS implementations MUST support the following matching
criteria:<list style="empty">
<t>match based on the IP header (IPv4 and IPv6), match based on
the transport header (TCP, UDP, and ICMP), and any combination
thereof. The same matching fields are used for both ICMP and thereof. The same matching fields are used for both ICMP and
ICMPv6.</t> ICMPv6.</li>
</list></t> </ul>
<t>The following match fields <bcp14>MUST</bcp14> be supported by DOTS
<t>The following match fields MUST be supported by DOTS implementations (<xref target="mf" format="default"/>):</t>
implementations (<xref target="mf"></xref>):</t> <table align="center" anchor="mf">
<name>Mandatory DOTS Channel Match Fields</name>
<texttable align="center" anchor="mf" style="headers" <thead>
title="Mandatory DOTS Channel Match Fields"> <tr>
<ttcol>ACL Match</ttcol> <th align="left">ACL Match</th>
<th align="left">Mandatory Fields</th>
<ttcol>Mandatory Fields</ttcol> </tr>
</thead>
<c>ipv4</c> <tbody>
<tr>
<c>length, protocol, destination-ipv4-network, source-ipv4-network, <td align="left">ipv4</td>
and fragment</c> <td align="left">length, protocol, destination-ipv4-network, sourc
e-ipv4-network,
<c>ipv6</c> and fragment</td>
</tr>
<c>length, protocol, destination-ipv6-network, source-ipv6-network, <tr>
and fragment</c> <td align="left">ipv6</td>
<td align="left">length, protocol, destination-ipv6-network, sourc
<c>tcp</c> e-ipv6-network,
and fragment</td>
<c>flags-bitmask, source-port-range-or-operator, and </tr>
destination-port-range-or-operator</c> <tr>
<td align="left">tcp</td>
<c>udp</c> <td align="left">flags-bitmask, source-port-range-or-operator, and
destination-port-range-or-operator</td>
<c>length, source-port-range-or-operator, and </tr>
destination-port-range-or-operator</c> <tr>
<td align="left">udp</td>
<c>icmp</c> <td align="left">length, source-port-range-or-operator, and
destination-port-range-or-operator</td>
<c>type and code</c> </tr>
</texttable> <tr>
<td align="left">icmp</td>
<t>Implementations MAY support other filtering match fields and <td align="left">type and code</td>
actions. The 'ietf-dots-data-channel' provides a method for an </tr>
</tbody>
</table>
<t>Implementations <bcp14>MAY</bcp14> support other filtering match fiel
ds and
actions. The 'ietf-dots-data-channel' YANG module provides a method for
an
implementation to expose its filtering capabilities. The tree implementation to expose its filtering capabilities. The tree
structure of the 'capabilities' is shown in <xref structure of the 'capabilities' is shown in <xref target="tcap" format="
target="tcap"></xref>. DOTS clients that support both 'fragment' and default"/>.
'flags' (or 'flags-bitmask' and 'flags') matching fields MUST NOT set DOTS clients that support both 'fragment' and
'flags' (or 'flags-bitmask' and 'flags') matching fields <bcp14>MUST NOT
</bcp14> set
these fields in the same request.</t> these fields in the same request.</t>
<figure anchor="tcap">
<t><figure anchor="tcap" title="Filtering Capabilities Subtree"> <name>Filtering Capabilities Subtree</name>
<artwork align="left"><![CDATA[module: ietf-dots-data-channel <sourcecode type="yangtree"><![CDATA[
+--rw dots-data module: ietf-dots-data-channel
... +--rw dots-data
+--ro capabilities ...
+--ro address-family* enumeration +--ro capabilities
+--ro forwarding-actions* identityref +--ro address-family* enumeration
+--ro rate-limit? boolean +--ro forwarding-actions* identityref
+--ro transport-protocols* uint8 +--ro rate-limit? boolean
+--ro ipv4 +--ro transport-protocols* uint8
| +--ro dscp? boolean +--ro ipv4
| +--ro ecn? boolean | +--ro dscp? boolean
| +--ro length? boolean | +--ro ecn? boolean
| +--ro ttl? boolean | +--ro length? boolean
| +--ro protocol? boolean | +--ro ttl? boolean
| +--ro ihl? boolean | +--ro protocol? boolean
| +--ro flags? boolean | +--ro ihl? boolean
| +--ro offset? boolean | +--ro flags? boolean
| +--ro identification? boolean | +--ro offset? boolean
| +--ro source-prefix? boolean | +--ro identification? boolean
| +--ro destination-prefix? boolean | +--ro source-prefix? boolean
| +--ro fragment? boolean | +--ro destination-prefix? boolean
+--ro ipv6 | +--ro fragment? boolean
| +--ro dscp? boolean +--ro ipv6
| +--ro ecn? boolean | +--ro dscp? boolean
| +--ro length? boolean | +--ro ecn? boolean
| +--ro hoplimit? boolean | +--ro length? boolean
| +--ro protocol? boolean | +--ro hoplimit? boolean
| +--ro destination-prefix? boolean | +--ro protocol? boolean
| +--ro source-prefix? boolean | +--ro destination-prefix? boolean
| +--ro flow-label? boolean | +--ro source-prefix? boolean
| +--ro fragment? boolean | +--ro flow-label? boolean
+--ro tcp | +--ro fragment? boolean
| +--ro sequence-number? boolean +--ro tcp
| +--ro acknowledgement-number? boolean | +--ro sequence-number? boolean
| +--ro data-offset? boolean | +--ro acknowledgement-number? boolean
| +--ro reserved? boolean | +--ro data-offset? boolean
| +--ro flags? boolean | +--ro reserved? boolean
| +--ro window-size? boolean | +--ro flags? boolean
| +--ro urgent-pointer? boolean | +--ro window-size? boolean
| +--ro options? boolean | +--ro urgent-pointer? boolean
| +--ro flags-bitmask? boolean | +--ro options? boolean
| +--ro source-port? boolean | +--ro flags-bitmask? boolean
| +--ro destination-port? boolean | +--ro source-port? boolean
| +--ro port-range? boolean | +--ro destination-port? boolean
+--ro udp | +--ro port-range? boolean
| +--ro length? boolean +--ro udp
| +--ro source-port? boolean | +--ro length? boolean
| +--ro destination-port? boolean | +--ro source-port? boolean
| +--ro port-range? boolean | +--ro destination-port? boolean
+--ro icmp | +--ro port-range? boolean
+--ro type? boolean +--ro icmp
+--ro code? boolean +--ro type? boolean
+--ro rest-of-header? boolean +--ro code? boolean
]]></artwork> +--ro rest-of-header? boolean
</figure></t> ]]></sourcecode>
</figure>
<t></t> <t/>
</section> </section>
<section numbered="true" toc="default">
<name>YANG Module</name>
<t>This module uses the common YANG types defined in <xref target="RFC69
91" format="default"/> and types defined in <xref target="RFC8519" format="defau
lt"/>. </t>
<section title="YANG Module"> <sourcecode name="ietf-dots-data-channel@2020-05-28.yang" type="yang" ma
<t>This module uses the common YANG types defined in <xref rkers="true"><![CDATA[
target="RFC6991"></xref> and types defined in <xref
target="RFC8519"></xref>. <figure>
<artwork><![CDATA[<CODE BEGINS> file "ietf-dots-data-channel@2019-05
-09.yang"
module ietf-dots-data-channel { module ietf-dots-data-channel {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-data-channel"; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-data-channel";
prefix data-channel; prefix data-channel;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference "Section 4 of RFC 6991"; reference
"Section 4 of RFC 6991";
} }
import ietf-access-control-list { import ietf-access-control-list {
prefix ietf-acl; prefix ietf-acl;
reference reference
"RFC 8519: YANG Data Model for Network Access "RFC 8519: YANG Data Model for Network Access
Control Lists (ACLs)"; Control Lists (ACLs)";
} }
import ietf-packet-fields { import ietf-packet-fields {
prefix packet-fields; prefix packet-fields;
reference reference
skipping to change at line 1001 skipping to change at line 904
organization organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group"; "IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/dots/> "WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org> WG List: <mailto:dots@ietf.org>
Editor: Mohamed Boucadair Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Editor: Konda, Tirumaleswar Reddy Editor: Konda, Tirumaleswar Reddy.K
<mailto:TirumaleswarReddy_Konda@McAfee.com> <mailto:TirumaleswarReddy_Konda@McAfee.com>
Author: Jon Shallow Author: Jon Shallow
<mailto:jon.shallow@nccgroup.com> <mailto:jon.shallow@nccgroup.com>
Author: Kaname Nishizuka Author: Kaname Nishizuka
<mailto:kaname@nttv6.jp> <mailto:kaname@nttv6.jp>
Author: Liang Xia Author: Liang Xia
<mailto:frank.xialiang@huawei.com> <mailto:frank.xialiang@huawei.com>
Author: Prashanth Patil Author: Prashanth Patil
<mailto:praspati@cisco.com> <mailto:praspati@cisco.com>
Author: Andrew Mortensen Author: Andrew Mortensen
<mailto:amortensen@arbor.net> <mailto:amortensen@arbor.net>
Author: Nik Teague Author: Nik Teague
<mailto:nteague@verisign.com>"; <mailto:nteague@ironmountain.co.uk>";
description description
"This module contains YANG definition for configuring "This module contains YANG definition for configuring
aliases for resources and filtering rules using DOTS aliases for resources and filtering rules using DOTS
data channel. data channel.
Copyright (c) 2019 IETF Trust and the persons identified as Copyright (c) 2020 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 8783; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2019-05-09 { revision 2020-05-28 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Distributed Denial-of-Service Open Threat "RFC 8783: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Data Channel Specification"; Signaling (DOTS) Data Channel Specification";
} }
typedef activation-type { typedef activation-type {
type enumeration { type enumeration {
enum "activate-when-mitigating" { enum activate-when-mitigating {
value 1; value 1;
description description
"The Access Control List (ACL) is installed only when "The Access Control List (ACL) is installed only when
a mitigation is active for the DOTS client."; a mitigation is active for the DOTS client.";
} }
enum "immediate" { enum immediate {
value 2; value 2;
description description
"The ACL is immediately activated."; "The ACL is immediately activated.";
} }
enum "deactivate" { enum deactivate {
value 3; value 3;
description description
"The ACL is maintained by the DOTS server, but it is "The ACL is maintained by the DOTS server, but it is
deactivated."; deactivated.";
} }
} }
description description
"Indicates the activation type of an ACL."; "Indicates the activation type of an ACL.";
} }
typedef operator { typedef operator {
type bits { type bits {
bit not { bit not {
position 0; position 0;
description description
"If set, logical negation of operation."; "If set, logical negation of operation.";
} }
bit match { bit match {
position 1; position 1;
description description
"Match bit. This is a bitwise match operation "Match bit. This is a bitwise match operation
defined as '(data & value) == value'."; defined as '(data & value) == value'.";
} }
bit any { bit any {
position 3; position 3;
description description
"Any bit. This is a match on any of the bits in "Any bit. This is a match on any of the bits in
bitmask. It evaluates to 'true' if any of the bits bitmask. It evaluates to 'true' if any of the bits
in the value mask are set in the data, in the value mask are set in the data,
i.e., '(data & value) != 0'."; i.e., '(data & value) != 0'.";
} }
} }
description description
"Specifies how to apply the defined bitmask."; "Specifies how to apply the defined bitmask.
'any' and 'match' bits must not be set simultaneously.";
} }
grouping tcp-flags { grouping tcp-flags {
leaf operator { leaf operator {
type operator; type operator;
default "match"; default "match";
description description
"Specifies how to interpret the TCP flags."; "Specifies how to interpret the TCP flags.";
} }
leaf bitmask { leaf bitmask {
type uint16; type uint16;
mandatory true; mandatory true;
description description
"The bitmask matches the last 4 bits of byte 12 "The bitmask matches the last 4 bits of byte 12
and byte 13 of the TCP header. For clarity, the 4 bits and byte 13 of the TCP header. For clarity, the 4 bits
of byte 12 corresponding to the TCP data offset field of byte 12 corresponding to the TCP data offset field
are not included in any matching."; are not included in any matching.";
} }
description description
"Operations on TCP flags."; "Operations on TCP flags.";
} }
typedef fragment-type { typedef fragment-type {
type bits { type bits {
bit df { bit df {
skipping to change at line 1156 skipping to change at line 1060
description description
"Specifies the targets of the mitigation request."; "Specifies the targets of the mitigation request.";
leaf-list target-prefix { leaf-list target-prefix {
type inet:ip-prefix; type inet:ip-prefix;
description description
"IPv4 or IPv6 prefix identifying the target."; "IPv4 or IPv6 prefix identifying the target.";
} }
list target-port-range { list target-port-range {
key "lower-port"; key "lower-port";
description description
"Port range. When only lower-port is "Port range. When only lower-port is
present, it represents a single port number."; present, it represents a single port number.";
leaf lower-port { leaf lower-port {
type inet:port-number; type inet:port-number;
mandatory true; mandatory true;
description description
"Lower port number of the port range."; "Lower port number of the port range.";
} }
leaf upper-port { leaf upper-port {
type inet:port-number; type inet:port-number;
must '. >= ../lower-port' { must '. >= ../lower-port' {
error-message error-message
"The upper port number must be greater than "The upper-port number must be greater than
or equal to the lower-port number."; or equal to the lower-port number.";
} }
description description
"Upper port number of the port range."; "Upper port number of the port range.";
} }
} }
leaf-list target-protocol { leaf-list target-protocol {
type uint8; type uint8;
description description
"Identifies the target protocol number. "Identifies the target protocol number.
Values are taken from the IANA protocol registry: Values are taken from the IANA protocol registry:
https://www.iana.org/assignments/protocol-numbers/ https://www.iana.org/assignments/protocol-numbers/
protocol-numbers.xhtml
For example, 6 for TCP or 17 for UDP."; For example, 6 for TCP or 17 for UDP.";
} }
leaf-list target-fqdn { leaf-list target-fqdn {
type inet:domain-name; type inet:domain-name;
description description
"FQDN identifying the target."; "FQDN identifying the target.";
} }
leaf-list target-uri { leaf-list target-uri {
type inet:uri; type inet:uri;
skipping to change at line 1217 skipping to change at line 1120
mandatory true; mandatory true;
description description
"Indicates what fragment type to look for."; "Indicates what fragment type to look for.";
} }
description description
"Operations on fragment types."; "Operations on fragment types.";
} }
grouping aliases { grouping aliases {
description description
"Top level container for aliases."; "Top-level container for aliases.";
list alias { list alias {
key "name"; key "name";
description description
"List of aliases."; "List of aliases.";
leaf name { leaf name {
type string; type string;
description description
"The name of the alias."; "The name of the alias.";
} }
uses target; uses target;
skipping to change at line 1272 skipping to change at line 1175
} }
grouping access-lists { grouping access-lists {
description description
"Specifies the ordered set of Access Control Lists."; "Specifies the ordered set of Access Control Lists.";
list acl { list acl {
key "name"; key "name";
ordered-by user; ordered-by user;
description description
"An ACL is an ordered list of Access Control Entries (ACE). "An ACL is an ordered list of Access Control Entries (ACE).
Each ACE has a list of match criteria and a list of actions."; Each ACE has a list of match criteria and a list of
actions.";
leaf name { leaf name {
type string { type string {
length "1..64"; length "1..64";
} }
description description
"The name of the access list."; "The name of the access list.";
reference reference
"RFC 8519: YANG Data Model for Network Access "RFC 8519: YANG Data Model for Network Access
Control Lists (ACLs)"; Control Lists (ACLs)";
} }
leaf type { leaf type {
type ietf-acl:acl-type; type ietf-acl:acl-type;
description description
"Type of access control list. Indicates the primary intended "Type of access control list. Indicates the primary
type of match criteria (e.g., IPv4, IPv6) used in the list intended type of match criteria (e.g., IPv4, IPv6)
instance."; used in the list instance.";
reference reference
"RFC 8519: YANG Data Model for Network Access "RFC 8519: YANG Data Model for Network Access
Control Lists (ACLs)"; Control Lists (ACLs)";
} }
leaf activation-type { leaf activation-type {
type activation-type; type activation-type;
default "activate-when-mitigating"; default "activate-when-mitigating";
description description
"Indicates the activation type of an ACL. An ACL can be "Indicates the activation type of an ACL. An ACL can be
deactivated, installed immediately, or installed when deactivated, installed immediately, or installed when
a mitigation is active."; a mitigation is active.";
} }
leaf pending-lifetime { leaf pending-lifetime {
type int32; type int32;
units "minutes"; units "minutes";
config false; config false;
description description
"Indicates the pending validity lifetime of the ACL "Indicates the pending validity lifetime of the ACL
entry."; entry.";
skipping to change at line 1450 skipping to change at line 1354
list dots-client { list dots-client {
key "cuid"; key "cuid";
description description
"List of DOTS clients."; "List of DOTS clients.";
leaf cuid { leaf cuid {
type string; type string;
description description
"A unique identifier that is generated by a DOTS client "A unique identifier that is generated by a DOTS client
to prevent request collisions."; to prevent request collisions.";
reference reference
"RFC YYYY: Distributed Denial-of-Service Open Threat "RFC 8782: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
} }
leaf cdid { leaf cdid {
type string; type string;
description description
"A client domain identifier conveyed by a "A client domain identifier conveyed by a
server-domain DOTS gateway to a remote DOTS server."; server-domain DOTS gateway to a remote DOTS server.";
reference reference
"RFC YYYY: Distributed Denial-of-Service Open Threat "RFC 8782: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
} }
container aliases { container aliases {
description description
"Set of aliases that are bound to a DOTS client."; "Set of aliases that are bound to a DOTS client.";
uses aliases; uses aliases;
} }
container acls { container acls {
description description
"Access lists that are bound to a DOTS client."; "Access lists that are bound to a DOTS client.";
uses access-lists; uses access-lists;
} }
} }
container capabilities { container capabilities {
config false; config false;
description description
"Match capabilities"; "Match capabilities";
leaf-list address-family { leaf-list address-family {
type enumeration { type enumeration {
enum "ipv4" { enum ipv4 {
description description
"IPv4 is supported."; "IPv4 is supported.";
} }
enum "ipv6" { enum ipv6 {
description description
"IPv6 is supported."; "IPv6 is supported.";
} }
} }
description description
"Indicates the IP address families supported by "Indicates the IP address families supported by
the DOTS server."; the DOTS server.";
} }
leaf-list forwarding-actions { leaf-list forwarding-actions {
type identityref { type identityref {
skipping to change at line 1511 skipping to change at line 1415
description description
"Support of rate-limit action."; "Support of rate-limit action.";
} }
leaf-list transport-protocols { leaf-list transport-protocols {
type uint8; type uint8;
description description
"Upper-layer protocol associated with a filtering rule. "Upper-layer protocol associated with a filtering rule.
Values are taken from the IANA protocol registry: Values are taken from the IANA protocol registry:
https://www.iana.org/assignments/protocol-numbers/ https://www.iana.org/assignments/protocol-numbers/
protocol-numbers.xhtml
For example, this field contains 1 for ICMP, 6 for TCP For example, this field contains 1 for ICMP, 6 for TCP
17 for UDP, or 58 for ICMPv6."; 17 for UDP, or 58 for ICMPv6.";
} }
container ipv4 { container ipv4 {
description description
"Indicates IPv4 header fields that are supported to enforce "Indicates IPv4 header fields that are supported to enforce
ACLs."; ACLs.";
leaf dscp { leaf dscp {
type boolean; type boolean;
description description
"Support of filtering based on Differentiated Services Code "Support of filtering based on Differentiated Services
Point (DSCP)."; Code Point (DSCP).";
} }
leaf ecn { leaf ecn {
type boolean; type boolean;
description description
"Support of filtering based on Explicit Congestion "Support of filtering based on Explicit Congestion
Notification (ECN)."; Notification (ECN).";
} }
leaf length { leaf length {
type boolean; type boolean;
description description
skipping to change at line 1582 skipping to change at line 1485
} }
leaf destination-prefix { leaf destination-prefix {
type boolean; type boolean;
description description
"Support of filtering based on the destination prefix."; "Support of filtering based on the destination prefix.";
} }
leaf fragment { leaf fragment {
type boolean; type boolean;
description description
"Indicates the capability of a DOTS server to "Indicates the capability of a DOTS server to
enforce filters on IPv4 fragments. That is, the match enforce filters on IPv4 fragments. That is, the match
functionality based on the Layer 3 'fragment' clause functionality based on the Layer 3 'fragment' clause
is supported."; is supported.";
} }
} }
container ipv6 { container ipv6 {
description description
"Indicates IPv6 header fields that are supported to enforce "Indicates IPv6 header fields that are supported to enforce
ACLs."; ACLs.";
leaf dscp { leaf dscp {
type boolean; type boolean;
skipping to change at line 1629 skipping to change at line 1532
"Support of filtering based on the destination prefix."; "Support of filtering based on the destination prefix.";
} }
leaf source-prefix { leaf source-prefix {
type boolean; type boolean;
description description
"Support of filtering based on the source prefix."; "Support of filtering based on the source prefix.";
} }
leaf flow-label { leaf flow-label {
type boolean; type boolean;
description description
"Support of filtering based on the Flow label."; "Support of filtering based on the Flow Label.";
} }
leaf fragment { leaf fragment {
type boolean; type boolean;
description description
"Indicates the capability of a DOTS server to "Indicates the capability of a DOTS server to
enforce filters on IPv6 fragments."; enforce filters on IPv6 fragments.";
} }
} }
container tcp { container tcp {
description description
skipping to change at line 1706 skipping to change at line 1609
description description
"Support of filtering based on the destination port "Support of filtering based on the destination port
number."; number.";
} }
leaf port-range { leaf port-range {
type boolean; type boolean;
description description
"Support of filtering based on a port range. "Support of filtering based on a port range.
This includes filtering based on a source port range, This includes filtering based on a source port range,
destination port range, or both. All operators destination port range, or both. All operators
(i.e, less than or equal to, greater than or equal to, (i.e, less than or equal to, greater than or equal to,
equal to, and not equal to) are supported."; equal to, and not equal to) are supported.
In particular, this means that the implementation
supports filtering based on
source-port-range-or-operator and
destination-port-range-or-operator.";
} }
} }
container udp { container udp {
description description
"Set of UDP fields that are supported by the DOTS server "Set of UDP fields that are supported by the DOTS server
to enforce filters."; to enforce filters.";
leaf length { leaf length {
type boolean; type boolean;
description description
"Support of filtering based on the UDP length."; "Support of filtering based on the UDP length.";
skipping to change at line 1737 skipping to change at line 1645
description description
"Support of filtering based on the destination port "Support of filtering based on the destination port
number."; number.";
} }
leaf port-range { leaf port-range {
type boolean; type boolean;
description description
"Support of filtering based on a port range. "Support of filtering based on a port range.
This includes filtering based on a source port range, This includes filtering based on a source port range,
destination port range, or both. All operators destination port range, or both. All operators
(i.e, less than or equal, greater than or equal, equal to, (i.e, less than or equal, greater than or equal,
and not equal to) are supported."; equal to, and not equal to) are supported.
In particular, this means that the implementation
supports filtering based on
source-port-range-or-operator and
destination-port-range-or-operator.";
} }
} }
container icmp { container icmp {
description description
"Set of ICMP/ICMPv6 fields that are supported by the DOTS "Set of ICMP/ICMPv6 fields that are supported by the DOTS
server to enforce filters."; server to enforce filters.";
leaf type { leaf type {
type boolean; type boolean;
description description
"Support of filtering based on the ICMP/ICMPv6 type."; "Support of filtering based on the ICMP/ICMPv6 type.";
} }
leaf code { leaf code {
type boolean; type boolean;
description description
"Support of filtering based on the ICMP/ICMPv6 code."; "Support of filtering based on the ICMP/ICMPv6 code.";
} }
leaf rest-of-header { leaf rest-of-header {
type boolean; type boolean;
description description
"Support of filtering based on the ICMP four-bytes "Support of filtering based on the ICMP four-byte
field / the ICMPv6 message body."; field / the ICMPv6 message body.";
} }
} }
} }
} }
} }
<CODE ENDS> ]]></sourcecode>
]]></artwork>
</figure></t>
</section> </section>
</section> </section>
<section anchor="registering" numbered="true" toc="default">
<section anchor="registering" title="Managing DOTS Clients"> <name>Managing DOTS Clients</name>
<section anchor="registe" title="Registering DOTS Clients"> <section anchor="registe" numbered="true" toc="default">
<t>In order to make use of DOTS data channel, a DOTS client MUST <name>Registering DOTS Clients</name>
register to its DOTS server(s) by creating a DOTS client <t>In order to make use of the DOTS data channel, a DOTS client <bcp14>M
('dots-client') resource. To that aim, DOTS clients SHOULD send a POST UST</bcp14>
request (shown in <xref target="register"></xref>).</t> register with its DOTS server(s) by creating a DOTS client
('dots-client') resource. To that aim, DOTS clients <bcp14>SHOULD</bcp14
<t><figure anchor="register" title="POST to Register Schema"> > send a POST
<artwork align="left"><![CDATA[ POST /restconf/data/ietf-dots-data-c request (shown in <xref target="register" format="default"/>).</t>
hannel:dots-data HTTP/1.1 <figure anchor="register">
<name>POST to Register Schema</name>
<sourcecode type=""><![CDATA[
POST /restconf/data/ietf-dots-data-channel:dots-data HTTP/1.1
Host: {host}:{port} Host: {host}:{port}
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-data-channel:dots-client": [ "ietf-dots-data-channel:dots-client": [
{ {
"cuid": "string" "cuid": "string"
} }
] ]
}]]></artwork> }]]></sourcecode>
</figure></t> </figure>
<t>The 'cuid' (client unique identifier) parameter is described <t>The 'cuid' (client unique identifier) parameter is described
below:<list style="hanging"> below:</t>
<t hangText="cuid:">A globally unique identifier that is meant to <dl newline="false" spacing="normal">
<dt>cuid:</dt>
<dd>
<t>A globally unique identifier that is meant to
prevent collisions among DOTS clients. This attribute has the same prevent collisions among DOTS clients. This attribute has the same
meaning, syntax, and processing rules as the 'cuid' attribute meaning, syntax, and processing rules as the 'cuid' attribute
defined in <xref defined in <xref target="RFC8782" format="default"/>.</t>
target="I-D.ietf-dots-signal-channel"></xref>.<vspace <t>DOTS clients <bcp14>MUST</bcp14> use the same 'cuid' for both
blankLines="1" />DOTS clients MUST use the same 'cuid' for both signal and data channels.</t>
signal and data channels.<vspace blankLines="1" />This is a <t>This is a
mandatory attribute.</t> mandatory attribute.</t>
</list></t> </dd>
</dl>
<t>In deployments where server-domain DOTS gateways are enabled, <t>In deployments where server-domain DOTS gateways are enabled,
identity information about the origin source client domain SHOULD be identity information about the origin source client domain <bcp14>SHOULD </bcp14> be
supplied to the DOTS server. That information is meant to assist the supplied to the DOTS server. That information is meant to assist the
DOTS server to enforce some policies. These policies can be enforced DOTS server to enforce some policies. These policies can be enforced
per-client, per-client domain, or both. <xref per client, per client domain, or both. <xref target="register-relayed"
target="register-relayed"></xref> shows a schema example of a request format="default"/>
relayed by a server-domain DOTS gateway.<figure shows a schema of a register request relayed by a server-domain DOTS
anchor="register-relayed" gateway.</t>
title="POST to Register Schema (via a Server-Domain DOTS Gateway)"> <figure anchor="register-relayed">
<artwork align="left"><![CDATA[ POST /restconf/data/ietf-dots-data-c <name>POST to Register Schema (via a Server-Domain DOTS Gateway)</name
hannel:dots-data HTTP/1.1 >
<sourcecode type=""><![CDATA[
POST /restconf/data/ietf-dots-data-channel:dots-data HTTP/1.1
Host: {host}:{port} Host: {host}:{port}
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-data-channel:dots-client": [ "ietf-dots-data-channel:dots-client": [
{ {
"cuid": "string", "cuid": "string",
"cdid": "string" "cdid": "string"
} }
] ]
}]]></artwork> }
</figure>A server-domain DOTS gateway SHOULD add the following ]]></sourcecode>
</figure>
<t>A server-domain DOTS gateway <bcp14>SHOULD</bcp14> add the following
attribute:</t> attribute:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>cdid:</dt>
<t hangText="cdid:">This attribute has the same meaning, syntax, <dd>
and processing rules as the 'cdid' attribute defined in <xref <t>This attribute has the same meaning, syntax,
target="I-D.ietf-dots-signal-channel"></xref>. <vspace and processing rules as the 'cdid' attribute defined in
blankLines="1" /> In deployments where server-domain DOTS gateways <xref target="RFC8782" format="default"/>. </t>
<t> In deployments where server-domain DOTS gateways
are enabled, 'cdid' does not need to be inserted when relaying are enabled, 'cdid' does not need to be inserted when relaying
DOTS methods to manage aliases (<xref target="identifier"></xref>) DOTS methods to manage aliases (<xref target="identifier" format="de
or filtering rules (<xref target="filter"></xref>). DOTS servers fault"/>)
or filtering rules (<xref target="filter" format="default"/>). DOTS
servers
are responsible for maintaining the association between 'cdid' and are responsible for maintaining the association between 'cdid' and
'cuid' for policy enforcement purposes.<vspace 'cuid' for policy enforcement purposes.</t>
blankLines="1" />This is an optional attribute.</t> <t>This is an optional attribute.</t>
</list></t> </dd>
</dl>
<t>A request example to create a 'dots-client' resource is depicted in <t>An example request to create a 'dots-client' resource is depicted in
<xref target="register-example"></xref>. This request is relayed by a <xref target="register-example" format="default"/>. This request is rela
yed by a
server-domain DOTS gateway as hinted by the presence of the 'cdid' server-domain DOTS gateway as hinted by the presence of the 'cdid'
attribute.</t> attribute.</t>
<figure anchor="register-example">
<t><figure anchor="register-example" <name>POST to Register (DOTS gateway)</name>
title="POST to Register (DOTS gateway)"> <sourcecode type=""><![CDATA[
<artwork align="left"><![CDATA[ POST /restconf/data/ietf-dots-data-c POST /restconf/data/ietf-dots-data-channel:dots-data HTTP/1.1
hannel:dots-data HTTP/1.1
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-data-channel:dots-client": [ "ietf-dots-data-channel:dots-client": [
{ {
"cuid": "dz6pHjaADkaFTbjr0JGBpw", "cuid": "dz6pHjaADkaFTbjr0JGBpw",
"cdid": "7eeaf349529eb55ed50113" "cdid": "7eeaf349529eb55ed50113"
} }
] ]
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>As a reminder, DOTS gateways may rewrite the 'cuid' used by peer <t>As a reminder, DOTS gateways may rewrite the 'cuid' used by peer
DOTS clients (Section 4.4.1 of <xref DOTS clients (<xref target="RFC8782" section="4.4.1" sectionFormat="of"
target="I-D.ietf-dots-signal-channel"></xref>).</t> format="default"/>).</t>
<t>DOTS servers can identify the DOTS client domain using the 'cdid' <t>DOTS servers can identify the DOTS client domain using the 'cdid'
parameter or using the client's DNS name specified in the Subject parameter or using the client's DNS name specified in the Subject
Alternative Name extension's dNSName type in the client certificate Alternative Name extension's dNSName type in the client certificate
<xref target="RFC6125"></xref>.</t> <xref target="RFC6125" format="default"/>.</t>
<t>DOTS servers <bcp14>MUST</bcp14> limit the number of 'dots-client' re
<t>DOTS servers MUST limit the number of 'dots-client' resources to be sources to be
created by the same DOTS client to 1 per request. Requests with created by the same DOTS client to 1 per request. Requests with
multiple 'dots-client' resources MUST be rejected by DOTS servers. To multiple 'dots-client' resources <bcp14>MUST</bcp14> be rejected by DOTS
that aim, the DOTS server MUST rely on the same procedure to servers. To
unambiguously identify a DOTS client as discussed in Section 4.4.1 of that aim, the DOTS server <bcp14>MUST</bcp14> rely on the same procedure
<xref target="I-D.ietf-dots-signal-channel"></xref>.</t> to
unambiguously identify a DOTS client as discussed in
<xref target="RFC8782" section="4.4.1" sectionFormat="of" format="defaul
t"/>.</t>
<t>The DOTS server indicates the result of processing the POST request <t>The DOTS server indicates the result of processing the POST request
using status-line codes. Status codes in the range "2xx" codes are using status-line codes. Status codes in the "2xx" range are
success, "4xx" codes are some sort of invalid requests and "5xx" codes success, "4xx" codes are some sort of invalid requests and "5xx" codes
are returned if the DOTS server has erred or is incapable of accepting are returned if the DOTS server has erred or is incapable of accepting
the creation of the 'dots-client' resource. In particular, <list the creation of the 'dots-client' resource. In particular, </t>
style="symbols"> <ul spacing="normal">
<t>"201 Created" status-line is returned in the response, if the <li>"201 Created" status-line is returned in the response if the
DOTS server has accepted the request.</t> DOTS server has accepted the request.</li>
<li>"400 Bad Request" status-line is returned by the DOTS server
<t>"400 Bad Request" status-line is returned by the DOTS server,
if the request does not include a 'cuid' parameter. The error-tag if the request does not include a 'cuid' parameter. The error-tag
"missing-attribute" is used in this case.</t> "missing-attribute" is used in this case.</li>
<li>"409 Conflict" status-line is returned to the requesting DOTS
<t>"409 Conflict" status-line is returned to the requesting DOTS client if the data resource already exists. The error-tag
client, if the data resource already exists. The error-tag "resource-denied" is used in this case.</li>
"resource-denied" is used in this case.</t> </ul>
</list></t> <t>Once a DOTS client registers itself with a DOTS server, it can
create/delete/retrieve aliases (<xref target="identifier" format="defaul
<t>Once a DOTS client registers itself to a DOTS server, it can t"/>) and
create/delete/retrieve aliases (<xref target="identifier"></xref>) and filtering rules (<xref target="filter" format="default"/>).</t>
filtering rules (<xref target="filter"></xref>).</t> <t>A DOTS client <bcp14>MAY</bcp14> use the PUT request
(<xref target="RFC8040" section="4.5" sectionFormat="of" format="default
<t>A DOTS client MAY use the PUT request (Section 4.5 in <xref "/>)
target="RFC8040"></xref>) to register a DOTS client within the DOTS to register a DOTS client within the DOTS
server. An example is shown in <xref target="putregister"></xref>.</t> server. An example is shown in <xref target="putregister" format="defaul
t"/>.</t>
<t><figure anchor="putregister" title="PUT to Register"> <figure anchor="putregister">
<artwork align="center"><![CDATA[ PUT /restconf/data/ietf-dots-data- <name>PUT to Register</name>
channel:dots-data\ <sourcecode type=""><![CDATA[
PUT /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1 /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-data-channel:dots-client": [ "ietf-dots-data-channel:dots-client": [
{ {
"cuid": "dz6pHjaADkaFTbjr0JGBpw" "cuid": "dz6pHjaADkaFTbjr0JGBpw"
} }
] ]
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
<t>The DOTS gateway that inserted a 'cdid' in a PUT request MUST strip <t>The DOTS gateway that inserted a 'cdid' in a PUT request <bcp14>MUST<
/bcp14> strip
the 'cdid' parameter in the corresponding response before forwarding the 'cdid' parameter in the corresponding response before forwarding
the response to the DOTS client.</t> the response to the DOTS client.</t>
</section> </section>
<section anchor="unregistering" numbered="true" toc="default">
<section anchor="unregistering" title="Unregistering DOTS Clients"> <name>De-registering DOTS Clients</name>
<t>A DOTS client de-registers from its DOTS server(s) by deleting the <t>A DOTS client de-registers from its DOTS server(s) by deleting the
'cuid' resource(s). Resources bound to this DOTS client will be 'cuid' resource(s). Resources bound to this DOTS client will be
deleted by the DOTS server. An example of a de-register request is deleted by the DOTS server. An example of a de-register request is
shown in <xref target="derigister"></xref>.</t> shown in <xref target="derigister" format="default"/>.</t>
<figure anchor="derigister">
<t><figure align="center" anchor="derigister" <name>De-register a DOTS Client</name>
title="De-register a DOTS Client"> <sourcecode type=""><![CDATA[
<artwork><![CDATA[ DELETE /restconf/data/ietf-dots-data-channel:dots DELETE /restconf/data/ietf-dots-data-channel:dots-data\
-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1 /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
Host: example.com Host: example.com
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
</section> </section>
</section> </section>
<section anchor="identifier" numbered="true" toc="default">
<section anchor="identifier" title="Managing DOTS Aliases"> <name>Managing DOTS Aliases</name>
<t>The following sub-sections define means for a DOTS client to create <t>The following subsections define the means for a DOTS client to create
aliases (<xref target="calias"></xref>), retrieve one or a list of aliases (<xref target="calias" format="default"/>), to retrieve one or a l
aliases (<xref target="ralias"></xref>), and delete an alias (<xref ist of
target="dalias"></xref>).</t> aliases (<xref target="ralias" format="default"/>), and to delete an alias
(<xref target="dalias" format="default"/>).</t>
<section anchor="calias" title="Create Aliases"> <section anchor="calias" numbered="true" toc="default">
<t>A POST or PUT request is used by a DOTS client to create aliases, <name>Creating Aliases</name>
<t>A POST or PUT request is used by a DOTS client to create aliases
for resources for which a mitigation may be requested. Such aliases for resources for which a mitigation may be requested. Such aliases
may be used in subsequent DOTS signal channel exchanges to refer more may be used in subsequent DOTS signal channel exchanges to refer more
efficiently to the resources under attack.</t> efficiently to the resources under attack.</t>
<t>DOTS clients within the same domain can create different aliases <t>DOTS clients within the same domain can create different aliases
for the same resource.</t> for the same resource.</t>
<t>The structure of POST requests used to create aliases is shown in <t>The structure of POST requests used to create aliases is shown in
<xref target="createalias"></xref>.</t> <xref target="createalias" format="default"/>.</t>
<figure anchor="createalias">
<t><figure anchor="createalias" <name>POST to Create Aliases (Request Schema)</name>
title="POST to Create Aliases (Request Schema)"> <sourcecode type=""><![CDATA[
<artwork align="left"><![CDATA[ POST /restconf/data/ietf-dots-data-c POST /restconf/data/ietf-dots-data-channel:dots-data\
hannel:dots-data\
/dots-client=cuid HTTP/1.1 /dots-client=cuid HTTP/1.1
Host: {host}:{port} Host: {host}:{port}
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-data-channel:aliases": { "ietf-dots-data-channel:aliases": {
"alias": [ "alias": [
{ {
"name": "string", "name": "string",
"target-prefix": [ "target-prefix": [
skipping to change at line 1993 skipping to change at line 1902
], ],
"target-fqdn": [ "target-fqdn": [
"string" "string"
], ],
"target-uri": [ "target-uri": [
"string" "string"
] ]
} }
] ]
} }
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
<t>The parameters are described below:</t> <t>The parameters are described below:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>name:</dt>
<t hangText="name:">Name of the alias. <vspace <dd>
blankLines="1" />This is a mandatory attribute.</t> <t>Name of the alias. </t>
<t>This is a mandatory attribute.</t>
<t hangText="target-prefix: ">Prefixes are separated by commas. </dd>
<dt>target-prefix: </dt>
<dd>
<t>Prefixes are separated by commas.
Prefixes are represented using Classless Inter-domain Routing Prefixes are represented using Classless Inter-domain Routing
(CIDR) notation <xref target="RFC4632"></xref>. As a reminder, the (CIDR) notation <xref target="RFC4632" format="default"/>. As a remi
prefix length must be less than or equal to 32 (resp. 128) for nder, the
IPv4 (resp. IPv6).<vspace blankLines="1" />The prefix list MUST prefix length must be less than or equal to 32 for
NOT include broadcast, loopback, or multicast addresses. These IPv4 or 128 for IPv6.</t>
<t>The prefix list <bcp14>MUST
NOT</bcp14> include broadcast, loopback, or multicast addresses. The
se
addresses are considered as invalid values. In addition, the DOTS addresses are considered as invalid values. In addition, the DOTS
server MUST validate that these prefixes are within the scope of server <bcp14>MUST</bcp14> validate that these prefixes are within t he scope of
the DOTS client domain. Other validation checks may be supported the DOTS client domain. Other validation checks may be supported
by DOTS servers.<vspace blankLines="1" />This is an optional by DOTS servers.</t>
<t>This is an optional
attribute.</t> attribute.</t>
</dd>
<t hangText="target-port-range: ">A range of port numbers. <vspace <dt>target-port-range: </dt>
blankLines="1" />The port range is defined by two bounds, a lower <dd>
port number (lower-port) and an upper port number (upper-port). <t>A range of port numbers. </t>
<t>The port range is defined by two bounds, a lower
port number ('lower-port') and an upper port number ('upper-port').
The range is considered to include both the lower and upper The range is considered to include both the lower and upper
bounds.<vspace blankLines="1" />When only 'lower-port' is present, bounds.</t>
it represents a single port number. <vspace blankLines="1" />For <t>When only 'lower-port' is present,
TCP, UDP, Stream Control Transmission Protocol (SCTP) <xref it represents a single port number. </t>
target="RFC4960"></xref>, or Datagram Congestion Control Protocol <t>For TCP, UDP, Stream Control Transmission Protocol (SCTP) <xref t
(DCCP) <xref target="RFC4340"></xref>, the range of port numbers arget="RFC4960" format="default"/>,
can be, for example, 1024-65535. <vspace blankLines="1" />This is or Datagram Congestion Control Protocol (DCCP) <xref target="RFC4340
an optional attribute.</t> " format="default"/>,
the range of port numbers can be, for example, 1024-65535. </t>
<t hangText="target-protocol: ">A list of protocols. Values are <t>This is an optional attribute.</t>
taken from the IANA protocol registry <xref </dd>
target="proto_numbers"></xref>. <vspace blankLines="1" />If <dt>target-protocol: </dt>
<dd>
<t>A list of protocols. Values are
taken from the IANA protocol registry <xref target="IANA-PROTO" form
at="default"/>. </t>
<t>If
'target-protocol' is not specified, then the request applies to 'target-protocol' is not specified, then the request applies to
any protocol. <vspace blankLines="1" />This is an optional any protocol. </t>
<t>This is an optional
attribute.</t> attribute.</t>
</dd>
<t hangText="target-fqdn: ">A list of Fully Qualified Domain Names <dt>target-fqdn: </dt>
(FQDNs) identifying resources under attack <xref <dd>
target="RFC8499"></xref>.<vspace blankLines="1" />How a name is <t>A list of Fully Qualified Domain Names
passed to an underlying name resolution library is implementation- (FQDNs) identifying resources under attack <xref target="RFC8499" fo
and deployment-specific. Nevertheless, once the name is resolved rmat="default"/>.</t>
into one or multiple IP addresses, DOTS servers MUST apply the <t>How a name is
same validation checks as those for 'target-prefix'.<vspace passed to an underlying name resolution library is
blankLines="1" />The use of FQDNs may be suboptimal because it implementation and deployment specific. Nevertheless, once the name i
s resolved
into one or multiple IP addresses, DOTS servers <bcp14>MUST</bcp14>
apply the
same validation checks as those for 'target-prefix'.</t>
<t>The use of FQDNs may be suboptimal because it
does not guarantee that the DOTS server will resolve a name to the does not guarantee that the DOTS server will resolve a name to the
same IP addresses that the DOTS client does.<vspace same IP addresses that the DOTS client does.</t>
blankLines="1" />This is an optional attribute.</t> <t>This is an optional attribute.</t>
</dd>
<t hangText="target-uri: ">A list of Uniform Resource Identifiers <dt>target-uri: </dt>
(URIs) <xref target="RFC3986"></xref>. <vspace <dd>
blankLines="1" />The same validation checks used for 'target-fqdn' <t>A list of Uniform Resource Identifiers
MUST be followed by DOTS servers to validate a target URI. <vspace (URIs) <xref target="RFC3986" format="default"/>. </t>
blankLines="1" />This is an optional attribute.</t> <t>The same validation checks used for 'target-fqdn'
</list></t> <bcp14>MUST</bcp14> be followed by DOTS servers to validate a target
URI. </t>
<t>This is an optional attribute.</t>
</dd>
</dl>
<t>In POST or PUT requests, at least one of the 'target-prefix', <t>In POST or PUT requests, at least one of the 'target-prefix',
'target-fqdn', or 'target-uri' attributes MUST be present. DOTS agents 'target-fqdn', or 'target-uri' attributes <bcp14>MUST</bcp14> be present
can safely ignore Vendor-Specific parameters they don't . DOTS agents
can safely ignore vendor-specific parameters they don't
understand.</t> understand.</t>
<t>If more than one 'target-*' scope types (e.g., 'target-prefix' and <t>If more than one 'target-*' scope types (e.g., 'target-prefix' and
'target-fqdn' or 'target-fqdn' and 'target-uri') are included in a 'target-fqdn' or 'target-fqdn' and 'target-uri') are included in a
POST or PUT request, the DOTS server binds all resulting IP POST or PUT request, the DOTS server binds all resulting IP
addresses/prefixes to the same resource.</t> addresses/prefixes to the same resource.</t>
<t><xref target="Figure2" format="default"/> shows a POST request to cre
<t><xref target="Figure2"></xref> shows a POST request to create an ate an
alias called "https1" for HTTPS servers with IP addresses alias called "https1" for HTTPS servers with IP addresses
2001:db8:6401::1 and 2001:db8:6401::2 listening on TCP port number 2001:db8:6401::1 and 2001:db8:6401::2 listening on TCP port number
443.</t> 443.</t>
<figure anchor="Figure2">
<t><figure anchor="Figure2" <name>Example of a POST to Create an Alias</name>
title="Example of a POST to Create an Alias"> <sourcecode type=""><![CDATA[
<artwork align="left"><![CDATA[POST /restconf/data/ietf-dots-data-ch POST /restconf/data/ietf-dots-data-channel:dots-data\
annel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1 /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
Host: www.example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-data-channel:aliases": { "ietf-dots-data-channel:aliases": {
"alias": [ "alias": [
{ {
"name": "https1", "name": "https1",
"target-protocol": [ "target-protocol": [
6 6
], ],
skipping to change at line 2094 skipping to change at line 2015
"2001:db8:6401::2/128" "2001:db8:6401::2/128"
], ],
"target-port-range": [ "target-port-range": [
{ {
"lower-port": 443 "lower-port": 443
} }
] ]
} }
] ]
} }
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
<t>"201 Created" status-line MUST be returned in the response if the <t>A "201 Created" status-line <bcp14>MUST</bcp14> be returned in the re
sponse if the
DOTS server has accepted the alias.</t> DOTS server has accepted the alias.</t>
<t>A "409 Conflict" status-line <bcp14>MUST</bcp14> be returned to the r
<t>"409 Conflict" status-line MUST be returned to the requesting DOTS equesting DOTS
client, if the request is conflicting with an existing alias name. The client, if the request is conflicting with an existing alias name. The
error-tag "resource-denied" is used in this case.</t> error-tag "resource-denied" is used in this case.</t>
<t>If the request is missing a mandatory attribute or it contains an <t>If the request is missing a mandatory attribute or it contains an
invalid or unknown parameter, "400 Bad Request" status-line MUST be invalid or unknown parameter, a "400 Bad Request" status-line <bcp14>MUS T</bcp14> be
returned by the DOTS server. The error-tag is set to returned by the DOTS server. The error-tag is set to
"missing-attribute", "invalid-value", or "unknown-element" as a "missing-attribute", "invalid-value", or "unknown-element" as a
function of the encountered error.</t> function of the encountered error.</t>
<t>If the request is received via a server-domain DOTS gateway, but <t>If the request is received via a server-domain DOTS gateway, but
the DOTS server does not maintain a 'cdid' for this 'cuid' while a the DOTS server does not maintain a 'cdid' for this 'cuid' while a
'cdid' is expected to be supplied, the DOTS server MUST reply with 'cdid' is expected to be supplied, the DOTS server <bcp14>MUST</bcp14> r
"403 Forbidden" status-line and the error-tag "access-denied". Upon eply with
receipt of this message, the DOTS client MUST register (<xref a "403 Forbidden" status-line and the error-tag "access-denied". Upon
target="registering"></xref>).</t> receipt of this message, the DOTS client <bcp14>MUST</bcp14> register (<
xref target="registering" format="default"/>).</t>
<t>A DOTS client uses the PUT request to modify the aliases in the <t>A DOTS client uses the PUT request to modify the aliases in the
DOTS server. In particular, a DOTS client MUST update its alias DOTS server. In particular, a DOTS client <bcp14>MUST</bcp14> update its alias
entries upon change of the prefix indicated in the entries upon change of the prefix indicated in the
'target-prefix'.</t> 'target-prefix'.</t>
<t>A DOTS server <bcp14>MUST</bcp14> maintain an alias for at least 1008
<t>A DOTS server MUST maintain an alias for at least 10080 minutes (1 0 minutes (1
week). If no refresh request is seen from the DOTS client, the DOTS week). If no refresh request is seen from the DOTS client, the DOTS
server removes expired entries.</t> server removes expired entries.</t>
</section> </section>
<section anchor="ralias" numbered="true" toc="default">
<section anchor="ralias" title="Retrieve Installed Aliases"> <name>Retrieving Installed Aliases</name>
<t>A GET request is used to retrieve one or all installed aliases by a <t>A GET request is used to retrieve one or all installed aliases by a
DOTS client from a DOTS server (Section 3.3.1 in <xref DOTS client from a DOTS server (<xref target="RFC8040" section="3.3.1" s
target="RFC8040"></xref>). If no 'name' is included in the request, ectionFormat="of" format="default"/>). If no 'name' is included in the request,
this is an indication that the request is about retrieving all aliases this indicates that the request is about retrieving all aliases
instantiated by the DOTS client.</t> instantiated by the DOTS client.</t>
<t><xref target="Figure4" format="default"/> shows an example to retriev
<t><xref target="Figure4"></xref> shows an example to retrieve all the e all the
aliases that were instantiated by the requesting DOTS client. The aliases that were instantiated by the requesting DOTS client. The
"content" query parameter and its permitted values are defined in "content" query parameter and its permitted values are defined in
Section 4.8.1 of <xref target="RFC8040"></xref>.</t> <xref target="RFC8040" section="4.8.1" sectionFormat="of" format="defaul
t"/>.</t>
<figure anchor="Figure4" title="GET to Retrieve All Installed Aliases"> <figure anchor="Figure4">
<artwork align="left"><![CDATA[ GET /restconf/data/ietf-dots-data-cha <name>GET to Retrieve All Installed Aliases</name>
nnel:dots-data\ <sourcecode type=""><![CDATA[
GET /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw\ /dots-client=dz6pHjaADkaFTbjr0JGBpw\
/aliases?content=all HTTP/1.1 /aliases?content=all HTTP/1.1
Host: example.com Host: example.com
Accept: application/yang-data+json Accept: application/yang-data+json
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t><xref target="Figure6" format="default"/> shows an example of the res
<t></t> ponse
<t><xref target="Figure6"></xref> shows an example of the response
message body that includes all the aliases that are maintained by the message body that includes all the aliases that are maintained by the
DOTS server for the DOTS client identified by the 'cuid' DOTS server for the DOTS client identified by the 'cuid'
parameter.</t> parameter.</t>
<figure anchor="Figure6">
<t><figure anchor="Figure6" <name>An Example of a Response Body Listing All Installed Aliases</nam
title="An Example of Response Body Listing All Installed Aliases"> e>
<artwork align="left"><![CDATA[{ <sourcecode type=""><![CDATA[
{
"ietf-dots-data-channel:aliases": { "ietf-dots-data-channel:aliases": {
"alias": [ "alias": [
{ {
"name": "Server1", "name": "Server1",
"target-protocol": [ "target-protocol": [
6 6
], ],
"target-prefix": [ "target-prefix": [
"2001:db8:6401::1/128", "2001:db8:6401::1/128",
"2001:db8:6401::2/128" "2001:db8:6401::2/128"
skipping to change at line 2194 skipping to change at line 2105
], ],
"target-port-range": [ "target-port-range": [
{ {
"lower-port": 80 "lower-port": 80
} }
], ],
"pending-lifetime": 9869 "pending-lifetime": 9869
} }
] ]
} }
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
<t><xref target="analias"></xref> shows an example of a GET request to <t><xref target="analias" format="default"/> shows an example of a GET r
equest to
retrieve the alias "Server2" that was instantiated by the DOTS client. retrieve the alias "Server2" that was instantiated by the DOTS client.
<figure anchor="analias" title="GET to Retrieve an Alias"> </t>
<artwork align="left"><![CDATA[ GET /restconf/data/ietf-dots-data-c <figure anchor="analias">
hannel:dots-data\ <name>GET to Retrieve an Alias</name>
<sourcecode type=""><![CDATA[
GET /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw\ /dots-client=dz6pHjaADkaFTbjr0JGBpw\
/aliases/alias=Server2?content=all HTTP/1.1 /aliases/alias=Server2?content=all HTTP/1.1
Host: example.com Host: example.com
Accept: application/yang-data+json]]></artwork> Accept: application/yang-data+json
</figure></t> ]]></sourcecode>
</figure>
<t>If an alias name ('name') is included in the request, but the DOTS <t>If an alias name ('name') is included in the request, but the DOTS
server does not find that alias name for this DOTS client in its server does not find that alias name for this DOTS client in its
configuration data, it MUST respond with a "404 Not Found" configuration data, it <bcp14>MUST</bcp14> respond with a "404 Not Found "
status-line.</t> status-line.</t>
</section> </section>
<section anchor="dalias" numbered="true" toc="default">
<section anchor="dalias" title="Delete Aliases"> <name>Deleting Aliases</name>
<t>A DELETE request is used to delete an alias maintained by a DOTS <t>A DELETE request is used to delete an alias maintained by a DOTS
server.</t> server.</t>
<t>If the DOTS server does not find the alias name that was conveyed in
<t>If the DOTS server does not find the alias name, conveyed in the the
DELETE request, in its configuration data for this DOTS client, it DELETE request in its configuration data for this DOTS client, it
MUST respond with a "404 Not Found" status-line.</t> <bcp14>MUST</bcp14> respond with a "404 Not Found" status-line.</t>
<t>The DOTS server successfully acknowledges a DOTS client's request <t>The DOTS server successfully acknowledges a DOTS client's request
to remove the alias using "204 No Content" status-line in the to remove the alias using "204 No Content" status-line in the
response.</t> response.</t>
<t><xref target="Figure3" format="default"/> shows an example of a reque
<t><xref target="Figure3"></xref> shows an example of a request to st to
delete an alias.</t> delete an alias.</t>
<figure anchor="Figure3">
<t><figure anchor="Figure3" title="Delete an Alias"> <name>Delete an Alias</name>
<artwork align="left"><![CDATA[ DELETE /restconf/data/ietf-dots-dat <sourcecode type=""><![CDATA[
a-channel:dots-data\ DELETE /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw\ /dots-client=dz6pHjaADkaFTbjr0JGBpw\
/aliases/alias=Server1 HTTP/1.1 /aliases/alias=Server1 HTTP/1.1
Host: example.com]]></artwork> Host: example.com
</figure></t> ]]></sourcecode>
</figure>
</section> </section>
</section> </section>
<section anchor="filter" numbered="true" toc="default">
<section anchor="filter" title="Managing DOTS Filtering Rules"> <name>Managing DOTS Filtering Rules</name>
<t>The following sub-sections define means for a DOTS client to retrieve <t>The following subsections define the means for a DOTS client to retriev
DOTS filtering capabilities (<xref target="rcap"></xref>), create e
filtering rules (<xref target="install"></xref>), retrieve active DOTS filtering capabilities (<xref target="rcap" format="default"/>), to c
filtering rules (<xref target="rfilter"></xref>), and delete a filtering reate
rule (<xref target="dfilter"></xref>).</t> filtering rules (<xref target="install" format="default"/>), to retrieve a
ctive
<section anchor="rcap" title="Retrieve DOTS Filtering Capabilities"> filtering rules (<xref target="rfilter" format="default"/>), and to delete
<t>A DOTS client MAY send a GET request to retrieve the filtering a filtering
capabilities supported by a DOTS server. <xref target="cap"></xref> rule (<xref target="dfilter" format="default"/>).</t>
<section anchor="rcap" numbered="true" toc="default">
<name>Retrieving DOTS Filtering Capabilities</name>
<t>A DOTS client <bcp14>MAY</bcp14> send a GET request to retrieve the f
iltering
capabilities supported by a DOTS server. <xref target="cap" format="defa
ult"/>
shows an example of such request.</t> shows an example of such request.</t>
<figure anchor="cap">
<t><figure anchor="cap" <name>GET to Retrieve the Capabilities of a DOTS Server</name>
title="GET to Retrieve the Capabilities of a DOTS Server"> <sourcecode type=""><![CDATA[
<artwork align="left"><![CDATA[ GET /restconf/data/ietf-dots-data-c GET /restconf/data/ietf-dots-data-channel:dots-data\
hannel:dots-data\
/capabilities HTTP/1.1 /capabilities HTTP/1.1
Host: example.com Host: example.com
Accept: application/yang-data+json Accept: application/yang-data+json
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>A DOTS client, which issued a GET request to retrieve the filtering
<t>A DOTS client which issued a GET request to retrieve the filtering capabilities supported by its DOTS server, <bcp14>SHOULD NOT</bcp14> req
capabilities supported by its DOTS server, SHOULD NOT request for uest
filtering actions that are not supported by that DOTS server.</t> filtering actions that are not supported by that DOTS server.</t>
<t><xref target="capex" format="default"/> shows an example of a respons
<t><xref target="capex"></xref> shows an example of a response body e body
received from a DOTS server which supports:<list style="symbols"> received from a DOTS server which supports:</t>
<t>IPv4, IPv6, TCP, UDP, ICMP, and ICMPv6 mandatory match criteria <ul spacing="normal">
listed in <xref target="filf"></xref>.</t> <li>IPv4, IPv6, TCP, UDP, ICMP, and ICMPv6 mandatory match criteria
listed in <xref target="filf" format="default"/>.</li>
<t>'accept', 'drop', and 'rate-limit' actions.</t> <li>'accept', 'drop', and 'rate-limit' actions.</li>
</list></t> </ul>
<figure anchor="capex">
<t><figure anchor="capex" <name>Reply to a GET Request with Filtering Capabilities (Message Body
title="Reply to a GET Request with Filtering Capabilities (Message B )</name>
ody)"> <sourcecode type=""><![CDATA[
<artwork align="left"><![CDATA[ { {
"ietf-dots-data-channel:capabilities": { "ietf-dots-data-channel:capabilities": {
"address-family": ["ipv4", "ipv6"], "address-family": ["ipv4", "ipv6"],
"forwarding-actions": ["drop", "accept"], "forwarding-actions": ["drop", "accept"],
"rate-limit": true, "rate-limit": true,
"transport-protocols": [1, 6, 17, 58], "transport-protocols": [1, 6, 17, 58],
"ipv4": { "ipv4": {
"length": true, "length": true,
"protocol": true, "protocol": true,
"destination-prefix": true, "destination-prefix": true,
"source-prefix": true, "source-prefix": true,
skipping to change at line 2309 skipping to change at line 2220
"length": true, "length": true,
"source-port": true, "source-port": true,
"destination-port": true, "destination-port": true,
"port-range": true "port-range": true
}, },
"icmp": { "icmp": {
"type": true, "type": true,
"code": true "code": true
} }
} }
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
</section> </section>
<section anchor="install" numbered="true" toc="default">
<section anchor="install" title="Install Filtering Rules"> <name>Installing Filtering Rules</name>
<t>A POST or PUT request is used by a DOTS client to communicate <t>A POST or PUT request is used by a DOTS client to communicate
filtering rules to a DOTS server.</t> filtering rules to a DOTS server.</t>
<t><xref target="Figure7" format="default"/> shows an example of a POST
<t><xref target="Figure7"></xref> shows a POST request example to request to
block traffic from 192.0.2.0/24 and destined to 198.51.100.0/24. Other block traffic from 192.0.2.0/24 and destined to 198.51.100.0/24. Other
examples are discussed in <xref target="frag"></xref>.</t> examples are discussed in <xref target="frag" format="default"/>.</t>
<figure anchor="Figure7">
<t><figure anchor="Figure7" title="POST to Install Filtering Rules"> <name>POST to Install Filtering Rules</name>
<artwork align="left"><![CDATA[ POST /restconf/data/ietf-dots-data-c <sourcecode type=""><![CDATA[
hannel:dots-data\ POST /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1 /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [ "acl": [
{ {
"name": "sample-ipv4-acl", "name": "sample-ipv4-acl",
"type": "ipv4-acl-type", "type": "ipv4-acl-type",
skipping to change at line 2353 skipping to change at line 2265
}, },
"actions": { "actions": {
"forwarding": "drop" "forwarding": "drop"
} }
} }
] ]
} }
} }
] ]
} }
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
<t>The meaning of these parameters is as follows:</t> <t>The meaning of these parameters is as follows:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>name:</dt>
<t hangText="name:">The name of the access list. <vspace <dd>
blankLines="1" />This is a mandatory attribute.</t> <t>The name of the access list. </t>
<t>This is a mandatory attribute.</t>
<t hangText="type:">Indicates the primary intended type of match </dd>
<dt>type:</dt>
<dd>
<t>Indicates the primary intended type of match
criteria (e.g., IPv4, IPv6). It is set to 'ipv4-acl-type' in the criteria (e.g., IPv4, IPv6). It is set to 'ipv4-acl-type' in the
example of <xref target="Figure7"></xref>. <vspace example of <xref target="Figure7" format="default"/>. </t>
blankLines="1" />This is an optional attribute.</t> <t>This is an optional attribute.</t>
</dd>
<t hangText="activation-type:">Indicates whether an ACL has to be <dt>activation-type:</dt>
<dd>
<t>Indicates whether an ACL has to be
activated (immediately or during mitigation time) or instantiated activated (immediately or during mitigation time) or instantiated
without being activated (deactivated). Deactivated ACLs can be without being activated (deactivated). Deactivated ACLs can be
activated using a variety of means such as manual configuration on activated using a variety of means, such as manual configuration on
a DOTS server or using the DOTS data channel. <vspace a DOTS server or by using the DOTS data channel. </t>
blankLines="1" />If this attribute is not provided, the DOTS <t>If this attribute is not provided, the DOTS
server MUST use 'activate-when-mitigating' as default server <bcp14>MUST</bcp14> use 'activate-when-mitigating' as the def
value.<vspace blankLines="1" />When a mitigation is in progress, ault
the DOTS server MUST only activate 'activate-when-mitigating' value.</t>
<t>When a mitigation is in progress,
the DOTS server <bcp14>MUST</bcp14> only activate 'activate-when-mit
igating'
filters that are bound to the DOTS client that triggered the filters that are bound to the DOTS client that triggered the
mitigation. <vspace blankLines="1" />This is an optional mitigation. </t>
<t>This is an optional
attribute.</t> attribute.</t>
</dd>
<t hangText="matches:">Define criteria used to identify a flow on <dt>matches:</dt>
<dd>
<t>Defines criteria used to identify a flow on
which to apply the rule. It can be "l3" (IPv4, IPv6) or "l4" (TCP, which to apply the rule. It can be "l3" (IPv4, IPv6) or "l4" (TCP,
UDP, ..). The detailed match parameters are specified in <xref UDP, ICMP). The detailed match parameters are specified in <xref tar
target="YANG"></xref>.<vspace blankLines="1" />In the example get="YANG" format="default"/>.</t>
depicted in <xref target="Figure7"></xref>, an IPv4 matching <t>In the example
criteria is used.<vspace blankLines="1" />This is an optional depicted in <xref target="Figure7" format="default"/>, an IPv4 match
ing
criteria is used.</t>
<t>This is an optional
attribute.</t> attribute.</t>
</dd>
<t hangText="destination-ipv4-network:">The destination IPv4 <dt>destination-ipv4-network:</dt>
prefix. DOTS servers MUST validate that these prefixes are within <dd>
<t>The destination IPv4
prefix. DOTS servers <bcp14>MUST</bcp14> validate that these prefixe
s are within
the scope of the DOTS client domain. Other validation checks may the scope of the DOTS client domain. Other validation checks may
be supported by DOTS servers. If this attribute is not provided, be supported by DOTS servers. If this attribute is not provided,
the DOTS server enforces the ACL on any destination IP address the DOTS server enforces the ACL on any destination IP address
that belong to the DOTS client domain. <vspace that belongs to the DOTS client domain. </t>
blankLines="1" />This is a mandatory attribute in requests with an <t>This is a mandatory attribute in requests with an
'activation-type' set to 'immediate'.</t> 'activation-type' set to 'immediate'.</t>
</dd>
<t hangText="source-ipv4-network:">The source IPv4 prefix. <vspace <dt>source-ipv4-network:</dt>
blankLines="1" />This is an optional attribute.</t> <dd>
<t>The source IPv4 prefix. </t>
<t hangText="actions: ">Actions in the forwarding ACL category can <t>This is an optional attribute.</t>
be "drop" or "accept". The "accept" action is used to accept-list </dd>
traffic. The "drop" action is used to drop-list traffic. <vspace <dt>actions: </dt>
blankLines="1" />Accepted traffic may be subject to "rate-limit"; <dd>
<t>Actions in the forwarding ACL category can
be 'drop' or 'accept'. The 'accept' action is used to accept-list
traffic. The "drop" action is used to drop-list traffic. </t>
<t>Accepted traffic may be subject to 'rate-limit';
the allowed traffic rate is represented in bytes per second. This the allowed traffic rate is represented in bytes per second. This
unit is the same as the one used for "traffic-rate" in <xref unit is the same as the one used for "traffic-rate" in <xref target=
target="RFC5575"></xref>.<vspace blankLines="1" />This is a "RFC5575" format="default"/>.</t>
<t>This is a
mandatory attribute.</t> mandatory attribute.</t>
</list></t> </dd>
</dl>
<t>The DOTS server indicates the result of processing the POST request <t>The DOTS server indicates the result of processing the POST request
using the status-line. Concretely, "201 Created" status-line MUST be using the status-line. Concretely, a "201 Created" status-line <bcp14>MU ST</bcp14> be
returned in the response if the DOTS server has accepted the filtering returned in the response if the DOTS server has accepted the filtering
rules. If the request is missing a mandatory attribute or contains an rules. If the request is missing a mandatory attribute or contains an
invalid or unknown parameter (e.g., a match field not supported by the invalid or unknown parameter (e.g., a match field not supported by the
DOTS server), "400 Bad Request" status-line MUST be returned by the DOTS server), a "400 Bad Request" status-line <bcp14>MUST</bcp14> be ret urned by the
DOTS server in the response. The error-tag is set to DOTS server in the response. The error-tag is set to
"missing-attribute", "invalid-value", or "unknown-element" as a "missing-attribute", "invalid-value", or "unknown-element" as a
function of the encountered error.</t> function of the encountered error.</t>
<t>If the request is received via a server-domain DOTS gateway, but <t>If the request is received via a server-domain DOTS gateway, but
the DOTS server does not maintain a 'cdid' for this 'cuid' while a the DOTS server does not maintain a 'cdid' for this 'cuid' while a
'cdid' is expected to be supplied, the DOTS server MUST reply with 'cdid' is expected to be supplied, the DOTS server <bcp14>MUST</bcp14> r
"403 Forbidden" status-line and the error-tag "access-denied". Upon eply with
receipt of this message, the DOTS client MUST register (<xref a "403 Forbidden" status-line and the error-tag "access-denied". Upon
target="register"></xref>).</t> receipt of this message, the DOTS client <bcp14>MUST</bcp14> register (<
xref target="register" format="default"/>).</t>
<t>If the request is conflicting with an existing filtering installed <t>If the request is conflicting with an existing filtering installed
by another DOTS client of the domain, absent any local policy, the by another DOTS client of the domain, absent any local policy, the
DOTS server returns "409 Conflict" status-line to the requesting DOTS DOTS server returns a "409 Conflict" status-line to the requesting DOTS
client. The error-tag "resource-denied" is used in this case.</t> client. The error-tag "resource-denied" is used in this case.</t>
<t>The "insert" query parameter (<xref target="RFC8040" section="4.8.5"
<t>The "insert" query parameter (Section 4.8.5 of <xref sectionFormat="of" format="default"/>)
target="RFC8040"></xref>) MAY be used to specify how an access control <bcp14>MAY</bcp14> be used to specify how an access control
entry is inserted within an ACL and how an ACL is inserted within an entry is inserted within an ACL and how an ACL is inserted within an
ACL set.</t> ACL set.</t>
<t>The DOTS client uses the PUT request to modify its filtering rules <t>The DOTS client uses the PUT request to modify its filtering rules
maintained by the DOTS server. In particular, a DOTS client MUST maintained by the DOTS server. In particular, a DOTS client <bcp14>MUST<
update its filtering entries upon change of the destination-prefix. /bcp14>
update its filtering entries upon change of the destination prefix.
How such change is detected is out of scope.</t> How such change is detected is out of scope.</t>
<t>A DOTS server <bcp14>MUST</bcp14> maintain a filtering rule for at le
<t>A DOTS server MUST maintain a filtering rule for at least 10080 ast 10080
minutes (1 week). If no refresh request is seen from the DOTS client, minutes (1 week). If no refresh request is seen from the DOTS client,
the DOTS server removes expired entries. Typically, a refresh request the DOTS server removes expired entries. Typically, a refresh request
is a PUT request which echoes the content of a response to a GET is a PUT request that echoes the content of a response to a GET
request with all of the read-only parameters stripped out (e.g., request with all of the read-only parameters stripped out (e.g.,
pending-lifetime).</t> 'pending-lifetime').</t>
</section> </section>
<section anchor="rfilter" numbered="true" toc="default">
<section anchor="rfilter" title="Retrieve Installed Filtering Rules "> <name>Retrieving Installed Filtering Rules</name>
<t>A DOTS client periodically queries its DOTS server to check the <t>A DOTS client periodically queries its DOTS server to check the
counters for installed filtering rules. A GET request is used to counters for installed filtering rules. A GET request is used to
retrieve filtering rules from a DOTS server. In order to indicate retrieve filtering rules from a DOTS server. In order to indicate
which type of data is requested in a GET request, the DOTS client sets which type of data is requested in a GET request, the DOTS client sets
adequately the "content" query parameter.</t> adequately the "content" query parameter.</t>
<t>If the DOTS server does not find the access list name conveyed in <t>If the DOTS server does not find the access list name conveyed in
the GET request in its configuration data for this DOTS client, it the GET request in its configuration data for this DOTS client, it
responds with a "404 Not Found" status-line.</t> responds with a "404 Not Found" status-line.</t>
<t>In order to illustrate the intended behavior, consider the example <t>In order to illustrate the intended behavior, consider the example
depicted in <xref target="PUTv6"></xref>. In reference to this depicted in <xref target="PUTv6" format="default"/>. In reference to thi s
example, the DOTS client requests the creation of an immediate ACL example, the DOTS client requests the creation of an immediate ACL
called "test-acl-ipv6-udp".</t> called "test-acl-ipv6-udp".</t>
<figure anchor="PUTv6">
<t><figure anchor="PUTv6" <name>Example of a PUT Request to Create a Filtering</name>
title="Example of a PUT Request to Create a Filtering"> <sourcecode type=""><![CDATA[
<artwork align="left"><![CDATA[PUT /restconf/data/ietf-dots-data-cha PUT /restconf/data/ietf-dots-data-channel:dots-data\
nnel:dots-data\
/dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
/acl=test-acl-ipv6-udp HTTP/1.1 /acl=test-acl-ipv6-udp HTTP/1.1
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [ "acl": [
{ {
"name": "test-acl-ipv6-udp", "name": "test-acl-ipv6-udp",
skipping to change at line 2493 skipping to change at line 2413
{ {
"name": "my-test-ace", "name": "my-test-ace",
"matches": { "matches": {
"ipv6": { "ipv6": {
"destination-ipv6-network": "2001:db8:6401::2/127", "destination-ipv6-network": "2001:db8:6401::2/127",
"source-ipv6-network": "2001:db8:1234::/96", "source-ipv6-network": "2001:db8:1234::/96",
"protocol": 17, "protocol": 17,
"flow-label": 10000 "flow-label": 10000
}, },
"udp": { "udp": {
"source-port": { "source-port-range-or-operator": {
"operator": "lte", "operator": "lte",
"port": 80 "port": 80
}, },
"destination-port": { "destination-port-range-or-operator": {
"operator": "neq", "operator": "neq",
"port": 1010 "port": 1010
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
} }
] ]
} }
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
<t>The peer DOTS server follows the procedure specified in <xref <t>The peer DOTS server follows the procedure specified in
target="install"></xref> to process the request. We consider in the <xref target="install" format="default"/> to process the request. We con
sider in the
following that a positive response is sent back to the requesting DOTS following that a positive response is sent back to the requesting DOTS
client to confirm that the "test-acl-ipv6-udp" ACL is successfully client to confirm that the "test-acl-ipv6-udp" ACL is successfully
installed by the DOTS server.</t> installed by the DOTS server.</t>
<t>The DOTS client can issue a GET request to retrieve all its <t>The DOTS client can issue a GET request to retrieve all its
filtering rules and the number of matches for the installed filtering filtering rules and the number of matches for the installed filtering
rules as illustrated in <xref target="Get"></xref>. The "content" rules as illustrated in <xref target="Get" format="default"/>. The "cont ent"
query parameter is set to 'all'. The message body of the response to query parameter is set to 'all'. The message body of the response to
this GET request is shown in <xref target="Getr"></xref>.</t> this GET request is shown in <xref target="Getr" format="default"/>.</t>
<figure anchor="Get">
<figure anchor="Get" <name>Retrieve the Configuration Data and State Data for the Filtering
title="Retrieve the Configuration Data and State Data for the Fi Rules (GET Request)</name>
ltering Rules (GET Request)"> <sourcecode type=""><![CDATA[
<artwork align="left"><![CDATA[ GET /restconf/data/ietf-dots-data-cha GET /restconf/data/ietf-dots-data-channel:dots-data\
nnel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw\ /dots-client=dz6pHjaADkaFTbjr0JGBpw\
/acls?content=all HTTP/1.1 /acls?content=all HTTP/1.1
Host: example.com Host: example.com
Accept: application/yang-data+json Accept: application/yang-data+json
]]></artwork> ]]></sourcecode>
</figure> </figure>
<figure anchor="Getr">
<t></t> <name>Retrieve the Configuration Data and State Data for the Filtering
Rules (Response Message Body)</name>
<t><figure anchor="Getr" <sourcecode type=""><![CDATA[
title="Retrieve the Configuration Data and State Data for the Filter {
ing Rules (Response Message Body)">
<artwork align="left"><![CDATA[{
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [ "acl": [
{ {
"name": "test-acl-ipv6-udp", "name": "test-acl-ipv6-udp",
"type": "ipv6-acl-type", "type": "ipv6-acl-type",
"activation-type": "immediate", "activation-type": "immediate",
"pending-lifetime":9080, "pending-lifetime":9080,
"aces": { "aces": {
"ace": [ "ace": [
{ {
"name": "my-test-ace", "name": "my-test-ace",
"matches": { "matches": {
"ipv6": { "ipv6": {
"destination-ipv6-network": "2001:db8:6401::2/127", "destination-ipv6-network": "2001:db8:6401::2/127",
"source-ipv6-network": "2001:db8:1234::/96", "source-ipv6-network": "2001:db8:1234::/96",
"protocol": 17, "protocol": 17,
"flow-label": 10000 "flow-label": 10000
}, },
"udp": { "udp": {
"source-port": { "source-port-range-or-operator": {
"operator": "lte", "operator": "lte",
"port": 80 "port": 80
}, },
"destination-port": { "destination-port-range-or-operator": {
"operator": "neq", "operator": "neq",
"port": 1010 "port": 1010
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
} }
] ]
} }
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
<t>Also, a DOTS client can issue a GET request to retrieve only <t>Also, a DOTS client can issue a GET request to retrieve only
configuration data related to an ACL as shown in <xref configuration data related to an ACL as shown in <xref target="GEtc" for
target="GEtc"></xref>. It does so by setting the "content" query mat="default"/>. It does so by setting the "content" query
parameter to 'config'.</t> parameter to 'config'.</t>
<figure anchor="GEtc">
<t><figure anchor="GEtc" <name>Retrieve the Configuration Data for a Filtering Rule (GET Reques
title="Retrieve the Configuration Data for a Filtering Rule (GET Req t)</name>
uest)"> <sourcecode type=""><![CDATA[
<artwork align="left"><![CDATA[ GET /restconf/data/ietf-dots-data-c GET /restconf/data/ietf-dots-data-channel:dots-data\
hannel:dots-data\
/dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
/acl=test-acl-ipv6-udp?content=config HTTP/1.1 /acl=test-acl-ipv6-udp?content=config HTTP/1.1
Host: example.com Host: example.com
Accept: application/yang-data+json]]></artwork> Accept: application/yang-data+json
</figure></t> ]]></sourcecode>
</figure>
<t>A response to this GET request is shown in <xref <t>A response to this GET request is shown in <xref target="GEtcr" forma
target="GEtcr"></xref>.</t> t="default"/>.</t>
<figure anchor="GEtcr">
<t><figure anchor="GEtcr" <name>Retrieve the Configuration Data for a Filtering Rule (Response M
title="Retrieve the Configuration Data for a Filtering Rule (Respons essage Body)</name>
e Message Body)"> <sourcecode type=""><![CDATA[
<artwork align="left"><![CDATA[{ {
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [ "acl": [
{ {
"name": "test-acl-ipv6-udp", "name": "test-acl-ipv6-udp",
"type": "ipv6-acl-type", "type": "ipv6-acl-type",
"activation-type": "immediate", "activation-type": "immediate",
"aces": { "aces": {
"ace": [ "ace": [
{ {
"name": "my-test-ace", "name": "my-test-ace",
"matches": { "matches": {
"ipv6": { "ipv6": {
"destination-ipv6-network": "2001:db8:6401::2/127", "destination-ipv6-network": "2001:db8:6401::2/127",
"source-ipv6-network": "2001:db8:1234::/96", "source-ipv6-network": "2001:db8:1234::/96",
"protocol": 17, "protocol": 17,
"flow-label": 10000 "flow-label": 10000
}, },
"udp": { "udp": {
"source-port": { "source-port-range-or-operator": {
"operator": "lte", "operator": "lte",
"port": 80 "port": 80
}, },
"destination-port": { "destination-port-range-or-operator": {
"operator": "neq", "operator": "neq",
"port": 1010 "port": 1010
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
} }
] ]
} }
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
<t>A DOTS client can also issue a GET request with a "content" query <t>A DOTS client can also issue a GET request with a "content" query
parameter set to 'non-config' to exclusively retrieve parameter set to 'non-config' to exclusively retrieve
non-configuration data bound to a given ACL as shown in <xref non-configuration data bound to a given ACL as shown in <xref target="GE
target="GEtnc"></xref>. A response to this GET request is shown in tnc" format="default"/>. A response to this GET request is shown in
<xref target="GEtncr"></xref>.</t> <xref target="GEtncr" format="default"/>.</t>
<figure anchor="GEtnc">
<t><figure anchor="GEtnc" <name>Retrieve the Non-Configuration Data for a Filtering Rule (GET Re
title="Retrieve the Non-Configuration Data for a Filtering Rule (GET quest)</name>
Request)"> <sourcecode type=""><![CDATA[
<artwork align="left"><![CDATA[ GET /restconf/data/ietf-dots-data-c GET /restconf/data/ietf-dots-data-channel:dots-data\
hannel:dots-data\
/dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
/acl=test-acl-ipv6-udp?content=non-config HTTP/1.1 /acl=test-acl-ipv6-udp?content=non-config HTTP/1.1
Host: example.com Host: example.com
Accept: application/yang-data+json]]></artwork> Accept: application/yang-data+json
</figure></t> ]]></sourcecode>
</figure>
<t><figure anchor="GEtncr" <figure anchor="GEtncr">
title="Retrieve the Non-Configuration Data for a Filtering Rule (Res <name>Retrieve the Non-Configuration Data for a Filtering Rule (Respon
ponse Message Body)"> se Message Body)</name>
<artwork align="left"><![CDATA[{ <sourcecode type=""><![CDATA[
{
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [ "acl": [
{ {
"name": "test-acl-ipv6-udp", "name": "test-acl-ipv6-udp",
"pending-lifetime": 8000, "pending-lifetime": 8000,
"aces": { "aces": {
"ace": [ "ace": [
{ {
"name": "my-test-ace" "name": "my-test-ace"
} }
] ]
} }
} }
] ]
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
</section> </section>
<section anchor="dfilter" numbered="true" toc="default">
<section anchor="dfilter" title="Remove Filtering Rules"> <name>Removing Filtering Rules</name>
<t>A DELETE request is used by a DOTS client to delete filtering rules <t>A DELETE request is used by a DOTS client to delete filtering rules
from a DOTS server.</t> from a DOTS server.</t>
<t>If the DOTS server does not find the access list name carried in <t>If the DOTS server does not find the access list name carried in
the DELETE request in its configuration data for this DOTS client, it the DELETE request in its configuration data for this DOTS client, it
MUST respond with a "404 Not Found" status-line. The DOTS server <bcp14>MUST</bcp14> respond with a "404 Not Found" status-line. The DOTS server
successfully acknowledges a DOTS client's request to withdraw the successfully acknowledges a DOTS client's request to withdraw the
filtering rules using "204 No Content" status-line, and removes the filtering rules using a "204 No Content" status-line, and removes the
filtering rules accordingly.</t> filtering rules accordingly.</t>
<t><xref target="Figure9" format="default"/> shows an example of a reque
<t><xref target="Figure9"></xref> shows an example of a request to st to
remove the IPv4 ACL "sample-ipv4-acl" created in <xref remove the IPv4 ACL "sample-ipv4-acl" created in <xref target="install"
target="install"></xref>.</t> format="default"/>.</t>
<figure anchor="Figure9">
<figure anchor="Figure9" <name>Remove a Filtering Rule (DELETE Request)</name>
title="Remove a Filtering Rule (DELETE Request)"> <sourcecode type=""><![CDATA[
<artwork align="left"><![CDATA[ DELETE /restconf/data/ietf-dots-data DELETE /restconf/data/ietf-dots-data-channel:dots-data\
-channel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw/acls\ /dots-client=dz6pHjaADkaFTbjr0JGBpw/acls\
/acl=sample-ipv4-acl HTTP/1.1 /acl=sample-ipv4-acl HTTP/1.1
Host: example.com]]></artwork> Host: example.com]]>
</sourcecode>
</figure> </figure>
<t/>
<t></t> <t><xref target="Figure9a" format="default"/> shows an example of a resp
onse
<t><xref target="Figure9a"></xref> shows an example of a response
received from the DOTS server to confirm the deletion of received from the DOTS server to confirm the deletion of
"sample-ipv4-acl".</t> "sample-ipv4-acl".</t>
<figure anchor="Figure9a">
<t><figure anchor="Figure9a" <name>Remove a Filtering Rule (Response)</name>
title="Remove a Filtering Rule (Response)"> <sourcecode type=""><![CDATA[
<artwork align="left"><![CDATA[ HTTP/1.1 204 No Content HTTP/1.1 204 No Content
Server: Apache Server: Apache
Date: Fri, 27 Jul 2018 10:05:15 GMT Date: Fri, 27 Jul 2018 10:05:15 GMT
Cache-Control: no-cache Cache-Control: no-cache
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
Content-Length: 0 Content-Length: 0
Connection: Keep-Alive]]></artwork> Connection: Keep-Alive
</figure></t> ]]></sourcecode>
</figure>
</section> </section>
</section> </section>
<section anchor="operational" numbered="true" toc="default">
<section anchor="operational" title="Operational Considerations"> <name>Operational Considerations</name>
<t>The following operational considerations should be taken into <t>The following operational considerations should be taken into
account:</t> account:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>DOTS servers <bcp14>MUST NOT</bcp14> enable both DOTS data channel a
<t>DOTS servers MUST NOT enable both DOTS data channel and direct nd direct
configuration, to avoid race conditions and inconsistent configuration, to avoid race conditions and inconsistent
configurations arising from simultaneous updates from multiple configurations arising from simultaneous updates from multiple
sources.</t> sources.</li>
<li>DOTS agents <bcp14>SHOULD</bcp14> enable the DOTS data channel to co
<t>DOTS agents SHOULD enable the DOTS data channel to configure nfigure
aliases and ACLs, and only use direct configuration as a stop-gap aliases and ACLs, and only use direct configuration as a stop-gap
mechanism to test DOTS signal channel with aliases and ACLs. mechanism to test DOTS signal channel with aliases and ACLs.
Further, direct configuration SHOULD only be used when the on-path Further, direct configuration <bcp14>SHOULD</bcp14> only be used when
DOTS agents are within the same domain.</t> the on-path
DOTS agents are within the same domain.</li>
<t>If a DOTS server has enabled direct configuration, it can reject <li>If a DOTS server has enabled direct configuration, it can reject
the DOTS data channel connection using hard ICMP error <xref the DOTS data channel connection using hard ICMP error <xref target="R
target="RFC1122"></xref> or RST (Reset) bit in the TCP header or FC1122" format="default"/> or RST (Reset) bit in the TCP header or
reject the RESTCONF request using an error response containing a reject the RESTCONF request using an error response containing a
"503 Service Unavailable" status-line.</t> "503 Service Unavailable" status-line.</li>
</list></t> </ul>
</section> </section>
<section title="IANA Considerations"> <section numbered="true" toc="default">
<t>This document requests IANA to register the following URI in the "ns" <name>IANA Considerations</name>
subregistry within the "IETF XML Registry" <xref <t>IANA has registered the following URI in the "ns"
target="RFC3688"></xref>: <figure> subregistry within the "IETF XML Registry" <xref target="RFC3688" format="
<artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-dots- default"/>: </t>
data-channel <dl newline="false" spacing="compact">
Registrant Contact: The IESG. <dt>ID:</dt> <dd>yang:ietf-dots-data-channel</dd>
XML: N/A; the requested URI is an XML namespace. <dt>URI:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-dots-data-cha
]]></artwork> nnel</dd>
</figure> This document requests IANA to register the following YANG <dt>Registrant Contact:</dt> <dd>The IESG.</dd>
module in the "YANG Module Names" subregistry <xref <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd
target="RFC7950"></xref> within the "YANG Parameters" registry.<figure> >
<artwork><![CDATA[ Name: ietf-dots-data-channel <dt>Reference: </dt><dd>RFC 8783</dd>
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-data-channel </dl>
Prefix: data-channel <t>IANA has registered the following YANG
Reference: RFC XXXX]]></artwork> module in the "YANG Module Names" subregistry <xref target="RFC7950" forma
</figure></t> t="default"/>
within the "YANG Parameters" registry.</t>
<dl newline="false" spacing="compact">
<dt>Name:</dt><dd>ietf-dots-data-channel</dd>
<dt>Namespace: </dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-data-channel</d
d>
<dt>Prefix: </dt><dd>data-channel</dd>
<dt>Reference: </dt><dd>RFC 8783</dd>
</dl>
<t>This module is not maintained by IANA.</t> <t>This module is not maintained by IANA.</t>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<section anchor="security" title="Security Considerations"> <name>Security Considerations</name>
<t>RESTCONF security considerations are discussed in <xref <t>RESTCONF security considerations are discussed in <xref target="RFC8040
target="RFC8040"></xref>. In particular, DOTS agents MUST follow the " format="default"/>.
security recommendations in Sections 2 and 12 of <xref In particular, DOTS agents <bcp14>MUST</bcp14> follow the
target="RFC8040"></xref>. Also, DOTS agents MUST support the mutual security recommendations in Sections <xref target="RFC8040" section="2" se
authentication TLS profile discussed in Sections 7.1 and 8 of <xref ctionFormat="bare" format="default"/> and
target="I-D.ietf-dots-signal-channel"></xref>.</t> <xref target="RFC8040" section="12" sectionFormat="bare" format="default"/
>
<t>Authenticated encryption MUST be used for data confidentiality and of <xref target="RFC8040" format="default"/>.
Also, DOTS agents <bcp14>MUST</bcp14> support the mutual
authentication TLS profile discussed in
Sections <xref target="RFC8782" section="7.1" sectionFormat="bare" format=
"default"/> and
<xref target="RFC8782" section="8" sectionFormat="bare" format="default"/>
of <xref target="RFC8782" format="default"/>.</t>
<t>Authenticated encryption <bcp14>MUST</bcp14> be used for data confident
iality and
message integrity. The interaction between the DOTS agents requires message integrity. The interaction between the DOTS agents requires
Transport Layer Security (TLS) with a cipher suite offering Transport Layer Security (TLS) with a cipher suite offering
confidentiality protection and the guidance given in <xref confidentiality protection, and the guidance given in <xref target="RFC752
target="RFC7525"></xref> MUST be followed to avoid attacks on TLS.</t> 5" format="default"/>
<bcp14>MUST</bcp14> be followed to avoid attacks on TLS.</t>
<t>The installation of drop- or accept-list rules using RESTCONF over <t>The installation of drop-list or accept-list rules using RESTCONF over
TLS reveals the attacker IP addresses and legitimate IP addresses only TLS reveals the attacker IP addresses and legitimate IP addresses only
to the DOTS server trusted by the DOTS client. The secure communication to the DOTS server trusted by the DOTS client. The secure communication
channel between DOTS agents provides privacy and prevents a network channel between DOTS agents provides privacy and prevents a network
eavesdropper from directly gaining access to the drop- and accept-listed eavesdropper from directly gaining access to the drop-listed and accept-li sted
IP addresses.</t> IP addresses.</t>
<t>An attacker may be able to inject RST packets, bogus application <t>An attacker may be able to inject RST packets, bogus application
segments, etc., regardless of whether TLS authentication is used. segments, etc., regardless of whether TLS authentication is used.
Because the application data is TLS protected, this will not result in Because the application data is TLS protected, this will not result in
the application receiving bogus data, but it will constitute a DoS on the application receiving bogus data, but it will constitute a DoS on
the connection. This attack can be countered by using TCP-AO <xref the connection. This attack can be countered by using
target="RFC5925"></xref>. If TCP-AO is used, then any bogus packets TCP Authentication Option (TCP-AO) <xref target="RFC5925" format="default"
/>. If TCP-AO is used, then any bogus packets
injected by an attacker will be rejected by the TCP-AO integrity check injected by an attacker will be rejected by the TCP-AO integrity check
and therefore will never reach the TLS layer.</t> and therefore will never reach the TLS layer.</t>
<t>In order to prevent leaking internal information outside a <t>In order to prevent leaking internal information outside a
client-domain, client-side DOTS gateways SHOULD NOT reveal the identity client domain, client-side DOTS gateways <bcp14>SHOULD NOT</bcp14> reveal the identity
of internal DOTS clients (e.g., source IP address, client's hostname) of internal DOTS clients (e.g., source IP address, client's hostname)
unless explicitly configured to do so.</t> unless explicitly configured to do so.</t>
<t>DOTS servers <bcp14>MUST</bcp14> verify that requesting DOTS clients ar
<t>DOTS servers MUST verify that requesting DOTS clients are entitled to e entitled to
enforce filtering rules on a given IP prefix. That is, only filtering enforce filtering rules on a given IP prefix. That is, only filtering
rules on IP resources that belong to the DOTS client domain can be rules on IP resources that belong to the DOTS client domain can be
authorized by a DOTS server. The exact mechanism for the DOTS servers to authorized by a DOTS server. The exact mechanism for the DOTS servers to
validate that the target prefixes are within the scope of the DOTS validate that the target prefixes are within the scope of the DOTS
client domain is deployment-specific.</t> client domain is deployment specific.</t>
<t>Rate-limiting DOTS requests, including those with new 'cuid' values, <t>Rate-limiting DOTS requests, including those with new 'cuid' values,
from the same DOTS client defends against DoS attacks that would result from the same DOTS client defends against DoS attacks that would result
from varying the 'cuid' to exhaust DOTS server resources. Rate-limit from varying the 'cuid' to exhaust DOTS server resources. Rate-limit
policies SHOULD be enforced on DOTS gateways (if deployed) and DOTS policies <bcp14>SHOULD</bcp14> be enforced on DOTS gateways (if deployed) and DOTS
servers.</t> servers.</t>
<t>Applying resources quota per DOTS client and/or per DOTS client <t>Applying resources quota per DOTS client and/or per DOTS client
domain (e.g., limit the number of aliases and filters to be installed by domain (e.g., limiting the number of aliases and filters to be installed b
DOTS clients) prevents DOTS server resources to be aggressively used by y
some DOTS clients and ensures, therefore, DDoS mitigation usage DOTS clients) prevents DOTS server resources from being aggressively used
by
some DOTS clients and therefore ensures DDoS mitigation usage
fairness. Additionally, DOTS servers may limit the number of DOTS fairness. Additionally, DOTS servers may limit the number of DOTS
clients that can be enabled per domain.</t> clients that can be enabled per domain.</t>
<t>When FQDNs are used as targets, the DOTS server <bcp14>MUST</bcp14> rel
<t>When FQDNs are used as targets, the DOTS server MUST rely upon DNS y upon DNS
privacy enabling protocols (e.g., DNS over TLS <xref privacy enabling protocols (e.g., DNS over TLS <xref target="RFC7858" form
target="RFC7858"></xref> or DoH <xref target="RFC8484"></xref>) to at="default"/>
or DNS over HTTPS (DoH) <xref target="RFC8484" format="default"/>) to
prevent eavesdroppers from possibly identifying the target resources prevent eavesdroppers from possibly identifying the target resources
protected by the DDoS mitigation service, and means to ensure the target protected by the DDoS mitigation service, and means to ensure the target
FQDN resolution is authentic (e.g., DNSSEC <xref FQDN resolution is authentic (e.g., DNSSEC <xref target="RFC4034" format="
target="RFC4034"></xref>).</t> default"/>).</t>
<t>The presence of DOTS gateways may lead to infinite forwarding loops, <t>The presence of DOTS gateways may lead to infinite forwarding loops,
which is undesirable. To prevent and detect such loops, a mechanism is which is undesirable. To prevent and detect such loops, a mechanism is
defined in <xref target="loops"></xref>.</t> defined in <xref target="loops" format="default"/>.</t>
<t>
<t>All data nodes defined in the YANG module which can be created, The YANG module specified in this document defines a schema for data
modified, and deleted (i.e., config true, which is the default) are that is designed to be accessed via network management protocols such
considered sensitive. Write operations applied to these data nodes as NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>.
without proper protection can negatively affect network operations. This The lowest NETCONF layer is the secure transport layer, and the
module reuses YANG structures from <xref target="RFC8519"></xref>, and mandatory-to-implement secure transport is Secure Shell (SSH)
the security considerations for those nodes continue to apply for this <xref target="RFC6242"/>. The lowest RESTCONF layer is HTTPS, and the
usage. Appropriate security measures are recommended to prevent mandatory-to-implement secure transport is TLS <xref target="RFC8446"/>.
illegitimate users from invoking DOTS data channel primitives. </t>
Nevertheless, an attacker who can access a DOTS client is technically <t>
capable of launching various attacks, such as:<list style="symbols"> The Network Configuration Access Control Model (NACM) <xref target="RFC8341"/>
<t>Setting an arbitrarily low rate-limit, which may prevent provides the means to restrict access for particular NETCONF or RESTCONF users
legitimate traffic from being forwarded (rate-limit).</t> to a preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
<t>Setting an arbitrarily high rate-limit, which may lead to the </t>
forwarding of illegitimate DDoS traffic (rate-limit).</t>
<t>Communicating invalid aliases to the server (alias), which will
cause the failure of associating both data and signal channels.</t>
<t>Setting invalid ACL entries, which may prevent legitimate traffic <t>
There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the default).
These data nodes may be considered sensitive or vulnerable in some network
environments. Write operations (e.g., edit-config) to these data nodes
without proper protection can have a negative effect on network operations.
The DOTS data channel is responsible for exchanging configuration data
that affect traffic filtering during DDoS attack mitigation, in particular.
Appropriate security measures are recommended to prevent illegitimate users fr
om
invoking DOTS data channel primitives on writable data nodes.
Nevertheless, an attacker who can access a DOTS client is technically
capable of launching various attacks, such as:
</t>
<ul spacing="normal">
<li>Setting an arbitrarily low rate-limit, which may prevent
legitimate traffic from being forwarded (rate-limit).</li>
<li>Setting an arbitrarily high rate-limit, which may lead to the
forwarding of illegitimate DDoS traffic (rate-limit).</li>
<li>Communicating invalid aliases to the server (alias), which will
cause the failure of associating both data and signal channels.</li>
<li>Setting invalid ACL entries, which may prevent legitimate traffic
from being forwarded. Likewise, invalid ACL entries may lead to from being forwarded. Likewise, invalid ACL entries may lead to
forward DDoS traffic.</t> forward DDoS traffic.</li>
</list></t> </ul>
</section> <t>
This module reuses YANG structures from <xref target="RFC8519"/>, and the secu
<section title="Contributing Authors"> rity
<t>The following individuals co-authored this document:</t> considerations for those nodes continue to apply for this usage.
</t>
<t><figure>
<artwork><![CDATA[ Kaname Nishizuka
NTT Communications
GranPark 16F 3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
Email: kaname@nttv6.jp
Liang Xia
Huawei
101 Software Avenue, Yuhuatai District
Nanjing, Jiangsu 210012
China
Email: frank.xialiang@huawei.com
Prashanth Patil
Cisco Systems, Inc.
Email: praspati@cisco.com
Andrew Mortensen
Arbor Networks, Inc.
2727 S. State St
Ann Arbor, MI 48104
United States
Email: andrew.mortensen@netscout.com
Nik Teague
Iron Mountain Data Centers
United Kingdom
Email: nteague@ironmountain.co.uk]]></artwork>
</figure></t>
</section>
<section anchor="contr" title="Contributors">
<t>The following individuals have contributed to this document:<list
style="symbols">
<t>Dan Wing, Email: dwing-ietf@fuggles.com</t>
<t>Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.com</t>
</list></t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, Ehud
Doron, Russ White, Gilbert Clark, Kathleen Moriarty, Nesredien Suleiman,
Roni Even, and Brian Trammel for the discussion and comments.</t>
<t>The authors would like to give special thanks to Kaname Nishizuka and
Jon Shallow for their efforts in implementing the protocol and
performing interop testing at IETF Hackathons.</t>
<t>Many thanks to Ben Kaduk for the detailed AD review.</t>
<t>Thanks to Martin Bjorklund for the guidance on RESTCONF.</t>
<t>Thanks to Alexey Melnikov, Adam Roach, Suresh Krishnan, Mirja
K&uuml;hlewind, and Warren Kumari for the review.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-dots-architecture" to="DOTS-ARCH"/>
<?rfc include="reference.RFC.2119"?> <displayreference target="I-D.ietf-dots-server-discovery" to="DOTS-SERVER-DI
SC"/>
<?rfc include="reference.RFC.7525"?> <displayreference target="I-D.ietf-netconf-restconf-client-server" to="RESTC
ONF-MODELS"/>
<?rfc include="reference.RFC.8040"?> <references>
<name>References</name>
<?rfc include="reference.RFC.8519"?> <references>
<name>Normative References</name>
<?rfc include="reference.I-D.ietf-dots-signal-channel"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<?rfc include="reference.RFC.7951"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7525.xml"/>
<?rfc include='reference.RFC.3688'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8040.xml"/>
<?rfc include='reference.RFC.8174'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8519.xml"/>
<?rfc include='reference.RFC.4632'?> <reference anchor="RFC8782" target="https://www.rfc-editor.org/info/rfc8
782">
<?rfc include='reference.RFC.6991'?> <front>
<title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Si
<?rfc include='reference.RFC.7230'?> gnal Channel Specification</title>
<author initials="T" surname="Reddy.K" fullname="Tirumaleswar Reddy.
<?rfc include="reference.RFC.7950"?> K" role="editor">
<organization/>
<?rfc include="reference.RFC.8259"?> </author>
<author initials="M" surname="Boucadair" fullname="Mohamed Boucadair
<?rfc include='reference.RFC.6125'?> " role="editor">
</references> <organization/>
</author>
<references title="Informative References"> <author initials="P" surname="Patil" fullname="Prashanth Patil">
<?rfc include='reference.RFC.1122'?> <organization/>
</author>
<?rfc include="reference.I-D.ietf-dots-architecture"?> <author initials="A" surname="Mortensen" fullname="Andrew Mortensen"
>
<?rfc include='reference.RFC.8499'?> <organization/>
</author>
<?rfc include='reference.RFC.4034'?> <author initials="N" surname="Teague" fullname="Nik Teague">
<organization/>
<?rfc include='reference.RFC.7858'?> </author>
<date month="May" year="2020"/>
<?rfc include='reference.RFC.8484'?> </front>
<seriesInfo name="RFC" value="8782"/>
<?rfc include='reference.RFC.4340'?> <seriesInfo name="DOI" value="10.17487/RFC8782"/>
</reference>
<?rfc include="reference.RFC.5925"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7951.xml"/>
<?rfc include="reference.RFC.6520"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3688.xml"/>
<?rfc include='reference.RFC.3986'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<?rfc include='reference.RFC.4960'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4632.xml"/>
<?rfc include="reference.RFC.8612"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6991.xml"/>
<?rfc include='reference.RFC.8340'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7230.xml"/>
<?rfc include='reference.RFC.5575'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7950.xml"/>
<?rfc include='reference.I-D.ietf-dots-server-discovery'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8259.xml"/>
<?rfc include='reference.I-D.ietf-netconf-restconf-client-server'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6125.xml"/>
<reference anchor="proto_numbers" <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
target="http://www.iana.org/assignments/protocol-numbers"> FC.8446.xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<title>IANA, "Protocol Numbers"</title> FC.6241.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author> FC.6242.xml"/>
<organization></organization> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</author> FC.8341.xml"/>
</references>
<date year="2011" /> <references>
</front> <name>Informative References</name>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1122.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.ietf-dots-architecture.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8499.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4034.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7858.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8484.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5925.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6520.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4960.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8612.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5575.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.ietf-dots-server-discovery.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.ietf-netconf-restconf-client-server.xml"/>
<reference anchor="IANA-PROTO" target="http://www.iana.org/assignments/p
rotocol-numbers">
<front>
<title>Protocol Numbers</title>
<author>
<organization>IANA</organization>
</author>
<date></date>
</front>
</reference>
</references>
</references> </references>
<section anchor="frag" numbered="true" toc="default">
<section anchor="frag" title="Sample Examples: Filtering Fragments"> <name>Examples: Filtering Fragments</name>
<t>This specification strongly recommends the use of "fragment" for <t>This specification strongly recommends the use of 'fragment' for
handling fragments.</t> handling fragments.</t>
<t><xref target="fragdnsv4" format="default"/> shows the content of the PO
<t><xref target="fragdnsv4"></xref> shows the content of the POST ST
request to be issued by a DOTS client to its DOTS server to allow the request to be issued by a DOTS client to its DOTS server to allow the
traffic destined to 198.51.100.0/24 and UDP port number 53, but to drop traffic destined to 198.51.100.0/24 and UDP port number 53, but to drop
all fragmented packets. The following ACEs are defined (in this all fragmented packets. The following ACEs are defined (in this
order):</t> order):</t>
<ul spacing="normal">
<li>"drop-all-fragments" ACE: discards all fragments.</li>
<li>"allow-dns-packets" ACE: accepts DNS packets destined to
198.51.100.0/24.</li>
</ul>
<figure anchor="fragdnsv4">
<name>Filtering IPv4 Fragmented Packets</name>
<sourcecode type=""><![CDATA[
POST /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
<t><list style="symbols"> {
<t>"drop-all-fragments" ACE: discards all fragments.</t>
<t>"allow-dns-packets" ACE: accepts DNS packets destined to
198.51.100.0/24.</t>
</list></t>
<t><figure anchor="fragdnsv4" title="Filtering IPv4 Fragmented Packets">
<artwork align="left"><![CDATA[ POST /restconf/data/ietf-dots-data-cha
nnel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [ "acl": [
{ {
"name": "dns-fragments", "name": "dns-fragments",
"type": "ipv4-acl-type", "type": "ipv4-acl-type",
"aces": { "aces": {
"ace": [ "ace": [
{ {
"name": "drop-all-fragments", "name": "drop-all-fragments",
"matches": { "matches": {
"ipv4": { "ipv4": {
"fragment": { "fragment": {
"operator": "match", "operator": "match",
"type": "isf" "type": "isf"
} }
} }
}, },
"actions": { "actions": {
"forwarding": "drop" "forwarding": "drop"
} }
} },
]
"ace": [
{ {
"name": "allow-dns-packets", "name": "allow-dns-packets",
"matches": { "matches": {
"ipv4": { "ipv4": {
"destination-ipv4-network": "198.51.100.0/24" "destination-ipv4-network": "198.51.100.0/24"
} },
"udp": { "udp": {
"destination-port": { "destination-port-range-or-operator": {
"operator": "eq", "operator": "eq",
"port": 53 "port": 53
}
},
"actions": {
"forwarding": "accept"
} }
},
"actions": {
"forwarding": "accept"
} }
} }
] ]
} }
} }
] ]
} }
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
<t><xref target="fragdnsv6"></xref> shows a POST request example issued <t><xref target="fragdnsv6" format="default"/> shows an example of a POST
request issued
by a DOTS client to its DOTS server to allow the traffic destined to by a DOTS client to its DOTS server to allow the traffic destined to
2001:db8::/32 and UDP port number 53, but to drop all fragmented 2001:db8::/32 and UDP port number 53, but to drop all fragmented
packets. The following ACEs are defined (in this order):</t> packets. The following ACEs are defined (in this order):</t>
<ul spacing="normal">
<li>"drop-all-fragments" ACE: discards all fragments (including
atomic fragments). That is, IPv6 packets that include a Fragment
header (44) are dropped.</li>
<li>"allow-dns-packets" ACE: accepts DNS packets destined to
2001:db8::/32.</li>
</ul>
<figure anchor="fragdnsv6">
<name>Filtering IPv6 Fragmented Packets</name>
<sourcecode type=""><![CDATA[
POST /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
<t><list style="symbols"> {
<t>"drop-all-fragments" ACE: discards all fragments (including
atomic fragments). That is, IPv6 packets which include a Fragment
header (44) are dropped.</t>
<t>"allow-dns-packets" ACE: accepts DNS packets destined to
2001:db8::/32.</t>
</list></t>
<t><figure anchor="fragdnsv6" title="Filtering IPv6 Fragmented Packets">
<artwork align="left"><![CDATA[ POST /restconf/data/ietf-dots-data-cha
nnel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [ "acl": [
{ {
"name": "dns-fragments", "name": "dns-fragments",
"type": "ipv6-acl-type", "type": "ipv6-acl-type",
"aces": { "aces": {
"ace": [ "ace": [
{ {
"name": "drop-all-fragments", "name": "drop-all-fragments",
"matches": { "matches": {
"ipv6": { "ipv6": {
"fragment": { "fragment": {
"operator": "match", "operator": "match",
"type": "isf" "type": "isf"
} }
} }
}, },
"actions": { "actions": {
"forwarding": "drop" "forwarding": "drop"
} }
} },
]
"ace": [
{ {
"name": "allow-dns-packets", "name": "allow-dns-packets",
"matches": { "matches": {
"ipv6": { "ipv6": {
"destination-ipv6-network": "2001:db8::/32" "destination-ipv6-network": "2001:db8::/32"
} },
"udp": { "udp": {
"destination-port": { "destination-port-range-or-operator": {
"operator": "eq", "operator": "eq",
"port": 53 "port": 53
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
} }
] ]
} }
} }
]]></artwork> ]]>
</figure></t> </sourcecode>
</figure>
</section> </section>
<section anchor="flags" numbered="true" toc="default">
<section anchor="flags" title="Sample Examples: Filtering TCP Messages"> <name>Examples: Filtering TCP Messages</name>
<t>This section provides sample examples to illustrate TCP-specific <t>This section provides examples to illustrate TCP-specific
filtering based on the flag bits. These examples should not be filtering based on the flag bits. These examples should not be
interpreted as recommended filtering behaviors under specific DDoS interpreted as recommended filtering behaviors under specific DDoS
attacks.</t> attacks.</t>
<section numbered="true" toc="default">
<section title="Discard TCP Null Attack"> <name>Discard TCP Null Attack</name>
<t><xref target="ex3"></xref> shows an example of a DOTS request sent <t><xref target="ex3" format="default"/> shows an example of a DOTS requ
est sent
by a DOTS client to install immediately a filter to discard incoming by a DOTS client to install immediately a filter to discard incoming
TCP messages having all flags unset. The bitmask can be set to 255 to TCP messages having all flags unset. The bitmask can be set to 255 to
check against the (CWR, ECE, URG, ACK, PSH, RST, SYN, FIN) flags.</t> check against the (CWR, ECE, URG, ACK, PSH, RST, SYN, FIN) flags.</t>
<figure anchor="ex3">
<t><figure anchor="ex3" <name>Example of a DOTS Request to Deny TCP Null Attack Messages</name
title="Example of a DOTS Request to Deny TCP Null Attack Messages"> >
<artwork><![CDATA[PUT /restconf/data/ietf-dots-data-channel:dots-dat <sourcecode type=""><![CDATA[
a\ PUT /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
/acl=tcp-flags-example HTTP/1.1 /acl=tcp-flags-example HTTP/1.1
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [{ "acl": [{
"name": "tcp-flags-example", "name": "tcp-flags-example",
"activation-type": "immediate", "activation-type": "immediate",
skipping to change at line 3191 skipping to change at line 3044
} }
}, },
"actions": { "actions": {
"forwarding": "drop" "forwarding": "drop"
} }
}] }]
} }
}] }]
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Rate-Limit SYN Flooding"> <name>Rate-Limit SYN Flooding</name>
<t><xref target="syn-rate"></xref> shows an ACL example to rate-limit <t><xref target="syn-rate" format="default"/> shows an ACL example to ra
incoming SYNs during a SYN-flood attack.<figure anchor="syn-rate" te-limit
title="Example of DOTS Request to Rate-Limit Incoming TCP SYNs"> incoming SYNs during a SYN flood attack.</t>
<artwork><![CDATA[PUT /restconf/data/ietf-dots-data-channel:dots-dat <figure anchor="syn-rate">
a\ <name>Example of DOTS Request to Rate-Limit Incoming TCP SYNs</name>
<sourcecode type=""><![CDATA[
PUT /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
/acl=tcp-flags-example HTTP/1.1 /acl=tcp-flags-example HTTP/1.1
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [{ "acl": [{
"name": "tcp-flags-example", "name": "tcp-flags-example",
"activation-type": "activate-when-mitigating", "activation-type": "activate-when-mitigating",
skipping to change at line 3230 skipping to change at line 3085
}, },
"actions": { "actions": {
"forwarding": "accept", "forwarding": "accept",
"rate-limit": "20.00" "rate-limit": "20.00"
} }
}] }]
} }
}] }]
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Rate-Limit ACK Flooding"> <name>Rate-Limit ACK Flooding</name>
<t><xref target="ex1"></xref> shows an ACL example to rate-limit <t><xref target="ex1" format="default"/> shows an ACL example to rate-li
incoming ACKs during an ACK-flood attack.</t> mit
incoming ACKs during an ACK flood attack.</t>
<t><figure anchor="ex1" <figure anchor="ex1">
title="Example of DOTS Request to Rate-Limit Incoming TCP ACKs"> <name>Example of DOTS Request to Rate-Limit Incoming TCP ACKs</name>
<artwork><![CDATA[PUT /restconf/data/ietf-dots-data-channel:dots-dat <sourcecode type=""><![CDATA[
a\ PUT /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
/acl=tcp-flags-example HTTP/1.1 /acl=tcp-flags-example HTTP/1.1
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [{ "acl": [{
"name": "tcp-flags-example", "name": "tcp-flags-example",
"type": "ipv4-acl-type", "type": "ipv4-acl-type",
skipping to change at line 3272 skipping to change at line 3127
}, },
"actions": { "actions": {
"forwarding": "accept", "forwarding": "accept",
"rate-limit": "20.00" "rate-limit": "20.00"
} }
}] }]
} }
}] }]
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
</section> </section>
</section> </section>
<section anchor="ack" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Thanks to <contact fullname="Christian Jacquenet"/>,
<contact fullname="Roland Dobbins"/>, <contact fullname="Roman Danyliw"/>,
<contact fullname="Ehud Doron"/>, <contact fullname="Russ White"/>,
<contact fullname="Gilbert Clark"/>, <contact fullname="Kathleen Moriarty"
/>,
<contact fullname="Nesredien Suleiman"/>, <contact fullname="Roni Even"/>,
and
<contact fullname="Brian Trammel"/> for the discussion and comments.</t>
<t>The authors would like to give special thanks to <contact fullname="Kan
ame Nishizuka"/> and
<contact fullname="Jon Shallow"/> for their efforts in implementing the pr
otocol and
performing interop testing at IETF Hackathons.</t>
<t>Many thanks to <contact fullname="Benjamin Kaduk"/> for the detailed AD
review.</t>
<t>Thanks to <contact fullname="Martin Björklund"/> for the guidance on RE
STCONF.</t>
<t>Thanks to <contact fullname="Alexey Melnikov"/>, <contact fullname="Ada
m Roach"/>,
<contact fullname="Suresh Krishnan"/>, <contact fullname="Mirja Kühlewind"
/>, and
<contact fullname="Warren Kumari"/> for the review.</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<t>The following people contributed substantially to the content of this
document and should be considered coauthors:</t>
<contact fullname="Kaname Nishizuka" >
<organization>NTT Communications</organization>
<address>
<postal>
<street>GranPark 16F 3-4-1 Shibaura, Minato-ku</street>
<city></city>
<region>Tokyo</region><code>108-8118</code>
<country>Japan</country>
</postal>
<email>kaname@nttv6.jp</email>
</address>
</contact>
<contact fullname="Liang Xia" >
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhuatai District</street>
<city>Nanjing</city>
<region>Jiangsu</region><code>210012</code>
<country>China</country>
</postal>
<email>frank.xialiang@huawei.com</email>
</address>
</contact>
<contact fullname="Prashanth Patil" >
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region><code></code>
<country></country>
</postal>
<email>praspati@cisco.com</email>
</address>
</contact>
<contact fullname="Andrew Mortensen" >
<organization>Arbor Networks, Inc.</organization>
<address>
<postal>
<street>2727 S. State Street</street>
<city>Ann Arbor</city>
<region>Michigan</region><code>48104</code>
<country>United States of America</country>
</postal>
<email>andrew@moretension.com</email>
</address>
</contact>
<contact fullname="Nik Teague" >
<organization>Iron Mountain Data Centers</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region><code></code>
<country>United Kingdom</country>
</postal>
<email>nteague@ironmountain.co.uk</email>
</address>
</contact>
<t>The following individuals have contributed to this
document:</t>
<contact fullname="Dan Wing" >
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region><code></code>
<country></country>
</postal>
<email>dwing-ietf@fuggles.com</email>
</address>
</contact>
<contact fullname="Jon Shallow" >
<organization>NCC Group</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region><code></code>
<country></country>
</postal>
<email>jon.shallow@nccgroup.com</email>
</address>
</contact>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 334 change blocks. 
1555 lines changed or deleted 1712 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/