rfc9244xml2.original.xml   rfc9244.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="3"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<?rfc inline="yes"?> tf-dots-telemetry-25" number="9244" ipr="trust200902" obsoletes="" updates="" su
<?rfc compact="yes"?> bmissionType="IETF" consensus="true" xml:lang="en" tocInclude="true" tocDepth="3
<?rfc subcompact="no"?> " symRefs="true" sortRefs="true" version="3">
<rfc category="std" docName="draft-ietf-dots-telemetry-25" ipr="trust200902"> <!-- xml2rfc v2v3 conversion 3.12.2 -->
<front> <front>
<title abbrev="DOTS Telemetry">Distributed Denial-of-Service Open Threat <title abbrev="DOTS Telemetry">Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry</title> Signaling (DOTS) Telemetry</title>
<author fullname="Mohamed Boucadair" initials="M." role="editor" <seriesInfo name="RFC" value="9244"/>
surname="Boucadair"> <author fullname="Mohamed Boucadair" initials="M." role="editor" surname="Bo
ucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Rennes</city> <city>Rennes</city>
<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.K" initials="T." role="editor" "Reddy.K">
surname="Reddy.K">
<organization>Akamai</organization> <organization>Akamai</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>
<author fullname="Ehud Doron" initials="E." surname="Doron"> <author fullname="Ehud Doron" initials="E." surname="Doron">
<organization>Radware Ltd.</organization> <organization>Radware Ltd.</organization>
<address> <address>
<postal> <postal>
<street>Raoul Wallenberg Street</street> <street>Raoul Wallenberg Street</street>
<city>Tel-Aviv</city> <city>Tel-Aviv</city>
<code>69710</code> <code>69710</code>
<country>Israel</country> <country>Israel</country>
</postal> </postal>
<email>ehudd@radware.com</email> <email>ehudd@radware.com</email>
</address> </address>
</author> </author>
<author fullname="Meiling Chen" initials="M." surname="Chen"> <author fullname="Meiling Chen" initials="M." surname="Chen">
<organization>CMCC</organization> <organization>CMCC</organization>
<address> <address>
<postal> <postal>
<street>32, Xuanwumen West</street> <street>32 Xuanwumen West Street</street>
<city>Beijing</city>
<city>BeiJing</city>
<region>BeiJing</region>
<code>100053</code> <code>100053</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>chenmeiling@chinamobile.com</email> <email>chenmeiling@chinamobile.com</email>
</address> </address>
</author> </author>
<author fullname="Jon Shallow" initials="J." surname="Shallow"> <author fullname="Jon Shallow" initials="J." surname="Shallow">
<organization></organization> <organization/>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city/>
<city></city> <region/>
<code/>
<region></region>
<code></code>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<email>supjps-ietf@jpshallow.com</email> <email>supjps-ietf@jpshallow.com</email>
</address> </address>
</author> </author>
<date month="June" year="2022"/>
<date /> <area>sec</area>
<workgroup>DOTS</workgroup> <workgroup>DOTS</workgroup>
<keyword>automation</keyword> <keyword>automation</keyword>
<keyword>cybersecurity</keyword> <keyword>cybersecurity</keyword>
<keyword>DDoS</keyword> <keyword>DDoS</keyword>
<keyword>Resilience</keyword> <keyword>Resilience</keyword>
<keyword>Intelligence</keyword> <keyword>Intelligence</keyword>
<keyword>Service delivery</keyword> <keyword>Service delivery</keyword>
<keyword>Robustness</keyword>
<keyword>Robsutness</keyword>
<keyword>Collaborative</keyword> <keyword>Collaborative</keyword>
<abstract> <abstract>
<t>This document aims to enrich the DOTS signal channel protocol with <t>This document aims to enrich the Distributed Denial-of-Service Open Thr eat Signaling (DOTS) signal channel protocol with
various telemetry attributes, allowing for optimal Distributed various telemetry attributes, allowing for optimal Distributed
Denial-of-Service (DDoS) attack mitigation. It specifies the normal Denial-of-Service (DDoS) attack mitigation. It specifies the normal
traffic baseline and attack traffic telemetry attributes a DOTS client traffic baseline and attack traffic telemetry attributes a DOTS client
can convey to its DOTS server in the mitigation request, the mitigation can convey to its DOTS server in the mitigation request, the mitigation
status telemetry attributes a DOTS server can communicate to a DOTS status telemetry attributes a DOTS server can communicate to a DOTS
client, and the mitigation efficacy telemetry attributes a DOTS client client, and the mitigation efficacy telemetry attributes a DOTS client
can communicate to a DOTS server. The telemetry attributes can assist can communicate to a DOTS server. The telemetry attributes can assist
the mitigator to choose the DDoS mitigation techniques and perform the mitigator in choosing the DDoS mitigation techniques and performing
optimal DDoS attack mitigation.</t> optimal DDoS attack mitigation.</t>
<t>This document specifies two YANG modules: one for representing DOTS tel
<t>This document specifies a YANG module for representing DOTS telemetry emetry
message types. It also specifies a second YANG module to share the message types and one for sharing the attack mapping details over the DOTS
attack mapping details over the DOTS data channel.</t> data channel.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction" numbered="true" toc="default">
<t>IT organizations and service providers are facing Distributed Denial <name>Introduction</name>
of Service (DDoS) attacks that fall into two broad categories:<list <t>IT organizations and service providers are facing Distributed Denial-of
style="numbers"> -Service
<t>Network/Transport layer attacks target the victim's (DDoS) attacks that fall into two broad categories:</t>
<ol spacing="normal" type="1"><li>
<t>Network-layer and transport-layer attacks target the victim's
infrastructure. These attacks are not necessarily aimed at taking infrastructure. These attacks are not necessarily aimed at taking
down the actual delivered services, but rather to prevent various down the actual delivered services; rather, these attacks prevent vari ous
network elements (routers, switches, firewalls, transit links, and network elements (routers, switches, firewalls, transit links, and
so on) from serving legitimate users' traffic. <vspace so on) from serving legitimate users' traffic. </t>
blankLines="1" />The main method of such attacks is to send a large <t>The main method of such attacks is to send a large
volume or high packet per second (pps) of traffic toward the volume of traffic (e.g., high-pps (packets per second) traffic) toward
the
victim's infrastructure. Typically, attack volumes may vary from a victim's infrastructure. Typically, attack volumes may vary from a
few 100 Mbps to 100s of Gbps or even Tbps. Attacks are commonly few hundred Mbps to hundreds of Gbps or even Tbps. Attacks are commonl y
carried out leveraging botnets and attack reflectors for carried out leveraging botnets and attack reflectors for
amplification attacks (Section 3.1 of <xref amplification attacks (<xref target="RFC4732" sectionFormat="of" secti
target="RFC4732"></xref>) such as NTP (Network Time Protocol), DNS on="3.1"/>) such as NTP (Network Time Protocol), DNS
(Domain Name System), SNMP (Simple Network Management Protocol), or (Domain Name System), SNMP (Simple Network Management Protocol), or
SSDP (Simple Service Discovery Protocol).</t> SSDP (Simple Service Discovery Protocol).</t>
</li>
<t>Application layer attacks target various applications. Typical <li>
<t>Application-layer attacks target various applications. Typical
examples include attacks against HTTP/HTTPS, DNS, SIP (Session examples include attacks against HTTP/HTTPS, DNS, SIP (Session
Initiation Protocol), or SMTP (Simple Mail Transfer Protocol). Initiation Protocol), or SMTP (Simple Mail Transfer Protocol).
However, all applications with their port numbers open at network However, all applications with their port numbers open at network
edges can be attractive attack targets. <vspace edges can be attractive attack targets. </t>
blankLines="1" />Application layer attacks are considered more <t>Application-layer attacks are considered more
complex and harder to categorize, and therefore harder to detect and complex and harder to categorize and are therefore harder to detect an
d
mitigate efficiently.</t> mitigate efficiently.</t>
</list></t> </li>
</ol>
<t>To compound the problem, attackers also leverage multi-vectored <t>To compound the problem, attackers also leverage multi-vectored
attacks. These attacks are assembled from dynamic attack vectors attacks. These attacks are assembled from dynamic network-layer and
(Network/Application) and tactics. As such, multiple attack vectors application-layer attack vectors and other tactics. As such, multiple atta
ck vectors
formed by multiple attack types and volumes are launched simultaneously formed by multiple attack types and volumes are launched simultaneously
towards a victim. Multi-vector attacks are harder to detect and defend toward a victim. Multi-vector attacks are harder to detect and defend
against. Multiple and simultaneous mitigation techniques are needed to against. Multiple and simultaneous mitigation techniques are needed to
defeat such attack campaigns. It is also common for attackers to change defeat such attack campaigns. It is also common for attackers to change
attack vectors right after a successful mitigation, burdening their attack vectors right after a successful mitigation, burdening their
opponents with changing their defense methods.</t> opponents with changing their defense methods.</t>
<t>The conclusion derived from the aforementioned attack scenarios is <t>The conclusion derived from the aforementioned attack scenarios is
that modern attacks detection and mitigation are most certainly that modern attack detection and mitigation are most certainly
complicated and highly convoluted tasks. They demand a comprehensive complicated and highly convoluted tasks. They demand a comprehensive
knowledge of the attack attributes, the normal behavior of the targeted knowledge of the attack attributes and the normal behavior of the targeted
systems (including normal traffic patterns), as well as the attacker's systems (including normal traffic patterns), as well as the attacker's
ongoing and past actions. Even more challenging, retrieving all the ongoing and past actions. Even more challenging, retrieving all the
analytics needed for detecting these attacks is not simple with the analytics needed for detecting these attacks is not simple with the
industry's current reporting capabilities.</t> industry's current reporting capabilities.</t>
<t>The Distributed Denial-of-Service Open Threat Signaling (DOTS) signal c
<t>The DOTS signal channel protocol <xref target="RFC9132"></xref> is hannel protocol <xref target="RFC9132" format="default"/> is
used to carry information about a network resource or a network (or a used to carry information about a network resource or a network (or a
part thereof) that is under a DDoS attack. Such information is sent by a part thereof) that is under a DDoS attack. Such information is sent by a
DOTS client to one or multiple DOTS servers so that appropriate DOTS client to one or multiple DOTS servers so that appropriate
mitigation actions are undertaken on traffic deemed suspicious. Various mitigation actions are undertaken on traffic deemed suspicious. Various
use cases are discussed in <xref target="RFC8903"></xref>.</t> use cases are discussed in <xref target="RFC8903" format="default"/>.</t>
<t>DOTS clients can be integrated within a DDoS attack detector or
<t>DOTS clients can be integrated within a DDoS attack detector, or within network and security elements that have been actively engaged with
network and security elements that have been actively engaged with
ongoing attacks. The DOTS client mitigation environment determines that ongoing attacks. The DOTS client mitigation environment determines that
it is no longer possible or practical for it to handle these attacks it is no longer possible or practical for it to handle these attacks
itself. This can be due to a lack of resources or security capabilities, itself. This can be due to a lack of resources or security capabilities,
as derived from the complexities and the intensity of these attacks. In as derived from the complexities and intensity of these attacks. In
this circumstance, the DOTS client has invaluable knowledge about the this circumstance, the DOTS client has invaluable knowledge about the
actual attacks that need to be handled by its DOTS server(s). By actual attacks that need to be handled by its DOTS server(s). By
enabling the DOTS client to share this comprehensive knowledge of an enabling the DOTS client to share this comprehensive knowledge of an
ongoing attack under specific circumstances, the DOTS server can ongoing attack under specific circumstances, the DOTS server can
drastically increase its ability to accomplish successful mitigation. drastically increase its ability to accomplish successful mitigation.
While the attack is being handled by the mitigation resources associated While the attack is being handled by the mitigation resources associated
with the DOTS server, the DOTS server has knowledge about the ongoing with the DOTS server, the DOTS server has knowledge about the ongoing
attack mitigation. The DOTS server can share this information with the attack mitigation. The DOTS server can share this information with the
DOTS client so that the client can better assess and evaluate the actual DOTS client so that the client can better assess and evaluate the actual
mitigation realized.</t> mitigation realized.</t>
skipping to change at line 226 skipping to change at line 174
this circumstance, the DOTS client has invaluable knowledge about the this circumstance, the DOTS client has invaluable knowledge about the
actual attacks that need to be handled by its DOTS server(s). By actual attacks that need to be handled by its DOTS server(s). By
enabling the DOTS client to share this comprehensive knowledge of an enabling the DOTS client to share this comprehensive knowledge of an
ongoing attack under specific circumstances, the DOTS server can ongoing attack under specific circumstances, the DOTS server can
drastically increase its ability to accomplish successful mitigation. drastically increase its ability to accomplish successful mitigation.
While the attack is being handled by the mitigation resources associated While the attack is being handled by the mitigation resources associated
with the DOTS server, the DOTS server has knowledge about the ongoing with the DOTS server, the DOTS server has knowledge about the ongoing
attack mitigation. The DOTS server can share this information with the attack mitigation. The DOTS server can share this information with the
DOTS client so that the client can better assess and evaluate the actual DOTS client so that the client can better assess and evaluate the actual
mitigation realized.</t> mitigation realized.</t>
<t>DOTS clients can send mitigation hints derived from attack details to <t>DOTS clients can send mitigation hints derived from attack details to
DOTS servers, with the full understanding that the DOTS server may DOTS servers, with the full understanding that a DOTS server may
ignore mitigation hints, as described in <xref target="RFC8612"></xref> ignore mitigation hints, as described in <xref target="RFC8612" format="de
fault"/>
(Gen-004). Mitigation hints will be transmitted across the DOTS signal (Gen-004). Mitigation hints will be transmitted across the DOTS signal
channel, as the data channel may not be functional during an attack. How channel, as the data channel may not be functional during an attack. How
a DOTS server is handling normal and attack traffic attributes, and a DOTS server handles normal and attack traffic attributes, and
mitigation hints, is implementation specific.</t> mitigation hints, is implementation specific.</t>
<t>Both DOTS clients and servers can benefit from this information by <t>Both DOTS clients and servers can benefit from this information by
presenting various information in relevant management, reporting, and presenting various information details in relevant management, reporting, and
portal systems.</t> portal systems.</t>
<t>This document defines DOTS telemetry attributes that can be conveyed <t>This document defines DOTS telemetry attributes that can be conveyed
by DOTS clients to DOTS servers, and vice versa. The DOTS telemetry by DOTS clients to DOTS servers, and vice versa. The DOTS telemetry
attributes are not mandatory attributes of the DOTS signal channel attributes are not mandatory attributes of the DOTS signal channel
protocol <xref target="RFC9132"></xref>. When no limitation policy is protocol <xref target="RFC9132" format="default"/>. When no limitation pol icy is
provided to a DOTS agent, it can signal available telemetry attributes provided to a DOTS agent, it can signal available telemetry attributes
to it peers in order to optimize the overall mitigation service to its peers in order to optimize the overall mitigation service
provisioned using DOTS. The aforementioned policy can be, for example, provisioned using DOTS. The aforementioned policy can be, for example,
agreed during a service subscription (that is out of scope) to identify agreed upon during a service subscription (which is out of scope for this document) to identify
a subset of DOTS clients among those deployed in a DOTS client domain a subset of DOTS clients among those deployed in a DOTS client domain
that are allowed to send or receive telemetry data.</t> that are allowed to send or receive telemetry data.</t>
<t><xref target="data" format="default"/> of this document specifies a YAN
<t>Also, the document specifies a YANG module (<xref G module that augments the DOTS data channel <xref target="RFC8783" format="defa
target="data"></xref>) that augments the DOTS data channel <xref ult"/> with information related to attack details. Sharing such
target="RFC8783"></xref> with attack details information. Sharing such
details during 'idle' time is meant to optimize the data exchanged over details during 'idle' time is meant to optimize the data exchanged over
the DOTS signal channel.</t> the DOTS signal channel.</t>
</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>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP 14 "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
<xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and "<bcp14>SHOULD NOT</bcp14>",
only when, they appear in all capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
<t>The reader should be familiar with the terms defined in <xref are to be interpreted as described in BCP&nbsp;14
target="RFC8612"></xref>.</t> <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
<t>"DOTS Telemetry" is defined as the collection of attributes that are <t>The reader should be familiar with the terms defined in <xref target="R
FC8612" format="default"/>.</t>
<t>"DOTS telemetry" is defined as the collection of attributes that are
used to characterize the normal traffic baseline, attacks and their used to characterize the normal traffic baseline, attacks and their
mitigation measures, and any related information that may help in mitigation measures, and any related information that may help in
enforcing countermeasures. DOTS Telemetry is an optional set of enforcing countermeasures. "DOTS telemetry" is an optional set of
attributes that can be signaled in the DOTS signal channel protocol.</t> attributes that can be signaled in the DOTS signal channel protocol.</t>
<t>The Telemetry Setup Identifier (tsid) is an identifier that is generate
<t>Telemetry Setup Identifier (tsid) is an identifier that is generated d
by DOTS clients to uniquely identify DOTS telemetry setup configuration by DOTS clients to uniquely identify DOTS telemetry setup configuration
data. See <xref target="PUT"></xref> for more details.</t> data. See <xref target="PUT" format="default"/> for more details.</t>
<t>The Telemetry Identifier (tmid) is an identifier that is generated by
<t>Telemetry Identifier (tmid) is an identifier that is generated by
DOTS clients to uniquely identify DOTS telemetry data that is DOTS clients to uniquely identify DOTS telemetry data that is
communicated prior to or during a mitigation. See <xref communicated prior to or during a mitigation. See <xref target="preCtoS" f
target="preCtoS"></xref> for more details.</t> ormat="default"/> for more details.</t>
<t>"Overlapped" lower numeric 'tsid' (or 'tmid') refers to the lower 'tsid
<t>When two telemetry requests overlap, "overlapped" lower numeric ' (or 'tmid') value of two overlapping telemetry requests.</t>
'tsid' (or 'tmid') refers to the lower 'tsid' (or 'tmid') value of these
overlapping requests.</t>
<t>The term "pipe" represents the maximum level of traffic that the DOTS <t>The term "pipe" represents the maximum level of traffic that the DOTS
client domain can receive. Whether a "pipe" is mapped to one or a group client domain can receive. Whether a "pipe" is mapped to one or a group
of network interfaces is deployment-specific. For example, each of network interfaces is deployment specific. For example, each
interconnection link may be considered as a specific pipe if the DOTS interconnection link may be considered as a specific pipe if the DOTS
server is hosted by each upstream provider, while the aggregate of all server is hosted by each upstream provider, while the aggregate of all
links to connect to upstream network providers can be considered by a links to connect to upstream network providers can be considered by a
DOTS client domain as a single pipe when communicating with a DOTS DOTS client domain as a single pipe when communicating with a DOTS
server not hosted by these upstream providers.</t> server not hosted by these upstream providers.</t>
<t>This document uses IANA-assigned Enterprise Numbers. These numbers are
<t>The document uses IANA-assigned Enterprise Numbers. These numbers are
also known as "Private Enterprise Numbers" and "SMI (Structure of also known as "Private Enterprise Numbers" and "SMI (Structure of
Management Information) Network Management Private Enterprise Codes" Management Information) Network Management Private Enterprise Codes"
<xref target="Private-Enterprise-Numbers"></xref>.</t> <xref target="Private-Enterprise-Numbers" format="default"/>.</t>
<t>The meanings of the symbols in YANG tree diagrams are defined in <xref
<t>The meaning of the symbols in YANG tree diagrams are defined in <xref target="RFC8340" format="default"/> and <xref target="RFC8791" format="default"/
target="RFC8340"></xref> and <xref target="RFC8791"></xref>.</t> >.</t>
<t>Consistent with the convention set in <xref target="RFC8783" sectionFor
<t>Consistent with the convention set in Section 2 of <xref mat="of" section="2"/>, the examples in <xref target="vam" format="default"/> us
target="RFC8783"></xref>, the examples in <xref target="vam"></xref> use e
"/restconf" as the discovered RESTCONF API root path. Within these "/restconf" as the discovered RESTCONF API root path. Within these
examples, some protocol header lines are split into multiple lines for examples, some protocol header lines are split into multiple lines for
display purposes only. When a line ends with backslash ('\') as the last display purposes only. When a line ends with a backslash ("\") as the last
character, the line is wrapped for display purposes. It is considered to character, the line is wrapped for display purposes. It is considered to
be joined to the next line by deleting the backslash, the following line be joined to the next line by deleting the backslash, the following line
break, and the leading whitespace of the next line.</t> break, and the leading whitespace of the next line.</t>
</section> </section>
<section anchor="overview" numbered="true" toc="default">
<section anchor="overview" title="DOTS Telemetry: Overview and Purpose"> <name>DOTS Telemetry: Overview and Purpose</name>
<t>Timely and effective signaling of up-to-date DDoS telemetry to all <t>Timely and effective signaling of up-to-date DDoS telemetry to all
elements involved in the mitigation process is essential and improves elements involved in the mitigation process is essential and improves
the overall DDoS mitigation service effectiveness. Bidirectional the overall DDoS mitigation service's effectiveness. Bidirectional
feedback between DOTS agents is required for increased awareness by each feedback between DOTS agents is required for increased awareness by each
party of the attack and mitigation efforts, supporting a superior and party of the attack and mitigation efforts, supporting a superior and
highly efficient attack mitigation service.</t> highly efficient attack mitigation service.</t>
<section numbered="true" toc="default">
<section title="Need More Visibility"> <name>Need for More Visibility</name>
<t>When signaling a mitigation request, it is most certainly <t>When signaling a mitigation request, it is most certainly
beneficial for DOTS clients to signal to DOTS servers any knowledge beneficial for DOTS clients to signal to DOTS servers any knowledge
regarding ongoing attacks. This can happen in cases where DOTS clients regarding ongoing attacks. This can happen in cases where DOTS clients
are asking DOTS servers for support in defending against attacks that are asking DOTS servers for support in defending against attacks that
they have already detected and/or (partially) mitigated.</t> they have already detected and/or (partially) mitigated.</t>
<t>If attacks are already detected and categorized within a DOTS <t>If attacks are already detected and categorized within a DOTS
client domain, the DOTS server, and its associated mitigation client domain, the DOTS server, and its associated mitigation
services, can proactively benefit from this information and optimize services, can proactively benefit from this information and optimize
the overall service delivery. It is important to note that DOTS client the overall service delivery. It is important to note that DOTS client
domains' and DOTS server domains' detection and mitigation approaches domains' and DOTS server domains' detection and mitigation approaches
can be different, and can potentially result in different results and can be different and can potentially result in different results and
attack classifications. The DDoS mitigation service treats the ongoing attack classifications. The DDoS mitigation service treats the ongoing
attack details received from DOTS clients as hints and cannot attack details received from DOTS clients as hints and cannot
completely rely or trust the attack details conveyed by DOTS completely rely on or trust the attack details conveyed by DOTS
clients.</t> clients.</t>
<t>In addition to the DOTS server directly using telemetry data as <t>In addition to the DOTS server directly using telemetry data as
operational hints, the DOTS server security operation team also operational hints, the DOTS server's security operation team also
benefits from telemetry data. A basic requirement of security benefits from telemetry data. A basic requirement of security
operation teams is to be aware of and get visibility into the attacks operation teams is to be aware of and get visibility into the attacks
they need to handle. This holds especially for the case of ongoing they need to handle. This holds especially for the case of ongoing
attacks, where DOTS telemetry provides data about the current attack attacks, where DOTS telemetry provides data about the current attack
status. Even if some mitigation can be automated, operational teams status. Even if some mitigation can be automated, operational teams
can use the DOTS telemetry information to be prepared for attack can use the DOTS telemetry information to be prepared for attack
mitigation and to assign the correct resources (operation staff, mitigation and to assign the correct resources (e.g., operation staff,
networking and mitigation) for the specific service. Similarly, networking resources, mitigation resources) for the specific service. Si
milarly,
security operations personnel at the DOTS client side ask for feedback security operations personnel at the DOTS client side ask for feedback
about their requests for protection. Therefore, it is valuable for about their requests for protection. Therefore, it is valuable for
DOTS servers to share DOTS telemetry with DOTS clients.</t> DOTS servers to share DOTS telemetry with DOTS clients.</t>
<t>Mutual sharing of information is thus crucial for "closing the <t>Mutual sharing of information is thus crucial for "closing the
mitigation loop" between DOTS clients and servers. For the server side mitigation loop" between DOTS clients and servers. For the server-side
team, it is important to confirm that the same attacks that the DOTS team, it is important to confirm that the same attacks that the DOTS
server's mitigation resources are seeing are those that a DOTS client server's mitigation resources are seeing are those for which a DOTS clie
is asking for mitigation of. For the DOTS client side team, it is nt
is requesting mitigation. For the DOTS client-side team, it is
important to realize that the DOTS clients receive the required important to realize that the DOTS clients receive the required
service. For example, understanding that "I asked for mitigation of service -- for example, understanding that "I asked for mitigation of
two attacks and my DOTS server detects and mitigates only one of two attacks, and my DOTS server detects and mitigates only one of
them". Cases of inconsistency in attack classification between DOTS them." Cases of inconsistency in attack classification between DOTS
clients and servers can be highlighted, and maybe handled, using the clients and servers can be highlighted, and maybe handled, using the
DOTS telemetry attributes.</t> DOTS telemetry attributes.</t>
<t>In addition, management and orchestration systems, at both the DOTS
<t>In addition, management and orchestration systems, at both DOTS
client and server sides, can use DOTS telemetry as feedback to client and server sides, can use DOTS telemetry as feedback to
automate various control and management activities derived from automate various control and management activities derived from
signaled telemetry information.</t> signaled telemetry information.</t>
<t>If the DOTS server's mitigation resources have the capabilities to <t>If the DOTS server's mitigation resources have the capabilities to
facilitate the DOTS telemetry, the DOTS server adapts its protection facilitate the DOTS telemetry, the DOTS server adapts its protection
strategy and activates the required countermeasures immediately strategy and activates the required countermeasures immediately
(automation enabled) for the sake of optimized attack mitigation (automation enabled) for the sake of optimized attack mitigation
decisions and actions. The interface from the DOTS server to the decisions and actions. Discussion regarding the interface from the DOTS
mitigator to signal the telemetry data is out of scope.</t> server to the
mitigator to signal the telemetry data is out of scope for this document
.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Enhanced Detection"> <name>Enhanced Detection</name>
<t>DOTS telemetry can also be used as input for determining what <t>DOTS telemetry can also be used as input for determining what
values to use for the tuning parameters available on the mitigation values to use for the tuning parameters available on the mitigation
resources. During the last few years, DDoS attack detection resources. During the last few years, DDoS attack detection
technologies have evolved from threshold-based detection (that is, technologies have evolved from threshold-based detection (that is,
cases when all or specific parts of traffic cross a predefined cases when all or specific parts of traffic cross a predefined
threshold for a certain period of time is considered as an attack) to threshold for a certain period of time is considered as an attack) to
an "anomaly detection" approach. For the latter, it is required to an "anomaly detection" approach. For the latter, it is required to
maintain rigorous learning of "normal" behavior, and an "anomaly" (or maintain rigorous learning of "normal" behavior, and an "anomaly" (or
an attack) is identified and categorized based on the knowledge about an attack) is identified and categorized based on the knowledge about
the normal behavior and a deviation from this normal behavior. the normal behavior and a deviation from this normal behavior.
skipping to change at line 396 skipping to change at line 322
maintain rigorous learning of "normal" behavior, and an "anomaly" (or maintain rigorous learning of "normal" behavior, and an "anomaly" (or
an attack) is identified and categorized based on the knowledge about an attack) is identified and categorized based on the knowledge about
the normal behavior and a deviation from this normal behavior. the normal behavior and a deviation from this normal behavior.
Statistical and artificial intelligence algorithms (e.g., machine Statistical and artificial intelligence algorithms (e.g., machine
learning) are used such that the actual traffic thresholds are learning) are used such that the actual traffic thresholds are
automatically calculated by learning the protected entity's normal automatically calculated by learning the protected entity's normal
traffic behavior during 'idle' time (i.e., no mitigation is active). traffic behavior during 'idle' time (i.e., no mitigation is active).
The normal traffic characterization learned is referred to as the The normal traffic characterization learned is referred to as the
"normal traffic baseline". An attack is detected when the victim's "normal traffic baseline". An attack is detected when the victim's
actual traffic is deviating from this normal baseline pattern.</t> actual traffic is deviating from this normal baseline pattern.</t>
<t>In addition, subsequent activities toward mitigating an attack are <t>In addition, subsequent activities toward mitigating an attack are
much more challenging. The ability to distinguish legitimate traffic much more challenging. The ability to distinguish legitimate traffic
from attacker traffic on a per-packet basis is complex. For example, a from attacker traffic on a per-packet basis is complex. For example, a
packet may look "legitimate" and no attack signature can be packet may look "legitimate" and no attack signature can be
identified. The anomaly can be identified only after detailed identified. The anomaly can be identified only after detailed
statistical analysis. DDoS attack mitigators use the normal baseline statistical analysis. DDoS attack mitigators use the normal baseline
during the mitigation of an attack to identify and categorize the during the mitigation of an attack to identify and categorize the
expected appearance of a specific traffic pattern. Particularly, the expected appearance of a specific traffic pattern. Particularly, the
mitigators use the normal baseline to recognize the "level of mitigators use the normal baseline to recognize the "level of
normality" that needs to be achieved during the various mitigation normality" that needs to be achieved during the various mitigation
process.</t> processes.</t>
<t>Normal baseline calculation is performed based on continuous <t>Normal baseline calculation is performed based on continuous
learning of the normal behavior of the protected entities. The minimum learning of the normal behavior of the protected entities. The minimum
learning period varies from hours to days and even weeks, depending on learning period varies from hours to days and even weeks, depending on
the protected application behavior. The baseline cannot be learned the protected applications' behavior. The baseline cannot be learned
during active attacks because attack conditions do not characterize during active attacks because attack conditions do not characterize
the protected entities' normal behavior.</t> the protected entities' normal behavior.</t>
<t>If the DOTS client has calculated the normal baseline of its <t>If the DOTS client has calculated the normal baseline of its
protected entities, signaling such information to the DOTS server protected entities, signaling such information to the DOTS server
along with the attack traffic levels provides value. The DOTS server along with the attack traffic levels provides value. The DOTS server
benefits from this telemetry by tuning its mitigation resources with benefits from this telemetry by tuning its mitigation resources with
the DOTS client's normal baseline. The DOTS server mitigators use the the DOTS client's normal baseline. The DOTS server's mitigators use the
baseline to familiarize themselves with the attack victim's normal baseline to familiarize themselves with the attack victim's normal
behavior and target the baseline as the level of normality they need behavior and target the baseline as the level of normality they need
to achieve. Fed with this information, the overall mitigation to achieve. Fed with this information, the overall mitigation
performances is expected to be improved in terms of time to mitigate, performance is expected to be improved in terms of time to mitigate,
accuracy, and false-negative and false-positive rates.</t> accuracy, and false-negative and false-positive rates.</t>
<t>Mitigation of attacks without having certain knowledge of normal <t>Mitigation of attacks without having certain knowledge of normal
traffic can be inaccurate at best. This is especially true for traffic can be inaccurate at best. This is especially true for
recursive signaling (see Section 3.2.3 of <xref recursive signaling (see <xref target="RFC8811" sectionFormat="of" secti
target="RFC8811"></xref>). Given that DOTS clients can be integrated on="3.2.3"/>). Given that DOTS clients can be integrated
in a highly diverse set of scenarios and use cases, this emphasizes in a highly diverse set of scenarios and use cases, this emphasizes
the need for knowledge of each DOTS client domain behavior, especially the need for knowledge of the behavior of each DOTS client domain -- esp
given that common global thresholds for attack detection practically ecially
cannot be realized. Each DOTS client domain can have its own levels of given that common global thresholds for attack detection can almost neve
r
be realized. Each DOTS client domain can have its own levels of
traffic and normal behavior. Without facilitating normal baseline traffic and normal behavior. Without facilitating normal baseline
signaling, it may be very difficult for DOTS servers in some cases to signaling, it may be very difficult for DOTS servers in some cases to
detect and mitigate the attacks accurately: <list style="empty"> detect and mitigate the attacks accurately:</t>
<t>It is important to emphasize that it is practically impossible <ul spacing="normal">
<li>It is important to emphasize that it is practically impossible
for the DOTS server's mitigators to calculate the normal baseline for the DOTS server's mitigators to calculate the normal baseline
in cases where they do not have any knowledge of the traffic in cases where they do not have any knowledge of the traffic
beforehand.</t> beforehand.</li>
</list></t> </ul>
<t>Of course, this information can be provided using out-of-band <t>Of course, this information can be provided using out-of-band
mechanisms or manual configuration at the risk of unmaintained mechanisms or manual configuration, at the risk of unmaintained
information becoming inaccurate as the network evolves and "normal" information becoming inaccurate as the network evolves and "normal"
patterns change. The use of a dynamic and collaborative means between patterns change. The use of a dynamic and collaborative means between
the DOTS client and server to identify and share key parameters for the DOTS client and server to identify and share key parameters for
the sake of efficient DDoS protection is valuable.</t> the sake of efficient DDoS protection is valuable.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Efficient Mitigation"> <name>Efficient Mitigation</name>
<t>During a high volume attack, DOTS client pipes can be totally <t>During a high-volume attack, DOTS client pipes can be totally
saturated. DOTS clients ask their DOTS servers to handle the attack saturated. DOTS clients ask their DOTS servers to handle the attack
upstream so that DOTS client pipes return to a reasonable load level upstream so that DOTS client pipes return to a reasonable load level
(normal pattern, ideally). At this point, it is essential to ensure (normal pattern, ideally). At this point, it is essential to ensure
that the mitigator does not overwhelm the DOTS client pipes by sending that the mitigator does not overwhelm the DOTS client pipes by sending
back large volumes of "clean traffic", or what it believes is "clean". back large volumes of "clean traffic", or what it believes is "clean".
This can happen when the mitigator has not managed to detect and This can happen when the mitigator has not managed to detect and
mitigate all the attacks launched towards the DOTS client domain.</t> mitigate all the attacks launched toward the DOTS client domain.</t>
<t>In this case, it can be valuable to DOTS clients to signal to DOTS <t>In this case, it can be valuable to DOTS clients to signal to DOTS
servers the total pipe capacity, which is the level of traffic the servers the total pipe capacity, which is the level of traffic the
DOTS client domain can absorb from its upstream network. This usually DOTS client domain can absorb from its upstream network. This is usually
is the circuit size which includes all the packet overheads. Dynamic the circuit size, which includes all the packet overheads. Dynamic
updates of the condition of pipes between DOTS agents while they are updates of the condition of pipes between DOTS agents while they are
under a DDoS attack is essential (e.g., where multiple DOTS clients under a DDoS attack are essential (e.g., where multiple DOTS clients
share the same physical connectivity pipes). The DOTS server should share the same physical connectivity pipes). The DOTS server should
activate other mechanisms to ensure it does not allow the DOTS client activate other mechanisms to ensure that it does not allow the DOTS clie nt
domain's pipes to be saturated unintentionally. The rate-limit action domain's pipes to be saturated unintentionally. The rate-limit action
defined in <xref target="RFC8783"></xref> is a reasonable candidate to defined in <xref target="RFC8783" format="default"/> is a reasonable can didate to
achieve this objective; the DOTS client can indicate the type(s) of achieve this objective; the DOTS client can indicate the type(s) of
traffic (such as ICMP, UDP, TCP port number 80) it prefers to limit. traffic (such as ICMP, UDP, TCP port number 80) it prefers to limit.
The rate-limit action can be controlled via the signal channel <xref The rate-limit action can be controlled via the signal channel <xref tar
target="RFC9133"></xref> even when the pipe is overwhelmed.</t> get="RFC9133" format="default"/> even when the pipe is overwhelmed.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Design Overview"> <name>Design Overview</name>
<t></t> <section numbered="true" toc="default">
<name>Overview of Telemetry Operations</name>
<section title="Overview of Telemetry Operations">
<t>The DOTS protocol suite is divided into two logical channels: the <t>The DOTS protocol suite is divided into two logical channels: the
signal channel <xref target="RFC9132"></xref> and data channel <xref signal channel <xref target="RFC9132" format="default"/> and data channe
target="RFC8783"></xref>. This division is due to the vastly different l <xref target="RFC8783" format="default"/>. This division is due to the vastly
different
requirements placed upon the traffic they carry. The DOTS signal requirements placed upon the traffic they carry. The DOTS signal
channel must remain available and usable even in the face of attack channel must remain available and usable even in the face of attack
traffic that might, e.g., saturate one direction of the links traffic that might, for example, saturate one direction of the links
involved, rendering acknowledgment-based mechanisms unreliable and involved, rendering acknowledgment-based mechanisms unreliable and
strongly incentivizing messages to be small enough to be contained in strongly incentivizing messages to be small enough to be contained in
a single IP packet (Section 2.2 of <xref target="RFC8612"></xref>). In a single IP packet (<xref target="RFC8612" sectionFormat="of" section="2 .2"/>). In
contrast, the DOTS data channel is available for high-bandwidth data contrast, the DOTS data channel is available for high-bandwidth data
transfer before or after an attack, using more conventional transport transfer before or after an attack, using more conventional transport
protocol techniques (Section 2.3 of <xref target="RFC8612"></xref>). protocol techniques (<xref target="RFC8612" sectionFormat="of" section=" 2.3"/>).
It is generally preferable to perform advance configuration over the It is generally preferable to perform advance configuration over the
DOTS data channel, including configuring aliases for static or nearly DOTS data channel, including configuring aliases for static or nearly
static data sets such as sets of network addresses/prefixes that might static data sets such as sets of network addresses/prefixes that might
be subject to related attacks. This design helps to optimize the use be subject to related attacks. This design helps to optimize the use
of the DOTS signal channel for the small messages that are important of the DOTS signal channel for the small messages that are important
to deliver during an attack. As a reminder, both DOTS signal and data to deliver during an attack. As a reminder, the DOTS signal channel and
channels require secure communication channels (Section 11 of <xref data
target="RFC9132"></xref> and Section 10 of <xref channel both require secure communication channels (<xref target="RFC913
target="RFC8783"></xref>).</t> 2" sectionFormat="of" section="11"/> and <xref target="RFC8783" sectionFormat="o
f" section="10"/>).</t>
<t>Telemetry information has aspects that correspond to both <t>Telemetry information has aspects that correspond to both
operational modes (i.e., signal and data channels): there is certainly operational modes (i.e., signal channel and data channel): there is cert ainly
a need to convey updated information about ongoing attack traffic and a need to convey updated information about ongoing attack traffic and
targets during an attack, so as to convey detailed information about targets during an attack, so as to convey detailed information about
mitigation status and inform updates to mitigation strategy in the mitigation status and inform updates to mitigation strategy in the
face of adaptive attacks. However, it is also useful to provide face of adaptive attacks. However, it is also useful to provide
mitigation services with a picture of normal or "baseline" traffic mitigation services with a picture of normal or "baseline" traffic
towards potential targets to aid in detecting when incoming traffic toward potential targets to aid in detecting when incoming traffic
deviates from normal into being an attack. Also, one might populate a deviates from normal into being an attack. Also, one might populate a
"database" of classifications of known types of attack so that a short "database" of classifications of known types of attacks so that a short
attack identifier can be used during attack time to describe an attack identifier can be used during an attack period to describe an
observed attack. This specification does make provision for use of the observed attack. This specification does make provision for use of the
DOTS data channel for the latter function (<xref DOTS data channel for the latter function (<xref target="vam" format="de
target="vam"></xref>), but otherwise retains most telemetry fault"/>) but otherwise retains most telemetry
functionality in the DOTS signal channel.</t> functionality in the DOTS signal channel.</t>
<t>Note that it is a functional requirement to convey information <t>Note that it is a functional requirement to convey information
about ongoing attack traffic during an attack, and information about about ongoing attack traffic during an attack, and information about
baseline traffic uses an essentially identical data structure that is baseline traffic uses an essentially identical data structure that is
naturally defined to sit next to the description of attack traffic. naturally defined to sit next to the description of attack traffic.
The related telemetry setup information used to parameterize actual The related telemetry setup information used to parameterize actual
traffic data is also sent over the signal channel, out of traffic data is also sent over the signal channel, out of
expediency.</t> expediency.</t>
<t>This document specifies an extension to the DOTS signal channel <t>This document specifies an extension to the DOTS signal channel
protocol. Considerations about how to establish, maintain, and make protocol. Considerations about how to establish, maintain, and make
use of the DOTS signal channel are specified in <xref use of the DOTS signal channel are specified in <xref target="RFC9132" f
target="RFC9132"></xref>.</t> ormat="default"/>.</t>
<t>Once the DOTS signal channel is established, DOTS clients that <t>Once the DOTS signal channel is established, DOTS clients that
support the DOTS telemetry extension proceed with the telemetry setup support the DOTS telemetry extension proceed with the telemetry setup
configuration (e.g., measurement interval, telemetry notification configuration (e.g., measurement interval, telemetry notification
interval, pipe capacity, normal traffic baseline) as detailed in <xref interval, pipe capacity, normal traffic baseline) as detailed in <xref t
target="conf"></xref>. DOTS agents can then include DOTS telemetry arget="conf" format="default"/>. DOTS agents can then include DOTS telemetry
attributes using the DOTS signal channel (<xref target="pre"></xref>). attributes using the DOTS signal channel (<xref target="pre" format="def
ault"/>).
A DOTS client can use separate messages to share with its DOTS A DOTS client can use separate messages to share with its DOTS
server(s) a set of telemetry data bound to an ongoing mitigation server(s) a set of telemetry data bound to an ongoing mitigation
(<xref target="preCtoS"></xref>). Also, a DOTS client that is (<xref target="preCtoS" format="default"/>). Also, a DOTS client that is
interested in receiving telemetry notifications related to some of its interested in receiving telemetry notifications related to some of its
resources follows the procedure defined in <xref resources follows the procedure defined in <xref target="preStoC" format
target="preStoC"></xref>. The DOTS client can then decide to send a ="default"/>. A DOTS client that receives such notifications can then decide to
mitigation request if the notified attack cannot be mitigated locally send a mitigation request if an attack cannot be mitigated locally
within the DOTS client domain.</t> within the DOTS client domain.</t>
<t>Aggregate DOTS telemetry data can also be included in efficacy <t>Aggregate DOTS telemetry data can also be included in efficacy
update (<xref target="effu-S"></xref>) or mitigation update (<xref update (<xref target="effu-S" format="default"/>) or mitigation update (
target="premStoC"></xref>) messages.</t> <xref target="premStoC" format="default"/>) messages.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Block-wise Transfer"> <name>Block-Wise Transfers</name>
<t>DOTS clients can use block wise transfer <xref <t>DOTS clients can use a block-wise transfer <xref target="RFC7959" for
target="RFC7959"></xref> with the recommendation detailed in Section mat="default"/> with the recommendation detailed in <xref target="RFC9132" secti
4.4.2 of <xref target="RFC9132"></xref> to control the size of a onFormat="of" section="4.4.2"/> to control the size of a
response when the data to be returned does not fit within a single response when the data to be returned does not fit within a single
datagram.</t> datagram.</t>
<t>DOTS clients can also use the Constrained Application Protocol (CoAP)
<t>DOTS clients can also use CoAP Block1 Option in a PUT request Block1 Option in a PUT request
(Section 2.5 of <xref target="RFC7959"></xref>) to initiate large (<xref target="RFC7959" sectionFormat="of" section="2.5"/>) to initiate
large
transfers, but these Block1 transfers are likely to fail if the transfers, but these Block1 transfers are likely to fail if the
inbound "pipe" is running full because the transfer requires a message inbound "pipe" is running full because the transfer requires a message
from the server for each block, which would likely be lost in the from the server for each block, which would likely be lost in the
incoming flood. Consideration needs to be made to try to fit this PUT incoming flood. Consideration needs to be made to try to fit this PUT
into a single transfer or to separate out the PUT into several into a single transfer or to separate out the PUT into several
discrete PUTs where each of them fits into a single packet.</t> discrete PUTs where each of them fits into a single packet.</t>
<t>Q-Block1 and Q-Block2 Options that are similar to the CoAP Block1 <t>Q-Block1 and Q-Block2 Options that are similar to the CoAP Block1
and Block2 Options, but enable robust transmissions of big blocks of and Block2 Options, but enable robust transmissions of big blocks of
data with less packet interchanges using NON messages, are defined in data with less packet interchanges using NON messages, are defined in
<xref target="I-D.ietf-core-new-block"></xref>. DOTS implementations <xref target="RFC9177" format="default"/>. DOTS implementations
can consider the use of Q-Block1 and Q-Block2 Options <xref can consider the use of Q-Block1 and Q-Block2 Options <xref target="I-D.
target="I-D.ietf-dots-robust-blocks"></xref>.</t> ietf-dots-robust-blocks" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="DOTS Multi-homing Considerations"> <name>DOTS Multihoming Considerations</name>
<t>Considerations for multi-homed DOTS clients to select which DOTS <t>Considerations for multihomed DOTS clients to select which DOTS
server to contact and which IP prefixes to include in a telemetry server to contact and which IP prefixes to include in a telemetry
message to a given peer DOTS server are discussed in <xref message to a given peer DOTS server are discussed in <xref target="I-D.i
target="I-D.ietf-dots-multihoming"></xref>. For example, if each etf-dots-multihoming" format="default"/>. For example, if each
upstream network exposes a DOTS server and the DOTS client maintains upstream network exposes a DOTS server and the DOTS client maintains
DOTS channels with all of them, only the information related to DOTS channels with all of them, only the information related to
prefixes assigned by an upstream network to the DOTS client domain prefixes assigned by an upstream network to the DOTS client domain
will be signaled via the DOTS channel established with the DOTS server will be signaled via the DOTS channel established with the DOTS server
of that upstream network.</t> of that upstream network.</t>
<t>Considerations related to whether (and how) a DOTS client gleans <t>Considerations related to whether (and how) a DOTS client gleans
some telemetry information (e.g., attack details) it receives from a some telemetry information (e.g., attack details) it receives from a
first DOTS server and share it with a second DOTS server are first DOTS server and shares it with a second DOTS server are
implementation and deployment specific.</t> implementation and deployment specific.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="YANG Considerations"> <name>YANG Considerations</name>
<t>Telemetry messages exchanged between DOTS agents are serialized <t>Telemetry messages exchanged between DOTS agents are serialized
using Concise Binary Object Representation (CBOR) <xref using Concise Binary Object Representation (CBOR) <xref target="RFC8949"
target="RFC8949"></xref>. CBOR-encoded payloads are used to carry format="default"/>. CBOR-encoded payloads are used to carry
signal-channel-specific payload messages which convey request signal-channel-specific payload messages that convey request
parameters and response information such as errors.</t> parameters and response information such as errors.</t>
<t>This document specifies a YANG module <xref target="RFC7950" format="
<t>This document specifies a YANG module <xref default"/> for representing DOTS telemetry message types
target="RFC7950"></xref> for representing DOTS telemetry message types (<xref target="module" format="default"/>). All parameters in the payloa
(<xref target="module"></xref>). All parameters in the payload of the d of the
DOTS signal channel are mapped to CBOR types as specified in <xref DOTS signal channel are mapped to CBOR types as specified in <xref targe
target="map1"></xref>. As a reminder, Section 3 of <xref t="map1" format="default"/>. As a reminder, <xref target="RFC9132" sectionFormat
target="RFC9132"></xref> defines the rules for mapping YANG-modeled ="of" section="3"/> defines the rules for mapping YANG-modeled
data to CBOR.</t> data to CBOR.</t>
<t>The DOTS telemetry module (<xref target="module" format="default"/>)
<t>The DOTS telemetry module (<xref target="module"></xref>) is not is not
intended to be used via NETCONF/RESTCONF for DOTS server management intended to be used via the Network Configuration Protocol (NETCONF) / R
ESTCONF for DOTS server management
purposes. It serves only to provide a data model and encoding purposes. It serves only to provide a data model and encoding
following <xref target="RFC8791"></xref>. Server deviations (Section following <xref target="RFC8791" format="default"/>. Server deviations (
5.6.3 of <xref target="RFC7950"></xref>) are strongly discouraged, as <xref target="RFC7950" sectionFormat="of" section="5.6.3"/>) are strongly discou
the peer DOTS agent does not have means to retrieve the list of raged, as
the peer DOTS agent does not have the means to retrieve the list of
deviations and thus interoperability issues are likely to be deviations and thus interoperability issues are likely to be
encountered.</t> encountered.</t>
<t>The DOTS telemetry module (<xref target="module" format="default"/>)
<t>The DOTS telemetry module (<xref target="module"></xref>) uses uses
"enumerations" rather than "identities" to define units, samples, and "enumerations" rather than "identities" to define units, samples, and
intervals because otherwise the namespace identifier intervals because otherwise the namespace identifier
"ietf-dots-telemetry" must be included when a telemetry attribute is "ietf-dots-telemetry" must be included when a telemetry attribute is
included (e.g., in a mitigation efficacy update). The use of included (e.g., in a mitigation efficacy update). The use of
"identities" is thus suboptimal from a message compactness standpoint; "identities" is thus suboptimal from the standpoint of message compactne
one of the key requirements for DOTS Signal Channel messages.</t> ss,
as message compactness is one of the key requirements for DOTS signal ch
<t>The DOTS telemetry module (<xref target="module"></xref>) includes annel messages.</t>
some lists for which no key statement is included. This behavior is <t>The DOTS telemetry module (<xref target="module" format="default"/>)
compliant with <xref target="RFC8791"></xref>. The reason for not includes
including these keys is because they are not included in the message some lists for which no "key" statement is included. This behavior is
compliant with <xref target="RFC8791" format="default"/>. The reason for
not
including these keys is that they are not included in the message
body of DOTS requests; such keys are included as mandatory Uri-Paths body of DOTS requests; such keys are included as mandatory Uri-Paths
in requests (Sections <xref format="counter" target="conf"></xref> and in requests (Sections&nbsp;<xref format="counter" target="conf"/> and
<xref format="counter" target="pre-t"></xref>). Otherwise, whenever a <xref format="counter" target="pre-t"/>). Otherwise, whenever a
key statement is used in the module, the same definition as in Section "key" statement is used in the module, the same definition as the defini
7.8.2 of <xref target="RFC7950"></xref> is assumed.</t> tion provided in <xref target="RFC7950" sectionFormat="of" section="7.8.2"/> is
assumed.</t>
<t>Some parameters (e.g., low percentile values) may be associated <t>Some parameters (e.g., low-percentile values) may be associated
with different YANG types (e.g., decimal64 and yang:gauge64). To with different YANG types (e.g., decimal64 and yang:gauge64). To
easily distinguish the types of these parameters while using easily distinguish the types of these parameters while using
meaningful names, the following suffixes are used:</t> meaningful names, the following suffixes are used:</t>
<table anchor="tab-1" align="center">
<texttable> <name>Suffixes and YANG Types</name>
<ttcol>Suffix</ttcol> <thead>
<tr>
<ttcol>YANG Type</ttcol> <th align="left">Suffix</th>
<th align="left">YANG Type</th>
<ttcol>Example</ttcol> <th align="left">Example</th>
</tr>
<c>-g</c> </thead>
<tbody>
<c>yang:gauge64</c> <tr>
<td align="left">-g</td>
<c>low-percentile-g</c> <td align="left">yang:gauge64</td>
<td align="left">low-percentile-g</td>
<c>-c</c> </tr>
<tr>
<c>container</c> <td align="left">-c</td>
<td align="left">container</td>
<c>connection-c</c> <td align="left">connection-c</td>
</tr>
<c>-ps</c> <tr>
<td align="left">-ps</td>
<c>per second</c> <td align="left">per second</td>
<td align="left">connection-ps</td>
<c>connection-ps</c> </tr>
</texttable> </tbody>
</table>
<t>The full tree diagram of the DOTS telemetry module can be generated <t>The full tree diagram of the DOTS telemetry module can be generated
using the "pyang" tool <xref target="PYANG"></xref>. That tree is not using the "pyang" tool <xref target="PYANG" format="default"/>. That tre
included here because it is too long (Section 3.3 of <xref e is not
target="RFC8340"></xref>). Instead, subtrees are provided for the included here because it is too long (<xref target="RFC8340" sectionForm
at="of" section="3.3"/>). Instead, subtrees are provided for the
reader's convenience.</t> reader's convenience.</t>
<t>In order to optimize the data exchanged over the DOTS signal <t>In order to optimize the data exchanged over the DOTS signal
channel, the document specifies a second YANG module channel, this document specifies a second YANG module
("ietf-dots-mapping", <xref target="data"></xref>) that augments the ("ietf-dots-mapping"; see <xref target="data" format="default"/>) that a
DOTS data channel <xref target="RFC8783"></xref>. This augmentation ugments the
DOTS data channel <xref target="RFC8783" format="default"/>. This augmen
tation
can be used during 'idle' time to share the attack mapping details can be used during 'idle' time to share the attack mapping details
(<xref target="attackdetails"></xref>). DOTS clients can use tools, (<xref target="attackdetails" format="default"/>). DOTS clients can use
e.g., YANG Library <xref target="RFC8525"></xref>, to retrieve the tools,
e.g., the YANG Library <xref target="RFC8525" format="default"/>, to ret
rieve the
list of features and deviations supported by the DOTS server over the list of features and deviations supported by the DOTS server over the
data channel.</t> data channel.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Generic Considerations"> <name>Generic Considerations</name>
<t></t> <section numbered="true" toc="default">
<name>DOTS Client Identification</name>
<section title="DOTS Client Identification"> <t>Following the rules in <xref target="RFC9132" sectionFormat="of" sect
<t>Following the rules in Section 4.4.1 of <xref ion="4.4.1"/>, a unique identifier is generated by a DOTS
target="RFC9132"></xref>, a unique identifier is generated by a DOTS
client to prevent request collisions ('cuid').</t> client to prevent request collisions ('cuid').</t>
<t>As a reminder, <xref target="RFC9132" sectionFormat="of" section="4.4
<t>As a reminder, <xref target="RFC9132"></xref> forbids 'cuid' to be .1.3"/>
returned in a response message body.</t> forbids 'cuid' to be returned in a response message body.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="DOTS Gateways"> <name>DOTS Gateways</name>
<t>DOTS gateways may be located between DOTS clients and servers. The <t>DOTS gateways may be located between DOTS clients and servers. The
considerations elaborated in Section 4.4.1 of <xref considerations elaborated in <xref target="RFC9132" sectionFormat="of" s
target="RFC9132"></xref> must be followed. In particular, 'cdid' ection="4.4.1"/> must be followed. In particular, the 'cdid'
attribute is used to unambiguously identify a DOTS client domain.</t> attribute is used to unambiguously identify a DOTS client domain.</t>
<t>As a reminder, <xref target="RFC9132" sectionFormat="of" section="4.4
<t>As a reminder, Section 4.4.1.3 of <xref target="RFC9132"></xref> .1.3"/>
forbids 'cdid' (if present) to be returned in a response message forbids 'cdid' (if present) to be returned in a response message
body.</t> body.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Empty URI Paths"> <name>Uri-Path Parameters and Empty Values</name>
<t>Uri-Path parameters and attributes with empty values MUST NOT be <t>Uri-Path parameters and attributes with empty values <bcp14>MUST NOT<
/bcp14> be
present in a request. The presence of such an empty value renders the present in a request. The presence of such an empty value renders the
entire containing message invalid.</t> entire containing message invalid.</t>
</section> </section>
<section anchor="control" numbered="true" toc="default">
<section anchor="control" title="Controlling Configuration Data"> <name>Controlling Configuration Data</name>
<t>The DOTS server follows the same considerations discussed in <t>The DOTS server follows the same considerations discussed in
Section of 4.5.3 of <xref target="RFC9132"></xref> for managing DOTS <xref target="RFC9132" sectionFormat="of" section="4.5.3"/> for managing
telemetry configuration freshness and notification.</t> DOTS
telemetry configuration freshness and notifications.</t>
<t>Likewise, a DOTS client may control the selection of configuration <t>Likewise, a DOTS client may control the selection of configuration
and non-configuration data nodes when sending a GET request by means and non-configuration data nodes when sending a GET request by means
of the 'c' Uri-Query option and following the procedure specified in of the 'c' (content) Uri-Query option and following the procedure specif
Section of 4.4.2 of <xref target="RFC9132"></xref>. These ied in
<xref target="RFC9132" sectionFormat="of" section="4.4.2"/>. These
considerations are not reiterated in the following sections.</t> considerations are not reiterated in the following sections.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Message Validation"> <name>Message Validation</name>
<t>The authoritative reference for validating telemetry messages <t>The authoritative references for validating telemetry messages
exchanged over the DOTS signal channel are Sections <xref exchanged over the DOTS signal channel are Sections&nbsp;<xref format="c
format="counter" target="conf"></xref>, <xref format="counter" ounter" target="conf"/>, <xref format="counter" target="pre-t"/>, and <xref form
target="pre-t"></xref>, and <xref format="counter" at="counter" target="status"/> together with the mapping table provided in
target="status"></xref> together with the mapping table established in <xref target="map1" format="default"/>. The structure of telemetry messa
<xref target="map1"></xref>. The structure of telemetry message bodies ge bodies
is represented as a YANG data structure (<xref is represented as a YANG data structure (<xref target="module" format="d
target="module"></xref>).</t> efault"/>).</t>
</section> </section>
<section anchor="note-examples" numbered="true" toc="default">
<section anchor="note-examples" title="A Note About Examples"> <name>A Note about Examples</name>
<t>Examples are provided for illustration purposes. The document does <t>Examples are provided for illustration purposes. This document does
not aim to provide a comprehensive list of message examples.</t> not aim to provide a comprehensive list of message examples.</t>
<t>JSON encoding of YANG-modeled data is used to illustrate the <t>JSON encoding of YANG-modeled data is used to illustrate the
various telemetry operations. To ease readability, parameter names and various telemetry operations. To ease readability, parameter names and
their JSON types are, thus, used in the examples rather than their their JSON types are thus used in the examples rather than their
CBOR key values and CBOR types following the mappings in <xref CBOR key values and CBOR types following the mappings in <xref target="m
target="map1"></xref>. These conventions are inherited from <xref ap1" format="default"/>. These conventions are inherited from <xref target="RFC9
target="RFC9132"></xref>.</t> 132" format="default"/>.</t>
<t>The examples use Enterprise Number 32473, which is defined for
<t>The examples use the Enterprise Number 32473 defined for documentation use; see <xref target="RFC5612" format="default"/>.</t>
documentation use <xref target="RFC5612"></xref>.</t>
</section> </section>
</section> </section>
<section anchor="tel-op-paths" numbered="true" toc="default">
<section title="Telemetry Operation Paths"> <name>Telemetry Operation Paths</name>
<t>As discussed in Section 4.2 of <xref target="RFC9132"></xref>, each <t>As discussed in <xref target="RFC9132" sectionFormat="of" section="4.2"
/>, each
DOTS operation is indicated by a path suffix that indicates the intended DOTS operation is indicated by a path suffix that indicates the intended
operation. The operation path is appended to the path prefix to form the operation. The operation path is appended to the path prefix to form the
URI used with a CoAP request to perform the desired DOTS operation. The URI used with a CoAP request to perform the desired DOTS operation. The
following telemetry path suffixes are defined (Table 2):<figure> following telemetry path suffixes are defined (<xref target="tab-2"/>):</t
<artwork><![CDATA[ +-----------------+----------------+----- >
------+
| Operation | Operation Path | Details |
+=================+================+===========+
| Telemetry Setup | /tm-setup | Section 6 |
| Telemetry | /tm | Section 7 |
+-----------------+----------------+-----------+
Table 2: DOTS Telemetry Operations]]></artwork>
</figure></t>
<t>Consequently, the "ietf-dots-telemetry" YANG module defined in <xref <table anchor="tab-2">
target="module"></xref> defines data structure to represent new DOTS <name>DOTS Telemetry Operations</name>
<thead>
<tr>
<th>Operation</th>
<th>Operation Path</th>
<th>Details</th>
</tr>
</thead>
<tbody>
<tr>
<td>Telemetry Setup</td>
<td>/tm-setup</td>
<td><xref target="conf"/></td>
</tr>
<tr>
<td>Telemetry</td>
<td>/tm</td>
<td><xref target="pre-t"/></td>
</tr>
</tbody>
</table>
<t>Consequently, the "ietf-dots-telemetry" YANG module defined in <xref ta
rget="module" format="default"/> defines a data structure to represent new DOTS
message types called 'telemetry-setup' and 'telemetry'. The tree message types called 'telemetry-setup' and 'telemetry'. The tree
structure is shown in <xref target="abstract"></xref>. More details are structure is shown in <xref target="abstract-basic" format="default"/>. Mo
provided in Sections <xref format="counter" target="conf"></xref> and re details are
<xref format="counter" target="pre-t"></xref> about the exact structure provided in Sections&nbsp;<xref format="counter" target="conf"/> and
<xref format="counter" target="pre-t"/> about the exact structure
of 'telemetry-setup' and 'telemetry' message types.</t> of 'telemetry-setup' and 'telemetry' message types.</t>
<figure anchor="abstract-basic">
<t><figure anchor="abstract" <name>New DOTS Message Types (YANG Tree Structure)</name>
title="New DOTS Message Types (YANG Tree Structure)"> <sourcecode name="" type="yangtree"><![CDATA[ structure dots-telemetry:
<artwork><![CDATA[ structure dots-telemetry:
+-- (telemetry-message-type)? +-- (telemetry-message-type)?
+--:(telemetry-setup) +--:(telemetry-setup)
| ... | ...
| +-- telemetry* [] | +-- telemetry* []
| ... | ...
| +-- (setup-type)? | +-- (setup-type)?
| +--:(telemetry-config) | +--:(telemetry-config)
| | ... | | ...
| +--:(pipe) | +--:(pipe)
| | ... | | ...
| +--:(baseline) | +--:(baseline)
| ... | ...
+--:(telemetry) +--:(telemetry)
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>DOTS implementations <bcp14>MUST</bcp14> support the Observe Option <xr
<t>DOTS implementations MUST support the Observe Option <xref ef target="RFC7641" format="default"/> for 'tm' (<xref target="pre-t" format="de
target="RFC7641"></xref> for 'tm' (<xref target="pre-t"></xref>).</t> fault"/>).</t>
</section> </section>
<section anchor="conf" numbered="true" toc="default">
<section anchor="conf" title="DOTS Telemetry Setup Configuration"> <name>DOTS Telemetry Setup Configuration</name>
<t>In reference to <xref target="abstract"></xref>, a DOTS telemetry <t>In reference to <xref target="abstract-basic" format="default"/>, a DOT
setup message MUST include only telemetry-related configuration S telemetry
parameters (<xref target="tconfig"></xref>) or information about DOTS setup message <bcp14>MUST</bcp14> include only telemetry-related configura
client domain pipe capacity (<xref target="tpipe"></xref>) or telemetry tion
traffic baseline (<xref target="tbl"></xref>). As such, requests that parameters (<xref target="tconfig" format="default"/>), information about
DOTS
client domain pipe capacity (<xref target="tpipe" format="default"/>), or
information about the telemetry
traffic baseline (<xref target="tbl" format="default"/>). As such, request
s that
include a mix of telemetry configuration, pipe capacity, and traffic include a mix of telemetry configuration, pipe capacity, and traffic
baseline MUST be rejected by DOTS servers with a 4.00 (Bad Request).</t> baseline information <bcp14>MUST</bcp14> be rejected by DOTS servers with
a 4.00 (Bad Request) Response Code.</t>
<t>A DOTS client can reset all installed DOTS telemetry setup <t>A DOTS client can reset all installed DOTS telemetry setup
configuration data following the considerations detailed in <xref configuration data following the considerations detailed in <xref target="
target="reseta"></xref>.</t> reseta" format="default"/>.</t>
<t>A DOTS server may detect conflicts when processing requests related <t>A DOTS server may detect conflicts when processing requests related
to DOTS client domain pipe capacity or telemetry traffic baseline with to DOTS client domain pipe capacity or telemetry traffic baseline informat ion with
requests from other DOTS clients of the same DOTS client domain. More requests from other DOTS clients of the same DOTS client domain. More
details are included in <xref target="conflict"></xref>.</t> details are included in <xref target="conflict" format="default"/>.</t>
<t>Telemetry setup configuration is bound to a DOTS client domain. DOTS <t>Telemetry setup configuration is bound to a DOTS client domain. DOTS
servers MUST NOT expect DOTS clients to send regular requests to refresh servers <bcp14>MUST NOT</bcp14> expect DOTS clients to send regular reques ts to refresh
the telemetry setup configuration. Any available telemetry setup the telemetry setup configuration. Any available telemetry setup
configuration is valid till the DOTS server ceases to service a DOTS configuration is valid until the DOTS server ceases to service a DOTS
client domain. DOTS servers MUST NOT reset 'tsid' because a session client domain. DOTS servers <bcp14>MUST NOT</bcp14> reset 'tsid' because a
session
failed with a DOTS client. DOTS clients update their telemetry setup failed with a DOTS client. DOTS clients update their telemetry setup
configuration upon change of a parameter that may impact attack configuration upon change of a parameter that may impact attack
mitigation.</t> mitigation.</t>
<t>DOTS telemetry setup configuration request and response messages are <t>DOTS telemetry setup configuration request and response messages are
marked as Confirmable messages (Section 2.1 of <xref marked as Confirmable messages (<xref target="RFC7252" sectionFormat="of"
target="RFC7252"></xref>).</t> section="2.1"/>).</t>
<section anchor="tconfig" numbered="true" toc="default">
<section anchor="tconfig" title="Telemetry Configuration"> <name>Telemetry Configuration</name>
<t>DOTS telemetry uses several percentile values to provide a picture <t>DOTS telemetry uses several percentile values to provide a picture
of a traffic distribution overall, as opposed to just a single of a traffic distribution overall, as opposed to just a single
snapshot of observed traffic at a single point in time. Modeling raw snapshot of observed traffic at a single point in time. Modeling raw
traffic flow data as a distribution and describing that distribution traffic flow data as a distribution and describing that distribution
entails choosing a measurement period that the distribution will entails choosing a measurement period that the distribution will
describe, and a number of sampling intervals, or "buckets", within describe, and a number of sampling intervals, or "buckets", within
that measurement period. Traffic within each bucket is treated as a that measurement period. Traffic within each bucket is treated as a
single event (i.e., averaged), and then the distribution of buckets is single event (i.e., averaged), and then the distribution of buckets is
used to describe the distribution of traffic over the measurement used to describe the distribution of traffic over the measurement
period. A distribution can be characterized by statistical measures period. A distribution can be characterized by statistical measures
(e.g., mean, median, and standard deviation), and also by reporting (e.g., mean, median, and standard deviation) and also by reporting
the value of the distribution at various percentile levels of the data the value of the distribution at various percentile levels of the data
set in question (e.g., "quartiles" that correspond to 25th, 50th, and set in question (e.g., "quartiles" that correspond to 25th, 50th, and
75th percentile). More details about percentile values and their 75th percentiles). More details about percentile values and their
computation are found in Section 11.3 of <xref computation are found in <xref target="RFC2330" sectionFormat="of" secti
target="RFC2330"></xref>.</t> on="11.3"/>.</t>
<t>DOTS telemetry uses up to three percentile values, plus the overall <t>DOTS telemetry uses up to three percentile values, plus the overall
peak, to characterize traffic distributions. Which percentile peak, to characterize traffic distributions. Which percentile
thresholds are used for these "low", "medium", and "high" percentile thresholds are used for these "low-percentile", "mid-percentile", and "h
values is configurable. Default values are defined in <xref igh-percentile"
target="PUT"></xref>.</t> values is configurable. Default values are defined in <xref target="PUT"
format="default"/>.</t>
<t>A DOTS client can negotiate with its server(s) a set of telemetry <t>A DOTS client can negotiate with its server(s) a set of telemetry
configuration parameters to be used for telemetry. Such parameters configuration parameters to be used for telemetry. Such parameters
include:</t> include:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Percentile-related measurement parameters. In particular,
<t>Percentile-related measurement parameters. In particular, 'measurement-interval' defines the period during which percentiles a
'measurement-interval' defines the period on which percentiles are re
computed, while 'measurement-sample' defines the time distribution computed, while 'measurement-sample' defines the time distribution
for measuring values that are used to compute percentiles.</t> for measuring values that are used to compute percentiles.</li>
<li>Measurement units.</li>
<t>Measurement units</t> <li>Acceptable percentile values.</li>
<li>Telemetry notification interval.</li>
<t>Acceptable percentile values</t> <li>Acceptable server-originated telemetry.</li>
</ul>
<t>Telemetry notification interval</t> <section anchor="acc" numbered="true" toc="default">
<name>Retrieving the Current DOTS Telemetry Configuration</name>
<t>Acceptable Server-originated telemetry</t>
</list></t>
<t></t>
<section anchor="acc"
title="Retrieve Current DOTS Telemetry Configuration">
<t>A GET request is used to obtain acceptable and current telemetry <t>A GET request is used to obtain acceptable and current telemetry
configuration parameters on the DOTS server. This request may configuration parameters on the DOTS server. This request may
include a 'cdid' Uri-Path when the request is relayed by a DOTS include a 'cdid' Uri-Path when the request is relayed by a DOTS
gateway. An example of such a GET request (without gateway) is gateway. An example of such a GET request (without a gateway) is
depicted in <xref target="GETa"></xref>.</t> depicted in <xref target="GETa" format="default"/>.</t>
<figure anchor="GETa">
<t><figure anchor="GETa" <name>GET to Retrieve the Current and Acceptable DOTS Telemetry Conf
title="GET to Retrieve Current and Acceptable DOTS Telemetry Confi iguration</name>
guration "> <sourcecode name="" type="json"><![CDATA[Header: GET (Code=0.01)
<artwork><![CDATA[Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"]]></artwork> Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
</figure></t> ]]></sourcecode>
</figure>
<t>Upon receipt of such a request, and assuming no error is <t>Upon receipt of such a request, and assuming that no error is
encountered when processing the request, the DOTS server replies encountered when processing the request, the DOTS server replies
with a 2.05 (Content) response that conveys the telemetry parameters with a 2.05 (Content) response that conveys the telemetry parameters
that are acceptable by the DOTS server, any pipe information (<xref that are acceptable to the DOTS server, any pipe information (<xref ta
target="tpipe"></xref>), and the current baseline information (<xref rget="tpipe" format="default"/>), and the current baseline information (<xref ta
target="tbl"></xref>) maintained by the DOTS server for this DOTS rget="tbl" format="default"/>) maintained by the DOTS server for this DOTS
client. The tree structure of the response message body is provided client. The tree structure of the response message body is provided
in <xref target="tree-acceptable"></xref>.</t> in <xref target="tree-acceptable" format="default"/>.</t>
<t>DOTS servers that support the capability of sending telemetry <t>DOTS servers that support the capability of sending telemetry
information to DOTS clients prior to or during a mitigation (<xref information to DOTS clients prior to or during a mitigation (<xref tar
target="premStoC"></xref>) sets 'server-originated-telemetry' under get="premStoC" format="default"/>) set 'server-originated-telemetry' under
'max-config-values' to 'true' ('false' is used otherwise). If 'max-config-values' to 'true' ('false' is used otherwise). If
'server-originated-telemetry' is not present in a response, this is 'server-originated-telemetry' is not present in a response, this is
equivalent to receiving a response with equivalent to receiving a response with
'server-originated-telemetry' set to 'false'.</t> 'server-originated-telemetry' set to 'false'.</t>
<figure anchor="tree-acceptable">
<t><figure anchor="tree-acceptable" <name>Telemetry Configuration Tree Structure</name>
title="Telemetry Configuration Tree Structure"> <sourcecode name="" type="yangtree"><![CDATA[ structure dots-telemetry:
<artwork><![CDATA[ structure dots-telemetry:
+-- (telemetry-message-type)? +-- (telemetry-message-type)?
+--:(telemetry-setup) +--:(telemetry-setup)
| +-- (direction)? | +-- (direction)?
| | +--:(server-to-client-only) | | +--:(server-to-client-only)
| | +-- max-config-values | | +-- max-config-values
| | | +-- measurement-interval? interval | | | +-- measurement-interval? interval
| | | +-- measurement-sample? sample | | | +-- measurement-sample? sample
| | | +-- low-percentile? percentile | | | +-- low-percentile? percentile
| | | +-- mid-percentile? percentile | | | +-- mid-percentile? percentile
| | | +-- high-percentile? percentile | | | +-- high-percentile? percentile
skipping to change at line 962 skipping to change at line 818
| | | +-- unit unit-class | | | +-- unit unit-class
| | | +-- unit-status boolean | | | +-- unit-status boolean
| | +-- server-originated-telemetry? boolean | | +-- server-originated-telemetry? boolean
| | +-- telemetry-notify-interval? uint16 | | +-- telemetry-notify-interval? uint16
| +--:(pipe) | +--:(pipe)
| | ... | | ...
| +--:(baseline) | +--:(baseline)
| ... | ...
+--:(telemetry) +--:(telemetry)
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>When both 'min-config-values' and 'max-config-values' attributes <t>When both 'min-config-values' and 'max-config-values' attributes
are present, the values carried in 'max-config-values' attributes are present, the values carried in 'max-config-values' attributes
MUST be greater or equal to their counterpart in 'min-config-values' <bcp14>MUST</bcp14> be greater than or equal to their counterparts in 'min-config-values'
attributes.</t> attributes.</t>
</section> </section>
<section anchor="PUT" numbered="true" toc="default">
<section anchor="PUT" title="Conveying DOTS Telemetry Configuration"> <name>Conveying the DOTS Telemetry Configuration</name>
<t>A PUT request is used to convey the configuration parameters for <t>A PUT request is used to convey the configuration parameters for
the telemetry data (e.g., low, mid, or high percentile values). For the telemetry data (e.g., low-, mid-, or high-percentile values). For
example, a DOTS client may contact its DOTS server to change the example, a DOTS client may contact its DOTS server to change the
default percentile values used as baseline for telemetry data. <xref default percentile values used as the baseline for telemetry data. <xr
target="tree-acceptable"></xref> lists the attributes that can be ef target="tree-acceptable" format="default"/> lists the attributes that can be
set by a DOTS client in such a PUT request. An example of a DOTS set by a DOTS client in such a PUT request. An example of a DOTS
client that modifies all percentile reference values is shown in client that modifies all percentile reference values is shown in
<xref target="tput"></xref>. <list style="empty"> <xref target="tput" format="default"/>. </t>
<t>Note: The payload of the message depicted in <xref <aside><t>
target="tput"></xref> is CBOR-encoded as indicated by the Note: The payload of the message depicted in <xref target="tput" f
Content-Format set to "application/dots+cbor" (Section 10.3 of ormat="default"/> is CBOR-encoded as indicated by setting the
<xref target="RFC9132"></xref>). However, and for the sake of Content-Format entry to "application/dots+cbor" (<xref target="RFC
9132" sectionFormat="of" section="10.3"/>). However, and for the sake of
better readability, the example (and other similar figures better readability, the example (and other similar figures
depicting a DOTS telemetry message body) follows the conventions depicting a DOTS telemetry message body) follows the conventions
set in <xref target="note-examples"></xref>: use the JSON names set in <xref target="note-examples" format="default"/>: use the JS
and types defined in <xref target="map1"></xref>.</t> ON names
</list></t> and types defined in <xref target="map1" format="default"/>.
</t></aside>
<t><figure anchor="tput" <figure anchor="tput">
title="PUT to Convey the DOTS Telemetry Configuration, depicted as <name>PUT to Convey the DOTS Telemetry Configuration, Depicted as pe
per Section 5.6"> r Section 5.6</name>
<artwork align="left"><![CDATA[Header: PUT (Code=0.03) <sourcecode name="" type="json"><![CDATA[Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=123" Uri-Path: "tsid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
{ {
"current-config": { "current-config": {
"low-percentile": "5.00", "low-percentile": "5.00",
"mid-percentile": "65.00", "mid-percentile": "65.00",
"high-percentile": "95.00" "high-percentile": "95.00"
} }
} }
] ]
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>'cuid' is a mandatory Uri-Path parameter for PUT requests.</t> <t>'cuid' is a mandatory Uri-Path parameter for PUT requests.</t>
<t>The following additional Uri-Path parameter is defined: </t>
<t>The following additional Uri-Path parameter is defined: <list <dl newline="false" spacing="normal">
hangIndent="5" style="hanging"> <dt>tsid:</dt>
<t hangText="tsid:">Telemetry Setup Identifier is an identifier <dd>
<t>The Telemetry Setup Identifier is an identifier
for the DOTS telemetry setup configuration data represented as for the DOTS telemetry setup configuration data represented as
an integer. This identifier MUST be generated by DOTS clients. an integer. This identifier <bcp14>MUST</bcp14> be generated by DO
'tsid' values MUST increase monotonically whenever new TS clients.
'tsid' values <bcp14>MUST</bcp14> increase monotonically whenever
new
configuration parameters (not just for changed values) need to configuration parameters (not just for changed values) need to
be conveyed by the DOTS client. <vspace blankLines="1" />The be conveyed by the DOTS client. </t>
procedure specified in Section 4.4.1 of <xref <t>The
target="RFC9132"></xref> for 'mid' rollover MUST also be procedure specified in <xref target="RFC9132" sectionFormat="of" s
followed for 'tsid' rollover.<vspace blankLines="1" />This is a ection="4.4.1"/> for 'mid' rollover <bcp14>MUST</bcp14> also be
mandatory attribute. 'tsid' MUST appear after 'cuid' in the followed for 'tsid' rollover.</t>
<t>This is a
mandatory attribute. &nbsp;'tsid' <bcp14>MUST</bcp14> appear after
'cuid' in the
Uri-Path options.</t> Uri-Path options.</t>
</list></t> </dd>
</dl>
<t>'cuid' and 'tsid' MUST NOT appear in the PUT request message <t>'cuid' and 'tsid' <bcp14>MUST NOT</bcp14> appear in the PUT request
message
body.</t> body.</t>
<t>At least one configurable attribute <bcp14>MUST</bcp14> be present
<t>At least one configurable attribute MUST be present in the PUT in the PUT
request.</t> request.</t>
<t>A PUT request with a higher numeric 'tsid' value overrides the <t>A PUT request with a higher numeric 'tsid' value overrides the
DOTS telemetry configuration data installed by a PUT request with a DOTS telemetry configuration data installed by a PUT request with a
lower numeric 'tsid' value. To avoid maintaining a long list of lower numeric 'tsid' value. To avoid maintaining a long list of
'tsid' requests for requests carrying telemetry configuration data 'tsid' requests for requests carrying telemetry configuration data
from a DOTS client, the lower numeric 'tsid' MUST be automatically from a DOTS client, the lower numeric 'tsid' <bcp14>MUST</bcp14> be au tomatically
deleted and no longer be available at the DOTS server.</t> deleted and no longer be available at the DOTS server.</t>
<t>The DOTS server indicates the result of processing the PUT <t>The DOTS server indicates the result of processing the PUT
request using the following Response Codes:<list style="symbols"> request using the following Response Codes:</t>
<t>If the request is missing a mandatory attribute, does not <ul spacing="normal">
<li>If the request is missing a mandatory attribute, does not
include 'cuid' or 'tsid' Uri-Path parameters, or contains one or include 'cuid' or 'tsid' Uri-Path parameters, or contains one or
more invalid or unknown parameters, 4.00 (Bad Request) MUST be more invalid or unknown parameters, a 4.00 (Bad Request) Response
returned in the response.</t> Code <bcp14>MUST</bcp14> be
returned in the response.</li>
<t>If the DOTS server does not find the 'tsid' parameter value <li>If the DOTS server does not find the 'tsid' parameter value
conveyed in the PUT request in its configuration data and if the conveyed in the PUT request in its configuration data and if the
DOTS server has accepted the configuration parameters, then a DOTS server has accepted the configuration parameters, then a
2.01 (Created) Response Code MUST be returned in the 2.01 (Created) Response Code <bcp14>MUST</bcp14> be returned in th
response.</t> e
response.</li>
<t>If the DOTS server finds the 'tsid' parameter value conveyed <li>If the DOTS server finds the 'tsid' parameter value conveyed
in the PUT request in its configuration data and if the DOTS in the PUT request in its configuration data and if the DOTS
server has accepted the updated configuration parameters, 2.04 server has accepted the updated configuration parameters, a 2.04
(Changed) MUST be returned in the response.</t> (Changed) Response Code <bcp14>MUST</bcp14> be returned in the res
ponse.</li>
<li>
<t>If any of the enclosed configurable attribute values are not <t>If any of the enclosed configurable attribute values are not
acceptable to the DOTS server (<xref target="acc"></xref>), 4.22 acceptable to the DOTS server (<xref target="acc" format="default"
(Unprocessable Entity) MUST be returned in the response. <vspace />), a 4.22
blankLines="1" />The DOTS client may retry and send the PUT (Unprocessable Entity) Response Code <bcp14>MUST</bcp14> be return
ed in the response. </t>
<t>The DOTS client may retry and send the PUT
request with updated attribute values acceptable to the DOTS request with updated attribute values acceptable to the DOTS
server.</t> server.</t>
</list></t> </li>
</ul>
<t>By default, low percentile (10th percentile), mid percentile <t>By default, low-percentile (10th percentile), mid-percentile
(50th percentile), high percentile (90th percentile), and peak (50th percentile), high-percentile (90th percentile), and peak
(100th percentile) values are used to represent telemetry data. (100th percentile) values are used to represent telemetry data.
Nevertheless, a DOTS client can disable some percentile types (low, Nevertheless, a DOTS client can disable some percentile types (low,
mid, high). In particular, setting 'low-percentile' to '0.00' mid, high). In particular, setting 'low-percentile' to "0.00"
indicates that the DOTS client is not interested in receiving indicates that the DOTS client is not interested in receiving
low-percentiles. Likewise, setting 'mid-percentile' (or low-percentiles. Likewise, setting 'mid-percentile' (or
'high-percentile') to the same value as 'low-percentile' (or 'high-percentile') to the same value as 'low-percentile' (or
'mid-percentile') indicates that the DOTS client is not interested 'mid-percentile') indicates that the DOTS client is not interested
in receiving mid-percentiles (or high-percentiles). For example, a in receiving mid-percentiles (or high-percentiles). For example, a
DOTS client can send the request depicted in <xref DOTS client can send the request depicted in <xref target="tput1" form
target="tput1"></xref> to inform the server that it is interested in at="default"/> to inform the server that it is interested in
receiving only high-percentiles. This assumes that the client will receiving only high-percentiles. This assumes that the client will
only use that percentile type when sharing telemetry data with the only use that percentile type when sharing telemetry data with the
server.</t> server.</t>
<figure anchor="tput1">
<t><figure anchor="tput1" <name>PUT to Disable Low- and Mid-Percentiles, Depicted as per Secti
title="PUT to Disable Low- and Mid-Percentiles, depicted as per Se on 5.6</name>
ction 5.6 "> <sourcecode name="" type="json"><![CDATA[Header: PUT (Code=0.03)
<artwork align="left"><![CDATA[Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=124" Uri-Path: "tsid=124"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
{ {
"current-config": { "current-config": {
"low-percentile": "0.00", "low-percentile": "0.00",
"mid-percentile": "0.00", "mid-percentile": "0.00",
"high-percentile": "95.00" "high-percentile": "95.00"
} }
} }
] ]
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>DOTS clients can also configure the unit class(es) to be used for <t>DOTS clients can also configure the unit class(es) to be used for
traffic-related telemetry data among the following supported unit traffic-related telemetry data among the following supported unit
classes: packets per second, bits per second, and bytes per second. classes: packets per second, bits per second, and bytes per second.
Supplying both bits per second and bytes per second unit-classes is Supplying both bits per second and bytes per second unit classes is
allowed for a given telemetry data. However, receipt of conflicting allowed for a given set of telemetry data. However, receipt of conflic
values is treated as invalid parameters and rejected with 4.00 (Bad ting
Request).</t> values is treated as invalid parameters and rejected with a 4.00 (Bad
Request) Response Code.</t>
<t>DOTS clients that are interested to receive pre or ongoing <t>DOTS clients that are interested in receiving pre-or-ongoing-
mitigation telemetry (pre-or-ongoing-mitigation) information from a mitigation telemetry ('pre-or-ongoing-mitigation') information from a
DOTS server (<xref target="premStoC"></xref>) MUST set DOTS server (<xref target="premStoC" format="default"/>) <bcp14>MUST</
bcp14> set
'server-originated-telemetry' to 'true'. If 'server-originated-telemetry' to 'true'. If
'server-originated-telemetry' is not present in a PUT request, this 'server-originated-telemetry' is not present in a PUT request, this
is equivalent to receiving a request with is equivalent to receiving a request with
'server-originated-telemetry' set to 'false'. An example of a 'server-originated-telemetry' set to 'false'. An example of a
request to enable pre-or-ongoing-mitigation telemetry from DOTS request to enable pre-or-ongoing-mitigation telemetry from DOTS
servers is shown in <xref target="tput2"></xref>.</t> servers is shown in <xref target="tput2" format="default"/>.</t>
<figure anchor="tput2">
<t><figure anchor="tput2" <name>PUT to Enable Pre-or-Ongoing-Mitigation Telemetry from the DOT
title="PUT to Enable Pre-or-ongoing-mitigation Telemetry from the S Server, Depicted as per Section 5.6</name>
DOTS server, depicted as per Section 5.6"> <sourcecode name="" type="json"><![CDATA[Header: PUT (Code=0.03)
<artwork align="left"><![CDATA[Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=125" Uri-Path: "tsid=125"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
{ {
"current-config": { "current-config": {
"server-originated-telemetry": true "server-originated-telemetry": true
} }
} }
] ]
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t></t>
<t></t>
</section> </section>
<section anchor="GET" numbered="true" toc="default">
<section anchor="GET" <name>Retrieving the Installed DOTS Telemetry Configuration</name>
title="Retrieve Installed DOTS Telemetry Configuration"> <t>A DOTS client may issue a GET message with a 'tsid' Uri-Path
<t>A DOTS client may issue a GET message with 'tsid' Uri-Path
parameter to retrieve the current DOTS telemetry configuration. An parameter to retrieve the current DOTS telemetry configuration. An
example of such a request is depicted in <xref example of such a request is depicted in <xref target="GETs" format="d
target="GETs"></xref>.</t> efault"/>.</t>
<figure anchor="GETs">
<t><figure anchor="GETs" <name>GET to Retrieve the Current DOTS Telemetry Configuration</name
title="GET to Retrieve Current DOTS Telemetry Configuration"> >
<artwork><![CDATA[Header: GET (Code=0.01) <sourcecode name="" type="json"><![CDATA[Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=123"]]></artwork> Uri-Path: "tsid=123"
</figure></t> ]]></sourcecode>
</figure>
<t>If the DOTS server does not find the 'tsid' Uri-Path value <t>If the DOTS server does not find the 'tsid' Uri-Path value
conveyed in the GET request in its configuration data for the conveyed in the GET request in its configuration data for the
requesting DOTS client, it MUST respond with a 4.04 (Not Found) requesting DOTS client, it <bcp14>MUST</bcp14> respond with a 4.04 (No t Found)
error Response Code.</t> error Response Code.</t>
</section> </section>
<section anchor="DEL" numbered="true" toc="default">
<section anchor="DEL" title="Delete DOTS Telemetry Configuration"> <name>Deleting the DOTS Telemetry Configuration</name>
<t>A DELETE request is used to delete the installed DOTS telemetry <t>A DELETE request is used to delete the installed DOTS telemetry
configuration data (<xref target="cdelete"></xref>). 'cuid' and configuration data (<xref target="cdelete" format="default"/>). &nbsp; 'cuid' and
'tsid' are mandatory Uri-Path parameters for such DELETE 'tsid' are mandatory Uri-Path parameters for such DELETE
requests.</t> requests.</t>
<figure anchor="cdelete">
<figure anchor="cdelete" title="Delete Telemetry Configuration"> <name>Deleting the Telemetry Configuration</name>
<artwork align="left"><![CDATA[Header: DELETE (Code=0.04) <sourcecode name="" type="json"><![CDATA[Header: DELETE (Code=0.04)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=123" Uri-Path: "tsid=123"
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t></t>
<t>The DOTS server resets the DOTS telemetry configuration back to <t>The DOTS server resets the DOTS telemetry configuration back to
the default values and acknowledges a DOTS client's request to the default values and acknowledges a DOTS client's request to
remove the DOTS telemetry configuration using 2.02 (Deleted) remove the DOTS telemetry configuration using a 2.02 (Deleted)
Response Code. A 2.02 (Deleted) Response Code is returned even if Response Code. A 2.02 (Deleted) Response Code is returned even if
the 'tsid' parameter value conveyed in the DELETE request does not the 'tsid' parameter value conveyed in the DELETE request does not
exist in its configuration data before the request.</t> exist in its configuration data before the request.</t>
<t><xref target="reseta" format="default"/> discusses the procedure to
<t><xref target="reseta"></xref> discusses the procedure to reset reset
all DOTS telemetry setup configuration.</t> all DOTS telemetry setup configuration data.</t>
</section> </section>
</section> </section>
<section anchor="tpipe" numbered="true" toc="default">
<section anchor="tpipe" title="Total Pipe Capacity"> <name>Total Pipe Capacity</name>
<t>A DOTS client can communicate to the DOTS server(s) its DOTS client <t>A DOTS client can communicate to the DOTS server(s) its DOTS client
domain pipe information. The tree structure of the pipe information is domain pipe information. The tree structure of the pipe information is
shown in <xref target="ptree"></xref>.</t> shown in <xref target="ptree" format="default"/>.</t>
<figure anchor="ptree">
<t><figure anchor="ptree" title="Pipe Tree Structure"> <name>Pipe Tree Structure</name>
<artwork><![CDATA[ structure dots-telemetry: <sourcecode name="" type="yangtree"><![CDATA[ structure dots-telemetry:
+-- (telemetry-message-type)? +-- (telemetry-message-type)?
+--:(telemetry-setup) +--:(telemetry-setup)
| ... | ...
| +-- telemetry* [] | +-- telemetry* []
| +-- (direction)? | +-- (direction)?
| | +--:(server-to-client-only) | | +--:(server-to-client-only)
| | +-- tsid? uint32 | | +-- tsid? uint32
| +-- (setup-type)? | +-- (setup-type)?
| +--:(telemetry-config) | +--:(telemetry-config)
| | ... | | ...
| +--:(pipe) | +--:(pipe)
| | +-- total-pipe-capacity* [link-id unit] | | +-- total-pipe-capacity* [link-id unit]
| | +-- link-id nt:link-id | | +-- link-id nt:link-id
| | +-- capacity uint64 | | +-- capacity uint64
| | +-- unit unit | | +-- unit unit
| +--:(baseline) | +--:(baseline)
| ... | ...
+--:(telemetry) +--:(telemetry)
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>A DOTS client domain pipe is defined as a list of limits on
<t>A DOTS client domain pipe is defined as a list of limits of
(incoming) traffic volume ('total-pipe-capacity') that can be (incoming) traffic volume ('total-pipe-capacity') that can be
forwarded over ingress interconnection links of a DOTS client domain. forwarded over ingress interconnection links of a DOTS client domain.
Each of these links is identified with a 'link-id' <xref Each of these links is identified with a 'link-id' <xref target="RFC8345
target="RFC8345"></xref>.</t> " format="default"/>.</t>
<t>The unit used by a DOTS client when conveying pipe information is <t>The unit used by a DOTS client when conveying pipe information is
captured in the 'unit' attribute. The DOTS client MUST auto-scale so captured in the 'unit' attribute. The DOTS client <bcp14>MUST</bcp14> au to-scale so
that the appropriate unit is used. That is, for a given unit class, that the appropriate unit is used. That is, for a given unit class,
the DOTS client uses the largest unit that gives a value greater than the DOTS client uses the largest unit that gives a value greater than
one. As such, only one unit per unit class is allowed.</t> one. As such, only one unit per unit class is allowed.</t>
<section numbered="true" toc="default">
<section title="Conveying DOTS Client Domain Pipe Capacity"> <name>Conveying DOTS Client Domain Pipe Capacity</name>
<t>Similar considerations to those specified in <xref <t>Considerations similar to those specified in <xref target="PUT" for
target="PUT"></xref> are followed with one exception:<list mat="default"/> are followed, with one exception:</t>
style="empty"> <ul spacing="normal">
<t>The relative order of two PUT requests carrying DOTS client <li>The relative order of two PUT requests carrying DOTS client
domain pipe attributes from a DOTS client is determined by domain pipe attributes from a DOTS client is determined by
comparing their respective 'tsid' values. If such two requests comparing their respective 'tsid' values. If these two requests
have overlapping 'link-id' and 'unit', the PUT request with have overlapping 'link-id' and 'unit' settings, the PUT request wi
th a
higher numeric 'tsid' value will override the request with a higher numeric 'tsid' value will override the request with a
lower numeric 'tsid' value. The overlapped lower numeric 'tsid' lower numeric 'tsid' value. The overlapped lower numeric 'tsid'
MUST be automatically deleted and no longer be available.</t> <bcp14>MUST</bcp14> be automatically deleted and no longer be avai
</list></t> lable.</li>
</ul>
<t>DOTS clients SHOULD minimize the number of active 'tsid's used <t>DOTS clients <bcp14>SHOULD</bcp14> minimize the number of active 't
sid's used
for pipe information. In order to avoid maintaining a long list of for pipe information. In order to avoid maintaining a long list of
'tsid's for pipe information, it is RECOMMENDED that DOTS clients 'tsid's for pipe information, it is <bcp14>RECOMMENDED</bcp14> that DO TS clients
include in any request to update information related to a given link include in any request to update information related to a given link
the information of other links (already communicated using a lower the information regarding other links (already communicated using a lo
'tsid' value). Doing so, this update request will override these wer
existing requests and hence optimize the number of 'tsid' request 'tsid' value). By doing so, this update request will override these
per DOTS client. <list style="symbols"> existing requests and hence optimize the number of 'tsid' requests
<t>Note: This assumes that all link information can fit in one per DOTS client. </t>
single message.</t> <aside><t>
</list></t> Note: This assumes that all link information can fit in one
single message.
</t></aside>
<t>As an example of configuring pipe information, a DOTS client <t>As an example of configuring pipe information, a DOTS client
managing a single homed domain (<xref target="single"></xref>) can managing a single-homed domain (<xref target="single" format="default"
send a PUT request (shown in <xref target="putp1"></xref>) to />) can
send a PUT request (shown in <xref target="putp1" format="default"/>)
to
communicate the capacity of "link1" used to connect to its ISP.</t> communicate the capacity of "link1" used to connect to its ISP.</t>
<figure anchor="single">
<t><figure anchor="single" title="Single Homed DOTS Client Domain"> <name>Single-Homed DOTS Client Domain</name>
<artwork><![CDATA[ ,--,--,--. ,-- <artwork name="" type="" align="left" alt=""><![CDATA[
,--,--. ,--,--,--. ,--,--,--.
,-' `-. ,-' `-. ,-' `-. ,-' `-.
( DOTS Client )=====( ISP#A ) ( DOTS Client )=====( ISP#A )
`-. Domain ,-' link1 `-. ,-' `-. Domain ,-' link1 `-. ,-'
`--'--'--' `--'--'--']]></artwork> `--'--'--' `--'--'--'
</figure></t> ]]></artwork>
</figure>
<t><figure anchor="putp1" <figure anchor="putp1">
title="Example of a PUT Request to Convey Pipe Information (Single <name>Example of a PUT Request to Convey Pipe Information (Single-Ho
Homed), depicted as per Section 5.6 "> med), Depicted as per Section 5.6</name>
<artwork align="left"><![CDATA[Header: PUT (Code=0.03) <sourcecode name="" type="json"><![CDATA[Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=126" Uri-Path: "tsid=126"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
skipping to change at line 1318 skipping to change at line 1146
{ {
"link-id": "link1", "link-id": "link1",
"capacity": "500", "capacity": "500",
"unit": "megabit-ps" "unit": "megabit-ps"
} }
] ]
} }
] ]
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>DOTS clients may be instructed to signal a link aggregate instead <t>DOTS clients may be instructed to signal a link aggregate instead
of individual links. For example, a DOTS client that manages a DOTS of individual links. For example, a DOTS client that manages a DOTS
client domain having two interconnection links with an upstream ISP client domain having two interconnection links with an upstream ISP
(<xref target="singleagg"></xref>) can send a PUT request (shown in (<xref target="singleagg" format="default"/>) can send a PUT request (
<xref target="putp1a"></xref>) to communicate the aggregate link shown in
<xref target="putp1a" format="default"/>) to communicate the aggregate
link
capacity with its ISP. Signaling individual or aggregate link capacity with its ISP. Signaling individual or aggregate link
capacity is deployment specific.</t> capacity is deployment specific.</t>
<figure anchor="singleagg">
<t><figure anchor="singleagg" <name>DOTS Client Domain with Two Interconnection Links</name>
title="DOTS Client Domain with Two Interconnection Links"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ ,--,--,--. ,-- ,--,--,--. ,--,--,--.
,--,--.
,-' `-.===== ,-' `-. ,-' `-.===== ,-' `-.
( DOTS Client ) ( ISP#C ) ( DOTS Client ) ( ISP#C )
`-. Domain ,-'====== `-. ,-' `-. Domain ,-'====== `-. ,-'
`--'--'--' `--'--'--']]></artwork> `--'--'--' `--'--'--'
</figure></t> ]]></artwork>
</figure>
<t><figure anchor="putp1a" <figure anchor="putp1a">
title="Example of a PUT Request to Convey Pipe Information (Aggreg <name>Example of a PUT Request to Convey Pipe Information (Aggregate
ated Link), depicted as per Section 5.6 "> d Link), Depicted as per Section 5.6</name>
<artwork align="left"><![CDATA[Header: PUT (Code=0.03) <sourcecode name="" type="json"><![CDATA[Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=hmcpH87lmPGsSTjkhXCbin" Uri-Path: "cuid=hmcpH87lmPGsSTjkhXCbin"
Uri-Path: "tsid=896" Uri-Path: "tsid=896"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
skipping to change at line 1363 skipping to change at line 1189
{ {
"link-id": "aggregate", "link-id": "aggregate",
"capacity": "700", "capacity": "700",
"unit": "megabit-ps" "unit": "megabit-ps"
} }
] ]
} }
] ]
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>Now consider that the DOTS client domain was upgraded to connect <t>Now consider that the DOTS client domain was upgraded to connect
to an additional ISP (e.g., ISP#B of <xref target="multi"></xref>); to an additional ISP (e.g., ISP#B in <xref target="multi" format="defa ult"/>);
the DOTS client can inform a DOTS server that is not hosted with the DOTS client can inform a DOTS server that is not hosted with
ISP#A and ISP#B domains about this update by sending the PUT request ISP#A and ISP#B domains about this update by sending the PUT request
depicted in <xref target="putp2"></xref>. This request also includes depicted in <xref target="putp2" format="default"/>. This request also includes
information related to "link1" even if that link is not upgraded. information related to "link1" even if that link is not upgraded.
Upon receipt of this request, the DOTS server removes the request Upon receipt of this request, the DOTS server removes the request
with 'tsid=126' and updates its configuration base to maintain two with 'tsid=126' and updates its configuration base to maintain two
links (link#1 and link#2).</t> links (link1 and link2).</t>
<figure anchor="multi">
<t><figure anchor="multi" title="Multi-Homed DOTS Client Domain"> <name>Multihomed DOTS Client Domain</name>
<artwork><![CDATA[ ,--,--,--. <artwork name="" type="" align="left" alt=""><![CDATA[
,--,--,--.
,-' `-. ,-' `-.
( ISP#B ) ( ISP#B )
`-. ,-' `-. ,-'
`--'--'--' `--'--'--'
|| ||
|| link2 || link2
,--,--,--. ,--,--,--. ,--,--,--. ,--,--,--.
,-' `-. ,-' `-. ,-' `-. ,-' `-.
( DOTS Client )=====( ISP#A ) ( DOTS Client )=====( ISP#A )
`-. Domain ,-' link1 `-. ,-' `-. Domain ,-' link1 `-. ,-'
`--'--'--' `--'--'--' `--'--'--' `--'--'--'
]]></artwork> ]]></artwork>
</figure></t> </figure>
<figure anchor="putp2">
<t><figure anchor="putp2" <name>Example of a PUT Request to Convey Pipe Information (Multihome
title="Example of a PUT Request to Convey Pipe Information (Multi- d), Depicted as per Section 5.6</name>
Homed), depicted as per Section 5.6"> <sourcecode name="" type="json"><![CDATA[Header: PUT (Code=0.03)
<artwork align="left"><![CDATA[Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=127" Uri-Path: "tsid=127"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
skipping to change at line 1422 skipping to change at line 1246
{ {
"link-id": "link2", "link-id": "link2",
"capacity": "500", "capacity": "500",
"unit": "megabit-ps" "unit": "megabit-ps"
} }
] ]
} }
] ]
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>A DOTS client can delete a link by sending a PUT request with the <t>A DOTS client can delete a link by sending a PUT request with the
'capacity' attribute set to "0" if other links are still active for 'capacity' attribute set to "0" if other links are still active for
the same DOTS client domain (see <xref target="pdel"></xref> for the same DOTS client domain. For example, if a DOTS client domain re-h
other delete cases). For example, if a DOTS client domain re-homes omes
(that is, it changes its ISP), the DOTS client can inform its DOTS (that is, it changes its ISP), the DOTS client can inform its DOTS
server about this update (e.g., from the network configuration in server about this update (e.g., from the network configuration in
<xref target="single"></xref> to the one shown in <xref <xref target="single" format="default"/> to the network configuration
target="single2"></xref>) by sending the PUT request depicted in shown in <xref target="single2" format="default"/>) by sending the PUT request d
<xref target="putp3"></xref>. Upon receipt of this request, and epicted in
assuming no error is encountered when processing the request, the <xref target="putp3" format="default"/>. Upon receipt of this request,
and
assuming that no error is encountered when processing the request, the
DOTS server removes "link1" from its configuration bases for this DOTS server removes "link1" from its configuration bases for this
DOTS client domain. Note that if the DOTS server receives a PUT DOTS client domain. Note that if the DOTS server receives a PUT
request with a 'capacity' attribute set to "0" for all included request with a 'capacity' attribute set to "0" for all included
links, it MUST reject the request with a 4.00 (Bad Request). links, it <bcp14>MUST</bcp14> reject the request with a 4.00 (Bad Requ est) Response Code.
Instead, the DOTS client can use a DELETE request to delete all Instead, the DOTS client can use a DELETE request to delete all
links (<xref target="pdel"></xref>).</t> links (<xref target="pdel" format="default"/>).</t>
<figure anchor="single2">
<t><figure anchor="single2" title="Multi-Homed DOTS Client Domain"> <name>Multihomed DOTS Client Domain</name>
<artwork><![CDATA[ ,--,--,--. <artwork name="" type="" align="left" alt=""><![CDATA[
,--,--,--.
,-' `-. ,-' `-.
( ISP#B ) ( ISP#B )
`-. ,-' `-. ,-'
`--'--'--' `--'--'--'
|| ||
|| link2 || link2
,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
( DOTS Client ) ( DOTS Client )
`-. Domain ,-' `-. Domain ,-'
`--'--'--' ]]></artwork> `--'--'--'
</figure><figure anchor="putp3" ]]></artwork>
title="Example of a PUT Request to Convey Pipe Information (Multi- </figure>
Homed), depicted as per Section 5.6"> <figure anchor="putp3">
<artwork align="left"><![CDATA[Header: PUT (Code=0.03) <name>Example of a PUT Request to Convey Pipe Information (Multihome
d), Depicted as per Section 5.6</name>
<sourcecode name="" type="json"><![CDATA[Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=128" Uri-Path: "tsid=128"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
skipping to change at line 1485 skipping to change at line 1308
{ {
"link-id": "link2", "link-id": "link2",
"capacity": "500", "capacity": "500",
"unit": "megabit-ps" "unit": "megabit-ps"
} }
] ]
} }
] ]
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Retrieve Installed DOTS Client Domain Pipe Capacity"> <name>Retrieving Installed DOTS Client Domain Pipe Capacity</name>
<t>A GET request with 'tsid' Uri-Path parameter is used to retrieve <t>A GET request with a 'tsid' Uri-Path parameter is used to retrieve
a specific installed DOTS client domain pipe related information. the
The same procedure as defined in <xref target="GET"></xref> is specific information related to an installed DOTS client domain pipe.
The same procedure as that defined in <xref target="GET" format="defau
lt"/> is
followed.</t> followed.</t>
<t>To retrieve all pipe information bound to a DOTS client, the DOTS <t>To retrieve all pipe information bound to a DOTS client, the DOTS
client proceeds as specified in <xref target="acc"></xref>.</t> client proceeds as specified in <xref target="acc" format="default"/>. </t>
</section> </section>
<section anchor="pdel" numbered="true" toc="default">
<section anchor="pdel" <name>Deleting Installed DOTS Client Domain Pipe Capacity</name>
title="Delete Installed DOTS Client Domain Pipe Capacity"> <t>A DELETE request is used to delete the specific information related
<t>A DELETE request is used to delete the installed DOTS client to an installed DOTS client domain pipe. The same procedure as that defined in
domain pipe related information. The same procedure as defined in <xref target="DEL" format="default"/> is followed.</t>
<xref target="DEL"></xref> is followed.</t>
</section> </section>
</section> </section>
<section anchor="tbl" numbered="true" toc="default">
<section anchor="tbl" title="Telemetry Baseline"> <name>Telemetry Baseline</name>
<t>A DOTS client can communicate to its DOTS server(s) its normal <t>A DOTS client can communicate to its DOTS server(s) its normal
traffic baseline and connections capacity:<list style="hanging"> traffic baseline and connection capacity:</t>
<t hangText="Total traffic normal baseline:">The percentile values <dl newline="false" spacing="normal">
<dt>Total traffic normal baseline:</dt>
<dd>
<t>Total traffic normal baseline data provides the percentile values
representing the total traffic normal baseline. It can be representing the total traffic normal baseline. It can be
represented for a target using 'total-traffic-normal'.<vspace represented for a target using 'total-traffic-normal'.</t>
blankLines="1" />The traffic normal per-protocol <t>The traffic normal per-protocol
('total-traffic-normal-per-protocol') baseline is represented for ('total-traffic-normal-per-protocol') baseline is represented for
a target and is transport-protocol specific.<vspace a target and is transport-protocol specific.</t>
blankLines="1" />The traffic normal per-port-number <t>The traffic normal per-port-number
('total-traffic-normal-per-port') baseline is represented for each ('total-traffic-normal-per-port') baseline is represented for each
port number bound to a target.<vspace blankLines="1" />If the DOTS port number bound to a target.</t>
client negotiated percentile values and units (<xref <t>If the DOTS
target="tconfig"></xref>), these negotiated parameters will be client negotiated percentile values and units (<xref target="tconfig
used instead of the default ones. For each used unit class, the " format="default"/>), these negotiated parameters will be
DOTS client MUST auto-scale so that the appropriate unit is used instead of the default parameters. For each unit class used, th
e
DOTS client <bcp14>MUST</bcp14> auto-scale so that the appropriate u
nit is
used.</t> used.</t>
</dd>
<t hangText="Total connections capacity:">If the target is <dt>Total connection capacity:</dt>
<dd>
<t>If the target is
susceptible to resource-consuming DDoS attacks, the following susceptible to resource-consuming DDoS attacks, the following
optional attributes for the target per transport protocol are optional attributes for the target per transport protocol are
useful to detect resource-consuming DDoS attacks:<list useful for detecting resource-consuming DDoS attacks:</t>
style="symbols"> <ul spacing="normal">
<t>The maximum number of simultaneous connections that are <li>The maximum number of simultaneous connections that are
allowed to the target.</t> allowed to the target.</li>
<li>The maximum number of simultaneous connections that are
<t>The maximum number of simultaneous connections that are allowed to the target per client.</li>
allowed to the target per client.</t> <li>The maximum number of simultaneous embryonic connections
<t>The maximum number of simultaneous embryonic connections
that are allowed to the target. The term "embryonic that are allowed to the target. The term "embryonic
connection" refers to a connection whose connection handshake connection" refers to a connection whose connection handshake
is not finished. Embryonic connection is only possible in is not finished. Embryonic connections are only possible in
connection-oriented transport protocols like TCP or Stream connection-oriented transport protocols like TCP or the Stream
Control Transmission Protocol (SCTP) <xref Control Transmission Protocol (SCTP) <xref target="RFC9260" form
target="RFC4960"></xref>.</t> at="default"/>.</li>
<li>The maximum number of simultaneous embryonic connections
<t>The maximum number of simultaneous embryonic connections that are allowed to the target per client.</li>
that are allowed to the target per client.</t> <li>The maximum number of connections allowed per second to the
target.</li>
<t>The maximum number of connections allowed per second to the <li>The maximum number of connections allowed per second to the
target.</t> target per client.</li>
<li>The maximum number of requests (e.g., HTTP/DNS/SIP
<t>The maximum number of connections allowed per second to the requests) allowed per second to the target.</li>
target per client.</t> <li>The maximum number of requests allowed per second to the
target per client.</li>
<t>The maximum number of requests (e.g., HTTP/DNS/SIP <li>The maximum number of outstanding partial requests allowed
requests) allowed per second to the target.</t>
<t>The maximum number of requests allowed per second to the
target per client.</t>
<t>The maximum number of outstanding partial requests allowed
to the target. Attacks relying upon partial requests create a to the target. Attacks relying upon partial requests create a
connection with a target but do not send a complete request connection with a target but do not send a complete request
(e.g., HTTP request).</t> (e.g., an HTTP request).</li>
<li>The maximum number of outstanding partial requests allowed
<t>The maximum number of outstanding partial requests allowed to the target per client.</li>
to the target per client.</t> </ul>
</list><vspace blankLines="1" />The aggregate per transport <t>The aggregate per transport
protocol is captured in 'total-connection-capacity', while protocol is captured in 'total-connection-capacity', while
port-specific capabilities are represented using port-specific capabilities are represented using
'total-connection-capacity-per-port'.</t> 'total-connection-capacity-per-port'.</t>
</list></t> </dd>
</dl>
<t>Note that a target resource is identified using the attributes <t>Note that a target resource is identified using the attributes
'target-prefix', 'target-port-range', 'target-protocol', 'target- 'target-prefix', 'target-port-range', 'target-protocol', 'target-
fqdn', 'target-uri', or 'alias-name' defined in Section 4.4.1.1 of fqdn', 'target-uri', or 'alias-name' as defined in <xref target="RFC9132
<xref target="RFC9132"></xref>.</t> " sectionFormat="of" section="4.4.1.1"/>.</t>
<t>The tree structure of the normal traffic baseline is shown in <xref t
<t>The tree structure of the normal traffic baseline is shown in <xref arget="bltree" format="default"/>.</t>
target="bltree"></xref>.</t> <figure anchor="bltree">
<name>Telemetry Baseline Tree Structure</name>
<t><figure anchor="bltree" title="Telemetry Baseline Tree Structure"> <sourcecode name="" type="yangtree"><![CDATA[ structure dots-telemetry:
<artwork><![CDATA[ structure dots-telemetry:
+-- (telemetry-message-type)? +-- (telemetry-message-type)?
+--:(telemetry-setup) +--:(telemetry-setup)
| ... | ...
| +-- telemetry* [] | +-- telemetry* []
| +-- (direction)? | +-- (direction)?
| | +--:(server-to-client-only) | | +--:(server-to-client-only)
| | +-- tsid? uint32 | | +-- tsid? uint32
| +-- (setup-type)? | +-- (setup-type)?
| +--:(telemetry-config) | +--:(telemetry-config)
| | ... | | ...
| +--:(pipe) | +--:(pipe)
| | ... | | ...
| +--:(baseline) | +--:(baseline)
| +-- baseline* [id] | +-- baseline* [id]
| +-- id | +-- id uint32
| | uint32
| +-- target-prefix* | +-- target-prefix*
| | inet:ip-prefix | | inet:ip-prefix
| +-- target-port-range* [lower-port] | +-- target-port-range* [lower-port]
| | +-- lower-port inet:port-number | | +-- lower-port inet:port-number
| | +-- upper-port? inet:port-number | | +-- upper-port? inet:port-number
| +-- target-protocol* uint8 | +-- target-protocol* uint8
| +-- target-fqdn* | +-- target-fqdn*
| | inet:domain-name | | inet:domain-name
| +-- target-uri* | +-- target-uri*
| | inet:uri | | inet:uri
skipping to change at line 1660 skipping to change at line 1472
| +-- embryonic? uint64 | +-- embryonic? uint64
| +-- embryonic-client? uint64 | +-- embryonic-client? uint64
| +-- connection-ps? uint64 | +-- connection-ps? uint64
| +-- connection-client-ps? uint64 | +-- connection-client-ps? uint64
| +-- request-ps? uint64 | +-- request-ps? uint64
| +-- request-client-ps? uint64 | +-- request-client-ps? uint64
| +-- partial-request-max? uint64 | +-- partial-request-max? uint64
| +-- partial-request-client-max? uint64 | +-- partial-request-client-max? uint64
+--:(telemetry) +--:(telemetry)
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>A DOTS client can share one or multiple normal traffic baselines <t>A DOTS client can share one or multiple normal traffic baselines
(e.g., aggregate or per-prefix baselines), each are uniquely (e.g., aggregate or per-prefix baselines); each is uniquely
identified within the DOTS client domain with an identifier 'id'. This identified within the DOTS client domain with an identifier ('id'). This
identifier can be used to update a baseline entry, delete a specific identifier can be used to update a baseline entry, delete a specific
entry, etc.</t> entry, etc.</t>
<section numbered="true" toc="default">
<section title="Conveying DOTS Client Domain Baseline Information"> <name>Conveying DOTS Client Domain Baseline Information</name>
<t>Similar considerations to those specified in <xref <t>Considerations similar to those specified in <xref target="PUT" for
target="PUT"></xref> are followed with one exception:<list mat="default"/> are followed, with one exception:</t>
style="empty"> <ul spacing="normal">
<t>The relative order of two PUT requests carrying DOTS client <li>The relative order of two PUT requests carrying DOTS client
domain baseline attributes from a DOTS client is determined by domain baseline attributes from a DOTS client is determined by
comparing their respective 'tsid' values. If such two requests comparing their respective 'tsid' values. If these two requests
have overlapping targets, the PUT request with higher numeric have overlapping targets, the PUT request with a higher numeric
'tsid' value will override the request with a lower numeric 'tsid' value will override the request with a lower numeric
'tsid' value. The overlapped lower numeric 'tsid' MUST be 'tsid' value. The overlapped lower numeric 'tsid' <bcp14>MUST</bcp
automatically deleted and no longer be available.</t> 14> be
</list></t> automatically deleted and no longer be available.</li>
</ul>
<t>Two PUT requests from a DOTS client have overlapping targets if <t>Two PUT requests from a DOTS client have overlapping targets if
there is a common IP address, IP prefix, FQDN, URI, or alias-name. there is a common IP address, IP prefix, FQDN, URI, or alias name.
Also, two PUT requests from a DOTS client have overlapping targets Also, two PUT requests from a DOTS client have overlapping targets
from the perspective of the DOTS server if the addresses associated from the perspective of the DOTS server if the addresses associated
with the FQDN, URI, or alias are overlapping with each other or with with the FQDN, URI, or alias are overlapping with each other or with
'target-prefix'.</t> 'target-prefix'.</t>
<t>DOTS clients <bcp14>SHOULD</bcp14> minimize the number of active 't
<t>DOTS clients SHOULD minimize the number of active 'tsid's used sid's used
for baseline information. In order to avoid maintaining a long list for baseline information. In order to avoid maintaining a long list
of 'tsid's for baseline information, it is RECOMMENDED that DOTS of 'tsid's for baseline information, it is <bcp14>RECOMMENDED</bcp14>
clients include in a request to update information related to a that DOTS
given target, the information of other targets (already communicated clients include in any request to update information related to a
using a lower 'tsid' value) (assuming this fits within one single given target the information regarding other targets (already communic
ated
using a lower 'tsid' value) (assuming that this information fits withi
n one single
datagram). This update request will override these existing requests datagram). This update request will override these existing requests
and hence optimize the number of 'tsid' request per DOTS client.</t> and hence optimize the number of 'tsid' requests per DOTS client.</t>
<t>If no target attribute is included in the request, this is an <t>If no target attribute is included in the request, this is an
indication that the baseline information applies for the DOTS client indication that the baseline information applies for the DOTS client
domain as a whole.</t> domain as a whole.</t>
<t>An example of a PUT request to convey the baseline information is <t>An example of a PUT request to convey the baseline information is
shown in <xref target="tputs"></xref>.</t> shown in <xref target="tputs" format="default"/>.</t>
<figure anchor="tputs">
<t><figure anchor="tputs" <name>PUT to Convey DOTS Traffic Baseline Information, Depicted as p
title="PUT to Conveying the DOTS Traffic Baseline, depicted as per er Section 5.6</name>
Section 5.6"> <sourcecode name="" type="json"><![CDATA[Header: PUT (Code=0.03)
<artwork align="left"><![CDATA[Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=129" Uri-Path: "tsid=129"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
skipping to change at line 1738 skipping to change at line 1543
"unit": "megabit-ps", "unit": "megabit-ps",
"peak-g": "60" "peak-g": "60"
} }
] ]
} }
] ]
} }
] ]
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>The DOTS client may share protocol-specific baseline information
<t>The DOTS client may share protocol specific baseline information (e.g., TCP and UDP) as shown in <xref target="tputs2" format="default"
(e.g., TCP and UDP) as shown in <xref />.</t>
target="tputs2"></xref>.<figure anchor="tputs2" <figure anchor="tputs2">
title="PUT to Convey the DOTS Traffic Baseline (2), depicted as pe <name>PUT to Convey DOTS Traffic Baseline Information (2), Depicted
r Section 5.6"> as per Section 5.6</name>
<artwork align="left"><![CDATA[Header: PUT (Code=0.03) <sourcecode name="" type="json"><![CDATA[Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=130" Uri-Path: "tsid=130"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
skipping to change at line 1782 skipping to change at line 1586
"protocol": 17, "protocol": 17,
"peak-g": "10" "peak-g": "10"
} }
] ]
} }
] ]
} }
] ]
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>The normal traffic baseline information should be updated to <t>The normal traffic baseline information should be updated to
reflect legitimate overloads (e.g., flash crowds) to prevent reflect legitimate overloads (e.g., flash crowds) to prevent
unnecessary mitigation.</t> unnecessary mitigation.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Retrieve Installed Normal Traffic Baseline"> <name>Retrieving Installed Normal Traffic Baseline Information</name>
<t>A GET request with 'tsid' Uri-Path parameter is used to retrieve <t>A GET request with a 'tsid' Uri-Path parameter is used to retrieve
a specific installed DOTS client domain baseline traffic a specific installed DOTS client domain's baseline traffic
information. The same procedure as defined in <xref information. The same procedure as that defined in <xref target="GET"
target="GET"></xref> is followed.</t> format="default"/> is followed.</t>
<t>To retrieve all baseline information bound to a DOTS client, the <t>To retrieve all baseline information bound to a DOTS client, the
DOTS client proceeds as specified in <xref target="acc"></xref>.</t> DOTS client proceeds as specified in <xref target="acc" format="defaul t"/>.</t>
</section> </section>
<section anchor="basedel" numbered="true" toc="default">
<section anchor="basedel" <name>Deleting Installed Normal Traffic Baseline Information</name>
title="Delete Installed Normal Traffic Baseline">
<t>A DELETE request is used to delete the installed DOTS client <t>A DELETE request is used to delete the installed DOTS client
domain normal traffic baseline. The same procedure as defined in domain's normal traffic baseline information. The same procedure as th
<xref target="DEL"></xref> is followed.</t> at defined in
<xref target="DEL" format="default"/> is followed.</t>
</section> </section>
</section> </section>
<section anchor="reseta" numbered="true" toc="default">
<section anchor="reseta" title="Reset Installed Telemetry Setup"> <name>Resetting the Installed Telemetry Setup</name>
<t>Upon bootstrapping (or reboot or any other event that may alter the <t>Upon bootstrapping (or reboot or any other event that may alter the
DOTS client setup), a DOTS client MAY send a DELETE request to set the DOTS client setup), a DOTS client <bcp14>MAY</bcp14> send a DELETE reque st to set the
telemetry parameters to default values. Such a request does not telemetry parameters to default values. Such a request does not
include any 'tsid'. An example of such a request is depicted in <xref include any 'tsid' parameters. An example of such a request is depicted
target="bdel"></xref>.</t> in <xref target="bdel" format="default"/>.</t>
<figure anchor="bdel">
<t><figure anchor="bdel" title="Delete Telemetry Configuration"> <name>Deleting the Telemetry Configuration</name>
<artwork align="left"><![CDATA[Header: DELETE (Code=0.04) <sourcecode name="" type="json"><![CDATA[Header: DELETE (Code=0.04)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
</section> </section>
<section anchor="conflict" numbered="true" toc="default">
<section anchor="conflict" <name>Conflict with Other DOTS Clients of the Same Domain</name>
title="Conflict with Other DOTS Clients of the Same Domain">
<t>A DOTS server may detect conflicts between requests conveying pipe <t>A DOTS server may detect conflicts between requests conveying pipe
and baseline information received from DOTS clients of the same DOTS and baseline information received from DOTS clients of the same DOTS
client domain. 'conflict-information' is used to report the conflict client domain. &nbsp;'conflict-information' is used to report the confli
to the DOTS client following similar conflict handling discussed in ct
Section 4.4.1 of <xref target="RFC9132"></xref>. The conflict cause to the DOTS client, following guidelines for conflict handling similar t
can be set to one of these values:<list style="empty"> o those discussed in
<t>1: Overlapping targets (Section 4.4.1 of <xref <xref target="RFC9132" sectionFormat="of" section="4.4.1"/>. The conflic
target="RFC9132"></xref>).</t> t cause
can be set to one of these values:</t>
<t>TBA: Overlapping pipe scope (see <xref <dl newline="false" spacing="normal">
target="IANA"></xref>).</t> <dt>1:</dt><dd>Overlapping targets (<xref target="RFC9132" sectionForm
</list></t> at="of" section="4.4.1"/>).</dd>
<dt>5:</dt><dd>Overlapping pipe scope (see <xref target="IANA" format=
<t></t> "default"/>).</dd>
</dl>
</section> </section>
</section> </section>
<section anchor="pre-t" numbered="true" toc="default">
<section anchor="pre-t" title="DOTS Pre-or-Ongoing Mitigation Telemetry"> <name>DOTS Pre-or-Ongoing-Mitigation Telemetry</name>
<t>There are two broad types of DDoS attacks: one is a bandwidth <t>There are two broad types of DDoS attacks: bandwidth-consuming attacks
consuming attack, the other is a target-resource-consuming attack. This and target-resource-consuming attacks. This
section outlines the set of DOTS telemetry attributes (<xref section outlines the set of DOTS telemetry attributes (<xref target="pre"
target="pre"></xref>) that covers both types of attack. The objective of format="default"/>) that covers both types of attacks. The objective of
these attributes is to allow for the complete knowledge of attacks and these attributes is to allow for the complete knowledge of attacks and
the various particulars that can best characterize attacks.</t> the various particulars that can best characterize attacks.</t>
<t>The "ietf-dots-telemetry" YANG module (<xref target="module" format="de
<t>The "ietf-dots-telemetry" YANG module (<xref target="module"></xref>) fault"/>)
defines the data structure of a new message type called 'telemetry'. The defines the data structure of a new message type called 'telemetry'. The
tree structure of the 'telemetry' message type is shown in <xref tree structure of the 'telemetry' message type is shown in <xref target="t
target="tt"></xref>.</t> t" format="default"/>.</t>
<figure anchor="tt">
<t>The pre-or-ongoing-mitigation telemetry attributes are indicated by <name>Telemetry Message Type Tree Structure</name>
the path suffix '/tm'. The '/tm' is appended to the path prefix to form <sourcecode name="" type="yangtree"><![CDATA[ structure dots-telemetry:
the URI used with a CoAP request to signal the DOTS telemetry.
Pre-or-ongoing-mitigation telemetry attributes specified in <xref
target="pre"></xref> can be signaled between DOTS agents.</t>
<t>Pre-or-ongoing-mitigation telemetry attributes may be sent by a DOTS
client or a DOTS server.</t>
<t>DOTS agents SHOULD bind pre-or-ongoing-mitigation telemetry data to
mitigation requests associated with the resources under attack. In
particular, a telemetry PUT request sent after a mitigation request may
include a reference to that mitigation request ('mid-list') as shown in
<xref target="mid-co"></xref>. An example illustrating request
correlation by means of 'target-prefix' is shown in <xref
target="mid-co2"></xref>.</t>
<t>Many of the pre-or-ongoing-mitigation telemetry data use a unit that
falls under the unit class that is configured following the procedure
described in <xref target="PUT"></xref>. When generating telemetry data
to send to a peer, the DOTS agent MUST auto-scale so that appropriate
unit(s) are used.</t>
<t><figure anchor="mid-co"
title="Example of Request Correlation using 'mid'">
<artwork><![CDATA[ +-----------+
+-----------+
|DOTS client| |DOTS server|
+-----------+ +-----------+
| |
|===============Mitigation Request (mid)===============>|
| |
|===============Telemetry (mid-list{mid})==============>|
| |
]]></artwork>
</figure></t>
<t><figure anchor="mid-co2"
title="Example of Request Correlation using Target Prefix">
<artwork><![CDATA[ +-----------+
+-----------+
|DOTS client| |DOTS server|
+-----------+ +-----------+
| |
|<================Telemetry (target-prefix)=============|
| |
|=========Mitigation Request (target-prefix)===========>|
| |
]]></artwork>
</figure></t>
<t>DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry
notifications to the same peer more frequently than once every
'telemetry-notify-interval' (<xref target="tconfig"></xref>). If a
telemetry notification is sent using a block-like transfer mechanism
(e.g., <xref target="I-D.ietf-core-new-block"></xref>), this rate limit
policy MUST NOT consider these individual blocks as separate
notifications, but as a single notification.</t>
<t>DOTS pre-or-ongoing-mitigation telemetry request and response
messages MUST be marked as Non-Confirmable messages (Section 2.1 of
<xref target="RFC7252"></xref>).</t>
<t><figure anchor="tt" title="Telemetry Message Type Tree Structure ">
<artwork><![CDATA[ structure dots-telemetry:
+-- (telemetry-message-type)? +-- (telemetry-message-type)?
+--:(telemetry-setup) +--:(telemetry-setup)
| ... | ...
| +-- telemetry* [] | +-- telemetry* []
| +-- (direction)? | +-- (direction)?
| | +--:(server-to-client-only) | | +--:(server-to-client-only)
| | +-- tsid? uint32 | | +-- tsid? uint32
| +-- (setup-type)? | +-- (setup-type)?
| +--:(telemetry-config) | +--:(telemetry-config)
| | ... | | ...
skipping to change at line 1959 skipping to change at line 1688
+-- total-attack-traffic-protocol* [unit protocol] +-- total-attack-traffic-protocol* [unit protocol]
| ... | ...
+-- total-attack-traffic-port* [unit port] +-- total-attack-traffic-port* [unit port]
| ... | ...
+-- total-attack-connection-protocol* [protocol] +-- total-attack-connection-protocol* [protocol]
| ... | ...
+-- total-attack-connection-port* [protocol port] +-- total-attack-connection-port* [protocol port]
| ... | ...
+-- attack-detail* [vendor-id attack-id] +-- attack-detail* [vendor-id attack-id]
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<section anchor="pre"
title="Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes">
<t>The description and motivation behind each attribute are presented
in <xref target="overview"></xref>.</t>
<section title="Target"> <t>The pre-or-ongoing-mitigation telemetry attributes are indicated by
<t>A target resource (<xref target="targett"></xref>) is identified the path suffix '/tm'. &nbsp;'/tm' is appended to the path prefix to form
the URI used with a CoAP request to signal the DOTS telemetry.
Pre-or-ongoing-mitigation telemetry attributes as specified in <xref targe
t="pre" format="default"/> can be signaled between DOTS agents.</t>
<t>Pre-or-ongoing-mitigation telemetry attributes may be sent by a DOTS
client or a DOTS server.</t>
<t>DOTS agents <bcp14>SHOULD</bcp14> bind pre-or-ongoing-mitigation teleme
try data to
mitigation requests associated with the resources under attack. In
particular, a telemetry PUT request sent after a mitigation request may
include a reference to that mitigation request ('mid-list') as shown in
<xref target="mid-co" format="default"/>. An example illustrating request
correlation by means of 'target-prefix' is shown in <xref target="mid-co2"
format="default"/>.</t>
<t>Much of the pre-or-ongoing-mitigation telemetry data uses a unit that
falls under the unit class that is configured following the procedure
described in <xref target="PUT" format="default"/>. When generating teleme
try data
to send to a peer, the DOTS agent <bcp14>MUST</bcp14> auto-scale so that o
ne or more appropriate
units are used.</t>
<figure anchor="mid-co">
<name>Example of Request Correlation Using 'mid'</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ +-----------+
+-----------+
|DOTS client| |DOTS server|
+-----------+ +-----------+
| |
|==============Mitigation Request (mid)==============>|
| |
|==============Telemetry (mid-list{mid})=============>|
| |
]]></artwork>
</figure>
<figure anchor="mid-co2">
<name>Example of Request Correlation Using &apos;target-prefix&apos;</na
me>
<artwork name="" type="" align="left" alt=""><![CDATA[ +-----------+
+-----------+
|DOTS client| |DOTS server|
+-----------+ +-----------+
| |
|<===============Telemetry (target-prefix)============|
| |
|========Mitigation Request (target-prefix)==========>|
| |
]]></artwork>
</figure>
<t>DOTS agents <bcp14>MUST NOT</bcp14> send pre-or-ongoing-mitigation tele
metry
notifications to the same peer more frequently than once every
'telemetry-notify-interval' (<xref target="tconfig" format="default"/>). I
f a
telemetry notification is sent using a block-like transfer mechanism
(e.g., <xref target="RFC9177" format="default"/>), this
rate-limit
policy <bcp14>MUST NOT</bcp14> consider these individual blocks as separat
e
notifications, but as a single notification.</t>
<t>DOTS pre-or-ongoing-mitigation telemetry request and response
messages <bcp14>MUST</bcp14> be marked as Non-confirmable messages (<xref
target="RFC7252" sectionFormat="of" section="2.1"/>).</t>
<section anchor="pre" numbered="true" toc="default">
<name>Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes</name>
<t><xref target="overview" format="default"/> discusses the motivation f
or using the DOTS telemetry attributes. These attributes are specified in the fo
llowing subsections.</t>
<section numbered="true" toc="default">
<name>Target</name>
<t>A target resource (<xref target="targett" format="default"/>) is id
entified
using the attributes 'target-prefix', 'target-port-range', using the attributes 'target-prefix', 'target-port-range',
'target-protocol', 'target-fqdn', 'target-uri', 'alias-name', or a 'target-protocol', 'target-fqdn', 'target-uri', 'alias-name', or a
pointer to a mitigation request ('mid-list').</t> pointer to a mitigation request ('mid-list').</t>
<figure anchor="targett">
<t><figure anchor="targett" title="Target Tree Structure"> <name>Target Tree Structure</name>
<artwork><![CDATA[ +--:(telemetry) <sourcecode name="" type="yangtree"><![CDATA[
+--:(telemetry)
+-- pre-or-ongoing-mitigation* [] +-- pre-or-ongoing-mitigation* []
+-- (direction)? +-- (direction)?
| +--:(server-to-client-only) | +--:(server-to-client-only)
| +-- tmid? uint32 | +-- tmid? uint32
+-- target +-- target
| +-- target-prefix* inet:ip-prefix | +-- target-prefix* inet:ip-prefix
| +-- target-port-range* [lower-port] | +-- target-port-range* [lower-port]
| | +-- lower-port inet:port-number | | +-- lower-port inet:port-number
| | +-- upper-port? inet:port-number | | +-- upper-port? inet:port-number
| +-- target-protocol* uint8 | +-- target-protocol* uint8
skipping to change at line 2007 skipping to change at line 1787
+-- total-attack-traffic-protocol* [unit protocol] +-- total-attack-traffic-protocol* [unit protocol]
| ... | ...
+-- total-attack-traffic-port* [unit port] +-- total-attack-traffic-port* [unit port]
| ... | ...
+-- total-attack-connection-protocol* [protocol] +-- total-attack-connection-protocol* [protocol]
| ... | ...
+-- total-attack-connection-port* [protocol port] +-- total-attack-connection-port* [protocol port]
| ... | ...
+-- attack-detail* [vendor-id attack-id] +-- attack-detail* [vendor-id attack-id]
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>At least one of the attributes 'target-prefix', 'target-fqdn', <t>At least one of the attributes 'target-prefix', 'target-fqdn',
'target-uri', 'alias-name', or 'mid-list' MUST be present in the 'target-uri', 'alias-name', or 'mid-list' <bcp14>MUST</bcp14> be prese nt in the
target definition.</t> target definition.</t>
<t>If the target is susceptible to bandwidth-consuming attacks, the <t>If the target is susceptible to bandwidth-consuming attacks, the
attributes representing the percentile values of the 'attack-id' attributes representing the percentile values of the 'attack-id'
attack traffic are included.</t> attack traffic are included.</t>
<t>If the target is susceptible to resource-consuming DDoS attacks, <t>If the target is susceptible to resource-consuming DDoS attacks,
the attributes defined in <xref target="attackconn"></xref> are the attributes defined in <xref target="attackconn" format="default"/> are
applicable for representing the attack.</t> applicable for representing the attack.</t>
<t>At least the 'target' attribute and one other <t>At least the 'target' attribute and one other
pre-or-ongoing-mitigation attribute MUST be present in the DOTS pre-or-ongoing-mitigation attribute <bcp14>MUST</bcp14> be present in the DOTS
telemetry message.</t> telemetry message.</t>
</section> </section>
<section anchor="tot" numbered="true" toc="default">
<section anchor="tot" title="Total Traffic"> <name>Total Traffic</name>
<t>The 'total-traffic' attribute (<xref target="ttt"></xref>) <t>The 'total-traffic' attribute (<xref target="ttt" format="default"/
>)
conveys the percentile values (including peak and current observed conveys the percentile values (including peak and current observed
values) of the total observed traffic. More fine-grained information values) of the total observed traffic. More fine-grained information
about the total traffic can be conveyed in the about the total traffic can be conveyed in the
'total-traffic-protocol' and 'total-traffic-port' attributes.</t> 'total-traffic-protocol' and 'total-traffic-port' attributes.</t>
<t>The 'total-traffic-protocol' attribute represents the total <t>The 'total-traffic-protocol' attribute represents the total
traffic for a target and is transport-protocol specific.</t> traffic for a target and is transport-protocol specific.</t>
<t>The 'total-traffic-port' attribute represents the total traffic for
<t>The 'total-traffic-port' represents the total traffic for a a
target per port number.</t> target per port number.</t>
<figure anchor="ttt">
<t><figure anchor="ttt" title="Total Traffic Tree Structure"> <name>Total Traffic Tree Structure</name>
<artwork><![CDATA[ +--:(telemetry) <sourcecode name="" type="yangtree"><![CDATA[
+--:(telemetry)
+-- pre-or-ongoing-mitigation* [] +-- pre-or-ongoing-mitigation* []
+-- (direction)? +-- (direction)?
| +--:(server-to-client-only) | +--:(server-to-client-only)
| +-- tmid? uint32 | +-- tmid? uint32
+-- target +-- target
| ... | ...
+-- total-traffic* [unit] +-- total-traffic* [unit]
| +-- unit unit | +-- unit unit
| +-- low-percentile-g? yang:gauge64 | +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64 | +-- mid-percentile-g? yang:gauge64
skipping to change at line 2083 skipping to change at line 1858
+-- total-attack-traffic-protocol* [unit protocol] +-- total-attack-traffic-protocol* [unit protocol]
| ... | ...
+-- total-attack-traffic-port* [unit port] +-- total-attack-traffic-port* [unit port]
| ... | ...
+-- total-attack-connection-protocol* [protocol] +-- total-attack-connection-protocol* [protocol]
| ... | ...
+-- total-attack-connection-port* [protocol port] +-- total-attack-connection-port* [protocol port]
| ... | ...
+-- attack-detail* [vendor-id attack-id] +-- attack-detail* [vendor-id attack-id]
... ...
]]></sourcecode>
]]></artwork> </figure>
</figure></t>
</section> </section>
<section anchor="tat" numbered="true" toc="default">
<section anchor="tat" title="Total Attack Traffic "> <name>Total Attack Traffic</name>
<t>The 'total-attack-traffic' attribute (<xref <t>The 'total-attack-traffic' attribute (<xref target="tatt" format="d
target="tatt"></xref>) conveys the total observed attack traffic. efault"/>) conveys the total observed attack traffic.
More fine-grained information about the total attack traffic can be More fine-grained information about the total attack traffic can be
conveyed in the 'total-attack-traffic-protocol' and conveyed in the 'total-attack-traffic-protocol' and
'total-attack-traffic-port' attributes.</t> 'total-attack-traffic-port' attributes.</t>
<t>The 'total-attack-traffic-protocol' attribute represents the <t>The 'total-attack-traffic-protocol' attribute represents the
total attack traffic for a target and is transport-protocol total attack traffic for a target and is transport-protocol
specific.</t> specific.</t>
<t>The 'total-attack-traffic-port' attribute represents the total <t>The 'total-attack-traffic-port' attribute represents the total
attack traffic for a target per port number.</t> attack traffic for a target per port number.</t>
<figure anchor="tatt">
<t><figure anchor="tatt" title="Total Attack Traffic Tree Structure"> <name>Total Attack Traffic Tree Structure</name>
<artwork><![CDATA[ +--:(telemetry) <sourcecode name="" type="yangtree"><![CDATA[
+--:(telemetry)
+-- pre-or-ongoing-mitigation* [] +-- pre-or-ongoing-mitigation* []
+-- (direction)? +-- (direction)?
| +--:(server-to-client-only) | +--:(server-to-client-only)
| +-- tmid? uint32 | +-- tmid? uint32
+-- target +-- target
| ... | ...
+-- total-traffic* [unit] +-- total-traffic* [unit]
| ... | ...
+-- total-traffic-protocol* [unit protocol] +-- total-traffic-protocol* [unit protocol]
| ... | ...
skipping to change at line 2145 skipping to change at line 1917
| +-- mid-percentile-g? yang:gauge64 | +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64 | +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64 | +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64 | +-- current-g? yang:gauge64
+-- total-attack-connection-protocol* [protocol] +-- total-attack-connection-protocol* [protocol]
| ... | ...
+-- total-attack-connection-port* [protocol port] +-- total-attack-connection-port* [protocol port]
| ... | ...
+-- attack-detail* [vendor-id attack-id] +-- attack-detail* [vendor-id attack-id]
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
</section> </section>
<section anchor="attackconn" numbered="true" toc="default">
<section anchor="attackconn" title="Total Attack Connections"> <name>Total Attack Connections</name>
<t>If the target is susceptible to resource-consuming DDoS attacks, <t>If the target is susceptible to resource-consuming DDoS attacks,
the 'total-attack-connection-protocol' attribute is used to convey the 'total-attack-connection-protocol' attribute is used to convey
the percentile values (including peak and current observed values) the percentile values (including peak and current observed values)
of various attributes related to the total attack connections. The of various attributes related to the total attack connections. The
following optional sub-attributes for the target per transport following optional sub-attributes for the target per transport
protocol are included to represent the attack characteristics:<?rfc su protocol are included to represent the attack characteristics:</t>
bcompact="yes" ?><list <ul spacing="normal">
style="symbols"> <li>The number of simultaneous attack connections to the
<t>The number of simultaneous attack connections to the target.</li>
target.</t> <li>The number of simultaneous embryonic connections to the
target.</li>
<t>The number of simultaneous embryonic connections to the <li>The number of attack connections per second to the
target.</t> target.</li>
<li>The number of attack requests per second to the target.</li>
<t>The number of attack connections per second to the <li>The number of attack partial requests to the target.</li>
target.</t> </ul>
<t>The total attack connections per port number are represented
<t>The number of attack requests per second to the target.</t> using the 'total-attack-connection-port' attribute.</t>
<figure anchor="tact">
<t>The number of attack partial requests to the target.<?rfc subco <name>Total Attack Connections Tree Structure</name>
mpact="no" ?></t> <sourcecode name="" type="yangtree"><![CDATA[
</list>The total attack connections per port number is represented +--:(telemetry)
using the 'total-attack-connection-port' attribute.<figure
anchor="tact" title="Total Attack Connections Tree Structure">
<artwork><![CDATA[ +--:(telemetry)
+-- pre-or-ongoing-mitigation* [] +-- pre-or-ongoing-mitigation* []
+-- (direction)? +-- (direction)?
| +--:(server-to-client-only) | +--:(server-to-client-only)
| +-- tmid? uint32 | +-- tmid? uint32
+-- target +-- target
| ... | ...
+-- total-traffic* [unit] +-- total-traffic* [unit]
| ... | ...
+-- total-traffic-protocol* [unit protocol] +-- total-traffic-protocol* [unit protocol]
| ... | ...
skipping to change at line 2258 skipping to change at line 2029
| | +-- peak-g? yang:gauge64 | | +-- peak-g? yang:gauge64
| | +-- current-g? yang:gauge64 | | +-- current-g? yang:gauge64
| +-- partial-request-c | +-- partial-request-c
| +-- low-percentile-g? yang:gauge64 | +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64 | +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64 | +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64 | +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64 | +-- current-g? yang:gauge64
+-- attack-detail* [vendor-id attack-id] +-- attack-detail* [vendor-id attack-id]
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
</section> </section>
<section anchor="attackdetails" numbered="true" toc="default">
<section anchor="attackdetails" title="Attack Details"> <name>Attack Details</name>
<t>This attribute (depicted in <xref target="adt"></xref>) is used <t>This attribute (depicted in <xref target="adt" format="default"/>)
is used
to signal a set of details characterizing an attack. The following to signal a set of details characterizing an attack. The following
sub-attributes describing the ongoing attack can be signalled as sub-attributes describing the ongoing attack can be signaled as
attack details:</t> attack details:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>vendor-id:</dt>
<t hangText="vendor-id:">Vendor ID is a security vendor's <dd>Vendor ID. This parameter represents a security vendor's
enterprise number as registered in the IANA's "Private enterprise number as registered in the IANA "Private
Enterprise Numbers" registry <xref Enterprise Numbers" registry <xref target="Private-Enterprise-Numb
target="Private-Enterprise-Numbers"></xref>.</t> ers" format="default"/>.</dd>
<dt>attack-id:</dt>
<t hangText="attack-id:">Unique identifier assigned for the <dd>Unique identifier assigned for the
attack by a vendor. This parameter MUST be present independent attack by a vendor. This parameter <bcp14>MUST</bcp14> be present,
of whether 'attack-description' is included or not.</t> independently
of whether 'attack-description' is included or not.</dd>
<t hangText="description-lang:">Indicates the language tag that <dt>description-lang:</dt>
<dd>Indicates the language tag that
is used for the text that is included in the is used for the text that is included in the
'attack-description' attribute. The attribute is encoded 'attack-description' attribute. This attribute is encoded
following the rules in Section 2.1 of <xref following the rules in <xref target="RFC5646" sectionFormat="of" s
target="RFC5646"></xref>. The default language tag is ection="2.1"/>. The default language tag is
"en-US".</t> "en-US".</dd>
<dt>attack-description:</dt>
<t hangText="attack-description:">Textual representation of the <dd>Textual representation of the
attack description. This description is related to the class of attack description. This description is related to the class of
attack rather than a specific instance of it. Natural Language attack rather than a specific instance of it. Natural Language
Processing techniques (e.g., word embedding) might provide some Processing techniques (e.g., word embedding) might provide some
utility in mapping the attack description to an attack type. utility in mapping the attack description to an attack type.
Textual representation of attack solves two problems: (a) avoids Textual representation of an attack solves two problems: it avoids
the need to create mapping tables manually between vendors and the need to (a) create mapping tables manually between vendors and
(b) avoids the need to standardize attack types which keep (b) standardize attack types that keep
evolving.</t> evolving.</dd>
<dt>attack-severity:</dt>
<t hangText="attack-severity:">Attack severity level. This <dd>Attack severity level. This
attribute takes one of the values defined in Section 3.12.2 of attribute takes one of the values defined in <xref target="RFC7970
<xref target="RFC7970"></xref>.</t> " sectionFormat="of" section="3.12.2"/>.</dd>
<dt>start-time:</dt>
<t hangText="start-time:">The time the attack started. The <dd>The time the attack started. The
attack's start time is expressed in seconds relative to attack's start time is expressed in seconds relative to
1970-01-01T00:00Z (Section 3.4.2 of <xref 1970-01-01T00:00Z (<xref target="RFC8949" sectionFormat="of" secti
target="RFC8949"></xref>). The CBOR encoding is modified so that on="3.4.2"/>). The CBOR encoding is modified so that
the leading tag 1 (epoch-based date/time) MUST be omitted.</t> the leading tag 1 (epoch-based date/time) <bcp14>MUST</bcp14> be o
mitted.</dd>
<t hangText="end-time:">The time the attack ended. The attack <dt>end-time:</dt>
<dd>The time the attack ended. The attack's
end time is expressed in seconds relative to 1970-01-01T00:00Z end time is expressed in seconds relative to 1970-01-01T00:00Z
(Section 3.4.2 of <xref target="RFC8949"></xref>). The CBOR (<xref target="RFC8949" sectionFormat="of" section="3.4.2"/>). The CBOR
encoding is modified so that the leading tag 1 (epoch-based encoding is modified so that the leading tag 1 (epoch-based
date/time) MUST be omitted.</t> date/time) <bcp14>MUST</bcp14> be omitted.</dd>
<dt>source-count:</dt>
<t hangText="source-count:">A count of sources involved in the <dd>A count of sources involved in the
attack targeting the victim.</t> attack targeting the victim.</dd>
<dt>top-talker:</dt>
<t hangText="top-talker:">A list of attack sources that are <dd>
involved in an attack and which are generating an important part <t>A list of attack sources that are
of the attack traffic. The top talkers are represented using the involved in an attack and that are generating an important part
'source-prefix'.<vspace blankLines="1" />'spoofed-status' of the attack traffic. The top talkers are represented using
'source-prefix'.</t>
<t>'spoofed-status'
indicates whether a top talker is a spoofed IP address (e.g., indicates whether a top talker is a spoofed IP address (e.g.,
reflection attacks) or not. If no 'spoofed-status' data node is reflection attacks) or not. If no 'spoofed-status' data node is
included, this means that the spoofing status is unknown.<vspace included, this means that the spoofing status is unknown.</t>
blankLines="1" />If the target is being subjected to a <t>If the target is being subjected to a
bandwidth-consuming attack, a statistical profile of the attack bandwidth-consuming attack, a statistical profile of the attack
traffic from each of the top talkers is included traffic from each of the top talkers is included
('total-attack-traffic', <xref target="tat"></xref>). <vspace ('total-attack-traffic'; see <xref target="tat" format="default"/>
blankLines="1" />If the target is being subjected to a ). </t>
resource-consuming DDoS attack, the same attributes defined in <t>If the target is being subjected to a
<xref target="attackconn"></xref> are applicable for resource-consuming DDoS attack, the same attributes as those defin
ed in
<xref target="attackconn" format="default"/> are applicable for
characterizing the attack on a per-talker basis.</t> characterizing the attack on a per-talker basis.</t>
</list></t> </dd>
</dl>
<t><figure anchor="adt" title="Attack Detail Tree Structure"> <figure anchor="adt">
<artwork><![CDATA[ +--:(telemetry) <name>Attack Details Tree Structure</name>
<sourcecode name="" type="yangtree"><![CDATA[
+--:(telemetry)
+-- pre-or-ongoing-mitigation* [] +-- pre-or-ongoing-mitigation* []
+-- (direction)? +-- (direction)?
| +--:(server-to-client-only) | +--:(server-to-client-only)
| +-- tmid? uint32 | +-- tmid? uint32
+-- target +-- target
| ... | ...
+-- total-traffic* [unit] +-- total-traffic* [unit]
| ... | ...
+-- total-traffic-protocol* [unit protocol] +-- total-traffic-protocol* [unit protocol]
| ... | ...
skipping to change at line 2419 skipping to change at line 2190
| +-- mid-percentile-g? yang:gauge64 | +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64 | +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64 | +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64 | +-- current-g? yang:gauge64
+-- partial-request-c +-- partial-request-c
+-- low-percentile-g? yang:gauge64 +-- low-percentile-g? yang:gauge64
+-- mid-percentile-g? yang:gauge64 +-- mid-percentile-g? yang:gauge64
+-- high-percentile-g? yang:gauge64 +-- high-percentile-g? yang:gauge64
+-- peak-g? yang:gauge64 +-- peak-g? yang:gauge64
+-- current-g? yang:gauge64 +-- current-g? yang:gauge64
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>In order to optimize the size of telemetry data conveyed over the <t>In order to optimize the size of telemetry data conveyed over the
DOTS signal channel, DOTS agents MAY use the DOTS data channel <xref DOTS signal channel, DOTS agents <bcp14>MAY</bcp14> use the DOTS data
target="RFC8783"></xref> to exchange vendor specific attack mapping channel <xref target="RFC8783" format="default"/> to exchange vendor-specific at
tack mapping
details (that is, {vendor identifier, attack identifier} ==&gt; details (that is, {vendor identifier, attack identifier} ==&gt;
textual representation of the attack description). As such, DOTS textual representation of the attack description). As such, DOTS
agents do not have to convey systematically an attack description in agents do not have to convey an attack description systematically in
their telemetry messages over the DOTS signal channel. Refer to their telemetry messages over the DOTS signal channel. Refer to
<xref target="vam"></xref>.</t> <xref target="vam" format="default"/>.</t>
</section> </section>
<section anchor="vam" numbered="true" toc="default">
<section anchor="vam" title="Vendor Attack Mapping"> <name>Vendor Attack Mapping</name>
<t>Multiple mappings for different vendor identifiers may be used; <t>Multiple mappings for different vendor identifiers may be used;
the DOTS agent transmitting telemetry information can elect to use the DOTS agent transmitting telemetry information can elect to use
one or more vendor mappings even in the same telemetry message.<list one or more vendor mappings even in the same telemetry message.</t>
style="empty"> <aside><t>
<t>Note: It is possible that a DOTS server is making use of Note: It is possible that a DOTS server is making use of
multiple DOTS mitigators; each from a different vendor. How multiple DOTS mitigators, each from a different vendor. How
telemetry information and vendor mappings are exchanged between telemetry information and vendor mappings are exchanged between
DOTS servers and DOTS mitigators is outside the scope of this DOTS servers and DOTS mitigators is outside the scope of this
document.</t> document.
</list></t> </t></aside>
<t>DOTS clients and servers may be provided with mappings from <t>DOTS clients and servers may be provided with mappings from
different vendors and so have their own different sets of vendor different vendors and so have their own different sets of vendor
attack mappings. A DOTS agent MUST accept receipt of telemetry data attack mappings. A DOTS agent <bcp14>MUST</bcp14> accept receipt of te
with a vendor identifier that is different to the one it uses to lemetry data
with a vendor identifier that is different than the identifier it uses
to
transmit telemetry data. Furthermore, it is possible that the DOTS transmit telemetry data. Furthermore, it is possible that the DOTS
client and DOTS server are provided by the same vendor, but the client and DOTS server are provided by the same vendor but the
vendor mapping tables are at different revisions. The DOTS client vendor mapping tables are at different revisions. The DOTS client
SHOULD transmit telemetry information using any vendor mapping(s) <bcp14>SHOULD</bcp14> transmit telemetry information using any vendor mapping(s)
that it provided to the DOTS server (e.g., using a POST as depicted that it provided to the DOTS server (e.g., using a POST as depicted
in <xref target="installmap"></xref>) and the DOTS server SHOULD use in <xref target="installmap" format="default"/>), and the DOTS server <bcp14>SHOULD</bcp14> use
any vendor mappings(s) provided to the DOTS client when transmitting any vendor mappings(s) provided to the DOTS client when transmitting
telemetry data to the peer DOTS agent.</t> telemetry data to the peer DOTS agent.</t>
<figure anchor="installmap">
<name>POST to Install Vendor Attack Mapping Details</name>
<artwork name="" type="" align="left" alt=""><![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>The "ietf-dots-mapping" YANG module defined in <xref {
target="data"></xref> augments the "ietf-dots-data-channel" <xref "ietf-dots-mapping:vendor-mapping": {
target="RFC8783"></xref> module. The tree structure of the "vendor": [
"ietf-dots-mapping" module is shown in <xref {
target="abstract-data"></xref>.</t> "vendor-id": 345,
"vendor-name": "mitigator-c",
<t><figure anchor="abstract-data" "last-updated": "1629898958",
title="Vendor Attack Mapping Tree Structure"> "attack-mapping": [
<artwork><![CDATA[module: ietf-dots-mapping {
"attack-id": 1,
"attack-description":
"Include a description of this attack"
},
{
"attack-id": 2,
"attack-description":
"Again, include a description of the attack"
}
]
}
]
}
}
]]></artwork>
</figure>
<t>The "ietf-dots-mapping" YANG module defined in <xref target="data"
format="default"/> augments the "ietf-dots-data-channel" module <xref target="RF
C8783" format="default"/>. The tree structure of the
"ietf-dots-mapping" module is shown in <xref target="abstract-data" fo
rmat="default"/>.</t>
<figure anchor="abstract-data">
<name>Vendor Attack Mapping Tree Structure</name>
<sourcecode name="" type="yangtree"><![CDATA[
module: ietf-dots-mapping
augment /data-channel:dots-data/data-channel:dots-client: augment /data-channel:dots-data/data-channel:dots-client:
+--rw vendor-mapping {dots-telemetry}? +--rw vendor-mapping {dots-telemetry}?
+--rw vendor* [vendor-id] +--rw vendor* [vendor-id]
+--rw vendor-id uint32 +--rw vendor-id uint32
+--rw vendor-name? string +--rw vendor-name? string
+--rw description-lang? string +--rw description-lang? string
+--rw last-updated uint64 +--rw last-updated uint64
+--rw attack-mapping* [attack-id] +--rw attack-mapping* [attack-id]
+--rw attack-id uint32 +--rw attack-id uint32
+--rw attack-description string +--rw attack-description string
skipping to change at line 2488 skipping to change at line 2284
augment /data-channel:dots-data: augment /data-channel:dots-data:
+--ro vendor-mapping {dots-telemetry}? +--ro vendor-mapping {dots-telemetry}?
+--ro vendor* [vendor-id] +--ro vendor* [vendor-id]
+--ro vendor-id uint32 +--ro vendor-id uint32
+--ro vendor-name? string +--ro vendor-name? string
+--ro description-lang? string +--ro description-lang? string
+--ro last-updated uint64 +--ro last-updated uint64
+--ro attack-mapping* [attack-id] +--ro attack-mapping* [attack-id]
+--ro attack-id uint32 +--ro attack-id uint32
+--ro attack-description string +--ro attack-description string
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>A DOTS client sends a GET request over the DOTS data channel to <t>A DOTS client sends a GET request over the DOTS data channel to
retrieve the capabilities supported by a DOTS server as per Section retrieve the capabilities supported by a DOTS server as per <xref targ
7.1 of <xref target="RFC8783"></xref>. This request is meant to et="RFC8783" sectionFormat="of" section="7.1"/>. This request is meant to
assess whether the capability of sharing vendor attack mapping assess whether the capability of sharing vendor attack mapping
details is supported by the server (i.e., check the value of details is supported by the server (i.e., check the value of
'vendor-mapping-enabled').</t> 'vendor-mapping-enabled').</t>
<t>If 'vendor-mapping-enabled' is set to 'true', a DOTS client <bcp14>
<t>If 'vendor-mapping-enabled' is set to 'true', a DOTS client MAY MAY</bcp14>
send a GET request to retrieve the DOTS server's vendor attack send a GET request to retrieve the DOTS server's vendor attack
mapping details. An example of such a GET request is shown in <xref mapping details. An example of such a GET request is shown in <xref ta
target="MfS"></xref>.</t> rget="MfS" format="default"/>.</t>
<figure anchor="MfS">
<t><figure anchor="MfS" <name>GET to Retrieve the Vendor Attack Mappings of a DOTS Server</n
title="GET to Retrieve the Vendor Attack Mappings of a DOTS Server ame>
"> <artwork name="" type="" align="left" alt=""><![CDATA[GET /restconf/
<artwork><![CDATA[GET /restconf/data/ietf-dots-data-channel:dots-d data/ietf-dots-data-channel:dots-data\
ata\
/ietf-dots-mapping:vendor-mapping HTTP/1.1 /ietf-dots-mapping:vendor-mapping HTTP/1.1
Host: example.com Host: example.com
Accept: application/yang-data+json Accept: application/yang-data+json
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>A DOTS client can retrieve only the list of vendors supported by <t>A DOTS client can retrieve only the list of vendors supported by
the DOTS server. It does so by setting the "depth" parameter the DOTS server. It does so by setting the "depth" parameter
(Section 4.8.2 of <xref target="RFC8040"></xref>) to "3" in the GET (<xref target="RFC8040" sectionFormat="of" section="4.8.2"/>) to "3" i
request as shown in <xref target="MfSd"></xref>. An example of a n the GET
request as shown in <xref target="MfSd" format="default"/>. An example
of a
response body received from the DOTS server as a response to such a response body received from the DOTS server as a response to such a
request is illustrated in <xref target="MfSdr"></xref>.</t> request is illustrated in <xref target="MfSdr" format="default"/>.</t>
<figure anchor="MfSd">
<t><figure anchor="MfSd" <name>GET to Retrieve the Vendors List Used by a DOTS Server</name>
title="GET to Retrieve the Vendors List used by a DOTS Server"> <artwork name="" type="" align="left" alt=""><![CDATA[GET /restconf/
<artwork><![CDATA[GET /restconf/data/ietf-dots-data-channel:dots-d data/ietf-dots-data-channel:dots-data\
ata\
/ietf-dots-mapping:vendor-mapping?depth=3 HTTP/1.1 /ietf-dots-mapping:vendor-mapping?depth=3 HTTP/1.1
Host: example.com Host: example.com
Accept: application/yang-data+json Accept: application/yang-data+json
]]></artwork> ]]></artwork>
</figure></t> </figure>
<figure anchor="MfSdr">
<t><figure anchor="MfSdr" <name>Response Message Body to a GET to Retrieve the Vendors List Us
title="Response Message Body to a GET to Retrieve the Vendors List ed by a DOTS Server</name>
used by a DOTS Server"> <artwork name="" type="" align="left" alt=""><![CDATA[{
<artwork><![CDATA[{
"ietf-dots-mapping:vendor-mapping": { "ietf-dots-mapping:vendor-mapping": {
"vendor": [ "vendor": [
{ {
"vendor-id": 32473, "vendor-id": 32473,
"vendor-name": "mitigator-s", "vendor-name": "mitigator-s",
"last-updated": "1629898758", "last-updated": "1629898758",
"attack-mapping": [] "attack-mapping": []
} }
] ]
} }
} }
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The DOTS client repeats the above procedure regularly (e.g., once <t>The DOTS client repeats the above procedure regularly (e.g., once
a week) to update the DOTS server's vendor attack mapping a week) to update the DOTS server's vendor attack mapping
details.</t> details.</t>
<t>If the DOTS client concludes that the DOTS server does not have <t>If the DOTS client concludes that the DOTS server does not have
any reference to the specific vendor attack mapping details, the any reference to the specific vendor attack mapping details, the
DOTS client uses a POST request to install its vendor attack mapping DOTS client uses a POST request to install its vendor attack mapping
details. An example of such a POST request is depicted in <xref details. An example of such a POST request is depicted in <xref target
target="installmap"></xref>.</t> ="installmap" format="default"/>.</t>
<t><figure anchor="installmap"
title="POST to Install Vendor Attack Mapping Details">
<artwork><![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
{
"ietf-dots-mapping:vendor-mapping": {
"vendor": [
{
"vendor-id": 345,
"vendor-name": "mitigator-c",
"last-updated": "1629898958",
"attack-mapping": [
{
"attack-id": 1,
"attack-description":
"Include a description of this attack"
},
{
"attack-id": 2,
"attack-description":
"Again, include a description of the attack"
}
]
}
]
}
}
]]></artwork>
</figure></t>
<t>The DOTS server indicates the result of processing the POST <t>The DOTS server indicates the result of processing the POST
request using the status-line. A "201 Created" status-line MUST be request using the status-line. A "201 Created" status-line <bcp14>MUST </bcp14> be
returned in the response if the DOTS server has accepted the vendor returned in the response if the DOTS server has accepted the vendor
attack mapping details. If the request is missing a mandatory attack mapping details. If the request is missing a mandatory
attribute or contains an invalid or unknown parameter, "400 Bad attribute or contains an invalid or unknown parameter, a "400 Bad
Request" status-line MUST be returned by the DOTS server in the Request" status-line <bcp14>MUST</bcp14> be returned by the DOTS serve
r in the
response. The error-tag is set to "missing-attribute", response. The error-tag is set to "missing-attribute",
"invalid-value", or "unknown-element" as a function of the "invalid-value", or "unknown-element" as a function of the
encountered error.</t> 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> reply with a
"403 Forbidden" status-line and the error-tag "access-denied". Upon "403 Forbidden" status-line and the error-tag "access-denied". Upon
receipt of this message, the DOTS client MUST register (Section 5.1 receipt of this message, the DOTS client <bcp14>MUST</bcp14> register
of <xref target="RFC8783"></xref>).</t> (<xref target="RFC8783" sectionFormat="of" section="5.1"/>).</t>
<t>The DOTS client uses the PUT request to modify its vendor attack <t>The DOTS client uses the PUT request to modify its vendor attack
mapping details maintained by the DOTS server (e.g., add a new mapping details maintained by the DOTS server (e.g., add a new
mapping entry, update an existing mapping).</t> mapping entry, update an existing mapping).</t>
<t>A DOTS client uses a GET request to retrieve its vendor attack <t>A DOTS client uses a GET request to retrieve its vendor attack
mapping details as maintained by the DOTS server (<xref mapping details as maintained by the DOTS server (<xref target="allD"
target="allD"></xref>).</t> format="default"/>).</t>
<figure anchor="allD">
<t><figure anchor="allD" <name>GET to Retrieve Installed Vendor Attack Mapping Details</name>
title="GET to Retrieve Installed Vendor Attack Mapping Details"> <artwork name="" type="" align="left" alt=""><![CDATA[GET /restconf/
<artwork><![CDATA[GET /restconf/data/ietf-dots-data-channel:dots-d data/ietf-dots-data-channel:dots-data\
ata\
/dots-client=dz6pHjaADkaFTbjr0JGBpw\ /dots-client=dz6pHjaADkaFTbjr0JGBpw\
/ietf-dots-mapping:vendor-mapping?\ /ietf-dots-mapping:vendor-mapping?\
content=all HTTP/1.1 content=all HTTP/1.1
Host: example.com Host: example.com
Accept: application/yang-data+json]]></artwork> Accept: application/yang-data+json
</figure></t> ]]></artwork>
</figure>
<t>When conveying attack details in DOTS telemetry messages <t>When conveying attack details in DOTS telemetry messages
(Sections <xref format="counter" target="preCtoS"></xref>, <xref (Sections&nbsp;<xref format="counter" target="preCtoS"/>, <xref format
format="counter" target="preStoC"></xref>, and <xref ="counter" target="preStoC"/>, and <xref format="counter" target="status"/>), DO
format="counter" target="status"></xref>), DOTS agents MUST NOT TS agents <bcp14>MUST NOT</bcp14>
include the 'attack-description' attribute unless the corresponding include the 'attack-description' attribute unless the corresponding
attack mapping details were not previously shared with the peer DOTS attack mapping details were not previously shared with the peer DOTS
agent.</t> agent.</t>
</section> </section>
</section> </section>
<section anchor="preCtoS" numbered="true" toc="default">
<section anchor="preCtoS" title="From DOTS Clients to DOTS Servers"> <name>From DOTS Clients to DOTS Servers</name>
<t>DOTS clients use PUT requests to signal pre-or-ongoing-mitigation <t>DOTS clients use PUT requests to signal pre-or-ongoing-mitigation
telemetry to DOTS servers. An example of such a request is shown in telemetry to DOTS servers. An example of such a request is shown in
<xref target="put-tmid-c"></xref>.</t> <xref target="put-tmid-c" format="default"/>.</t>
<figure anchor="put-tmid-c">
<t><figure anchor="put-tmid-c" <name>PUT to Send Pre-or-Ongoing-Mitigation Telemetry, Depicted as per
title="PUT to Send Pre-or-Ongoing-Mitigation Telemetry, depicted as Section 5.6</name>
per Section 5.6"> <sourcecode name="" type="json"><![CDATA[Header: PUT (Code=0.03)
<artwork><![CDATA[Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=123" Uri-Path: "tmid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [ "pre-or-ongoing-mitigation": [
skipping to change at line 2675 skipping to change at line 2417
{ {
"vendor-id": 32473, "vendor-id": 32473,
"attack-id": 77, "attack-id": 77,
"start-time": "1608336568", "start-time": "1608336568",
"attack-severity": "high" "attack-severity": "high"
} }
] ]
} }
] ]
} }
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
<t>'cuid' is a mandatory Uri-Path parameter for DOTS PUT requests.</t> <t>'cuid' is a mandatory Uri-Path parameter for DOTS PUT requests.</t>
<t>The following additional Uri-Path parameter is defined: </t>
<t>The following additional Uri-Path parameter is defined: <list <dl newline="false" spacing="normal">
hangIndent="5" style="hanging"> <dt>tmid:</dt>
<t hangText="tmid:">Telemetry Identifier is an identifier for the <dd>
<t>The Telemetry Identifier is an identifier for the
DOTS pre-or-ongoing-mitigation telemetry data represented as an DOTS pre-or-ongoing-mitigation telemetry data represented as an
integer. This identifier MUST be generated by DOTS clients. 'tmid' integer. This identifier <bcp14>MUST</bcp14> be generated by DOTS cl
values MUST increase monotonically whenever a DOTS client needs to ients. &nbsp;'tmid'
convey new set of pre-or-ongoing-mitigation telemetry. <vspace values <bcp14>MUST</bcp14> increase monotonically whenever a DOTS cl
blankLines="1" />The procedure specified in Section 4.4.1 of <xref ient needs to
target="RFC9132"></xref> for 'mid' rollover MUST be followed for convey a new set of pre-or-ongoing-mitigation telemetry data. </t>
'tmid' rollover.<vspace blankLines="1" />This is a mandatory <t>The procedure specified in <xref target="RFC9132" sectionFormat="
attribute. 'tmid' MUST appear after 'cuid' in the Uri-Path of" section="4.4.1"/> for 'mid' rollover <bcp14>MUST</bcp14> be followed for
'tmid' rollover.</t>
<t>This is a mandatory
attribute. &nbsp;'tmid' <bcp14>MUST</bcp14> appear after 'cuid' in t
he Uri-Path
options.</t> options.</t>
</list></t> </dd>
</dl>
<t>'cuid' and 'tmid' MUST NOT appear in the PUT request message <t>'cuid' and 'tmid' <bcp14>MUST NOT</bcp14> appear in the PUT request m
essage
body.</t> body.</t>
<t>At least the 'target' attribute and another <t>At least the 'target' attribute and another
pre-or-ongoing-mitigation attribute (<xref target="pre"></xref>) MUST pre-or-ongoing-mitigation attribute (<xref target="pre" format="default" />) <bcp14>MUST</bcp14>
be present in the PUT request. If only the 'target' attribute is be present in the PUT request. If only the 'target' attribute is
present, this request is handled as per <xref present, this request is handled as per <xref target="preStoC" format="d
target="preStoC"></xref>.</t> efault"/>.</t>
<t>The relative order of two PUT requests carrying DOTS <t>The relative order of two PUT requests carrying DOTS
pre-or-ongoing-mitigation telemetry from a DOTS client is determined pre-or-ongoing-mitigation telemetry from a DOTS client is determined
by comparing their respective 'tmid' values. If two such requests have by comparing their respective 'tmid' values. If these two requests have
an overlapping 'target', the PUT request with higher numeric 'tmid' an overlapping 'target', the PUT request with a higher numeric 'tmid'
value will override the request with a lower numeric 'tmid' value. The value will override the request with a lower numeric 'tmid' value. The
overlapped lower numeric 'tmid' MUST be automatically deleted and no overlapped lower numeric 'tmid' <bcp14>MUST</bcp14> be automatically del eted and no
longer be available.</t> longer be available.</t>
<t>The DOTS server indicates the result of processing a PUT request <t>The DOTS server indicates the result of processing a PUT request
using CoAP Response Codes. In particular, the 2.04 (Changed) Response using CoAP Response Codes. In particular, the 2.04 (Changed) Response
Code is returned if the DOTS server has accepted the Code is returned if the DOTS server has accepted the
pre-or-ongoing-mitigation telemetry. The 5.03 (Service Unavailable) pre-or-ongoing-mitigation telemetry. The 5.03 (Service Unavailable)
Response Code is returned if the DOTS server has erred. 5.03 uses the Response Code is returned if the DOTS server has erred. The 5.03 Respons e Code uses the
Max-Age Option to indicate the number of seconds after which to Max-Age Option to indicate the number of seconds after which to
retry.</t> retry.</t>
<t>How long a DOTS server maintains a 'tmid' as active or logs the <t>How long a DOTS server maintains a 'tmid' as active or logs the
enclosed telemetry information is implementation specific. Note that enclosed telemetry information is implementation specific. Note that
if a 'tmid&rsquo; is still active, then logging details are updated by if a 'tmid' is still active, then logging details are updated by
the DOTS server as a function of the updates received from the peer the DOTS server as a function of the updates received from the peer
DOTS client.</t> DOTS client.</t>
<t>A DOTS client that lost the state of its active 'tmid's or has to <t>A DOTS client that lost the state of its active 'tmid's or has to
set 'tmid' back to zero (e.g., crash or restart) MUST send a GET set 'tmid' back to zero (e.g., crash or restart) <bcp14>MUST</bcp14> sen d a GET
request to the DOTS server to retrieve the list of active 'tmid' request to the DOTS server to retrieve the list of active 'tmid'
values. The DOTS client may then delete 'tmid's that should not be values. The DOTS client may then delete 'tmid's that should not be
active anymore (<xref target="spa"></xref>). Sending a DELETE with no active anymore (<xref target="spa" format="default"/>). Sending a DELETE
'tmid' indicates that all 'tmid's must be deactivated (<xref with no
target="dpa"></xref>).</t> 'tmid' indicates that all 'tmid's must be deactivated (<xref target="dpa
" format="default"/>).</t>
<t><figure anchor="spa" <figure anchor="spa">
title="Delete a Pre-or-Ongoing-Mitigation Telemetry"> <name>Deleting Specific Pre-or-Ongoing-Mitigation Telemetry Informati
<artwork align="left"><![CDATA[Header: DELETE (Code=0.04) on</name>
<sourcecode name="" type="json"><![CDATA[Header: DELETE (Code=0.04)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=123" Uri-Path: "tmid=123"
]]></artwork> ]]></sourcecode>
</figure><figure anchor="dpa" </figure>
title="Delete All Pre-or-Ongoing-Mitigation Telemetry"> <figure anchor="dpa">
<artwork align="left"><![CDATA[Header: DELETE (Code=0.04) <name>Deleting All Pre-or-Ongoing-Mitigation Telemetry Information</na
me>
<sourcecode name="" type="json"><![CDATA[Header: DELETE (Code=0.04)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
</section> </section>
<section anchor="preStoC" numbered="true" toc="default">
<section anchor="preStoC" title="From DOTS Servers to DOTS Clients"> <name>From DOTS Servers to DOTS Clients</name>
<t>The pre-or-ongoing-mitigation data (attack details, in particular) <t>The pre-or-ongoing-mitigation data (attack details in particular)
can also be signaled from DOTS servers to DOTS clients. For example, a can also be signaled from DOTS servers to DOTS clients. For example, a
DOTS server co-located with a DDoS detector can collect monitoring DOTS server co-located with a DDoS detector can collect monitoring
information from the target network, identify a DDoS attack using information from the target network, identify a DDoS attack using
statistical analysis or deep learning techniques, and signal the statistical analysis or deep learning techniques, and signal the
attack details to the DOTS client.</t> attack details to the DOTS client.</t>
<t>The DOTS client can use the attack details to decide whether to <t>The DOTS client can use the attack details to decide whether to
trigger a DOTS mitigation request or not. Furthermore, the security trigger a DOTS mitigation request or not. Furthermore, the security
operations personnel at the DOTS client domain can use the attack operations personnel at the DOTS client domain can use the attack
details to determine the protection strategy and select the details to determine the protection strategy and select the
appropriate DOTS server for mitigating the attack.</t> appropriate DOTS server for mitigating the attack.</t>
<t>In order to receive pre-or-ongoing-mitigation telemetry <t>In order to receive pre-or-ongoing-mitigation telemetry
notifications from a DOTS server, a DOTS client MUST send a PUT notifications from a DOTS server, a DOTS client <bcp14>MUST</bcp14> send a PUT
(followed by a GET) with the target filter. An example of such a PUT (followed by a GET) with the target filter. An example of such a PUT
request is shown in <xref target="put-tmid"></xref>. In order to avoid request is shown in <xref target="put-tmid" format="default"/>. In order
maintaining a long list of such requests, it is RECOMMENDED that DOTS to avoid
clients include all targets in the same request (assuming this fits maintaining a long list of such requests, it is <bcp14>RECOMMENDED</bcp1
4> that DOTS
clients include all targets in the same request (assuming that this info
rmation fits
within one single datagram). DOTS servers may be instructed to within one single datagram). DOTS servers may be instructed to
restrict the number of pre-or-ongoing-mitigation requests per DOTS restrict the number of pre-or-ongoing-mitigation requests per DOTS
client domain. The pre-or-ongoing mitigation requests MUST be client domain. The pre-or-ongoing-mitigation requests <bcp14>MUST</bcp14
maintained in an active state by the DOTS server until a delete > be
maintained in an active state by the DOTS server until a DELETE
request is received from the same DOTS client to clear this request is received from the same DOTS client to clear this
pre-or-ongoing-mitigation telemetry or when the DOTS client is pre-or-ongoing-mitigation telemetry or when the DOTS client is
considered inactive (e.g., Section 3.5 of <xref considered inactive (e.g., <xref target="RFC8783" sectionFormat="of" sec
target="RFC8783"></xref>).</t> tion="3.5"/>).</t>
<t>The relative order of two PUT requests carrying DOTS <t>The relative order of two PUT requests carrying DOTS
pre-or-ongoing-mitigation telemetry from a DOTS client is determined pre-or-ongoing-mitigation telemetry from a DOTS client is determined
by comparing their respective 'tmid' values. If such two requests have by comparing their respective 'tmid' values. If these two requests have
overlapping 'target', the PUT request with higher numeric 'tmid' value an
overlapping 'target', the PUT request with a higher numeric 'tmid' value
will override the request with a lower numeric 'tmid' value. The will override the request with a lower numeric 'tmid' value. The
overlapped lower numeric 'tmid' MUST be automatically deleted and no overlapped lower numeric 'tmid' <bcp14>MUST</bcp14> be automatically del eted and no
longer be available.</t> longer be available.</t>
<figure anchor="put-tmid">
<t><figure anchor="put-tmid" <name>PUT to Request Pre-or-Ongoing-Mitigation Telemetry, Depicted as
title="PUT to Request Pre-or-Ongoing-Mitigation Telemetry, depicted per Section 5.6</name>
as per Section 5.6"> <sourcecode name="" type="json"><![CDATA[Header: PUT (Code=0.03)
<artwork><![CDATA[Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=567" Uri-Path: "tmid=567"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [ "pre-or-ongoing-mitigation": [
{ {
"target": { "target": {
"target-prefix": [ "target-prefix": [
"2001:db8::/32" "2001:db8::/32"
] ]
} }
} }
] ]
} }
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
<t>DOTS clients of the same domain can request to receive <t>DOTS clients of the same domain can ask to receive
pre-or-ongoing-mitigation telemetry bound to the same target without pre-or-ongoing-mitigation telemetry bound to the same target without
being considered to be "overlapping" and in conflict.</t> being considered to be "overlapping" and in conflict.</t>
<t>Once the PUT request to instantiate request state on the server has <t>Once the PUT request to instantiate request state on the server has
succeeded, the DOTS client issues a GET request to receive ongoing succeeded, the DOTS client issues a GET request to receive ongoing
telemtry updates. The client uses the Observe Option, set to '0' telemetry updates. The client uses the Observe Option, set to "0"
(register), in the GET request to receive asynchronous notifications (register), in the GET request to receive asynchronous notifications
carrying pre-or-ongoing-mitigation telemetry data from the DOTS carrying pre-or-ongoing-mitigation telemetry data from the DOTS
server. The GET request can specify a specific 'tmid' (<xref server. The GET request can specify a specific 'tmid' (<xref target="get
target="gettmid"></xref>) or omit the 'tmid' (<xref tmid" format="default"/>) or omit the 'tmid' (<xref target="getall" format="defa
target="getall"></xref>) to receive updates on all active requests ult"/>) to receive updates on all active requests
from that client.</t> from that client.</t>
<figure anchor="gettmid">
<t><figure anchor="gettmid" <name>GET to Subscribe to Telemetry Asynchronous Notifications for a S
title="GET to Subscribe to Telemetry Asynchronous Notifications for pecific 'tmid'</name>
a Specific 'tmid'"> <sourcecode name="" type="json"><![CDATA[Header: GET (Code=0.01)
<artwork><![CDATA[Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=567" Uri-Path: "tmid=567"
Observe: 0]]></artwork> Observe: 0
</figure></t> ]]></sourcecode>
</figure>
<t></t> <figure anchor="getall">
<name>GET to Subscribe to Telemetry Asynchronous Notifications for All
<t><figure anchor="getall" 'tmid's</name>
title="GET to Subscribe to Telemetry Asynchronous Notifications for <sourcecode name="" type="json"><![CDATA[Header: GET (Code=0.01)
All 'tmids'">
<artwork><![CDATA[Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Observe: 0]]></artwork> Observe: 0
</figure></t> ]]></sourcecode>
</figure>
<t>The DOTS client can use a filter to request a subset of the <t>The DOTS client can use a filter to request a subset of the
asynchronous notifications from the DOTS server by indicating one or asynchronous notifications from the DOTS server by indicating one or
more Uri-Query options in its GET request. A Uri-Query option can more Uri-Query options in its GET request. A Uri-Query option can
include the following parameters to restrict the notifications based include the following parameters to restrict the notifications based
on the attack target: 'target-prefix', 'target-port', on the attack target: 'target-prefix', 'target-port',
'target-protocol', 'target-fqdn', 'target-uri', 'alias-name', 'mid', 'target-protocol', 'target-fqdn', 'target-uri', 'alias-name', 'mid',
and 'c' (content) (<xref target="control"></xref>). Furthermore:<list and 'c' (content) (<xref target="control" format="default"/>). Furthermo
style="empty"> re:</t>
<t>If more than one Uri-Query option is included in a request, <ul spacing="normal">
<li>If more than one Uri-Query option is included in a request,
these options are interpreted in the same way as when multiple these options are interpreted in the same way as when multiple
target attributes are included in a message body (Section 4.4.1 of target attributes are included in a message body (<xref target="RFC9
<xref target="RFC9132"></xref>).</t> 132" sectionFormat="of" section="4.4.1"/>).</li>
<li>If multiple values of a query parameter are to be included in a
<t>If multiple values of a query parameter are to be included in a request, these values <bcp14>MUST</bcp14> be included in the same Ur
request, these values MUST be included in the same Uri-Query i-Query
option and separated by a "," character without any spaces.</t> option and separated by a "," character without any spaces.</li>
<li>Range values (i.e., a contiguous inclusive block) can be
<t>Range values (i.e., a contiguous inclusive block) can be
included for the 'target-port', 'target-protocol', and 'mid' included for the 'target-port', 'target-protocol', and 'mid'
parameters by indicating the two boundary values separated by a parameters by indicating the two boundary values separated by a
"-" character.</t> "-" character.</li>
<li>Wildcard names (i.e., a name with the leftmost label is the "*"
<t>Wildcard names (i.e., a name with the leftmost label is the "*"
character) can be included in 'target-fqdn' or 'target-uri' character) can be included in 'target-fqdn' or 'target-uri'
parameters. DOTS clients MUST NOT include a name in which the "*" parameters. DOTS clients <bcp14>MUST NOT</bcp14> include a name in w hich the "*"
character is included in a label other than the leftmost label. character is included in a label other than the leftmost label.
"*.example.com" is an example of a valid wildcard name that can be "*.example.com" is an example of a valid wildcard name that can be
included as a value of the 'target-fqdn' parameter in an Uri-Query included as a value of the 'target-fqdn' parameter in a Uri-Query
option.</t> option.</li>
</list></t> </ul>
<t>DOTS clients may also filter out the asynchronous notifications <t>DOTS clients may also filter out the asynchronous notifications
from the DOTS server by indicating information about a specific attack from the DOTS server by indicating information about a specific attack
source. To that aim, a DOTS client may include 'source-prefix', source. To that aim, a DOTS client may include 'source-prefix',
'source-port', or 'source-icmp-type' in a Uri-Query option. The same 'source-port', or 'source-icmp-type' in a Uri-Query option. The same
considerations (ranges, multiple values) specified for target considerations (ranges, multiple values) specified for target
attributes apply for source attributes. Special care SHOULD be taken attributes apply for source attributes. Special care <bcp14>SHOULD</bcp1
when using these filters as their use may cause some attacks may be 4> be taken
hidden to the requesting DOTS client (e.g., if the attack changes its when using these filters, as their use may cause some attacks to be
hidden from the requesting DOTS client (e.g., if the attack changes its
source information).</t> source information).</t>
<t>Requests with invalid query types (e.g., not supported, malformed) <t>Requests with invalid query types (e.g., not supported, malformed)
received by the DOTS server MUST be rejected with a 4.00 (Bad Request) received by the DOTS server <bcp14>MUST</bcp14> be rejected with a 4.00
response code.</t> (Bad Request) Response Code.</t>
<t>An example of a request to subscribe to asynchronous telemetry <t>An example of a request to subscribe to asynchronous telemetry
notifications regarding UDP traffic is shown in <xref notifications regarding UDP traffic is shown in <xref target="notif_filt
target="notif_filter-tm"></xref>. This filter will be applied for all er-tm" format="default"/>. This filter will be applied for all
'tmid's.</t> 'tmid's.</t>
<figure anchor="notif_filter-tm">
<t><figure anchor="notif_filter-tm" <name>GET Request to Receive Telemetry Asynchronous Notifications Filt
title="GET Request to Receive Telemetry Asynchronous Notifications F ered Using Uri-Query</name>
iltered using Uri-Query"> <sourcecode name="" type="json"><![CDATA[Header: GET (Code=0.01)
<artwork><![CDATA[Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Query: "target-protocol=17" Uri-Query: "target-protocol=17"
Observe: 0]]></artwork> Observe: 0
</figure></t> ]]></sourcecode>
</figure>
<t>The DOTS server will send asynchronous notifications to the DOTS <t>The DOTS server will send asynchronous notifications to the DOTS
client when an attack event is detected following similar client when an attack event is detected, following considerations simila
considerations as in Section 4.4.2.1 of <xref r
target="RFC9132"></xref>. An example of a pre-or-ongoing-mitigation to those discussed in <xref target="RFC9132" sectionFormat="of" section=
telemetry notification is shown in <xref target="noti"></xref>.</t> "4.4.2.1"/>. An example of a pre-or-ongoing-mitigation
telemetry notification is shown in <xref target="noti" format="default"/
<t><figure anchor="noti" >.</t>
title="Message Body of a Pre-or-Ongoing-Mitigation Telemetry Notific <figure anchor="noti">
ation from the DOTS Server, depicted as per Section 5.6"> <name>Message Body of a Pre-or-Ongoing-Mitigation Telemetry Notificati
<artwork><![CDATA[{ on from the DOTS Server, Depicted as per Section 5.6</name>
<artwork name="" type="" align="left" alt=""><![CDATA[{
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [ "pre-or-ongoing-mitigation": [
{ {
"tmid": 567, "tmid": 567,
"target": { "target": {
"target-prefix": [ "target-prefix": [
"2001:db8::1/128" "2001:db8::1/128"
] ]
}, },
"target-protocol": [ "target-protocol": [
skipping to change at line 2951 skipping to change at line 2664
{ {
"vendor-id": 32473, "vendor-id": 32473,
"attack-id": 77, "attack-id": 77,
"start-time": "1618339785", "start-time": "1618339785",
"attack-severity": "high" "attack-severity": "high"
} }
] ]
} }
] ]
} }
}]]></artwork> }
</figure></t> ]]></artwork>
</figure>
<t>A DOTS server sends the aggregate data for a target using <t>A DOTS server sends the aggregate data for a target using the
'total-attack-traffic' attribute. The aggregate assumes that Uri-Query 'total-attack-traffic' attribute. The aggregate assumes that Uri-Query
filters are applied on the target. The DOTS server MAY include more filters are applied on the target. The DOTS server <bcp14>MAY</bcp14> in clude more
fine-grained data when needed (that is, fine-grained data when needed (that is,
'total-attack-traffic-protocol' and 'total-attack-traffic-port'). If a 'total-attack-traffic-protocol' and 'total-attack-traffic-port'). If a
port filter (or protocol filter) is included in a request, port filter (or protocol filter) is included in a request,
'total-attack-traffic-protocol' (or 'total-attack-traffic-port') 'total-attack-traffic-protocol' (or 'total-attack-traffic-port')
conveys the data with the port (or protocol) filter applied.</t> conveys the data with the port (or protocol) filter applied.</t>
<t>A DOTS server may aggregate pre-or-ongoing-mitigation data (e.g., <t>A DOTS server may aggregate pre-or-ongoing-mitigation data (e.g.,
'top-talker') for all targets of a domain, or when justified, send 'top-talker') for all targets of a domain or, when justified, send
specific information (e.g., 'top-talker') per individual targets.</t> specific information (e.g., 'top-talker') for a specific target.</t>
<t>The DOTS client may log pre-or-ongoing-mitigation telemetry data <t>The DOTS client may log pre-or-ongoing-mitigation telemetry data
with an alert sent to an administrator or a network controller. The with an alert sent to an administrator or a network controller. The
DOTS client may send a mitigation request if the attack cannot be DOTS client may send a mitigation request if the attack cannot be
handled locally.</t> handled locally.</t>
<t>A DOTS client that is not interested in receiving
<t>A DOTS client that is not interested to receive pre-or-ongoing-mitigation telemetry data for a target sends a DELETE
pre-or-ongoing-mitigation telemetry data for a target sends a delete request similar to the DELETE request depicted in <xref target="spa" for
request similar to the one depicted in <xref target="spa"></xref>.</t> mat="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="status" numbered="true" toc="default">
<section anchor="status" title="DOTS Telemetry Mitigation Status Update"> <name>DOTS Telemetry Mitigation Status Update</name>
<t></t> <section anchor="effu-S" numbered="true" toc="default">
<name>From DOTS Clients to DOTS Servers: Mitigation Efficacy DOTS Teleme
<section anchor="effu-S" try Attributes</name>
title="DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry
Attributes">
<t>The mitigation efficacy telemetry attributes can be signaled from <t>The mitigation efficacy telemetry attributes can be signaled from
DOTS clients to DOTS servers as part of the periodic mitigation DOTS clients to DOTS servers as part of the periodic mitigation
efficacy updates to the server (Section 4.4.3 of <xref efficacy updates to the server (<xref target="RFC9132" sectionFormat="of
target="RFC9132"></xref>).</t> " section="4.4.3"/>).</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Total attack traffic: </dt>
<t hangText="Total Attack Traffic: ">The overall attack traffic as <dd>The overall attack traffic as
observed from the DOTS client perspective during an active observed from the DOTS client's perspective during an active
mitigation. See <xref target="tatt"></xref>.</t> mitigation. See <xref target="tatt" format="default"/>.</dd>
<dt>Attack details: </dt>
<t hangText="Attack Details: ">The overall attack details as <dd>The overall attack details as
observed from the DOTS client perspective during an active observed from the DOTS client's perspective during an active
mitigation. See <xref target="attackdetails"></xref>.</t> mitigation. See <xref target="attackdetails" format="default"/>.</dd
</list></t> >
</dl>
<t>The "ietf-dots-telemetry" YANG module (<xref <t>The "ietf-dots-telemetry" YANG module (<xref target="module" format="
target="module"></xref>) augments the 'mitigation-scope' message type default"/>) augments the 'mitigation-scope' message type
defined in the "ietf-dots-signal" module <xref defined in the "ietf-dots-signal-channel" module <xref target="RFC9132"
target="RFC9132"></xref> so that these attributes can be signalled by format="default"/> so that these attributes can be signaled by
a DOTS client in a mitigation efficacy update (<xref a DOTS client in a mitigation efficacy update (<xref target="eff" format
target="eff"></xref>).<figure anchor="eff" ="default"/>).</t>
title="Telemetry Efficacy Update Tree Structure"> <figure anchor="eff">
<artwork><![CDATA[ augment-structure /dots-signal:dots-signal/dots- <name>Telemetry Efficacy Update Tree Structure</name>
signal:message-type <sourcecode name="" type="yangtree"><![CDATA[ augment-structure /dots-signal:do
ts-signal/dots-signal:message-type
/dots-signal:mitigation-scope/dots-signal:scope: /dots-signal:mitigation-scope/dots-signal:scope:
+-- total-attack-traffic* [unit] +-- total-attack-traffic* [unit]
| +-- unit unit | +-- unit unit
| +-- low-percentile-g? yang:gauge64 | +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64 | +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64 | +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64 | +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64 | +-- current-g? yang:gauge64
+-- attack-detail* [vendor-id attack-id] +-- attack-detail* [vendor-id attack-id]
+-- vendor-id uint32 +-- vendor-id uint32
+-- attack-id uint32 +-- attack-id uint32
+-- attack-description? string +-- attack-description? string
+-- attack-severity? attack-severity +-- attack-severity? attack-severity
+-- start-time? uint64 +-- start-time? uint64
+-- end-time? uint64 +-- end-time? uint64
+-- source-count +-- source-count
| +-- low-percentile-g? yang:gauge64 | +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64 | +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64 | +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64 | +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64 | +-- current-g? yang:gauge64
+-- top-talker +-- top-talker
+-- talker* [source-prefix] +-- talker* [source-prefix]
+-- spoofed-status? boolean +-- spoofed-status? boolean
+-- source-prefix inet:ip-prefix +-- source-prefix inet:ip-prefix
+-- source-port-range* [lower-port] +-- source-port-range* [lower-port]
| +-- lower-port inet:port-number | +-- lower-port inet:port-number
| +-- upper-port? inet:port-number | +-- upper-port? inet:port-number
+-- source-icmp-type-range* [lower-type] +-- source-icmp-type-range* [lower-type]
| +-- lower-type uint8 | +-- lower-type uint8
| +-- upper-type? uint8 | +-- upper-type? uint8
+-- total-attack-traffic* [unit] +-- total-attack-traffic* [unit]
| +-- unit unit | +-- unit unit
| +-- low-percentile-g? yang:gauge64 | +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64 | +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64 | +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64 | +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64 | +-- current-g? yang:gauge64
+-- total-attack-connection +-- total-attack-connection
+-- connection-c +-- connection-c
| +-- low-percentile-g? yang:gauge64 | +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64 | +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64 | +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64 | +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64 | +-- current-g? yang:gauge64
+-- embryonic-c +-- embryonic-c
| ... | ...
+-- connection-ps-c +-- connection-ps-c
| ... | ...
+-- request-ps-c +-- request-ps-c
| ... | ...
+-- partial-request-c +-- partial-request-c
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>In order to signal telemetry data in a mitigation efficacy update, <t>In order to signal telemetry data in a mitigation efficacy update,
it is RECOMMENDED that the DOTS client has already established a DOTS it is <bcp14>RECOMMENDED</bcp14> that the DOTS client have already estab lished a DOTS
telemetry setup session with the server in 'idle' time. Such a session telemetry setup session with the server in 'idle' time. Such a session
is primarily meant to assess whether the peer DOTS server supports is primarily meant to assess whether the peer DOTS server supports
telemetry extensions and, thus, prevent message processing failure telemetry extensions and to thus prevent message processing failure
(Section 3.1 of <xref target="RFC9132"></xref>).</t> (<xref target="RFC9132" sectionFormat="of" section="3.1"/>).</t>
<t>An example of an efficacy update with telemetry attributes is <t>An example of an efficacy update with telemetry attributes is
depicted in <xref target="effu"></xref>.</t> depicted in <xref target="effu" format="default"/>.</t>
<figure anchor="effu">
<t><figure anchor="effu" <name>Example of Mitigation Efficacy Update with Telemetry Attributes,
title="An Example of Mitigation Efficacy Update with Telemetry Attri Depicted as per Section 5.6</name>
butes, depicted as per Section 5.6"> <sourcecode name="" type="json"><![CDATA[Header: PUT (Code=0.03)
<artwork><![CDATA[Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
If-Match: If-Match:
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
skipping to change at line 3101 skipping to change at line 2802
"attack-status": "under-attack", "attack-status": "under-attack",
"ietf-dots-telemetry:total-attack-traffic": [ "ietf-dots-telemetry:total-attack-traffic": [
{ {
"unit": "megabit-ps", "unit": "megabit-ps",
"mid-percentile-g": "900" "mid-percentile-g": "900"
} }
] ]
} }
] ]
} }
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
</section> </section>
<section anchor="premStoC" numbered="true" toc="default">
<section anchor="premStoC" <name>From DOTS Servers to DOTS Clients: Mitigation Status DOTS Telemetr
title="DOTS Servers to Clients Mitigation Status DOTS Telemetry A y Attributes</name>
ttributes ">
<t>The mitigation status telemetry attributes can be signaled from the <t>The mitigation status telemetry attributes can be signaled from the
DOTS server to the DOTS client as part of the periodic mitigation DOTS server to the DOTS client as part of the periodic mitigation
status update (Section 4.4.2 of <xref target="RFC9132"></xref>). In status update (<xref target="RFC9132" sectionFormat="of" section="4.4.2" />). In
particular, DOTS clients can receive asynchronous notifications of the particular, DOTS clients can receive asynchronous notifications of the
attack details from DOTS servers using the Observe option defined in attack details from DOTS servers using the Observe Option defined in
<xref target="RFC7641"></xref>.</t> <xref target="RFC7641" format="default"/>.</t>
<t>In order to make use of this feature, DOTS clients <bcp14>MUST</bcp14
<t>In order to make use of this feature, DOTS clients MUST establish a > establish a
telemetry session with the DOTS server in 'idle' time and MUST set the telemetry session with the DOTS server in 'idle' time and <bcp14>MUST</b
cp14> set the
'server-originated-telemetry' attribute to 'true'.</t> 'server-originated-telemetry' attribute to 'true'.</t>
<t>DOTS servers <bcp14>MUST NOT</bcp14> include telemetry attributes in
<t>DOTS servers MUST NOT include telemetry attributes in mitigation mitigation
status updates sent to DOTS clients for telemetry sessions in which status updates sent to DOTS clients for telemetry sessions in which
the 'server-originated-telemetry' attribute is set to 'false'.</t> the 'server-originated-telemetry' attribute is set to 'false'.</t>
<t>As defined in <xref target="RFC8612" format="default"/>, the actual m
<t>As defined in <xref target="RFC8612"></xref>, the actual mitigation itigation
activities can include several countermeasure mechanisms. The DOTS activities can include several countermeasure mechanisms. The DOTS
server signals the current operational status of relevant server signals the current operational status of relevant
countermeasures. A list of attacks detected by these countermeasures countermeasures. A list of attacks detected by these countermeasures
MAY also be included. The same attributes defined in <xref <bcp14>MAY</bcp14> also be included. The same attributes as those define
target="attackdetails"></xref> are applicable for describing the d in <xref target="attackdetails" format="default"/> are applicable for describi
ng the
attacks detected and mitigated at the DOTS server domain.</t> attacks detected and mitigated at the DOTS server domain.</t>
<t>The "ietf-dots-telemetry" YANG module (<xref target="module" format="
<t>The "ietf-dots-telemetry" YANG module (<xref default"/>) augments the 'mitigation-scope' message type
target="module"></xref>) augments the 'mitigation-scope' message type defined in the "ietf-dots-signal-channel" module <xref target="RFC9132"
defined in "ietf-dots-signal" <xref target="RFC9132"></xref> with format="default"/> with
telemetry data as depicted in <xref target="miscope"></xref>.<figure telemetry data as depicted in <xref target="miscope" format="default"/>.
anchor="miscope" </t>
title="DOTS Servers to Clients Mitigation Status Telemetry Tree Stru <figure anchor="miscope">
cture"> <name>DOTS Server-to-Client Mitigation Status Telemetry Tree Structure
<artwork><![CDATA[ augment-structure /dots-signal:dots-signal/dots- </name>
signal:message-type <sourcecode name="" type="yangtree"><![CDATA[ augment-structure /dots-signal:do
ts-signal/dots-signal:message-type
/dots-signal:mitigation-scope/dots-signal:scope: /dots-signal:mitigation-scope/dots-signal:scope:
+-- (direction)? +-- (direction)?
| +--:(server-to-client-only) | +--:(server-to-client-only)
| +-- total-traffic* [unit] | +-- total-traffic* [unit]
| | +-- unit unit | | +-- unit unit
| | +-- low-percentile-g? yang:gauge64 | | +-- low-percentile-g? yang:gauge64
| | +-- mid-percentile-g? yang:gauge64 | | +-- mid-percentile-g? yang:gauge64
| | +-- high-percentile-g? yang:gauge64 | | +-- high-percentile-g? yang:gauge64
| | +-- peak-g? yang:gauge64 | | +-- peak-g? yang:gauge64
| | +-- current-g? yang:gauge64 | | +-- current-g? yang:gauge64
skipping to change at line 3214 skipping to change at line 2909
| +-- peak-g? yang:gauge64 | +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64 | +-- current-g? yang:gauge64
+-- embryonic-c +-- embryonic-c
| ... | ...
+-- connection-ps-c +-- connection-ps-c
| ... | ...
+-- request-ps-c +-- request-ps-c
| ... | ...
+-- partial-request-c +-- partial-request-c
... ...
]]></sourcecode>
]]></artwork> </figure>
</figure></t> <t><xref target="upex" format="default"/> shows an example of an asynchr
onous
<t><xref target="upex"></xref> shows an example of an asynchronous
notification of attack mitigation status from the DOTS server. This notification of attack mitigation status from the DOTS server. This
notification signals both the mid-percentile value of processed attack notification signals both the mid-percentile value of processed attack
traffic and the peak count of unique sources involved in the traffic and the peak count of unique sources involved in the
attack.</t> attack.</t>
<figure anchor="upex">
<t><figure anchor="upex" <name>Response Body of a Mitigation Status with Telemetry Attributes,
title="Response Body of a Mitigation Status With Telemetry Attribute Depicted as per Section 5.6</name>
s, depicted as per Section 5.6"> <artwork name="" type="" align="left" alt=""><![CDATA[{
<artwork><![CDATA[{
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"mid": 12332, "mid": 12332,
"mitigation-start": "1507818434", "mitigation-start": "1507818434",
"alias-name": [ "alias-name": [
"https1", "https1",
"https2" "https2"
], ],
"lifetime": 1600, "lifetime": 1600,
skipping to change at line 3260 skipping to change at line 2952
"vendor-id": 32473, "vendor-id": 32473,
"attack-id": 77, "attack-id": 77,
"source-count": { "source-count": {
"peak-g": "12683" "peak-g": "12683"
} }
} }
] ]
} }
] ]
} }
}]]></artwork> }
</figure></t> ]]></artwork>
</figure>
<t>DOTS clients can filter out the asynchronous notifications from the <t>DOTS clients can filter out the asynchronous notifications from the
DOTS server by indicating one or more Uri-Query options in its GET DOTS server by indicating one or more Uri-Query options in its GET
request. A Uri-Query option can include the following parameters: request. A Uri-Query option can include the following parameters:
'target-prefix', 'target-port', 'target-protocol', 'target-fqdn', 'target-prefix', 'target-port', 'target-protocol', 'target-fqdn',
'target-uri', 'alias-name', and 'c' (content) (<xref 'target-uri', 'alias-name', and 'c' (content) (<xref target="control" fo
target="control"></xref>). The considerations discussed in <xref rmat="default"/>). The considerations discussed in <xref target="preStoC" format
target="preStoC"></xref> MUST be followed to include multiple query ="default"/> <bcp14>MUST</bcp14> be followed to include multiple query
values, ranges ('target-port', 'target-protocol'), and wildcard names values, ranges ('target-port', 'target-protocol'), and wildcard names
('target-fqdn', 'target-uri').</t> ('target-fqdn', 'target-uri').</t>
<t>An example of a request to subscribe to asynchronous notifications
<t>An example of request to subscribe to asynchronous notifications bound to the "https1" alias is shown in <xref target="notif_filter" form
bound to the "https1" alias is shown in <xref at="default"/>.</t>
target="notif_filter"></xref>.</t> <figure anchor="notif_filter">
<name>GET Request to Receive Asynchronous Notifications
<t><figure anchor="notif_filter" Filtered Using Uri-&wj;Query</name>
title="GET Request to Receive Asynchronous Notifications Filtered us <sourcecode name="" type="json"><![CDATA[Header: GET (Code=0.01)
ing Uri-Query">
<artwork><![CDATA[Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=12332" Uri-Path: "mid=12332"
Uri-Query: "target-alias=https1" Uri-Query: "target-alias=https1"
Observe: 0]]></artwork> Observe: 0
</figure></t> ]]></sourcecode>
</figure>
<t>If the target query does not match the target of the enclosed 'mid' <t>If the target query does not match the target of the enclosed 'mid'
as maintained by the DOTS server, the latter MUST respond with a 4.04 as maintained by the DOTS server, the latter <bcp14>MUST</bcp14> respond
(Not Found) error Response Code. The DOTS server MUST NOT add a new with a 4.04
observe entry if this query overlaps with an existing one. In such a (Not Found) error Response Code. The DOTS server <bcp14>MUST NOT</bcp14>
case, the DOTS server replies with 4.09 (Conflict).</t> add a new
Observe entry if this query overlaps with an existing Observe entry. In
such a
case, the DOTS server replies with a 4.09 (Conflict) Response Code.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Error Handling"> <name>Error Handling</name>
<t>A list of common CoAP errors that are implemented by DOTS servers are <t>A list of common CoAP errors that are implemented by DOTS servers is
provided in Section 9 of <xref target="RFC9132"></xref>. The following provided in <xref target="RFC9132" sectionFormat="of" section="9"/>. The f
ollowing
additional error cases apply for the telemetry extension:</t> additional error cases apply for the telemetry extension:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>4.00 (Bad Request) is returned by the DOTS server when the DOTS
<t>4.00 (Bad Request) is returned by the DOTS server when the DOTS
client has sent a request that violates the DOTS telemetry client has sent a request that violates the DOTS telemetry
extension.</t> extension.</li>
<li>4.04 (Not Found) is returned by the DOTS server when the DOTS
<t>4.04 (Not Found) is returned by the DOTS server when the DOTS client is requesting a 'tsid' or 'tmid' that is not valid.</li>
client is requesting a 'tsid' or 'tmid' that is not valid.</t> <li>4.00 (Bad Request) is returned by the DOTS server when the DOTS
<t>4.00 (Bad Request) is returned by the DOTS server when the DOTS
client has sent a request with invalid query types (e.g., not client has sent a request with invalid query types (e.g., not
supported, malformed).</t> supported, malformed).</li>
<li>4.04 (Not Found) is returned by the DOTS server when the DOTS
<t>4.04 (Not Found) is returned by the DOTS server when the DOTS
client has sent a request with a target query that does not match client has sent a request with a target query that does not match
the target of the enclosed 'mid' as maintained by the DOTS the target of the enclosed 'mid' as maintained by the DOTS
server.</t> server.</li>
</list></t> </ul>
<t>As indicated in <xref target="RFC9132" sectionFormat="of" section="9"/>
<t>As indicated in Section 9 of <xref target="RFC9132"></xref>, an , an
additional plain text diagnostic payload (Section 5.5.2 of <xref additional plaintext diagnostic payload (<xref target="RFC7252" sectionFor
target="RFC7252"></xref>) to help troubleshooting is returned in the mat="of" section="5.5.2"/>) to help with troubleshooting is returned in the
body of the response.</t> body of the response.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="YANG Modules"> <name>YANG Modules</name>
<t></t> <section anchor="module" numbered="true" toc="default">
<name>DOTS Signal Channel Telemetry YANG Module</name>
<section anchor="module" <t>This module uses types defined in <xref target="RFC6991" format="defa
title="DOTS Signal Channel Telemetry YANG Module"> ult"/> and <xref target="RFC8345" format="default"/>. It also reuses a grouping
<t>This module uses types defined in <xref target="RFC6991"></xref> from <xref target="RFC8783"/>.</t>
and <xref target="RFC8345"></xref>.</t> <sourcecode name="ietf-dots-telemetry@2022-05-18.yang" type="yang" marke
rs="true"><![CDATA[
<t><figure>
<artwork><![CDATA[<CODE BEGINS> file "ietf-dots-telemetry@2022-02-04
.yang"
module ietf-dots-telemetry { module ietf-dots-telemetry {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry"; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry";
prefix dots-telemetry; prefix dots-telemetry;
import ietf-dots-signal-channel { import ietf-dots-signal-channel {
prefix dots-signal; prefix dots-signal;
reference reference
"RFC 9132: Distributed Denial-of-Service Open Threat Signaling "RFC 9132: Distributed Denial-of-Service Open Threat
(DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
} }
import ietf-dots-data-channel { import ietf-dots-data-channel {
prefix data-channel; prefix data-channel;
reference reference
"RFC 8783: Distributed Denial-of-Service Open Threat "RFC 8783: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Data Channel Specification"; Signaling (DOTS) Data Channel Specification";
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
"Section 3 of RFC 6991"; "RFC 6991: Common YANG Data Types, Section 3";
} }
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"Section 4 of RFC 6991"; "RFC 6991: Common YANG Data Types, Section 4";
} }
import ietf-network-topology { import ietf-network-topology {
prefix nt; prefix nt;
reference reference
"Section 6.2 of RFC 8345: A YANG Data Model for Network "RFC 8345: A YANG Data Model for Network Topologies,
Topologies"; Section 6.2";
} }
import ietf-yang-structure-ext { import ietf-yang-structure-ext {
prefix sx; prefix sx;
reference reference
"RFC 8791: YANG Data Structure Extensions"; "RFC 8791: YANG Data Structure Extensions";
} }
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>
Author: Mohamed Boucadair Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Author: Konda, Tirumaleswar Reddy.K Author: Konda, Tirumaleswar Reddy.K
<mailto:kondtir@gmail.com>"; <mailto:kondtir@gmail.com>";
description description
"This module contains YANG definitions for the signaling "This module contains YANG definitions for the signaling
of DOTS telemetry data exchanged between a DOTS client and of DOTS telemetry data exchanged between a DOTS client and
a DOTS server by means of the DOTS signal channel. a DOTS server by means of the DOTS signal channel.
Copyright (c) 2022 IETF Trust and the persons identified as Copyright (c) 2022 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 to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://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 9244; see the
the RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2022-02-04 { revision 2022-05-18 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Distributed Denial-of-Service Open Threat "RFC 9244: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry"; Signaling (DOTS) Telemetry";
} }
typedef attack-severity { typedef attack-severity {
type enumeration { type enumeration {
enum none { enum none {
value 1; value 1;
description description
"No effect on the DOTS client domain."; "No effect on the DOTS client domain.";
} }
enum low { enum low {
value 2; value 2;
description description
"Minimal effect on the DOTS client domain."; "Minimal effect on the DOTS client domain.";
} }
enum medium { enum medium {
value 3; value 3;
description description
"A subset of DOTS client domain resources are "A subset of DOTS client domain resources is
out of service."; out of service.";
} }
enum high { enum high {
value 4; value 4;
description description
"The DOTS client domain is under extremely severe "The DOTS client domain is under extremely severe
conditions."; conditions.";
} }
enum unknown { enum unknown {
value 5; value 5;
skipping to change at line 3459 skipping to change at line 3136
typedef unit-class { typedef unit-class {
type enumeration { type enumeration {
enum packet-ps { enum packet-ps {
value 1; value 1;
description description
"Packets per second (pps)."; "Packets per second (pps).";
} }
enum bit-ps { enum bit-ps {
value 2; value 2;
description description
"Bits per Second (bit/s)."; "Bits per second (bps).";
} }
enum byte-ps { enum byte-ps {
value 3; value 3;
description description
"Bytes per second (Byte/s)."; "Bytes per second (Bps).";
} }
} }
description description
"Enumeration to indicate which unit class is used. "Enumeration to indicate which unit class is used.
These classes are supported: pps, bit/s, and Byte/s."; These classes are supported: pps, bps, and Bps.";
} }
typedef unit { typedef unit {
type enumeration { type enumeration {
enum packet-ps { enum packet-ps {
value 1; value 1;
description description
"Packets per second (pps)."; "Packets per second (pps).";
} }
enum bit-ps { enum bit-ps {
value 2; value 2;
description description
"Bits per Second (bps)."; "Bits per second (bps).";
} }
enum byte-ps { enum byte-ps {
value 3; value 3;
description description
"Bytes per second (Bps)."; "Bytes per second (Bps).";
} }
enum kilopacket-ps { enum kilopacket-ps {
value 4; value 4;
description description
"Kilo packets per second (kpps)."; "Kilo packets per second (kpps).";
skipping to change at line 3648 skipping to change at line 3325
} }
description description
"Enumeration to indicate the overall measurement period."; "Enumeration to indicate the overall measurement period.";
} }
typedef sample { typedef sample {
type enumeration { type enumeration {
enum second { enum second {
value 1; value 1;
description description
"A one-second measurement period."; "One-second measurement period.";
} }
enum 5-seconds { enum 5-seconds {
value 2; value 2;
description description
"5-second measurement period."; "5-second measurement period.";
} }
enum 30-seconds { enum 30-seconds {
value 3; value 3;
description description
"30-second measurement period."; "30-second measurement period.";
skipping to change at line 3749 skipping to change at line 3426
"Query based on source prefix."; "Query based on source prefix.";
} }
enum source-port { enum source-port {
value 9; value 9;
description description
"Query based on source port number."; "Query based on source port number.";
} }
enum source-icmp-type { enum source-icmp-type {
value 10; value 10;
description description
"Query based on ICMP type"; "Query based on ICMP type.";
} }
enum content { enum content {
value 11; value 11;
description description
"Query based on 'c' Uri-Query option that is used "Query based on the 'c' (content) Uri-Query option,
to control the selection of configuration which is used to control the selection of configuration
and non-configuration data nodes."; and non-configuration data nodes.";
reference reference
"Section 4.4.2 of RFC 9132."; "RFC 9132: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel
Specification, Section 4.4.2";
} }
} }
description description
"Enumeration of support for query types that can be used "Enumeration of support for query types that can be used
in a GET request to filter out data. Requests with in a GET request to filter out data. Requests with
invalid query types (e.g., not supported, malformed) invalid query types (e.g., not supported, malformed)
received by the DOTS server are rejected with received by the DOTS server are rejected with
a 4.00 (Bad Request) response code."; a 4.00 (Bad Request) Response Code.";
} }
grouping telemetry-parameters { grouping telemetry-parameters {
description description
"A grouping that includes a set of parameters that "A grouping that includes a set of parameters that
are used to prepare the reported telemetry data. are used to prepare the reported telemetry data.
The grouping indicates a measurement interval, The grouping indicates a measurement interval,
a measurement sample period, and low/mid/high a measurement sample period, and
percentile values."; low-percentile/mid-percentile/high-percentile values.";
leaf measurement-interval { leaf measurement-interval {
type interval; type interval;
description description
"Defines the period on which percentiles are computed."; "Defines the period during which percentiles are
computed.";
} }
leaf measurement-sample { leaf measurement-sample {
type sample; type sample;
description description
"Defines the time distribution for measuring "Defines the time distribution for measuring
values that are used to compute percentiles. values that are used to compute percentiles.
The measurement sample value must be less than the The measurement sample value must be less than the
measurement interval value."; measurement interval value.";
} }
leaf low-percentile { leaf low-percentile {
type percentile; type percentile;
default "10.00"; default "10.00";
description description
"Low percentile. If set to '0', this means low-percentiles "Low-percentile. If set to '0', this means that
are disabled."; the use of low-percentile values is disabled.";
} }
leaf mid-percentile { leaf mid-percentile {
type percentile; type percentile;
must '. >= ../low-percentile' { must '. >= ../low-percentile' {
error-message error-message
"The mid-percentile must be greater than "The mid-percentile must be greater than
or equal to the low-percentile."; or equal to the low-percentile.";
} }
default "50.00"; default "50.00";
description description
"Mid percentile. If set to the same value as low-percentile, "Mid-percentile. If set to the same value as
this means mid-percentiles are disabled."; 'low-percentile', this means that the use of
mid-percentile values is disabled.";
} }
leaf high-percentile { leaf high-percentile {
type percentile; type percentile;
must '. >= ../mid-percentile' { must '. >= ../mid-percentile' {
error-message error-message
"The high-percentile must be greater than "The high-percentile must be greater than
or equal to the mid-percentile."; or equal to the mid-percentile.";
} }
default "90.00"; default "90.00";
description description
"High percentile. If set to the same value as mid-percentile, "High-percentile. If set to the same value as
this means high-percentiles are disabled."; 'mid-percentile', this means that the use of
high-percentile values is disabled.";
} }
} }
grouping percentile-and-peak { grouping percentile-and-peak {
description description
"Generic grouping for percentile and peak values."; "Generic grouping for percentile and peak values.";
leaf low-percentile-g { leaf low-percentile-g {
type yang:gauge64; type yang:gauge64;
description description
"Low percentile value."; "Low-percentile value.";
} }
leaf mid-percentile-g { leaf mid-percentile-g {
type yang:gauge64; type yang:gauge64;
description description
"Mid percentile value."; "Mid-percentile value.";
} }
leaf high-percentile-g { leaf high-percentile-g {
type yang:gauge64; type yang:gauge64;
description description
"High percentile value."; "High-percentile value.";
} }
leaf peak-g { leaf peak-g {
type yang:gauge64; type yang:gauge64;
description description
"Peak value."; "Peak value.";
} }
} }
grouping percentile-peak-and-current { grouping percentile-peak-and-current {
description description
skipping to change at line 3871 skipping to change at line 3553
description description
"Generic grouping for unit configuration."; "Generic grouping for unit configuration.";
list unit-config { list unit-config {
key "unit"; key "unit";
description description
"Controls which unit classes are allowed when sharing "Controls which unit classes are allowed when sharing
telemetry data."; telemetry data.";
leaf unit { leaf unit {
type unit-class; type unit-class;
description description
"Can be packet-ps, bit-ps, or byte-ps."; "Can be 'packet-ps', 'bit-ps', or 'byte-ps'.";
} }
leaf unit-status { leaf unit-status {
type boolean; type boolean;
mandatory true; mandatory true;
description description
"Enable/disable the use of the measurement unit class."; "Enable/disable the use of the measurement unit class.";
} }
} }
} }
grouping traffic-unit { grouping traffic-unit {
description description
"Grouping of traffic as a function of the measurement unit."; "Grouping of traffic as a function of the
measurement unit.";
leaf unit { leaf unit {
type unit; type unit;
description description
"The traffic can be measured using unit classes: packet-ps, "The traffic can be measured using unit classes:
bit-ps, or byte-ps. DOTS agents auto-scale to the 'packet-ps', 'bit-ps', or 'byte-ps'. DOTS agents
appropriate units (e.g., megabit-ps, kilobit-ps)."; auto-scale to the appropriate units (e.g., 'megabit-ps',
'kilobit-ps').";
} }
uses percentile-and-peak; uses percentile-and-peak;
} }
grouping traffic-unit-all { grouping traffic-unit-all {
description description
"Grouping of traffic as a function of the measurement unit, "Grouping of traffic as a function of the measurement unit,
including current values."; including current values.";
uses traffic-unit; uses traffic-unit;
leaf current-g { leaf current-g {
skipping to change at line 3915 skipping to change at line 3599
} }
grouping traffic-unit-protocol { grouping traffic-unit-protocol {
description description
"Grouping of traffic of a given transport protocol as "Grouping of traffic of a given transport protocol as
a function of the measurement unit."; a function of the measurement unit.";
leaf protocol { leaf protocol {
type uint8; type uint8;
description description
"The transport protocol. "The transport protocol.
Values are taken from the IANA Protocol Numbers registry: Values are taken from the IANA 'Protocol Numbers'
registry:
<https://www.iana.org/assignments/protocol-numbers/>. <https://www.iana.org/assignments/protocol-numbers/>.
For example, this parameter contains 6 for TCP, For example, this parameter contains 6 for TCP,
17 for UDP, 33 for DCCP, or 132 for SCTP."; 17 for UDP, 33 for the Datagram Congestion Control
Protocol (DCCP), or 132 for the Stream Control
Transmission Protocol (SCTP).";
} }
uses traffic-unit; uses traffic-unit;
} }
grouping traffic-unit-protocol-all { grouping traffic-unit-protocol-all {
description description
"Grouping of traffic of a given transport protocol as "Grouping of traffic of a given transport protocol as
a function of the measurement unit, including current a function of the measurement unit, including current
values."; values.";
uses traffic-unit-protocol; uses traffic-unit-protocol;
skipping to change at line 3965 skipping to change at line 3652
leaf current-g { leaf current-g {
type yang:gauge64; type yang:gauge64;
description description
"Current observed value."; "Current observed value.";
} }
} }
grouping total-connection-capacity { grouping total-connection-capacity {
description description
"Total connection capacities for various types of "Total connection capacities for various types of
connections, as well as overall capacity. These data nodes are connections, as well as overall capacity. These data nodes
useful to detect resource-consuming DDoS attacks."; are useful for detecting resource-consuming DDoS attacks.";
leaf connection { leaf connection {
type uint64; type uint64;
description description
"The maximum number of simultaneous connections that "The maximum number of simultaneous connections that
are allowed to the target server."; are allowed to the target server.";
} }
leaf connection-client { leaf connection-client {
type uint64; type uint64;
description description
"The maximum number of simultaneous connections that "The maximum number of simultaneous connections that
are allowed to the target server per client."; are allowed to the target server per client.";
} }
leaf embryonic { leaf embryonic {
type uint64; type uint64;
description description
"The maximum number of simultaneous embryonic connections "The maximum number of simultaneous embryonic connections
that are allowed to the target server. The term 'embryonic that are allowed to the target server. The term
connection' refers to a connection whose connection 'embryonic connection' refers to a connection whose
handshake is not finished. Embryonic connections are only connection handshake is not finished. Embryonic
possible in connection-oriented transport protocols like connections are only possible in connection-oriented
TCP or SCTP."; transport protocols like TCP or SCTP.";
} }
leaf embryonic-client { leaf embryonic-client {
type uint64; type uint64;
description description
"The maximum number of simultaneous embryonic connections "The maximum number of simultaneous embryonic connections
that are allowed to the target server per client."; that are allowed to the target server per client.";
} }
leaf connection-ps { leaf connection-ps {
type uint64; type uint64;
description description
skipping to change at line 4035 skipping to change at line 3722
leaf partial-request-client-max { leaf partial-request-client-max {
type uint64; type uint64;
description description
"The maximum number of outstanding partial requests "The maximum number of outstanding partial requests
that are allowed to the target server per client."; that are allowed to the target server per client.";
} }
} }
grouping total-connection-capacity-protocol { grouping total-connection-capacity-protocol {
description description
"Total connections capacity per protocol. These data nodes are "Total connection capacity per protocol. These data nodes
useful to detect resource consuming DDoS attacks."; are useful for detecting resource-consuming DDoS attacks.";
leaf protocol { leaf protocol {
type uint8; type uint8;
description description
"The transport protocol. "The transport protocol.
Values are taken from the IANA Protocol Numbers registry: Values are taken from the IANA 'Protocol Numbers'
registry:
<https://www.iana.org/assignments/protocol-numbers/>."; <https://www.iana.org/assignments/protocol-numbers/>.";
} }
uses total-connection-capacity; uses total-connection-capacity;
} }
grouping connection-percentile-and-peak { grouping connection-percentile-and-peak {
description description
"A set of data nodes which represent the attack "A set of data nodes that represent the attack
characteristics."; characteristics.";
container connection-c { container connection-c {
uses percentile-and-peak; uses percentile-and-peak;
description description
"The number of simultaneous attack connections to "The number of simultaneous attack connections to
the target server."; the target server.";
} }
container embryonic-c { container embryonic-c {
uses percentile-and-peak; uses percentile-and-peak;
description description
skipping to change at line 4085 skipping to change at line 3773
container partial-request-c { container partial-request-c {
uses percentile-and-peak; uses percentile-and-peak;
description description
"The number of attack partial requests to "The number of attack partial requests to
the target server."; the target server.";
} }
} }
grouping connection-all { grouping connection-all {
description description
"Total attack connections including current values."; "Total attack connections, including current values.";
container connection-c { container connection-c {
uses percentile-peak-and-current; uses percentile-peak-and-current;
description description
"The number of simultaneous attack connections to "The number of simultaneous attack connections to
the target server."; the target server.";
} }
container embryonic-c { container embryonic-c {
uses percentile-peak-and-current; uses percentile-peak-and-current;
description description
"The number of simultaneous embryonic connections to "The number of simultaneous embryonic connections to
skipping to change at line 4125 skipping to change at line 3813
} }
} }
grouping connection-protocol { grouping connection-protocol {
description description
"Total attack connections."; "Total attack connections.";
leaf protocol { leaf protocol {
type uint8; type uint8;
description description
"The transport protocol. "The transport protocol.
Values are taken from the IANA Protocol Numbers registry: Values are taken from the IANA 'Protocol Numbers'
registry:
<https://www.iana.org/assignments/protocol-numbers/>."; <https://www.iana.org/assignments/protocol-numbers/>.";
} }
uses connection-percentile-and-peak; uses connection-percentile-and-peak;
} }
grouping connection-port { grouping connection-port {
description description
"Total attack connections per port number."; "Total attack connections per port number.";
leaf protocol { leaf protocol {
type uint8; type uint8;
description description
"The transport protocol. "The transport protocol.
Values are taken from the IANA Protocol Numbers registry: Values are taken from the IANA 'Protocol Numbers'
registry:
<https://www.iana.org/assignments/protocol-numbers/>."; <https://www.iana.org/assignments/protocol-numbers/>.";
} }
leaf port { leaf port {
type inet:port-number; type inet:port-number;
description description
"Port number."; "Port number.";
} }
uses connection-percentile-and-peak; uses connection-percentile-and-peak;
} }
grouping connection-protocol-all { grouping connection-protocol-all {
description description
"Total attack connections per protocol, including current "Total attack connections per protocol, including current
values."; values.";
leaf protocol { leaf protocol {
type uint8; type uint8;
description description
"The transport protocol. "The transport protocol.
Values are taken from the IANA Protocol Numbers registry: Values are taken from the IANA 'Protocol Numbers'
registry:
<https://www.iana.org/assignments/protocol-numbers/>."; <https://www.iana.org/assignments/protocol-numbers/>.";
} }
uses connection-all; uses connection-all;
} }
grouping connection-protocol-port-all { grouping connection-protocol-port-all {
description description
"Total attack connections per port number, including current "Total attack connections per port number, including current
values."; values.";
leaf protocol { leaf protocol {
type uint8; type uint8;
description description
"The transport protocol. "The transport protocol.
Values are taken from the IANA Protocol Numbers registry: Values are taken from the IANA 'Protocol Numbers'
registry:
<https://www.iana.org/assignments/protocol-numbers/>."; <https://www.iana.org/assignments/protocol-numbers/>.";
} }
leaf port { leaf port {
type inet:port-number; type inet:port-number;
description description
"Port number."; "Port number.";
} }
uses connection-all; uses connection-all;
} }
grouping attack-detail { grouping attack-detail {
description description
"Various details that describe the ongoing "Various details that describe the ongoing
attacks that need to be mitigated by the DOTS server. attacks that need to be mitigated by the DOTS server.
The attack details need to cover well-known and common attacks The attack details need to cover well-known and common
(such as a SYN Flood) along with new emerging or attacks (such as a SYN flood) along with new emerging or
vendor-specific attacks."; vendor-specific attacks.";
leaf vendor-id { leaf vendor-id {
type uint32; type uint32;
description description
"Vendor ID is a security vendor's Private Enterprise Number "The Vendor ID is a security vendor's Private Enterprise
as registered with IANA."; Number as registered with IANA.";
reference reference
"IANA: Private Enterprise Numbers"; "IANA: Private Enterprise Numbers
(https://www.iana.org/assignments/enterprise-numbers/)";
} }
leaf attack-id { leaf attack-id {
type uint32; type uint32;
description description
"Unique identifier assigned by the vendor for the attack."; "Unique identifier assigned by the vendor for the attack.";
} }
leaf description-lang { leaf description-lang {
type string { type string {
pattern '(([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})' pattern '((([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})'
+ '{0,2})?|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})?' + '{0,2})?)|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})'
+ '(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}' + '?(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}'
+ '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WY-Za-wy-z]' + '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WYZa-wyz]'
+ '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]' + '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]'
+ '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|' + '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|'
+ '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-' + '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-'
+ '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-' + '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-'
+ '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-' + '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-'
+ '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]' + '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]'
+ '|[Ii]-[Hh][Aa][Kk]|' + '|[Ii]-[Hh][Aa][Kk]|'
+ '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|' + '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|'
+ '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|' + '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|'
+ '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|' + '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|'
skipping to change at line 4240 skipping to change at line 3933
default "en-US"; default "en-US";
description description
"Indicates the language tag that is used for "Indicates the language tag that is used for
'attack-description'."; 'attack-description'.";
reference reference
"RFC 5646: Tags for Identifying Languages, Section 2.1"; "RFC 5646: Tags for Identifying Languages, Section 2.1";
} }
leaf attack-description { leaf attack-description {
type string; type string;
description description
"Textual representation of attack description. Natural "Textual representation of the attack description.
Language Processing techniques (e.g., word embedding) Natural Language Processing techniques (e.g.,
might provide some utility in mapping the attack word embedding) might provide some utility in mapping
description to an attack type."; the attack description to an attack type.";
} }
leaf attack-severity { leaf attack-severity {
type attack-severity; type attack-severity;
description description
"Severity level of an attack. How this level is determined "Severity level of an attack. How this level is
is implementation-specific."; determined is implementation specific.";
} }
leaf start-time { leaf start-time {
type uint64; type uint64;
description description
"The time the attack started. Start time is represented in "The time the attack started. The start time is
seconds relative to 1970-01-01T00:00:00Z."; represented in seconds relative to
1970-01-01T00:00:00Z.";
} }
leaf end-time { leaf end-time {
type uint64; type uint64;
description description
"The time the attack ended. End time is represented in "The time the attack ended. The end time is represented
seconds relative to 1970-01-01T00:00:00Z."; in seconds relative to 1970-01-01T00:00:00Z.";
} }
container source-count { container source-count {
description description
"Indicates the count of unique sources involved "Indicates the count of unique sources involved
in the attack."; in the attack.";
uses percentile-and-peak; uses percentile-and-peak;
leaf current-g { leaf current-g {
type yang:gauge64; type yang:gauge64;
description description
"Current observed value."; "Current observed value.";
} }
} }
} }
grouping talker { grouping talker {
description description
"Defines generic data related to top-talkers."; "Defines generic data related to top talkers.";
leaf spoofed-status { leaf spoofed-status {
type boolean; type boolean;
description description
"When set to 'true', it indicates whether this address "When set to 'true', it indicates whether this address
is spoofed."; is spoofed.";
} }
leaf source-prefix { leaf source-prefix {
type inet:ip-prefix; type inet:ip-prefix;
description description
"IPv4 or IPv6 prefix identifying the attacker(s)."; "IPv4 or IPv6 prefix identifying the attacker(s).";
} }
list source-port-range { list source-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;
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 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.";
} }
} }
list source-icmp-type-range { list source-icmp-type-range {
key "lower-type"; key "lower-type";
description description
"ICMP type range. When only lower-type is "ICMP type range. When only 'lower-type' is
present, it represents a single ICMP type."; present, it represents a single ICMP type.";
leaf lower-type { leaf lower-type {
type uint8; type uint8;
description description
"Lower ICMP type of the ICMP type range."; "Lower ICMP type of the ICMP type range.";
} }
leaf upper-type { leaf upper-type {
type uint8; type uint8;
must '. >= ../lower-type' { must '. >= ../lower-type' {
error-message error-message
"The upper ICMP type must be greater than "The upper ICMP type must be greater than
or equal to lower ICMP type."; or equal to the lower ICMP type.";
} }
description description
"Upper type of the ICMP type range."; "Upper type of the ICMP type range.";
} }
} }
list total-attack-traffic { list total-attack-traffic {
key "unit"; key "unit";
description description
"Total attack traffic issued from this source."; "Total attack traffic issued from this source.";
uses traffic-unit-all; uses traffic-unit-all;
} }
} }
grouping top-talker-aggregate { grouping top-talker-aggregate {
description description
"An aggregate of top attack sources. This aggregate is "An aggregate of top attack sources. This aggregate is
typically used when included in a mitigation request."; typically used when included in a mitigation request.";
list talker { list talker {
key "source-prefix"; key "source-prefix";
description description
"Refers to a top-talker that is identified by an IPv4 "Refers to a top talker that is identified by an IPv4
or IPv6 prefix identifying the attacker(s)."; or IPv6 prefix identifying the attacker(s).";
uses talker; uses talker;
container total-attack-connection { container total-attack-connection {
description description
"Total attack connections issued from this source."; "Total attack connections issued from this source.";
uses connection-all; uses connection-all;
} }
} }
} }
grouping top-talker { grouping top-talker {
description description
"Top attack sources with detailed per-protocol "Top attack sources with detailed per-protocol
structure."; structure.";
list talker { list talker {
key "source-prefix"; key "source-prefix";
description description
"Refers to a top-talker that is identified by an IPv4 "Refers to a top talker that is identified by an IPv4
or IPv6 prefix identifying the attacker(s)."; or IPv6 prefix identifying the attacker(s).";
uses talker; uses talker;
list total-attack-connection-protocol { list total-attack-connection-protocol {
key "protocol"; key "protocol";
description description
"Total attack connections issued from this source."; "Total attack connections issued from this source.";
uses connection-protocol-all; uses connection-protocol-all;
} }
} }
} }
grouping baseline { grouping baseline {
description description
"Grouping for the telemetry baseline."; "Grouping for the telemetry baseline.";
uses data-channel:target; uses data-channel:target;
leaf-list alias-name { leaf-list alias-name {
type string; type string;
description description
"An alias name that points to an IP resource. "An alias name that points to an IP resource.
An IP resource can be a router, a host, An IP resource can be a router, a host,
an IoT object, a server, etc."; an Internet of Things (IoT) object, a server, etc.";
} }
list total-traffic-normal { list total-traffic-normal {
key "unit"; key "unit";
description description
"Total traffic normal baselines."; "Total traffic normal baselines.";
uses traffic-unit; uses traffic-unit;
} }
list total-traffic-normal-per-protocol { list total-traffic-normal-per-protocol {
key "unit protocol"; key "unit protocol";
description description
skipping to change at line 4525 skipping to change at line 4219
} }
list total-attack-traffic { list total-attack-traffic {
key "unit"; key "unit";
description description
"Total attack traffic."; "Total attack traffic.";
uses traffic-unit-all; uses traffic-unit-all;
} }
list attack-detail { list attack-detail {
key "vendor-id attack-id"; key "vendor-id attack-id";
description description
"Attack details"; "Attack details.";
uses attack-detail; uses attack-detail;
container top-talker { container top-talker {
description description
"Top attack sources."; "Top attack sources.";
uses top-talker-aggregate; uses top-talker-aggregate;
} }
} }
} }
sx:structure dots-telemetry { sx:structure dots-telemetry {
description description
"Main structure for DOTS telemetry messages."; "Main structure for DOTS telemetry messages.";
choice telemetry-message-type { choice telemetry-message-type {
description description
"Can be a telemetry-setup or telemetry data."; "Can be 'telemetry-setup' or telemetry data.";
case telemetry-setup { case telemetry-setup {
description description
"Indicates the message is about telemetry steup."; "Indicates that the message is about telemetry setup.";
choice direction { choice direction {
description description
"Indicates the communication direction in which the "Indicates the communication direction in which the
data nodes can be included."; data nodes can be included.";
case server-to-client-only { case server-to-client-only {
description description
"These data nodes appear only in a telemetry message "These data nodes appear only in a telemetry message
sent from the server to the client."; sent from the server to the client.";
container max-config-values { container max-config-values {
description description
"Maximum acceptable configuration values."; "Maximum acceptable configuration values.";
uses telemetry-parameters; uses telemetry-parameters;
leaf server-originated-telemetry { leaf server-originated-telemetry {
type boolean; type boolean;
default "false"; default "false";
description description
"Indicates whether the DOTS server can be "Indicates whether the DOTS server can be
instructed to send pre-or-ongoing-mitigation instructed to send pre-or-ongoing-mitigation
telemetry. If set to 'false' or the data node telemetry. If set to 'false' or the data node
is not present, this is an indication that is not present, this is an indication that
the server does not support this capability."; the server does not support this capability.";
} }
leaf telemetry-notify-interval { leaf telemetry-notify-interval {
type uint16 { type uint16 {
range "1 .. 3600"; range "1 .. 3600";
} }
units "seconds"; units "seconds";
must '. >= ../../min-config-values' must '. >= ../../min-config-values'
+ '/telemetry-notify-interval' { + '/telemetry-notify-interval' {
error-message error-message
"The value must be greater than or equal "The value must be greater than or equal
to the telemetry-notify-interval in the to the 'telemetry-notify-interval' value in
min-config-values"; the 'min-config-values' attribute";
} }
description description
"Minimum number of seconds between successive "Minimum number of seconds between successive
telemetry notifications."; telemetry notifications.";
} }
} }
container min-config-values { container min-config-values {
description description
"Minimum acceptable configuration values."; "Minimum acceptable configuration values.";
uses telemetry-parameters; uses telemetry-parameters;
skipping to change at line 4606 skipping to change at line 4300
container supported-unit-classes { container supported-unit-classes {
description description
"Supported unit classes and default activation "Supported unit classes and default activation
status."; status.";
uses unit-config; uses unit-config;
} }
leaf-list supported-query-type { leaf-list supported-query-type {
type query-type; type query-type;
description description
"Indicates which query types are supported by "Indicates which query types are supported by
the server. If the server does not announce the server. If the server does not announce
the query types it supports, the client will the query types it supports, the client will
be unable to use any of the potential be unable to use any of the potential
query-type values to reduce the returned data 'query-type' values to reduce the returned data
content from the server."; content from the server.";
} }
} }
} }
list telemetry { list telemetry {
description description
"The telemetry data per DOTS client. The keys "The telemetry data per DOTS client. The keys
of the list are 'cuid' and 'tsid', but these keys are of the list are 'cuid' and 'tsid', but these keys are
not represented here because these keys are conveyed not represented here because these keys are conveyed
as mandatory Uri-Paths in requests. Omitting keys as mandatory Uri-Paths in requests. Omitting keys
is compliant with RFC8791."; is compliant with RFC 8791.";
reference
"RFC 8791: YANG Data Structure Extensions";
choice direction { choice direction {
description description
"Indicates the communication direction in which the "Indicates the communication direction in which the
data nodes can be included."; data nodes can be included.";
case server-to-client-only { case server-to-client-only {
description description
"These data nodes appear only in a telemetry message "These data nodes appear only in a telemetry
sent from the server to the client."; message sent from the server to the client.";
leaf tsid { leaf tsid {
type uint32; type uint32;
description description
"A client-assigned identifier for the DOTS "A client-assigned identifier for the DOTS
telemetry setup data."; telemetry setup data.";
} }
} }
} }
choice setup-type { choice setup-type {
description description
"Can be a mitigation configuration, a pipe capacity, "Can be a mitigation configuration, a pipe capacity,
or baseline message."; or a baseline message.";
case telemetry-config { case telemetry-config {
description description
"Used to set telemetry parameters such as setting "Used to set telemetry parameters such as setting
low, mid, and high percentile values."; low-, mid-, and high-percentile values.";
container current-config { container current-config {
description description
"Current telemetry configuration values."; "Current telemetry configuration values.";
uses telemetry-parameters; uses telemetry-parameters;
uses unit-config; uses unit-config;
leaf server-originated-telemetry { leaf server-originated-telemetry {
type boolean; type boolean;
description description
"Used by a DOTS client to enable/disable whether "Used by a DOTS client to enable/disable
it requests pre-or-ongoing-mitigation telemetry whether it requests pre-or-ongoing-mitigation
from the DOTS server."; telemetry from the DOTS server.";
} }
leaf telemetry-notify-interval { leaf telemetry-notify-interval {
type uint16 { type uint16 {
range "1 .. 3600"; range "1 .. 3600";
} }
units "seconds"; units "seconds";
description description
"Minimum number of seconds between successive "Minimum number of seconds between successive
telemetry notifications."; telemetry notifications.";
} }
skipping to change at line 4685 skipping to change at line 4381
leaf link-id { leaf link-id {
type nt:link-id; type nt:link-id;
description description
"Identifier of an interconnection link of "Identifier of an interconnection link of
the DOTS client domain."; the DOTS client domain.";
} }
leaf capacity { leaf capacity {
type uint64; type uint64;
mandatory true; mandatory true;
description description
"Pipe capacity. This attribute is mandatory when "Pipe capacity. This attribute is mandatory
total-pipe-capacity is included in a message."; when 'total-pipe-capacity' is included in a
message.";
} }
leaf unit { leaf unit {
type unit; type unit;
description description
"The traffic can be measured using unit classes: "The traffic can be measured using unit
packets per second (pps), bits per second classes: packets per second (pps), bits per
(bit/s), and/or bytes per second (Byte/s). second (bps), and/or bytes per second
(Bps).
For a given unit class, the DOTS agents For a given unit class, the DOTS agents
auto-scales to the appropriate units (e.g., auto-scale to the appropriate units (e.g.,
megabit-ps, kilobit-ps)."; 'megabit-ps', 'kilobit-ps').";
} }
} }
} }
case baseline { case baseline {
description description
"Traffic baseline information of a DOTS client "Traffic baseline information related to a DOTS
domain."; client domain.";
list baseline { list baseline {
key "id"; key "id";
description description
"Traffic baseline information of a DOTS client "Traffic baseline information related to a DOTS
domain."; client domain.";
leaf id { leaf id {
type uint32; type uint32;
must '. >= 1'; must '. >= 1';
description description
"An identifier that uniquely identifies a "An identifier that uniquely identifies a
baseline entry communicated by a DOTS client."; baseline entry communicated by a
DOTS client.";
} }
uses baseline; uses baseline;
} }
} }
} }
} }
} }
case telemetry { case telemetry {
description description
"Telemetry information."; "Telemetry information.";
list pre-or-ongoing-mitigation { list pre-or-ongoing-mitigation {
description description
"Pre-or-ongoing-mitigation telemetry per DOTS client. "Pre-or-ongoing-mitigation telemetry per DOTS client.
The keys of the list are 'cuid' and 'tmid', but these The keys of the list are 'cuid' and 'tmid', but these
keys are not represented here because these keys are keys are not represented here because these keys are
conveyed as mandatory Uri-Paths in requests. conveyed as mandatory Uri-Paths in requests.
Omitting keys is compliant with RFC8791."; Omitting keys is compliant with RFC 8791.";
reference
"RFC 8791: YANG Data Structure Extensions";
choice direction { choice direction {
description description
"Indicates the communication direction in which the "Indicates the communication direction in which the
data nodes can be included."; data nodes can be included.";
case server-to-client-only { case server-to-client-only {
description description
"These data nodes appear only in a telemetry message "These data nodes appear only in a telemetry
sent from the server to the client."; message sent from the server to the client.";
leaf tmid { leaf tmid {
type uint32; type uint32;
description description
"A client-assigned identifier for the DOTS "A client-assigned identifier for the DOTS
telemetry data."; telemetry data.";
} }
} }
} }
container target { container target {
description description
"Indicates the target. At least one of the attributes "Indicates the target. At least one of the
'target-prefix', 'target-fqdn', 'target-uri', attributes 'target-prefix', 'target-fqdn',
'alias-name', or 'mid-list' must be present in the 'target-uri', 'alias-name', or 'mid-list'
target definition."; must be present in the target definition.";
uses data-channel:target; uses data-channel:target;
leaf-list alias-name { leaf-list alias-name {
type string; type string;
description description
"An alias name that points to a resource."; "An alias name that points to a resource.";
} }
leaf-list mid-list { leaf-list mid-list {
type uint32; type uint32;
description description
"Reference a list of associated mitigation "Reference to a list of associated mitigation
requests."; requests.";
reference reference
"RFC 9132: Distributed Denial-of-Service Open Threat "RFC 9132: Distributed Denial-of-Service Open
Signaling (DOTS) Signal Channel Threat Signaling (DOTS) Signal Channel
Specification, Section 4.4.1"; Specification, Section 4.4.1";
} }
} }
uses pre-or-ongoing-mitigation; uses pre-or-ongoing-mitigation;
} }
} }
} }
} }
} }
<CODE ENDS> ]]></sourcecode>
]]></artwork>
</figure></t>
</section> </section>
<section anchor="data" numbered="true" toc="default">
<section anchor="data" title="Vendor Attack Mapping Details YANG Module"> <name>Vendor Attack Mapping Details YANG Module</name>
<t><figure> <sourcecode name="ietf-dots-mapping@2022-05-18.yang" type="yang" markers
<artwork><![CDATA[<CODE BEGINS> file "ietf-dots-mapping@2022-02-04.y ="true"><![CDATA[
ang"
module ietf-dots-mapping { module ietf-dots-mapping {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-mapping"; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-mapping";
prefix dots-mapping; prefix dots-mapping;
import ietf-dots-data-channel { import ietf-dots-data-channel {
prefix data-channel; prefix data-channel;
reference reference
"RFC 8783: Distributed Denial-of-Service Open Threat "RFC 8783: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Data Channel Specification"; Signaling (DOTS) Data Channel Specification";
} }
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>
Author: Mohamed Boucadair Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Author: Jon Shallow Author: Jon Shallow
<mailto:supjps-ietf@jpshallow.com>"; <mailto:supjps-ietf@jpshallow.com>";
description description
"This module contains YANG definitions for the sharing "This module contains YANG definitions for the sharing
DDoS attack mapping details between a DOTS client and of DDoS attack mapping details between a DOTS client and
a DOTS server, by means of the DOTS data channel. a DOTS server by means of the DOTS data channel.
Copyright (c) 2022 IETF Trust and the persons identified as Copyright (c) 2022 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 to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://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 9244; see the
the RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2022-02-04 { revision 2022-05-18 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Distributed Denial-of-Service Open Threat "RFC 9244: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry"; Signaling (DOTS) Telemetry";
} }
feature dots-telemetry { feature dots-telemetry {
description description
"This feature indicates that DOTS telemetry data can be "This feature indicates that DOTS telemetry data can be
shared between DOTS clients and servers."; shared between DOTS clients and servers.";
} }
grouping attack-mapping { grouping attack-mapping {
description description
"A set of information used for sharing vendor attack mapping "A set of information used for sharing vendor attack mapping
information with a peer."; information with a peer.";
list vendor { list vendor {
key "vendor-id"; key "vendor-id";
description description
"Vendor attack mapping information of the client/server"; "Vendor attack mapping information related to the
client/server.";
leaf vendor-id { leaf vendor-id {
type uint32; type uint32;
description description
"Vendor ID is a security vendor's Private Enterprise Number "The Vendor ID is a security vendor's Private Enterprise
as registered with IANA."; Number as registered with IANA.";
reference reference
"IANA: Private Enterprise Numbers"; "IANA: Private Enterprise Numbers
(https://www.iana.org/assignments/enterprise-numbers/)";
} }
leaf vendor-name { leaf vendor-name {
type string; type string;
description description
"The name of the vendor (e.g., company A)."; "The name of the vendor (e.g., company A).";
} }
leaf description-lang { leaf description-lang {
type string { type string {
pattern '(([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})' pattern '((([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})'
+ '{0,2})?|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})?' + '{0,2})?)|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})'
+ '(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}' + '?(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}'
+ '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WY-Za-wy-z]' + '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WYZa-wyz]'
+ '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]' + '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]'
+ '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|' + '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|'
+ '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-' + '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-'
+ '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-' + '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-'
+ '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-' + '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-'
+ '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]' + '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]'
+ '|[Ii]-[Hh][Aa][Kk]|' + '|[Ii]-[Hh][Aa][Kk]|'
+ '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|' + '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|'
+ '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|' + '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|'
+ '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|' + '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|'
skipping to change at line 4901 skipping to change at line 4601
description description
"Indicates the language tag that is used for "Indicates the language tag that is used for
'attack-description'."; 'attack-description'.";
reference reference
"RFC 5646: Tags for Identifying Languages, Section 2.1"; "RFC 5646: Tags for Identifying Languages, Section 2.1";
} }
leaf last-updated { leaf last-updated {
type uint64; type uint64;
mandatory true; mandatory true;
description description
"The time the mapping table was updated. It is represented "The time the mapping table was updated. It is
in seconds relative to 1970-01-01T00:00:00Z."; represented in seconds relative to
1970-01-01T00:00:00Z.";
} }
list attack-mapping { list attack-mapping {
key "attack-id"; key "attack-id";
description description
"Attack mapping details."; "Attack mapping details.";
leaf attack-id { leaf attack-id {
type uint32; type uint32;
description description
"Unique identifier assigned by the vendor for the "Unique identifier assigned by the vendor for the
attack."; attack.";
} }
leaf attack-description { leaf attack-description {
type string; type string;
mandatory true; mandatory true;
description description
"Textual representation of attack description. Natural "Textual representation of the attack description.
Language Processing techniques (e.g., word embedding) Natural Language Processing techniques (e.g.,
might provide some utility in mapping the attack word embedding) might provide some utility in
description to an attack type."; mapping the attack description to an attack type.";
} }
} }
} }
} }
augment "/data-channel:dots-data/data-channel:dots-client" { augment "/data-channel:dots-data/data-channel:dots-client" {
if-feature "dots-telemetry"; if-feature "dots-telemetry";
description description
"Augments the data channel with a vendor attack "Augments the data channel with a vendor attack
mapping table of the DOTS client."; mapping table of the DOTS client.";
skipping to change at line 4964 skipping to change at line 4665
augment "/data-channel:dots-data" { augment "/data-channel:dots-data" {
if-feature "dots-telemetry"; if-feature "dots-telemetry";
description description
"Augments the data channel with a vendor attack "Augments the data channel with a vendor attack
mapping table of the DOTS server."; mapping table of the DOTS server.";
container vendor-mapping { container vendor-mapping {
config false; config false;
description description
"Includes the list of vendor attack mapping details "Includes the list of vendor attack mapping details
that will be shared upon request with DOTS clients."; that will be shared with DOTS clients upon request.";
uses attack-mapping; uses attack-mapping;
} }
} }
} }
<CODE ENDS> ]]></sourcecode>
]]></artwork>
</figure></t>
</section> </section>
</section> </section>
<section anchor="map1" numbered="true" toc="default">
<section anchor="map1" title="YANG/JSON Mapping Parameters to CBOR"> <name>YANG/JSON Mapping Parameters to CBOR</name>
<t>All DOTS telemetry parameters in the payload of the DOTS signal <t>All DOTS telemetry parameters in the payload of the DOTS signal
channel MUST be mapped to CBOR types as shown in Table 3:</t> channel <bcp14>MUST</bcp14> be mapped to CBOR types as shown in <xref targ
et="tab-3"/>:</t>
<t><list style="symbols"> <aside><t>
<t>Note: Implementers must check that the mapping output provided by Note: Implementers must check that the mapping output provided by
their YANG-to-CBOR encoding schemes is aligned with the content of their YANG-to-CBOR encoding schemes is aligned with the contents of
Table 2.</t> <xref target="tab-3"/>.
</list></t> </t></aside>
<table anchor="tab-3">
<t><figure align="center"> <name>YANG/JSON Mapping Parameters to CBOR</name>
<artwork align="center"><![CDATA[+----------------------+------------- <thead>
+------+---------------+--------+ <tr>
| Parameter Name | YANG | CBOR | CBOR Major | JSON | <th>Parameter Name</th>
| | Type | Key | Type & | Type | <th>YANG Type</th>
| | | | Information | | <th>CBOR Key</th>
+======================+=============+======+===============+========+ <th>CBOR Major Type &amp; Information</th>
| tsid | uint32 |TBA1 | 0 unsigned | Number | <th>JSON Type</th>
| telemetry | list |TBA2 | 4 array | Array | </tr>
| low-percentile | decimal64 |TBA3 | 6 tag 4 | | </thead>
| | | | [-2, integer]| String | <tbody>
| mid-percentile | decimal64 |TBA4 | 6 tag 4 | | <tr>
| | | | [-2, integer]| String | <td>tsid</td>
| high-percentile | decimal64 |TBA5 | 6 tag 4 | | <td>uint32</td>
| | | | [-2, integer]| String | <td>128</td>
| unit-config | list |TBA6 | 4 array | Array | <td>0 unsigned</td>
| unit | enumeration |TBA7 | 0 unsigned | String | <td>Number</td>
| unit-status | boolean |TBA8 | 7 bits 20 | False | </tr>
| | | | 7 bits 21 | True | <tr>
| total-pipe-capacity | list |TBA9 | 4 array | Array | <td>telemetry</td>
| link-id | string |TBA10 | 3 text string | String | <td>list</td>
| pre-or-ongoing- | list |TBA11 | 4 array | Array | <td>129</td>
| mitigation | | | | | <td>4 array</td>
| total-traffic-normal | list |TBA12 | 4 array | Array | <td>Array</td>
| low-percentile-g | yang:gauge64|TBA13 | 0 unsigned | String | </tr>
| mid-percentile-g | yang:gauge64|TBA14 | 0 unsigned | String | <tr>
| high-percentile-g | yang:gauge64|TBA15 | 0 unsigned | String | <td>low-percentile</td>
| peak-g | yang:gauge64|TBA16 | 0 unsigned | String | <td>decimal64</td>
| total-attack-traffic | list |TBA17 | 4 array | Array | <td>130</td>
| total-traffic | list |TBA18 | 4 array | Array | <td>6 tag 4 [-2, integer]</td>
| total-connection- | | | | | <td>String</td>
| capacity | list |TBA19 | 4 array | Array | </tr>
| connection | uint64 |TBA20 | 0 unsigned | String | <tr>
| connection-client | uint64 |TBA21 | 0 unsigned | String | <td>mid-percentile</td>
| embryonic | uint64 |TBA22 | 0 unsigned | String | <td>decimal64</td>
| embryonic-client | uint64 |TBA23 | 0 unsigned | String | <td>131</td>
| connection-ps | uint64 |TBA24 | 0 unsigned | String | <td>6 tag 4 [-2, integer]</td>
| connection-client-ps | uint64 |TBA25 | 0 unsigned | String | <td>String</td>
| request-ps | uint64 |TBA26 | 0 unsigned | String | </tr>
| request-client-ps | uint64 |TBA27 | 0 unsigned | String | <tr>
| partial-request-max | uint64 |TBA28 | 0 unsigned | String | <td>high-percentile</td>
| partial-request- | | | | | <td>decimal64</td>
| client-max | uint64 |TBA29 | 0 unsigned | String | <td>132</td>
| total-attack- | | | | | <td>6 tag 4 [-2, integer]</td>
| connection | container |TBA30 | 5 map | Object | <td>String</td>
| connection-c | container |TBA31 | 5 map | Object | </tr>
| embryonic-c | container |TBA32 | 5 map | Object | <tr>
| connection-ps-c | container |TBA33 | 5 map | Object | <td>unit-config</td>
| request-ps-c | container |TBA34 | 5 map | Object | <td>list</td>
| attack-detail | list |TBA35 | 4 array | Array | <td>133</td>
| id | uint32 |TBA36 | 0 unsigned | Number | <td>4 array</td>
| attack-id | uint32 |TBA37 | 0 unsigned | Number | <td>Array</td>
| attack-description | string |TBA38 | 3 text string | String | </tr>
| attack-severity | enumeration |TBA39 | 0 unsigned | String | <tr>
| start-time | uint64 |TBA40 | 0 unsigned | String | <td>unit</td>
| end-time | uint64 |TBA41 | 0 unsigned | String | <td>enumeration</td>
| source-count | container |TBA42 | 5 map | Object | <td>134</td>
| top-talker | container |TBA43 | 5 map | Object | <td>0 unsigned</td>
| spoofed-status | boolean |TBA44 | 7 bits 20 | False | <td>String</td>
| | | | 7 bits 21 | True | </tr>
| partial-request-c | container |TBA45 | 5 map | Object | <tr>
| total-attack- | | | | | <td rowspan="2">unit-status</td>
| connection-protocol | list |TBA46 | 4 array | Array | <td rowspan="2">boolean</td>
| baseline | list |TBA49 | 4 array | Array | <td rowspan="2">135</td>
| current-config | container |TBA50 | 5 map | Object | <td>7 bits 20</td>
| max-config-values | container |TBA51 | 5 map | Object | <td>False</td>
| min-config-values | container |TBA52 | 5 map | Object | </tr>
|supported-unit-classes| container |TBA53 | 5 map | Object | <tr>
| server-originated- | boolean |TBA54 | 7 bits 20 | False | <td>7 bits 21</td>
| telemetry | | | 7 bits 21 | True | <td>True</td>
| telemetry-notify- | uint16 |TBA55 | 0 unsigned | Number | </tr>
| interval | | | | | <tr>
| tmid | uint32 |TBA56 | 0 unsigned | Number | <td>total-pipe-capacity</td>
| measurement-interval | enumeration |TBA57 | 0 unsigned | String | <td>list</td>
| measurement-sample | enumeration |TBA58 | 0 unsigned | String | <td>136</td>
| talker | list |TBA59 | 4 array | Array | <td>4 array</td>
| source-prefix | inet: |TBA60 | 3 text string | String | <td>Array</td>
| | ip-prefix | | | | </tr>
| mid-list | leaf-list |TBA61 | 4 array | Array | <tr>
| | uint32 | | 0 unsigned | Number | <td>link-id</td>
| source-port-range | list |TBA62 | 4 array | Array | <td>string</td>
| source-icmp-type- | list |TBA63 | 4 array | Array | <td>137</td>
| range | | | | | <td>3 text string</td>
| target | container |TBA64 | 5 map | Object | <td>String</td>
| capacity | uint64 |TBA65 | 0 unsigned | String | </tr>
| protocol | uint8 |TBA66 | 0 unsigned | Number | <tr>
| total-traffic- | | | | | <td>pre-or-ongoing-mitigation</td>
| normal-per-protocol | list |TBA67 | 4 array | Array | <td>list</td>
| total-traffic- | | | | | <td>138</td>
| normal-per-port | list |TBA68 | 4 array | Array | <td>4 array</td>
| total-connection- | | | | | <td>Array</td>
| capacity-per-port | list |TBA69 | 4 array | Array | </tr>
| total-traffic- | | | | | <tr>
| protocol | list |TBA70 | 4 array | Array | <td>total-traffic-normal</td>
| total-traffic-port | list |TBA71 | 4 array | Array | <td>list</td>
| total-attack- | | | | | <td>139</td>
| traffic-protocol | list |TBA72 | 4 array | Array | <td>4 array</td>
| total-attack- | | | | | <td>Array</td>
| traffic-port | list |TBA73 | 4 array | Array | </tr>
| total-attack- | | | | | <tr>
| connection-port | list |TBA74 | 4 array | Array | <td>low-percentile-g</td>
| port | inet: | | | | <td>yang:gauge64</td>
| | port-number|TBA75 | 0 unsigned | Number | <td>140</td>
| supported-query-type | leaf-list |TBA76 | 4 array | Array | <td>0 unsigned</td>
| | | | 0 unsigned | String | <td>String</td>
| vendor-id | uint32 |TBA77 | 0 unsigned | Number | </tr>
| ietf-dots-telemetry: | | | | | <tr>
| telemetry-setup | container |TBA78 | 5 map | Object | <td>mid-percentile-g</td>
| ietf-dots-telemetry: | | | | | <td>yang:gauge64</td>
| total-traffic | list |TBA79 | 4 array | Array | <td>141</td>
| ietf-dots-telemetry: | | | | | <td>0 unsigned</td>
| total-attack-traffic | list |TBA80 | 4 array | Array | <td>String</td>
| ietf-dots-telemetry: | | | | | </tr>
| total-attack- | | | | | <tr>
| connection | container |TBA81 | 5 map | Object | <td>high-percentile-g</td>
| ietf-dots-telemetry: | | | | | <td>yang:gauge64</td>
| attack-detail | list |TBA82 | 4 array | Array | <td>142</td>
| ietf-dots-telemetry: | | | | | <td>0 unsigned</td>
| telemetry | container |TBA83 | 5 map | Object | <td>String</td>
| current-g | yang:gauge64|TBA84 | 0 unsigned | String | </tr>
| description-lang | string |TBA85 | 3 text string | String | <tr>
| lower-type | uint8 |32771 | 0 unsigned | Number | <td>peak-g</td>
| upper-type | uint8 |32772 | 0 unsigned | Number | <td>yang:gauge64</td>
+----------------------+-------------+------+---------------+--------+ <td>143</td>
<td>0 unsigned</td>
Table 3: YANG/JSON Mapping Parameters to CBOR <td>String</td>
]]></artwork> </tr>
</figure></t> <tr>
<td>total-attack-traffic</td>
<td>list</td>
<td>144</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>total-traffic</td>
<td>list</td>
<td>145</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>total-connection-capacity</td>
<td>list</td>
<td>146</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>connection</td>
<td>uint64</td>
<td>147</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>connection-client</td>
<td>uint64</td>
<td>148</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>embryonic</td>
<td>uint64</td>
<td>149</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>embryonic-client</td>
<td>uint64</td>
<td>150</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>connection-ps</td>
<td>uint64</td>
<td>151</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>connection-client-ps</td>
<td>uint64</td>
<td>152</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>request-ps</td>
<td>uint64</td>
<td>153</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>request-client-ps</td>
<td>uint64</td>
<td>154</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>partial-request-max</td>
<td>uint64</td>
<td>155</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>partial-request-client-max</td>
<td>uint64</td>
<td>156</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>total-attack-connection</td>
<td>container</td>
<td>157</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>connection-c</td>
<td>container</td>
<td>158</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>embryonic-c</td>
<td>container</td>
<td>159</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>connection-ps-c</td>
<td>container</td>
<td>160</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>request-ps-c</td>
<td>container</td>
<td>161</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>attack-detail</td>
<td>list</td>
<td>162</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>id</td>
<td>uint32</td>
<td>163</td>
<td>0 unsigned</td>
<td>Number</td>
</tr>
<tr>
<td>attack-id</td>
<td>uint32</td>
<td>164</td>
<td>0 unsigned</td>
<td>Number</td>
</tr>
<tr>
<td>attack-description</td>
<td>string</td>
<td>165</td>
<td>3 text string</td>
<td>String</td>
</tr>
<tr>
<td>attack-severity</td>
<td>enumeration</td>
<td>166</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>start-time</td>
<td>uint64</td>
<td>167</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>end-time</td>
<td>uint64</td>
<td>168</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>source-count</td>
<td>container</td>
<td>169</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>top-talker</td>
<td>container</td>
<td>170</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td rowspan="2">spoofed-status</td>
<td rowspan="2">boolean</td>
<td rowspan="2">171</td>
<td>7 bits 20</td>
<td>False</td>
</tr>
<tr>
<td>7 bits 21</td>
<td>True</td>
</tr>
<tr>
<td>partial-request-c</td>
<td>container</td>
<td>172</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>total-attack-connection-protocol</td>
<td>list</td>
<td>173</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>baseline</td>
<td>list</td>
<td>174</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>current-config</td>
<td>container</td>
<td>175</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>max-config-values</td>
<td>container</td>
<td>176</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>min-config-values</td>
<td>container</td>
<td>177</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>supported-unit-classes</td>
<td>container</td>
<td>178</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td rowspan="2">server-originated-telemetry</td>
<td rowspan="2">boolean</td>
<td rowspan="2">179</td>
<td>7 bits 20</td>
<td>False</td>
</tr>
<tr>
<td>7 bits 21</td>
<td>True</td>
</tr>
<tr>
<td>telemetry-notify-interval</td>
<td>uint16</td>
<td>180</td>
<td>0 unsigned</td>
<td>Number</td>
</tr>
<tr>
<td>tmid</td>
<td>uint32</td>
<td>181</td>
<td>0 unsigned</td>
<td>Number</td>
</tr>
<tr>
<td>measurement-interval</td>
<td>enumeration</td>
<td>182</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>measurement-sample</td>
<td>enumeration</td>
<td>183</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>talker</td>
<td>list</td>
<td>184</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>source-prefix</td>
<td>inet:ip-prefix</td>
<td>185</td>
<td>3 text string</td>
<td>String</td>
</tr>
<tr>
<td rowspan="2">mid-list</td>
<td>leaf-list</td>
<td>186</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>uint32</td>
<td></td>
<td>0 unsigned</td>
<td>Number</td>
</tr>
<tr>
<td>source-port-range</td>
<td>list</td>
<td>187</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>source-icmp-type-range</td>
<td>list</td>
<td>188</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>target</td>
<td>container</td>
<td>189</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>capacity</td>
<td>uint64</td>
<td>190</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>protocol</td>
<td>uint8</td>
<td>191</td>
<td>0 unsigned</td>
<td>Number</td>
</tr>
<tr>
<td>total-traffic-normal-per-protocol</td>
<td>list</td>
<td>192</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>total-traffic-normal-per-port</td>
<td>list</td>
<td>193</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>total-connection-capacity-per-port</td>
<td>list</td>
<td>194</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>total-traffic-protocol</td>
<td>list</td>
<td>195</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>total-traffic-port</td>
<td>list</td>
<td>196</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>total-attack-traffic-protocol</td>
<td>list</td>
<td>197</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>total-attack-traffic-port</td>
<td>list</td>
<td>198</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>total-attack-connection-port</td>
<td>list</td>
<td>199</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>port</td>
<td>inet:port-number</td>
<td>200</td>
<td>0 unsigned</td>
<td>Number</td>
</tr>
<tr>
<td rowspan="2">supported-query-type</td>
<td>leaf-list</td>
<td>201</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td></td>
<td></td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>vendor-id</td>
<td>uint32</td>
<td>202</td>
<td>0 unsigned</td>
<td>Number</td>
</tr>
<tr>
<td>ietf-dots-telemetry:telemetry-setup</td>
<td>container</td>
<td>203</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>ietf-dots-telemetry:total-traffic</td>
<td>list</td>
<td>204</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>ietf-dots-telemetry:total-attack-traffic</td>
<td>list</td>
<td>205</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>ietf-dots-telemetry:total-attack-connection</td>
<td>container</td>
<td>206</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>ietf-dots-telemetry:attack-detail</td>
<td>list</td>
<td>207</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>ietf-dots-telemetry:telemetry</td>
<td>container</td>
<td>208</td>
<td>5 map</td>
<td>Object</td>
</tr>
<tr>
<td>current-g</td>
<td>yang:gauge64</td>
<td>209</td>
<td>0 unsigned</td>
<td>String</td>
</tr>
<tr>
<td>description-lang</td>
<td>string</td>
<td>210</td>
<td>3 text string</td>
<td>String</td>
</tr>
<tr>
<td>lower-type</td>
<td>uint8</td>
<td>32771</td>
<td>0 unsigned</td>
<td>Number</td>
</tr>
<tr>
<td>upper-type</td>
<td>uint8</td>
<td>32772</td>
<td>0 unsigned</td>
<td>Number</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<section anchor="map" title="DOTS Signal Channel CBOR Key Values"> <section anchor="map" numbered="true" toc="default">
<t>This specification registers the DOTS telemetry attributes in the <name>DOTS Signal Channel CBOR Key Values</name>
IANA "DOTS Signal Channel CBOR Key Values" registry <xref <t>This specification registers the following comprehension-optional par
target="Key-Map"></xref>.</t> ameters in the IANA "DOTS Signal Channel CBOR Key Values" registry <xref target=
"Key-Map" format="default"/>.</t>
<t>The DOTS telemetry attributes defined in this specification are <table anchor="tab-4">
comprehension-optional parameters.</t> <name>Registered DOTS Signal Channel CBOR Key Values</name>
<thead>
<t><list style="symbols"> <tr>
<t>Note to the IANA: CBOR keys are assigned from the "128-255" <th>Parameter Name</th>
range. This specification meets the requirements listed in Section <th>CBOR Key Value</th>
3.1 <xref target="RFC9132"></xref> for assignments in the <th>CBOR Major Type</th>
"128-255" range.</t> <th>Change Controller</th>
<th>Reference</th>
<t>Note to the RFC Editor: Please replace all occurrences of </tr>
"TBA1-TBA84" with the assigned values.</t> </thead>
</list><figure align="center"> <tbody>
<artwork><![CDATA[ +----------------------+-------+-------+------- <tr>
-----+---------------+ <td>tsid</td>
| Parameter Name | CBOR | CBOR | Change | Specification | <td>128</td>
| | Key | Major | Controller | Document(s) | <td>0</td>
| | Value | Type | | | <td>IESG</td>
+======================+=======+=======+============+===============+ <td>RFC 9244</td>
| tsid | TBA1 | 0 | IESG | [RFCXXXX] | </tr>
| telemetry | TBA2 | 4 | IESG | [RFCXXXX] | <tr>
| low-percentile | TBA3 | 6tag4 | IESG | [RFCXXXX] | <td>telemetry</td>
| mid-percentile | TBA4 | 6tag4 | IESG | [RFCXXXX] | <td>129</td>
| high-percentile | TBA5 | 6tag4 | IESG | [RFCXXXX] | <td>4</td>
| unit-config | TBA6 | 4 | IESG | [RFCXXXX] | <td>IESG</td>
| unit | TBA7 | 0 | IESG | [RFCXXXX] | <td>RFC 9244</td>
| unit-status | TBA8 | 7 | IESG | [RFCXXXX] | </tr>
| total-pipe-capacity | TBA9 | 4 | IESG | [RFCXXXX] | <tr>
| link-id | TBA10 | 3 | IESG | [RFCXXXX] | <td>low-percentile</td>
| pre-or-ongoing- | TBA11 | 4 | IESG | [RFCXXXX] | <td>130</td>
| mitigation | | | | | <td>6tag4</td>
| total-traffic-normal | TBA12 | 4 | IESG | [RFCXXXX] | <td>IESG</td>
| low-percentile-g | TBA13 | 0 | IESG | [RFCXXXX] | <td>RFC 9244</td>
| mid-percentile-g | TBA14 | 0 | IESG | [RFCXXXX] | </tr>
| high-percentile-g | TBA15 | 0 | IESG | [RFCXXXX] | <tr>
| peak-g | TBA16 | 0 | IESG | [RFCXXXX] | <td>mid-percentile</td>
| total-attack-traffic | TBA17 | 4 | IESG | [RFCXXXX] | <td>131</td>
| total-traffic | TBA18 | 4 | IESG | [RFCXXXX] | <td>6tag4</td>
| total-connection- | TBA19 | 4 | IESG | [RFCXXXX] | <td>IESG</td>
| capacity | | | | | <td>RFC 9244</td>
| connection | TBA20 | 0 | IESG | [RFCXXXX] | </tr>
| connection-client | TBA21 | 0 | IESG | [RFCXXXX] | <tr>
| embryonic | TBA22 | 0 | IESG | [RFCXXXX] | <td>high-percentile</td>
| embryonic-client | TBA23 | 0 | IESG | [RFCXXXX] | <td>132</td>
| connection-ps | TBA24 | 0 | IESG | [RFCXXXX] | <td>6tag4</td>
| connection-client-ps | TBA25 | 0 | IESG | [RFCXXXX] | <td>IESG</td>
| request-ps | TBA26 | 0 | IESG | [RFCXXXX] | <td>RFC 9244</td>
| request-client-ps | TBA27 | 0 | IESG | [RFCXXXX] | </tr>
| partial-request-max | TBA28 | 0 | IESG | [RFCXXXX] | <tr>
| partial-request- | TBA29 | 0 | IESG | [RFCXXXX] | <td>unit-config</td>
| client-max | | | | | <td>133</td>
| total-attack- | TBA30 | 5 | IESG | [RFCXXXX] | <td>4</td>
| connection | | | | | <td>IESG</td>
| connection-c | TBA31 | 5 | IESG | [RFCXXXX] | <td>RFC 9244</td>
| embryonic-c | TBA32 | 5 | IESG | [RFCXXXX] | </tr>
| connection-ps-c | TBA33 | 5 | IESG | [RFCXXXX] | <tr>
| request-ps-c | TBA34 | 5 | IESG | [RFCXXXX] | <td>unit</td>
| attack-detail | TBA35 | 4 | IESG | [RFCXXXX] | <td>134</td>
| id | TBA36 | 0 | IESG | [RFCXXXX] | <td>0</td>
| attack-id | TBA37 | 0 | IESG | [RFCXXXX] | <td>IESG</td>
| attack-description | TBA38 | 3 | IESG | [RFCXXXX] | <td>RFC 9244</td>
| attack-severity | TBA39 | 0 | IESG | [RFCXXXX] | </tr>
| start-time | TBA40 | 0 | IESG | [RFCXXXX] | <tr>
| end-time | TBA41 | 0 | IESG | [RFCXXXX] | <td>unit-status</td>
| source-count | TBA42 | 5 | IESG | [RFCXXXX] | <td>135</td>
| top-talker | TBA43 | 5 | IESG | [RFCXXXX] | <td>7</td>
| spoofed-status | TBA44 | 7 | IESG | [RFCXXXX] | <td>IESG</td>
| partial-request-c | TBA45 | 5 | IESG | [RFCXXXX] | <td>RFC 9244</td>
| total-attack- | TBA46 | 4 | IESG | [RFCXXXX] | </tr>
| connection-protocol | | | | | <tr>
| baseline | TBA49 | 4 | IESG | [RFCXXXX] | <td>total-pipe-capacity</td>
| current-config | TBA50 | 5 | IESG | [RFCXXXX] | <td>136</td>
| max-config-value | TBA51 | 5 | IESG | [RFCXXXX] | <td>4</td>
| min-config-values | TBA52 | 5 | IESG | [RFCXXXX] | <td>IESG</td>
|supported-unit-classes| TBA53 | 5 | IESG | [RFCXXXX] | <td>RFC 9244</td>
| server-originated- | TBA54 | 7 | IESG | [RFCXXXX] | </tr>
| telemetry | | | | | <tr>
| telemetry-notify- | TBA55 | 0 | IESG | [RFCXXXX] | <td>link-id</td>
| interval | | | | | <td>137</td>
| tmid | TBA56 | 0 | IESG | [RFCXXXX] | <td>3</td>
| measurement-interval | TBA57 | 0 | IESG | [RFCXXXX] | <td>IESG</td>
| measurement-sample | TBA58 | 0 | IESG | [RFCXXXX] | <td>RFC 9244</td>
| talker | TBA59 | 4 | IESG | [RFCXXXX] | </tr>
| source-prefix | TBA60 | 3 | IESG | [RFCXXXX] | <tr>
| mid-list | TBA61 | 4 | IESG | [RFCXXXX] | <td>pre-or-ongoing-mitigation</td>
| source-port-range | TBA62 | 4 | IESG | [RFCXXXX] | <td>138</td>
| source-icmp-type- | TBA63 | 4 | IESG | [RFCXXXX] | <td>4</td>
| range | | | | | <td>IESG</td>
| target | TBA64 | 5 | IESG | [RFCXXXX] | <td>RFC 9244</td>
| capacity | TBA65 | 0 | IESG | [RFCXXXX] | </tr>
| protocol | TBA66 | 0 | IESG | [RFCXXXX] | <tr>
| total-traffic- | TBA67 | 4 | IESG | [RFCXXXX] | <td>total-traffic-normal</td>
| normal-per-protocol | | | | | <td>139</td>
| total-traffic- | TBA68 | 4 | IESG | [RFCXXXX] | <td>4</td>
| normal-per-port | | | | | <td>IESG</td>
| total-connection- | TBA69 | 4 | IESG | [RFCXXXX] | <td>RFC 9244</td>
| capacity-per-port | | | | | </tr>
| total-traffic- | TBA70 | 4 | IESG | [RFCXXXX] | <tr>
| protocol | | | | | <td>low-percentile-g</td>
| total-traffic-port | TBA71 | 4 | IESG | [RFCXXXX] | <td>140</td>
| total-attack- | TBA72 | 4 | IESG | [RFCXXXX] | <td>0</td>
| traffic-protocol | | | | | <td>IESG</td>
| total-attack- | TBA73 | 4 | IESG | [RFCXXXX] | <td>RFC 9244</td>
| traffic-port | | | | | </tr>
| total-attack- | TBA74 | 4 | IESG | [RFCXXXX] | <tr>
| connection-port | | | | | <td>mid-percentile-g</td>
| port | TBA75 | 0 | IESG | [RFCXXXX] | <td>141</td>
| supported-query-type | TBA76 | 4 | IESG | [RFCXXXX] | <td>0</td>
| vendor-id | TBA77 | 0 | IESG | [RFCXXXX] | <td>IESG</td>
| ietf-dots-telemetry: | TBA78 | 5 | IESG | [RFCXXXX] | <td>RFC 9244</td>
| telemetry-setup | | | | | </tr>
| ietf-dots-telemetry: | TBA79 | 4 | IESG | [RFCXXXX] | <tr>
| total-traffic | | | | | <td>high-percentile-g</td>
| ietf-dots-telemetry: | TBA80 | 4 | IESG | [RFCXXXX] | <td>142</td>
| total-attack-traffic | | | | | <td>0</td>
| ietf-dots-telemetry: | TBA81 | 5 | IESG | [RFCXXXX] | <td>IESG</td>
| total-attack- | | | | | <td>RFC 9244</td>
| connection | | | | | </tr>
| ietf-dots-telemetry: | TBA82 | 4 | IESG | [RFCXXXX] | <tr>
| attack-detail | | | | | <td>peak-g</td>
| ietf-dots-telemetry: | TBA83 | 5 | IESG | [RFCXXXX] | <td>143</td>
| telemetry | | | | | <td>0</td>
| current-g | TBA84 | 0 | IESG | [RFCXXXX] | <td>IESG</td>
| description-lang | TBA85 | 3 | IESG | [RFCXXXX] | <td>RFC 9244</td>
+----------------------+-------+-------+------------+---------------+ </tr>
<tr>
Table 4: Registered DOTS Signal Channel CBOR Key Values <td>total-attack-traffic</td>
]]></artwork> <td>144</td>
</figure></t> <td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>total-traffic</td>
<td>145</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>total-connection-capacity</td>
<td>146</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>connection</td>
<td>147</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>connection-client</td>
<td>148</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>embryonic</td>
<td>149</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>embryonic-client</td>
<td>150</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>connection-ps</td>
<td>151</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>connection-client-ps</td>
<td>152</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>request-ps</td>
<td>153</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>request-client-ps</td>
<td>154</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>partial-request-max</td>
<td>155</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>partial-request-client-max</td>
<td>156</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>total-attack-connection</td>
<td>157</td>
<td>5</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>connection-c</td>
<td>158</td>
<td>5</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>embryonic-c</td>
<td>159</td>
<td>5</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>connection-ps-c</td>
<td>160</td>
<td>5</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>request-ps-c</td>
<td>161</td>
<td>5</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>attack-detail</td>
<td>162</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>id</td>
<td>163</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>attack-id</td>
<td>164</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>attack-description</td>
<td>165</td>
<td>3</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>attack-severity</td>
<td>166</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>start-time</td>
<td>167</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>end-time</td>
<td>168</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>source-count</td>
<td>169</td>
<td>5</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>top-talker</td>
<td>170</td>
<td>5</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>spoofed-status</td>
<td>171</td>
<td>7</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>partial-request-c</td>
<td>172</td>
<td>5</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>total-attack-connection-protocol</td>
<td>173</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>baseline</td>
<td>174</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>current-config</td>
<td>175</td>
<td>5</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>max-config-values</td>
<td>176</td>
<td>5</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>min-config-values</td>
<td>177</td>
<td>5</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>supported-unit-classes</td>
<td>178</td>
<td>5</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>server-originated-telemetry</td>
<td>179</td>
<td>7</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>telemetry-notify-interval</td>
<td>180</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>tmid</td>
<td>181</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>measurement-interval</td>
<td>182</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>measurement-sample</td>
<td>183</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>talker</td>
<td>184</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>source-prefix</td>
<td>185</td>
<td>3</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>mid-list</td>
<td>186</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>source-port-range</td>
<td>187</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>source-icmp-type-range</td>
<td>188</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>target</td>
<td>189</td>
<td>5</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>capacity</td>
<td>190</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>protocol</td>
<td>191</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>total-traffic-normal-per-protocol</td>
<td>192</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>total-traffic-normal-per-port</td>
<td>193</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>total-connection-capacity-per-port</td>
<td>194</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>total-traffic-protocol</td>
<td>195</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>total-traffic-port</td>
<td>196</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>total-attack-traffic-protocol</td>
<td>197</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>total-attack-traffic-port</td>
<td>198</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>total-attack-connection-port</td>
<td>199</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>port</td>
<td>200</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>supported-query-type</td>
<td>201</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>vendor-id</td>
<td>202</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>ietf-dots-telemetry:telemetry-setup</td>
<td>203</td>
<td>5</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>ietf-dots-telemetry:total-traffic</td>
<td>204</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>ietf-dots-telemetry:total-attack-traffic</td>
<td>205</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>ietf-dots-telemetry:total-attack-connection</td>
<td>206</td>
<td>5</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>ietf-dots-telemetry:attack-detail</td>
<td>207</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>ietf-dots-telemetry:telemetry</td>
<td>208</td>
<td>5</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>current-g</td>
<td>209</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
<tr>
<td>description-lang</td>
<td>210</td>
<td>3</td>
<td>IESG</td>
<td>RFC 9244</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default">
<name>DOTS Signal Channel Conflict Cause Codes</name>
<t>Per this document, IANA has assigned a new code from the
"DOTS Signal Channel Conflict Cause Codes" registry <xref target="Cause"
format="default"/>.</t>
<section title="DOTS Signal Channel Conflict Cause Codes"> <table anchor="tab-5">
<t>This specification requests IANA to assign a new code from the <name>Registered DOTS Signal Channel Conflict Cause Code</name>
"DOTS Signal Channel Conflict Cause Codes" registry <xref <thead>
target="Cause"></xref>.</t> <tr>
<th>Code</th>
<t><figure> <th>Label</th>
<artwork align="center"><![CDATA[+------+-------------------+------- <th>Description</th>
-----------------+-------------+ <th>Reference</th>
| Code | Label | Description | Reference | </tr>
+======+===================+========================+=============+ </thead>
| TBA | overlapping-pipes | Overlapping pipe scope | [RFCXXXX] | <tbody>
+------+-------------------+------------------------+-------------+ <tr>
<td>5</td>
Table 5: Registered DOTS Signal Channel Conflict Cause Code <td>overlapping-pipes</td>
]]></artwork> <td>Overlapping pipe scope</td>
</figure><list style="symbols"> <td>RFC 9244</td>
<t>Note to the RFC Editor: Please replace all occurrences of "TBA" </tr>
with the assigned value.</t> </tbody>
</list></t> </table>
</section> </section>
<section anchor="yang" numbered="true" toc="default">
<name>DOTS Telemetry URIs and YANG Module Registrations</name>
<t>Per this document, IANA has registered the following URIs in the
"ns" subregistry within the "IETF XML Registry" <xref target="RFC3688" f
ormat="default"/>: </t>
<dl newline="false" spacing="compact">
<dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-telemetry</dd>
<dt>Registrant Contact:</dt><dd>The IESG.</dd>
<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-mapping</dd>
<dt>Registrant Contact:</dt><dd>The IESG.</dd>
<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<section anchor="yang" title="DOTS Signal Telemetry YANG Module"> <t>Per this document, IANA has registered the following YANG
<t>This document requests IANA to register the following URIs in the modules in the "YANG Module Names" subregistry <xref target="RFC6020" fo
"ns" subregistry within the "IETF XML Registry" <xref rmat="default"/> within the "YANG Parameters" registry.</t>
target="RFC3688"></xref>: <figure> <dl newline="false" spacing="compact">
<artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-dot <dt>Name:</dt><dd>ietf-dots-telemetry</dd>
s-telemetry <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-telemetry</dd>
Registrant Contact: The IESG. <dt>Maintained by IANA:</dt><dd>N</dd>
XML: N/A; the requested URI is an XML namespace. <dt>Prefix:</dt><dd>dots-telemetry</dd>
<dt>Reference:</dt><dd>RFC 9244</dd>
URI: urn:ietf:params:xml:ns:yang:ietf-dots-mapping </dl>
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.]]></artwork>
</figure>This document requests IANA to register the following YANG
modules in the "YANG Module Names" subregistry <xref
target="RFC6020"></xref> within the "YANG Parameters" registry.<figure>
<artwork><![CDATA[ name: ietf-dots-telemetry
namespace: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry
maintained by IANA: N
prefix: dots-telemetry
reference: RFC XXXX
name: ietf-dots-mapping <dl newline="false" spacing="compact">
namespace: urn:ietf:params:xml:ns:yang:ietf-dots-mapping <dt>Name:</dt><dd>ietf-dots-mapping</dd>
maintained by IANA: N <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-mapping</dd>
prefix: dots-mapping <dt>Maintained by IANA:</dt><dd>N</dd>
reference: RFC XXXX <dt>Prefix:</dt><dd>dots-mapping</dd>
]]></artwork> <dt>Reference:</dt><dd>RFC 9244</dd>
</figure></t> </dl>
</section> </section>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<section anchor="security" title="Security Considerations"> <name>Security Considerations</name>
<t></t> <section anchor="sec-cons-1" numbered="true" toc="default">
<name>DOTS Signal Channel Telemetry</name>
<section anchor="sec1" title="DOTS Signal Channel Telemetry">
<t>The security considerations for the DOTS signal channel protocol <t>The security considerations for the DOTS signal channel protocol
are discussed in Section 11 of <xref target="RFC9132"></xref>. The are discussed in <xref target="RFC9132" sectionFormat="of" section="11"/ >. The
following discusses the security considerations that are specific to following discusses the security considerations that are specific to
the DOTS signal channel extension defined in this document.</t> the DOTS signal channel extension defined in this document.</t>
<t>The DOTS telemetry information includes DOTS client network <t>The DOTS telemetry information includes DOTS client network
topology, DOTS client domain pipe capacity, normal traffic baseline topology, DOTS client domain pipe capacity, normal traffic baseline
and connections' capacity, and threat and mitigation information. Such and connection capacity, and threat and mitigation information. Such
information is sensitive; it MUST be protected at rest by the DOTS information is sensitive; it <bcp14>MUST</bcp14> be protected at rest by
the DOTS
server domain to prevent data leakage. Note that sharing this server domain to prevent data leakage. Note that sharing this
sensitive data with a trusted DOTS server does not introduce any new sensitive data with a trusted DOTS server does not introduce any new
significant considerations other that the need for the aforementioned significant considerations other than the need for the aforementioned
protection. Such a DOTS server is already trusted to have access to protection. Such a DOTS server is already trusted to have access to
that kind of information by being in the position to observe and that kind of information by being in the position to observe and
mitigate attacks.</t> mitigate attacks.</t>
<t>DOTS clients are typically considered to be trusted devices by the <t>DOTS clients are typically considered to be trusted devices by the
DOTS client domain. DOTS clients may be co-located on network security DOTS client domain. DOTS clients may be co-located on network security
services (e.g., firewall devices), and a compromised security service services (e.g., firewall devices), and a compromised security service
potentially can do a lot more damage to the network than just the DOTS potentially can do a lot more damage to the network than just the DOTS
client component. This assumption differs from the often held view client component. This assumption differs from the often-held view
that devices are untrusted, often referred to as the "zero-trust (often referred to as the "zero-trust model") that devices are untrusted
model". A compromised DOTS client can send fake DOTS telemetry data to . A compromised DOTS client can send fake DOTS telemetry data to
a DOTS server to mislead the DOTS server. This attack can be prevented a DOTS server to mislead the DOTS server. This attack can be prevented
by monitoring and auditing DOTS clients to detect misbehavior and to by monitoring and auditing DOTS clients to detect misbehavior and to
deter misuse, and by only authorizing the DOTS client to convey DOTS deter misuse, and by only authorizing the DOTS client to convey DOTS
telemetry information for specific target resources (e.g., an telemetry information for specific target resources (e.g., an
application server is authorized to exchange DOTS telemetry for its IP application server is authorized to exchange DOTS telemetry for its IP
addresses but a DDoS mitigator can exchange DOTS telemetry for any addresses but a DDoS mitigator can exchange DOTS telemetry for any
target resource in the network). As a reminder, this is a variation of target resource in the network). As a reminder, this is a variation of
dealing with compromised DOTS clients as discussed in Section 11 of dealing with compromised DOTS clients as discussed in <xref target="RFC9
<xref target="RFC9132"></xref>.</t> 132" sectionFormat="of" section="11"/>.</t>
<t>DOTS servers must be capable of defending themselves against DoS <t>DOTS servers must be capable of defending themselves against DoS
attacks from compromised DOTS clients. The following non-comprehensive attacks from compromised DOTS clients. The following non-comprehensive
list of mitigation techniques can be used by a DOTS server to handle list of mitigation techniques can be used by a DOTS server to handle
misbehaving DOTS clients:</t> misbehaving DOTS clients:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The probing rate (defined in <xref target="RFC9132" sectionFormat=
<t>The probing rate (defined in Section 4.5 of <xref "of" section="4.5"/>) can be used to limit the average data
target="RFC9132"></xref>) can be used to limit the average data rate to the DOTS server.</li>
rate to the DOTS server.</t> <li>Rate-limiting DOTS telemetry, including packets with new 'tmid'
values from the same DOTS client, defends against DoS attacks that
<t>Rate-limiting DOTS telemetry, including those with new 'tmid'
values, from the same DOTS client defends against DoS attacks that
would result in varying the 'tmid' to exhaust DOTS server would result in varying the 'tmid' to exhaust DOTS server
resources. Likewise, the DOTS server can enforce a quota and resources.
time-limit on the number of active pre-or-ongoing-mitigation Likewise, the DOTS server can enforce a quota and
time limit on the number of active pre-or-ongoing-mitigation
telemetry data items (identified by 'tmid') from the DOTS telemetry data items (identified by 'tmid') from the DOTS
client.</t> client.</li>
</list></t> </ul>
<t>Note also that the telemetry notification interval may be used to
<t>Note also that telemetry notification interval may be used to
rate-limit the pre-or-ongoing-mitigation telemetry notifications rate-limit the pre-or-ongoing-mitigation telemetry notifications
received by a DOTS client domain.</t> received by a DOTS client domain.</t>
</section> </section>
<section anchor="sec-cons-2" numbered="true" toc="default">
<section title="Vendor Attack Mapping"> <name>Vendor Attack Mapping</name>
<t>The security considerations for the DOTS data channel protocol are <t>The security considerations for the DOTS data channel protocol are
discussed in Section 10 of <xref target="RFC8783"></xref>. The discussed in <xref target="RFC8783" sectionFormat="of" section="10"/>. T he
following discusses the security considerations that are specific to following discusses the security considerations that are specific to
the DOTS data channel extension defined in this document.</t> the DOTS data channel extension defined in this document.</t>
<t>All data nodes defined in the YANG module specified in <xref target="data" fo
<t>All data nodes defined in the YANG module specified in <xref rmat="default"/> that can be created, modified, and deleted (i.e., config true,
target="data"></xref> which can be created, modified, and deleted which
(i.e., config true, which is the default) are considered sensitive. is the default) are considered sensitive. Write operations to these
Write operations to these data nodes without proper protection can data nodes without proper protection can have a negative effect on
have a negative effect on network operations. Appropriate security network operations. Appropriate security measures are recommended to prevent
measures are recommended to prevent illegitimate users from invoking illegitimate users
DOTS data channel primitives as discussed in <xref from invoking DOTS data channel primitives as discussed in <xref
target="RFC8783"></xref>. Nevertheless, an attacker who can access a target="RFC8783" format="default"/>. Nevertheless, an attacker who can a
DOTS client is technically capable of undertaking various attacks, ccess
such as: <list style="symbols"> a DOTS client is technically capable of undertaking various attacks,
<t>Communicating invalid attack mapping details to the server such as: </t>
<ul spacing="normal">
<li>Communicating invalid attack mapping details to the server
('/data-channel:dots-data/data-channel:dots-client/dots-telemetry:ve ndor-mapping'), ('/data-channel:dots-data/data-channel:dots-client/dots-telemetry:ve ndor-mapping'),
which will mislead the server when correlating attack details.</t> which will mislead the server when correlating attack details.</li>
</list></t> </ul>
<t>Some of the readable data nodes in the YANG module specified in <t>Some of the readable data nodes in the YANG module specified in
<xref target="data"></xref> may be considered sensitive. It is thus <xref target="data" format="default"/> may be considered sensitive. It i s thus
important to control read access to these data nodes. These are the important to control read access to these data nodes. These are the
data nodes and their sensitivity:<list style="symbols"> data nodes and their sensitivity:</t>
<t>'/data-channel:dots-data/data-channel:dots-client/dots-telemetry: <ul spacing="normal">
vendor-mapping' <li>'/data-channel:dots-data/data-channel:dots-client/dots-telemetry:v
endor-mapping'
can be misused to infer the DDoS protection technology deployed in can be misused to infer the DDoS protection technology deployed in
a DOTS client domain.</t> a DOTS client domain.</li>
<li>'/data-channel:dots-data/dots-telemetry:vendor-mapping' can be
<t>'/data-channel:dots-data/dots-telemetry:vendor-mapping' can be
used by a compromised DOTS client to leak the attack detection used by a compromised DOTS client to leak the attack detection
capabilities of the DOTS server. This is a variation of the capabilities of the DOTS server. This is a variation of the
compromised DOTS client attacks discussed in <xref compromised DOTS client attacks discussed in <xref target="sec-cons-
target="sec1"></xref>.</t> 1" format="default"/>.</li>
</list></t> </ul>
<t></t>
</section> </section>
</section> </section>
</middle>
<back>
<section anchor="contr" title="Contributors"> <displayreference target="I-D.ietf-dots-multihoming" to="DOTS-Multihoming"/>
<t>The following individuals have contributed to this document:<list <displayreference target="I-D.ietf-dots-robust-blocks" to="DOTS-Robust-Blocks"/>
style="symbols"> <references>
<t>Li Su, CMCC, Email: suli@chinamobile.com</t> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7950.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3688.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7641.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6991.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8949.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7959.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8783.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8345.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7970.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8040.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7252.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6020.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9132.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8791.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5646.xml"/>
<reference anchor="Private-Enterprise-Numbers" target="https://www.iana.
org/assignments/enterprise-numbers/">
<front>
<title>Private Enterprise Numbers</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9133.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4732.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8811.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2330.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8525.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8903.xml"/>
<t>Pan Wei, Huawei, Email: william.panwei@huawei.com</t> <!-- draft-doron-dots-telemetry ("long way"; error in author name) (Expired) -->
</list></t> <reference anchor="DOTS-Telemetry-Specs">
</section> <front>
<title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetr
y Specifications</title>
<author initials="E." surname="Doron" fullname="Ehud Doron">
</author>
<author initials="T." surname="Reddy" fullname="Tirumaleswar Reddy">
</author>
<author initials="F." surname="Andreasen" fullname="Flemming Andreasen">
</author>
<author initials="L." surname="Xia" fullname="Liang Xia">
</author>
<author initials="K." surname="Nishizuka" fullname="Kaname Nishizuka">
</author>
<date month="October" day="30" year="2016" />
</front>
<seriesInfo name="Internet-Draft" value="draft-doron-dots-telemetry-00" />
</reference>
<section anchor="ack" title="Acknowledgements"> <!-- draft-ietf-dots-multihoming (IESG Eval / AD Followup) -->
<t>The authors would like to thank Flemming Andreasen, Liang Xia, and <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-do
Kaname Nishizuka, co-authors of <xref ts-multihoming.xml"/>
target="I-D.doron-dots-telemetry"></xref>, and everyone who had <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
contributed to that document.</t> 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.9260.xml"/>
<t>Thanks to Kaname Nishizuka, Wei Pan, Yuuhei Hayashi, and Tom Petch <!-- draft-ietf-core-new-block (RFC 9177; published March 2022) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9177.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-do
ts-robust-blocks.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5612.xml"/>
<reference anchor="Key-Map" target="https://www.iana.org/assignments/dot
s/">
<front>
<title>DOTS Signal Channel CBOR Key Values</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="Cause" target="https://www.iana.org/assignments/dots/
">
<front>
<title>DOTS Signal Channel Conflict Cause Codes</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="PYANG" target="https://github.com/mbj4668/pyang">
<front>
<title>pyang</title>
<author>
<organization/>
</author>
<date month="April" year="2022"/>
</front>
<refcontent>commit dad5c68</refcontent>
</reference>
</references>
</references>
<section anchor="ack" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Flemming Andreasen"/
>, <contact fullname="Liang Xia"/>, and
<contact fullname="Kaname Nishizuka"/>, coauthors of <xref target="DOTS-Te
lemetry-Specs" format="default"/>, and everyone who had
contributed to that document.</t>
<t>Thanks to <contact fullname="Kaname Nishizuka"/>, <contact fullname="Yu
hei Hayashi"/>, and <contact fullname="Tom Petch"/>
for comments and review.</t> for comments and review.</t>
<t>Special thanks to <contact fullname="Jon Shallow"/> and <contact fullna
<t>Special thanks to Jon Shallow and Kaname Nishizuka for their me="Kaname Nishizuka"/> for their
implementation and interoperability work.</t> implementation and interoperability work.</t>
<t>Many thanks to <contact fullname="Jan Lindblad"/> for the yangdoctors r
<t>Many thanks to Jan Lindblad for the yangdoctors review, Nagendra eview, <contact fullname="Nagendra Nainar"/> for the opsdir review, <contact ful
Nainar for the opsdir review, James Gruessing for the artart review, lname="James Gruessing"/> for the artart review,
Michael Scharf for the tsv-art review, Ted Lemon for the int-dir review, <contact fullname="Michael Scharf"/> for the tsv-art review, <contact full
and Robert Sparks for the gen-art review.</t> name="Ted Lemon"/> for the int-dir review,
and <contact fullname="Robert Sparks"/> for the gen-art review.</t>
<t>Thanks to Benjamin Kaduk for the detailed AD review.</t> <t>Thanks to <contact fullname="Benjamin Kaduk"/> for the detailed AD revi
ew.</t>
<t>Thanks to Roman Danyliw, &Eacute;ric Vyncke, Francesca Palombini, <t>Thanks to <contact fullname="Roman Danyliw"/>, <contact fullname="Éric
Warren Kumari, Erik Kline, Lars Eggert, and Robert Wilton for the IESG Vyncke"/>, <contact fullname="Francesca Palombini"/>,
<contact fullname="Warren Kumari"/>, <contact fullname="Erik Kline"/>, <co
ntact fullname="Lars Eggert"/>, and <contact fullname="Robert Wilton"/> for the
IESG
review.</t> review.</t>
</section> </section>
</middle> <section anchor="contr" numbered="false" toc="default">
<name>Contributors</name>
<back> <t>The following individuals have contributed to this document:</t>
<references title="Normative References"> <contact fullname="Li Su">
<?rfc include="reference.RFC.2119"?> <organization>CMCC</organization>
<address>
<?rfc include="reference.RFC.7950"?> <email>suli@chinamobile.com</email>
</address>
<?rfc include="reference.RFC.3688"?> </contact>
<contact fullname="Pan Wei">
<?rfc include='reference.RFC.8174'?> <organization>Huawei</organization>
<address>
<?rfc include='reference.RFC.7641'?> <email>william.panwei@huawei.com</email>
</address>
<?rfc include='reference.RFC.6991'?> </contact>
</section>
<?rfc include='reference.RFC.8949'?>
<?rfc include='reference.RFC.7959'?>
<?rfc include="reference.RFC.8783" ?>
<?rfc include='reference.RFC.8345'?>
<?rfc include='reference.RFC.7970'?>
<?rfc include='reference.RFC.8040'?>
<?rfc include='reference.RFC.7252'?>
<?rfc ?>
<?rfc include='reference.RFC.6020'?>
<?rfc include='reference.RFC.9132'?>
<?rfc include='reference.RFC.8791'?>
<?rfc include='reference.RFC.5646'?>
<reference anchor="Private-Enterprise-Numbers"
target="https://www.iana.org/assignments/enterprise-numbers">
<front>
<title>Private Enterprise Numbers</title>
<author>
<organization></organization>
</author>
<date day="04" month="May" year="2020" />
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.9133'?>
<?rfc include='reference.RFC.4732'?>
<?rfc include='reference.RFC.8811'?>
<?rfc include='reference.RFC.2330'?>
<?rfc include='reference.RFC.8525'?>
<?rfc include='reference.RFC.8903'?>
<?rfc include='reference.I-D.doron-dots-telemetry'?>
<?rfc include='reference.I-D.ietf-dots-multihoming'?>
<?rfc include="reference.RFC.8612"?>
<?rfc include='reference.RFC.8340'?>
<?rfc include='reference.RFC.4960'?>
<?rfc include='reference.I-D.ietf-core-new-block'?>
<?rfc include='reference.I-D.ietf-dots-robust-blocks'?>
<?rfc include='reference.RFC.5612'?>
<reference anchor="Key-Map"
target="https://www.iana.org/assignments/dots/dots.xhtml#dots-s
ignal-channel-cbor-key-values">
<front>
<title>DOTS Signal Channel CBOR Key Values</title>
<author fullname="IANA">
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="Cause"
target="https://www.iana.org/assignments/dots/dots.xhtml#dots-s
ignal-channel-conflict-cause-codes">
<front>
<title>DOTS Signal Channel Conflict Cause Codes</title>
<author fullname="IANA">
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="PYANG" target="https://github.com/mbj4668/pyang">
<front>
<title>pyang</title>
<author>
<organization></organization>
</author>
<date month="November" year="2020" />
</front>
</reference>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 585 change blocks. 
2185 lines changed or deleted 3148 lines changed or added

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