< draft-ietf-dots-telemetry-19.txt   draft-ietf-dots-telemetry-20.txt >
DOTS M. Boucadair, Ed. DOTS M. Boucadair, Ed.
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track T. Reddy, Ed. Intended status: Standards Track T. Reddy.K, Ed.
Expires: 8 July 2022 Akamai Expires: 28 July 2022 Akamai
E. Doron E. Doron
Radware Ltd. Radware Ltd.
M. Chen M. Chen
CMCC CMCC
J. Shallow J. Shallow
4 January 2022 24 January 2022
Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
draft-ietf-dots-telemetry-19 draft-ietf-dots-telemetry-20
Abstract Abstract
This document aims to enrich the DOTS signal channel protocol with This document aims to enrich the DOTS signal channel protocol with
various telemetry attributes, allowing for optimal Distributed various telemetry attributes, allowing for optimal Distributed
Denial-of-Service (DDoS) attack mitigation. It specifies the normal Denial-of-Service (DDoS) attack mitigation. It specifies the normal
traffic baseline and attack traffic telemetry attributes a DOTS traffic baseline and attack traffic telemetry attributes a DOTS
client can convey to its DOTS server in the mitigation request, the client can convey to its DOTS server in the mitigation request, the
mitigation status telemetry attributes a DOTS server can communicate mitigation status telemetry attributes a DOTS server can communicate
to a DOTS client, and the mitigation efficacy telemetry attributes a to a DOTS client, and the mitigation efficacy telemetry attributes a
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 July 2022. This Internet-Draft will expire on 28 July 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. DOTS Telemetry: Overview and Purpose . . . . . . . . . . . . 6 3. DOTS Telemetry: Overview and Purpose . . . . . . . . . . . . 7
3.1. Need More Visibility . . . . . . . . . . . . . . . . . . 7 3.1. Need More Visibility . . . . . . . . . . . . . . . . . . 7
3.2. Enhanced Detection . . . . . . . . . . . . . . . . . . . 8 3.2. Enhanced Detection . . . . . . . . . . . . . . . . . . . 8
3.3. Efficient Mitigation . . . . . . . . . . . . . . . . . . 9 3.3. Efficient Mitigation . . . . . . . . . . . . . . . . . . 10
4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Overview of Telemetry Operations . . . . . . . . . . . . 10 4.1. Overview of Telemetry Operations . . . . . . . . . . . . 10
4.2. Generic Considerations . . . . . . . . . . . . . . . . . 11 4.2. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 12
4.2.1. DOTS Client Identification . . . . . . . . . . . . . 11 4.3. DOTS Multi-homing Considerations . . . . . . . . . . . . 12
4.2.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . 12 4.4. YANG Considerations . . . . . . . . . . . . . . . . . . . 12
4.2.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . 12 5. Generic Considerations . . . . . . . . . . . . . . . . . . . 14
4.2.4. Controlling Configuration Data . . . . . . . . . . . 12 5.1. DOTS Client Identification . . . . . . . . . . . . . . . 14
4.3. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 12 5.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . . . 14
4.4. DOTS Multi-homing Considerations . . . . . . . . . . . . 13 5.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . . . 14
4.5. YANG Considerations . . . . . . . . . . . . . . . . . . . 13 5.4. Controlling Configuration Data . . . . . . . . . . . . . 14
4.6. A Note About Examples . . . . . . . . . . . . . . . . . . 14 5.5. Message Validation . . . . . . . . . . . . . . . . . . . 15
5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 15 5.6. A Note About Examples . . . . . . . . . . . . . . . . . . 15
6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 16 6. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 15
6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 16 7. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 16
6.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 17 7.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 17
6.1.2. Conveying DOTS Telemetry Configuration . . . . . . . 19 7.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 18
6.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 22 7.1.2. Conveying DOTS Telemetry Configuration . . . . . . . 20
6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 23 7.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 23
6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 23 7.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 24
6.2.1. Conveying DOTS Client Domain Pipe Capacity . . . . . 24 7.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 24
6.2.2. Retrieve Installed DOTS Client Domain Pipe 7.2.1. Conveying DOTS Client Domain Pipe Capacity . . . . . 25
Capacity . . . . . . . . . . . . . . . . . . . . . . 30 7.2.2. Retrieve Installed DOTS Client Domain Pipe
6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 30 Capacity . . . . . . . . . . . . . . . . . . . . . . 31
6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 30 7.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 31
6.3.1. Conveying DOTS Client Domain Baseline Information . . 33 7.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 31
6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 37 7.3.1. Conveying DOTS Client Domain Baseline Information . . 34
6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 37 7.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 38
6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 37 7.3.3. Delete Installed Normal Traffic Baseline . . . . . . 38
6.5. Conflict with Other DOTS Clients of the Same Domain . . . 37 7.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 38
7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 38 7.5. Conflict with Other DOTS Clients of the Same Domain . . . 38
7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 41 8. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 39
7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 41 8.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 41
7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 42 8.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 42
7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 44 8.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 43
7.1.4. Total Attack Connections . . . . . . . . . . . . . . 46 8.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 45
7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 48 8.1.4. Total Attack Connections . . . . . . . . . . . . . . 47
7.1.6. Vendor Attack Mapping . . . . . . . . . . . . . . . . 51 8.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 49
7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 55 8.1.6. Vendor Attack Mapping . . . . . . . . . . . . . . . . 52
7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 58 8.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 56
8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 63 8.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 59
8.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry 9. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 64
Attributes . . . . . . . . . . . . . . . . . . . . . . . 63 9.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry
8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry Attributes . . . . . . . . . . . . . . . . . . . . . . . 64
Attributes . . . . . . . . . . . . . . . . . . . . . . . 65 9.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry
9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 69 Attributes . . . . . . . . . . . . . . . . . . . . . . . 66
10. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 70 10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 70
10.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . 70 11. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 71
10.2. Vendor Attack Mapping Details YANG Module . . . . . . . 99 11.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . 71
11. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 102 11.2. Vendor Attack Mapping Details YANG Module . . . . . . . 100
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105 12. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 103
12.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 105 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106
12.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 108 13.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 106
12.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 108 13.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 109
13. Security Considerations . . . . . . . . . . . . . . . . . . . 109 13.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 109
13.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 109 14. Security Considerations . . . . . . . . . . . . . . . . . . . 110
13.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 110 14.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 110
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 111 14.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 111
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 111 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 112
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 112 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 112
16.1. Normative References . . . . . . . . . . . . . . . . . . 112 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 112
16.2. Informative References . . . . . . . . . . . . . . . . . 113 17.1. Normative References . . . . . . . . . . . . . . . . . . 112
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 115 17.2. Informative References . . . . . . . . . . . . . . . . . 114
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 116
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/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, but rather to prevent taking down the actual delivered services, but rather to prevent
various network elements (routers, switches, firewalls, transit various network elements (routers, switches, firewalls, transit
skipping to change at page 5, line 38 skipping to change at page 5, line 38
DOTS server is handling 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 in relevant management, reporting, and presenting various information in relevant management, 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]. Nevertheless, when DOTS telemetry attributes are protocol [RFC9132]. When no limitation policy is provided to a DOTS
available to a DOTS agent, and absent any limitation by policy, it agent, it can signal available telemetry attributes to it peers in
can signal the attributes in order to optimize the overall mitigation order to optimize the overall mitigation service provisioned using
service provisioned using DOTS. The aforementioned policy can be, DOTS. The aforementioned policy can be, for example, agreed during a
for example, agreed during a service subscription (that is out of service subscription (that is out of scope) to identify a subset of
scope) to identify a subset of DOTS clients among those deployed in a DOTS clients among those deployed in a DOTS client domain that are
DOTS client domain that are allowed to send or receive telemetry allowed to send or receive telemetry data.
data.
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 BCP "OPTIONAL" in this document are to be interpreted as described in 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].
skipping to change at page 6, line 33 skipping to change at page 6, line 25
configuration data. configuration data.
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. communicated prior to or during a mitigation.
When two telemetry requests overlap, "overlapped" lower numeric When two telemetry requests overlap, "overlapped" lower numeric
'tsid' (or 'tmid') refers to the lower 'tsid' (or 'tmid') value of 'tsid' (or 'tmid') refers to the lower 'tsid' (or 'tmid') value of
these overlapping requests. these overlapping requests.
The term "pipe" represents the maximum level of traffic that the DOTS
client domain can receive. Whether a "pipe" is mapped to one or a
group of network interfaces is deployment-specific. For example,
each interconnection link may be considered as a specific pipe if the
DOTS server is hosted by each upstream provider, whike the aggregate
of all links to connect to upstream network providers can be
considered by a DOTS client domain as a single pipe when
communicating with a DOTS server not hosted by these upstream
providers.
The document uses IANA-assigned Enterprise Numbers. These numbers
are also known as "Private Enterprise Numbers" and "SMI (Structure of
Management Information) Network Management Private Enterprise Codes"
[Private-Enterprise-Numbers].
The meaning 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 7.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 backslash ('\') as the last character, the line is wrapped ends with backslash ('\') as the last character, the line is wrapped
for display purposes. It is to be considered to be joined to the for display purposes. It is to be considered to be joined to the
next line by deleting the backslash, the following line break, and next line by deleting the backslash, the following line break, and
the leading whitespace of the next line. the leading 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
skipping to change at page 9, line 33 skipping to change at page 9, line 40
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.
In addition, baseline learning requires a period of time that Of course, this information can be provided using out-of-band
cannot be afforded during active attack. mechanisms or manual configuration at the risk of unmaintained
information becoming inaccurate as the network evolves and "normal"
Of course, this information can provided using out-of-band mechanisms patterns change. The use of a dynamic and collaborative means
or manual configuration at the risk of unmaintained information between the DOTS client and server to identify and share key
becoming inaccurate as the network evolves and "normal" patterns parameters for the sake of efficient DDoS protection is valuable.
change. The use of a dynamic and collaborative means between the
DOTS client and server to identify and share key 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 towards 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. Dynamic DOTS client domain can absorb from its upstream network. Dynamic
updates of the condition of pipes between DOTS agents while they are updates of the condition of pipes between DOTS agents while they are
under a DDoS attack is essential (e.g., where multiple DOTS clients under a DDoS attack is essential (e.g., where multiple DOTS clients
share the same physical connectivity pipes). It is important to note share the same physical connectivity pipes). The DOTS server should
that the term "pipe" noted here does not necessary represent physical activate other mechanisms to ensure it does not allow the DOTS client
pipe, but rather represents the maximum level of traffic that the domain's pipes to be saturated unintentionally. The rate-limit
DOTS client domain can receive. The DOTS server should activate action defined in [RFC8783] is a reasonable candidate to achieve this
other mechanisms to ensure it does not allow the DOTS client domain's objective; the DOTS client can indicate the type(s) of traffic (such
pipes to be saturated unintentionally. The rate-limit action defined as ICMP, UDP, TCP port number 80) it prefers to limit. The rate-
in [RFC8783] is a reasonable candidate to achieve this objective; the limit action can be controlled via the signal channel [RFC9133] even
DOTS client can indicate the type(s) of traffic (such as ICMP, UDP, when the pipe is overwhelmed.
TCP port number 80) it prefers to limit. The rate-limit action can
be controlled via the signal channel [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, e.g., saturate one even in the face of attack traffic that might, e.g., saturate one
skipping to change at page 10, line 43 skipping to change at page 10, line 51
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 truly require reliable delivery during an attack. small messages that are important to deliver during an attack. As a
reminder, both DOTS signal and data channels require secure
communication channels (Section 11 of [RFC9132] and Section 10 of
[RFC8783]).
Telemetry information has aspects that correspond to both operational Telemetry information has aspects that correspond to both operational
modes (i.e., signal and data channels): there is certainly a need to modes (i.e., signal and data channels): there is certainly a need to
convey updated information about ongoing attack traffic and targets convey updated information about ongoing attack traffic and 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, but it is also useful to provide mitigation face of adaptive attacks, but it is also useful to provide mitigation
services with a picture of normal or "baseline" traffic towards services with a picture of normal or "baseline" traffic towards
potential targets, to aid in detecting when incoming traffic deviates potential targets, to aid in detecting when incoming traffic deviates
from normal into being an attack. Also, one might populate a from normal into being an attack. Also, one might populate a
"database" of classifications of known types of attack so that a "database" of classifications of known types of attack so that a
short attack identifier can be used during attack time to describe an short attack identifier can be used during attack time to describe an
observed attack. This specification does make provision for use of observed attack. This specification does make provision for use of
the DOTS data channel for the latter function (Section 7.1.6), but the DOTS data channel for the latter function (Section 8.1.6), but
otherwise retains most telemetry functionality in the DOTS signal otherwise retains most telemetry functionality in 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
use of the DOTS signal channel are specified in [RFC9132]. use of the DOTS signal channel are specified in [RFC9132].
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 6. DOTS agents can then include DOTS telemetry attributes Section 7. DOTS agents can then include DOTS telemetry attributes
using the DOTS signal channel (Section 7.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 7.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 7.3. The DOTS client can then decide to send a mitigation Section 8.3. The DOTS client can then decide to send a mitigation
request if the notified attack cannot be mitigated locally within the request if the notified attack cannot be mitigated 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 8.1) or mitigation update (Section 8.2) messages. (Section 9.1) or mitigation update (Section 9.2) messages.
4.2. Generic Considerations
4.2.1. DOTS Client Identification
Following the rules in Section 4.4.1 of [RFC9132], a unique
identifier is generated by a DOTS client to prevent request
collisions ('cuid').
As a reminder, [RFC9132] forbids 'cuid' to be returned in a response
message body.
4.2.2. DOTS Gateways
DOTS gateways may be located between DOTS clients and servers. The
considerations elaborated in Section 4.4.1 of [RFC9132] must be
followed. In particular, 'cdid' attribute is used to unambiguously
identify a DOTS client domain.
As a reminder, Section 4.4.1.3 of [RFC9132] forbids 'cdid' (if
present) to be returned in a response message body.
4.2.3. Empty URI Paths
Uri-Path parameters and attributes with empty values MUST NOT be
present in a request. The presence of such an empty value renders
the entire containing message invalid.
4.2.4. Controlling Configuration Data
The DOTS server follows the same considerations discussed in
Section of 4.5.3 of [RFC9132] for managing DOTS telemetry
configuration freshness and notification.
Likewise, a DOTS client may control the selection of configuration
and non-configuration data nodes when sending a GET request by means
of the 'c' Uri-Query option and following the procedure specified in
Section of 4.4.2 of [RFC9132]. These considerations are not
reiterated in the following sections.
4.3. Block-wise Transfer 4.2. Block-wise Transfer
DOTS clients can use 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 CoAP Block1 Option in a PUT request DOTS clients can also use CoAP Block1 Option in a PUT request
(Section 2.5 of [RFC7959]) to initiate large transfers, but these (Section 2.5 of [RFC7959]) to initiate large transfers, but these
Block1 transfers are likely to fail if the inbound "pipe" is running Block1 transfers are likely to fail if the inbound "pipe" is running
full because the transfer requires a message from the server for each full because the transfer requires a message from the server for each
skipping to change at page 13, line 11 skipping to change at page 12, line 27
Consideration needs to be made to try to fit this PUT into a single Consideration needs to be made to try to fit this PUT into a single
transfer or to separate out the PUT into several discrete PUTs where transfer or to separate out the PUT into 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
[I-D.ietf-core-new-block]. DOTS implementations can consider the use [I-D.ietf-core-new-block]. DOTS implementations can consider the use
of Q-Block1 and Q-Block2 Options [I-D.ietf-dots-robust-blocks]. of Q-Block1 and Q-Block2 Options [I-D.ietf-dots-robust-blocks].
4.4. DOTS Multi-homing Considerations 4.3. DOTS Multi-homing Considerations
Multi-homed DOTS clients are assumed to follow the recommendations in Considerations for multi-homed DOTS clients to select which DOTS
[I-D.ietf-dots-multihoming] to select which DOTS server to contact server to contact and which IP prefixes to include in a telemetry
and which IP prefixes to include in a telemetry message to a given message to a given peer DOTS server are discussed in
peer DOTS server. 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 share it with a second DOTS server are implementation DOTS server and share it with a second DOTS server are implementation
and deployment specific. and deployment specific.
4.5. 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
which 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 10.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 11. 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 10.1) is not intended to be used The DOTS telemetry module (Section 11.1) is not intended to be used
via NETCONF/RESTCONF for DOTS server management purposes. It serves via NETCONF/RESTCONF for DOTS server management purposes. It serves
only to provide a data model and encoding following [RFC8791]. only to provide a data model and encoding following [RFC8791].
Server deviations are strongly discouraged, as the peer DOTS agent Server deviations are strongly discouraged, as the peer DOTS agent
does not have means to retrieve the list of deviations and thus does not have means to retrieve the list of deviations and thus
interoperability issues are likely to be encountered. interoperability issues are likely to be encountered.
The DOTS telemetry module (Section 10.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 a message compactness standpoint; one of the key suboptimal from a message compactness standpoint; one of the key
requirements for DOTS Signal Channel messages. requirements for DOTS Signal Channel messages.
The DOTS telemetry module (Section 10.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 with which no key statement is included. This behavior is compliant with
[RFC8791]. The reason for not including these keys is because they [RFC8791]. The reason for not including these keys is because they
are not included in the request message body but as mandatory Uri- are not included in the message body of DOTS requests; such keys are
Paths in requests (Sections 6 and 7). Otherwise, whenever a key included as mandatory Uri-Paths in requests (Sections 7 and 8).
statement is used in the module, the same definition as in Otherwise, whenever a key statement is used in the module, the same
Section 7.8.2 of [RFC7950] is assumed. definition as in Section 7.8.2 of [RFC7950] is assumed.
Some parameters (e.g., low percentile values) may be associated with
different YANG types (e.g., decimal64 and yang:gauge64). To easily
distinguish the types of these parameters while using meaningful
names, the following suffixes are used:
+========+==============+==================+
| Suffix | YANG Type | Example |
+========+==============+==================+
| -g | yang:gauge64 | low-percentile-g |
+--------+--------------+------------------+
| -c | container | connection-c |
+--------+--------------+------------------+
| -ps | per second | connection-ps |
+--------+--------------+------------------+
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,
the document specifies a second YANG module ("ietf-dots-mapping", the document specifies a second YANG module ("ietf-dots-mapping",
Section 10.2) that augments the DOTS data channel [RFC8783]. This Section 11.2) that augments the DOTS data channel [RFC8783]. 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 7.1.5). DOTS clients can use tools, e.g., mapping details (Section 8.1.5). DOTS clients can use tools, e.g.,
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.
4.6. A Note About Examples 5. Generic Considerations
Examples are provided for illustration purposes. The document does 5.1. DOTS Client Identification
not aim to provide a comprehensive list of message examples.
Following the rules in Section 4.4.1 of [RFC9132], a unique
identifier is generated by a DOTS client to prevent request
collisions ('cuid').
As a reminder, [RFC9132] forbids 'cuid' to be returned in a response
message body.
5.2. DOTS Gateways
DOTS gateways may be located between DOTS clients and servers. The
considerations elaborated in Section 4.4.1 of [RFC9132] must be
followed. In particular, 'cdid' attribute is used to unambiguously
identify a DOTS client domain.
As a reminder, Section 4.4.1.3 of [RFC9132] forbids 'cdid' (if
present) to be returned in a response message body.
5.3. Empty URI Paths
Uri-Path parameters and attributes with empty values MUST NOT be
present in a request. The presence of such an empty value renders
the entire containing message invalid.
5.4. Controlling Configuration Data
The DOTS server follows the same considerations discussed in
Section of 4.5.3 of [RFC9132] for managing DOTS telemetry
configuration freshness and notification.
Likewise, a DOTS client may control the selection of configuration
and non-configuration data nodes when sending a GET request by means
of the 'c' Uri-Query option and following the procedure specified in
Section of 4.4.2 of [RFC9132]. These considerations are not
reiterated in the following sections.
5.5. Message Validation
The authoritative reference for validating telemetry messages The authoritative reference for validating telemetry messages
exchanged over the DOTS signal channel are Sections 6, 7, and 8 exchanged over the DOTS signal channel are Sections 7, 8, and 9
together with the mapping table established in Section 11. 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 10.1). structure (Section 11.1).
5.6. A Note About Examples
Examples are provided for illustration purposes. The document does
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. telemetry operations.
The examples use the Enterprise Number 32473 defined for The examples use the Enterprise Number 32473 defined for
documentation use [RFC5612]. documentation use [RFC5612].
5. 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 1): following telemetry path suffixes are defined (Table 2):
+-----------------+----------------+-----------+ +-----------------+----------------+-----------+
| Operation | Operation Path | Details | | Operation | Operation Path | Details |
+=================+================+===========+ +=================+================+===========+
| Telemetry Setup | /tm-setup | Section 6 | | Telemetry Setup | /tm-setup | Section 6 |
| Telemetry | /tm | Section 7 | | Telemetry | /tm | Section 7 |
+-----------------+----------------+-----------+ +-----------------+----------------+-----------+
Table 1: 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 10.1 defines 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 6 and 7 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* []
| ... | ...
| +-- (setup-type)? | +-- (setup-type)?
skipping to change at page 15, line 48 skipping to change at page 16, line 24
| +--:(pipe) | +--:(pipe)
| | ... | | ...
| +--:(baseline) | +--:(baseline)
| ... | ...
+--:(telemetry) +--:(telemetry)
... ...
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 7). 'tm' (Section 8).
6. 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 6.1) or only telemetry-related configuration parameters (Section 7.1) or
information about DOTS client domain pipe capacity (Section 6.2) or information about DOTS client domain pipe capacity (Section 7.2) or
telemetry traffic baseline (Section 6.3). As such, requests that telemetry traffic baseline (Section 7.3). As such, requests that
include a mix of telemetry configuration, pipe capacity, and traffic include a mix of telemetry configuration, pipe capacity, and traffic
baseline MUST be rejected by DOTS servers with a 4.00 (Bad Request). baseline MUST be rejected by DOTS servers with a 4.00 (Bad Request).
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 6.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
with requests from other DOTS clients of the same DOTS client domain. with requests from other DOTS clients of the same DOTS client domain.
More details are included in Section 6.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 till the DOTS server ceases to service a setup configuration is valid till the DOTS server ceases to service 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]).
6.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 percentile). More details about percentile values and 50th, and 75th percentile). More details about percentile values 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", "medium", and "high" percentile thresholds are used for these "low", "medium", and "high" percentile
values is configurable (with suitable defaults). values is configurable. Default values are defined 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 on which percentiles are 'measurement-interval' defines the period on which percentiles are
computed, while 'measurement-sample' defines the time distribution computed, while 'measurement-sample' defines the time distribution
for measuring values that are used to compute percentiles. for measuring values that are used to compute 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
6.1.1. Retrieve 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 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 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 no error is encountered Upon receipt of such a request, and assuming no error is encountered
when processing the request, the DOTS server replies with a 2.05 when processing the request, the DOTS server replies with a 2.05
(Content) response that conveys the telemetry parameters that are (Content) response that conveys the telemetry parameters that are
acceptable by the DOTS server, any pipe information (Section 6.2), acceptable by the DOTS server, any pipe information (Section 7.2),
and the current baseline information (Section 6.3) maintained by the and the current baseline information (Section 7.3) maintained by the
DOTS server for this DOTS client. The tree structure of the response DOTS server for this DOTS client. The tree 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 8.2) sets '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 page 19, line 20 skipping to change at page 20, line 5
+--:(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 or equal to their counterpart in 'min-config-values' greater or equal to their counterpart in 'min-config-values'
attributes. attributes.
6.1.2. Conveying 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 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.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
skipping to change at page 21, line 6 skipping to change at page 21, line 38
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, 2.04 (Changed) has accepted the updated configuration parameters, 2.04 (Changed)
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 6.1.1), 4.22 (Unprocessable acceptable to the DOTS server (Section 7.1.1), 4.22 (Unprocessable
Entity) MUST be returned in the response. Entity) MUST be returned in the 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'
skipping to change at page 22, line 15 skipping to change at page 22, line 44
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 telemetry data. However, receipt of conflicting allowed for a given telemetry data. However, receipt of conflicting
values is treated as invalid parameters and rejected with 4.00 (Bad values is treated as invalid parameters and rejected with 4.00 (Bad
Request). Request).
DOTS clients that are interested to receive pre or ongoing mitigation DOTS clients that are interested to receive pre or ongoing mitigation
telemetry (pre-or-ongoing-mitigation) information from a DOTS server telemetry (pre-or-ongoing-mitigation) information from a DOTS server
(Section 8.2) MUST set 'server-originated-telemetry' to 'true'. If (Section 9.2) MUST set 'server-originated-telemetry' to 'true'. If
'server-originated-telemetry' is not present in a PUT request, this 'server-originated-telemetry' is not present in a PUT request, this
is equivalent to receiving a request with 'server-originated- is equivalent to receiving a request with 'server-originated-
telemetry' set to 'false'. An example of a request to enable pre-or- telemetry' set to 'false'. An example of a request to enable pre-or-
ongoing-mitigation telemetry from DOTS servers is shown in Figure 6. ongoing-mitigation telemetry from DOTS servers is shown 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"
skipping to change at page 22, line 44 skipping to change at page 23, line 28
"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 the DOTS server
6.1.3. Retrieve Installed DOTS Telemetry Configuration 7.1.3. Retrieve Installed DOTS Telemetry Configuration
A DOTS client may issue a GET message with 'tsid' Uri-Path parameter A DOTS client may issue a GET message with 'tsid' Uri-Path parameter
to retrieve the current DOTS telemetry configuration. An example of to retrieve the current DOTS telemetry configuration. An 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 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.
6.1.4. Delete 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"
skipping to change at page 23, line 40 skipping to change at page 24, line 27
Figure 8: Delete 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 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 6.4 discusses the procedure to reset all DOTS telemetry setup Section 7.4 discusses the procedure to reset all DOTS telemetry setup
configuration. configuration.
6.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)
| ... | ...
| +-- telemetry* [] | +-- telemetry* []
skipping to change at page 24, line 39 skipping to change at page 25, line 39
(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.
6.2.1. Conveying DOTS Client Domain Pipe Capacity 7.2.1. Conveying DOTS Client Domain Pipe Capacity
Similar considerations to those specified in Section 6.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 such two requests have their respective 'tsid' values. If such two requests have
overlapping 'link-id' and 'unit', the PUT request with higher overlapping 'link-id' and 'unit', the PUT request with 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.
skipping to change at page 26, line 51 skipping to change at page 27, line 51
} }
] ]
} }
} }
Figure 13: Example of a PUT Request to Convey Pipe Information Figure 13: Example of a PUT Request to Convey Pipe Information
(Aggregated Link) (Aggregated Link)
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 of Figure 14); the DOTS client can an additional ISP (e.g., ISP#B of Figure 14); the DOTS client can
inform a third-party DOTS server (that is, not hosted with ISP#A and inform a DOTS server that is not hosted with ISP#A and ISP#B domains
ISP#B domains) about this update by sending the PUT request depicted about this update by sending the PUT request depicted in Figure 15.
in Figure 15. This request also includes information related to This request also includes information related to "link1" even if
"link1" even if that link is not upgraded. Upon receipt of this that link is not upgraded. Upon receipt of this request, the DOTS
request, the DOTS server removes the request with 'tsid=126' and server removes the request with 'tsid=126' and updates its
updates its configuration base to maintain two links (link#1 and configuration base to maintain two links (link#1 and link#2).
link#2).
,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
( ISP#B ) ( ISP#B )
`-. ,-' `-. ,-'
`--'--'--' `--'--'--'
|| ||
|| link2 || link2
,--,--,--. ,--,--,--. ,--,--,--. ,--,--,--.
,-' `-. ,-' `-. ,-' `-. ,-' `-.
skipping to change at page 28, line 39 skipping to change at page 29, line 39
} }
] ]
} }
} }
Figure 15: Example of a PUT Request to Convey Pipe Information Figure 15: Example of a PUT Request to Convey Pipe Information
(Multi-Homed) (Multi-Homed)
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 (see Section 6.2.3 for other delete the same DOTS client domain (see Section 7.2.3 for other delete
cases). For example, if a DOTS client domain re-homes (that is, it cases). For example, if a DOTS client domain re-homes (that is, it
changes its ISP), the DOTS client can inform its DOTS server about changes its ISP), the DOTS client can inform its DOTS server about
this update (e.g., from the network configuration in Figure 10 to the this update (e.g., from the network configuration in Figure 10 to the
one shown in Figure 16) by sending the PUT request depicted in one shown in Figure 16) by sending the PUT request depicted in
Figure 17. Upon receipt of this request, and assuming no error is Figure 17. Upon receipt of this request, and assuming no error is
encountered when processing the request, the DOTS server removes encountered when processing the request, the DOTS server removes
"link1" from its configuration bases for this DOTS client domain. "link1" from its configuration bases for this DOTS client domain.
Note that if the DOTS server receives a PUT request with a 'capacity' Note that if the DOTS server receives a PUT request with a 'capacity'
attribute set to "0" for all included links, it MUST reject the attribute set to "0" for all included links, it MUST reject the
request with a 4.00 (Bad Request). request with a 4.00 (Bad Request). Instead, the DOTS client can use
a DELETE request to delete all links (Section 7.2.3).
,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
( ISP#B ) ( ISP#B )
`-. ,-' `-. ,-'
`--'--'--' `--'--'--'
|| ||
|| link2 || link2
,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
skipping to change at page 30, line 5 skipping to change at page 31, line 5
} }
] ]
} }
] ]
} }
} }
Figure 17: Example of a PUT Request to Convey Pipe Information Figure 17: Example of a PUT Request to Convey Pipe Information
(Multi-Homed) (Multi-Homed)
6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity 7.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity
A GET request with '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 pipe related information. The specific installed DOTS client domain pipe related information. The
same procedure as defined in Section 6.1.3 is followed. same procedure as defined in Section 7.1.3 is 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 6.1.1. client proceeds as specified in Section 7.1.1.
6.2.3. Delete Installed DOTS Client Domain Pipe Capacity 7.2.3. Delete Installed DOTS Client Domain Pipe Capacity
A DELETE request is used to delete the installed DOTS client domain A DELETE request is used to delete the installed DOTS client domain
pipe related information. The same procedure as defined in pipe related information. The same procedure as defined in
Section 6.1.4 is followed. Section 7.1.4 is followed.
6.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 connections capacity: traffic baseline and connections capacity:
Total traffic normal baseline: The percentile values representing Total traffic normal baseline: The percentile values representing
the total traffic normal baseline. It can be represented for a the total traffic normal baseline. It can be represented for a
target using 'total-traffic-normal'. target using 'total-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 6.1), these negotiated parameters will be used instead of (Section 7.1), these negotiated parameters will be used instead of
the default ones. For each used unit class, the DOTS client MUST the default ones. For each used unit class, the DOTS client MUST
auto-scale so that the appropriate unit is used. auto-scale so that the appropriate unit is used.
Total connections capacity: If the target is susceptible to Total connections capacity: If the target is susceptible to
resource-consuming DDoS attacks, the following optional attributes resource-consuming DDoS attacks, the following optional attributes
for the target per transport protocol are useful to detect for the target per transport protocol are useful to detect
resource-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.
skipping to change at page 33, line 38 skipping to change at page 34, line 38
... ...
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 are 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.
6.3.1. Conveying DOTS Client Domain Baseline Information 7.3.1. Conveying DOTS Client Domain Baseline Information
Similar considerations to those specified in Section 6.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 such two requests have their respective 'tsid' values. If such two requests have
overlapping targets, the PUT request with 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.
skipping to change at page 35, line 40 skipping to change at page 36, line 40
} }
] ]
} }
] ]
} }
} }
Figure 19: PUT to Conveying the DOTS Traffic Baseline Figure 19: PUT to Conveying the DOTS Traffic Baseline
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 19. (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 page 37, line 5 skipping to change at page 38, line 5
] ]
} }
} }
Figure 20: PUT to Convey the DOTS Traffic Baseline (2) Figure 20: PUT to Convey the DOTS Traffic Baseline (2)
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.
6.3.2. Retrieve Installed Normal Traffic Baseline 7.3.2. Retrieve Installed Normal Traffic Baseline
A GET request with '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 baseline traffic information. specific installed DOTS client domain baseline traffic information.
The same procedure as defined in Section 6.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 6.1.1. client proceeds as specified in Section 7.1.1.
6.3.3. Delete Installed Normal Traffic Baseline 7.3.3. Delete Installed Normal Traffic Baseline
A DELETE request is used to delete the installed DOTS client domain A DELETE request is used to delete the installed DOTS client domain
normal traffic baseline. The same procedure as defined in normal traffic baseline. The same procedure as defined in
Section 6.1.4 is followed. Section 7.1.4 is followed.
6.4. Reset 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'. An example of such a request is depicted in include any 'tsid'. An example of such a request is 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: Delete Telemetry Configuration Figure 21: Delete Telemetry Configuration
6.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 similar conflict handling discussed in to the DOTS client following similar conflict handling discussed in
Section 4.4.1 of [RFC9132]. The conflict cause can be set to one of Section 4.4.1 of [RFC9132]. The 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]).
TBA: Overlapping pipe scope (see Section 12). TBA: Overlapping pipe scope (see Section 13).
7. DOTS Pre-or-Ongoing Mitigation Telemetry 8. DOTS Pre-or-Ongoing Mitigation Telemetry
There are two broad types of DDoS attacks: one is a bandwidth There are two broad types of DDoS attacks: one is a bandwidth
consuming attack, the other is a target-resource-consuming attack. consuming attack, the other is a target-resource-consuming attack.
This section outlines the set of DOTS telemetry attributes This section outlines the set of DOTS telemetry attributes
(Section 7.1) that covers both types of attack. The objective of (Section 8.1) that covers both types of attack. The objective of
these attributes is to allow for the complete knowledge of attacks these attributes is to allow for the complete knowledge of attacks
and the various particulars that can best characterize attacks. and the various particulars that can best characterize attacks.
The "ietf-dots-telemetry" YANG module (Section 10.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 24. structure of the 'telemetry' message type is shown in Figure 24.
The pre-or-ongoing-mitigation telemetry attributes are indicated by The pre-or-ongoing-mitigation telemetry attributes are indicated by
the path suffix '/tm'. The '/tm' is appended to the path prefix to 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. form the URI used with a CoAP request to signal the DOTS telemetry.
Pre-or-ongoing-mitigation telemetry attributes specified in Pre-or-ongoing-mitigation telemetry attributes specified in
Section 7.1 can be signaled between DOTS agents. Section 8.1 can be signaled between DOTS agents.
Pre-or-ongoing-mitigation telemetry attributes may be sent by a DOTS Pre-or-ongoing-mitigation telemetry attributes may be sent by a DOTS
client or a DOTS server. client or a DOTS server.
DOTS agents SHOULD bind pre-or-ongoing-mitigation telemetry data to DOTS agents SHOULD bind pre-or-ongoing-mitigation telemetry data to
mitigation requests associated with the resources under attack. In mitigation requests associated with the resources under attack. In
particular, a telemetry PUT request sent after a mitigation request particular, a telemetry PUT request sent after a mitigation request
may include a reference to that mitigation request ('mid-list') as may include a reference to that mitigation request ('mid-list') as
shown in Figure 22. An example illustrating request correlation by shown in Figure 22. An example illustrating request correlation by
means of 'target-prefix' is shown in Figure 23. means of 'target-prefix' is shown in Figure 23.
Many of the pre-or-ongoing-mitigation telemetry data use a unit that Many of the pre-or-ongoing-mitigation telemetry data use a unit that
falls under the unit class that is configured following the procedure falls under the unit class that is configured following the procedure
described in Section 6.1.2. When generating telemetry data to send 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) to a peer, the DOTS agent MUST auto-scale so that appropriate unit(s)
are used. are used.
+-----------+ +-----------+ +-----------+ +-----------+
|DOTS client| |DOTS server| |DOTS client| |DOTS server|
+-----------+ +-----------+ +-----------+ +-----------+
| | | |
|===============Mitigation Request (mid)===============>| |===============Mitigation Request (mid)===============>|
| | | |
|===============Telemetry (mid-list{mid})==============>| |===============Telemetry (mid-list{mid})==============>|
skipping to change at page 39, line 18 skipping to change at page 40, line 18
| | | |
|<================Telemetry (target-prefix)=============| |<================Telemetry (target-prefix)=============|
| | | |
|=========Mitigation Request (target-prefix)===========>| |=========Mitigation Request (target-prefix)===========>|
| | | |
Figure 23: Example of Request Correlation using Target Prefix Figure 23: Example of Request Correlation using Target Prefix
DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry
notifications to the same peer more frequently than once every notifications to the same peer more frequently than once every
'telemetry-notify-interval' (Section 6.1). If a telemetry 'telemetry-notify-interval' (Section 7.1). If a telemetry
notification is sent using a block-like transfer mechanism (e.g., notification is sent using a block-like transfer mechanism (e.g.,
[I-D.ietf-core-new-block]), this rate limit policy MUST NOT consider [I-D.ietf-core-new-block]), this rate limit policy MUST NOT consider
these individual blocks as separate notifications, but as a single these individual blocks as separate notifications, but as a single
notification. notification.
DOTS pre-or-ongoing-mitigation telemetry request and response DOTS pre-or-ongoing-mitigation telemetry request and response
messages MUST be marked as Non-Confirmable messages (Section 2.1 of messages MUST be marked as Non-Confirmable messages (Section 2.1 of
[RFC7252]). [RFC7252]).
structure dots-telemetry: structure dots-telemetry:
skipping to change at page 41, line 5 skipping to change at page 41, line 48
| ... | ...
+-- 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 24: Telemetry Message Type Tree Structure Figure 24: Telemetry Message Type Tree Structure
7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes 8.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes
The description and motivation behind each attribute are presented in The description and motivation behind each attribute are presented in
Section 3. DOTS telemetry attributes are optionally signaled and Section 3.
therefore MUST NOT be treated as mandatory fields in the DOTS signal
channel protocol.
7.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* []
+-- (direction)? +-- (direction)?
| +--:(server-to-client-only) | +--:(server-to-client-only)
skipping to change at page 42, line 16 skipping to change at page 43, line 10
At least one of the attributes 'target-prefix', 'target-fqdn', At least one of the attributes 'target-prefix', 'target-fqdn',
'target-uri', 'alias-name', or 'mid-list' MUST be present in the 'target-uri', 'alias-name', or 'mid-list' MUST be present in the
target definition. target definition.
If the target is susceptible to bandwidth-consuming attacks, the If the target is susceptible to bandwidth-consuming attacks, the
attributes representing the percentile values of the 'attack-id' attributes representing the percentile values of the 'attack-id'
attack traffic are included. attack traffic are included.
If the target is susceptible to resource-consuming DDoS attacks, the If the target is susceptible to resource-consuming DDoS attacks, the
same attributes defined in Section 7.1.4 are applicable for attributes defined in Section 8.1.4 are applicable for representing
representing the attack. the attack.
At least the 'target' attribute and one other pre-or-ongoing- At least the 'target' attribute and one other pre-or-ongoing-
mitigation attribute MUST be present in the DOTS telemetry message. mitigation attribute MUST be present in the DOTS telemetry message.
7.1.2. Total Traffic 8.1.2. Total Traffic
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.
skipping to change at page 44, line 5 skipping to change at page 45, line 5
| ... | ...
+-- 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 26: Total Traffic Tree Structure Figure 26: Total Traffic Tree Structure
7.1.3. Total Attack Traffic 8.1.3. Total Attack Traffic
The 'total-attack-traffic' attribute (Figure 27) conveys the total The 'total-attack-traffic' attribute (Figure 27) conveys the total
observed attack traffic. More fine-grained information about the observed attack traffic. More fine-grained information about the
total attack traffic can be conveyed in the 'total-attack-traffic- total attack traffic can be conveyed in the 'total-attack-traffic-
protocol' and 'total-attack-traffic-port' attributes. protocol' and 'total-attack-traffic-port' attributes.
The 'total-attack-traffic-protocol' attribute represents the total The 'total-attack-traffic-protocol' attribute represents the total
attack traffic for a target and is transport-protocol specific. attack traffic for a target and is transport-protocol specific.
The 'total-attack-traffic-port' attribute represents the total attack The 'total-attack-traffic-port' attribute represents the total attack
skipping to change at page 46, line 5 skipping to change at page 47, line 5
| +-- current-g? yang:gauge64 | +-- current-g? yang:gauge64
+-- total-attack-connection-protocol* [protocol] +-- total-attack-connection-protocol* [protocol]
| ... | ...
+-- total-attack-connection-port* [protocol port] +-- total-attack-connection-port* [protocol port]
| ... | ...
+-- attack-detail* [vendor-id attack-id] +-- attack-detail* [vendor-id attack-id]
... ...
Figure 27: Total Attack Traffic Tree Structure Figure 27: Total Attack Traffic Tree Structure
7.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 subattributes for the target per transport following optional subattributes 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.
skipping to change at page 48, line 15 skipping to change at page 49, line 15
| +-- low-percentile-g? yang:gauge64 | +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64 | +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64 | +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64 | +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64 | +-- current-g? yang:gauge64
+-- attack-detail* [vendor-id attack-id] +-- attack-detail* [vendor-id attack-id]
... ...
Figure 28: Total Attack Connections Tree Structure Figure 28: Total Attack Connections Tree Structure
7.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 subattributes details characterizing an attack. The following subattributes
describing the ongoing attack can be signalled as attack details: describing the ongoing attack can be signalled as attack details:
vendor-id: Vendor ID is a security vendor's Enterprise Number as vendor-id: Vendor ID is a security vendor's enterprise number as
registered with IANA [Enterprise-Numbers]. It is a four-byte registered in the IANA's "Private Enterprise Numbers" registry
integer value. [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 whether 'attack- This parameter MUST be present independent of whether 'attack-
description' is included or not. description' is included or not.
attack-description: Textual representation of the attack attack-description: Textual representation of the attack
description. Natural Language Processing techniques (e.g., word description. Natural Language Processing techniques (e.g., word
embedding) might provide some utility in mapping the attack embedding) might provide some utility in mapping the attack
description to an attack type. Textual representation of attack description to an attack type. Textual representation of attack
solves two problems: (a) avoids the need to create mapping tables solves two problems: (a) avoids the need to create mapping tables
manually between vendors and (b) avoids the need to standardize manually between vendors and (b) avoids the need to standardize
attack types which keep evolving. attack types which keep evolving.
skipping to change at page 49, line 16 skipping to change at page 50, line 16
and which 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 the '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', Section 7.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 defined in Section 7.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 page 51, line 20 skipping to change at page 52, line 20
+-- current-g? yang:gauge64 +-- current-g? yang:gauge64
Figure 29: Attack Detail 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 systematically an attack description in their telemetry convey systematically an attack description in their telemetry
messages over the DOTS signal channel. Refer to Section 7.1.6. messages over the DOTS signal channel. Refer to Section 8.1.6.
7.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 multiple Note: It is possible that a DOTS server is making use of multiple
DOTS mitigators; each from a different vendor. How telemetry DOTS mitigators; each from a different vendor. How telemetry
information and vendor mappings are exchanged between DOTS servers information and vendor mappings are exchanged between DOTS servers
and DOTS mitigators is outside the scope of this document. and DOTS mitigators is outside the scope of this document.
skipping to change at page 51, line 45 skipping to change at page 52, line 45
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 to the one it uses to transmit vendor identifier that is different to the one it uses to transmit
telemetry data. Furthermore, it is possible that the DOTS client and telemetry data. Furthermore, it is possible that the DOTS client and
DOTS server are provided by the same vendor, but the vendor mapping DOTS server are provided by the same vendor, but the vendor mapping
tables are at different revisions. The DOTS client SHOULD transmit tables are at different revisions. The DOTS client SHOULD transmit
telemetry information using any vendor mapping(s) that it provided to telemetry information using any vendor mapping(s) that it provided to
the DOTS server (e.g., using a POST as depicted in Figure 34) and the the DOTS server (e.g., using a POST as depicted in Figure 34) and the
DOTS server SHOULD use any vendor mappings(s) provided to the DOTS DOTS server SHOULD use any vendor mappings(s) provided to the DOTS
client when transmitting telemetry data to the peer DOTS agent. client when transmitting telemetry data to the peer DOTS agent.
The "ietf-dots-mapping" YANG module defined in Section 10.2 augments The "ietf-dots-mapping" YANG module defined in Section 11.2 augments
the "ietf-dots-data-channel" [RFC8783] module. The tree structure of the "ietf-dots-data-channel" [RFC8783] module. The tree structure of
the "ietf-dots-mapping" module is shown in Figure 30. 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 last-updated uint64 +--rw last-updated uint64
skipping to change at page 53, line 28 skipping to change at page 54, line 28
"last-updated": "1629898758", "last-updated": "1629898758",
"attack-mapping": [] "attack-mapping": []
} }
] ]
} }
} }
Figure 33: Response to a GET to Retrieve the Vendors List used by Figure 33: Response to a GET to Retrieve the Vendors List used by
a DOTS Server a DOTS Server
The DOTS client reiterates the above procedure regularly (e.g., once The DOTS client repeats the above procedure regularly (e.g., once a
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 34. details. An example of such a POST request is depicted in Figure 34.
POST /restconf/data/ietf-dots-data-channel:dots-data\ POST /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1 /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
skipping to change at page 54, line 37 skipping to change at page 55, line 37
} }
] ]
} }
] ]
} }
} }
Figure 34: POST to Install Vendor Attack Mapping Details 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. Concretely, "201 Created" status-line MUST be using the status-line. A "201 Created" status-line MUST be returned
returned in the response if the DOTS server has accepted the vendor in the response if the DOTS server has accepted the vendor attack
attack mapping details. If the request is missing a mandatory mapping details. If the request is missing a mandatory attribute or
attribute or contains an invalid or unknown parameter, "400 Bad contains an invalid or unknown parameter, "400 Bad Request" status-
Request" status-line MUST be returned by the DOTS server in the line MUST be returned by the DOTS server in the response. The error-
response. The error-tag is set to "missing-attribute", "invalid- tag is set to "missing-attribute", "invalid-value", or "unknown-
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 "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
skipping to change at page 55, line 22 skipping to change at page 56, line 22
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 (Sections When conveying attack details in DOTS telemetry messages (Sections
7.2, 7.3, and 8), 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.
7.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)
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"
skipping to change at page 57, line 13 skipping to change at page 58, line 13
DOTS client to convey pre-or-ongoing-mitigation telemetry). DOTS client to convey 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 follow 'cuid'. This is a mandatory attribute. 'tmid' MUST follow 'cuid'.
'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 7.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 7.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 two such requests have an their respective 'tmid' values. If two such requests have an
overlapping 'target', the PUT request with 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
skipping to change at page 58, line 14 skipping to change at page 59, line 14
Figure 37: Delete a Pre-or-Ongoing-Mitigation Telemetry Figure 37: Delete a Pre-or-Ongoing-Mitigation Telemetry
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: Delete All Pre-or-Ongoing-Mitigation Telemetry Figure 38: Delete All Pre-or-Ongoing-Mitigation Telemetry
7.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) The pre-or-ongoing-mitigation data (attack details, in particular)
can also be signaled from DOTS servers to DOTS clients. For example, can also be signaled from DOTS servers to DOTS clients. For example,
a 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
skipping to change at page 58, line 36 skipping to change at page 59, line 36
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 this fits within one single datagram). the same request (assuming this fits within one single datagram).
DOTS servers may be instructed to restrict the number of pre-or- DOTS servers may be instructed to restrict the number of pre-or-
ongoing-mitigation requests per DOTS client domain. The PUT request ongoing-mitigation requests per DOTS client domain. The pre-or-
MUST be maintained in an active state by the DOTS server until a ongoing mitigation requests MUST be maintained in an active state by
delete request is received from the same DOTS client to clear this the DOTS server until a delete request is received from the same DOTS
pre-or-ongoing-mitigation telemetry or when the DOTS client is client to clear this pre-or-ongoing-mitigation telemetry or when the
considered inactive (e.g., Section 3.5 of [RFC8783]). DOTS client is considered inactive (e.g., 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 such two requests have their respective 'tmid' values. If such two requests have
overlapping 'target', the PUT request with 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)
skipping to change at page 60, line 21 skipping to change at page 61, line 21
Figure 41: GET to Subscribe to Telemetry Asynchronous Figure 41: GET to Subscribe to Telemetry Asynchronous
Notifications for All 'tmids' 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 4.2.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.
skipping to change at page 63, line 14 skipping to change at page 64, line 14
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 to receive 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 one depicted in Figure 37. to the one depicted in Figure 37.
8. DOTS Telemetry Mitigation Status Update 9. DOTS Telemetry Mitigation Status Update
8.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry 9.1. DOTS Clients to Servers Mitigation Efficacy DOTS 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 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 perspective during an active mitigation. See client perspective during an active mitigation. See
Section 7.1.5. Section 8.1.5.
The "ietf-dots-telemetry" YANG module (Section 10.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"
module [RFC9132] so that these attributes can be signalled by a DOTS module [RFC9132] so that these attributes can be signalled by 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
skipping to change at page 64, line 48 skipping to change at page 65, line 48
+-- 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 has 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 primary meant to assess whether the peer DOTS server session is primarily meant to assess whether the peer DOTS server
supports telemetry extensions and, 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"
skipping to change at page 65, line 40 skipping to change at page 66, line 40
} }
] ]
} }
] ]
} }
} }
Figure 45: An Example of Mitigation Efficacy Update with Figure 45: An Example of Mitigation Efficacy Update with
Telemetry Attributes Telemetry Attributes
8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry 9.2. DOTS Servers to Clients Mitigation Status DOTS 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 defined in Section 7.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 10.1) augments the The "ietf-dots-telemetry" YANG module (Section 11.1) augments the
'mitigation-scope' message type defined in "ietf-dots-signal" 'mitigation-scope' message type defined in "ietf-dots-signal"
[RFC9132] with telemetry data as depicted in Figure 46. [RFC9132] with telemetry data as depicted in 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
skipping to change at page 69, line 9 skipping to change at page 70, line 9
} }
} }
Figure 47: Response Body of a Mitigation Status With Telemetry Figure 47: Response Body of a Mitigation Status With Telemetry
Attributes Attributes
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 4.2.4). The 'target-uri', 'alias-name', and 'c' (content) (Section 5.4). The
considerations discussed in Section 7.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 request to subscribe to asynchronous notifications An example of request to subscribe to asynchronous notifications
bound to the "http1" 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 one. In such a observe entry if this query overlaps with an existing one. In such a
case, the DOTS server replies with 4.09 (Conflict). case, the DOTS server replies with 4.09 (Conflict).
9. Error Handling 10. Error Handling
A list of common CoAP errors that are implemented by DOTS servers are 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.
10. YANG Modules As indicated in Section 9 of [RFC9132], an additional plain text
diagnostic payload (Section 5.5.2 of [RFC7252]) to help
troubleshooting is returned in the body of the response.
10.1. DOTS Signal Channel Telemetry YANG Module 11. YANG Modules
11.1. DOTS Signal Channel Telemetry YANG Module
This module uses types defined in [RFC6991] and [RFC8345]. This module uses types defined in [RFC6991] and [RFC8345].
<CODE BEGINS> file "ietf-dots-telemetry@2021-11-29.yang" <CODE BEGINS> file "ietf-dots-telemetry@2021-11-29.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 {
skipping to change at page 70, line 48 skipping to change at page 72, line 4
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"Section 4 of RFC 6991"; "Section 4 of RFC 6991";
} }
import ietf-network-topology { import ietf-network-topology {
prefix nt; prefix nt;
reference reference
"Section 6.2 of RFC 8345: A YANG Data Model for Network "Section 6.2 of RFC 8345: A YANG Data Model for Network
Topologies"; 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 Author: Konda, Tirumaleswar Reddy.K
<mailto:TirumaleswarReddy_Konda@McAfee.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) 2021 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 without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2021-11-29 { revision 2021-11-29 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Distributed Denial-of-Service Open Threat "RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry"; Signaling (DOTS) Telemetry";
skipping to change at page 79, line 6 skipping to change at page 80, line 10
description description
"Query based on ICMP type"; "Query based on ICMP type";
} }
enum content { enum content {
value 11; value 11;
description description
"Query based on 'c' Uri-Query option that is used "Query based on 'c' Uri-Query option that 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
"Section 4.4.2 of RFC UUUU."; "Section 4.4.2 of RFC 9132.";
} }
} }
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.";
} }
skipping to change at page 88, line 4 skipping to change at page 89, line 8
uses connection-all; uses connection-all;
} }
grouping attack-detail { grouping attack-detail {
description description
"Various details that describe the on-going "Various details that describe the on-going
attacks that need to be mitigated by the DOTS server. attacks that need to be mitigated by the DOTS server.
The attack details need to cover well-known and common attacks The attack details need to cover well-known and common 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
"Vendor ID is a security vendor's Enterprise Number as "Vendor ID is a security vendor's Private Enterprise Number
as registered with IANA."; as registered with IANA.";
reference reference
"IANA: Private Enterprise Numbers"; "IANA: Private 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 attack-description { leaf attack-description {
skipping to change at page 94, line 42 skipping to change at page 95, line 46
"Can be a telemetry-setup or telemetry data."; "Can be a telemetry-setup or telemetry data.";
case telemetry-setup { case telemetry-setup {
description description
"Indicates the message is about telemetry steup."; "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 mitigation 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
skipping to change at page 96, line 23 skipping to change at page 97, line 27
of the list are 'cuid' and 'tsid', but these keys are of the list are 'cuid' and 'tsid', but these keys are
not represented here because these keys are conveyed not represented here because these keys are conveyed
as mandatory Uri-Paths in requests. Omitting keys as mandatory Uri-Paths in requests. Omitting keys
is compliant with RFC8791."; is compliant with RFC8791.";
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 mitigation message "These data nodes appear only in a telemetry 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 {
skipping to change at page 98, line 39 skipping to change at page 99, line 44
The keys of the list are 'cuid' and 'tmid', but these The keys of the list are 'cuid' and 'tmid', but these
keys are not represented here because these keys are keys are not represented here because these keys are
conveyed as mandatory Uri-Paths in requests. conveyed as mandatory Uri-Paths in requests.
Omitting keys is compliant with RFC8791."; Omitting keys is compliant with RFC8791.";
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 mitigation message "These data nodes appear only in a telemetry 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 attributes "Indicates the target. At least one of the attributes
'target-prefix', 'target-fqdn', 'target-uri', 'target-prefix', 'target-fqdn', 'target-uri',
'alias-name', or 'mid-list' must be present in the 'alias-name', or 'mid-list' 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;
skipping to change at page 99, line 32 skipping to change at page 100, line 37
} }
} }
uses pre-or-ongoing-mitigation; uses pre-or-ongoing-mitigation;
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
10.2. Vendor Attack Mapping Details YANG Module 11.2. Vendor Attack Mapping Details YANG Module
<CODE BEGINS> file "ietf-dots-mapping@2020-06-26.yang" <CODE BEGINS> file "ietf-dots-mapping@2020-06-26.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
skipping to change at page 100, line 4 skipping to change at page 101, line 8
reference reference
"RFC 8783: Distributed Denial-of-Service Open Threat "RFC 8783: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Data Channel Specification"; Signaling (DOTS) Data Channel Specification";
} }
organization organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group"; "IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/dots/> "WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org> WG List: <mailto:dots@ietf.org>
Author: Mohamed Boucadair Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Author: Jon Shallow Author: Jon Shallow
<mailto:supjps-ietf@jpshallow.com>"; <mailto:supjps-ietf@jpshallow.com>";
description description
"This module contains YANG definitions for the sharing "This module contains YANG definitions for the sharing
DDoS attack mapping details between a DOTS client and 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) 2021 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 without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2020-06-26 { revision 2020-06-26 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Distributed Denial-of-Service Open Threat "RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry"; Signaling (DOTS) Telemetry";
skipping to change at page 101, line 4 skipping to change at page 102, line 9
description description
"A set of information used for sharing vendor attack mapping "A set of information used for sharing vendor attack mapping
information with a peer."; information with a peer.";
list vendor { list vendor {
key "vendor-id"; key "vendor-id";
description description
"Vendor attack mapping information of the client/server"; "Vendor attack mapping information of the client/server";
leaf vendor-id { leaf vendor-id {
type uint32; type uint32;
description description
"Vendor ID is a security vendor's Enterprise Number as "Vendor ID is a security vendor's Private Enterprise Number
registered with IANA."; as registered with IANA.";
reference reference
"IANA: Private Enterprise Numbers"; "IANA: Private 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 last-updated { leaf last-updated {
type uint64; type uint64;
skipping to change at page 102, line 40 skipping to change at page 103, line 45
config false; config false;
description description
"Includes the list of vendor attack mapping details "Includes the list of vendor attack mapping details
that will be shared upon request with DOTS clients."; that will be shared upon request with DOTS clients.";
uses attack-mapping; uses attack-mapping;
} }
} }
} }
<CODE ENDS> <CODE ENDS>
11. 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 2: channel MUST be mapped to CBOR types as shown in Table 3:
* Note: Implementers must check that the mapping output provided by * Note: Implementers must check that the mapping output provided by
their YANG-to-CBOR encoding schemes is aligned with the content of their YANG-to-CBOR encoding schemes is aligned with the content of
Table 2. Table 2.
+----------------------+-------------+------+---------------+--------+ +----------------------+-------------+------+---------------+--------+
| Parameter Name | YANG | CBOR | CBOR Major | JSON | | Parameter Name | YANG | CBOR | CBOR Major | JSON |
| | Type | Key | Type & | Type | | | Type | Key | Type & | Type |
| | | | Information | | | | | | Information | |
+======================+=============+======+===============+========+ +======================+=============+======+===============+========+
skipping to change at page 105, line 30 skipping to change at page 106, line 34
| connection | container |TBA81 | 5 map | Object | | connection | container |TBA81 | 5 map | Object |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| attack-detail | list |TBA82 | 4 array | Array | | attack-detail | list |TBA82 | 4 array | Array |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| telemetry | container |TBA83 | 5 map | Object | | telemetry | container |TBA83 | 5 map | Object |
| current-g | yang:gauge64|TBA84 | 0 unsigned | String | | current-g | yang:gauge64|TBA84 | 0 unsigned | String |
| lower-type | uint8 |32771 | 0 unsigned | Number | | lower-type | uint8 |32771 | 0 unsigned | Number |
| upper-type | uint8 |32772 | 0 unsigned | Number | | upper-type | uint8 |32772 | 0 unsigned | Number |
+----------------------+-------------+------+---------------+--------+ +----------------------+-------------+------+---------------+--------+
Table 2: YANG/JSON Mapping Parameters to CBOR Table 3: YANG/JSON Mapping Parameters to CBOR
12. IANA Considerations 13. IANA Considerations
12.1. DOTS Signal Channel CBOR Key Values 13.1. DOTS Signal Channel CBOR Key Values
This specification registers the DOTS telemetry attributes in the This specification registers the DOTS telemetry attributes in the
IANA "DOTS Signal Channel CBOR Key Values" registry [Key-Map]. IANA "DOTS Signal Channel CBOR Key Values" registry [Key-Map].
The DOTS telemetry attributes defined in this specification are The DOTS telemetry attributes defined in this specification are
comprehension-optional parameters. comprehension-optional parameters.
* Note to the RFC Editor: CBOR keys are assigned from the "128-255" * Note to the IANA: CBOR keys are assigned from the "128-255" range.
range. This specification meets the requirements listed in This specification meets the requirements listed in Section 3.1
Section 3.1 [RFC9132] for assignments in the "128-255" range. [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 | | Parameter Name | CBOR | CBOR | Change | Specification |
| | Key | Major | Controller | Document(s) | | | Key | Major | Controller | Document(s) |
| | Value | Type | | | | | Value | Type | | |
+======================+=======+=======+============+===============+ +======================+=======+=======+============+===============+
| tsid | TBA1 | 0 | IESG | [RFCXXXX] | | tsid | TBA1 | 0 | IESG | [RFCXXXX] |
| telemetry | TBA2 | 4 | IESG | [RFCXXXX] | | telemetry | TBA2 | 4 | IESG | [RFCXXXX] |
| low-percentile | TBA3 | 6tag4 | IESG | [RFCXXXX] | | low-percentile | TBA3 | 6tag4 | IESG | [RFCXXXX] |
| mid-percentile | TBA4 | 6tag4 | IESG | [RFCXXXX] | | mid-percentile | TBA4 | 6tag4 | IESG | [RFCXXXX] |
skipping to change at page 108, line 13 skipping to change at page 109, line 19
| ietf-dots-telemetry: | TBA81 | 5 | IESG | [RFCXXXX] | | ietf-dots-telemetry: | TBA81 | 5 | IESG | [RFCXXXX] |
| total-attack- | | | | | | total-attack- | | | | |
| connection | | | | | | connection | | | | |
| ietf-dots-telemetry: | TBA82 | 4 | IESG | [RFCXXXX] | | ietf-dots-telemetry: | TBA82 | 4 | IESG | [RFCXXXX] |
| attack-detail | | | | | | attack-detail | | | | |
| ietf-dots-telemetry: | TBA83 | 5 | IESG | [RFCXXXX] | | ietf-dots-telemetry: | TBA83 | 5 | IESG | [RFCXXXX] |
| telemetry | | | | | | telemetry | | | | |
| current-g | TBA84 | 0 | IESG | [RFCXXXX] | | current-g | TBA84 | 0 | IESG | [RFCXXXX] |
+----------------------+-------+-------+------------+---------------+ +----------------------+-------+-------+------------+---------------+
Table 3: Registered DOTS Signal Channel CBOR Key Values Table 4: Registered DOTS Signal Channel CBOR Key Values
12.2. DOTS Signal Channel Conflict Cause Codes 13.2. DOTS Signal Channel Conflict Cause Codes
This specification requests IANA to assign a new code from the "DOTS This specification requests IANA to assign a new code from the "DOTS
Signal Channel Conflict Cause Codes" registry [Cause]. Signal Channel Conflict Cause Codes" registry [Cause].
+------+-------------------+------------------------+-------------+ +------+-------------------+------------------------+-------------+
| Code | Label | Description | Reference | | Code | Label | Description | Reference |
+======+===================+========================+=============+ +======+===================+========================+=============+
| TBA | overlapping-pipes | Overlapping pipe scope | [RFCXXXX] | | TBA | overlapping-pipes | Overlapping pipe scope | [RFCXXXX] |
+------+-------------------+------------------------+-------------+ +------+-------------------+------------------------+-------------+
Table 4: Registered DOTS Signal Channel Conflict Cause Code Table 5: Registered DOTS Signal Channel Conflict Cause Code
12.3. DOTS Signal Telemetry YANG Module * Note to the RFC Editor: Please replace all occurrences of "TBA"
with the assigned value.
13.3. DOTS Signal Telemetry YANG Module
This document requests IANA to register the following URIs in the This document requests IANA to register the following URIs in the
"ns" subregistry within the "IETF XML Registry" [RFC3688]: "ns" subregistry within the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry 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.
URI: urn:ietf:params:xml:ns:yang:ietf-dots-mapping URI: urn:ietf:params:xml:ns:yang:ietf-dots-mapping
Registrant Contact: The IESG. Registrant Contact: The IESG.
skipping to change at page 109, line 17 skipping to change at page 110, line 21
maintained by IANA: N maintained by IANA: N
prefix: dots-telemetry prefix: dots-telemetry
reference: RFC XXXX 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 XXXX reference: RFC XXXX
13. Security Considerations 14. Security Considerations
13.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
connections 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
skipping to change at page 110, line 41 skipping to change at page 111, line 29
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 resources. Likewise, the DOTS server can enforce a quota and
time-limit on the number of active pre-or-ongoing-mitigation time-limit on the number of active pre-or-ongoing-mitigation
telemetry data items (identified by 'tmid') from the DOTS client. telemetry data items (identified by 'tmid') from the DOTS client.
Note also that telemetry notification interval may be used to rate- Note also that telemetry notification interval may be used to rate-
limit the pre-or-ongoing-mitigation telemetry notifications received limit the pre-or-ongoing-mitigation telemetry notifications received
by a DOTS client domain. by a DOTS client domain.
13.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 10.2 All data nodes defined in the YANG module specified in Section 11.2
which 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-
telemetry:vendor-mapping'), which will mislead the server when telemetry:vendor-mapping'), which will mislead the server when
correlating attack details. correlating attack details.
Some of the readable data nodes in the YANG module specified in Some of the readable data nodes in the YANG module specified in
Section 10.2 may be considered sensitive. It is thus important to Section 11.2 may be considered sensitive. It is thus important to
control read access to these data nodes. These are the data nodes control read access to these data nodes. These are the data nodes
and their sensitivity: and their sensitivity:
* '/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 13.1. compromised DOTS client attacks discussed in Section 14.1.
14. Contributors 15. Contributors
The following individuals have contributed to this document: The following individuals have contributed to this document:
* Li Su, CMCC, Email: suli@chinamobile.com * Li Su, CMCC, Email: suli@chinamobile.com
* Pan Wei, Huawei, Email: william.panwei@huawei.com * Pan Wei, Huawei, Email: william.panwei@huawei.com
15. Acknowledgements 16. Acknowledgements
The authors would like to thank Flemming Andreasen, Liang Xia, and The authors would like to thank Flemming Andreasen, Liang Xia, and
Kaname Nishizuka co-authors of [I-D.doron-dots-telemetry] and Kaname Nishizuka, co-authors of [I-D.doron-dots-telemetry], and
everyone who had contributed to that document. everyone who had contributed to that document.
The authors would like to thank Kaname Nishizuka, Wei Pan, and Yuuhei Thanks to Kaname Nishizuka, Wei Pan, Yuuhei Hayashi, and Tom Petch
Hayashi for comments and review. for comments and review.
Special thanks to Jon Shallow and Kaname Nishizuka for their Special thanks to Jon Shallow and Kaname Nishizuka for their
implementation and interoperability work. implementation and interoperability work.
Many thanks to Jan Lindblad for the yangdoctors review and Nagendra Many thanks to Jan Lindblad for the yangdoctors review, Nagendra
Nainar for the opsdir review. 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 Benjamin Kaduk for the detailed AD review.
16. References 17. References
16.1. Normative References 17.1. Normative References
[Enterprise-Numbers] [Private-Enterprise-Numbers]
"Private Enterprise Numbers", 4 May 2020, "Private Enterprise Numbers", 4 May 2020,
<http://www.iana.org/assignments/enterprise-numbers.html>. <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 page 113, line 27 skipping to change at page 114, line 19
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>. 2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed
Denial-of-Service Open Threat Signaling (DOTS) Data Denial-of-Service Open Threat Signaling (DOTS) Data
Channel Specification", RFC 8783, DOI 10.17487/RFC8783, Channel Specification", RFC 8783, DOI 10.17487/RFC8783,
May 2020, <https://www.rfc-editor.org/info/rfc8783>. May 2020, <https://www.rfc-editor.org/info/rfc8783>.
[RFC8791] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Data [RFC8791] Bierman, A., Bjรถrklund, M., and K. Watsen, "YANG Data
Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
June 2020, <https://www.rfc-editor.org/info/rfc8791>. June 2020, <https://www.rfc-editor.org/info/rfc8791>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
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>.
16.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/dots.xhtml#dots- <https://www.iana.org/assignments/dots/dots.xhtml#dots-
signal-channel-conflict-cause-codes>. signal-channel-conflict-cause-codes>.
[I-D.doron-dots-telemetry] [I-D.doron-dots-telemetry]
Doron, E., Reddy, T., Andreasen, F., (Frank), L. X., and Doron, E., Reddy, T., Andreasen, F., (Frank), L. X., and
K. Nishizuka, "Distributed Denial-of-Service Open Threat K. Nishizuka, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry Specifications", Work in Signaling (DOTS) Telemetry Specifications", Work in
Progress, Internet-Draft, draft-doron-dots-telemetry-00, Progress, Internet-Draft, draft-doron-dots-telemetry-00,
skipping to change at page 114, line 25 skipping to change at page 115, line 17
Protocol (CoAP) Block-Wise Transfer Options Supporting Protocol (CoAP) Block-Wise Transfer Options Supporting
Robust Transmission", Work in Progress, Internet-Draft, Robust Transmission", Work in Progress, Internet-Draft,
draft-ietf-core-new-block-14, 26 May 2021, draft-ietf-core-new-block-14, 26 May 2021,
<https://www.ietf.org/archive/id/draft-ietf-core-new- <https://www.ietf.org/archive/id/draft-ietf-core-new-
block-14.txt>. block-14.txt>.
[I-D.ietf-dots-multihoming] [I-D.ietf-dots-multihoming]
Boucadair, M., Reddy, T., and W. Pan, "Multi-homing Boucadair, M., Reddy, 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-09, 2 December Internet-Draft, draft-ietf-dots-multihoming-10, 4 January
2021, <https://www.ietf.org/archive/id/draft-ietf-dots- 2022, <https://www.ietf.org/archive/id/draft-ietf-dots-
multihoming-09.txt>. multihoming-10.txt>.
[I-D.ietf-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-00, 23 August 2021, blocks-01, 5 January 2022,
<https://www.ietf.org/archive/id/draft-ietf-dots-robust- <https://www.ietf.org/archive/id/draft-ietf-dots-robust-
blocks-00.txt>. blocks-01.txt>.
[Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values",
<https://www.iana.org/assignments/dots/dots.xhtml#dots- <https://www.iana.org/assignments/dots/dots.xhtml#dots-
signal-channel-cbor-key-values>. signal-channel-cbor-key-values>.
[PYANG] "pyang", November 2020, [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,
skipping to change at page 116, line 4 skipping to change at page 116, line 40
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>.
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 (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.
 End of changes. 170 change blocks. 
337 lines changed or deleted 381 lines changed or added

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