rfc9244.txt   draft-ietf-dots-telemetry.txt 
Internet Engineering Task Force (IETF) M. Boucadair, Ed. DOTS M. Boucadair, Ed.
Request for Comments: 9244 Orange Internet-Draft Orange
Category: Standards Track T. Reddy.K, Ed. Intended status: Standards Track T. Reddy.K, Ed.
ISSN: 2070-1721 Akamai Expires: 22 September 2022 Akamai
E. Doron E. Doron
Radware Ltd. Radware Ltd.
M. Chen M. Chen
CMCC CMCC
J. Shallow J. Shallow
June 2022 21 March 2022
Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
draft-ietf-dots-telemetry-23
Abstract Abstract
This document aims to enrich the Distributed Denial-of-Service Open This document aims to enrich the DOTS signal channel protocol with
Threat Signaling (DOTS) signal channel protocol with various various telemetry attributes, allowing for optimal Distributed
telemetry attributes, allowing for optimal Distributed Denial-of- Denial-of-Service (DDoS) attack mitigation. It specifies the normal
Service (DDoS) attack mitigation. It specifies the normal traffic traffic baseline and attack traffic telemetry attributes a DOTS
baseline and attack traffic telemetry attributes a DOTS client can client can convey to its DOTS server in the mitigation request, the
convey to its DOTS server in the mitigation request, the mitigation mitigation status telemetry attributes a DOTS server can communicate
status telemetry attributes a DOTS server can communicate to a DOTS to a DOTS client, and the mitigation efficacy telemetry attributes a
client, and the mitigation efficacy telemetry attributes a DOTS DOTS client can communicate to a DOTS server. The telemetry
client can communicate to a DOTS server. The telemetry attributes attributes can assist the mitigator to choose the DDoS mitigation
can assist the mitigator in choosing the DDoS mitigation techniques techniques and perform optimal DDoS attack mitigation.
and performing optimal DDoS attack mitigation.
This document specifies two YANG modules: one for representing DOTS This document specifies a YANG module for representing DOTS telemetry
telemetry message types and one for sharing the attack mapping message types. It also specifies a second YANG module to share the
details over the DOTS data channel. attack mapping details over the DOTS data channel.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document is a product of the Internet Engineering Task Force Internet-Drafts are working documents of the Internet Engineering
(IETF). It represents the consensus of the IETF community. It has Task Force (IETF). Note that other groups may also distribute
received public review and has been approved for publication by the working documents as Internet-Drafts. The list of current Internet-
Internet Engineering Steering Group (IESG). Further information on Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, Internet-Drafts are draft documents valid for a maximum of six months
and how to provide feedback on it may be obtained at and may be updated, replaced, or obsoleted by other documents at any
https://www.rfc-editor.org/info/rfc9244. time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 22 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Revised BSD License text as described in Section 4.e of the described in Section 4.e of the Trust Legal Provisions and are
Trust Legal Provisions and are provided without warranty as described provided without warranty as described in the Revised BSD License.
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. DOTS Telemetry: Overview and Purpose 3. DOTS Telemetry: Overview and Purpose . . . . . . . . . . . . 7
3.1. Need for More Visibility 3.1. Need More Visibility . . . . . . . . . . . . . . . . . . 7
3.2. Enhanced Detection 3.2. Enhanced Detection . . . . . . . . . . . . . . . . . . . 8
3.3. Efficient Mitigation 3.3. Efficient Mitigation . . . . . . . . . . . . . . . . . . 10
4. Design Overview 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Overview of Telemetry Operations 4.1. Overview of Telemetry Operations . . . . . . . . . . . . 11
4.2. Block-Wise Transfers 4.2. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 12
4.3. DOTS Multihoming Considerations 4.3. DOTS Multi-homing Considerations . . . . . . . . . . . . 13
4.4. YANG Considerations 4.4. YANG Considerations . . . . . . . . . . . . . . . . . . . 13
5. Generic Considerations 5. Generic Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. DOTS Client Identification 5.1. DOTS Client Identification . . . . . . . . . . . . . . . 14
5.2. DOTS Gateways 5.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Uri-Path Parameters and Empty Values 5.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . . . 15
5.4. Controlling Configuration Data 5.4. Controlling Configuration Data . . . . . . . . . . . . . 15
5.5. Message Validation 5.5. Message Validation . . . . . . . . . . . . . . . . . . . 15
5.6. A Note about Examples 5.6. A Note About Examples . . . . . . . . . . . . . . . . . . 15
6. Telemetry Operation Paths 6. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 16
7. DOTS Telemetry Setup Configuration 7. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 17
7.1. Telemetry Configuration 7.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 17
7.1.1. Retrieving the Current DOTS Telemetry Configuration 7.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 18
7.1.2. Conveying the DOTS Telemetry Configuration 7.1.2. Conveying DOTS Telemetry Configuration . . . . . . . 20
7.1.3. Retrieving the Installed DOTS Telemetry Configuration 7.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 24
7.1.4. Deleting the DOTS Telemetry Configuration 7.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 25
7.2. Total Pipe Capacity 7.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 25
7.2.1. Conveying DOTS Client Domain Pipe Capacity 7.2.1. Conveying DOTS Client Domain Pipe Capacity . . . . . 26
7.2.2. Retrieving Installed DOTS Client Domain Pipe Capacity 7.2.2. Retrieve Installed DOTS Client Domain Pipe
7.2.3. Deleting Installed DOTS Client Domain Pipe Capacity Capacity . . . . . . . . . . . . . . . . . . . . . . 32
7.3. Telemetry Baseline 7.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 32
7.3.1. Conveying DOTS Client Domain Baseline Information 7.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 32
7.3.2. Retrieving Installed Normal Traffic Baseline 7.3.1. Conveying DOTS Client Domain Baseline Information . . 35
Information 7.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 39
7.3.3. Deleting Installed Normal Traffic Baseline Information 7.3.3. Delete Installed Normal Traffic Baseline . . . . . . 39
7.4. Resetting the Installed Telemetry Setup 7.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 39
7.5. Conflict with Other DOTS Clients of the Same Domain 7.5. Conflict with Other DOTS Clients of the Same Domain . . . 39
8. DOTS Pre-or-Ongoing-Mitigation Telemetry 8. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 40
8.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes 8.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 42
8.1.1. Target 8.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 43
8.1.2. Total Traffic 8.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 44
8.1.3. Total Attack Traffic 8.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 46
8.1.4. Total Attack Connections 8.1.4. Total Attack Connections . . . . . . . . . . . . . . 48
8.1.5. Attack Details 8.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 50
8.1.6. Vendor Attack Mapping 8.1.6. Vendor Attack Mapping . . . . . . . . . . . . . . . . 53
8.2. From DOTS Clients to DOTS Servers 8.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 57
8.3. From DOTS Servers to DOTS Clients 8.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 60
9. DOTS Telemetry Mitigation Status Update 9. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 65
9.1. From DOTS Clients to DOTS Servers: Mitigation Efficacy DOTS 9.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry
Telemetry Attributes Attributes . . . . . . . . . . . . . . . . . . . . . . . 65
9.2. From DOTS Servers to DOTS Clients: Mitigation Status DOTS 9.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry
Telemetry Attributes Attributes . . . . . . . . . . . . . . . . . . . . . . . 67
10. Error Handling 10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 71
11. YANG Modules 11. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 72
11.1. DOTS Signal Channel Telemetry YANG Module 11.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . 72
11.2. Vendor Attack Mapping Details YANG Module 11.2. Vendor Attack Mapping Details YANG Module . . . . . . . 102
12. YANG/JSON Mapping Parameters to CBOR 12. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 106
13. IANA Considerations 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 109
13.1. DOTS Signal Channel CBOR Key Values 13.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 109
13.2. DOTS Signal Channel Conflict Cause Codes 13.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 111
13.3. DOTS Telemetry URIs and YANG Module Registrations 13.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 112
14. Security Considerations 14. Security Considerations . . . . . . . . . . . . . . . . . . . 112
14.1. DOTS Signal Channel Telemetry 14.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 113
14.2. Vendor Attack Mapping 14.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 114
15. References 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 115
15.1. Normative References 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 115
15.2. Informative References 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 115
Acknowledgments 17.1. Normative References . . . . . . . . . . . . . . . . . . 115
Contributors 17.2. Informative References . . . . . . . . . . . . . . . . . 117
Authors' Addresses Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 119
1. Introduction 1. Introduction
IT organizations and service providers are facing Distributed Denial- IT organizations and service providers are facing Distributed Denial
of-Service (DDoS) attacks that fall into two broad categories: of Service (DDoS) attacks that fall into two broad categories:
1. Network-layer and transport-layer attacks target the victim's 1. Network/Transport layer attacks target the victim's
infrastructure. These attacks are not necessarily aimed at infrastructure. These attacks are not necessarily aimed at
taking down the actual delivered services; rather, these attacks taking down the actual delivered services, but rather to prevent
prevent various network elements (routers, switches, firewalls, various network elements (routers, switches, firewalls, transit
transit links, and so on) from serving legitimate users' traffic. links, and so on) from serving legitimate users' traffic.
The main method of such attacks is to send a large volume of The main method of such attacks is to send a large volume or high
traffic (e.g., high-pps (packets per second) traffic) toward the packet per second (pps) of traffic toward the victim's
victim's infrastructure. Typically, attack volumes may vary from infrastructure. Typically, attack volumes may vary from a few
a few hundred Mbps to hundreds of Gbps or even Tbps. Attacks are 100 Mbps to 100s of Gbps or even Tbps. Attacks are commonly
commonly carried out leveraging botnets and attack reflectors for carried out leveraging botnets and attack reflectors for
amplification attacks (Section 3.1 of [RFC4732]) such as NTP amplification attacks (Section 3.1 of [RFC4732]) such as NTP
(Network Time Protocol), DNS (Domain Name System), SNMP (Simple (Network Time Protocol), DNS (Domain Name System), SNMP (Simple
Network Management Protocol), or SSDP (Simple Service Discovery Network Management Protocol), or SSDP (Simple Service Discovery
Protocol). Protocol).
2. Application-layer attacks target various applications. Typical 2. 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. edges can be attractive attack targets.
Application-layer attacks are considered more complex and harder Application layer attacks are considered more complex and harder
to categorize and are therefore harder to detect and mitigate to categorize, and therefore harder to detect and mitigate
efficiently. efficiently.
To compound the problem, attackers also leverage multi-vectored To compound the problem, attackers also leverage multi-vectored
attacks. These attacks are assembled from dynamic network-layer and attacks. These attacks are assembled from dynamic attack vectors
application-layer attack vectors and other tactics. As such, (Network/Application) and tactics. As such, multiple attack vectors
multiple attack vectors formed by multiple attack types and volumes formed by multiple attack types and volumes are launched
are launched simultaneously toward a victim. Multi-vector attacks simultaneously towards a victim. Multi-vector attacks are harder to
are harder to detect and defend against. Multiple and simultaneous detect and defend against. Multiple and simultaneous mitigation
mitigation techniques are needed to defeat such attack campaigns. It techniques are needed to defeat such attack campaigns. It is also
is also common for attackers to change attack vectors right after a common for attackers to change attack vectors right after a
successful mitigation, burdening their opponents with changing their successful mitigation, burdening their opponents with changing their
defense methods. defense methods.
The conclusion derived from the aforementioned attack scenarios is The conclusion derived from the aforementioned attack scenarios is
that modern attack detection and mitigation are most certainly that modern attacks 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 and the normal behavior of the knowledge of the attack attributes, the normal behavior of the
targeted systems (including normal traffic patterns), as well as the targeted systems (including normal traffic patterns), as well as the
attacker's ongoing and past actions. Even more challenging, attacker's ongoing and past actions. Even more challenging,
retrieving all the analytics needed for detecting these attacks is retrieving all the analytics needed for detecting these attacks is
not simple with the industry's current reporting capabilities. not simple with the industry's current reporting capabilities.
The Distributed Denial-of-Service Open Threat Signaling (DOTS) signal The DOTS signal channel protocol [RFC9132] is used to carry
channel protocol [RFC9132] is used to carry information about a information about a network resource or a network (or a part thereof)
network resource or a network (or a part thereof) that is under a that is under a DDoS attack. Such information is sent by a DOTS
DDoS attack. Such information is sent by a DOTS client to one or client to one or multiple DOTS servers so that appropriate mitigation
multiple DOTS servers so that appropriate mitigation actions are actions are undertaken on traffic deemed suspicious. Various use
undertaken on traffic deemed suspicious. Various use cases are cases are discussed in [RFC8903].
discussed in [RFC8903].
DOTS clients can be integrated within a DDoS attack detector or DOTS clients can be integrated within a DDoS attack detector, or
within network and security elements that have been actively engaged network and security elements that have been actively engaged with
with ongoing attacks. The DOTS client mitigation environment ongoing attacks. The DOTS client mitigation environment determines
determines that it is no longer possible or practical for it to that it is no longer possible or practical for it to handle these
handle these attacks itself. This can be due to a lack of resources attacks itself. This can be due to a lack of resources or security
or security capabilities, as derived from the complexities and capabilities, as derived from the complexities and the intensity of
intensity of these attacks. In this circumstance, the DOTS client these attacks. In this circumstance, the DOTS client has invaluable
has invaluable knowledge about the actual attacks that need to be knowledge about the actual attacks that need to be handled by its
handled by its DOTS server(s). By enabling the DOTS client to share DOTS server(s). By enabling the DOTS client to share this
this comprehensive knowledge of an ongoing attack under specific comprehensive knowledge of an ongoing attack under specific
circumstances, the DOTS server can drastically increase its ability circumstances, the DOTS server can drastically increase its ability
to accomplish successful mitigation. While the attack is being to accomplish successful mitigation. While the attack is being
handled by the mitigation resources associated with the DOTS server, handled by the mitigation resources associated with the DOTS server,
the DOTS server has knowledge about the ongoing attack mitigation. the DOTS server has knowledge about the ongoing attack mitigation.
The DOTS server can share this information with the DOTS client so The DOTS server can share this information with the DOTS client so
that the client can better assess and evaluate the actual mitigation that the client can better assess and evaluate the actual mitigation
realized. realized.
DOTS clients can send mitigation hints derived from attack details to DOTS clients can send mitigation hints derived from attack details to
DOTS servers, with the full understanding that a DOTS server may DOTS servers, with the full understanding that the DOTS server may
ignore mitigation hints, as described in [RFC8612] (Gen-004). ignore mitigation hints, as described in [RFC8612] (Gen-004).
Mitigation hints will be transmitted across the DOTS signal channel, Mitigation hints will be transmitted across the DOTS signal channel,
as the data channel may not be functional during an attack. How a as the data channel may not be functional during an attack. How a
DOTS server handles normal and attack traffic attributes, and DOTS server is handling normal and attack traffic attributes, and
mitigation hints, is implementation specific. mitigation hints, is implementation specific.
Both DOTS clients and servers can benefit from this information by Both DOTS clients and servers can benefit from this information by
presenting various information details in relevant management, presenting various information in relevant management, reporting, and
reporting, and portal systems. portal systems.
This document defines DOTS telemetry attributes that can be conveyed 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 [RFC9132]. When no limitation policy is provided to a DOTS protocol [RFC9132]. When no limitation policy is provided to a DOTS
agent, it can signal available telemetry attributes to its peers in agent, it can signal available telemetry attributes to it peers in
order to optimize the overall mitigation service provisioned using order to optimize the overall mitigation service provisioned using
DOTS. The aforementioned policy can be, for example, agreed upon DOTS. The aforementioned policy can be, for example, agreed during a
during a service subscription (which is out of scope for this service subscription (that is out of scope) to identify a subset of
document) to identify a subset of DOTS clients among those deployed DOTS clients among those deployed in a DOTS client domain that are
in a DOTS client domain that are allowed to send or receive telemetry allowed to send or receive telemetry data.
data.
Section 11.2 of this document specifies a YANG module that augments Also, the document specifies a YANG module (Section 11.2) that
the DOTS data channel [RFC8783] with information related to attack augments the DOTS data channel [RFC8783] with attack details
details. Sharing such details during 'idle' time is meant to information. Sharing such details during 'idle' time is meant to
optimize the data exchanged over the DOTS signal channel. optimize the data exchanged over the DOTS signal channel.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in BCP
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The reader should be familiar with the terms defined in [RFC8612]. The reader should be familiar with the terms defined in [RFC8612].
"DOTS telemetry" is defined as the collection of attributes that are "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. attributes that can be signaled in the DOTS signal channel protocol.
The Telemetry Setup Identifier (tsid) is an identifier that is Telemetry Setup Identifier (tsid) is an identifier that is generated
generated by DOTS clients to uniquely identify DOTS telemetry setup by DOTS clients to uniquely identify DOTS telemetry setup
configuration data. See Section 7.1.2 for more details. configuration data. See Section 7.1.2 for more details.
The Telemetry Identifier (tmid) is an identifier that is generated by 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 Section 8.2 for communicated prior to or during a mitigation. See Section 8.2 for
more details. more details.
"Overlapped" lower numeric 'tsid' (or 'tmid') refers to the lower When two telemetry requests overlap, "overlapped" lower numeric
'tsid' (or 'tmid') value of two overlapping telemetry requests. 'tsid' (or 'tmid') refers to the lower 'tsid' (or 'tmid') value of
these overlapping requests.
The term "pipe" represents the maximum level of traffic that the DOTS 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 client domain can receive. Whether a "pipe" is mapped to one or a
group of network interfaces is deployment specific. For example, group of network interfaces is deployment-specific. For example,
each interconnection link may be considered as a specific pipe if the each interconnection link may be considered as a specific pipe if the
DOTS server is hosted by each upstream provider, while the aggregate DOTS server is hosted by each upstream provider, while the aggregate
of all links to connect to upstream network providers can be of all links to connect to upstream network providers can be
considered by a DOTS client domain as a single pipe when considered by a DOTS client domain as a single pipe when
communicating with a DOTS server not hosted by these upstream communicating with a DOTS server not hosted by these upstream
providers. providers.
This document uses IANA-assigned Enterprise Numbers. These numbers The document uses IANA-assigned Enterprise Numbers. These numbers
are also known as "Private Enterprise Numbers" and "SMI (Structure of are also known as "Private Enterprise Numbers" and "SMI (Structure of
Management Information) Network Management Private Enterprise Codes" Management Information) Network Management Private Enterprise Codes"
[Private-Enterprise-Numbers]. [Private-Enterprise-Numbers].
The meanings of the symbols in YANG tree diagrams are defined in The meaning of the symbols in YANG tree diagrams are defined in
[RFC8340] and [RFC8791]. [RFC8340] and [RFC8791].
Consistent with the convention set in Section 2 of [RFC8783], the Consistent with the convention set in Section 2 of [RFC8783], the
examples in Section 8.1.6 use "/restconf" as the discovered RESTCONF examples in Section 8.1.6 use "/restconf" as the discovered RESTCONF
API root path. Within these examples, some protocol header lines are API root path. Within these examples, some protocol header lines are
split into multiple lines for display purposes only. When a line split into multiple lines for display purposes only. When a line
ends with a backslash ("\") as the last character, the line is ends with backslash ('\') as the last character, the line is wrapped
wrapped for display purposes. It is considered to be joined to the for display purposes. It is considered to be joined to the next line
next line by deleting the backslash, the following line break, and by deleting the backslash, the following line break, and the leading
the leading whitespace of the next line. whitespace of the next line.
3. DOTS Telemetry: Overview and Purpose 3. DOTS Telemetry: Overview and Purpose
Timely and effective signaling of up-to-date DDoS telemetry to all 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's effectiveness. Bidirectional the overall DDoS mitigation service effectiveness. Bidirectional
feedback between DOTS agents is required for increased awareness by feedback between DOTS agents is required for increased awareness by
each party of the attack and mitigation efforts, supporting a each party of the attack and mitigation efforts, supporting a
superior and highly efficient attack mitigation service. superior and highly efficient attack mitigation service.
3.1. Need for More Visibility 3.1. Need More Visibility
When signaling a mitigation request, it is most certainly beneficial When signaling a mitigation request, it is most certainly beneficial
for DOTS clients to signal to DOTS servers any knowledge regarding for DOTS clients to signal to DOTS servers any knowledge regarding
ongoing attacks. This can happen in cases where DOTS clients are ongoing attacks. This can happen in cases where DOTS clients are
asking DOTS servers for support in defending against attacks that asking DOTS servers for support in defending against attacks that
they have already detected and/or (partially) mitigated. they have already detected and/or (partially) mitigated.
If attacks are already detected and categorized within a DOTS client If attacks are already detected and categorized within a DOTS client
domain, the DOTS server, and its associated mitigation services, can domain, the DOTS server, and its associated mitigation services, can
proactively benefit from this information and optimize the overall proactively benefit from this information and optimize the overall
service delivery. It is important to note that DOTS client domains' service delivery. It is important to note that DOTS client domains'
and DOTS server domains' detection and mitigation approaches can be and DOTS server domains' detection and mitigation approaches can be
different and can potentially result in different results and attack different, and can potentially result in different results and attack
classifications. The DDoS mitigation service treats the ongoing 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 on or trust the attack details conveyed by DOTS completely rely or trust the attack details conveyed by DOTS clients.
clients.
In addition to the DOTS server directly using telemetry data as In addition to the DOTS server directly using telemetry data as
operational hints, the DOTS server's security operation team also operational hints, the DOTS server 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 (e.g., operation mitigation and to assign the correct resources (operation staff,
staff, networking resources, mitigation resources) for the specific networking and mitigation) for the specific service. Similarly,
service. Similarly, security operations personnel at the DOTS client security operations personnel at the DOTS client side ask for
side ask for feedback about their requests for protection. feedback about their requests for protection. Therefore, it is
Therefore, it is valuable for DOTS servers to share DOTS telemetry valuable for DOTS servers to share DOTS telemetry with DOTS clients.
with DOTS clients.
Mutual sharing of information is thus crucial for "closing the Mutual sharing of information is thus crucial for "closing the
mitigation loop" between DOTS clients and servers. For the server- mitigation loop" between DOTS clients and servers. For the server
side team, it is important to confirm that the same attacks that the side team, it is important to confirm that the same attacks that the
DOTS server's mitigation resources are seeing are those for which a DOTS server's mitigation resources are seeing are those that a DOTS
DOTS client is requesting mitigation. For the DOTS client-side team, client is asking for mitigation of. For the DOTS client side team,
it is important to realize that the DOTS clients receive the required it is 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. DOTS telemetry attributes.
In addition, management and orchestration systems, at both the DOTS 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. signaled telemetry information.
If the DOTS server's mitigation resources have the capabilities to 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. Discussion regarding the interface from the decisions and actions. The interface from the DOTS server to the
DOTS server to the mitigator to signal the telemetry data is out of mitigator to signal the telemetry data is out of scope.
scope for this document.
3.2. Enhanced Detection 3.2. Enhanced Detection
DOTS telemetry can also be used as input for determining what values DOTS telemetry can also be used as input for determining what values
to use for the tuning parameters available on the mitigation 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
skipping to change at line 393 skipping to change at page 9, line 24
In addition, subsequent activities toward mitigating an attack are 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, from attacker traffic on a per-packet basis is complex. For example,
a packet may look "legitimate" and no attack signature can be a 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
processes. process.
Normal baseline calculation is performed based on continuous learning Normal baseline calculation is performed based on continuous learning
of the normal behavior of the protected entities. The minimum of the normal behavior of the protected entities. The minimum
learning period varies from hours to days and even weeks, depending learning period varies from hours to days and even weeks, depending
on the protected applications' behavior. The baseline cannot be on the protected application behavior. The baseline cannot be
learned during active attacks because attack conditions do not learned during active attacks because attack conditions do not
characterize the protected entities' normal behavior. characterize the protected entities' normal behavior.
If the DOTS client has calculated the normal baseline of its 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's mitigators use the DOTS client's normal baseline. The DOTS server mitigators use
the baseline to familiarize themselves with the attack victim's the baseline to familiarize themselves with the attack victim's
normal behavior and target the baseline as the level of normality normal behavior and target the baseline as the level of normality
they need to achieve. Fed with this information, the overall they need to achieve. Fed with this information, the overall
mitigation performance is expected to be improved in terms of time to mitigation performances is expected to be improved in terms of time
mitigate, accuracy, and false-negative and false-positive rates. to mitigate, accuracy, and false-negative and false-positive rates.
Mitigation of attacks without having certain knowledge of normal 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 [RFC8811]). Given that recursive signaling (see Section 3.2.3 of [RFC8811]). Given that
DOTS clients can be integrated in a highly diverse set of scenarios DOTS clients can be integrated in a highly diverse set of scenarios
and use cases, this emphasizes the need for knowledge of the behavior and use cases, this emphasizes the need for knowledge of each DOTS
of each DOTS client domain -- especially given that common global client domain behavior, especially given that common global
thresholds for attack detection can almost never be realized. Each thresholds for attack detection practically cannot be realized. Each
DOTS client domain can have its own levels of traffic and normal DOTS client domain can have its own levels of traffic and normal
behavior. Without facilitating normal baseline signaling, it may be behavior. Without facilitating normal baseline signaling, it may be
very difficult for DOTS servers in some cases to detect and mitigate very difficult for DOTS servers in some cases to detect and mitigate
the attacks accurately: the attacks accurately:
* It is important to emphasize that it is practically impossible for It is important to emphasize that it is practically impossible for
the DOTS server's mitigators to calculate the normal baseline in the DOTS server's mitigators to calculate the normal baseline in
cases where they do not have any knowledge of the traffic cases where they do not have any knowledge of the traffic
beforehand. beforehand.
Of course, this information can be provided using out-of-band 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 patterns change. The use of a dynamic and collaborative means
between the DOTS client and server to identify and share key between the DOTS client and server to identify and share key
parameters for the sake of efficient DDoS protection is valuable. parameters for the sake of efficient DDoS protection is valuable.
3.3. Efficient Mitigation 3.3. Efficient Mitigation
During a high-volume attack, DOTS client pipes can be totally 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 that the mitigator does not overwhelm the DOTS client pipes by
sending back large volumes of "clean traffic", or what it believes is sending back large volumes of "clean traffic", or what it believes is
"clean". This can happen when the mitigator has not managed to "clean". This can happen when the mitigator has not managed to
detect and mitigate all the attacks launched toward the DOTS client detect and mitigate all the attacks launched towards the DOTS client
domain. domain.
In this case, it can be valuable to DOTS clients to signal to DOTS 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 is DOTS client domain can absorb from its upstream network. This
usually the circuit size, which includes all the packet overheads. usually is the circuit size which includes all the packet overheads.
Dynamic updates of the condition of pipes between DOTS agents while Dynamic updates of the condition of pipes between DOTS agents while
they are under a DDoS attack are essential (e.g., where multiple DOTS they are under a DDoS attack is essential (e.g., where multiple DOTS
clients share the same physical connectivity pipes). The DOTS server clients share the same physical connectivity pipes). The DOTS server
should activate other mechanisms to ensure that it does not allow the should activate other mechanisms to ensure it does not allow the DOTS
DOTS client domain's pipes to be saturated unintentionally. The client domain's pipes to be saturated unintentionally. The rate-
rate-limit action defined in [RFC8783] is a reasonable candidate to limit action defined in [RFC8783] is a reasonable candidate 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 The rate-limit action can be controlled via the signal channel
[RFC9133] even when the pipe is overwhelmed. [RFC9133] even when the pipe is overwhelmed.
4. Design Overview 4. Design Overview
4.1. Overview of Telemetry Operations 4.1. Overview of Telemetry Operations
The DOTS protocol suite is divided into two logical channels: the The DOTS protocol suite is divided into two logical channels: the
signal channel [RFC9132] and data channel [RFC8783]. This division signal channel [RFC9132] and data channel [RFC8783]. This division
is due to the vastly different requirements placed upon the traffic is due to the vastly different requirements placed upon the traffic
they carry. The DOTS signal channel must remain available and usable they carry. The DOTS signal channel must remain available and usable
even in the face of attack traffic that might, for example, saturate even in the face of attack traffic that might, e.g., saturate one
one direction of the links involved, rendering acknowledgment-based direction of the links involved, rendering acknowledgment-based
mechanisms unreliable and strongly incentivizing messages to be small mechanisms unreliable and strongly incentivizing messages to be small
enough to be contained in a single IP packet (Section 2.2 of enough to be contained in a single IP packet (Section 2.2 of
[RFC8612]). In contrast, the DOTS data channel is available for [RFC8612]). In contrast, the DOTS data channel is available for
high-bandwidth data transfer before or after an attack, using more high-bandwidth data transfer before or after an attack, using more
conventional transport protocol techniques (Section 2.3 of conventional transport protocol techniques (Section 2.3 of
[RFC8612]). It is generally preferable to perform advance [RFC8612]). It is generally preferable to perform advance
configuration over the DOTS data channel, including configuring configuration over the DOTS data channel, including configuring
aliases for static or nearly static data sets such as sets of network aliases for static or nearly static data sets such as sets of network
addresses/prefixes that might be subject to related attacks. This addresses/prefixes that might be subject to related attacks. This
design helps to optimize the use of the DOTS signal channel for the design helps to optimize the use of the DOTS signal channel for the
small messages that are important to deliver during an attack. As a small messages that are important to deliver during an attack. As a
reminder, the DOTS signal channel and data channel both require reminder, both DOTS signal and data channels require secure
secure communication channels (Section 11 of [RFC9132] and Section 10 communication channels (Section 11 of [RFC9132] and Section 10 of
of [RFC8783]). [RFC8783]).
Telemetry information has aspects that correspond to both operational Telemetry information has aspects that correspond to both operational
modes (i.e., signal channel and data channel): there is certainly a modes (i.e., signal and data channels): there is certainly a need to
need to convey updated information about ongoing attack traffic and convey updated information about ongoing attack traffic and targets
targets during an attack, so as to convey detailed information about 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
toward potential targets to aid in detecting when incoming traffic towards potential targets to aid in detecting when incoming traffic
deviates from normal into being an attack. Also, one might populate deviates from normal into being an attack. Also, one might populate
a "database" of classifications of known types of attacks so that a a "database" of classifications of known types of attack so that a
short attack identifier can be used during an attack period to short attack identifier can be used during attack time to describe an
describe an observed attack. This specification does make provision observed attack. This specification does make provision for use of
for use of the DOTS data channel for the latter function the DOTS data channel for the latter function (Section 8.1.6), but
(Section 8.1.6) but otherwise retains most telemetry functionality in otherwise retains most telemetry functionality in the DOTS signal
the DOTS signal channel. channel.
Note that it is a functional requirement to convey information about Note that it is a functional requirement to convey information about
ongoing attack traffic during an attack, and information 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 expediency. traffic data is also sent over the signal channel, out of expediency.
This document specifies an extension to the DOTS signal channel 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
skipping to change at line 526 skipping to change at page 12, line 19
Once the DOTS signal channel is established, DOTS clients that 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 interval, pipe capacity, normal traffic baseline) as detailed in
Section 7. DOTS agents can then include DOTS telemetry attributes Section 7. DOTS agents can then include DOTS telemetry attributes
using the DOTS signal channel (Section 8.1). A DOTS client can use using the DOTS signal channel (Section 8.1). A DOTS client can use
separate messages to share with its DOTS server(s) a set of telemetry separate messages to share with its DOTS server(s) a set of telemetry
data bound to an ongoing mitigation (Section 8.2). Also, a DOTS data bound to an ongoing mitigation (Section 8.2). Also, a DOTS
client that is interested in receiving telemetry notifications client that is interested in receiving telemetry notifications
related to some of its resources follows the procedure defined in related to some of its resources follows the procedure defined in
Section 8.3. A DOTS client that receives such notifications can then Section 8.3. The DOTS client can then decide to send a mitigation
decide to send a mitigation request if an attack cannot be mitigated request if the notified attack cannot be mitigated locally within the
locally within the DOTS client domain. DOTS client domain.
Aggregate DOTS telemetry data can also be included in efficacy update Aggregate DOTS telemetry data can also be included in efficacy update
(Section 9.1) or mitigation update (Section 9.2) messages. (Section 9.1) or mitigation update (Section 9.2) messages.
4.2. Block-Wise Transfers 4.2. Block-wise Transfer
DOTS clients can use a block-wise transfer [RFC7959] with the DOTS clients can use block wise transfer [RFC7959] with the
recommendation detailed in Section 4.4.2 of [RFC9132] to control the recommendation detailed in Section 4.4.2 of [RFC9132] to control the
size of a response when the data to be returned does not fit within a size of a response when the data to be returned does not fit within a
single datagram. single datagram.
DOTS clients can also use the Constrained Application Protocol (CoAP) DOTS clients can also use CoAP Block1 Option in a PUT request
Block1 Option in a PUT request (Section 2.5 of [RFC7959]) to initiate (Section 2.5 of [RFC7959]) to initiate large transfers, but these
large transfers, but these Block1 transfers are likely to fail if the Block1 transfers are likely to fail if the inbound "pipe" is running
inbound "pipe" is running full because the transfer requires a full because the transfer requires a message from the server for each
message from the server for each block, which would likely be lost in block, which would likely be lost in the incoming flood.
the incoming flood. Consideration needs to be made to try to fit Consideration needs to be made to try to fit this PUT into a single
this PUT into a single transfer or to separate out the PUT into transfer or to separate out the PUT into several discrete PUTs where
several discrete PUTs where each of them fits into a single packet. each of them fits into a single packet.
Q-Block1 and Q-Block2 Options that are similar to the CoAP Block1 and Q-Block1 and Q-Block2 Options that are similar to the CoAP Block1 and
Block2 Options, but enable robust transmissions of big blocks of data Block2 Options, but enable robust transmissions of big blocks of data
with less packet interchanges using NON messages, are defined in with less packet interchanges using NON messages, are defined in
[RFC9177]. DOTS implementations can consider the use of Q-Block1 and [I-D.ietf-core-new-block]. DOTS implementations can consider the use
Q-Block2 Options [DOTS-Robust-Blocks]. of Q-Block1 and Q-Block2 Options [I-D.ietf-dots-robust-blocks].
4.3. DOTS Multihoming Considerations 4.3. DOTS Multi-homing Considerations
Considerations for multihomed DOTS clients to select which DOTS Considerations for multi-homed 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 message to a given peer DOTS server are discussed in
[DOTS-Multihoming]. For example, if each upstream network exposes a [I-D.ietf-dots-multihoming]. For example, if each upstream network
DOTS server and the DOTS client maintains DOTS channels with all of exposes a DOTS server and the DOTS client maintains DOTS channels
them, only the information related to prefixes assigned by an with all of them, only the information related to prefixes assigned
upstream network to the DOTS client domain will be signaled via the by an upstream network to the DOTS client domain will be signaled via
DOTS channel established with the DOTS server of that upstream the DOTS channel established with the DOTS server of that upstream
network. network.
Considerations related to whether (and how) a DOTS client gleans some Considerations related to whether (and how) a DOTS client gleans some
telemetry information (e.g., attack details) it receives from a first telemetry information (e.g., attack details) it receives from a first
DOTS server and shares it with a second DOTS server are DOTS server and share it with a second DOTS server are implementation
implementation and deployment specific. and deployment specific.
4.4. YANG Considerations 4.4. YANG Considerations
Telemetry messages exchanged between DOTS agents are serialized using Telemetry messages exchanged between DOTS agents are serialized using
Concise Binary Object Representation (CBOR) [RFC8949]. CBOR-encoded Concise Binary Object Representation (CBOR) [RFC8949]. CBOR-encoded
payloads are used to carry signal-channel-specific payload messages payloads are used to carry signal-channel-specific payload messages
that convey request parameters and response information such as which convey request parameters and response information such as
errors. errors.
This document specifies a YANG module [RFC7950] for representing DOTS This document specifies a YANG module [RFC7950] for representing DOTS
telemetry message types (Section 11.1). All parameters in the telemetry message types (Section 11.1). All parameters in the
payload of the DOTS signal channel are mapped to CBOR types as payload of the DOTS signal channel are mapped to CBOR types as
specified in Section 12. As a reminder, Section 3 of [RFC9132] specified in Section 12. As a reminder, Section 3 of [RFC9132]
defines the rules for mapping YANG-modeled data to CBOR. defines the rules for mapping YANG-modeled data to CBOR.
The DOTS telemetry module (Section 11.1) is not intended to be used The DOTS telemetry module (Section 11.1) is not intended to be used
via the Network Configuration Protocol (NETCONF) / RESTCONF for DOTS via NETCONF/RESTCONF for DOTS server management purposes. It serves
server management purposes. It serves only to provide a data model only to provide a data model and encoding following [RFC8791].
and encoding following [RFC8791]. Server deviations (Section 5.6.3 Server deviations (Section 5.6.3 of [RFC7950]) are strongly
of [RFC7950]) are strongly discouraged, as the peer DOTS agent does discouraged, as the peer DOTS agent does not have means to retrieve
not have the means to retrieve the list of deviations and thus the list of deviations and thus interoperability issues are likely to
interoperability issues are likely to be encountered. be encountered.
The DOTS telemetry module (Section 11.1) uses "enumerations" rather The DOTS telemetry module (Section 11.1) uses "enumerations" rather
than "identities" to define units, samples, and intervals because than "identities" to define units, samples, and intervals because
otherwise the namespace identifier "ietf-dots-telemetry" must be otherwise the namespace identifier "ietf-dots-telemetry" must be
included when a telemetry attribute is included (e.g., in a included when a telemetry attribute is included (e.g., in a
mitigation efficacy update). The use of "identities" is thus mitigation efficacy update). The use of "identities" is thus
suboptimal from the standpoint of message compactness, as message suboptimal from a message compactness standpoint; one of the key
compactness is one of the key requirements for DOTS signal channel requirements for DOTS Signal Channel messages.
messages.
The DOTS telemetry module (Section 11.1) includes some lists for The DOTS telemetry module (Section 11.1) includes some lists for
which no "key" statement is included. This behavior is compliant which no key statement is included. This behavior is compliant with
with [RFC8791]. The reason for not including these keys is that they [RFC8791]. The reason for not including these keys is because they
are not included in the message body of DOTS requests; such keys are are not included in the message body of DOTS requests; such keys are
included as mandatory Uri-Paths in requests (Sections 7 and 8). included as mandatory Uri-Paths in requests (Sections 7 and 8).
Otherwise, whenever a "key" statement is used in the module, the same Otherwise, whenever a key statement is used in the module, the same
definition as the definition provided in Section 7.8.2 of [RFC7950] definition as in Section 7.8.2 of [RFC7950] is assumed.
is assumed.
Some parameters (e.g., low-percentile values) may be associated with Some parameters (e.g., low percentile values) may be associated with
different YANG types (e.g., decimal64 and yang:gauge64). To easily different YANG types (e.g., decimal64 and yang:gauge64). To easily
distinguish the types of these parameters while using meaningful distinguish the types of these parameters while using meaningful
names, the following suffixes are used: names, the following suffixes are used:
+========+==============+==================+ +========+==============+==================+
| Suffix | YANG Type | Example | | Suffix | YANG Type | Example |
+========+==============+==================+ +========+==============+==================+
| -g | yang:gauge64 | low-percentile-g | | -g | yang:gauge64 | low-percentile-g |
+--------+--------------+------------------+ +--------+--------------+------------------+
| -c | container | connection-c | | -c | container | connection-c |
+--------+--------------+------------------+ +--------+--------------+------------------+
| -ps | per second | connection-ps | | -ps | per second | connection-ps |
+--------+--------------+------------------+ +--------+--------------+------------------+
Table 1: Suffixes and YANG Types Table 1
The full tree diagram of the DOTS telemetry module can be generated The full tree diagram of the DOTS telemetry module can be generated
using the "pyang" tool [PYANG]. That tree is not included here using the "pyang" tool [PYANG]. That tree is not included here
because it is too long (Section 3.3 of [RFC8340]). Instead, subtrees because it is too long (Section 3.3 of [RFC8340]). Instead, subtrees
are provided for the reader's convenience. are provided for the reader's convenience.
In order to optimize the data exchanged over the DOTS signal channel, In order to optimize the data exchanged over the DOTS signal channel,
this document specifies a second YANG module ("ietf-dots-mapping"; the document specifies a second YANG module ("ietf-dots-mapping",
see Section 11.2) that augments the DOTS data channel [RFC8783]. Section 11.2) that augments the DOTS data channel [RFC8783]. This
This augmentation can be used during 'idle' time to share the attack augmentation can be used during 'idle' time to share the attack
mapping details (Section 8.1.5). DOTS clients can use tools, e.g., mapping details (Section 8.1.5). DOTS clients can use tools, e.g.,
the YANG Library [RFC8525], to retrieve the list of features and YANG Library [RFC8525], to retrieve the list of features and
deviations supported by the DOTS server over the data channel. deviations supported by the DOTS server over the data channel.
5. Generic Considerations 5. Generic Considerations
5.1. DOTS Client Identification 5.1. DOTS Client Identification
Following the rules in Section 4.4.1 of [RFC9132], a unique Following the rules in Section 4.4.1 of [RFC9132], a unique
identifier is generated by a DOTS client to prevent request identifier is generated by a DOTS client to prevent request
collisions ('cuid'). collisions ('cuid').
As a reminder, Section 4.4.1.3 of [RFC9132] forbids 'cuid' to be As a reminder, [RFC9132] forbids 'cuid' to be returned in a response
returned in a response message body. message body.
5.2. DOTS Gateways 5.2. DOTS Gateways
DOTS gateways may be located between DOTS clients and servers. The DOTS gateways may be located between DOTS clients and servers. The
considerations elaborated in Section 4.4.1 of [RFC9132] must be considerations elaborated in Section 4.4.1 of [RFC9132] must be
followed. In particular, the 'cdid' attribute is used to followed. In particular, 'cdid' attribute is used to unambiguously
unambiguously identify a DOTS client domain. identify a DOTS client domain.
As a reminder, Section 4.4.1.3 of [RFC9132] forbids 'cdid' (if As a reminder, Section 4.4.1.3 of [RFC9132] forbids 'cdid' (if
present) to be returned in a response message body. present) to be returned in a response message body.
5.3. Uri-Path Parameters and Empty Values 5.3. Empty URI Paths
Uri-Path parameters and attributes with empty values MUST NOT be Uri-Path parameters and attributes with empty values MUST NOT be
present in a request. The presence of such an empty value renders present in a request. The presence of such an empty value renders
the entire containing message invalid. the entire containing message invalid.
5.4. Controlling Configuration Data 5.4. Controlling Configuration Data
The DOTS server follows the same considerations discussed in The DOTS server follows the same considerations discussed in
Section 4.5.3 of [RFC9132] for managing DOTS telemetry configuration Section of 4.5.3 of [RFC9132] for managing DOTS telemetry
freshness and notifications. configuration freshness and notification.
Likewise, a DOTS client may control the selection of configuration 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' (content) Uri-Query option and following the procedure of the 'c' Uri-Query option and following the procedure specified in
specified in Section 4.4.2 of [RFC9132]. These considerations are Section of 4.4.2 of [RFC9132]. These considerations are not
not reiterated in the following sections. reiterated in the following sections.
5.5. Message Validation 5.5. Message Validation
The authoritative references for validating telemetry messages The authoritative reference for validating telemetry messages
exchanged over the DOTS signal channel are Sections 7, 8, and 9 exchanged over the DOTS signal channel are Sections 7, 8, and 9
together with the mapping table provided in Section 12. The together with the mapping table established in Section 12. The
structure of telemetry message bodies is represented as a YANG data structure of telemetry message bodies is represented as a YANG data
structure (Section 11.1). structure (Section 11.1).
5.6. A Note about Examples 5.6. A Note About Examples
Examples are provided for illustration purposes. This document does Examples are provided for illustration purposes. The document does
not aim to provide a comprehensive list of message examples. not aim to provide a comprehensive list of message examples.
JSON encoding of YANG-modeled data is used to illustrate the various JSON encoding of YANG-modeled data is used to illustrate the various
telemetry operations. To ease readability, parameter names and their telemetry operations. To ease readability, parameter names and their
JSON types are thus used in the examples rather than their CBOR key JSON types are, thus, used in the examples rather than their CBOR key
values and CBOR types following the mappings in Section 12. These values and CBOR types following the mappings in Section 12. These
conventions are inherited from [RFC9132]. conventions are inherited from [RFC9132].
The examples use Enterprise Number 32473, which is defined for The examples use the Enterprise Number 32473 defined for
documentation use; see [RFC5612]. documentation use [RFC5612].
6. Telemetry Operation Paths 6. Telemetry Operation Paths
As discussed in Section 4.2 of [RFC9132], each DOTS operation is As discussed in Section 4.2 of [RFC9132], each DOTS operation is
indicated by a path suffix that indicates the intended operation. indicated by a path suffix that indicates the intended operation.
The operation path is appended to the path prefix to form the URI 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 used with a CoAP request to perform the desired DOTS operation. The
following telemetry path suffixes are defined (Table 2): following telemetry path suffixes are defined (Table 2):
+=================+================+===========+ +-----------------+----------------+-----------+
| Operation | Operation Path | Details | | Operation | Operation Path | Details |
+=================+================+===========+ +=================+================+===========+
| Telemetry Setup | /tm-setup | Section 7 | | Telemetry Setup | /tm-setup | Section 6 |
+-----------------+----------------+-----------+ | Telemetry | /tm | Section 7 |
| Telemetry | /tm | Section 8 | +-----------------+----------------+-----------+
+-----------------+----------------+-----------+
Table 2: DOTS Telemetry Operations Table 2: DOTS Telemetry Operations
Consequently, the "ietf-dots-telemetry" YANG module defined in Consequently, the "ietf-dots-telemetry" YANG module defined in
Section 11.1 defines a data structure to represent new DOTS message Section 11.1 defines data structure to represent new DOTS message
types called 'telemetry-setup' and 'telemetry'. The tree structure types called 'telemetry-setup' and 'telemetry'. The tree structure
is shown in Figure 1. More details are provided in Sections 7 and 8 is shown in Figure 1. More details are provided in Sections 7 and 8
about the exact structure of 'telemetry-setup' and 'telemetry' about the exact structure of 'telemetry-setup' and 'telemetry'
message types. message types.
structure dots-telemetry: structure dots-telemetry:
+-- (telemetry-message-type)? +-- (telemetry-message-type)?
+--:(telemetry-setup) +--:(telemetry-setup)
| ... | ...
| +-- telemetry* [] | +-- telemetry* []
skipping to change at line 752 skipping to change at page 17, line 13
... ...
Figure 1: New DOTS Message Types (YANG Tree Structure) Figure 1: New DOTS Message Types (YANG Tree Structure)
DOTS implementations MUST support the Observe Option [RFC7641] for DOTS implementations MUST support the Observe Option [RFC7641] for
'tm' (Section 8). 'tm' (Section 8).
7. DOTS Telemetry Setup Configuration 7. DOTS Telemetry Setup Configuration
In reference to Figure 1, a DOTS telemetry setup message MUST include In reference to Figure 1, a DOTS telemetry setup message MUST include
only telemetry-related configuration parameters (Section 7.1), only telemetry-related configuration parameters (Section 7.1) or
information about DOTS client domain pipe capacity (Section 7.2), or information about DOTS client domain pipe capacity (Section 7.2) or
information about the telemetry traffic baseline (Section 7.3). As telemetry traffic baseline (Section 7.3). As such, requests that
such, requests that include a mix of telemetry configuration, pipe include a mix of telemetry configuration, pipe capacity, and traffic
capacity, and traffic baseline information MUST be rejected by DOTS baseline MUST be rejected by DOTS servers with a 4.00 (Bad Request).
servers with a 4.00 (Bad Request) Response Code.
A DOTS client can reset all installed DOTS telemetry setup A DOTS client can reset all installed DOTS telemetry setup
configuration data following the considerations detailed in configuration data following the considerations detailed in
Section 7.4. Section 7.4.
A DOTS server may detect conflicts when processing requests related A DOTS server may detect conflicts when processing requests related
to DOTS client domain pipe capacity or telemetry traffic baseline to DOTS client domain pipe capacity or telemetry traffic baseline
information with requests from other DOTS clients of the same DOTS with requests from other DOTS clients of the same DOTS client domain.
client domain. More details are included in Section 7.5. More details are included in Section 7.5.
Telemetry setup configuration is bound to a DOTS client domain. DOTS Telemetry setup configuration is bound to a DOTS client domain. DOTS
servers MUST NOT expect DOTS clients to send regular requests to servers MUST NOT expect DOTS clients to send regular requests to
refresh the telemetry setup configuration. Any available telemetry refresh the telemetry setup configuration. Any available telemetry
setup configuration is valid until the DOTS server ceases to service setup configuration is valid till the DOTS server ceases to service a
a DOTS client domain. DOTS servers MUST NOT reset 'tsid' because a DOTS client domain. DOTS servers MUST NOT reset 'tsid' because a
session failed with a DOTS client. DOTS clients update their session failed with a DOTS client. DOTS clients update their
telemetry setup configuration upon change of a parameter that may telemetry setup configuration upon change of a parameter that may
impact attack mitigation. impact attack mitigation.
DOTS telemetry setup configuration request and response messages are DOTS telemetry setup configuration request and response messages are
marked as Confirmable messages (Section 2.1 of [RFC7252]). marked as Confirmable messages (Section 2.1 of [RFC7252]).
7.1. Telemetry Configuration 7.1. Telemetry Configuration
DOTS telemetry uses several percentile values to provide a picture of DOTS telemetry uses several percentile values to provide a picture of
a traffic distribution overall, as opposed to just a single snapshot a traffic distribution overall, as opposed to just a single snapshot
of observed traffic at a single point in time. Modeling raw traffic of observed traffic at a single point in time. Modeling raw traffic
flow data as a distribution and describing that distribution entails flow data as a distribution and describing that distribution entails
choosing a measurement period that the distribution will describe, choosing a measurement period that the distribution will describe,
and a number of sampling intervals, or "buckets", within that and a number of sampling intervals, or "buckets", within that
measurement period. Traffic within each bucket is treated as a measurement period. Traffic within each bucket is treated as a
single event (i.e., averaged), and then the distribution of buckets single event (i.e., averaged), and then the distribution of buckets
is used to describe the distribution of traffic over the measurement is 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 the value of the distribution at various percentile levels of the
data set in question (e.g., "quartiles" that correspond to 25th, data set in question (e.g., "quartiles" that correspond to 25th,
50th, and 75th percentiles). More details about percentile values 50th, and 75th percentile). More details about percentile values and
and their computation are found in Section 11.3 of [RFC2330]. their computation are found in Section 11.3 of [RFC2330].
DOTS telemetry uses up to three percentile values, plus the overall 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-percentile", "mid-percentile", and thresholds are used for these "low", "medium", and "high" percentile
"high-percentile" values is configurable. Default values are defined values is configurable. Default values are defined in Section 7.1.2.
in Section 7.1.2.
A DOTS client can negotiate with its server(s) a set of telemetry 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: include:
* Percentile-related measurement parameters. In particular, * Percentile-related measurement parameters. In particular,
'measurement-interval' defines the period during which percentiles 'measurement-interval' defines the period on which percentiles are
are computed, while 'measurement-sample' defines the time computed, while 'measurement-sample' defines the time distribution
distribution for measuring values that are used to compute for measuring values that are used to compute percentiles.
percentiles.
* Measurement units. * Measurement units
* Acceptable percentile values. * Acceptable percentile values
* Telemetry notification interval. * Telemetry notification interval
* Acceptable server-originated telemetry. * Acceptable Server-originated telemetry
7.1.1. Retrieving the Current DOTS Telemetry Configuration 7.1.1. Retrieve Current DOTS Telemetry Configuration
A GET request is used to obtain acceptable and current telemetry 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 a gateway) is gateway. An example of such a GET request (without gateway) is
depicted in Figure 2. depicted in Figure 2.
Header: GET (Code=0.01) 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"
Figure 2: GET to Retrieve the Current and Acceptable DOTS Telemetry Figure 2: GET to Retrieve Current and Acceptable DOTS Telemetry
Configuration Configuration
Upon receipt of such a request, and assuming that no error is Upon receipt of such a request, and assuming no error is encountered
encountered when processing the request, the DOTS server replies with when processing the request, the DOTS server replies with a 2.05
a 2.05 (Content) response that conveys the telemetry parameters that (Content) response that conveys the telemetry parameters that are
are acceptable to the DOTS server, any pipe information acceptable by the DOTS server, any pipe information (Section 7.2),
(Section 7.2), and the current baseline information (Section 7.3) and the current baseline information (Section 7.3) maintained by the
maintained by the DOTS server for this DOTS client. The tree DOTS server for this DOTS client. The tree structure of the response
structure of the response message body is provided in Figure 3. message body is provided in Figure 3.
DOTS servers that support the capability of sending telemetry DOTS servers that support the capability of sending telemetry
information to DOTS clients prior to or during a mitigation information to DOTS clients prior to or during a mitigation
(Section 9.2) set 'server-originated-telemetry' under 'max-config- (Section 9.2) sets 'server-originated-telemetry' under 'max-config-
values' to 'true' ('false' is used otherwise). If 'server- values' to 'true' ('false' is used otherwise). If 'server-
originated-telemetry' is not present in a response, this is originated-telemetry' is not present in a response, this is
equivalent to receiving a response with 'server-originated-telemetry' equivalent to receiving a response with 'server-originated-telemetry'
set to 'false'. set to 'false'.
structure dots-telemetry: structure dots-telemetry:
+-- (telemetry-message-type)? +-- (telemetry-message-type)?
+--:(telemetry-setup) +--:(telemetry-setup)
| +-- (direction)? | +-- (direction)?
| | +--:(server-to-client-only) | | +--:(server-to-client-only)
skipping to change at line 908 skipping to change at page 20, line 22
| | ... | | ...
| +--:(baseline) | +--:(baseline)
| ... | ...
+--:(telemetry) +--:(telemetry)
... ...
Figure 3: Telemetry Configuration Tree Structure Figure 3: Telemetry Configuration Tree Structure
When both 'min-config-values' and 'max-config-values' attributes are When both 'min-config-values' and 'max-config-values' attributes are
present, the values carried in 'max-config-values' attributes MUST be present, the values carried in 'max-config-values' attributes MUST be
greater than or equal to their counterparts in 'min-config-values' greater or equal to their counterpart in 'min-config-values'
attributes. attributes.
7.1.2. Conveying the DOTS Telemetry Configuration 7.1.2. Conveying DOTS Telemetry Configuration
A PUT request is used to convey the configuration parameters for the A PUT request is used to convey the configuration parameters for the
telemetry data (e.g., low-, mid-, or high-percentile values). For 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 the baseline for telemetry data. default percentile values used as baseline for telemetry data.
Figure 3 lists the attributes that can be set by a DOTS client in Figure 3 lists the attributes that can be set by a DOTS client in
such a PUT request. An example of a DOTS client that modifies all such a PUT request. An example of a DOTS client that modifies all
percentile reference values is shown in Figure 4. percentile reference values is shown in Figure 4.
| Note: The payload of the message depicted in Figure 4 is CBOR- Note: The payload of the message depicted in Figure 4 is CBOR-
| encoded as indicated by setting the Content-Format entry to encoded as indicated by the Content-Format set to "application/
| "application/dots+cbor" (Section 10.3 of [RFC9132]). However, dots+cbor" (Section 10.3 of [RFC9132]). However, and for the sake
| and for the sake of better readability, the example (and other of better readability, the example (and other similar figures
| similar figures depicting a DOTS telemetry message body) depicting a DOTS telemetry message body) follows the conventions
| follows the conventions set in Section 5.6: use the JSON names set in Section 5.6: use the JSON names and types defined in
| and types defined in Section 12. Section 12.
Header: PUT (Code=0.03) 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"
{ {
skipping to change at line 952 skipping to change at page 21, line 28
"low-percentile": "5.00", "low-percentile": "5.00",
"mid-percentile": "65.00", "mid-percentile": "65.00",
"high-percentile": "95.00" "high-percentile": "95.00"
} }
} }
] ]
} }
} }
Figure 4: PUT to Convey the DOTS Telemetry Configuration, Figure 4: PUT to Convey the DOTS Telemetry Configuration,
Depicted as per Section 5.6 depicted as per Section 5.6
'cuid' is a mandatory Uri-Path parameter for PUT requests. 'cuid' is a mandatory Uri-Path parameter for PUT requests.
The following additional Uri-Path parameter is defined: The following additional Uri-Path parameter is defined:
tsid: The Telemetry Setup Identifier is an identifier for the DOTS tsid: Telemetry Setup Identifier is an identifier for the DOTS
telemetry setup configuration data represented as an integer. telemetry setup configuration data represented as an integer.
This identifier MUST be generated by DOTS clients. 'tsid' values This identifier MUST be generated by DOTS clients. 'tsid'
MUST increase monotonically whenever new configuration parameters values MUST increase monotonically whenever new configuration
(not just for changed values) need to be conveyed by the DOTS parameters (not just for changed values) need to be conveyed by
client. the DOTS client.
The procedure specified in Section 4.4.1 of [RFC9132] for 'mid' The procedure specified in Section 4.4.1 of [RFC9132] for 'mid'
rollover MUST also be followed for 'tsid' rollover. rollover MUST also be followed for 'tsid' rollover.
This is a mandatory attribute. 'tsid' MUST appear after 'cuid' in This is a mandatory attribute. 'tsid' MUST appear after 'cuid'
the Uri-Path options. in the Uri-Path options.
'cuid' and 'tsid' MUST NOT appear in the PUT request message body. 'cuid' and 'tsid' MUST NOT appear in the PUT request message body.
At least one configurable attribute MUST be present in the PUT At least one configurable attribute MUST be present in the PUT
request. request.
A PUT request with a higher numeric 'tsid' value overrides the DOTS A PUT request with a higher numeric 'tsid' value overrides the DOTS
telemetry configuration data installed by a PUT request with a lower telemetry configuration data installed by a PUT request with a lower
numeric 'tsid' value. To avoid maintaining a long list of 'tsid' numeric 'tsid' value. To avoid maintaining a long list of 'tsid'
requests for requests carrying telemetry configuration data from a requests for requests carrying telemetry configuration data from a
DOTS client, the lower numeric 'tsid' MUST be automatically deleted DOTS client, the lower numeric 'tsid' MUST be automatically deleted
and no longer be available at the DOTS server. and no longer be available at the DOTS server.
The DOTS server indicates the result of processing the PUT request The DOTS server indicates the result of processing the PUT request
using the following Response Codes: using the following Response Codes:
* If the request is missing a mandatory attribute, does not include * If the request is missing a mandatory attribute, does not include
'cuid' or 'tsid' Uri-Path parameters, or contains one or more 'cuid' or 'tsid' Uri-Path parameters, or contains one or more
invalid or unknown parameters, a 4.00 (Bad Request) Response Code invalid or unknown parameters, 4.00 (Bad Request) MUST be returned
MUST be returned in the response. in the response.
* If the DOTS server does not find the 'tsid' parameter value * 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 2.01 DOTS server has accepted the configuration parameters, then a 2.01
(Created) Response Code MUST be returned in the response. (Created) Response Code MUST be returned in the response.
* If the DOTS server finds the 'tsid' parameter value conveyed in * If the DOTS server finds the 'tsid' parameter value conveyed in
the PUT request in its configuration data and if the DOTS server the PUT request in its configuration data and if the DOTS server
has accepted the updated configuration parameters, a 2.04 has accepted the updated configuration parameters, 2.04 (Changed)
(Changed) Response Code MUST be returned in the response. MUST be returned in the response.
* If any of the enclosed configurable attribute values are not * If any of the enclosed configurable attribute values are not
acceptable to the DOTS server (Section 7.1.1), a 4.22 acceptable to the DOTS server (Section 7.1.1), 4.22 (Unprocessable
(Unprocessable Entity) Response Code MUST be returned in the Entity) MUST be returned in the response.
response.
The DOTS client may retry and send the PUT request with updated The DOTS client may retry and send the PUT request with updated
attribute values acceptable to the DOTS server. attribute values acceptable to the DOTS server.
By default, low-percentile (10th percentile), mid-percentile (50th By default, low percentile (10th percentile), mid percentile (50th
percentile), high-percentile (90th percentile), and peak (100th percentile), high percentile (90th percentile), and peak (100th
percentile) values are used to represent telemetry data. 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 low- indicates that the DOTS client is not interested in receiving low-
percentiles. Likewise, setting 'mid-percentile' (or 'high- percentiles. Likewise, setting 'mid-percentile' (or 'high-
percentile') to the same value as 'low-percentile' (or 'mid- percentile') to the same value as 'low-percentile' (or 'mid-
percentile') indicates that the DOTS client is not interested in percentile') indicates that the DOTS client is not interested in
receiving mid-percentiles (or high-percentiles). For example, a DOTS receiving mid-percentiles (or high-percentiles). For example, a DOTS
client can send the request depicted in Figure 5 to inform the server client can send the request depicted in Figure 5 to inform the server
that it is interested in receiving only high-percentiles. This that it is interested in receiving only high-percentiles. This
assumes that the client will only use that percentile type when assumes that the client will only use that percentile type when
sharing telemetry data with the server. sharing telemetry data with the server.
skipping to change at line 1046 skipping to change at page 23, line 27
"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"
} }
} }
] ]
} }
} }
Figure 5: PUT to Disable Low- and Mid-Percentiles, Depicted as Figure 5: PUT to Disable Low- and Mid-Percentiles, depicted as
per Section 5.6 per Section 5.6
DOTS clients can also configure the unit class(es) to be used for 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 set of telemetry data. However, receipt of allowed for a given telemetry data. However, receipt of conflicting
conflicting values is treated as invalid parameters and rejected with values is treated as invalid parameters and rejected with 4.00 (Bad
a 4.00 (Bad Request) Response Code. Request).
DOTS clients that are interested in receiving pre-or-ongoing- DOTS clients that are interested to receive pre or ongoing mitigation
mitigation telemetry ('pre-or-ongoing-mitigation') information from a telemetry (pre-or-ongoing-mitigation) information from a DOTS server
DOTS server (Section 9.2) MUST set 'server-originated-telemetry' to (Section 9.2) MUST set 'server-originated-telemetry' to 'true'. If
'true'. If 'server-originated-telemetry' is not present in a PUT 'server-originated-telemetry' is not present in a PUT request, this
request, this is equivalent to receiving a request with 'server- is equivalent to receiving a request with 'server-originated-
originated-telemetry' set to 'false'. An example of a request to telemetry' set to 'false'. An example of a request to enable pre-or-
enable pre-or-ongoing-mitigation telemetry from DOTS servers is shown ongoing-mitigation telemetry from DOTS servers is shown in Figure 6.
in Figure 6.
Header: PUT (Code=0.03) 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"
{ {
skipping to change at line 1086 skipping to change at page 24, line 25
"telemetry": [ "telemetry": [
{ {
"current-config": { "current-config": {
"server-originated-telemetry": true "server-originated-telemetry": true
} }
} }
] ]
} }
} }
Figure 6: PUT to Enable Pre-or-Ongoing-Mitigation Telemetry from Figure 6: PUT to Enable Pre-or-ongoing-mitigation Telemetry from
the DOTS Server, Depicted as per Section 5.6 the DOTS server, depicted as per Section 5.6
7.1.3. Retrieving the Installed DOTS Telemetry Configuration 7.1.3. Retrieve Installed DOTS Telemetry Configuration
A DOTS client may issue a GET message with a 'tsid' Uri-Path A DOTS client may issue a GET message with 'tsid' Uri-Path parameter
parameter to retrieve the current DOTS telemetry configuration. An to retrieve the current DOTS telemetry configuration. An example of
example of such a request is depicted in Figure 7. such a request is depicted in Figure 7.
Header: GET (Code=0.01) 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" Uri-Path: "tsid=123"
Figure 7: GET to Retrieve the Current DOTS Telemetry Configuration Figure 7: GET to Retrieve Current DOTS Telemetry Configuration
If the DOTS server does not find the 'tsid' Uri-Path value conveyed If the DOTS server does not find the 'tsid' Uri-Path value conveyed
in the GET request in its configuration data for the requesting DOTS in the GET request in its configuration data for the requesting DOTS
client, it MUST respond with a 4.04 (Not Found) error Response Code. client, it MUST respond with a 4.04 (Not Found) error Response Code.
7.1.4. Deleting the DOTS Telemetry Configuration 7.1.4. Delete DOTS Telemetry Configuration
A DELETE request is used to delete the installed DOTS telemetry A DELETE request is used to delete the installed DOTS telemetry
configuration data (Figure 8). 'cuid' and 'tsid' are mandatory Uri- configuration data (Figure 8). 'cuid' and 'tsid' are mandatory Uri-
Path parameters for such DELETE requests. Path parameters for such DELETE requests.
Header: DELETE (Code=0.04) 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"
Figure 8: Deleting the Telemetry Configuration Figure 8: Delete Telemetry Configuration
The DOTS server resets the DOTS telemetry configuration back to the The DOTS server resets the DOTS telemetry configuration back to the
default values and acknowledges a DOTS client's request to remove the default values and acknowledges a DOTS client's request to remove the
DOTS telemetry configuration using a 2.02 (Deleted) Response Code. A DOTS telemetry configuration using 2.02 (Deleted) Response Code. A
2.02 (Deleted) Response Code is returned even if the 'tsid' parameter 2.02 (Deleted) Response Code is returned even if the 'tsid' parameter
value conveyed in the DELETE request does not exist in its value conveyed in the DELETE request does not exist in its
configuration data before the request. configuration data before the request.
Section 7.4 discusses the procedure to reset all DOTS telemetry setup Section 7.4 discusses the procedure to reset all DOTS telemetry setup
configuration data. configuration.
7.2. Total Pipe Capacity 7.2. Total Pipe Capacity
A DOTS client can communicate to the DOTS server(s) its DOTS client A DOTS client can communicate to the DOTS server(s) its DOTS client
domain pipe information. The tree structure of the pipe information domain pipe information. The tree structure of the pipe information
is shown in Figure 9. is shown in Figure 9.
structure dots-telemetry: structure dots-telemetry:
+-- (telemetry-message-type)? +-- (telemetry-message-type)?
+--:(telemetry-setup) +--:(telemetry-setup)
skipping to change at line 1162 skipping to change at page 26, line 28
| | +-- link-id nt:link-id | | +-- link-id nt:link-id
| | +-- capacity uint64 | | +-- capacity uint64
| | +-- unit unit | | +-- unit unit
| +--:(baseline) | +--:(baseline)
| ... | ...
+--:(telemetry) +--:(telemetry)
... ...
Figure 9: Pipe Tree Structure Figure 9: Pipe Tree Structure
A DOTS client domain pipe is defined as a list of limits on 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' [RFC8345]. Each of these links is identified with a 'link-id' [RFC8345].
The unit used by a DOTS client when conveying pipe information is 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 MUST auto-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. one. As such, only one unit per unit class is allowed.
7.2.1. Conveying DOTS Client Domain Pipe Capacity 7.2.1. Conveying DOTS Client Domain Pipe Capacity
Considerations similar to those specified in Section 7.1.2 are Similar considerations to those specified in Section 7.1.2 are
followed, with one exception: followed with one exception:
* The relative order of two PUT requests carrying DOTS client domain The relative order of two PUT requests carrying DOTS client domain
pipe attributes from a DOTS client is determined by comparing pipe attributes from a DOTS client is determined by comparing
their respective 'tsid' values. If these two requests have their respective 'tsid' values. If such two requests have
overlapping 'link-id' and 'unit' settings, the PUT request with a overlapping 'link-id' and 'unit', the PUT request with higher
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 numeric 'tsid' value. The overlapped lower numeric 'tsid' MUST be
automatically deleted and no longer be available. automatically deleted and no longer be available.
DOTS clients SHOULD minimize the number of active 'tsid's used for DOTS clients SHOULD minimize the number of active 'tsid's used for
pipe information. In order to avoid maintaining a long list of 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 RECOMMENDED that DOTS 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 regarding other links (already communicated using a the information of other links (already communicated using a lower
lower 'tsid' value). By doing so, this update request will override 'tsid' value). Doing so, this update request will override these
these existing requests and hence optimize the number of 'tsid' existing requests and hence optimize the number of 'tsid' request per
requests per DOTS client. DOTS client.
| Note: This assumes that all link information can fit in one * Note: This assumes that all link information can fit in one single
| single message. message.
As an example of configuring pipe information, a DOTS client managing As an example of configuring pipe information, a DOTS client managing
a single-homed domain (Figure 10) can send a PUT request (shown in a single homed domain (Figure 10) can send a PUT request (shown in
Figure 11) to communicate the capacity of "link1" used to connect to Figure 11) to communicate the capacity of "link1" used to connect to
its ISP. its ISP.
,--,--,--. ,--,--,--. ,--,--,--. ,--,--,--.
,-' `-. ,-' `-. ,-' `-. ,-' `-.
( DOTS Client )=====( ISP#A ) ( DOTS Client )=====( ISP#A )
`-. Domain ,-' link1 `-. ,-' `-. Domain ,-' link1 `-. ,-'
`--'--'--' `--'--'--' `--'--'--' `--'--'--'
Figure 10: Single-Homed DOTS Client Domain Figure 10: Single Homed DOTS Client Domain
Header: PUT (Code=0.03) 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"
{ {
skipping to change at line 1234 skipping to change at page 28, line 4
{ {
"link-id": "link1", "link-id": "link1",
"capacity": "500", "capacity": "500",
"unit": "megabit-ps" "unit": "megabit-ps"
} }
] ]
} }
] ]
} }
} }
Figure 11: Example of a PUT Request to Convey Pipe Information Figure 11: Example of a PUT Request to Convey Pipe Information
(Single-Homed), Depicted as per Section 5.6 (Single Homed), depicted as per Section 5.6
DOTS clients may be instructed to signal a link aggregate instead of DOTS clients may be instructed to signal a link aggregate instead of
individual links. For example, a DOTS client that manages a DOTS 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
(Figure 12) can send a PUT request (shown in Figure 13) to (Figure 12) can send a PUT request (shown in Figure 13) to
communicate the aggregate link capacity with its ISP. Signaling communicate the aggregate link capacity with its ISP. Signaling
individual or aggregate link capacity is deployment specific. individual or aggregate link capacity is deployment specific.
,--,--,--. ,--,--,--. ,--,--,--. ,--,--,--.
,-' `-.===== ,-' `-. ,-' `-.===== ,-' `-.
skipping to change at line 1278 skipping to change at page 28, line 47
"capacity": "700", "capacity": "700",
"unit": "megabit-ps" "unit": "megabit-ps"
} }
] ]
} }
] ]
} }
} }
Figure 13: Example of a PUT Request to Convey Pipe Information Figure 13: Example of a PUT Request to Convey Pipe Information
(Aggregated Link), Depicted as per Section 5.6 (Aggregated Link), depicted as per Section 5.6
Now consider that the DOTS client domain was upgraded to connect to Now consider that the DOTS client domain was upgraded to connect to
an additional ISP (e.g., ISP#B in Figure 14); the DOTS client can an additional ISP (e.g., ISP#B of Figure 14); the DOTS client can
inform a DOTS server that is not hosted with ISP#A and ISP#B domains inform a DOTS server that is not hosted with ISP#A and ISP#B domains
about this update by sending the PUT request depicted in Figure 15. about this update by sending the PUT request depicted in Figure 15.
This request also includes information related to "link1" even if This request also includes information related to "link1" even if
that link is not upgraded. Upon receipt of this request, the DOTS that link is not upgraded. Upon receipt of this request, the DOTS
server removes the request with 'tsid=126' and updates its server removes the request with 'tsid=126' and updates its
configuration base to maintain two links (link1 and link2). configuration base to maintain two links (link#1 and link#2).
,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
( ISP#B ) ( ISP#B )
`-. ,-' `-. ,-'
`--'--'--' `--'--'--'
|| ||
|| link2 || link2
,--,--,--. ,--,--,--. ,--,--,--. ,--,--,--.
,-' `-. ,-' `-. ,-' `-. ,-' `-.
( DOTS Client )=====( ISP#A ) ( DOTS Client )=====( ISP#A )
`-. Domain ,-' link1 `-. ,-' `-. Domain ,-' link1 `-. ,-'
`--'--'--' `--'--'--' `--'--'--' `--'--'--'
Figure 14: Multihomed DOTS Client Domain Figure 14: Multi-Homed DOTS Client Domain
Header: PUT (Code=0.03) 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"
{ {
skipping to change at line 1334 skipping to change at page 30, line 35
"capacity": "500", "capacity": "500",
"unit": "megabit-ps" "unit": "megabit-ps"
} }
] ]
} }
] ]
} }
} }
Figure 15: Example of a PUT Request to Convey Pipe Information Figure 15: Example of a PUT Request to Convey Pipe Information
(Multihomed), Depicted as per Section 5.6 (Multi-Homed), depicted as per Section 5.6
A DOTS client can delete a link by sending a PUT request with the 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. For example, if a DOTS client domain the same DOTS client domain (see Section 7.2.3 for other delete
re-homes (that is, it changes its ISP), the DOTS client can inform cases). For example, if a DOTS client domain re-homes (that is, it
its DOTS server about this update (e.g., from the network changes its ISP), the DOTS client can inform its DOTS server about
configuration in Figure 10 to the network configuration shown in this update (e.g., from the network configuration in Figure 10 to the
Figure 16) by sending the PUT request depicted in Figure 17. Upon one shown in Figure 16) by sending the PUT request depicted in
receipt of this request, and assuming that no error is encountered Figure 17. Upon receipt of this request, and assuming no error is
when processing the request, the DOTS server removes "link1" from its encountered when processing the request, the DOTS server removes
configuration bases for this DOTS client domain. Note that if the "link1" from its configuration bases for this DOTS client domain.
DOTS server receives a PUT request with a 'capacity' attribute set to Note that if the DOTS server receives a PUT request with a 'capacity'
"0" for all included links, it MUST reject the request with a 4.00 attribute set to "0" for all included links, it MUST reject the
(Bad Request) Response Code. Instead, the DOTS client can use a request with a 4.00 (Bad Request). Instead, the DOTS client can use
DELETE request to delete all links (Section 7.2.3). a DELETE request to delete all links (Section 7.2.3).
,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
( ISP#B ) ( ISP#B )
`-. ,-' `-. ,-'
`--'--'--' `--'--'--'
|| ||
|| link2 || link2
,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
( DOTS Client ) ( DOTS Client )
`-. Domain ,-' `-. Domain ,-'
`--'--'--' `--'--'--'
Figure 16: Multihomed DOTS Client Domain Figure 16: Multi-Homed DOTS Client Domain
Header: PUT (Code=0.03) 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"
{ {
skipping to change at line 1396 skipping to change at page 31, line 50
"capacity": "500", "capacity": "500",
"unit": "megabit-ps" "unit": "megabit-ps"
} }
] ]
} }
] ]
} }
} }
Figure 17: Example of a PUT Request to Convey Pipe Information Figure 17: Example of a PUT Request to Convey Pipe Information
(Multihomed), Depicted as per Section 5.6 (Multi-Homed), depicted as per Section 5.6
7.2.2. Retrieving Installed DOTS Client Domain Pipe Capacity 7.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity
A GET request with a 'tsid' Uri-Path parameter is used to retrieve A GET request with 'tsid' Uri-Path parameter is used to retrieve a
the specific information related to an installed DOTS client domain specific installed DOTS client domain pipe related information. The
pipe. The same procedure as that defined in Section 7.1.3 is same procedure as defined in Section 7.1.3 is followed.
followed.
To retrieve all pipe information bound to a DOTS client, the DOTS To retrieve all pipe information bound to a DOTS client, the DOTS
client proceeds as specified in Section 7.1.1. client proceeds as specified in Section 7.1.1.
7.2.3. Deleting Installed DOTS Client Domain Pipe Capacity 7.2.3. Delete Installed DOTS Client Domain Pipe Capacity
A DELETE request is used to delete the specific information related A DELETE request is used to delete the installed DOTS client domain
to an installed DOTS client domain pipe. The same procedure as that pipe related information. The same procedure as defined in
defined in Section 7.1.4 is followed. Section 7.1.4 is followed.
7.3. Telemetry Baseline 7.3. Telemetry Baseline
A DOTS client can communicate to its DOTS server(s) its normal A DOTS client can communicate to its DOTS server(s) its normal
traffic baseline and connection capacity: traffic baseline and connections capacity:
Total traffic normal baseline: Total traffic normal baseline data Total traffic normal baseline: The percentile values representing
provides the percentile values representing the total traffic the total traffic normal baseline. It can be represented for a
normal baseline. It can be represented for a target using 'total- target using 'total-traffic-normal'.
traffic-normal'.
The traffic normal per-protocol ('total-traffic-normal-per- The traffic normal per-protocol ('total-traffic-normal-per-
protocol') baseline is represented for a target and is transport- protocol') baseline is represented for a target and is transport-
protocol specific. protocol specific.
The traffic normal per-port-number ('total-traffic-normal-per- The traffic normal per-port-number ('total-traffic-normal-per-
port') baseline is represented for each port number bound to a port') baseline is represented for each port number bound to a
target. target.
If the DOTS client negotiated percentile values and units If the DOTS client negotiated percentile values and units
(Section 7.1), these negotiated parameters will be used instead of (Section 7.1), these negotiated parameters will be used instead of
the default parameters. For each unit class used, the DOTS client the default ones. For each used unit class, the DOTS client MUST
MUST auto-scale so that the appropriate unit is used. auto-scale so that the appropriate unit is used.
Total connection capacity: If the target is susceptible to resource- Total connections capacity: If the target is susceptible to
consuming DDoS attacks, the following optional attributes for the resource-consuming DDoS attacks, the following optional attributes
target per transport protocol are useful for detecting resource- for the target per transport protocol are useful to detect
consuming DDoS attacks: resource-consuming DDoS attacks:
* The maximum number of simultaneous connections that are allowed * The maximum number of simultaneous connections that are allowed
to the target. to the target.
* The maximum number of simultaneous connections that are allowed * The maximum number of simultaneous connections that are allowed
to the target per client. to the target per client.
* The maximum number of simultaneous embryonic connections that * The maximum number of simultaneous embryonic connections that
are allowed to the target. The term "embryonic connection" are allowed to the target. The term "embryonic connection"
refers to a connection whose connection handshake is not refers to a connection whose connection handshake is not
finished. Embryonic connections are only possible in finished. Embryonic connection is only possible in connection-
connection-oriented transport protocols like TCP or the Stream oriented transport protocols like TCP or Stream Control
Control Transmission Protocol (SCTP) [RFC9260]. Transmission Protocol (SCTP) [RFC4960].
* The maximum number of simultaneous embryonic connections that * The maximum number of simultaneous embryonic connections that
are allowed to the target per client. are allowed to the target per client.
* The maximum number of connections allowed per second to the * The maximum number of connections allowed per second to the
target. target.
* The maximum number of connections allowed per second to the * The maximum number of connections allowed per second to the
target per client. target per client.
* The maximum number of requests (e.g., HTTP/DNS/SIP requests) * The maximum number of requests (e.g., HTTP/DNS/SIP requests)
allowed per second to the target. allowed per second to the target.
* The maximum number of requests allowed per second to the target * The maximum number of requests allowed per second to the target
per client. per client.
* The maximum number of outstanding partial requests allowed to * The maximum number of outstanding partial requests allowed to
the target. Attacks relying upon partial requests create a 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., an HTTP request). (e.g., HTTP request).
* The maximum number of outstanding partial requests allowed to * The maximum number of outstanding partial requests allowed to
the target per client. the target per client.
The aggregate per transport protocol is captured in 'total- The aggregate per transport protocol is captured in 'total-
connection-capacity', while port-specific capabilities are connection-capacity', while port-specific capabilities are
represented using 'total-connection-capacity-per-port'. represented using 'total-connection-capacity-per-port'.
Note that a target resource is identified using the attributes 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' as defined in Section 4.4.1.1 of fqdn', 'target-uri', or 'alias-name' defined in Section 4.4.1.1 of
[RFC9132]. [RFC9132].
The tree structure of the normal traffic baseline is shown in The tree structure of the normal traffic baseline is shown in
Figure 18. Figure 18.
structure dots-telemetry: 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 uint32 | +-- id
| | 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 1572 skipping to change at page 35, line 33
| +-- 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)
... ...
Figure 18: Telemetry Baseline Tree Structure Figure 18: Telemetry Baseline Tree Structure
A DOTS client can share one or multiple normal traffic baselines A DOTS client can share one or multiple normal traffic baselines
(e.g., aggregate or per-prefix baselines); each is uniquely (e.g., aggregate or per-prefix baselines), each are uniquely
identified within the DOTS client domain with an identifier ('id'). identified within the DOTS client domain with an identifier 'id'.
This identifier can be used to update a baseline entry, delete a This identifier can be used to update a baseline entry, delete a
specific entry, etc. specific entry, etc.
7.3.1. Conveying DOTS Client Domain Baseline Information 7.3.1. Conveying DOTS Client Domain Baseline Information
Considerations similar to those specified in Section 7.1.2 are Similar considerations to those specified in Section 7.1.2 are
followed, with one exception: followed with one exception:
* The relative order of two PUT requests carrying DOTS client domain The relative order of two PUT requests carrying DOTS client domain
baseline attributes from a DOTS client is determined by comparing baseline attributes from a DOTS client is determined by comparing
their respective 'tsid' values. If these two requests have their respective 'tsid' values. If such two requests have
overlapping targets, the PUT request with a higher numeric 'tsid' overlapping targets, the PUT request with higher numeric 'tsid'
value will override the request with a lower numeric 'tsid' value. value will override the request with a lower numeric 'tsid' value.
The overlapped lower numeric 'tsid' MUST be automatically deleted The overlapped lower numeric 'tsid' MUST be automatically deleted
and no longer be available. and no longer be available.
Two PUT requests from a DOTS client have overlapping targets if there Two PUT requests from a DOTS client have overlapping targets if there
is a common IP address, IP prefix, FQDN, URI, or alias name. Also, is a common IP address, IP prefix, FQDN, URI, or alias-name. Also,
two PUT requests from a DOTS client have overlapping targets from the two PUT requests from a DOTS client have overlapping targets from the
perspective of the DOTS server if the addresses associated with the perspective of the DOTS server if the addresses associated with the
FQDN, URI, or alias are overlapping with each other or with 'target- FQDN, URI, or alias are overlapping with each other or with 'target-
prefix'. prefix'.
DOTS clients SHOULD minimize the number of active 'tsid's used for DOTS clients SHOULD minimize the number of active 'tsid's used for
baseline information. In order to avoid maintaining a long list of baseline information. In order to avoid maintaining a long list of
'tsid's for baseline information, it is RECOMMENDED that DOTS clients 'tsid's for baseline information, it is RECOMMENDED that DOTS clients
include in any request to update information related to a given include in a request to update information related to a given target,
target the information regarding other targets (already communicated the information of other targets (already communicated using a lower
using a lower 'tsid' value) (assuming that this information fits 'tsid' value) (assuming this fits within one single datagram). This
within one single datagram). This update request will override these update request will override these existing requests and hence
existing requests and hence optimize the number of 'tsid' requests optimize the number of 'tsid' request per DOTS client.
per DOTS client.
If no target attribute is included in the request, this is an 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. domain as a whole.
An example of a PUT request to convey the baseline information is An example of a PUT request to convey the baseline information is
shown in Figure 19. shown in Figure 19.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
skipping to change at line 1646 skipping to change at page 37, line 37
"peak-g": "60" "peak-g": "60"
} }
] ]
} }
] ]
} }
] ]
} }
} }
Figure 19: PUT to Convey DOTS Traffic Baseline Information, Figure 19: PUT to Conveying the DOTS Traffic Baseline, depicted
Depicted as per Section 5.6 as per Section 5.6
The DOTS client may share protocol-specific baseline information The DOTS client may share protocol specific baseline information
(e.g., TCP and UDP) as shown in Figure 20. (e.g., TCP and UDP) as shown in Figure 20.
Header: PUT (Code=0.03) 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"
skipping to change at line 1690 skipping to change at page 38, line 43
"peak-g": "10" "peak-g": "10"
} }
] ]
} }
] ]
} }
] ]
} }
} }
Figure 20: PUT to Convey DOTS Traffic Baseline Information (2), Figure 20: PUT to Convey the DOTS Traffic Baseline (2), depicted
Depicted as per Section 5.6 as per Section 5.6
The normal traffic baseline information should be updated to reflect The normal traffic baseline information should be updated to reflect
legitimate overloads (e.g., flash crowds) to prevent unnecessary legitimate overloads (e.g., flash crowds) to prevent unnecessary
mitigation. mitigation.
7.3.2. Retrieving Installed Normal Traffic Baseline Information 7.3.2. Retrieve Installed Normal Traffic Baseline
A GET request with a 'tsid' Uri-Path parameter is used to retrieve a A GET request with 'tsid' Uri-Path parameter is used to retrieve a
specific installed DOTS client domain's baseline traffic information. specific installed DOTS client domain baseline traffic information.
The same procedure as that defined in Section 7.1.3 is followed. The same procedure as defined in Section 7.1.3 is followed.
To retrieve all baseline information bound to a DOTS client, the DOTS To retrieve all baseline information bound to a DOTS client, the DOTS
client proceeds as specified in Section 7.1.1. client proceeds as specified in Section 7.1.1.
7.3.3. Deleting Installed Normal Traffic Baseline Information 7.3.3. Delete Installed Normal Traffic Baseline
A DELETE request is used to delete the installed DOTS client domain's A DELETE request is used to delete the installed DOTS client domain
normal traffic baseline information. The same procedure as that normal traffic baseline. The same procedure as defined in
defined in Section 7.1.4 is followed. Section 7.1.4 is followed.
7.4. Resetting the Installed Telemetry Setup 7.4. Reset Installed Telemetry Setup
Upon bootstrapping (or reboot or any other event that may alter the 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 DOTS client setup), a DOTS client MAY send a DELETE request to set
the telemetry parameters to default values. Such a request does not the telemetry parameters to default values. Such a request does not
include any 'tsid' parameters. An example of such a request is include any 'tsid'. An example of such a request is depicted in
depicted in Figure 21. Figure 21.
Header: DELETE (Code=0.04) 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"
Figure 21: Deleting the Telemetry Configuration Figure 21: Delete Telemetry Configuration
7.5. Conflict with Other DOTS Clients of the Same Domain 7.5. Conflict with Other DOTS Clients of the Same Domain
A DOTS server may detect conflicts between requests conveying pipe 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. 'conflict-information' is used to report the conflict
to the DOTS client, following guidelines for conflict handling to the DOTS client following similar conflict handling discussed in
similar to those discussed in Section 4.4.1 of [RFC9132]. The Section 4.4.1 of [RFC9132]. The conflict cause can be set to one of
conflict cause can be set to one of these values: these values:
1: Overlapping targets (Section 4.4.1 of [RFC9132]). 1: Overlapping targets (Section 4.4.1 of [RFC9132]).
5: Overlapping pipe scope (see Section 13). TBA: Overlapping pipe scope (see Section 13).
8. DOTS Pre-or-Ongoing-Mitigation Telemetry 8. DOTS Pre-or-Ongoing Mitigation Telemetry
There are two broad types of DDoS attacks: bandwidth-consuming There are two broad types of DDoS attacks: one is a bandwidth
attacks and target-resource-consuming attacks. This section outlines consuming attack, the other is a target-resource-consuming attack.
the set of DOTS telemetry attributes (Section 8.1) that covers both This section outlines the set of DOTS telemetry attributes
types of attacks. The objective of these attributes is to allow for (Section 8.1) that covers both types of attack. The objective of
the complete knowledge of attacks and the various particulars that these attributes is to allow for the complete knowledge of attacks
can best characterize attacks. and the various particulars that can best characterize attacks.
The "ietf-dots-telemetry" YANG module (Section 11.1) defines the data The "ietf-dots-telemetry" YANG module (Section 11.1) defines the data
structure of a new message type called 'telemetry'. The tree structure of a new message type called 'telemetry'. The tree
structure of the 'telemetry' message type is shown in Figure 22. structure of the 'telemetry' message type is shown in Figure 24.
The pre-or-ongoing-mitigation telemetry attributes are indicated by
the path suffix '/tm'. The '/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 specified in
Section 8.1 can be signaled between DOTS agents.
Pre-or-ongoing-mitigation telemetry attributes may be sent by a DOTS
client or a DOTS server.
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 Figure 22. An example illustrating request correlation by
means of 'target-prefix' is shown in Figure 23.
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 Section 7.1.2. When generating telemetry data to send
to a peer, the DOTS agent MUST auto-scale so that appropriate unit(s)
are used.
+-----------+ +-----------+
|DOTS client| |DOTS server|
+-----------+ +-----------+
| |
|===============Mitigation Request (mid)===============>|
| |
|===============Telemetry (mid-list{mid})==============>|
| |
Figure 22: Example of Request Correlation using 'mid'
+-----------+ +-----------+
|DOTS client| |DOTS server|
+-----------+ +-----------+
| |
|<================Telemetry (target-prefix)=============|
| |
|=========Mitigation Request (target-prefix)===========>|
| |
Figure 23: Example of Request Correlation using Target Prefix
DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry
notifications to the same peer more frequently than once every
'telemetry-notify-interval' (Section 7.1). If a telemetry
notification is sent using a block-like transfer mechanism (e.g.,
[I-D.ietf-core-new-block]), this rate limit policy MUST NOT consider
these individual blocks as separate notifications, but as a single
notification.
DOTS pre-or-ongoing-mitigation telemetry request and response
messages MUST be marked as Non-Confirmable messages (Section 2.1 of
[RFC7252]).
structure dots-telemetry: 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)?
skipping to change at line 1795 skipping to change at page 42, line 46
| ... | ...
+-- 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]
... ...
Figure 22: Telemetry Message Type Tree Structure Figure 24: Telemetry Message Type Tree Structure
The pre-or-ongoing-mitigation telemetry attributes are indicated by
the path suffix '/tm'. '/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
Section 8.1 can be signaled between DOTS agents.
Pre-or-ongoing-mitigation telemetry attributes may be sent by a DOTS
client or a DOTS server.
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 Figure 23. An example illustrating request correlation by
means of 'target-prefix' is shown in Figure 24.
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 Section 7.1.2. When generating telemetry data to send
to a peer, the DOTS agent MUST auto-scale so that one or more
appropriate units are used.
+-----------+ +-----------+
|DOTS client| |DOTS server|
+-----------+ +-----------+
| |
|==============Mitigation Request (mid)==============>|
| |
|==============Telemetry (mid-list{mid})=============>|
| |
Figure 23: Example of Request Correlation Using 'mid'
+-----------+ +-----------+
|DOTS client| |DOTS server|
+-----------+ +-----------+
| |
|<===============Telemetry (target-prefix)============|
| |
|========Mitigation Request (target-prefix)==========>|
| |
Figure 24: Example of Request Correlation Using 'target-prefix'
DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry
notifications to the same peer more frequently than once every
'telemetry-notify-interval' (Section 7.1). If a telemetry
notification is sent using a block-like transfer mechanism (e.g.,
[RFC9177]), this rate-limit policy MUST NOT consider these individual
blocks as separate notifications, but as a single notification.
DOTS pre-or-ongoing-mitigation telemetry request and response
messages MUST be marked as Non-confirmable messages (Section 2.1 of
[RFC7252]).
8.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes 8.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes
Section 3 discusses the motivation for using the DOTS telemetry The description and motivation behind each attribute are presented in
attributes. These attributes are specified in the following Section 3.
subsections.
8.1.1. Target 8.1.1. Target
A target resource (Figure 25) is identified using the attributes A target resource (Figure 25) is identified using the attributes
'target-prefix', 'target-port-range', 'target-protocol', 'target- 'target-prefix', 'target-port-range', 'target-protocol', 'target-
fqdn', 'target-uri', 'alias-name', or a pointer to a mitigation fqdn', 'target-uri', 'alias-name', or a pointer to a mitigation
request ('mid-list'). request ('mid-list').
+--:(telemetry) +--:(telemetry)
+-- pre-or-ongoing-mitigation* [] +-- pre-or-ongoing-mitigation* []
skipping to change at line 1927 skipping to change at page 44, line 27
The 'total-traffic' attribute (Figure 26) conveys the percentile The 'total-traffic' attribute (Figure 26) conveys the percentile
values (including peak and current observed values) of the total values (including peak and current observed values) of the total
observed traffic. More fine-grained information about the total observed traffic. More fine-grained information about the total
traffic can be conveyed in the 'total-traffic-protocol' and 'total- traffic can be conveyed in the 'total-traffic-protocol' and 'total-
traffic-port' attributes. traffic-port' attributes.
The 'total-traffic-protocol' attribute represents the total traffic The 'total-traffic-protocol' attribute represents the total traffic
for a target and is transport-protocol specific. for a target and is transport-protocol specific.
The 'total-traffic-port' attribute represents the total traffic for a The 'total-traffic-port' represents the total traffic for a target
target per port number. per port number.
+--:(telemetry) +--:(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
skipping to change at line 2043 skipping to change at page 48, line 15
8.1.4. Total Attack Connections 8.1.4. Total Attack Connections
If the target is susceptible to resource-consuming DDoS attacks, the 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) of percentile values (including peak and current observed values) of
various attributes related to the total attack connections. The 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: protocol are included to represent the attack characteristics:
* The number of simultaneous attack connections to the target. * The number of simultaneous attack connections to the target.
* The number of simultaneous embryonic connections to the target. * The number of simultaneous embryonic connections to the target.
* The number of attack connections per second to the target. * The number of attack connections per second to the target.
* The number of attack requests per second to the target. * The number of attack requests per second to the target.
* The number of attack partial requests to the target. * The number of attack partial requests to the target.
The total attack connections per port number are represented using The total attack connections per port number is represented using the
the 'total-attack-connection-port' attribute. 'total-attack-connection-port' attribute.
+--:(telemetry) +--:(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]
| ... | ...
skipping to change at line 2148 skipping to change at page 50, line 19
| +-- current-g? yang:gauge64 | +-- current-g? yang:gauge64
+-- attack-detail* [vendor-id attack-id] +-- attack-detail* [vendor-id attack-id]
... ...
Figure 28: Total Attack Connections Tree Structure Figure 28: Total Attack Connections Tree Structure
8.1.5. Attack Details 8.1.5. Attack Details
This attribute (depicted in Figure 29) is used to signal a set of This attribute (depicted in Figure 29) is used to signal a set of
details characterizing an attack. The following sub-attributes details characterizing an attack. The following sub-attributes
describing the ongoing attack can be signaled as attack details: describing the ongoing attack can be signalled as attack details:
vendor-id: Vendor ID. This parameter represents a security vendor's vendor-id: Vendor ID is a security vendor's enterprise number as
enterprise number as registered in the IANA "Private Enterprise registered in the IANA's "Private Enterprise Numbers" registry
Numbers" registry [Private-Enterprise-Numbers]. [Private-Enterprise-Numbers].
attack-id: Unique identifier assigned for the attack by a vendor. attack-id: Unique identifier assigned for the attack by a vendor.
This parameter MUST be present, independently of whether 'attack- This parameter MUST be present independent of whether 'attack-
description' is included or not. description' is included or not.
description-lang: Indicates the language tag that is used for the description-lang: Indicates the language tag that is used for the
text that is included in the 'attack-description' attribute. This text that is included in the 'attack-description' attribute. The
attribute is encoded following the rules in Section 2.1 of attribute is encoded following the rules in Section 2.1 of
[RFC5646]. The default language tag is "en-US". [RFC5646]. The default language tag is "en-US".
attack-description: Textual representation of the attack attack-description: 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 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 an attack solves two problems: it avoids Textual representation of attack solves two problems: (a) avoids
the need to (a) create mapping tables manually between vendors and the need to create mapping tables manually between vendors and (b)
(b) standardize attack types that keep evolving. avoids the need to standardize attack types which keep evolving.
attack-severity: Attack severity level. This attribute takes one of attack-severity: Attack severity level. This attribute takes one of
the values defined in Section 3.12.2 of [RFC7970]. the values defined in Section 3.12.2 of [RFC7970].
start-time: The time the attack started. The attack's start time is start-time: The time the attack started. The attack's start time is
expressed in seconds relative to 1970-01-01T00:00Z (Section 3.4.2 expressed in seconds relative to 1970-01-01T00:00Z (Section 3.4.2
of [RFC8949]). The CBOR encoding is modified so that the leading of [RFC8949]). The CBOR encoding is modified so that the leading
tag 1 (epoch-based date/time) MUST be omitted. tag 1 (epoch-based date/time) MUST be omitted.
end-time: The time the attack ended. The attack's end time is end-time: The time the attack ended. The attack end time is
expressed in seconds relative to 1970-01-01T00:00Z (Section 3.4.2 expressed in seconds relative to 1970-01-01T00:00Z (Section 3.4.2
of [RFC8949]). The CBOR encoding is modified so that the leading of [RFC8949]). The CBOR encoding is modified so that the leading
tag 1 (epoch-based date/time) MUST be omitted. tag 1 (epoch-based date/time) MUST be omitted.
source-count: A count of sources involved in the attack targeting source-count: A count of sources involved in the attack targeting
the victim. the victim.
top-talker: A list of attack sources that are involved in an attack top-talker: A list of attack sources that are involved in an attack
and that are generating an important part of the attack traffic. and which are generating an important part of the attack traffic.
The top talkers are represented using 'source-prefix'. The top talkers are represented using the 'source-prefix'.
'spoofed-status' indicates whether a top talker is a spoofed IP 'spoofed-status' indicates whether a top talker is a spoofed IP
address (e.g., reflection attacks) or not. If no 'spoofed-status' address (e.g., reflection attacks) or not. If no 'spoofed-status'
data node is included, this means that the spoofing status is data node is included, this means that the spoofing status is
unknown. unknown.
If the target is being subjected to a bandwidth-consuming attack, If the target is being subjected to a bandwidth-consuming attack,
a statistical profile of the attack traffic from each of the top a statistical profile of the attack traffic from each of the top
talkers is included ('total-attack-traffic'; see Section 8.1.3). talkers is included ('total-attack-traffic', Section 8.1.3).
If the target is being subjected to a resource-consuming DDoS If the target is being subjected to a resource-consuming DDoS
attack, the same attributes as those defined in Section 8.1.4 are attack, the same attributes defined in Section 8.1.4 are
applicable for characterizing the attack on a per-talker basis. applicable for characterizing the attack on a per-talker basis.
+--:(telemetry) +--:(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]
skipping to change at line 2293 skipping to change at page 53, line 20
| +-- 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
Figure 29: Attack Details Tree Structure Figure 29: Attack Detail Tree Structure
In order to optimize the size of telemetry data conveyed over the In order to optimize the size of telemetry data conveyed over the
DOTS signal channel, DOTS agents MAY use the DOTS data channel DOTS signal channel, DOTS agents MAY use the DOTS data channel
[RFC8783] to exchange vendor-specific attack mapping details (that [RFC8783] to exchange vendor specific attack mapping details (that
is, {vendor identifier, attack identifier} ==> textual representation is, {vendor identifier, attack identifier} ==> textual representation
of the attack description). As such, DOTS agents do not have to of the attack description). As such, DOTS agents do not have to
convey an attack description systematically in their telemetry convey systematically an attack description in their telemetry
messages over the DOTS signal channel. Refer to Section 8.1.6. messages over the DOTS signal channel. Refer to Section 8.1.6.
8.1.6. Vendor Attack Mapping 8.1.6. Vendor Attack Mapping
Multiple mappings for different vendor identifiers may be used; the Multiple mappings for different vendor identifiers may be used; the
DOTS agent transmitting telemetry information can elect to use one or DOTS agent transmitting telemetry information can elect to use one or
more vendor mappings even in the same telemetry message. more vendor mappings even in the same telemetry message.
| 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
| multiple DOTS mitigators, each from a different vendor. How DOTS mitigators; each from a different vendor. How telemetry
| telemetry information and vendor mappings are exchanged between information and vendor mappings are exchanged between DOTS servers
| DOTS servers and DOTS mitigators is outside the scope of this and DOTS mitigators is outside the scope of this document.
| document.
DOTS clients and servers may be provided with mappings from different DOTS clients and servers may be provided with mappings from different
vendors and so have their own different sets of vendor attack vendors and so have their own different sets of vendor attack
mappings. A DOTS agent MUST accept receipt of telemetry data with a mappings. A DOTS agent MUST accept receipt of telemetry data with a
vendor identifier that is different than the identifier it uses to vendor identifier that is different to the one it uses to transmit
transmit telemetry data. Furthermore, it is possible that the DOTS telemetry data. Furthermore, it is possible that the DOTS client and
client and DOTS server are provided by the same vendor but the vendor DOTS server are provided by the same vendor, but the vendor mapping
mapping tables are at different revisions. The DOTS client SHOULD tables are at different revisions. The DOTS client SHOULD transmit
transmit telemetry information using any vendor mapping(s) that it telemetry information using any vendor mapping(s) that it provided to
provided to the DOTS server (e.g., using a POST as depicted in the DOTS server (e.g., using a POST as depicted in Figure 34) and the
Figure 30), and the DOTS server SHOULD use any vendor mappings(s) DOTS server SHOULD use any vendor mappings(s) provided to the DOTS
provided to the DOTS client when transmitting telemetry data to the client when transmitting telemetry data to the peer DOTS agent.
peer DOTS agent.
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"
}
]
}
]
}
}
Figure 30: POST to Install Vendor Attack Mapping Details
The "ietf-dots-mapping" YANG module defined in Section 11.2 augments The "ietf-dots-mapping" YANG module defined in Section 11.2 augments
the "ietf-dots-data-channel" module [RFC8783]. The tree structure of the "ietf-dots-data-channel" [RFC8783] module. The tree structure of
the "ietf-dots-mapping" module is shown in Figure 31. the "ietf-dots-mapping" module is shown in Figure 30.
module: ietf-dots-mapping 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]
skipping to change at line 2387 skipping to change at page 54, line 33
+--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
Figure 31: Vendor Attack Mapping Tree Structure Figure 30: Vendor Attack Mapping Tree Structure
A DOTS client sends a GET request over the DOTS data channel to A DOTS client sends a GET request over the DOTS data channel to
retrieve the capabilities supported by a DOTS server as per retrieve the capabilities supported by a DOTS server as per
Section 7.1 of [RFC8783]. This request is meant to assess whether Section 7.1 of [RFC8783]. This request is meant to assess whether
the capability of sharing vendor attack mapping details is supported the capability of sharing vendor attack mapping details is supported
by the server (i.e., check the value of 'vendor-mapping-enabled'). by the server (i.e., check the value of 'vendor-mapping-enabled').
If 'vendor-mapping-enabled' is set to 'true', a DOTS client MAY send If 'vendor-mapping-enabled' is set to 'true', a DOTS client MAY send
a GET request to retrieve the DOTS server's vendor attack mapping a GET request to retrieve the DOTS server's vendor attack mapping
details. An example of such a GET request is shown in Figure 32. details. An example of such a GET request is shown in Figure 31.
GET /restconf/data/ietf-dots-data-channel:dots-data\ GET /restconf/data/ietf-dots-data-channel:dots-data\
/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
Figure 32: GET to Retrieve the Vendor Attack Mappings of a DOTS Figure 31: GET to Retrieve the Vendor Attack Mappings of a DOTS
Server Server
A DOTS client can retrieve only the list of vendors supported by the A DOTS client can retrieve only the list of vendors supported by the
DOTS server. It does so by setting the "depth" parameter DOTS server. It does so by setting the "depth" parameter
(Section 4.8.2 of [RFC8040]) to "3" in the GET request as shown in (Section 4.8.2 of [RFC8040]) to "3" in the GET request as shown in
Figure 33. An example of a response body received from the DOTS Figure 32. An example of a response body received from the DOTS
server as a response to such a request is illustrated in Figure 34. server as a response to such a request is illustrated in Figure 33.
GET /restconf/data/ietf-dots-data-channel:dots-data\ GET /restconf/data/ietf-dots-data-channel:dots-data\
/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
Figure 33: GET to Retrieve the Vendors List Used by a DOTS Server Figure 32: GET to Retrieve the Vendors List used by a DOTS Server
{ {
"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": []
} }
] ]
} }
} }
Figure 34: Response Message Body to a GET to Retrieve the Vendors Figure 33: Response Message Body to a GET to Retrieve the Vendors
List Used by a DOTS Server List used by a DOTS Server
The DOTS client repeats the above procedure regularly (e.g., once a The DOTS client repeats the above procedure regularly (e.g., once a
week) to update the DOTS server's vendor attack mapping details. week) to update the DOTS server's vendor attack mapping details.
If the DOTS client concludes that the DOTS server does not have any If the DOTS client concludes that the DOTS server does not have any
reference to the specific vendor attack mapping details, the DOTS reference to the specific vendor attack mapping details, the DOTS
client uses a POST request to install its vendor attack mapping client uses a POST request to install its vendor attack mapping
details. An example of such a POST request is depicted in Figure 30. details. An example of such a POST request is depicted in Figure 34.
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"
}
]
}
]
}
}
Figure 34: POST to Install Vendor Attack Mapping Details
The DOTS server indicates the result of processing the POST request The DOTS server indicates the result of processing the POST request
using the status-line. A "201 Created" status-line MUST be returned using the status-line. A "201 Created" status-line MUST be returned
in the response if the DOTS server has accepted the vendor attack in the response if the DOTS server has accepted the vendor attack
mapping details. If the request is missing a mandatory attribute or mapping details. If the request is missing a mandatory attribute or
contains an invalid or unknown parameter, a "400 Bad Request" status- contains an invalid or unknown parameter, "400 Bad Request" status-
line MUST be returned by the DOTS server in the response. The error- line MUST be returned by the DOTS server in the response. The error-
tag is set to "missing-attribute", "invalid-value", or "unknown- tag is set to "missing-attribute", "invalid-value", or "unknown-
element" as a function of the encountered error. element" as a function of the encountered error.
If the request is received via a server-domain DOTS gateway but the 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 'cdid' DOTS server does not maintain a 'cdid' for this 'cuid' while a 'cdid'
is expected to be supplied, the DOTS server MUST reply with a "403 is expected to be supplied, the DOTS server MUST reply with "403
Forbidden" status-line and the error-tag "access-denied". Upon 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 MUST register (Section 5.1
of [RFC8783]). of [RFC8783]).
The DOTS client uses the PUT request to modify its vendor attack 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). mapping entry, update an existing mapping).
A DOTS client uses a GET request to retrieve its vendor attack A DOTS client uses a GET request to retrieve its vendor attack
mapping details as maintained by the DOTS server (Figure 35). mapping details as maintained by the DOTS server (Figure 35).
GET /restconf/data/ietf-dots-data-channel:dots-data\ GET /restconf/data/ietf-dots-data-channel:dots-data\
/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 Accept: application/yang-data+json
Figure 35: GET to Retrieve Installed Vendor Attack Mapping Details Figure 35: GET to Retrieve Installed Vendor Attack Mapping Details
When conveying attack details in DOTS telemetry messages When conveying attack details in DOTS telemetry messages (Sections
(Sections 8.2, 8.3, and 9), DOTS agents MUST NOT include the 'attack- 8.2, 8.3, and 9), DOTS agents MUST NOT include the 'attack-
description' attribute unless the corresponding attack mapping description' attribute unless the corresponding attack mapping
details were not previously shared with the peer DOTS agent. details were not previously shared with the peer DOTS agent.
8.2. From DOTS Clients to DOTS Servers 8.2. From DOTS Clients to DOTS Servers
DOTS clients use PUT requests to signal pre-or-ongoing-mitigation 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
Figure 36. Figure 36.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
skipping to change at line 2525 skipping to change at page 58, line 43
"start-time": "1608336568", "start-time": "1608336568",
"attack-severity": "high" "attack-severity": "high"
} }
] ]
} }
] ]
} }
} }
Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry, Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry,
Depicted as per Section 5.6 depicted as per Section 5.6
'cuid' is a mandatory Uri-Path parameter for DOTS PUT requests. 'cuid' is a mandatory Uri-Path parameter for DOTS PUT requests.
The following additional Uri-Path parameter is defined: The following additional Uri-Path parameter is defined:
tmid: The Telemetry Identifier is an identifier for the DOTS pre-or- tmid: Telemetry Identifier is an identifier for the DOTS pre-or-
ongoing-mitigation telemetry data represented as an integer. This ongoing-mitigation telemetry data represented as an integer.
identifier MUST be generated by DOTS clients. 'tmid' values MUST This identifier MUST be generated by DOTS clients. 'tmid' values
increase monotonically whenever a DOTS client needs to convey a MUST increase monotonically whenever a DOTS client needs to
new set of pre-or-ongoing-mitigation telemetry data. convey new set of pre-or-ongoing-mitigation telemetry.
The procedure specified in Section 4.4.1 of [RFC9132] for 'mid' The procedure specified in Section 4.4.1 of [RFC9132] for 'mid'
rollover MUST be followed for 'tmid' rollover. rollover MUST be followed for 'tmid' rollover.
This is a mandatory attribute. 'tmid' MUST appear after 'cuid' in This is a mandatory attribute. 'tmid' MUST appear after 'cuid'
the Uri-Path options. in the Uri-Path options.
'cuid' and 'tmid' MUST NOT appear in the PUT request message body. 'cuid' and 'tmid' MUST NOT appear in the PUT request message body.
At least the 'target' attribute and another pre-or-ongoing-mitigation At least the 'target' attribute and another pre-or-ongoing-mitigation
attribute (Section 8.1) MUST be present in the PUT request. If only attribute (Section 8.1) MUST be present in the PUT request. If only
the 'target' attribute is present, this request is handled as per the 'target' attribute is present, this request is handled as per
Section 8.3. Section 8.3.
The relative order of two PUT requests carrying DOTS pre-or-ongoing- The relative order of two PUT requests carrying DOTS pre-or-ongoing-
mitigation telemetry from a DOTS client is determined by comparing mitigation telemetry from a DOTS client is determined by comparing
their respective 'tmid' values. If these two requests have an their respective 'tmid' values. If two such requests have an
overlapping 'target', the PUT request with a higher numeric 'tmid' overlapping 'target', the PUT request with higher numeric 'tmid'
value will override the request with a lower numeric 'tmid' value. value will override the request with a lower numeric 'tmid' value.
The overlapped lower numeric 'tmid' MUST be automatically deleted and The overlapped lower numeric 'tmid' MUST be automatically deleted and
no longer be available. no longer be available.
The DOTS server indicates the result of processing a PUT request The DOTS server indicates the result of processing a PUT request
using CoAP Response Codes. In particular, the 2.04 (Changed) using CoAP Response Codes. In particular, the 2.04 (Changed)
Response Code is returned if the DOTS server has accepted the pre-or- Response Code is returned if the DOTS server has accepted the pre-or-
ongoing-mitigation telemetry. The 5.03 (Service Unavailable) ongoing-mitigation telemetry. The 5.03 (Service Unavailable)
Response Code is returned if the DOTS server has erred. The 5.03 Response Code is returned if the DOTS server has erred. 5.03 uses the
Response Code uses the Max-Age Option to indicate the number of Max-Age Option to indicate the number of seconds after which to
seconds after which to retry. retry.
How long a DOTS server maintains a 'tmid' as active or logs the 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' is still active, then logging details are updated by the 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 DOTS DOTS server as a function of the updates received from the peer DOTS
client. client.
A DOTS client that lost the state of its active 'tmid's or has to set 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 request 'tmid' back to zero (e.g., crash or restart) MUST send a GET request
to the DOTS server to retrieve the list of active 'tmid' values. The to the DOTS server to retrieve the list of active 'tmid' values. The
skipping to change at line 2586 skipping to change at page 60, line 12
(Figure 37). Sending a DELETE with no 'tmid' indicates that all (Figure 37). Sending a DELETE with no 'tmid' indicates that all
'tmid's must be deactivated (Figure 38). 'tmid's must be deactivated (Figure 38).
Header: DELETE (Code=0.04) 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"
Figure 37: Deleting Specific Pre-or-Ongoing-Mitigation Telemetry Figure 37: Delete a Pre-or-Ongoing-Mitigation Telemetry
Information
Header: DELETE (Code=0.04) 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"
Figure 38: Deleting All Pre-or-Ongoing-Mitigation Telemetry Figure 38: Delete All Pre-or-Ongoing-Mitigation Telemetry
Information
8.3. From DOTS Servers to DOTS Clients 8.3. From DOTS Servers to DOTS Clients
The pre-or-ongoing-mitigation data (attack details in particular) can The pre-or-ongoing-mitigation data (attack details, in particular)
also be signaled from DOTS servers to DOTS clients. For example, a can also be signaled from DOTS servers to DOTS clients. For example,
DOTS server co-located with a DDoS detector can collect monitoring a 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. attack details to the DOTS client.
The DOTS client can use the attack details to decide whether to 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. appropriate DOTS server for mitigating the attack.
In order to receive pre-or-ongoing-mitigation telemetry notifications In order to receive pre-or-ongoing-mitigation telemetry notifications
from a DOTS server, a DOTS client MUST send a PUT (followed by a GET) from a DOTS server, a DOTS client MUST send a PUT (followed by a GET)
with the target filter. An example of such a PUT request is shown in with the target filter. An example of such a PUT request is shown in
Figure 39. In order to avoid maintaining a long list of such Figure 39. In order to avoid maintaining a long list of such
requests, it is RECOMMENDED that DOTS clients include all targets in requests, it is RECOMMENDED that DOTS clients include all targets in
the same request (assuming that this information fits within one the same request (assuming this fits within one single datagram).
single datagram). DOTS servers may be instructed to restrict the DOTS servers may be instructed to restrict the number of pre-or-
number of pre-or-ongoing-mitigation requests per DOTS client domain. ongoing-mitigation requests per DOTS client domain. The pre-or-
The pre-or-ongoing-mitigation requests MUST be maintained in an ongoing mitigation requests MUST be maintained in an active state by
active state by the DOTS server until a DELETE request is received the DOTS server until a delete request is received from the same DOTS
from the same DOTS client to clear this pre-or-ongoing-mitigation client to clear this pre-or-ongoing-mitigation telemetry or when the
telemetry or when the DOTS client is considered inactive (e.g., DOTS client is considered inactive (e.g., Section 3.5 of [RFC8783]).
Section 3.5 of [RFC8783]).
The relative order of two PUT requests carrying DOTS pre-or-ongoing- The relative order of two PUT requests carrying DOTS pre-or-ongoing-
mitigation telemetry from a DOTS client is determined by comparing mitigation telemetry from a DOTS client is determined by comparing
their respective 'tmid' values. If these two requests have an their respective 'tmid' values. If such two requests have
overlapping 'target', the PUT request with a higher numeric 'tmid' overlapping 'target', the PUT request with higher numeric 'tmid'
value will override the request with a lower numeric 'tmid' value. value will override the request with a lower numeric 'tmid' value.
The overlapped lower numeric 'tmid' MUST be automatically deleted and The overlapped lower numeric 'tmid' MUST be automatically deleted and
no longer be available. no longer be available.
Header: PUT (Code=0.03) 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"
skipping to change at line 2658 skipping to change at page 61, line 32
"target-prefix": [ "target-prefix": [
"2001:db8::/32" "2001:db8::/32"
] ]
} }
} }
] ]
} }
} }
Figure 39: PUT to Request Pre-or-Ongoing-Mitigation Telemetry, Figure 39: PUT to Request Pre-or-Ongoing-Mitigation Telemetry,
Depicted as per Section 5.6 depicted as per Section 5.6
DOTS clients of the same domain can ask to receive pre-or-ongoing- DOTS clients of the same domain can request to receive pre-or-
mitigation telemetry bound to the same target without being ongoing-mitigation telemetry bound to the same target without being
considered to be "overlapping" and in conflict. considered to be "overlapping" and in conflict.
Once the PUT request to instantiate request state on the server has 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
telemetry updates. The client uses the Observe Option, set to "0" telemtry 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' (Figure 40) or server. The GET request can specify a specific 'tmid' (Figure 40) or
omit the 'tmid' (Figure 41) to receive updates on all active requests omit the 'tmid' (Figure 41) to receive updates on all active requests
from that client. from that client.
Header: GET (Code=0.01) 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"
skipping to change at line 2692 skipping to change at page 62, line 24
Notifications for a Specific 'tmid' Notifications for a Specific 'tmid'
Header: GET (Code=0.01) 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 Observe: 0
Figure 41: GET to Subscribe to Telemetry Asynchronous Figure 41: GET to Subscribe to Telemetry Asynchronous
Notifications for All 'tmid's Notifications for All 'tmids'
The DOTS client can use a filter to request a subset of the 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', 'target- on the attack target: 'target-prefix', 'target-port', 'target-
protocol', 'target-fqdn', 'target-uri', 'alias-name', 'mid', and 'c' protocol', 'target-fqdn', 'target-uri', 'alias-name', 'mid', and 'c'
(content) (Section 5.4). Furthermore: (content) (Section 5.4). Furthermore:
* If more than one Uri-Query option is included in a request, these If more than one Uri-Query option is included in a request, these
options are interpreted in the same way as when multiple target options are interpreted in the same way as when multiple target
attributes are included in a message body (Section 4.4.1 of attributes are included in a message body (Section 4.4.1 of
[RFC9132]). [RFC9132]).
* If multiple values of a query parameter are to be included in a If multiple values of a query parameter are to be included in a
request, these values MUST be included in the same Uri-Query request, these values MUST be included in the same Uri-Query
option and separated by a "," character without any spaces. option and separated by a "," character without any spaces.
* Range values (i.e., a contiguous inclusive block) can be included Range values (i.e., a contiguous inclusive block) can be included
for the 'target-port', 'target-protocol', and 'mid' parameters by for the 'target-port', 'target-protocol', and 'mid' parameters by
indicating the two boundary values separated by a "-" character. indicating the two boundary values separated by a "-" character.
* Wildcard names (i.e., a name with the leftmost label is the "*" 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 MUST NOT include a name in which 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 a Uri-Query included as a value of the 'target-fqdn' parameter in an Uri-Query
option. option.
DOTS clients may also filter out the asynchronous notifications from DOTS clients may also filter out the asynchronous notifications from
the DOTS server by indicating information about a specific attack 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 SHOULD be taken
when using these filters, as their use may cause some attacks to be when using these filters as their use may cause some attacks may be
hidden from the requesting DOTS client (e.g., if the attack changes hidden to the requesting DOTS client (e.g., if the attack changes its
its source information). source information).
Requests with invalid query types (e.g., not supported, malformed) Requests with invalid query types (e.g., not supported, malformed)
received by the DOTS server MUST be rejected with a 4.00 (Bad received by the DOTS server MUST be rejected with a 4.00 (Bad
Request) Response Code. Request) response code.
An example of a request to subscribe to asynchronous telemetry An example of a request to subscribe to asynchronous telemetry
notifications regarding UDP traffic is shown in Figure 42. This notifications regarding UDP traffic is shown in Figure 42. This
filter will be applied for all 'tmid's. filter will be applied for all 'tmid's.
Header: GET (Code=0.01) 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 Observe: 0
Figure 42: GET Request to Receive Telemetry Asynchronous Figure 42: GET Request to Receive Telemetry Asynchronous
Notifications Filtered Using Uri-Query Notifications Filtered using Uri-Query
The DOTS server will send asynchronous notifications to the DOTS The DOTS server will send asynchronous notifications to the DOTS
client when an attack event is detected, following considerations client when an attack event is detected following similar
similar to those discussed in Section 4.4.2.1 of [RFC9132]. An considerations as in Section 4.4.2.1 of [RFC9132]. An example of a
example of a pre-or-ongoing-mitigation telemetry notification is pre-or-ongoing-mitigation telemetry notification is shown in
shown in Figure 43. Figure 43.
{ {
"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"
] ]
skipping to change at line 2791 skipping to change at page 64, line 38
"start-time": "1618339785", "start-time": "1618339785",
"attack-severity": "high" "attack-severity": "high"
} }
] ]
} }
] ]
} }
} }
Figure 43: Message Body of a Pre-or-Ongoing-Mitigation Telemetry Figure 43: Message Body of a Pre-or-Ongoing-Mitigation Telemetry
Notification from the DOTS Server, Depicted as per Section 5.6 Notification from the DOTS Server, depicted as per Section 5.6
A DOTS server sends the aggregate data for a target using the 'total- A DOTS server sends the aggregate data for a target using 'total-
attack-traffic' attribute. The aggregate assumes that Uri-Query 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 MAY include more
fine-grained data when needed (that is, 'total-attack-traffic- fine-grained data when needed (that is, 'total-attack-traffic-
protocol' and 'total-attack-traffic-port'). If a port filter (or protocol' and 'total-attack-traffic-port'). If a port filter (or
protocol filter) is included in a request, 'total-attack-traffic- protocol filter) is included in a request, 'total-attack-traffic-
protocol' (or 'total-attack-traffic-port') conveys the data with the protocol' (or 'total-attack-traffic-port') conveys the data with the
port (or protocol) filter applied. port (or protocol) filter applied.
A DOTS server may aggregate pre-or-ongoing-mitigation data (e.g., 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') for a specific target. specific information (e.g., 'top-talker') per individual targets.
The DOTS client may log pre-or-ongoing-mitigation telemetry data with The DOTS client may log pre-or-ongoing-mitigation telemetry data with
an alert sent to an administrator or a network controller. The DOTS an alert sent to an administrator or a network controller. The DOTS
client may send a mitigation request if the attack cannot be handled client may send a mitigation request if the attack cannot be handled
locally. locally.
A DOTS client that is not interested in receiving pre-or-ongoing- A DOTS client that is not interested to receive pre-or-ongoing-
mitigation telemetry data for a target sends a DELETE request similar mitigation telemetry data for a target sends a delete request similar
to the DELETE request depicted in Figure 37. to the one depicted in Figure 37.
9. DOTS Telemetry Mitigation Status Update 9. DOTS Telemetry Mitigation Status Update
9.1. From DOTS Clients to DOTS Servers: Mitigation Efficacy DOTS 9.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry
Telemetry Attributes Attributes
The mitigation efficacy telemetry attributes can be signaled from 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 [RFC9132]). efficacy updates to the server (Section 4.4.3 of [RFC9132]).
Total attack traffic: The overall attack traffic as observed from Total Attack Traffic: The overall attack traffic as observed from
the DOTS client's perspective during an active mitigation. See the DOTS client perspective during an active mitigation. See
Figure 27. Figure 27.
Attack details: The overall attack details as observed from the DOTS Attack Details: The overall attack details as observed from the DOTS
client's perspective during an active mitigation. See client perspective during an active mitigation. See
Section 8.1.5. Section 8.1.5.
The "ietf-dots-telemetry" YANG module (Section 11.1) augments the The "ietf-dots-telemetry" YANG module (Section 11.1) augments the
'mitigation-scope' message type defined in the "ietf-dots-signal- 'mitigation-scope' message type defined in the "ietf-dots-signal"
channel" module [RFC9132] so that these attributes can be signaled by module [RFC9132] so that these attributes can be signalled by a DOTS
a DOTS client in a mitigation efficacy update (Figure 44). client in a mitigation efficacy update (Figure 44).
augment-structure /dots-signal:dots-signal/dots-signal:message-type augment-structure /dots-signal:dots-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
skipping to change at line 2858 skipping to change at page 66, line 9
+-- 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
... ...
Figure 44: Telemetry Efficacy Update Tree Structure Figure 44: Telemetry Efficacy Update Tree Structure
In order to signal telemetry data in a mitigation efficacy update, it In order to signal telemetry data in a mitigation efficacy update, it
is RECOMMENDED that the DOTS client have already established a DOTS is RECOMMENDED that the DOTS client has already established a DOTS
telemetry setup session with the server in 'idle' time. Such a telemetry setup session with the server in 'idle' time. Such a
session is primarily meant to assess whether the peer DOTS server session is primarily meant to assess whether the peer DOTS server
supports telemetry extensions and to thus prevent message processing supports telemetry extensions and, thus, prevent message processing
failure (Section 3.1 of [RFC9132]). failure (Section 3.1 of [RFC9132]).
An example of an efficacy update with telemetry attributes is An example of an efficacy update with telemetry attributes is
depicted in Figure 45. depicted in Figure 45.
Header: PUT (Code=0.03) 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"
skipping to change at line 2933 skipping to change at page 67, line 37
{ {
"unit": "megabit-ps", "unit": "megabit-ps",
"mid-percentile-g": "900" "mid-percentile-g": "900"
} }
] ]
} }
] ]
} }
} }
Figure 45: Example of Mitigation Efficacy Update with Telemetry Figure 45: An Example of Mitigation Efficacy Update with
Attributes, Depicted as per Section 5.6 Telemetry Attributes, depicted as per Section 5.6
9.2. From DOTS Servers to DOTS Clients: Mitigation Status DOTS 9.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry
Telemetry Attributes Attributes
The mitigation status telemetry attributes can be signaled from the 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 [RFC9132]). In particular, DOTS status update (Section 4.4.2 of [RFC9132]). In particular, DOTS
clients can receive asynchronous notifications of the attack details clients can receive asynchronous notifications of the attack details
from DOTS servers using the Observe Option defined in [RFC7641]. from DOTS servers using the Observe option defined in [RFC7641].
In order to make use of this feature, DOTS clients MUST establish a In order to make use of this feature, DOTS clients MUST establish a
telemetry session with the DOTS server in 'idle' time and MUST set telemetry session with the DOTS server in 'idle' time and MUST set
the 'server-originated-telemetry' attribute to 'true'. the 'server-originated-telemetry' attribute to 'true'.
DOTS servers MUST NOT include telemetry attributes in mitigation DOTS servers MUST NOT include telemetry attributes in 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'. the 'server-originated-telemetry' attribute is set to 'false'.
As defined in [RFC8612], the actual mitigation activities can include As defined in [RFC8612], the actual mitigation activities can include
several countermeasure mechanisms. The DOTS server signals the several countermeasure mechanisms. The DOTS server signals the
current operational status of relevant countermeasures. A list of current operational status of relevant countermeasures. A list of
attacks detected by these countermeasures MAY also be included. The attacks detected by these countermeasures MAY also be included. The
same attributes as those defined in Section 8.1.5 are applicable for same attributes defined in Section 8.1.5 are applicable for
describing the attacks detected and mitigated at the DOTS server describing the attacks detected and mitigated at the DOTS server
domain. domain.
The "ietf-dots-telemetry" YANG module (Section 11.1) augments the The "ietf-dots-telemetry" YANG module (Section 11.1) augments the
'mitigation-scope' message type defined in the "ietf-dots-signal- 'mitigation-scope' message type defined in "ietf-dots-signal"
channel" module [RFC9132] with telemetry data as depicted in [RFC9132] with telemetry data as depicted in Figure 46.
Figure 46.
augment-structure /dots-signal:dots-signal/dots-signal:message-type augment-structure /dots-signal:dots-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
skipping to change at line 3045 skipping to change at page 70, line 5
| +-- 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
... ...
Figure 46: DOTS Server-to-Client Mitigation Status Telemetry Tree Figure 46: DOTS Servers to Clients Mitigation Status Telemetry
Structure Tree Structure
Figure 47 shows an example of an asynchronous notification of attack Figure 47 shows an example of an asynchronous notification of attack
mitigation status from the DOTS server. This notification signals mitigation status from the DOTS server. This notification signals
both the mid-percentile value of processed attack traffic and the both the mid-percentile value of processed attack traffic and the
peak count of unique sources involved in the attack. peak count of unique sources involved in the attack.
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
skipping to change at line 3089 skipping to change at page 70, line 49
"source-count": { "source-count": {
"peak-g": "12683" "peak-g": "12683"
} }
} }
] ]
} }
] ]
} }
} }
Figure 47: Response Body of a Mitigation Status with Telemetry Figure 47: Response Body of a Mitigation Status With Telemetry
Attributes, Depicted as per Section 5.6 Attributes, depicted as per Section 5.6
DOTS clients can filter out the asynchronous notifications from the 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) (Section 5.4). The 'target-uri', 'alias-name', and 'c' (content) (Section 5.4). The
considerations discussed in Section 8.3 MUST be followed to include considerations discussed in Section 8.3 MUST be followed to include
multiple query values, ranges ('target-port', 'target-protocol'), and multiple query values, ranges ('target-port', 'target-protocol'), and
wildcard names ('target-fqdn', 'target-uri'). wildcard names ('target-fqdn', 'target-uri').
An example of a request to subscribe to asynchronous notifications An example of request to subscribe to asynchronous notifications
bound to the "https1" alias is shown in Figure 48. bound to the "https1" alias is shown in Figure 48.
Header: GET (Code=0.01) 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 Observe: 0
Figure 48: GET Request to Receive Asynchronous Notifications Figure 48: GET Request to Receive Asynchronous Notifications
Filtered Using Uri-Query Filtered using Uri- Query
If the target query does not match the target of the enclosed 'mid' 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 MUST respond with a 4.04
(Not Found) error Response Code. The DOTS server MUST NOT add a new (Not Found) error Response Code. The DOTS server MUST NOT add a new
Observe entry if this query overlaps with an existing Observe entry. observe entry if this query overlaps with an existing one. In such a
In such a case, the DOTS server replies with a 4.09 (Conflict) case, the DOTS server replies with 4.09 (Conflict).
Response Code.
10. Error Handling 10. Error Handling
A list of common CoAP errors that are implemented by DOTS servers is A list of common CoAP errors that are implemented by DOTS servers are
provided in Section 9 of [RFC9132]. The following additional error provided in Section 9 of [RFC9132]. The following additional error
cases apply for the telemetry extension: cases apply for the telemetry extension:
* 4.00 (Bad Request) is returned by the DOTS server when the DOTS * 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. extension.
* 4.04 (Not Found) is returned by the DOTS server when the DOTS * 4.04 (Not Found) is returned by the DOTS server when the DOTS
client is requesting a 'tsid' or 'tmid' that is not valid. client is requesting a 'tsid' or 'tmid' that is not valid.
* 4.00 (Bad Request) is returned by the DOTS server when the DOTS * 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). supported, malformed).
* 4.04 (Not Found) is returned by the DOTS server when the DOTS * 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 server. the target of the enclosed 'mid' as maintained by the DOTS server.
As indicated in Section 9 of [RFC9132], an additional plaintext As indicated in Section 9 of [RFC9132], an additional plain text
diagnostic payload (Section 5.5.2 of [RFC7252]) to help with diagnostic payload (Section 5.5.2 of [RFC7252]) to help
troubleshooting is returned in the body of the response. troubleshooting is returned in the body of the response.
11. YANG Modules 11. YANG Modules
11.1. DOTS Signal Channel Telemetry YANG Module 11.1. DOTS Signal Channel Telemetry YANG Module
This module uses types defined in [RFC6991] and [RFC8345]. It also This module uses types defined in [RFC6991] and [RFC8345].
reuses a grouping from [RFC8783].
<CODE BEGINS> file "ietf-dots-telemetry@2022-06-20.yang" <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 "RFC 9132: Distributed Denial-of-Service Open Threat Signaling
Signaling (DOTS) Signal Channel Specification"; (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
"RFC 6991: Common YANG Data Types, Section 3"; "Section 3 of RFC 6991";
} }
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Data Types, Section 4"; "Section 4 of RFC 6991";
} }
import ietf-network-topology { import ietf-network-topology {
prefix nt; prefix nt;
reference reference
"RFC 8345: A YANG Data Model for Network Topologies, "Section 6.2 of RFC 8345: A YANG Data Model for Network
Section 6.2"; Topologies";
} }
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 9244; see the This version of this YANG module is part of RFC XXXX; see
RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2022-06-20 { revision 2022-02-04 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 9244: Distributed Denial-of-Service Open Threat "RFC XXXX: 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 is "A subset of DOTS client domain resources are
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 3279 skipping to change at page 74, line 47
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 (bps)."; "Bits per Second (bit/s).";
} }
enum byte-ps { enum byte-ps {
value 3; value 3;
description description
"Bytes per second (Bps)."; "Bytes per second (Byte/s).";
} }
} }
description description
"Enumeration to indicate which unit class is used. "Enumeration to indicate which unit class is used.
These classes are supported: pps, bps, and Bps."; These classes are supported: pps, bit/s, and Byte/s.";
} }
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 3468 skipping to change at page 78, line 44
} }
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
"One-second measurement period."; "A 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 3569 skipping to change at page 80, line 49
"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 the 'c' (content) Uri-Query option, "Query based on 'c' Uri-Query option that is used
which is used to control the selection of configuration to control the selection of configuration
and non-configuration data nodes."; and non-configuration data nodes.";
reference reference
"RFC 9132: Distributed Denial-of-Service Open Threat "Section 4.4.2 of RFC 9132.";
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 a measurement sample period, and low/mid/high
low-percentile/mid-percentile/high-percentile values."; percentile values.";
leaf measurement-interval { leaf measurement-interval {
type interval; type interval;
description description
"Defines the period during which percentiles are "Defines the period on which percentiles are computed.";
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 that "Low percentile. If set to '0', this means low-percentiles
the use of low-percentile values is disabled."; are 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 "Mid percentile. If set to the same value as low-percentile,
'low-percentile', this means that the use of this means mid-percentiles are disabled.";
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 "High percentile. If set to the same value as mid-percentile,
'mid-percentile', this means that the use of this means high-percentiles are disabled.";
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
"Generic grouping for percentile and peak values."; "Generic grouping for percentile and peak values.";
uses percentile-and-peak; uses percentile-and-peak;
leaf current-g { leaf current-g {
type yang:gauge64; type yang:gauge64;
description description
"Current value."; "Current value.";
} }
} }
skipping to change at line 3696 skipping to change at page 83, line 26
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 "Grouping of traffic as a function of the measurement unit.";
measurement unit.";
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 classes: packet-ps,
'packet-ps', 'bit-ps', or 'byte-ps'. DOTS agents bit-ps, or byte-ps. DOTS agents auto-scale to the
auto-scale to the appropriate units (e.g., 'megabit-ps', appropriate units (e.g., megabit-ps, kilobit-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 3742 skipping to change at page 84, line 22
} }
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' Values are taken from the IANA Protocol Numbers registry:
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 the Datagram Congestion Control 17 for UDP, 33 for DCCP, or 132 for SCTP.";
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 3775 skipping to change at page 85, line 4
} }
grouping traffic-unit-port { grouping traffic-unit-port {
description description
"Grouping of traffic bound to a port number as "Grouping of traffic bound to a port number as
a function of the measurement unit."; a function of the measurement unit.";
leaf port { leaf port {
type inet:port-number; type inet:port-number;
description description
"Port number used by a transport protocol."; "Port number used by a transport protocol.";
} }
uses traffic-unit; uses traffic-unit;
} }
grouping traffic-unit-port-all { grouping traffic-unit-port-all {
description description
"Grouping of traffic bound to a port number as "Grouping of traffic bound to a port number as
a function of the measurement unit, including a function of the measurement unit, including
current values."; current values.";
uses traffic-unit-port; uses traffic-unit-port;
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 connections, as well as overall capacity. These data nodes are
are useful for detecting resource-consuming DDoS attacks."; useful to detect 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 that are allowed to the target server. The term 'embryonic
'embryonic connection' refers to a connection whose connection' refers to a connection whose connection
connection handshake is not finished. Embryonic handshake is not finished. Embryonic connections are only
connections are only possible in connection-oriented possible in connection-oriented transport protocols like
transport protocols like TCP or SCTP."; 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 3865 skipping to change at page 86, line 46
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 connection capacity per protocol. These data nodes "Total connections capacity per protocol. These data nodes are
are useful for detecting resource-consuming DDoS attacks."; useful to detect 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 that represent the attack "A set of data nodes which 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 3916 skipping to change at page 87, line 49
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 3956 skipping to change at page 88, line 40
} }
} }
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' Values are taken from the IANA Protocol Numbers registry:
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' Values are taken from the IANA Protocol Numbers registry:
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' Values are taken from the IANA Protocol Numbers registry:
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' Values are taken from the IANA Protocol Numbers registry:
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 The attack details need to cover well-known and common attacks
attacks (such as a SYN flood) along with new emerging or (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
"The Vendor ID is a security vendor's Private Enterprise "Vendor ID is a security vendor's Private Enterprise Number
Number as registered with IANA."; 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-WYZa-wyz]' + '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WY-Za-wy-z]'
+ '(-([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 4076 skipping to change at page 91, line 11
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 the attack description. "Textual representation of attack description. Natural
Natural Language Processing techniques (e.g., Language Processing techniques (e.g., word embedding)
word embedding) might provide some utility in mapping might provide some utility in mapping the attack
the attack description to an attack type."; 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 "Severity level of an attack. How this level is determined
determined is implementation specific."; is implementation-specific.";
} }
leaf start-time { leaf start-time {
type uint64; type uint64;
description description
"The time the attack started. The start time is "The time the attack started. Start time is represented in
represented in seconds relative to seconds relative to 1970-01-01T00:00:00Z.";
1970-01-01T00:00:00Z.";
} }
leaf end-time { leaf end-time {
type uint64; type uint64;
description description
"The time the attack ended. The end time is represented "The time the attack ended. End time is represented in
in seconds relative to 1970-01-01T00:00:00Z."; 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 the lower port number."; or equal to 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 the lower ICMP type."; or equal to 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;
} }
} }
} }
skipping to change at line 4213 skipping to change at page 94, line 4
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 Internet of Things (IoT) object, a server, etc."; an 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 4358 skipping to change at page 97, line 4
"Total attack connections."; "Total attack connections.";
uses connection-all; uses connection-all;
} }
} }
} }
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 'telemetry-setup' or telemetry data."; "Can be a telemetry-setup or telemetry data.";
case telemetry-setup { case telemetry-setup {
description description
"Indicates that the message is about telemetry setup."; "Indicates the message is about telemetry steup.";
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' value in to the telemetry-notify-interval in the
the 'min-config-values' attribute"; min-config-values";
} }
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 4443 skipping to change at page 98, line 41
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 RFC 8791."; is compliant with RFC8791.";
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 "These data nodes appear only in a telemetry message
message sent from the server to the client."; 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 a baseline message."; or 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 "Used by a DOTS client to enable/disable whether
whether it requests pre-or-ongoing-mitigation it requests pre-or-ongoing-mitigation telemetry
telemetry from the DOTS server."; 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.";
} }
} }
} }
case pipe { case pipe {
description description
"Total pipe capacity of a DOTS client domain."; "Total pipe capacity of a DOTS client domain.";
list total-pipe-capacity { list total-pipe-capacity {
key "link-id unit"; key "link-id unit";
description description
"Total pipe capacity of a DOTS client domain."; "Total pipe capacity of a DOTS client domain.";
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 "Pipe capacity. This attribute is mandatory when
when 'total-pipe-capacity' is included in a total-pipe-capacity is included in a message.";
message.";
} }
leaf unit { leaf unit {
type unit; type unit;
description description
"The traffic can be measured using unit "The traffic can be measured using unit classes:
classes: packets per second (pps), bits per packets per second (pps), bits per second
second (bps), and/or bytes per second (bit/s), and/or bytes per second (Byte/s).
(Bps).
For a given unit class, the DOTS agents For a given unit class, the DOTS agents
auto-scale to the appropriate units (e.g., auto-scales to the appropriate units (e.g.,
'megabit-ps', 'kilobit-ps')."; megabit-ps, kilobit-ps).";
} }
} }
} }
case baseline { case baseline {
description description
"Traffic baseline information related to a DOTS "Traffic baseline information of a DOTS client
client domain."; domain.";
list baseline { list baseline {
key "id"; key "id";
description description
"Traffic baseline information related to a DOTS "Traffic baseline information of a DOTS client
client domain."; 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 baseline entry communicated by a DOTS client.";
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 RFC 8791."; Omitting keys is compliant with RFC8791.";
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 "These data nodes appear only in a telemetry message
message sent from the server to the client."; 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 "Indicates the target. At least one of the attributes
attributes 'target-prefix', 'target-fqdn', 'target-prefix', 'target-fqdn', 'target-uri',
'target-uri', 'alias-name', or 'mid-list' 'alias-name', or 'mid-list' must be present in the
must be present in the target definition."; 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 to a list of associated mitigation "Reference a list of associated mitigation
requests."; requests.";
reference reference
"RFC 9132: Distributed Denial-of-Service Open "RFC 9132: Distributed Denial-of-Service Open Threat
Threat Signaling (DOTS) Signal Channel 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> <CODE ENDS>
11.2. Vendor Attack Mapping Details YANG Module 11.2. Vendor Attack Mapping Details YANG Module
<CODE BEGINS> file "ietf-dots-mapping@2022-06-20.yang" <CODE BEGINS> file "ietf-dots-mapping@2022-02-04.yang"
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
of DDoS attack mapping details between a DOTS client and 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 9244; see the This version of this YANG module is part of RFC XXXX; see
RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2022-06-20 { revision 2022-02-04 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 9244: Distributed Denial-of-Service Open Threat "RFC XXXX: 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 related to the "Vendor attack mapping information of the client/server";
client/server.";
leaf vendor-id { leaf vendor-id {
type uint32; type uint32;
description description
"The Vendor ID is a security vendor's Private Enterprise "Vendor ID is a security vendor's Private Enterprise Number
Number as registered with IANA."; 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-WYZa-wyz]' + '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WY-Za-wy-z]'
+ '(-([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 4744 skipping to change at page 104, line 45
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 "The time the mapping table was updated. It is represented
represented in seconds relative to in seconds relative to 1970-01-01T00:00:00Z.";
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 the attack description. "Textual representation of attack description. Natural
Natural Language Processing techniques (e.g., Language Processing techniques (e.g., word embedding)
word embedding) might provide some utility in might provide some utility in mapping the attack
mapping the attack description to an attack type."; 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 4808 skipping to change at page 106, line 12
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 with DOTS clients upon request."; that will be shared upon request with DOTS clients.";
uses attack-mapping; uses attack-mapping;
} }
} }
} }
<CODE ENDS> <CODE ENDS>
12. YANG/JSON Mapping Parameters to CBOR 12. YANG/JSON Mapping Parameters to CBOR
All DOTS telemetry parameters in the payload of the DOTS signal All DOTS telemetry parameters in the payload of the DOTS signal
channel MUST be mapped to CBOR types as shown in Table 3: channel MUST be mapped to CBOR types as shown in Table 3:
| Note: Implementers must check that the mapping output provided * Note: Implementers must check that the mapping output provided by
| by their YANG-to-CBOR encoding schemes is aligned with the their YANG-to-CBOR encoding schemes is aligned with the content of
| contents of Table 3. Table 2.
+======================+==============+======+=============+========+ +----------------------+-------------+------+---------------+--------+
|Parameter Name |YANG Type |CBOR |CBOR Major | JSON | | Parameter Name | YANG | CBOR | CBOR Major | JSON |
| | |Key |Type & | Type | | | Type | Key | Type & | Type |
| | | |Information | | | | | | Information | |
+======================+==============+======+=============+========+ +======================+=============+======+===============+========+
|tsid |uint32 |128 |0 unsigned | Number | | tsid | uint32 |TBA1 | 0 unsigned | Number |
+----------------------+--------------+------+-------------+--------+ | telemetry | list |TBA2 | 4 array | Array |
|telemetry |list |129 |4 array | Array | | low-percentile | decimal64 |TBA3 | 6 tag 4 | |
+----------------------+--------------+------+-------------+--------+ | | | | [-2, integer]| String |
|low-percentile |decimal64 |130 |6 tag 4 [-2, | String | | mid-percentile | decimal64 |TBA4 | 6 tag 4 | |
| | | |integer] | | | | | | [-2, integer]| String |
+----------------------+--------------+------+-------------+--------+ | high-percentile | decimal64 |TBA5 | 6 tag 4 | |
|mid-percentile |decimal64 |131 |6 tag 4 [-2, | String | | | | | [-2, integer]| String |
| | | |integer] | | | unit-config | list |TBA6 | 4 array | Array |
+----------------------+--------------+------+-------------+--------+ | unit | enumeration |TBA7 | 0 unsigned | String |
|high-percentile |decimal64 |132 |6 tag 4 [-2, | String | | unit-status | boolean |TBA8 | 7 bits 20 | False |
| | | |integer] | | | | | | 7 bits 21 | True |
+----------------------+--------------+------+-------------+--------+ | total-pipe-capacity | list |TBA9 | 4 array | Array |
|unit-config |list |133 |4 array | Array | | link-id | string |TBA10 | 3 text string | String |
+----------------------+--------------+------+-------------+--------+ | pre-or-ongoing- | list |TBA11 | 4 array | Array |
|unit |enumeration |134 |0 unsigned | String | | mitigation | | | | |
+----------------------+--------------+------+-------------+--------+ | total-traffic-normal | list |TBA12 | 4 array | Array |
|unit-status |boolean |135 |7 bits 20 | False | | low-percentile-g | yang:gauge64|TBA13 | 0 unsigned | String |
| | | +-------------+--------+ | mid-percentile-g | yang:gauge64|TBA14 | 0 unsigned | String |
| | | |7 bits 21 | True | | high-percentile-g | yang:gauge64|TBA15 | 0 unsigned | String |
+----------------------+--------------+------+-------------+--------+ | peak-g | yang:gauge64|TBA16 | 0 unsigned | String |
|total-pipe-capacity |list |136 |4 array | Array | | total-attack-traffic | list |TBA17 | 4 array | Array |
+----------------------+--------------+------+-------------+--------+ | total-traffic | list |TBA18 | 4 array | Array |
|link-id |string |137 |3 text string| String | | total-connection- | | | | |
+----------------------+--------------+------+-------------+--------+ | capacity | list |TBA19 | 4 array | Array |
|pre-or-ongoing- |list |138 |4 array | Array | | connection | uint64 |TBA20 | 0 unsigned | String |
|mitigation | | | | | | connection-client | uint64 |TBA21 | 0 unsigned | String |
+----------------------+--------------+------+-------------+--------+ | embryonic | uint64 |TBA22 | 0 unsigned | String |
|total-traffic-normal |list |139 |4 array | Array | | embryonic-client | uint64 |TBA23 | 0 unsigned | String |
+----------------------+--------------+------+-------------+--------+ | connection-ps | uint64 |TBA24 | 0 unsigned | String |
|low-percentile-g |yang:gauge64 |140 |0 unsigned | String | | connection-client-ps | uint64 |TBA25 | 0 unsigned | String |
+----------------------+--------------+------+-------------+--------+ | request-ps | uint64 |TBA26 | 0 unsigned | String |
|mid-percentile-g |yang:gauge64 |141 |0 unsigned | String | | request-client-ps | uint64 |TBA27 | 0 unsigned | String |
+----------------------+--------------+------+-------------+--------+ | partial-request-max | uint64 |TBA28 | 0 unsigned | String |
|high-percentile-g |yang:gauge64 |142 |0 unsigned | String | | partial-request- | | | | |
+----------------------+--------------+------+-------------+--------+ | client-max | uint64 |TBA29 | 0 unsigned | String |
|peak-g |yang:gauge64 |143 |0 unsigned | String | | total-attack- | | | | |
+----------------------+--------------+------+-------------+--------+ | connection | container |TBA30 | 5 map | Object |
|total-attack-traffic |list |144 |4 array | Array | | connection-c | container |TBA31 | 5 map | Object |
+----------------------+--------------+------+-------------+--------+ | embryonic-c | container |TBA32 | 5 map | Object |
|total-traffic |list |145 |4 array | Array | | connection-ps-c | container |TBA33 | 5 map | Object |
+----------------------+--------------+------+-------------+--------+ | request-ps-c | container |TBA34 | 5 map | Object |
|total-connection- |list |146 |4 array | Array | | attack-detail | list |TBA35 | 4 array | Array |
|capacity | | | | | | id | uint32 |TBA36 | 0 unsigned | Number |
+----------------------+--------------+------+-------------+--------+ | attack-id | uint32 |TBA37 | 0 unsigned | Number |
|connection |uint64 |147 |0 unsigned | String | | attack-description | string |TBA38 | 3 text string | String |
+----------------------+--------------+------+-------------+--------+ | attack-severity | enumeration |TBA39 | 0 unsigned | String |
|connection-client |uint64 |148 |0 unsigned | String | | start-time | uint64 |TBA40 | 0 unsigned | String |
+----------------------+--------------+------+-------------+--------+ | end-time | uint64 |TBA41 | 0 unsigned | String |
|embryonic |uint64 |149 |0 unsigned | String | | source-count | container |TBA42 | 5 map | Object |
+----------------------+--------------+------+-------------+--------+ | top-talker | container |TBA43 | 5 map | Object |
|embryonic-client |uint64 |150 |0 unsigned | String | | spoofed-status | boolean |TBA44 | 7 bits 20 | False |
+----------------------+--------------+------+-------------+--------+ | | | | 7 bits 21 | True |
|connection-ps |uint64 |151 |0 unsigned | String | | partial-request-c | container |TBA45 | 5 map | Object |
+----------------------+--------------+------+-------------+--------+ | total-attack- | | | | |
|connection-client-ps |uint64 |152 |0 unsigned | String | | connection-protocol | list |TBA46 | 4 array | Array |
+----------------------+--------------+------+-------------+--------+ | baseline | list |TBA49 | 4 array | Array |
|request-ps |uint64 |153 |0 unsigned | String | | current-config | container |TBA50 | 5 map | Object |
+----------------------+--------------+------+-------------+--------+ | max-config-values | container |TBA51 | 5 map | Object |
|request-client-ps |uint64 |154 |0 unsigned | String | | min-config-values | container |TBA52 | 5 map | Object |
+----------------------+--------------+------+-------------+--------+ |supported-unit-classes| container |TBA53 | 5 map | Object |
|partial-request-max |uint64 |155 |0 unsigned | String | | server-originated- | boolean |TBA54 | 7 bits 20 | False |
+----------------------+--------------+------+-------------+--------+ | telemetry | | | 7 bits 21 | True |
|partial-request- |uint64 |156 |0 unsigned | String | | telemetry-notify- | uint16 |TBA55 | 0 unsigned | Number |
|client-max | | | | | | interval | | | | |
+----------------------+--------------+------+-------------+--------+ | tmid | uint32 |TBA56 | 0 unsigned | Number |
|total-attack- |container |157 |5 map | Object | | measurement-interval | enumeration |TBA57 | 0 unsigned | String |
|connection | | | | | | measurement-sample | enumeration |TBA58 | 0 unsigned | String |
+----------------------+--------------+------+-------------+--------+ | talker | list |TBA59 | 4 array | Array |
|connection-c |container |158 |5 map | Object | | source-prefix | inet: |TBA60 | 3 text string | String |
+----------------------+--------------+------+-------------+--------+ | | ip-prefix | | | |
|embryonic-c |container |159 |5 map | Object | | mid-list | leaf-list |TBA61 | 4 array | Array |
+----------------------+--------------+------+-------------+--------+ | | uint32 | | 0 unsigned | Number |
|connection-ps-c |container |160 |5 map | Object | | source-port-range | list |TBA62 | 4 array | Array |
+----------------------+--------------+------+-------------+--------+ | source-icmp-type- | list |TBA63 | 4 array | Array |
|request-ps-c |container |161 |5 map | Object | | range | | | | |
+----------------------+--------------+------+-------------+--------+ | target | container |TBA64 | 5 map | Object |
|attack-detail |list |162 |4 array | Array | | capacity | uint64 |TBA65 | 0 unsigned | String |
+----------------------+--------------+------+-------------+--------+ | protocol | uint8 |TBA66 | 0 unsigned | Number |
|id |uint32 |163 |0 unsigned | Number | | total-traffic- | | | | |
+----------------------+--------------+------+-------------+--------+ | normal-per-protocol | list |TBA67 | 4 array | Array |
|attack-id |uint32 |164 |0 unsigned | Number | | total-traffic- | | | | |
+----------------------+--------------+------+-------------+--------+ | normal-per-port | list |TBA68 | 4 array | Array |
|attack-description |string |165 |3 text string| String | | total-connection- | | | | |
+----------------------+--------------+------+-------------+--------+ | capacity-per-port | list |TBA69 | 4 array | Array |
|attack-severity |enumeration |166 |0 unsigned | String | | total-traffic- | | | | |
+----------------------+--------------+------+-------------+--------+ | protocol | list |TBA70 | 4 array | Array |
|start-time |uint64 |167 |0 unsigned | String | | total-traffic-port | list |TBA71 | 4 array | Array |
+----------------------+--------------+------+-------------+--------+ | total-attack- | | | | |
|end-time |uint64 |168 |0 unsigned | String | | traffic-protocol | list |TBA72 | 4 array | Array |
+----------------------+--------------+------+-------------+--------+ | total-attack- | | | | |
|source-count |container |169 |5 map | Object | | traffic-port | list |TBA73 | 4 array | Array |
+----------------------+--------------+------+-------------+--------+ | total-attack- | | | | |
|top-talker |container |170 |5 map | Object | | connection-port | list |TBA74 | 4 array | Array |
+----------------------+--------------+------+-------------+--------+ | port | inet: | | | |
|spoofed-status |boolean |171 |7 bits 20 | False | | | port-number|TBA75 | 0 unsigned | Number |
| | | +-------------+--------+ | supported-query-type | leaf-list |TBA76 | 4 array | Array |
| | | |7 bits 21 | True | | | | | 0 unsigned | String |
+----------------------+--------------+------+-------------+--------+ | vendor-id | uint32 |TBA77 | 0 unsigned | Number |
|partial-request-c |container |172 |5 map | Object | | ietf-dots-telemetry: | | | | |
+----------------------+--------------+------+-------------+--------+ | telemetry-setup | container |TBA78 | 5 map | Object |
|total-attack- |list |173 |4 array | Array | | ietf-dots-telemetry: | | | | |
|connection-protocol | | | | | | total-traffic | list |TBA79 | 4 array | Array |
+----------------------+--------------+------+-------------+--------+ | ietf-dots-telemetry: | | | | |
|baseline |list |174 |4 array | Array | | total-attack-traffic | list |TBA80 | 4 array | Array |
+----------------------+--------------+------+-------------+--------+ | ietf-dots-telemetry: | | | | |
|current-config |container |175 |5 map | Object | | total-attack- | | | | |
+----------------------+--------------+------+-------------+--------+ | connection | container |TBA81 | 5 map | Object |
|max-config-values |container |176 |5 map | Object | | ietf-dots-telemetry: | | | | |
+----------------------+--------------+------+-------------+--------+ | attack-detail | list |TBA82 | 4 array | Array |
|min-config-values |container |177 |5 map | Object | | ietf-dots-telemetry: | | | | |
+----------------------+--------------+------+-------------+--------+ | telemetry | container |TBA83 | 5 map | Object |
|supported-unit-classes|container |178 |5 map | Object | | current-g | yang:gauge64|TBA84 | 0 unsigned | String |
+----------------------+--------------+------+-------------+--------+ | description-lang | string |TBA85 | 3 text string | String |
|server-originated- |boolean |179 |7 bits 20 | False | | lower-type | uint8 |32771 | 0 unsigned | Number |
|telemetry | | +-------------+--------+ | upper-type | uint8 |32772 | 0 unsigned | Number |
| | | |7 bits 21 | True | +----------------------+-------------+------+---------------+--------+
+----------------------+--------------+------+-------------+--------+
|telemetry-notify- |uint16 |180 |0 unsigned | Number |
|interval | | | | |
+----------------------+--------------+------+-------------+--------+
|tmid |uint32 |181 |0 unsigned | Number |
+----------------------+--------------+------+-------------+--------+
|measurement-interval |enumeration |182 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|measurement-sample |enumeration |183 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|talker |list |184 |4 array | Array |
+----------------------+--------------+------+-------------+--------+
|source-prefix |inet:ip-prefix|185 |3 text string| String |
+----------------------+--------------+------+-------------+--------+
|mid-list |leaf-list |186 |4 array | Array |
| +--------------+------+-------------+--------+
| |uint32 | |0 unsigned | Number |
+----------------------+--------------+------+-------------+--------+
|source-port-range |list |187 |4 array | Array |
+----------------------+--------------+------+-------------+--------+
|source-icmp-type-range|list |188 |4 array | Array |
+----------------------+--------------+------+-------------+--------+
|target |container |189 |5 map | Object |
+----------------------+--------------+------+-------------+--------+
|capacity |uint64 |190 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|protocol |uint8 |191 |0 unsigned | Number |
+----------------------+--------------+------+-------------+--------+
|total-traffic-normal- |list |192 |4 array | Array |
|per-protocol | | | | |
+----------------------+--------------+------+-------------+--------+
|total-traffic-normal- |list |193 |4 array | Array |
|per-port | | | | |
+----------------------+--------------+------+-------------+--------+
|total-connection- |list |194 |4 array | Array |
|capacity-per-port | | | | |
+----------------------+--------------+------+-------------+--------+
|total-traffic-protocol|list |195 |4 array | Array |
+----------------------+--------------+------+-------------+--------+
|total-traffic-port |list |196 |4 array | Array |
+----------------------+--------------+------+-------------+--------+
|total-attack-traffic- |list |197 |4 array | Array |
|protocol | | | | |
+----------------------+--------------+------+-------------+--------+
|total-attack-traffic- |list |198 |4 array | Array |
|port | | | | |
+----------------------+--------------+------+-------------+--------+
|total-attack- |list |199 |4 array | Array |
|connection-port | | | | |
+----------------------+--------------+------+-------------+--------+
|port |inet:port- |200 |0 unsigned | Number |
| |number | | | |
+----------------------+--------------+------+-------------+--------+
|supported-query-type |leaf-list |201 |4 array | Array |
| +--------------+------+-------------+--------+
| | | |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|vendor-id |uint32 |202 |0 unsigned | Number |
+----------------------+--------------+------+-------------+--------+
|ietf-dots- |container |203 |5 map | Object |
|telemetry:telemetry- | | | | |
|setup | | | | |
+----------------------+--------------+------+-------------+--------+
|ietf-dots- |list |204 |4 array | Array |
|telemetry:total- | | | | |
|traffic | | | | |
+----------------------+--------------+------+-------------+--------+
|ietf-dots- |list |205 |4 array | Array |
|telemetry:total- | | | | |
|attack-traffic | | | | |
+----------------------+--------------+------+-------------+--------+
|ietf-dots- |container |206 |5 map | Object |
|telemetry:total- | | | | |
|attack-connection | | | | |
+----------------------+--------------+------+-------------+--------+
|ietf-dots- |list |207 |4 array | Array |
|telemetry:attack- | | | | |
|detail | | | | |
+----------------------+--------------+------+-------------+--------+
|ietf-dots- |container |208 |5 map | Object |
|telemetry:telemetry | | | | |
+----------------------+--------------+------+-------------+--------+
|current-g |yang:gauge64 |209 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|description-lang |string |210 |3 text string| String |
+----------------------+--------------+------+-------------+--------+
|lower-type |uint8 |32771 |0 unsigned | Number |
+----------------------+--------------+------+-------------+--------+
|upper-type |uint8 |32772 |0 unsigned | Number |
+----------------------+--------------+------+-------------+--------+
Table 3: YANG/JSON Mapping Parameters to CBOR Table 3: YANG/JSON Mapping Parameters to CBOR
13. IANA Considerations 13. IANA Considerations
13.1. DOTS Signal Channel CBOR Key Values 13.1. DOTS Signal Channel CBOR Key Values
This specification registers the following comprehension-optional This specification registers the DOTS telemetry attributes in the
parameters in the IANA "DOTS Signal Channel CBOR Key Values" registry IANA "DOTS Signal Channel CBOR Key Values" registry [Key-Map].
[Key-Map].
+======================+==========+=======+============+===========+ The DOTS telemetry attributes defined in this specification are
| Parameter Name | CBOR Key | CBOR | Change | Reference | comprehension-optional parameters.
| | Value | Major | Controller | |
| | | Type | | |
+======================+==========+=======+============+===========+
| tsid | 128 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| telemetry | 129 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| low-percentile | 130 | 6tag4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| mid-percentile | 131 | 6tag4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| high-percentile | 132 | 6tag4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| unit-config | 133 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| unit | 134 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| unit-status | 135 | 7 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| total-pipe-capacity | 136 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| link-id | 137 | 3 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| pre-or-ongoing- | 138 | 4 | IESG | RFC 9244 |
| mitigation | | | | |
+----------------------+----------+-------+------------+-----------+
| total-traffic-normal | 139 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| low-percentile-g | 140 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| mid-percentile-g | 141 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| high-percentile-g | 142 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| peak-g | 143 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| total-attack-traffic | 144 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| total-traffic | 145 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| total-connection- | 146 | 4 | IESG | RFC 9244 |
| capacity | | | | |
+----------------------+----------+-------+------------+-----------+
| connection | 147 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| connection-client | 148 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| embryonic | 149 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| embryonic-client | 150 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| connection-ps | 151 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| connection-client-ps | 152 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| request-ps | 153 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| request-client-ps | 154 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| partial-request-max | 155 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| partial-request- | 156 | 0 | IESG | RFC 9244 |
| client-max | | | | |
+----------------------+----------+-------+------------+-----------+
| total-attack- | 157 | 5 | IESG | RFC 9244 |
| connection | | | | |
+----------------------+----------+-------+------------+-----------+
| connection-c | 158 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| embryonic-c | 159 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| connection-ps-c | 160 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| request-ps-c | 161 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| attack-detail | 162 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| id | 163 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| attack-id | 164 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| attack-description | 165 | 3 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| attack-severity | 166 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| start-time | 167 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| end-time | 168 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| source-count | 169 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| top-talker | 170 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| spoofed-status | 171 | 7 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| partial-request-c | 172 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| total-attack- | 173 | 4 | IESG | RFC 9244 |
| connection-protocol | | | | |
+----------------------+----------+-------+------------+-----------+
| baseline | 174 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| current-config | 175 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| max-config-values | 176 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| min-config-values | 177 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| supported-unit- | 178 | 5 | IESG | RFC 9244 |
| classes | | | | |
+----------------------+----------+-------+------------+-----------+
| server-originated- | 179 | 7 | IESG | RFC 9244 |
| telemetry | | | | |
+----------------------+----------+-------+------------+-----------+
| telemetry-notify- | 180 | 0 | IESG | RFC 9244 |
| interval | | | | |
+----------------------+----------+-------+------------+-----------+
| tmid | 181 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| measurement-interval | 182 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| measurement-sample | 183 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| talker | 184 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| source-prefix | 185 | 3 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| mid-list | 186 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| source-port-range | 187 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| source-icmp-type- | 188 | 4 | IESG | RFC 9244 |
| range | | | | |
+----------------------+----------+-------+------------+-----------+
| target | 189 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| capacity | 190 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| protocol | 191 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| total-traffic- | 192 | 4 | IESG | RFC 9244 |
| normal-per-protocol | | | | |
+----------------------+----------+-------+------------+-----------+
| total-traffic- | 193 | 4 | IESG | RFC 9244 |
| normal-per-port | | | | |
+----------------------+----------+-------+------------+-----------+
| total-connection- | 194 | 4 | IESG | RFC 9244 |
| capacity-per-port | | | | |
+----------------------+----------+-------+------------+-----------+
| total-traffic- | 195 | 4 | IESG | RFC 9244 |
| protocol | | | | |
+----------------------+----------+-------+------------+-----------+
| total-traffic-port | 196 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| total-attack- | 197 | 4 | IESG | RFC 9244 |
| traffic-protocol | | | | |
+----------------------+----------+-------+------------+-----------+
| total-attack- | 198 | 4 | IESG | RFC 9244 |
| traffic-port | | | | |
+----------------------+----------+-------+------------+-----------+
| total-attack- | 199 | 4 | IESG | RFC 9244 |
| connection-port | | | | |
+----------------------+----------+-------+------------+-----------+
| port | 200 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| supported-query-type | 201 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| vendor-id | 202 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| ietf-dots- | 203 | 5 | IESG | RFC 9244 |
| telemetry:telemetry- | | | | |
| setup | | | | |
+----------------------+----------+-------+------------+-----------+
| ietf-dots- | 204 | 4 | IESG | RFC 9244 |
| telemetry:total- | | | | |
| traffic | | | | |
+----------------------+----------+-------+------------+-----------+
| ietf-dots- | 205 | 4 | IESG | RFC 9244 |
| telemetry:total- | | | | |
| attack-traffic | | | | |
+----------------------+----------+-------+------------+-----------+
| ietf-dots- | 206 | 5 | IESG | RFC 9244 |
| telemetry:total- | | | | |
| attack-connection | | | | |
+----------------------+----------+-------+------------+-----------+
| ietf-dots- | 207 | 4 | IESG | RFC 9244 |
| telemetry:attack- | | | | |
| detail | | | | |
+----------------------+----------+-------+------------+-----------+
| ietf-dots- | 208 | 5 | IESG | RFC 9244 |
| telemetry:telemetry | | | | |
+----------------------+----------+-------+------------+-----------+
| current-g | 209 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| description-lang | 210 | 3 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
Table 4: Registered DOTS Signal Channel CBOR Key Values * Note to the IANA: CBOR keys are assigned from the "128-255" range.
This specification meets the requirements listed in Section 3.1
[RFC9132] for assignments in the "128-255" range.
* Note to the RFC Editor: Please replace all occurrences of
"TBA1-TBA84" with the assigned values.
+----------------------+-------+-------+------------+---------------+
| Parameter Name | CBOR | CBOR | Change | Specification |
| | Key | Major | Controller | Document(s) |
| | Value | Type | | |
+======================+=======+=======+============+===============+
| tsid | TBA1 | 0 | IESG | [RFCXXXX] |
| telemetry | TBA2 | 4 | IESG | [RFCXXXX] |
| low-percentile | TBA3 | 6tag4 | IESG | [RFCXXXX] |
| mid-percentile | TBA4 | 6tag4 | IESG | [RFCXXXX] |
| high-percentile | TBA5 | 6tag4 | IESG | [RFCXXXX] |
| unit-config | TBA6 | 4 | IESG | [RFCXXXX] |
| unit | TBA7 | 0 | IESG | [RFCXXXX] |
| unit-status | TBA8 | 7 | IESG | [RFCXXXX] |
| total-pipe-capacity | TBA9 | 4 | IESG | [RFCXXXX] |
| link-id | TBA10 | 3 | IESG | [RFCXXXX] |
| pre-or-ongoing- | TBA11 | 4 | IESG | [RFCXXXX] |
| mitigation | | | | |
| total-traffic-normal | TBA12 | 4 | IESG | [RFCXXXX] |
| low-percentile-g | TBA13 | 0 | IESG | [RFCXXXX] |
| mid-percentile-g | TBA14 | 0 | IESG | [RFCXXXX] |
| high-percentile-g | TBA15 | 0 | IESG | [RFCXXXX] |
| peak-g | TBA16 | 0 | IESG | [RFCXXXX] |
| total-attack-traffic | TBA17 | 4 | IESG | [RFCXXXX] |
| total-traffic | TBA18 | 4 | IESG | [RFCXXXX] |
| total-connection- | TBA19 | 4 | IESG | [RFCXXXX] |
| capacity | | | | |
| connection | TBA20 | 0 | IESG | [RFCXXXX] |
| connection-client | TBA21 | 0 | IESG | [RFCXXXX] |
| embryonic | TBA22 | 0 | IESG | [RFCXXXX] |
| embryonic-client | TBA23 | 0 | IESG | [RFCXXXX] |
| connection-ps | TBA24 | 0 | IESG | [RFCXXXX] |
| connection-client-ps | TBA25 | 0 | IESG | [RFCXXXX] |
| request-ps | TBA26 | 0 | IESG | [RFCXXXX] |
| request-client-ps | TBA27 | 0 | IESG | [RFCXXXX] |
| partial-request-max | TBA28 | 0 | IESG | [RFCXXXX] |
| partial-request- | TBA29 | 0 | IESG | [RFCXXXX] |
| client-max | | | | |
| total-attack- | TBA30 | 5 | IESG | [RFCXXXX] |
| connection | | | | |
| connection-c | TBA31 | 5 | IESG | [RFCXXXX] |
| embryonic-c | TBA32 | 5 | IESG | [RFCXXXX] |
| connection-ps-c | TBA33 | 5 | IESG | [RFCXXXX] |
| request-ps-c | TBA34 | 5 | IESG | [RFCXXXX] |
| attack-detail | TBA35 | 4 | IESG | [RFCXXXX] |
| id | TBA36 | 0 | IESG | [RFCXXXX] |
| attack-id | TBA37 | 0 | IESG | [RFCXXXX] |
| attack-description | TBA38 | 3 | IESG | [RFCXXXX] |
| attack-severity | TBA39 | 0 | IESG | [RFCXXXX] |
| start-time | TBA40 | 0 | IESG | [RFCXXXX] |
| end-time | TBA41 | 0 | IESG | [RFCXXXX] |
| source-count | TBA42 | 5 | IESG | [RFCXXXX] |
| top-talker | TBA43 | 5 | IESG | [RFCXXXX] |
| spoofed-status | TBA44 | 7 | IESG | [RFCXXXX] |
| partial-request-c | TBA45 | 5 | IESG | [RFCXXXX] |
| total-attack- | TBA46 | 4 | IESG | [RFCXXXX] |
| connection-protocol | | | | |
| baseline | TBA49 | 4 | IESG | [RFCXXXX] |
| current-config | TBA50 | 5 | IESG | [RFCXXXX] |
| max-config-value | TBA51 | 5 | IESG | [RFCXXXX] |
| min-config-values | TBA52 | 5 | IESG | [RFCXXXX] |
|supported-unit-classes| TBA53 | 5 | IESG | [RFCXXXX] |
| server-originated- | TBA54 | 7 | IESG | [RFCXXXX] |
| telemetry | | | | |
| telemetry-notify- | TBA55 | 0 | IESG | [RFCXXXX] |
| interval | | | | |
| tmid | TBA56 | 0 | IESG | [RFCXXXX] |
| measurement-interval | TBA57 | 0 | IESG | [RFCXXXX] |
| measurement-sample | TBA58 | 0 | IESG | [RFCXXXX] |
| talker | TBA59 | 4 | IESG | [RFCXXXX] |
| source-prefix | TBA60 | 3 | IESG | [RFCXXXX] |
| mid-list | TBA61 | 4 | IESG | [RFCXXXX] |
| source-port-range | TBA62 | 4 | IESG | [RFCXXXX] |
| source-icmp-type- | TBA63 | 4 | IESG | [RFCXXXX] |
| range | | | | |
| target | TBA64 | 5 | IESG | [RFCXXXX] |
| capacity | TBA65 | 0 | IESG | [RFCXXXX] |
| protocol | TBA66 | 0 | IESG | [RFCXXXX] |
| total-traffic- | TBA67 | 4 | IESG | [RFCXXXX] |
| normal-per-protocol | | | | |
| total-traffic- | TBA68 | 4 | IESG | [RFCXXXX] |
| normal-per-port | | | | |
| total-connection- | TBA69 | 4 | IESG | [RFCXXXX] |
| capacity-per-port | | | | |
| total-traffic- | TBA70 | 4 | IESG | [RFCXXXX] |
| protocol | | | | |
| total-traffic-port | TBA71 | 4 | IESG | [RFCXXXX] |
| total-attack- | TBA72 | 4 | IESG | [RFCXXXX] |
| traffic-protocol | | | | |
| total-attack- | TBA73 | 4 | IESG | [RFCXXXX] |
| traffic-port | | | | |
| total-attack- | TBA74 | 4 | IESG | [RFCXXXX] |
| connection-port | | | | |
| port | TBA75 | 0 | IESG | [RFCXXXX] |
| supported-query-type | TBA76 | 4 | IESG | [RFCXXXX] |
| vendor-id | TBA77 | 0 | IESG | [RFCXXXX] |
| ietf-dots-telemetry: | TBA78 | 5 | IESG | [RFCXXXX] |
| telemetry-setup | | | | |
| ietf-dots-telemetry: | TBA79 | 4 | IESG | [RFCXXXX] |
| total-traffic | | | | |
| ietf-dots-telemetry: | TBA80 | 4 | IESG | [RFCXXXX] |
| total-attack-traffic | | | | |
| ietf-dots-telemetry: | TBA81 | 5 | IESG | [RFCXXXX] |
| total-attack- | | | | |
| connection | | | | |
| ietf-dots-telemetry: | TBA82 | 4 | IESG | [RFCXXXX] |
| attack-detail | | | | |
| ietf-dots-telemetry: | TBA83 | 5 | IESG | [RFCXXXX] |
| telemetry | | | | |
| current-g | TBA84 | 0 | IESG | [RFCXXXX] |
| description-lang | TBA85 | 3 | IESG | [RFCXXXX] |
+----------------------+-------+-------+------------+---------------+
Table 4: Registered DOTS Signal Channel CBOR Key Values
13.2. DOTS Signal Channel Conflict Cause Codes 13.2. DOTS Signal Channel Conflict Cause Codes
Per this document, IANA has assigned a new code from the "DOTS Signal This specification requests IANA to assign a new code from the "DOTS
Channel Conflict Cause Codes" registry [Cause]. Signal Channel Conflict Cause Codes" registry [Cause].
+======+===================+========================+===========+ +------+-------------------+------------------------+-------------+
| Code | Label | Description | Reference | | Code | Label | Description | Reference |
+======+===================+========================+===========+ +======+===================+========================+=============+
| 5 | overlapping-pipes | Overlapping pipe scope | RFC 9244 | | TBA | overlapping-pipes | Overlapping pipe scope | [RFCXXXX] |
+------+-------------------+------------------------+-----------+ +------+-------------------+------------------------+-------------+
Table 5: Registered DOTS Signal Channel Conflict Cause Code Table 5: Registered DOTS Signal Channel Conflict Cause Code
13.3. DOTS Telemetry URIs and YANG Module Registrations * Note to the RFC Editor: Please replace all occurrences of "TBA"
with the assigned value.
Per this document, IANA has registered the following URIs in the "ns" 13.3. DOTS Signal Telemetry YANG Module
subregistry within the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry This document requests IANA to register the following URIs in the
Registrant Contact: The IESG. "ns" subregistry within the "IETF XML Registry" [RFC3688]:
XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-dots-mapping URI: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
Per this document, IANA has registered the following YANG modules in URI: urn:ietf:params:xml:ns:yang:ietf-dots-mapping
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG modules in
the "YANG Module Names" subregistry [RFC6020] within the "YANG the "YANG Module Names" subregistry [RFC6020] within the "YANG
Parameters" registry. Parameters" registry.
Name: ietf-dots-telemetry name: ietf-dots-telemetry
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry namespace: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry
Maintained by IANA: N maintained by IANA: N
Prefix: dots-telemetry prefix: dots-telemetry
Reference: RFC 9244 reference: RFC XXXX
Name: ietf-dots-mapping name: ietf-dots-mapping
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-mapping namespace: urn:ietf:params:xml:ns:yang:ietf-dots-mapping
Maintained by IANA: N maintained by IANA: N
Prefix: dots-mapping prefix: dots-mapping
Reference: RFC 9244 reference: RFC XXXX
14. Security Considerations 14. Security Considerations
14.1. DOTS Signal Channel Telemetry 14.1. DOTS Signal Channel Telemetry
The security considerations for the DOTS signal channel protocol are The security considerations for the DOTS signal channel protocol are
discussed in Section 11 of [RFC9132]. The following discusses the discussed in Section 11 of [RFC9132]. The following discusses the
security considerations that are specific to the DOTS signal channel security considerations that are specific to the DOTS signal channel
extension defined in this document. extension defined in this document.
The DOTS telemetry information includes DOTS client network topology, The DOTS telemetry information includes DOTS client network topology,
DOTS client domain pipe capacity, normal traffic baseline and DOTS client domain pipe capacity, normal traffic baseline and
connection capacity, and threat and mitigation information. Such connections' capacity, and threat and mitigation information. Such
information is sensitive; it MUST be protected at rest by the DOTS information is sensitive; it MUST 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 than the need for the aforementioned significant considerations other that 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. mitigate attacks.
DOTS clients are typically considered to be trusted devices by the DOTS clients are typically considered to be trusted devices by the
DOTS client domain. DOTS clients may be co-located on network DOTS client domain. DOTS clients may be co-located on network
security services (e.g., firewall devices), and a compromised security services (e.g., firewall devices), and a compromised
security service potentially can do a lot more damage to the network security service potentially can do a lot more damage to the network
than just the DOTS client component. This assumption differs from than just the DOTS client component. This assumption differs from
the often-held view (often referred to as the "zero-trust model") the often held view that devices are untrusted, often referred to as
that devices are untrusted. A compromised DOTS client can send fake the "zero-trust model". A compromised DOTS client can send fake DOTS
DOTS telemetry data to a DOTS server to mislead the DOTS server. telemetry data to a DOTS server to mislead the DOTS server. This
This attack can be prevented by monitoring and auditing DOTS clients attack can be prevented by monitoring and auditing DOTS clients to
to detect misbehavior and to deter misuse, and by only authorizing detect misbehavior and to deter misuse, and by only authorizing the
the DOTS client to convey DOTS telemetry information for specific DOTS client to convey DOTS telemetry information for specific target
target resources (e.g., an application server is authorized to resources (e.g., an application server is authorized to exchange DOTS
exchange DOTS telemetry for its IP addresses but a DDoS mitigator can telemetry for its IP addresses but a DDoS mitigator can exchange DOTS
exchange DOTS telemetry for any target resource in the network). As telemetry for any target resource in the network). As a reminder,
a reminder, this is a variation of dealing with compromised DOTS this is a variation of dealing with compromised DOTS clients as
clients as discussed in Section 11 of [RFC9132]. discussed in Section 11 of [RFC9132].
DOTS servers must be capable of defending themselves against DoS DOTS servers must be capable of defending themselves against DoS
attacks from compromised DOTS clients. The following non- attacks from compromised DOTS clients. The following non-
comprehensive list of mitigation techniques can be used by a DOTS comprehensive list of mitigation techniques can be used by a DOTS
server to handle misbehaving DOTS clients: server to handle misbehaving DOTS clients:
* The probing rate (defined in Section 4.5 of [RFC9132]) can be used * The probing rate (defined in Section 4.5 of [RFC9132]) can be used
to limit the average data rate to the DOTS server. to limit the average data rate to the DOTS server.
* Rate-limiting DOTS telemetry, including packets with new 'tmid' * Rate-limiting DOTS telemetry, including those with new 'tmid'
values from the same DOTS client, defends against DoS attacks that 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 time resources. Likewise, the DOTS server can enforce a quota and
limit on the number of active pre-or-ongoing-mitigation telemetry time-limit on the number of active pre-or-ongoing-mitigation
data items (identified by 'tmid') from the DOTS client. telemetry data items (identified by 'tmid') from the DOTS client.
Note also that the telemetry notification interval may be used to Note also that telemetry notification interval may be used to rate-
rate-limit the pre-or-ongoing-mitigation telemetry notifications limit the pre-or-ongoing-mitigation telemetry notifications received
received by a DOTS client domain. by a DOTS client domain.
14.2. Vendor Attack Mapping 14.2. Vendor Attack Mapping
The security considerations for the DOTS data channel protocol are The security considerations for the DOTS data channel protocol are
discussed in Section 10 of [RFC8783]. The following discusses the discussed in Section 10 of [RFC8783]. The following discusses the
security considerations that are specific to the DOTS data channel security considerations that are specific to the DOTS data channel
extension defined in this document. extension defined in this document.
All data nodes defined in the YANG module specified in Section 11.2 All data nodes defined in the YANG module specified in Section 11.2
that can be created, modified, and deleted (i.e., config true, which which can be created, modified, and deleted (i.e., config true, which
is the default) are considered sensitive. Write operations to these is the default) are considered sensitive. Write operations to these
data nodes without proper protection can have a negative effect on data nodes without proper protection can have a negative effect on
network operations. Appropriate security measures are recommended to network operations. Appropriate security measures are recommended to
prevent illegitimate users from invoking DOTS data channel primitives prevent illegitimate users from invoking DOTS data channel primitives
as discussed in [RFC8783]. Nevertheless, an attacker who can access as discussed in [RFC8783]. Nevertheless, an attacker who can access
a DOTS client is technically capable of undertaking various attacks, a DOTS client is technically capable of undertaking various attacks,
such as: such as:
* Communicating invalid attack mapping details to the server * Communicating invalid attack mapping details to the server
('/data-channel:dots-data/data-channel:dots-client/dots- ('/data-channel:dots-data/data-channel:dots-client/dots-
skipping to change at line 5382 skipping to change at page 115, line 5
* '/data-channel:dots-data/data-channel:dots-client/dots- * '/data-channel:dots-data/data-channel:dots-client/dots-
telemetry:vendor-mapping' can be misused to infer the DDoS telemetry:vendor-mapping' can be misused to infer the DDoS
protection technology deployed in a DOTS client domain. protection technology deployed in a DOTS client domain.
* '/data-channel:dots-data/dots-telemetry:vendor-mapping' can be * '/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 Section 14.1. compromised DOTS client attacks discussed in Section 14.1.
15. References 15. Contributors
15.1. Normative References The following individuals have contributed to this document:
* Li Su, CMCC, Email: suli@chinamobile.com
* Pan Wei, Huawei, Email: william.panwei@huawei.com
16. Acknowledgements
The authors would like to thank Flemming Andreasen, Liang Xia, and
Kaname Nishizuka, co-authors of [I-D.doron-dots-telemetry], and
everyone who had contributed to that document.
Thanks to Kaname Nishizuka, Wei Pan, Yuuhei Hayashi, and Tom Petch
for comments and review.
Special thanks to Jon Shallow and Kaname Nishizuka for their
implementation and interoperability work.
Many thanks to Jan Lindblad for the yangdoctors review, Nagendra
Nainar for the opsdir review, James Gruessing for the artart review,
Michael Scharf for the tsv-art review, Ted Lemon for the int-dir
review, and Robert Sparks for the gen-art review.
Thanks to Benjamin Kaduk for the detailed AD review.
Thanks to Roman Danyliw, Eric Vyncke, Francesca Palombini, Warren
Kumari, Erik Kline, Lars Eggert, and Robert Wilton for the IESG
review.
17. References
17.1. Normative References
[Private-Enterprise-Numbers] [Private-Enterprise-Numbers]
IANA, "Private Enterprise Numbers", "Private Enterprise Numbers", 4 May 2020,
<https://www.iana.org/assignments/enterprise-numbers/>. <https://www.iana.org/assignments/enterprise-numbers>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
skipping to change at line 5468 skipping to change at page 117, line 25
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K,
"Distributed Denial-of-Service Open Threat Signaling "Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification", RFC 9132, (DOTS) Signal Channel Specification", RFC 9132,
DOI 10.17487/RFC9132, September 2021, DOI 10.17487/RFC9132, September 2021,
<https://www.rfc-editor.org/info/rfc9132>. <https://www.rfc-editor.org/info/rfc9132>.
15.2. Informative References 17.2. Informative References
[Cause] IANA, "DOTS Signal Channel Conflict Cause Codes", [Cause] IANA, "DOTS Signal Channel Conflict Cause Codes",
<https://www.iana.org/assignments/dots/>. <https://www.iana.org/assignments/dots/dots.xhtml#dots-
signal-channel-conflict-cause-codes>.
[DOTS-Multihoming] [I-D.doron-dots-telemetry]
Doron, E., Reddy, T., Andreasen, F., (Frank), L. X., and
K. Nishizuka, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry Specifications", Work in
Progress, Internet-Draft, draft-doron-dots-telemetry-00,
30 October 2016, <https://www.ietf.org/archive/id/draft-
doron-dots-telemetry-00.txt>.
[I-D.ietf-core-new-block]
Boucadair, M. and J. Shallow, "Constrained Application
Protocol (CoAP) Block-Wise Transfer Options Supporting
Robust Transmission", Work in Progress, Internet-Draft,
draft-ietf-core-new-block-14, 26 May 2021,
<https://www.ietf.org/archive/id/draft-ietf-core-new-
block-14.txt>.
[I-D.ietf-dots-multihoming]
Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing
Deployment Considerations for Distributed-Denial-of- Deployment Considerations for Distributed-Denial-of-
Service Open Threat Signaling (DOTS)", Work in Progress, Service Open Threat Signaling (DOTS)", Work in Progress,
Internet-Draft, draft-ietf-dots-multihoming-13, 26 April Internet-Draft, draft-ietf-dots-multihoming-11, 10
2022, <https://datatracker.ietf.org/doc/html/draft-ietf- February 2022, <https://www.ietf.org/archive/id/draft-
dots-multihoming-13>. ietf-dots-multihoming-11.txt>.
[DOTS-Robust-Blocks] [I-D.ietf-dots-robust-blocks]
Boucadair, M. and J. Shallow, "Distributed Denial-of- Boucadair, M. and J. Shallow, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel Service Open Threat Signaling (DOTS) Signal Channel
Configuration Attributes for Robust Block Transmission", Configuration Attributes for Robust Block Transmission",
Work in Progress, Internet-Draft, draft-ietf-dots-robust- Work in Progress, Internet-Draft, draft-ietf-dots-robust-
blocks-03, 11 February 2022, blocks-03, 11 February 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-dots- <https://www.ietf.org/archive/id/draft-ietf-dots-robust-
robust-blocks-03>. blocks-03.txt>.
[DOTS-Telemetry-Specs]
Doron, E., Reddy, T., Andreasen, F., Xia, L., and K.
Nishizuka, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry Specifications", Work in
Progress, Internet-Draft, draft-doron-dots-telemetry-00,
30 October 2016, <https://datatracker.ietf.org/doc/html/
draft-doron-dots-telemetry-00>.
[Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values",
<https://www.iana.org/assignments/dots/>. <https://www.iana.org/assignments/dots/dots.xhtml#dots-
signal-channel-cbor-key-values>.
[PYANG] "pyang", commit dad5c68, April 2022, [PYANG] "pyang", November 2020,
<https://github.com/mbj4668/pyang>. <https://github.com/mbj4668/pyang>.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998, DOI 10.17487/RFC2330, May 1998,
<https://www.rfc-editor.org/info/rfc2330>. <https://www.rfc-editor.org/info/rfc2330>.
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
Denial-of-Service Considerations", RFC 4732, Denial-of-Service Considerations", RFC 4732,
DOI 10.17487/RFC4732, December 2006, DOI 10.17487/RFC4732, December 2006,
<https://www.rfc-editor.org/info/rfc4732>. <https://www.rfc-editor.org/info/rfc4732>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.
[RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for
Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August
2009, <https://www.rfc-editor.org/info/rfc5612>. 2009, <https://www.rfc-editor.org/info/rfc5612>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
and R. Wilton, "YANG Library", RFC 8525, and R. Wilton, "YANG Library", RFC 8525,
skipping to change at line 5548 skipping to change at page 119, line 31
L., and K. Nishizuka, "Use Cases for DDoS Open Threat L., and K. Nishizuka, "Use Cases for DDoS Open Threat
Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021, Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021,
<https://www.rfc-editor.org/info/rfc8903>. <https://www.rfc-editor.org/info/rfc8903>.
[RFC9133] Nishizuka, K., Boucadair, M., Reddy.K, T., and T. Nagata, [RFC9133] Nishizuka, K., Boucadair, M., Reddy.K, T., and T. Nagata,
"Controlling Filtering Rules Using Distributed Denial-of- "Controlling Filtering Rules Using Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel", Service Open Threat Signaling (DOTS) Signal Channel",
RFC 9133, DOI 10.17487/RFC9133, September 2021, RFC 9133, DOI 10.17487/RFC9133, September 2021,
<https://www.rfc-editor.org/info/rfc9133>. <https://www.rfc-editor.org/info/rfc9133>.
[RFC9177] Boucadair, M. and J. Shallow, "Constrained Application
Protocol (CoAP) Block-Wise Transfer Options Supporting
Robust Transmission", RFC 9177, DOI 10.17487/RFC9177,
March 2022, <https://www.rfc-editor.org/info/rfc9177>.
[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
June 2022, <https://www.rfc-editor.org/info/rfc9260>.
Acknowledgments
The authors would like to thank Flemming Andreasen, Liang Xia, and
Kaname Nishizuka, coauthors of [DOTS-Telemetry-Specs], and everyone
who had contributed to that document.
Thanks to Kaname Nishizuka, Yuhei Hayashi, and Tom Petch for comments
and review.
Special thanks to Jon Shallow and Kaname Nishizuka for their
implementation and interoperability work.
Many thanks to Jan Lindblad for the yangdoctors review, Nagendra
Nainar for the opsdir review, James Gruessing for the artart review,
Michael Scharf for the tsv-art review, Ted Lemon for the int-dir
review, and Robert Sparks for the gen-art review.
Thanks to Benjamin Kaduk for the detailed AD review.
Thanks to Roman Danyliw, Éric Vyncke, Francesca Palombini, Warren
Kumari, Erik Kline, Lars Eggert, and Robert Wilton for the IESG
review.
Contributors
The following individuals have contributed to this document:
Li Su
CMCC
Email: suli@chinamobile.com
Pan Wei
Huawei
Email: william.panwei@huawei.com
Authors' Addresses Authors' Addresses
Mohamed Boucadair (editor) Mohamed Boucadair (editor)
Orange Orange
35000 Rennes 35000 Rennes
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Tirumaleswar Reddy.K (editor) Tirumaleswar Reddy.K (editor)
Akamai Akamai
skipping to change at line 5607 skipping to change at page 120, line 4
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Tirumaleswar Reddy.K (editor) Tirumaleswar Reddy.K (editor)
Akamai Akamai
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore 560071 Bangalore 560071
Karnataka Karnataka
India India
Email: kondtir@gmail.com Email: kondtir@gmail.com
Ehud Doron Ehud Doron
Radware Ltd. Radware Ltd.
Raoul Wallenberg Street Raoul Wallenberg Street
Tel-Aviv 69710 Tel-Aviv 69710
Israel Israel
Email: ehudd@radware.com Email: ehudd@radware.com
Meiling Chen Meiling Chen
CMCC CMCC
32 Xuanwumen West Street 32, Xuanwumen West
Beijing BeiJing
100053 BeiJing, 100053
China China
Email: chenmeiling@chinamobile.com Email: chenmeiling@chinamobile.com
Jon Shallow Jon Shallow
United Kingdom United Kingdom
Email: supjps-ietf@jpshallow.com Email: supjps-ietf@jpshallow.com
 End of changes. 418 change blocks. 
1463 lines changed or deleted 1248 lines changed or added

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