< draft-ietf-dots-telemetry-09.txt   draft-ietf-dots-telemetry-10.txt >
DOTS M. Boucadair, Ed. DOTS M. Boucadair, Ed.
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track T. Reddy, Ed. Updates: 8782 (if approved) T. Reddy, Ed.
Expires: December 21, 2020 McAfee Intended status: Standards Track McAfee
E. Doron Expires: January 11, 2021 E. Doron
Radware Ltd. Radware Ltd.
M. Chen M. Chen
CMCC CMCC
J. Shallow J. Shallow
June 19, 2020 July 10, 2020
Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
draft-ietf-dots-telemetry-09 draft-ietf-dots-telemetry-10
Abstract Abstract
This document aims to enrich DOTS signal channel protocol with This document aims to enrich DOTS signal channel protocol with
various telemetry attributes allowing optimal Distributed Denial-of- various telemetry attributes allowing optimal Distributed Denial-of-
Service attack mitigation. It specifies the normal traffic baseline Service attack mitigation. It specifies the normal traffic baseline
and attack traffic telemetry attributes a DOTS client can convey to and attack traffic telemetry attributes a DOTS client can convey to
its DOTS server in the mitigation request, the mitigation status its DOTS server in the mitigation request, the mitigation status
telemetry attributes a DOTS server can communicate to a DOTS client, telemetry attributes a DOTS server can communicate to a DOTS client,
and the mitigation efficacy telemetry attributes a DOTS client can and the mitigation efficacy telemetry attributes a DOTS client can
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 December 21, 2020. This Internet-Draft will expire on January 11, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. DOTS Telemetry: Overview and Purpose . . . . . . . . . . . . 6 3. DOTS Telemetry: Overview and Purpose . . . . . . . . . . . . 6
4. Generic Considerations . . . . . . . . . . . . . . . . . . . 9 3.1. Need More Visibility . . . . . . . . . . . . . . . . . . 6
4.1. DOTS Client Identification . . . . . . . . . . . . . . . 9 3.2. Enahnced Detection . . . . . . . . . . . . . . . . . . . 7
4.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Efficient Mitigation . . . . . . . . . . . . . . . . . . 9
4.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . . . 9 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Controlling Configuration Data . . . . . . . . . . . . . 10 4.1. Overview of Telemetry Operations . . . . . . . . . . . . 9
4.5. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 10 4.2. Generic Considerations . . . . . . . . . . . . . . . . . 10
4.6. DOTS Multi-homing Considerations . . . . . . . . . . . . 10 4.2.1. DOTS Client Identification . . . . . . . . . . . . . 10
4.7. YANG Considerations . . . . . . . . . . . . . . . . . . . 11 4.2.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . 10
4.8. A Note About Examples . . . . . . . . . . . . . . . . . . 11 4.2.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . 10
5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 11 4.2.4. Controlling Configuration Data . . . . . . . . . . . 10
6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 12 4.3. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 11
6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 13 4.4. DOTS Multi-homing Considerations . . . . . . . . . . . . 11
6.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 13 4.5. YANG Considerations . . . . . . . . . . . . . . . . . . . 11
4.6. A Note About Examples . . . . . . . . . . . . . . . . . . 12
5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 12
6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 13
6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 14
6.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 14
6.1.2. Convey DOTS Telemetry Configuration . . . . . . . . . 16 6.1.2. Convey DOTS Telemetry Configuration . . . . . . . . . 16
6.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 19 6.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 19
6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 19 6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 20
6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 20 6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 20
6.2.1. Convey DOTS Client Domain Pipe Capacity . . . . . . . 21 6.2.1. Convey DOTS Client Domain Pipe Capacity . . . . . . . 21
6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity . 26 6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity . 27
6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 26 6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 27
6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 27 6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 27
6.3.1. Convey DOTS Client Domain Baseline Information . . . 30 6.3.1. Convey DOTS Client Domain Baseline Information . . . 30
6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 33 6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 33
6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 33 6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 33
6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 33 6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 33
6.5. Conflict with Other DOTS Clients of the Same Domain . . . 33 6.5. Conflict with Other DOTS Clients of the Same Domain . . . 33
7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 34 7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 34
7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 36 7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 36
7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 36 7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 37
7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 38 7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 38
7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 39 7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 39
7.1.4. Total Attack Connections . . . . . . . . . . . . . . 41 7.1.4. Total Attack Connections . . . . . . . . . . . . . . 41
7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 42 7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 44
7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 48 7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 50
7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 51 7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 53
8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 56 8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 58
8.1. DOTS Clients to Servers Mitigation Efficacy DOTS 8.1. DOTS Clients to Servers Mitigation Efficacy DOTS
Telemetry Attributes . . . . . . . . . . . . . . . . . . 56 Telemetry Attributes . . . . . . . . . . . . . . . . . . 58
8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry 8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry
Attributes . . . . . . . . . . . . . . . . . . . . . . . 57 Attributes . . . . . . . . . . . . . . . . . . . . . . . 60
9. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 61 9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 64
9.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . . 61 10. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 66
9.2. Vendor Attack Mapping Details YANG Module . . . . . . . . 88 10.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . 66
10. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 91 10.2. Vendor Attack Mapping Details YANG Module . . . . . . . 93
11. IANA Considerationsr . . . . . . . . . . . . . . . . . . . . 95 11. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 96
11.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 95 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 99
11.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 99 12.1. A New Range for Comprehension-optional Parameters . . . 99
11.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 99 12.2. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 99
12. Security Considerations . . . . . . . . . . . . . . . . . . . 100 12.3. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 102
12.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 100 12.4. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 102
12.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 101 13. Security Considerations . . . . . . . . . . . . . . . . . . . 103
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 102 13.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 103
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 102 13.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 104
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 102 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 105
15.1. Normative References . . . . . . . . . . . . . . . . . . 102 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105
15.2. Informative References . . . . . . . . . . . . . . . . . 104 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 105
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 105 16.1. Normative References . . . . . . . . . . . . . . . . . . 105
16.2. Informative References . . . . . . . . . . . . . . . . . 107
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 108
1. Introduction 1. Introduction
Distributed Denial of Service (DDoS) attacks have become more Distributed Denial of Service (DDoS) attacks have become more
sophisticated. IT organizations and service providers are facing sophisticated. IT organizations and service providers are facing
DDoS attacks that fall into two broad categories: 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 taking down the actual delivered services, but rather to
skipping to change at page 5, line 21 skipping to change at page 5, line 27
realized. realized.
DOTS clients can send mitigation hints derived from attack details to DOTS clients can send mitigation hints derived from attack details to
DOTS servers, with the full understanding that the DOTS server may DOTS servers, with the full understanding that the DOTS server may
ignore mitigation hints, as described in [RFC8612] (Gen-004). ignore mitigation hints, as described in [RFC8612] (Gen-004).
Mitigation hints will be transmitted across the DOTS signal channel, Mitigation hints will be transmitted across the DOTS signal channel,
as the data channel may not be functional during an attack. How a as the data channel may not be functional during an attack. How a
DOTS server 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 client and server can benefit this information by Both DOTS clients and servers can benefit 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 fields. Nevertheless, when DOTS attributes are not mandatory attributes of the DOTS signal channel
telemetry attributes are available to a DOTS agent, and absent any protocol [RFC8782]. Nevertheless, when DOTS telemetry attributes are
policy, it can signal the attributes in order to optimize the overall available to a DOTS agent, and absent any policy, it can signal the
mitigation service provisioned using DOTS. Some of the DOTS attributes in order to optimize the overall mitigation service
telemetry data is not shared during an attack time. provisioned using DOTS.
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].
"DOTS Telemetry" is defined as the collection of attributes that are "DOTS Telemetry" is defined as the collection of attributes that are
used to characterize normal traffic baseline, attacks and their used to characterize normal traffic baseline, attacks and their
mitigation measures, and any related information that may help in mitigation measures, and any related information that may help in
enforcing countermeasures. The DOTS Telemetry is an optional set of enforcing countermeasures. The DOTS Telemetry is an optional set of
attributes that can be signaled in the DOTS signal channel protocol. attributes that can be signaled in the DOTS signal channel protocol.
The meaning of the symbols in YANG tree diagrams is defined in The meaning of the symbols in YANG tree diagrams are defined in
[RFC8340]. [RFC8340] and [RFC8791].
3. DOTS Telemetry: Overview and Purpose 3. DOTS Telemetry: Overview and Purpose
Timely and effective signaling of up-to-date DDoS telemetry to all
elements involved in the mitigation process is essential and improves
the overall DDoS mitigation service effectiveness. Bi-directional
feedback between DOTS agents is required for an increased awareness
of each party, supporting superior and highly efficient attack
mitigation service.
3.1. Need More Visibility
When signaling a mitigation request, it is most certainly beneficial When signaling a mitigation request, it is most certainly beneficial
for DOTS clients to signal to DOTS servers any knowledge regarding for DOTS clients to signal to DOTS servers any knowledge regarding
ongoing attacks. This can happen in cases where DOTS clients are ongoing attacks. This can happen in cases where DOTS clients are
asking DOTS servers for support in defending against attacks that asking DOTS servers for support in defending against attacks that
they have already detected and/or mitigated. These actions taken by they have already detected and/or mitigated.
DOTS clients are referred to as "signaling the DOTS Telemetry".
If attacks are already detected and categorized within a DOTS client If attacks are already detected and categorized within a DOTS client
domain, the DOTS server, and its associated mitigation services, can domain, the DOTS server, and its associated mitigation services, can
proactively benefit this information and optimize the overall service proactively benefit this information and optimize the overall service
delivery. It is important to note that DOTS clients and servers delivery. It is important to note that DOTS client domains and DOTS
detection and mitigation approaches can be different, and can server domains detection and mitigation approaches can be different,
potentially outcome different results and attack classifications. and can potentially outcome different results and attack
The DDoS mitigation service treats the ongoing attack details classifications. The DDoS mitigation service treats the ongoing
received from DOTS clients as hints and cannot completely rely or attack details received from DOTS clients as hints and cannot
trust the attack details conveyed by DOTS clients. completely rely or trust the attack details conveyed by DOTS clients.
A basic requirement of security operation teams is to be aware and A basic requirement of security operation teams is to be aware and
get visibility into the attacks they need to handle. The DOTS server get visibility into the attacks they need to handle. The DOTS server
security operation teams benefit from the DOTS telemetry, especially security operation teams benefit from the DOTS telemetry, especially
from the reports of ongoing attacks. Even if some mitigation can be from the reports of ongoing attacks. Even if some mitigation can be
automated, operational teams can use the DOTS telemetry to be automated, operational teams can use the DOTS telemetry to be
prepared for attack mitigation and to assign the correct resources prepared for attack mitigation and to assign the correct resources
(operation staff, networking and mitigation) for the specific (operation staff, networking and mitigation) for the specific
service. Similarly, security operation personnel at the DOTS client service. Similarly, security operation personnel at the DOTS client
side ask for feedback about their requests for protection. side ask for feedback about their requests for protection.
Therefore, it is valuable for DOTS servers to share DOTS telemetry Therefore, it is valuable for DOTS servers to share DOTS telemetry
with DOTS clients. with DOTS clients.
Mutual sharing of information is thus crucial for "closing the Mutual sharing of information is thus crucial for "closing the
mitigation loop" between DOTS clients and servers. For the server mitigation loop" between DOTS clients and servers. For the server
side team, it is important to realize that the same attacks that the side team, it is important to realize that the same attacks that the
DOTS server's mitigation resources are seeing are those that a DOTS DOTS server's mitigation resources are seeing are those that a DOTS
client is asking to mitigate. For the DOTS client side team, it is client is asking to mitigate. For the DOTS client side team, it is
important to realize that the DOTS clients receive the required important to realize that the DOTS clients receive the required
service. For example, understanding that "I asked for mitigation of service. For example, understanding that "I asked for mitigation of
two attacks and my DOTS server detects and mitigates only one...". two attacks and my DOTS server detects and mitigates only one of
Cases of inconsistency in attack classification between DOTS clients them". Cases of inconsistency in attack classification between DOTS
and servers can be highlighted, and maybe handled, using the DOTS clients and servers can be highlighted, and maybe handled, using the
telemetry attributes. DOTS telemetry attributes.
In addition, management and orchestration systems, at both DOTS In addition, management and orchestration systems, at both DOTS
client and server sides, can use DOTS telemetry as a feedback to client and server sides, can use DOTS telemetry as a feedback to
automate various control and management activities derived from automate various control and management activities derived from
signaled telemetry information. signaled telemetry information.
If the DOTS server's mitigation resources have the capabilities to If the DOTS server's mitigation resources have the capabilities to
facilitate the DOTS telemetry, the DOTS server adapts its protection facilitate the DOTS telemetry, the DOTS server adapts its protection
strategy and activates the required countermeasures immediately strategy and activates the required countermeasures immediately
(automation enabled) for the sake of optimized attack mitigation (automation enabled) for the sake of optimized attack mitigation
decisions and actions. decisions and actions.
3.2. Enahnced Detection
DOTS telemetry can also be used to tune the DDoS mitigators with the DOTS telemetry can also be used to tune the DDoS mitigators with the
correct state of an attack. During the last few years, DDoS attack correct state of an attack. During the last few years, DDoS attack
detection technologies have evolved from threshold-based detection detection technologies have evolved from threshold-based detection
(that is, cases when all or specific parts of traffic cross a pre- (that is, cases when all or specific parts of traffic cross a pre-
defined threshold for a certain period of time is considered as an defined threshold for a certain period of time is considered as an
attack) to an "anomaly detection" approach. For the latter, it is attack) to an "anomaly detection" approach. For the latter, it is
required to maintain rigorous learning of "normal" behavior and where required to maintain rigorous learning of "normal" behavior and where
an "anomaly" (or an attack) is identified and categorized based on an "anomaly" (or an attack) is identified and categorized based on
the knowledge about the normal behavior and a deviation from this the knowledge about the normal behavior and a deviation from this
normal behavior. Machine learning approaches are used such that the normal behavior. Machine learning approaches are used such that the
skipping to change at page 8, line 35 skipping to change at page 9, line 5
In addition, baseline learning requires a period of time that In addition, baseline learning requires a period of time that
cannot be afforded during active attack. cannot be afforded during active attack.
Of course, this information can provided using out-of-band Of course, this information can provided using out-of-band
mechanisms or manual configuration at the risk to maintain mechanisms or manual configuration at the risk to maintain
inaccurate information as the network evolves and "normal" inaccurate information as the network evolves and "normal"
patterns change. The use of a dynamic and collaborative means patterns change. The use of a dynamic and collaborative means
between the DOTS client and server to identify and share key between the DOTS client and server to identify and share key
parameters for the sake of efficient DDoS protection is valuable. parameters for the sake of efficient DDoS protection is valuable.
3.3. Efficient Mitigation
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 "clean traffic", or what it believes is "clean". This sending back "clean traffic", or what it believes is "clean". This
can happen when the mitigator has not managed to detect and mitigate can happen when the mitigator has not managed to detect and mitigate
all the attacks launched towards the DOTS client domain. In this all the attacks launched towards the DOTS client domain.
case, it can be valuable to DOTS clients to signal to DOTS servers
the "total pipe capacity", which is the level of traffic the DOTS In this case, it can be valuable to DOTS clients to signal to DOTS
client domain can absorb from its upstream network. Dynamic updates servers the "total pipe capacity", which is the level of traffic the
of the condition of pipes between DOTS agents while they are under a DOTS client domain can absorb from its upstream network. Dynamic
DDoS attack is essential (e.g., where multiple DOTS clients share the updates of the condition of pipes between DOTS agents while they are
same physical connectivity pipes). It is important to note that the under a DDoS attack is essential (e.g., where multiple DOTS clients
term "pipe" noted here does not necessary represent physical pipe, share the same physical connectivity pipes). It is important to note
but rather represents the maximum level of traffic that the DOTS that the term "pipe" noted here does not necessary represent physical
client domain can receive. The DOTS server should activate other pipe, but rather represents the maximum level of traffic that the
mechanisms to ensure it does not allow the DOTS client domain's pipes DOTS client domain can receive. The DOTS server should activate
to be saturated unintentionally. The rate-limit action defined in other mechanisms to ensure it does not allow the DOTS client domain's
[RFC8783] is a reasonable candidate to achieve this objective; the pipes to be saturated unintentionally. The rate-limit action defined
in [RFC8783] is a reasonable candidate to achieve this objective; the
DOTS client can ask for the type(s) of traffic (such as ICMP, UDP, DOTS client can ask for the type(s) of traffic (such as ICMP, UDP,
TCP port number 80) it prefers to limit. The rate-limit action can TCP port number 80) it prefers to limit. The rate-limit action can
be controlled via the signal-channel be controlled via the signal-channel
[I-D.ietf-dots-signal-filter-control] even when the pipe is [I-D.ietf-dots-signal-filter-control] even when the pipe is
overwhelmed. overwhelmed.
To summarize: 4. Design Overview
Timely and effective signaling of up-to-date DDoS telemetry to all 4.1. Overview of Telemetry Operations
elements involved in the mitigation process is essential and
absolutely improves the overall DDoS mitigation service
effectiveness. Bi-directional feedback between DOTS agents is
required for an increased awareness of each party, supporting
superior and highly efficient attack mitigation service.
4. Generic Considerations This document specifies an extension to the DOTS signal channel
protocol. Considerations about how to establish, maintain, and make
use of the DOTS signal channel are specified in [RFC8782].
4.1. DOTS Client Identification Once the DOTS signal channel is established, DOTS clients that
support the DOTS telemetry extension proceed with the telemetry setup
configuration (e.g., measurement interval, telemetry notification
interface, pipe capacity, normal traffic baseline) as detailed in
Section 6. DOTS agents can then include DOTS telemetry attributes
using the DOTS signal channel (Section 7.1). Typically, a DOTS
client can use 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 client that is interested to receive telemetry
notifications related to some of its resources follows the procedure
defined in Section 7.3. The DOTS client can then decide to send a
mitigation request if the notified attack cannot be mitigated locally
within the DOTS client domain.
Aggregate DOTS telemetry data can also be included in efficacy update
(Section 8.1) or mitigation update (Section 8.2) messages.
4.2. Generic Considerations
4.2.1. DOTS Client Identification
Following the rules in Section 4.4.1 of [RFC8782], a unique Following the rules in Section 4.4.1 of [RFC8782], a unique
identifier is generated by a DOTS client to prevent request identifier is generated by a DOTS client to prevent request
collisions ('cuid'). collisions ('cuid').
As a reminder, [RFC8782] forbids 'cuid' to be returned in a response As a reminder, [RFC8782] forbids 'cuid' to be returned in a response
message body. message body.
4.2. DOTS Gateways 4.2.2. DOTS Gateways
DOTS gateways may be located between DOTS clients and servers. The DOTS gateways may be located between DOTS clients and servers. The
considerations elaborated in Section 4.4.1 of [RFC8782] must be considerations elaborated in Section 4.4.1 of [RFC8782] must be
followed. In particular, 'cdid' attribute is used to unambiguously followed. In particular, 'cdid' attribute is used to unambiguously
identify a DOTS client domain. identify a DOTS client domain.
As a reminder, [RFC8782] forbids 'cdid' (if present) to be returned As a reminder, [RFC8782] forbids 'cdid' (if present) to be returned
in a response message body. in a response message body.
4.3. Empty URI Paths 4.2.3. Empty URI Paths
Uri-Path parameters and attributes with empty values MUST NOT be Uri-Path parameters and attributes with empty values MUST NOT be
present in a request and render an entire message invalid. present in a request and render an entire message invalid.
4.4. Controlling Configuration Data 4.2.4. Controlling Configuration Data
The DOTS server follows the same considerations discussed in The DOTS server follows the same considerations discussed in
Section of 4.5.3 of [RFC8782] for managing DOTS telemetry Section of 4.5.3 of [RFC8782] for managing DOTS telemetry
configuration freshness and notification. Likewise, a DOTS client configuration freshness and notification.
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
[RFC8782]. These considerations are not re-iterated in the following
sections.
4.5. Block-wise Transfer 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 [RFC8782]. These considerations are not re-
iterated in the following sections.
4.3. 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 [RFC8782] to control the recommendation detailed in Section 4.4.2 of [RFC8782] 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 (see DOTS clients can also use CoAP Block1 Option in a PUT request (see
Section 2.5 of [RFC7959]) to initiate large transfers, but these Section 2.5 of [RFC7959]) to initiate large transfers, but these
Block1 transfers will fail if the inbound "pipe" is running full, so Block1 transfers will fail if the inbound "pipe" is running full, so
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.
Block3 and Block 4 Options that are similar to the CoAP Block1 and Block3 and Block 4 Options that are similar to the CoAP Block1 and
Block2 Options, but enable faster transmissions of big blocks of data Block2 Options, but enable faster transmissions of big blocks of data
with less packet interchanges, are defined in with less packet interchanges, are defined in
[I-D.bosh-core-new-block]. DOTS implementations can consider the use [I-D.bosh-core-new-block]. DOTS implementations can consider the use
of Block3 and Block 4 Options. of Block3 and Block 4 Options.
4.6. DOTS Multi-homing Considerations 4.4. DOTS Multi-homing Considerations
Multi-homed DOTS clients are assumed to follow the recommendations in Multi-homed DOTS clients are assumed to follow the recommendations in
[I-D.ietf-dots-multihoming] to select which DOTS server to contact [I-D.ietf-dots-multihoming] to select which DOTS server to contact
and which IP prefixes to include in a telemetry message to a given and which IP prefixes to include in a telemetry message to a given
peer DOTS server. For example, if each upstream network exposes a peer DOTS server. For example, if each upstream network exposes a
DOTS server and the DOTS client maintains DOTS channels with all of DOTS server and the DOTS client maintains DOTS channels with all of
them, only the information related to prefixes assigned by an them, only the information related to prefixes assigned by an
upstream network to the DOTS client domain will be signaled via the upstream network to the DOTS client domain will be signaled via the
DOTS channel established with the DOTS server of that upstream DOTS channel established with the DOTS server of that upstream
network. Considerations related to whether (and how) a DOTS client network.
gleans some telemetry information (e.g., attack details) it receives
from a first DOTS server and share it with a second DOTS server are
implementation and deployment-specific.
4.7. YANG Considerations Considerations related to whether (and how) a DOTS client gleans some
telemetry information (e.g., attack details) it receives from a first
DOTS server and share it with a second DOTS server are implementation
and deployment-specific.
4.5. 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). CBOR-encoded payloads Concise Binary Object Representation (CBOR) [RFC7252]. CBOR-encoded
are used to carry signal channel-specific payload messages which payloads are used to carry signal channel-specific payload messages
convey request parameters and response information such as errors. which convey request parameters and response information such as
errors.
This document specifies a YANG module for representing DOTS telemetry This document specifies a YANG module for representing DOTS telemetry
message types (Section 9.1). All parameters in the payload of the message types (Section 10.1). All parameters in the payload of the
DOTS signal channel are mapped to CBOR types as specified in DOTS signal channel are mapped to CBOR types as specified in
Section 10. Section 11.
The DOTS telemetry module (Section 9.1) is not intended to be used The DOTS telemetry module (Section 10.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, but not a management data only to provide a data model and encoding following [RFC8791].
model. DOTS servers are allowed to update the non-configurable 'ro'
entities in the responses of DOTS telemetry messages.
The DOTS telemetry module (Section 9.1) uses "enumerations" rather The DOTS telemetry module (Section 10.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. suboptimal from a message compactness standpoint.
4.8. A Note About Examples 4.6. A Note About Examples
Examples are provided for illustration purposes. The document does Examples are provided for illustration purposes. The document does
not aim to provide a comprehensive list of message examples. not aim to provide a comprehensive list of message examples.
The authoritative reference for validating telemetry messages is the The authoritative reference for validating telemetry messages is the
YANG module (Section 9.1) and the mapping table established in YANG module (Section 10.1) and the mapping table established in
Section 10. Section 11.
5. Telemetry Operation Paths 5. Telemetry Operation Paths
As discussed in Section 4.2 of [RFC8782], each DOTS operation is As discussed in Section 4.2 of [RFC8782], 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 1):
+-----------------+----------------+-----------+ +-----------------+----------------+-----------+
| 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 1: DOTS Telemetry Operations
Consequently, the "ietf-dots-telemetry" YANG module defined in Consequently, the "ietf-dots-telemetry" YANG module defined in
Section 9.1 augments the "ietf-dots-signal" with two new message Section 10.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 the following is shown in Figure 1. More details are provided in Sections 6 and 7
sections about the exact structure of "telemetry-setup" and about the exact structure of "telemetry-setup" and "telemetry"
"telemetry" message types). message types.
augment /ietf-signal:dots-signal/ietf-signal:message-type: structure dots-telemetry:
+--:(telemetry-setup) {dots-telemetry}? +-- (telemetry-message-type)?
| ... +--:(telemetry-setup)
| +--rw (setup-type)? | ...
| +--:(telemetry-config) | +-- telemetry* []
| | ... | ...
| +--:(pipe) | +-- (setup-type)?
| | ... | +--:(telemetry-config)
| +--:(baseline) | | ...
| ... | +--:(pipe)
+--:(telemetry) {dots-telemetry}? | | ...
... | +--:(baseline)
| ...
+--:(telemetry)
...
Figure 1: New DOTS Message Types (YANG Tree Structure) Figure 1: New DOTS Message Types (YANG Tree Structure)
6. DOTS Telemetry Setup Configuration 6. 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 6.1) or
information about DOTS client domain pipe capacity (Section 6.2) or information about DOTS client domain pipe capacity (Section 6.2) or
telemetry traffic baseline (Section 6.3). As such, requests that telemetry traffic baseline (Section 6.3). As such, requests that
include a mix of telemetry configuration, pipe capacity, or traffic include a mix of telemetry configuration, pipe capacity, or traffic
skipping to change at page 13, line 17 skipping to change at page 13, line 51
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 has a validity timeout of the DOTS association setup configuration has a validity timeout of the DOTS association
with a DOTS client domain. DOTS servers MUST NOT reset 'tsid' with a DOTS client domain. DOTS servers MUST NOT reset 'tsid'
because a session failed with a DOTS client. DOTS clients update because a session failed with a DOTS client. DOTS clients update
their telemetry setup configuration upon change of a parameter that their telemetry setup configuration upon change of a parameter that
may impact attack mitigation. may 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. marked as Confirmable messages (Section 2.1 of [RFC7252]).
6.1. Telemetry Configuration 6.1. Telemetry Configuration
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:
o Percentile-related measurement parameters o Percentile-related measurement parameters
o Measurement units o Measurement units
skipping to change at page 13, line 42 skipping to change at page 14, line 28
o Acceptable Server-originated telemetry o Acceptable Server-originated telemetry
Section 11.3 of [RFC2330] includes more details about computing Section 11.3 of [RFC2330] includes more details about computing
percentiles. percentiles.
6.1.1. Retrieve Current DOTS Telemetry Configuration 6.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' Path-URI 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 request is depicted in Figure 2. gateway. An example of such request is 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 request, the DOTS server replies with a 2.05 Upon receipt of such request, and assuming no error is encountered by
(Content) response that conveys the current and telemetry parameters processing the request, the DOTS server replies with a 2.05 (Content)
acceptable by the DOTS server. The tree structure of the response response that conveys the current and telemetry parameters acceptable
message body is provided in Figure 3. Note that the response also by the DOTS server. The tree structure of the response message body
includes any pipe (Section 6.2) and baseline information is provided in Figure 3. Note that the response also includes any
(Section 6.3) maintained by the DOTS server for this DOTS client. pipe (Section 6.2) and baseline information (Section 6.3) maintained
by the DOTS server for this DOTS client.
DOTS servers that support the capability of sending telemetry DOTS servers that support the capability of sending telemetry
information to DOTS clients prior or during a mitigation information to DOTS clients prior or during a mitigation
(Section 8.2) sets 'server-originated-telemetry' under 'max-config- (Section 8.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 request with 'server-originated-telemetry' equivalent to receiving a request with 'server-originated-telemetry'
set to 'false'. set to 'false'.
augment /ietf-signal:dots-signal/ietf-signal:message-type: structure dots-telemetry:
+--:(telemetry-setup) {dots-telemetry}? +-- (telemetry-message-type)?
| +--ro max-config-values +--:(telemetry-setup)
| | +--ro measurement-interval? interval | +-- (direction)?
| | +--ro measurement-sample? sample | | +--:(server-to-client-only)
| | +--ro low-percentile? percentile | | +-- max-config-values
| | +--ro mid-percentile? percentile | | | +-- measurement-interval? interval
| | +--ro high-percentile? percentile | | | +-- measurement-sample? sample
| | +--ro server-originated-telemetry? boolean | | | +-- low-percentile? percentile
| | +--ro telemetry-notify-interval? uint32 | | | +-- mid-percentile? percentile
| +--ro min-config-values | | | +-- high-percentile? percentile
| | +--ro measurement-interval? interval | | | +-- server-originated-telemetry? boolean
| | +--ro measurement-sample? sample | | | +-- telemetry-notify-interval? uint32
| | +--ro low-percentile? percentile | | +-- min-config-values
| | +--ro mid-percentile? percentile | | | +-- measurement-interval? interval
| | +--ro high-percentile? percentile | | | +-- measurement-sample? sample
| | +--ro telemetry-notify-interval? uint32 | | | +-- low-percentile? percentile
| +--ro supported-units | | | +-- mid-percentile? percentile
| | +--ro unit-config* [unit] | | | +-- high-percentile? percentile
| | +--ro unit unit-type | | | +-- telemetry-notify-interval? uint32
| | +--ro unit-status boolean | | +-- supported-units
| +--ro query-type* query-type | | | +-- unit-config* [unit]
| +--rw telemetry* [cuid tsid] | | | +-- unit unit-type
| +--rw cuid string | | | +-- unit-status boolean
| +--rw cdid? string | | +-- query-type* query-type
| +--rw tsid uint32 | +-- telemetry* []
| +--rw (setup-type)? | +-- (direction)?
| +--:(telemetry-config) | | +--:(server-to-client-only)
| | +--rw current-config | | +-- tsid? uint32
| | +--rw measurement-interval? interval | +-- (setup-type)?
| | +--rw measurement-sample? sample | +--:(telemetry-config)
| | +--rw low-percentile? percentile | | +-- current-config
| | +--rw mid-percentile? percentile | | +-- measurement-interval? interval
| | +--rw high-percentile? percentile | | +-- measurement-sample? sample
| | +--rw unit-config* [unit] | | +-- low-percentile? percentile
| | | +--rw unit unit-type | | +-- mid-percentile? percentile
| | | +--rw unit-status boolean | | +-- high-percentile? percentile
| | +--rw server-originated-telemetry? boolean | | +-- unit-config* [unit]
| | +--rw telemetry-notify-interval? uint32 | | | +-- unit unit-type
| +--:(pipe) | | | +-- unit-status boolean
| ... | | +-- server-originated-telemetry? boolean
| +--:(baseline) | | +-- telemetry-notify-interval? uint32
| ... | +--:(pipe)
+--:(telemetry) {dots-telemetry}? | | ...
+--rw pre-or-ongoing-mitigation* [cuid tmid] | +--:(baseline)
... | ...
+--:(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. Convey DOTS Telemetry Configuration 6.1.2. Convey DOTS Telemetry Configuration
skipping to change at page 17, line 10 skipping to change at page 17, line 15
tsid: Telemetry Setup Identifier is an identifier for the DOTS tsid: Telemetry Setup Identifier is an identifier for the DOTS
telemetry setup configuration data represented as an integer. telemetry setup configuration data represented as an integer.
This identifier MUST be generated by DOTS clients. 'tsid' This identifier MUST be generated by DOTS clients. 'tsid'
values MUST increase monotonically (when a new PUT is generated values MUST increase monotonically (when a new PUT is generated
by a DOTS client to convey new configuration parameters for the by a DOTS client to convey new configuration parameters for the
telemetry). telemetry).
The procedure specified in Section 4.4.1 of [RFC8782] MUST be The procedure specified in Section 4.4.1 of [RFC8782] MUST be
followed for 'tsid' rollover. followed for 'tsid' rollover.
This is a mandatory attribute. This is a mandatory attribute. 'tsid' MUST follow 'cuid'.
'cuid' and 'tsid' MUST NOT appear in the PUT request message body. 'cuid' and 'tsid' MUST NOT appear in the PUT request message body.
At least one configurable attribute MUST be present in the PUT At least one configurable attribute MUST be present in the PUT
request. request.
The PUT request with a higher numeric 'tsid' value overrides the DOTS The PUT request with a higher numeric 'tsid' value overrides the DOTS
telemetry configuration data installed by a PUT request with a lower telemetry configuration data installed by a PUT request with a lower
numeric 'tsid' value. To avoid maintaining a long list of 'tsid' numeric 'tsid' value. To avoid maintaining a long list of 'tsid'
requests for requests carrying telemetry configuration data from a requests for requests carrying telemetry configuration data from a
DOTS client, the lower numeric 'tsid' MUST be automatically deleted DOTS client, the lower numeric 'tsid' MUST be automatically deleted
and no longer be available at the DOTS server. and no longer be available at the DOTS server.
The DOTS server indicates the result of processing the PUT request The DOTS server indicates the result of processing the PUT request
using the following response codes: using the following Response Codes:
o If the request is missing a mandatory attribute, does not include o If the request is missing a mandatory attribute, does not include
'cuid' or 'tsid' Uri-Path parameters, or contains one or more 'cuid' or 'tsid' Uri-Path parameters, or contains one or more
invalid or unknown parameters, 4.00 (Bad Request) MUST be returned invalid or unknown parameters, 4.00 (Bad Request) MUST be returned
in the response. in the response.
o If the DOTS server does not find the 'tsid' parameter value o If the DOTS server does not find the 'tsid' parameter value
conveyed in the PUT request in its configuration data and if the conveyed in the PUT request in its configuration data and if the
DOTS server has accepted the configuration parameters, then a DOTS server has accepted the configuration parameters, then a 2.01
response code 2.01 (Created) MUST be returned in the response. (Created) Response Code MUST be returned in the response.
o If the DOTS server finds the 'tsid' parameter value conveyed in o 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.
o If any of the enclosed configurable attribute values are not o 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 6.1.1), 4.22 (Unprocessable
Entity) MUST be returned in the response. Entity) MUST be returned in the response.
skipping to change at page 19, line 45 skipping to change at page 19, line 48
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 6.1.4. Delete DOTS Telemetry Configuration
A DELETE request is used to delete the installed DOTS telemetry A DELETE request is used to delete the installed DOTS telemetry
configuration data (Figure 8). 'cuid' and 'tsid' are mandatory Uri- configuration data (Figure 8). 'cuid' and 'tsid' are mandatory Uri-
Path parameters for such DELETE requests. Path parameters for such DELETE requests.
Header: DELETE (Code=0.04) Header: DELETE (Code=0.04)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=123" Uri-Path: "tsid=123"
Figure 8: 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 6.4 discusses the procedure to reset all DOTS telemetry setup
configuration. configuration.
6.2. Total Pipe Capacity 6.2. Total Pipe Capacity
A DOTS client can communicate to its server(s) its DOTS client domain A DOTS client can communicate to the DOTS server(s) its DOTS client
pipe information. The tree structure of the pipe information is domain pipe information. The tree structure of the pipe information
shown in Figure 9. is shown in Figure 9.
augment /ietf-signal:dots-signal/ietf-signal:message-type: structure dots-telemetry:
+--:(telemetry-setup) {dots-telemetry}? +-- (telemetry-message-type)?
| ... +--:(telemetry-setup)
| +--rw telemetry* [cuid tsid] | ...
| +--rw cuid string | +-- telemetry* []
| +--rw cdid? string | +-- (direction)?
| +--rw tsid uint32 | | +--:(server-to-client-only)
| +--rw (setup-type)? | | +-- tsid? uint32
| +--:(telemetry-config) | +-- (setup-type)?
| | ... | +--:(telemetry-config)
| +--:(pipe) | | ...
| | +--rw total-pipe-capacity* [link-id unit] | +--:(pipe)
| | +--rw link-id nt:link-id | | +-- total-pipe-capacity* [link-id unit]
| | +--rw capacity uint64 | | +-- link-id nt:link-id
| | +--rw unit unit | | +-- capacity uint64
| +--:(baseline) | | +-- unit unit
| ... | +--:(baseline)
+--:(telemetry) {dots-telemetry}? | ...
+--rw pre-or-ongoing-mitigation* [cuid tmid] +--:(telemetry)
... ...
Figure 9: Pipe Tree Structure Figure 9: Pipe Tree Structure
A DOTS client domain pipe is defined as a list of limits of A DOTS client domain pipe is defined as a list of limits of
(incoming) traffic volume (total-pipe-capacity") that can be (incoming) traffic volume (total-pipe-capacity") that can be
forwarded over ingress interconnection links of a DOTS client domain. forwarded over ingress interconnection links of a DOTS client domain.
Each of these links is identified with a "link-id" [RFC8345]. Each of these links is identified with a "link-id" [RFC8345].
The unit used by a DOTS client when conveying pipe information is The unit used by a DOTS client when conveying pipe information is
skipping to change at page 22, line 33 skipping to change at page 23, line 6
] ]
} }
] ]
} }
} }
Figure 11: Example of a PUT Request to Convey Pipe Information Figure 11: Example of a PUT Request to Convey Pipe Information
(Single Homed) (Single Homed)
DOTS clients may be instructed to signal a link aggregate instead of DOTS clients may be instructed to signal a link aggregate instead of
individual links. For example, a DOTS client managing a DOTS client individual links. For example, a DOTS client that manages a DOTS
domain having two interconnection links with an upstream ISP client domain having two interconnection links with an upstream ISP
(Figure 12) can send a PUT request (shown in Figure 13) to (Figure 12) can send a PUT request (shown in Figure 13) to
communicate the aggregate link capacity with its ISP. Signalling communicate the aggregate link capacity with its ISP. Signalling
individual or aggregate link capacity is deployment-specific. individual or aggregate link capacity is deployment-specific.
,--,--,--. ,--,--,--. ,--,--,--. ,--,--,--.
,-' `-.===== ,-' `-. ,-' `-.===== ,-' `-.
( DOTS Client ) ( ISP#C ) ( DOTS Client ) ( ISP#C )
`-. Domain ,-'====== `-. ,-' `-. Domain ,-'====== `-. ,-'
`--'--'--' `--'--'--' `--'--'--' `--'--'--'
skipping to change at page 23, line 33 skipping to change at page 23, line 48
] ]
} }
] ]
} }
} }
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 (ISP#B of Figure 14), the DOTS client can inform a an additional ISP (e.g., ISP#B of Figure 14), the DOTS client can
third-party DOTS server (that is, not hosted with ISP#A and ISP#B inform a third-party DOTS server (that is, not hosted with ISP#A and
domains) about this update by sending the PUT request depicted in ISP#B domains) about this update by sending the PUT request depicted
Figure 15. This request also includes information related to "link1" in Figure 15. This request also includes information related to
even if that link is not upgraded. Upon receipt of this request, the "link1" even if that link is not upgraded. Upon receipt of this
DOTS server removes the request with 'tsid=457' and updates its request, the DOTS server removes the request with 'tsid=457' and
configuration base to maintain two links (link#1 and link#2). updates its configuration base to maintain two links (link#1 and
link#2).
,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
( ISP#B ) ( ISP#B )
`-. ,-' `-. ,-'
`--'--'--' `--'--'--'
|| ||
|| link2 || link2
,--,--,--. ,--,--,--. ,--,--,--. ,--,--,--.
,-' `-. ,-' `-. ,-' `-. ,-' `-.
skipping to change at page 25, line 12 skipping to change at page 25, line 44
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 6.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, the DOTS server removes Figure 17. Upon receipt of this request, and assuming no error is
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.
,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
( ISP#B ) ( ISP#B )
`-. ,-' `-. ,-'
`--'--'--' `--'--'--'
|| ||
|| link2 || link2
,--,--,--. ,--,--,--.
skipping to change at page 27, line 7 skipping to change at page 27, line 22
client proceeds as specified in Section 6.1.1. client proceeds as specified in Section 6.1.1.
6.2.3. Delete Installed DOTS Client Domain Pipe Capacity 6.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 6.1.4 is followed.
6.3. Telemetry Baseline 6.3. Telemetry Baseline
A DOTS client can communicate to its server(s) its normal traffic A DOTS client can communicate to its DOTS server(s) its normal
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-
skipping to change at page 28, line 23 skipping to change at page 28, line 38
connection with a target but do not send a complete request connection with a target but do not send a complete request
(e.g., HTTP request). (e.g., HTTP request).
* The maximum number of partial requests allowed per second to * The maximum number of partial requests allowed per second to
the target per client. the target per client.
The aggregate per transport protocol is captured in 'total- The aggregate per transport protocol is captured in 'total-
connection-capacity', while port-specific capabilities are connection-capacity', while port-specific capabilities are
represented using 'total-connection-capacity-per-port'. represented using 'total-connection-capacity-per-port'.
The tree structure of the baseline is shown in Figure 18. The tree structure of the normal traffic baseline is shown in
Figure 18.
augment /ietf-signal:dots-signal/ietf-signal:message-type: structure dots-telemetry:
+--:(telemetry-setup) {dots-telemetry}? +-- (telemetry-message-type)?
| ... +--:(telemetry-setup)
| +--rw telemetry* [cuid tsid] | ...
| +--rw cuid string | +-- telemetry* []
| +--rw cdid? string | +-- (direction)?
| +--rw tsid uint32 | | +--:(server-to-client-only)
| +--rw (setup-type)? | | +-- tsid? uint32
| +--:(telemetry-config) | +-- (setup-type)?
| | ... | +--:(telemetry-config)
| +--:(pipe) | | ...
| | ... | +--:(pipe)
| +--:(baseline) | | ...
| +--rw baseline* [id] | +--:(baseline)
| +--rw id uint32 | +-- baseline* [id]
| +--rw target-prefix* inet:ip-prefix | +-- id
| +--rw target-port-range* [lower-port] | | uint32
| | +--rw lower-port inet:port-number | +-- target-prefix*
| | +--rw upper-port? inet:port-number | | inet:ip-prefix
| +--rw target-protocol* uint8 | +-- target-port-range* [lower-port]
| +--rw target-fqdn* inet:domain-name | | +-- lower-port inet:port-number
| +--rw target-uri* inet:uri | | +-- upper-port? inet:port-number
| +--rw alias-name* string | +-- target-protocol* uint8
| +--rw total-traffic-normal* [unit] | +-- target-fqdn*
| | +--rw unit unit | | inet:domain-name
| | +--rw low-percentile-g? yang:gauge64 | +-- target-uri*
| | +--rw mid-percentile-g? yang:gauge64 | | inet:uri
| | +--rw high-percentile-g? yang:gauge64 | +-- alias-name*
| | +--rw peak-g? yang:gauge64 | | string
| +--rw total-traffic-normal-per-protocol* [unit protocol] | +-- total-traffic-normal* [unit]
| | +--rw unit unit | | +-- unit unit
| | +--rw protocol uint8 | | +-- low-percentile-g? yang:gauge64
| | +--rw low-percentile-g? yang:gauge64 | | +-- mid-percentile-g? yang:gauge64
| | +--rw mid-percentile-g? yang:gauge64 | | +-- high-percentile-g? yang:gauge64
| | +--rw high-percentile-g? yang:gauge64 | | +-- peak-g? yang:gauge64
| | +--rw peak-g? yang:gauge64 | +-- total-traffic-normal-per-protocol*
| +--rw total-traffic-normal-per-port* [unit port] | | [unit protocol]
| | +--rw port inet:port-number | | +-- protocol uint8
| | +--rw unit unit | | +-- unit unit
| | +--rw low-percentile-g? yang:gauge64 | | +-- low-percentile-g? yang:gauge64
| | +--rw mid-percentile-g? yang:gauge64 | | +-- mid-percentile-g? yang:gauge64
| | +--rw high-percentile-g? yang:gauge64 | | +-- high-percentile-g? yang:gauge64
| | +--rw peak-g? yang:gauge64 | | +-- peak-g? yang:gauge64
| +--rw total-connection-capacity* [protocol] | +-- total-traffic-normal-per-port* [unit port]
| | +--rw protocol uint8 | | +-- port inet:port-number
| | +--rw connection? uint64 | | +-- unit unit
| | +--rw connection-client? uint64 | | +-- low-percentile-g? yang:gauge64
| | +--rw embryonic? uint64 | | +-- mid-percentile-g? yang:gauge64
| | +--rw embryonic-client? uint64 | | +-- high-percentile-g? yang:gauge64
| | +--rw connection-ps? uint64 | | +-- peak-g? yang:gauge64
| | +--rw connection-client-ps? uint64 | +-- total-connection-capacity* [protocol]
| | +--rw request-ps? uint64 | | +-- protocol uint8
| | +--rw request-client-ps? uint64 | | +-- connection? uint64
| | +--rw partial-request-ps? uint64 | | +-- connection-client? uint64
| | +--rw partial-request-client-ps? uint64 | | +-- embryonic? uint64
| +--rw total-connection-capacity-per-port* [protocol port] | | +-- embryonic-client? uint64
| +--rw protocol uint8 | | +-- connection-ps? uint64
| +--rw port inet:port-number | | +-- connection-client-ps? uint64
| +--rw connection? uint64 | | +-- request-ps? uint64
| +--rw connection-client? uint64 | | +-- request-client-ps? uint64
| +--rw embryonic? uint64 | | +-- partial-request-ps? uint64
| +--rw embryonic-client? uint64 | | +-- partial-request-client-ps? uint64
| +--rw connection-ps? uint64 | +-- total-connection-capacity-per-port*
| +--rw connection-client-ps? uint64 | [protocol port]
| +--rw request-ps? uint64 | +-- port
| +--rw request-client-ps? uint64 | | inet:port-number
| +--rw partial-request-ps? uint64 | +-- protocol uint8
| +--rw partial-request-client-ps? uint64 | +-- connection? uint64
+--:(telemetry) {dots-telemetry}? | +-- connection-client? uint64
+--rw pre-or-ongoing-mitigation* [cuid tmid] | +-- embryonic? uint64
... | +-- embryonic-client? uint64
| +-- connection-ps? uint64
| +-- connection-client-ps? uint64
| +-- request-ps? uint64
| +-- request-client-ps? uint64
| +-- partial-request-ps? uint64
| +-- partial-request-client-ps? uint64
+--:(telemetry)
...
Figure 18: Telemetry Baseline Tree Structure Figure 18: Telemetry Baseline Tree Structure
6.3.1. Convey DOTS Client Domain Baseline Information 6.3.1. Convey DOTS Client Domain Baseline Information
Similar considerations to those specified in Section 6.1.2 are Similar considerations to those specified in Section 6.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
skipping to change at page 32, line 45 skipping to change at page 32, line 45
] ]
} }
] ]
} }
] ]
} }
} }
Figure 20: PUT to Convey the DOTS Traffic Baseline (2) Figure 20: PUT to Convey the DOTS Traffic Baseline (2)
The 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 6.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 6.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
skipping to change at page 33, line 47 skipping to change at page 33, line 47
A DOTS server may detect conflicts between requests to convey pipe A DOTS server may detect conflicts between requests to convey 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 [RFC8782]. The conflict cause can be set to one of Section 4.4.1 of [RFC8782]. The conflict cause can be set to one of
these values: these values:
1: Overlapping targets (Section 4.4.1 of [RFC8782]). 1: Overlapping targets (Section 4.4.1 of [RFC8782]).
TBA: Overlapping pipe scope (see Section 11). TBA: Overlapping pipe scope (see Section 12).
7. DOTS Pre-or-Ongoing Mitigation Telemetry 7. DOTS Pre-or-Ongoing Mitigation Telemetry
There are two broad types of DDoS attacks, one is bandwidth consuming There are two broad types of DDoS attacks, one is bandwidth consuming
attack, the other is target resource consuming attack. This section attack, the other is target resource consuming attack. This section
outlines the set of DOTS telemetry attributes (Section 7.1) that outlines the set of DOTS telemetry attributes (Section 7.1) that
covers both the types of attacks. The objective of these attributes covers both the types of attacks. The objective of these attributes
is to allow for the complete knowledge of attacks and the various is to allow for the complete knowledge of attacks and the various
particulars that can best characterize attacks. particulars that can best characterize attacks.
The "ietf-dots-telemetry" YANG module (Section 9.1) augments the The "ietf-dots-telemetry" YANG module (Section 10.1) defines the data
"ietf-dots-signal" with a new message type called "telemetry". The structure of a new message type called "telemetry". The tree
tree structure of the "telemetry" message type is shown 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 7.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 with DOTS agents SHOULD bind pre-or-ongoing-mitigation telemetry data with
mitigation requests relying upon the target clause. In particular, a mitigation requests relying upon the target clause. In particular, a
telemetry PUT request sent after a mitigation request may include a telemetry PUT request sent after a mitigation request may include a
reference to that mitigation request ('mid-list') as shown in reference to that mitigation request ('mid-list') as shown in
Figure 22. An example illustrating requests correlation by means of Figure 22. An example illustrating requests correlation by means of
'target-prefix' is shown in Figure 23. 'target-prefix' is shown in Figure 23.
When generating telemetry data to send to a peer, the DOTS agent must When generating telemetry data to send to a peer, the DOTS agent MUST
auto-scale so that appropriate unit(s) are used. auto-scale so that appropriate unit(s) 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 35, line 25 skipping to change at page 35, line 25
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 6.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.bosh-core-new-block]), this rate limit policy MUST NOT consider [I-D.bosh-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. messages MUST be marked as Non-Confirmable messages (Section 2.1 of
[RFC7252]).
augment /ietf-signal:dots-signal/ietf-signal:message-type: structure dots-telemetry:
+--:(telemetry-setup) {dots-telemetry}? +-- (telemetry-message-type)?
| +--rw telemetry* [cuid tsid] +--:(telemetry-setup)
| ... | ...
+--:(telemetry) {dots-telemetry}? | +-- telemetry* []
+--rw pre-or-ongoing-mitigation* [cuid tmid] | +-- (direction)?
+--rw cuid string | | +--:(server-to-client-only)
+--rw cdid? string | | +-- tsid? uint32
+--rw tmid uint32 | +-- (setup-type)?
+--rw target | +--:(telemetry-config)
| ... | | ...
+--rw total-traffic* [unit] | +--:(pipe)
| ... | | ...
+--rw total-traffic-protocol* [unit protocol] | +--:(baseline)
| ... | ...
+--rw total-traffic-port* [unit port] +--:(telemetry)
| ... +-- pre-or-ongoing-mitigation* []
+--rw total-attack-traffic* [unit] +-- (direction)?
| ... | +--:(server-to-client-only)
+--rw total-attack-traffic-protocol* [unit protocol] | +-- tmid? uint32
| ... +-- target
+--rw total-attack-traffic-port* [unit port] | ...
| ... +-- total-traffic* [unit]
+--rw total-attack-connection | ...
| ... +-- total-traffic-protocol* [unit protocol]
+--rw total-attack-connection-port | ...
| ... +-- total-traffic-port* [unit port]
+--rw attack-detail* [vendor-id attack-id] | ...
... +-- total-attack-traffic* [unit]
| ...
+-- total-attack-traffic-protocol* [unit protocol]
| ...
+-- total-attack-traffic-port* [unit port]
| ...
+-- total-attack-connection
| ...
+-- total-attack-connection-port
| ...
+-- 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 7.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. DOTS telemetry attributes are optionally signaled and
therefore MUST NOT be treated as mandatory fields in the DOTS signal therefore MUST NOT be treated as mandatory fields in the DOTS signal
channel protocol. channel protocol.
7.1.1. Target 7.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) {dots-telemetry}? +--:(telemetry)
+--rw pre-or-ongoing-mitigation* [cuid tmid] +-- pre-or-ongoing-mitigation* []
+--rw cuid string +-- (direction)?
+--rw cdid? string | +--:(server-to-client-only)
+--rw tmid uint32 | +-- tmid? uint32
+--rw target +-- target
| +--rw target-prefix* inet:ip-prefix | +-- target-prefix* inet:ip-prefix
| +--rw target-port-range* [lower-port] | +-- target-port-range* [lower-port]
| | +--rw lower-port inet:port-number | | +-- lower-port inet:port-number
| | +--rw upper-port? inet:port-number | | +-- upper-port? inet:port-number
| +--rw target-protocol* uint8 | +-- target-protocol* uint8
| +--rw target-fqdn* inet:domain-name | +-- target-fqdn* inet:domain-name
| +--rw target-uri* inet:uri | +-- target-uri* inet:uri
| +--rw alias-name* string | +-- alias-name* string
| +--rw mid-list* uint32 | +-- mid-list* uint32
+--rw total-traffic* [unit] +-- total-traffic* [unit]
| ... | ...
+--rw total-traffic-protocol* [unit protocol] +-- total-traffic-protocol* [unit protocol]
| ... | ...
+--rw total-traffic-port* [unit port] +-- total-traffic-port* [unit port]
| ... | ...
+--rw total-attack-traffic* [unit] +-- total-attack-traffic* [unit]
| ... | ...
+--rw total-attack-traffic-protocol* [unit protocol] +-- total-attack-traffic-protocol* [unit protocol]
| ... | ...
+--rw total-attack-traffic-port* [unit port] +-- total-attack-traffic-port* [unit port]
| ... | ...
+--rw total-attack-connection +-- total-attack-connection
| ... | ...
+--rw total-attack-connection-port +-- total-attack-connection-port
| ... | ...
+--rw attack-detail* [vendor-id attack-id] +-- attack-detail* [vendor-id attack-id]
... ...
Figure 25: Target Tree Structure Figure 25: Target Tree Structure
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 subjected to bandwidth consuming attack, the If the target is subjected to bandwidth consuming attack, 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.
skipping to change at page 39, line 5 skipping to change at page 39, line 5
values of total traffic observed during a DDoS attack. More granular values of total traffic observed during a DDoS attack. More granular
total traffic can be conveyed in 'total-traffic-protocol' and 'total- total traffic can be conveyed in 'total-traffic-protocol' and 'total-
traffic-port'. traffic-port'.
The 'total-traffic-protocol' represents the total traffic for a The 'total-traffic-protocol' represents the total traffic for a
target and is transport-protocol specific. target and is transport-protocol specific.
The 'total-traffic-port' represents the total traffic for a target The 'total-traffic-port' represents the total traffic for a target
per port number. per port number.
+--:(telemetry) {dots-telemetry}? +--:(telemetry)
+--rw pre-or-ongoing-mitigation* [cuid tmid] +-- pre-or-ongoing-mitigation* []
+--rw cuid string +-- (direction)?
+--rw cdid? string | +--:(server-to-client-only)
+--rw tmid uint32 | +-- tmid? uint32
+--rw target +-- target
| ... | ...
+--rw total-traffic* [unit] +-- total-traffic* [unit]
| +--rw unit unit | +-- unit unit
| +--rw low-percentile-g? yang:gauge64 | +-- low-percentile-g? yang:gauge64
| +--rw mid-percentile-g? yang:gauge64 | +-- mid-percentile-g? yang:gauge64
| +--rw high-percentile-g? yang:gauge64 | +-- high-percentile-g? yang:gauge64
| +--rw peak-g? yang:gauge64 | +-- peak-g? yang:gauge64
+--rw total-traffic-protocol* [unit protocol] +-- total-traffic-protocol* [unit protocol]
| +--rw protocol uint8 | +-- protocol uint8
| +--rw unit unit | +-- unit unit
| +--rw low-percentile-g? yang:gauge64 | +-- low-percentile-g? yang:gauge64
| +--rw mid-percentile-g? yang:gauge64 | +-- mid-percentile-g? yang:gauge64
| +--rw high-percentile-g? yang:gauge64 | +-- high-percentile-g? yang:gauge64
| +--rw peak-g? yang:gauge64 | +-- peak-g? yang:gauge64
+--rw total-traffic-port* [unit port] +-- total-traffic-port* [unit port]
| +--rw port inet:port-number | +-- port inet:port-number
| +--rw unit unit | +-- unit unit
| +--rw low-percentile-g? yang:gauge64 | +-- low-percentile-g? yang:gauge64
| +--rw mid-percentile-g? yang:gauge64 | +-- mid-percentile-g? yang:gauge64
| +--rw high-percentile-g? yang:gauge64 | +-- high-percentile-g? yang:gauge64
| +--rw peak-g? yang:gauge64 | +-- peak-g? yang:gauge64
+--rw total-attack-traffic* [unit] +-- total-attack-traffic* [unit]
| ... | ...
+--rw total-attack-traffic-protocol* [unit protocol] +-- total-attack-traffic-protocol* [unit protocol]
| ... | ...
+--rw total-attack-traffic-port* [unit port] +-- total-attack-traffic-port* [unit port]
| ... | ...
+--rw total-attack-connection +-- total-attack-connection
| ... | ...
+--rw total-attack-connection-port +-- total-attack-connection-port
| ... | ...
+--rw 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 7.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
attack traffic identified by the DOTS client domain's DMS (or DDoS attack traffic identified by the DOTS client domain's DMS (or DDoS
Detector). More granular total traffic can be conveyed in 'total- Detector). More granular total traffic can be conveyed in 'total-
attack-traffic-protocol' and 'total-attack-traffic-port'. attack-traffic-protocol' and 'total-attack-traffic-port'.
The 'total-attack-traffic-protocol' represents the total attack The 'total-attack-traffic-protocol' represents the total attack
traffic for a target and is transport-protocol specific. traffic for a target and is transport-protocol specific.
The 'total-attack-traffic-port' represents the total attack traffic The 'total-attack-traffic-port' represents the total attack traffic
for a target per port number. for a target per port number.
+--:(telemetry) {dots-telemetry}? +--:(telemetry)
+--rw pre-or-ongoing-mitigation* [cuid tmid] +-- pre-or-ongoing-mitigation* []
+--rw cuid string +-- (direction)?
+--rw cdid? string | +--:(server-to-client-only)
+--rw tmid uint32 | +-- tmid? uint32
+--rw target +-- target
| ... | ...
+--rw total-traffic* [unit] +-- total-traffic* [unit]
| ... | ...
+--rw total-traffic-protocol* [unit protocol] +-- total-traffic-protocol* [unit protocol]
| ... | ...
+--rw total-traffic-port* [unit port] +-- total-traffic-port* [unit port]
| ... | ...
+--rw total-attack-traffic* [unit] +-- total-attack-traffic* [unit]
| +--rw unit unit | +-- protocol? uint8
| +--rw low-percentile-g? yang:gauge64 | +-- unit unit
| +--rw mid-percentile-g? yang:gauge64 | +-- low-percentile-g? yang:gauge64
| +--rw high-percentile-g? yang:gauge64 | +-- mid-percentile-g? yang:gauge64
| +--rw peak-g? yang:gauge64 | +-- high-percentile-g? yang:gauge64
+--rw total-attack-traffic-protocol* [unit protocol] | +-- peak-g? yang:gauge64
| +--rw protocol uint8 +-- total-attack-traffic-protocol* [unit protocol]
| +--rw unit unit | +-- protocol uint8
| +--rw low-percentile-g? yang:gauge64 | +-- unit unit
| +--rw mid-percentile-g? yang:gauge64 | +-- low-percentile-g? yang:gauge64
| +--rw high-percentile-g? yang:gauge64 | +-- mid-percentile-g? yang:gauge64
| +--rw peak-g? yang:gauge64 | +-- high-percentile-g? yang:gauge64
+--rw total-attack-traffic-port* [unit port] | +-- peak-g? yang:gauge64
| +--rw port inet:port-number +-- total-attack-traffic-port* [unit port]
| +--rw unit unit | +-- port inet:port-number
| +--rw low-percentile-g? yang:gauge64 | +-- unit unit
| +--rw mid-percentile-g? yang:gauge64 | +-- low-percentile-g? yang:gauge64
| +--rw high-percentile-g? yang:gauge64 | +-- mid-percentile-g? yang:gauge64
| +--rw peak-g? yang:gauge64 | +-- high-percentile-g? yang:gauge64
+--rw total-attack-connection | +-- peak-g? yang:gauge64
| ... +-- total-attack-connection
+--rw total-attack-connection-port | ...
| ... +-- total-attack-connection-port
+--rw 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 7.1.4. Total Attack Connections
If the target is subjected to resource consuming DDoS attack, the If the target is subjected to resource consuming DDoS attack, the
'total-attack-connection' attribute is used to convey the percentile 'total-attack-connection' attribute is used to convey the percentile
values of total attack connections. The following optional sub- values of total attack connections. The following optional sub-
attributes for the target per transport-protocol are included to attributes for the target per transport-protocol are included to
represent the attack characteristics: represent the attack characteristics:
o The number of simultaneous attack connections to the target. o The number of simultaneous attack connections to the target.
o The number of simultaneous embryonic connections to the target. o The number of simultaneous embryonic connections to the target.
o The number of attack connections per second to the target. o The number of attack connections per second to the target.
o The number of attack requests to the target. o The number of attack requests to the target.
The total attack connections per port number is represented using The total attack connections per port number is represented using
'total-attack-connection-port' attribute. 'total-attack-connection-port' attribute.
+--:(telemetry) {dots-telemetry}? +--:(telemetry)
+--rw pre-or-ongoing-mitigation* [cuid tmid] +-- pre-or-ongoing-mitigation* []
+--rw cuid string +-- (direction)?
+--rw cdid? string | +--:(server-to-client-only)
+--rw tmid uint32 | +-- tmid? uint32
+--rw target +-- target
| ... | ...
+--rw total-attack-connection +-- total-traffic* [unit]
| +--rw low-percentile-l* [protocol] | ...
| | +--rw protocol uint8 +-- total-traffic-protocol* [unit protocol]
| | +--rw connection? yang:gauge64 | ...
| | +--rw embryonic? yang:gauge64 +-- total-traffic-port* [unit port]
| | +--rw connection-ps? yang:gauge64 | ...
| | +--rw request-ps? yang:gauge64 +-- total-attack-traffic* [unit]
| | +--rw partial-request-ps? yang:gauge64 | ...
| +--rw mid-percentile-l* [protocol] +-- total-attack-traffic-protocol* [unit protocol]
| | +--rw protocol uint8 | ...
| | +--rw connection? yang:gauge64 +-- total-attack-traffic-port* [unit port]
| | +--rw embryonic? yang:gauge64 | ...
| | +--rw connection-ps? yang:gauge64 +-- total-attack-connection
| | +--rw request-ps? yang:gauge64 | +-- low-percentile-l* [protocol]
| | +--rw partial-request-ps? yang:gauge64 | | +-- protocol uint8
| +--rw high-percentile-l* [protocol] | | +-- connection? yang:gauge64
| | +--rw protocol uint8 | | +-- embryonic? yang:gauge64
| | +--rw connection? yang:gauge64 | | +-- connection-ps? yang:gauge64
| | +--rw embryonic? yang:gauge64 | | +-- request-ps? yang:gauge64
| | +--rw connection-ps? yang:gauge64 | | +-- partial-request-ps? yang:gauge64
| | +--rw request-ps? yang:gauge64 | +-- mid-percentile-l* [protocol]
| | +--rw partial-request-ps? yang:gauge64 | | +-- protocol uint8
| +--rw peak-l* [protocol] | | +-- connection? yang:gauge64
| +--rw protocol uint8 | | +-- embryonic? yang:gauge64
| +--rw connection? yang:gauge64 | | +-- connection-ps? yang:gauge64
| +--rw embryonic? yang:gauge64 | | +-- request-ps? yang:gauge64
| +--rw connection-ps? yang:gauge64 | | +-- partial-request-ps? yang:gauge64
| +--rw request-ps? yang:gauge64 | +-- high-percentile-l* [protocol]
| +--rw partial-request-ps? yang:gauge64 | | +-- protocol uint8
+--rw total-attack-connection-port | | +-- connection? yang:gauge64
| +--rw low-percentile-l* [protocol port] | | +-- embryonic? yang:gauge64
| | +--rw port inet:port-number | | +-- connection-ps? yang:gauge64
| | +--rw protocol uint8 | | +-- request-ps? yang:gauge64
| | +--rw connection? yang:gauge64 | | +-- partial-request-ps? yang:gauge64
| | +--rw embryonic? yang:gauge64 | +-- peak-l* [protocol]
| | +--rw connection-ps? yang:gauge64 | +-- protocol uint8
| | +--rw request-ps? yang:gauge64 | +-- connection? yang:gauge64
| | +--rw partial-request-ps? yang:gauge64 | +-- embryonic? yang:gauge64
| +--rw mid-percentile-l* [protocol port] | +-- connection-ps? yang:gauge64
| | +--rw port inet:port-number | +-- request-ps? yang:gauge64
| | +--rw protocol uint8 | +-- partial-request-ps? yang:gauge64
| | +--rw connection? yang:gauge64 +-- total-attack-connection-port
| | +--rw embryonic? yang:gauge64 | +-- low-percentile-l* [protocol port]
| | +--rw connection-ps? yang:gauge64 | | +-- port inet:port-number
| | +--rw request-ps? yang:gauge64 | | +-- protocol uint8
| | +--rw partial-request-ps? yang:gauge64 | | +-- connection? yang:gauge64
| +--rw high-percentile-l* [protocol port] | | +-- embryonic? yang:gauge64
| | +--rw port inet:port-number | | +-- connection-ps? yang:gauge64
| | +--rw protocol uint8 | | +-- request-ps? yang:gauge64
| | +--rw connection? yang:gauge64 | | +-- partial-request-ps? yang:gauge64
| | +--rw embryonic? yang:gauge64 | +-- mid-percentile-l* [protocol port]
| | +--rw connection-ps? yang:gauge64 | | +-- port inet:port-number
| | +--rw request-ps? yang:gauge64 | | +-- protocol uint8
| | +--rw partial-request-ps? yang:gauge64 | | +-- connection? yang:gauge64
| +--rw peak-l* [protocol port] | | +-- embryonic? yang:gauge64
| +--rw port inet:port-number | | +-- connection-ps? yang:gauge64
| +--rw protocol uint8 | | +-- request-ps? yang:gauge64
| +--rw connection? yang:gauge64 | | +-- partial-request-ps? yang:gauge64
| +--rw embryonic? yang:gauge64 | +-- high-percentile-l* [protocol port]
| +--rw connection-ps? yang:gauge64 | | +-- port inet:port-number
| +--rw request-ps? yang:gauge64 | | +-- protocol uint8
| +--rw partial-request-ps? yang:gauge64 | | +-- connection? yang:gauge64
+--rw attack-detail* [vendor-id attack-id] | | +-- embryonic? yang:gauge64
... | | +-- connection-ps? yang:gauge64
| | +-- request-ps? yang:gauge64
| | +-- partial-request-ps? yang:gauge64
| +-- peak-l* [protocol port]
| +-- port inet:port-number
| +-- protocol uint8
| +-- connection? yang:gauge64
| +-- embryonic? yang:gauge64
| +-- connection-ps? yang:gauge64
| +-- request-ps? yang:gauge64
| +-- partial-request-ps? yang:gauge64
+-- 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 7.1.5. Attack Details
This attribute (Figure 29) is used to signal a set of details This attribute (Figure 29) is used to signal a set of details
characterizing an attack. The following sub-attributes describing characterizing an attack. The following sub-attributes describing
the on-going attack can be signal as attack details. the on-going attack can be signal 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 with IANA [Enterprise-Numbers]. It is a four-byte
integer value. integer value.
attack-id: Unique identifier assigned for the attack. attack-id: Unique identifier assigned for the attack.
attack-name: Textual representation of the attack description. attack-description: Textual representation of the attack
Natural Language Processing techniques (e.g., word embedding) can description. Natural Language Processing techniques (e.g., word
possibly be used to map the attack description to an attack type. embedding) can possibly be used to map the attack description to
Textual representation of attack solves two problems: (a) avoids an attack type. Textual representation of attack solves two
the need to create mapping tables manually between vendors and (b) problems: (a) avoids the need to create mapping tables manually
avoids the need to standardize attack types which keep evolving. between vendors and (b) avoids the need to standardize attack
types which keep evolving.
attack-severity: Attack severity level. This attribute takes one of attack-severity: Attack severity level. This attribute takes one of
the values defined in Section 3.12.2 of [RFC7970]. the values defined in Section 3.12.2 of [RFC7970].
start-time: The time the attack started. The attack's start time is start-time: The time the attack started. The attack's start time is
expressed in seconds relative to 1970-01-01T00:00Z in UTC time expressed in seconds relative to 1970-01-01T00:00Z in UTC time
(Section 2.4.1 of [RFC7049]). The CBOR encoding is modified so (Section 2.4.1 of [RFC7049]). The CBOR encoding is modified so
that the leading tag 1 (epoch-based date/time) MUST be omitted. that the leading tag 1 (epoch-based date/time) MUST be omitted.
end-time: The time the attack ended. The attack end time is end-time: The time the attack ended. The attack end time is
skipping to change at page 44, line 5 skipping to change at page 45, line 9
address (e.g., reflection attacks) or not. address (e.g., reflection attacks) or not.
If the target is subjected to a bandwidth consuming attack, the If the target is subjected to a bandwidth consuming attack, the
attack traffic from each of the top talkers is included ('total- attack traffic from each of the top talkers is included ('total-
attack-traffic', Section 7.1.3). attack-traffic', Section 7.1.3).
If the target is subjected to a resource consuming DDoS attack, If the target is subjected to a resource consuming DDoS attack,
the same attributes defined in Section 7.1.4 are applicable for the same attributes defined in Section 7.1.4 are applicable for
representing the attack per talker. representing the attack per talker.
+--:(telemetry) {dots-telemetry}? +--:(telemetry)
+--rw pre-or-ongoing-mitigation* [cuid tmid] +-- pre-or-ongoing-mitigation* []
+--rw cuid string +-- (direction)?
+--rw cdid? string | +--:(server-to-client-only)
+--rw tmid uint32 | +-- tmid? uint32
+--rw target +-- target
| ... | ...
+--rw attack-detail* [vendor-id attack-id] +-- total-traffic* [unit]
+--rw vendor-id uint32 | ...
+--rw attack-id uint32 +-- total-traffic-protocol* [unit protocol]
+--rw attack-name? string | ...
+--rw attack-severity? attack-severity +-- total-traffic-port* [unit port]
+--rw start-time? uint64 | ...
+--rw end-time? uint64 +-- total-attack-traffic* [unit]
+--rw top-talker | ...
+--rw talker* [source-prefix] +-- total-attack-traffic-protocol* [unit protocol]
+--rw spoofed-status? boolean | ...
+--rw source-prefix inet:ip-prefix +-- total-attack-traffic-port* [unit port]
+--rw source-port-range* [lower-port] | ...
| +--rw lower-port inet:port-number +-- total-attack-connection
| +--rw upper-port? inet:port-number | ...
+--rw source-icmp-type-range* [lower-type] +-- total-attack-connection-port
| +--rw lower-type uint8 | ...
| +--rw upper-type? uint8 +-- attack-detail* [vendor-id attack-id]
+--rw total-attack-traffic* [unit] +-- vendor-id uint32
| +--rw unit unit +-- attack-id uint32
| +--rw low-percentile-g? yang:gauge64 +-- attack-description? string
| +--rw mid-percentile-g? yang:gauge64 +-- attack-severity? attack-severity
| +--rw high-percentile-g? yang:gauge64 +-- start-time? uint64
| +--rw peak-g? yang:gauge64 +-- end-time? uint64
+--rw total-attack-connection +-- source-count
+--rw low-percentile-l* [protocol] | +-- low-percentile-g? yang:gauge64
| ... | +-- mid-percentile-g? yang:gauge64
+--rw mid-percentile-l* [protocol] | +-- high-percentile-g? yang:gauge64
| ... | +-- peak-g? yang:gauge64
+--rw high-percentile-l* [protocol] +-- top-talker
| ... +-- talker* [source-prefix]
+--rw peak-l* [protocol] +-- spoofed-status? boolean
... +-- source-prefix inet:ip-prefix
+-- source-port-range* [lower-port]
| +-- lower-port inet:port-number
| +-- upper-port? inet:port-number
+-- source-icmp-type-range* [lower-type]
| +-- lower-type uint8
| +-- upper-type? uint8
+-- total-attack-traffic* [unit]
| +-- unit unit
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
+-- total-attack-connection
+-- low-percentile-l* [protocol]
| +-- protocol uint8
| +-- connection? yang:gauge64
| +-- embryonic? yang:gauge64
| +-- connection-ps? yang:gauge64
| +-- request-ps? yang:gauge64
| +-- partial-request-ps? yang:gauge64
+-- mid-percentile-l* [protocol]
| +-- protocol uint8
| +-- connection? yang:gauge64
| +-- embryonic? yang:gauge64
| +-- connection-ps? yang:gauge64
| +-- request-ps? yang:gauge64
| +-- partial-request-ps? yang:gauge64
+-- high-percentile-l* [protocol]
| +-- protocol uint8
| +-- connection? yang:gauge64
| +-- embryonic? yang:gauge64
| +-- connection-ps? yang:gauge64
| +-- request-ps? yang:gauge64
| +-- partial-request-ps? yang:gauge64
+-- peak-l* [protocol]
+-- protocol uint8
+-- connection? yang:gauge64
+-- embryonic? yang:gauge64
+-- connection-ps? yang:gauge64
+-- request-ps? yang:gauge64
+-- partial-request-ps? 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} ==> attack name). As is, {vendor identifier, attack identifier} ==> attack description).
such, DOTS agents do not have to convey systematically an attack name As such, DOTS agents do not have to convey systematically an attack
in their telemetry messages over the DOTS signal channel. The "ietf- description in their telemetry messages over the DOTS signal channel.
dots-mapping" YANG module defined in Section 9.2) augments the "ietf-
dots-data-channel". The tree structure of this module is shown in Multiple mappings for different vendor identifiers may be used; the
Figure 30. DOTS agent transmitting telemetry information can elect to use one or
more vendor mappings even in the same telemetry message.
Note: It is possible that a DOTS server is making use of multiple
DOTS mitigators; each from a different vendor. How telemetry
information and vendor mappings are exchanged between DOTS servers
and DOTS mitigators is outside the scope of this document.
DOTS clients and servers may be provided with mappings from different
vendors and so have their own different sets of vendor attack
mappings. A DOTS agent MUST accept receipt of telemetry data with a
vendor identifier that is different to the one it uses to transmit
telemetry data. Furthermore, it is possible that the DOTS client and
DOTS server are provided by the same vendor, but the vendor mapping
tables are at different revisions. The DOTS client SHOULD transmit
telemetry information using the vendor mapping(s) that it provided to
the DOTS server and the DOTS server SHOULD use the vendor mappings(s)
provided to the DOTS client when transmitting telemetry data to peer
DOTS agent.
The "ietf-dots-mapping" YANG module defined in Section 10.2 augments
the "ietf-dots-data-channel" [RFC8783]. The tree structure of this
module is shown in Figure 30.
module: ietf-dots-mapping module: ietf-dots-mapping
augment /ietf-data:dots-data/ietf-data:dots-client: augment /ietf-data:dots-data/ietf-data: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 last-updated uint64
+--rw attack-mapping* [attack-id] +--rw attack-mapping* [attack-id]
+--rw attack-id uint32 +--rw attack-id uint32
+--rw attack-name string +--rw attack-description string
augment /ietf-data:dots-data/ietf-data:capabilities: augment /ietf-data:dots-data/ietf-data:capabilities:
+--ro vendor-mapping-enabled? boolean {dots-telemetry}? +--ro vendor-mapping-enabled? boolean {dots-telemetry}?
augment /ietf-data:dots-data: augment /ietf-data:dots-data:
+--ro vendor-mapping {dots-telemetry}? +--ro vendor-mapping {dots-telemetry}?
+--ro vendor* [vendor-id] +--ro vendor* [vendor-id]
+--ro vendor-id uint32 +--ro vendor-id uint32
+--ro vendor-name? string
+--ro last-updated uint64
+--ro attack-mapping* [attack-id] +--ro attack-mapping* [attack-id]
+--ro attack-id uint32 +--ro attack-id uint32
+--ro attack-name string +--ro attack-description string
Figure 30: Vendor Attack Mapping Tree Structure Figure 30: Vendor Attack Mapping Tree Structure
A DOTS client sends a GET request to retrieve the capabilities A DOTS client sends a GET request to retrieve the capabilities
supported by a DOTS server as per Section 7.1 of [RFC8783]. This supported by a DOTS server as per Section 7.1 of [RFC8783]. This
request is meant to assess whether vendor attack mapping details request is meant to assess whether vendor attack mapping details
feature is supported by the server (i.e., check the value of 'vendor- feature is supported by the server (i.e., check the value of 'vendor-
mapping-enabled'). mapping-enabled').
If 'vendor-mapping-enabled' is set to 'true', A DOTS client MAY send If 'vendor-mapping-enabled' is set to 'true', A DOTS client MAY send
skipping to change at page 46, line 14 skipping to change at page 48, line 38
GET /restconf/data/ietf-dots-data-channel:dots-data\ GET /restconf/data/ietf-dots-data-channel:dots-data\
/ietf-dots-mapping:vendor-mapping?depth=3 HTTP/1.1 /ietf-dots-mapping:vendor-mapping?depth=3 HTTP/1.1
Host: example.com Host: example.com
Accept: application/yang-data+json Accept: application/yang-data+json
Figure 32: GET to Retrieve the Vendors List used by a DOTS Server Figure 32: GET to Retrieve the Vendors List used by a DOTS Server
{ {
"ietf-dots-mapping:vendor-mapping": { "ietf-dots-mapping:vendor-mapping": {
"ietf-dots-mapping:vendor": [ "vendor": [
{ {
"ietf-dots-mapping:vendor-id": 1234, "vendor-id": 1234,
"ietf-dots-mapping:attack-mapping": [] "vendor-name": "mitigator-s",
"last-updated": "1576856561",
"attack-mapping": []
} }
] ]
} }
} }
Figure 33: Response to a GET to Retrieve the Vendors List used by a Figure 33: Response to a GET to Retrieve the Vendors List used by a
DOTS Server DOTS Server
The DOTS client reiterates the above procedure regularly (e.g., once The DOTS client reiterates the above procedure regularly (e.g., once
a week) to update the DOTS server's vendor attack mapping details. a week) to update the DOTS server's vendor attack mapping details.
skipping to change at page 47, line 12 skipping to change at page 49, line 20
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 POST request is depicted in Figure 34. details. An example of such 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
{ {
"ietf-dots-mapping:vendor-mapping": { "ietf-dots-mapping:vendor-mapping": {
"ietf-dots-mapping:vendor": [ "vendor": [
{ {
"ietf-dots-mapping:vendor-id": 345, "vendor-id": 345,
"ietf-dots-mapping:attack-mapping": [ "vendor-name": "mitigator-c",
"last-updated": "1576812345",
"attack-mapping": [
{ {
"ietf-dots-mapping:attack-id": 1, "attack-id": 1,
"ietf-dots-mapping:attack-name": "attack-description":
"Include a description of this attack" "Include a description of this attack"
}, },
{ {
"ietf-dots-mapping:attack-id": 2, "attack-id": 2,
"ietf-dots-mapping:attack-name": "attack-description":
"Again, include a description of the attack" "Again, include a description of the attack"
} }
] ]
} }
] ]
} }
} }
Figure 34: POST to Install Vendor Attack Mapping Details Figure 34: POST to Install Vendor Attack Mapping Details
skipping to change at page 48, line 18 skipping to change at page 50, line 29
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 'attack-name' 7.2, 7.3, and 8), DOTS agents MUST NOT include 'attack-description'
attribute except if the corresponding attack mapping details were not attribute except if the corresponding attack mapping details were not
shared with the peer DOTS agent (e.g., a DOTS server detects a new shared with the peer DOTS agent.
attack type).
7.2. From DOTS Clients to DOTS Servers 7.2. From DOTS Clients to DOTS Servers
DOTS clients uses PUT request to signal pre-or-ongoing-mitigation DOTS clients uses PUT request to signal pre-or-ongoing-mitigation
telemetry to DOTS servers. An example of such request is shown in telemetry to DOTS servers. An example of such 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"
skipping to change at page 50, line 8 skipping to change at page 52, line 8
tmid: Telemetry Identifier is an identifier for the DOTS pre-or- tmid: Telemetry Identifier is an identifier for the DOTS pre-or-
ongoing-mitigation telemetry data represented as an integer. ongoing-mitigation telemetry data represented as an integer.
This identifier MUST be generated by DOTS clients. 'tmid' values This identifier MUST be generated by DOTS clients. 'tmid' values
MUST increase monotonically (when a new PUT is generated by a MUST increase monotonically (when a new PUT is generated by a
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 [RFC8782] MUST be The procedure specified in Section 4.4.1 of [RFC8782] MUST be
followed for 'tmid' rollover. followed for 'tmid' rollover.
This is a mandatory attribute. 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 'target' attribute and another pre-or-ongoing-mitigation At least 'target' attribute and another pre-or-ongoing-mitigation
attributes (Section 7.1) MUST be present in the PUT request. If only attributes (Section 7.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 7.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 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.
The DOTS server indicates the result of processing a PUT request The DOTS server indicates the result of processing a PUT request
using CoAP response codes. The response code 2.04 (Changed) is using CoAP Response Codes. In particular, the 2.04 (Changed)
returned if the DOTS server has accepted the pre-or-ongoing- Response Code is returned if the DOTS server has accepted the pre-or-
mitigation telemetry. The error response code 5.03 (Service ongoing-mitigation telemetry. The 5.03 (Service Unavailable)
Unavailable) is returned if the DOTS server has erred. 5.03 uses Max- Response Code is returned if the DOTS server has erred. 5.03 uses
Age option to indicate the number of seconds after which to retry. Max-Age option to indicate the number of seconds after which to
retry.
How long a DOTS server maintains a 'tmid' as active or logs the How long a DOTS server maintains a 'tmid' as active or logs the
enclosed telemetry information is implementation-specific. Note that enclosed telemetry information is implementation-specific. Note that
if a 'tmid' is still active, then logging details are updated by the if a 'tmid' is still active, then logging details are updated by the
DOTS server as a function of the updates received from the peer DOTS DOTS server as a function of the updates received from the peer DOTS
client. client.
A DOTS client that lost the state of its active 'tmids' or has to set A DOTS client that lost the state of its active 'tmids' or has to set
'tmid' back to zero (e.g., crash or restart) MUST send a GET request 'tmid' back to zero (e.g., crash or restart) MUST send a GET request
to the DOTS server to retrieve the list of active 'tmid'. The DOTS to the DOTS server to retrieve the list of active 'tmid'. The DOTS
skipping to change at page 51, line 44 skipping to change at page 54, line 4
number of pre-or-ongoing-mitigation requests per DOTS client domain. number of pre-or-ongoing-mitigation requests per DOTS client domain.
This request MUST be maintained active by the DOTS server until a This request MUST be maintained active by the DOTS server until a
delete request is received from the same DOTS client to clear this delete request is received from the same DOTS client to clear this
pre-or-ongoing-mitigation telemetry. pre-or-ongoing-mitigation telemetry.
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)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=123" Uri-Path: "tmid=567"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [ "pre-or-ongoing-mitigation": [
{ {
"target": { "target": {
"target-prefix": [ "target-prefix": [
"2001:db8::/32" "2001:db8::/32"
] ]
skipping to change at page 52, line 42 skipping to change at page 54, line 45
The DOTS client conveys the Observe Option set to '0' in the GET The DOTS client conveys the Observe Option set to '0' in the GET
request to receive asynchronous notifications carrying pre-or- request to receive asynchronous notifications carrying pre-or-
ongoing-mitigation telemetry data from the DOTS server. The GET ongoing-mitigation telemetry data from the DOTS server. The GET
request specifies a 'tmid' (Figure 40) or not (Figure 41). request specifies a 'tmid' (Figure 40) or not (Figure 41).
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=123" Uri-Path: "tmid=567"
Observe: 0 Observe: 0
Figure 40: GET to Subscribe to Telemetry Asynchronous Notifications Figure 40: GET to Subscribe to Telemetry Asynchronous Notifications
for a Specific 'tmid' for a Specific 'tmid'
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Observe: 0 Observe: 0
Figure 41: GET to Subscribe to Telemetry Asynchronous Notifications Figure 41: GET to Subscribe to Telemetry Asynchronous Notifications
for All 'tmids' for All 'tmids'
The DOTS client can filter out the asynchronous notifications from The DOTS client can filter out the asynchronous notifications from
the DOTS server by indicating one or more Uri-Query options in its the DOTS server by indicating one or more Uri-Query options in its
GET request. An Uri-Query option can include the following GET request. An Uri-Query option can include the following
parameters: 'target-prefix', 'target-port', 'target-protocol', parameters: 'target-prefix', 'target-port', 'target-protocol',
'target-fqdn', 'target-uri', 'alias-name', 'mid', and 'c' (content) 'target-fqdn', 'target-uri', 'alias-name', 'mid', and 'c' (content)
(Section 4.4). Furthermore: (Section 4.2.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
clauses are included in a message body. clauses are included in a message body.
If multiple values of a query parameter are to be included in a If multiple values of a query parameter are to be included in a
request, these values MUST be included in the same Uri-Query request, these values MUST be included in the same Uri-Query
option and separated by a "," character without any spaces. option and separated by a "," character without any spaces.
Range values (i.e., contiguous inclusive block) can be included Range values (i.e., contiguous inclusive block) can be included
skipping to change at page 55, line 9 skipping to change at page 57, line 9
The DOTS server will send asynchronous notifications to the DOTS The DOTS server will send asynchronous notifications to the DOTS
client when an attack event is detected following similar client when an attack event is detected following similar
considerations as in Section 4.4.2.1 of [RFC8782]. An example of a considerations as in Section 4.4.2.1 of [RFC8782]. An example of a
pre-or-ongoing-mitigation telemetry notification is shown in pre-or-ongoing-mitigation telemetry notification is shown in
Figure 43. Figure 43.
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [ "pre-or-ongoing-mitigation": [
{ {
"tmid": 123, "tmid": 567,
"target": { "target": {
"target-prefix": [ "target-prefix": [
"2001:db8::1/128" "2001:db8::1/128"
] ]
}, },
"target-protocol": [ "target-protocol": [
17 17
], ],
"total-attack-traffic": [ "total-attack-traffic": [
{ {
skipping to change at page 56, line 31 skipping to change at page 58, line 31
efficacy updates to the server (Section 5.3.4 of [RFC8782]). efficacy updates to the server (Section 5.3.4 of [RFC8782]).
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 Attack Details: The overall attack details as observed from the
DOTS client perspective during an active mitigation. See DOTS client perspective during an active mitigation. See
Section 7.1.5. Section 7.1.5.
The "ietf-dots-telemetry" YANG module augments the "mitigation-scope" The "ietf-dots-telemetry" YANG module (Section 10.1) augments the
type message defined in "ietf-dots-signal" so that these attributes "mitigation-scope" message type defined in "ietf-dots-signal"
can be signalled by a DOTS client in a mitigation efficacy update [I-D.boucadair-dots-rfc8782-yang-update] so that these attributes can
be signalled by a DOTS client in a mitigation efficacy update
(Figure 44). (Figure 44).
augment /ietf-signal:dots-signal/ietf-signal:message-type augment-structure /signal:dots-signal/signal:message-type
/ietf-signal:mitigation-scope/ietf-signal:scope: /signal:mitigation-scope/signal:scope:
+--rw total-attack-traffic* [unit] {dots-telemetry}? +-- total-attack-traffic* [unit]
| ... | +-- unit unit
+--rw attack-detail* [vendor-id attack-id] {dots-telemetry}? | +-- low-percentile-g? yang:gauge64
+--rw vendor-id uint32 | +-- mid-percentile-g? yang:gauge64
+--rw attack-id uint32 | +-- high-percentile-g? yang:gauge64
+--rw attack-name? string | +-- peak-g? yang:gauge64
+--rw attack-severity? attack-severity +-- attack-detail* [vendor-id attack-id]
+--rw start-time? uint64 +-- vendor-id uint32
+--rw end-time? uint64 +-- attack-id uint32
+--rw source-count +-- attack-description? string
| ... +-- attack-severity? attack-severity
+--rw top-talker +-- start-time? uint64
... +-- end-time? uint64
+-- source-count
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
+-- top-talker
+-- talker* [source-prefix]
+-- spoofed-status? boolean
+-- source-prefix inet:ip-prefix
+-- source-port-range* [lower-port]
| +-- lower-port inet:port-number
| +-- upper-port? inet:port-number
+-- source-icmp-type-range* [lower-type]
| +-- lower-type uint8
| +-- upper-type? uint8
+-- total-attack-traffic* [unit]
| +-- unit unit
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
+-- total-attack-connection
+-- low-percentile-c
| +-- connection? yang:gauge64
| +-- embryonic? yang:gauge64
| +-- connection-ps? yang:gauge64
| +-- request-ps? yang:gauge64
| +-- partial-request-ps? yang:gauge64
+-- mid-percentile-c
| ...
+-- high-percentile-c
| ...
+-- peak-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. telemetry setup session with the server in 'idle' time.
An example of an efficacy update with telemetry attributes is
depicted in Figure 45.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
If-Match: If-Match:
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"alias-name": [ "alias-name": [
"https1", "https1",
"https2" "https2"
], ],
"attack-status": "under-attack", "attack-status": "under-attack",
"ietf-dots-telemetry:total-attack-traffic": [ "ietf-dots-telemetry:total-attack-traffic": [
{ {
"ietf-dots-telemetry:unit": "megabit-ps", "unit": "megabit-ps",
"ietf-dots-telemetry:mid-percentile-g": "900" "mid-percentile-g": "900"
} }
] ]
} }
] ]
} }
} }
Figure 45: An Example of Mitigation Efficacy Update with Telemetry Figure 45: An Example of Mitigation Efficacy Update with Telemetry
Attributes Attributes
skipping to change at page 58, line 11 skipping to change at page 61, line 7
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 setup session with the DOTS server in 'idle' time and MUST telemetry setup session with the DOTS server in 'idle' time and MUST
set the 'server-originated-telemetry' attribute to 'true'. set 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 which 'server-originated- status updates sent to DOTS clients for which 'server-originated-
telemetry' attribute is set to 'false'. 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 to each relevant countermeasure. A list current operational status of relevant countermeasures. A list of
of attacks detected by each countermeasure MAY also be included. The attacks detected by each countermeasure MAY also be included. The
same attributes defined for Section 7.1.5 are applicable for same attributes defined in Section 7.1.5 are applicable for
describing the attacks detected and mitigated. describing the attacks detected and mitigated at the DOTS server
domain.
The "ietf-dots-telemetry" YANG module (Section 9.1) augments the The "ietf-dots-telemetry" YANG module (Section 10.1) augments the
"mitigation-scope" type message defined in "ietf-dots-signal" with "mitigation-scope" message type defined in "ietf-dots-signal"
telemetry data as depicted in following tree structure: [I-D.boucadair-dots-rfc8782-yang-update] with telemetry data as
depicted in the following tree structure:
augment /ietf-signal:dots-signal/ietf-signal:message-type augment-structure /signal:dots-signal/signal:message-type
/ietf-signal:mitigation-scope/ietf-signal:scope: /signal:mitigation-scope/signal:scope:
+--ro total-traffic* [unit] {dots-telemetry}? +-- (direction)?
| +--ro unit unit | +--:(server-to-client-only)
| +--ro low-percentile-g? yang:gauge64 | +-- total-traffic* [unit]
| +--ro mid-percentile-g? yang:gauge64 | | +-- unit unit
| +--ro high-percentile-g? yang:gauge64 | | +-- low-percentile-g? yang:gauge64
| +--ro peak-g? yang:gauge64 | | +-- mid-percentile-g? yang:gauge64
+--rw total-attack-traffic* [unit] {dots-telemetry}? | | +-- high-percentile-g? yang:gauge64
| +--rw unit unit | | +-- peak-g? yang:gauge64
| +--rw low-percentile-g? yang:gauge64 | +-- total-attack-connection
| +--rw mid-percentile-g? yang:gauge64 | +-- low-percentile-c
| +--rw high-percentile-g? yang:gauge64 | | +-- connection? yang:gauge64
| +--rw peak-g? yang:gauge64 | | +-- embryonic? yang:gauge64
+--ro total-attack-connection {dots-telemetry}? | | +-- connection-ps? yang:gauge64
| +--ro low-percentile-c | | +-- request-ps? yang:gauge64
| | +--ro connection? yang:gauge64 | | +-- partial-request-ps? yang:gauge64
| | +--ro embryonic? yang:gauge64 | +-- mid-percentile-c
| | +--ro connection-ps? yang:gauge64 | | ...
| | +--ro request-ps? yang:gauge64 | +-- high-percentile-c
| | +--ro partial-request-ps? yang:gauge64 | | ...
| +--ro mid-percentile-c | +-- peak-c
| | ... | ...
| +--ro high-percentile-c +-- total-attack-traffic* [unit]
| | ... | +-- unit unit
| +--ro peak-c | +-- low-percentile-g? yang:gauge64
| ... | +-- mid-percentile-g? yang:gauge64
+--rw attack-detail* [vendor-id attack-id] {dots-telemetry}? | +-- high-percentile-g? yang:gauge64
+--rw vendor-id uint32 | +-- peak-g? yang:gauge64
+--rw attack-id uint32 +-- attack-detail* [vendor-id attack-id]
+--rw attack-name? string +-- vendor-id uint32
+--rw attack-severity? attack-severity +-- attack-id uint32
+--rw start-time? uint64 +-- attack-description? string
+--rw end-time? uint64 +-- attack-severity? attack-severity
+--rw source-count +-- start-time? uint64
| +--rw low-percentile-g? yang:gauge64 +-- end-time? uint64
| +--rw mid-percentile-g? yang:gauge64 +-- source-count
| +--rw high-percentile-g? yang:gauge64 | +-- low-percentile-g? yang:gauge64
| +--rw peak-g? yang:gauge64 | +-- mid-percentile-g? yang:gauge64
+--rw top-talker | +-- high-percentile-g? yang:gauge64
+--rw talker* [source-prefix] | +-- peak-g? yang:gauge64
+--rw spoofed-status? boolean +-- top-talker
+--rw source-prefix inet:ip-prefix +-- talker* [source-prefix]
+--rw source-port-range* [lower-port] +-- spoofed-status? boolean
| +--rw lower-port inet:port-number +-- source-prefix inet:ip-prefix
| +--rw upper-port? inet:port-number +-- source-port-range* [lower-port]
+--rw source-icmp-type-range* [lower-type] | +-- lower-port inet:port-number
| +--rw lower-type uint8 | +-- upper-port? inet:port-number
| +--rw upper-type? uint8 +-- source-icmp-type-range* [lower-type]
+--rw total-attack-traffic* [unit] | +-- lower-type uint8
| +--rw unit unit | +-- upper-type? uint8
| +--rw low-percentile-g? yang:gauge64 +-- total-attack-traffic* [unit]
| +--rw mid-percentile-g? yang:gauge64 | +-- unit unit
| +--rw high-percentile-g? yang:gauge64 | +-- low-percentile-g? yang:gauge64
| +--rw peak-g? yang:gauge64 | +-- mid-percentile-g? yang:gauge64
+--rw total-attack-connection | +-- high-percentile-g? yang:gauge64
+--rw low-percentile-c | +-- peak-g? yang:gauge64
| +--rw connection? yang:gauge64 +-- total-attack-connection
| +--rw embryonic? yang:gauge64 +-- low-percentile-c
| +--rw connection-ps? yang:gauge64 | +-- connection? yang:gauge64
| +--rw request-ps? yang:gauge64 | +-- embryonic? yang:gauge64
| +--rw partial-request-ps? yang:gauge64 | +-- connection-ps? yang:gauge64
+--rw mid-percentile-c | +-- request-ps? yang:gauge64
| +-- partial-request-ps? yang:gauge64
+-- mid-percentile-c
| ... | ...
+--rw high-percentile-c +-- high-percentile-c
| ... | ...
+--rw peak-c +-- peak-c
... ...
Figure 46 shows an example of an asynchronous notification of attack Figure 46 shows an example of an asynchronous notification of attack
mitigation status from the DOTS server. This notification signals mitigation status from the DOTS server. This notification signals
both the mid-percentile value of processed attack traffic and the both the mid-percentile value of processed attack traffic and the
peak percentile value of unique sources involved in the attack. peak percentile value of unique sources involved in the attack.
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
skipping to change at page 60, line 23 skipping to change at page 63, line 23
"https2" "https2"
], ],
"lifetime": 1600, "lifetime": 1600,
"status": "attack-successfully-mitigated", "status": "attack-successfully-mitigated",
"bytes-dropped": "134334555", "bytes-dropped": "134334555",
"bps-dropped": "43344", "bps-dropped": "43344",
"pkts-dropped": "333334444", "pkts-dropped": "333334444",
"pps-dropped": "432432", "pps-dropped": "432432",
"ietf-dots-telemetry:total-attack-traffic": [ "ietf-dots-telemetry:total-attack-traffic": [
{ {
"ietf-dots-telemetry:unit": "megabit-ps", "unit": "megabit-ps",
"ietf-dots-telemetry:mid-percentile-g": "900" "mid-percentile-g": "900"
} }
], ],
"ietf-dots-telemetry::attack-detail": [ "ietf-dots-telemetry:attack-detail": [
{ {
"ietf-dots-telemetry:vendor-id": 1234, "vendor-id": 1234,
"ietf-dots-telemetry:attack-id": 77, "attack-id": 77,
"ietf-dots-telemetry:source-count": { "source-count": {
"ietf-dots-telemetry:peak-g": "10000" "peak-g": "10000"
} }
} }
] ]
} }
] ]
} }
} }
Figure 46: Response Body of a Mitigation Status With Telemetry Figure 46: 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.4). The 'target-uri', 'alias-name', and 'c' (content) (Section 4.2.4). The
considerations discussed in Section 7.3 MUST be followed to include considerations discussed in Section 7.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 name ('target-fqdn', 'target-uri'). wildcard name ('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 47. bound to the "http1" alias is shown in Figure 47.
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
skipping to change at page 61, line 22 skipping to change at page 64, line 22
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 47: GET Request to Receive Asynchronous Notifications Filtered Figure 47: GET Request to Receive Asynchronous Notifications Filtered
using Uri-Query 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. observe entry if this query overlaps with an existing one.
9. YANG Modules 9. Error Handling
9.1. DOTS Signal Channel Telemetry YANG Module This section is a summary of the Error Code responses that can be
returned by a DOTS server. These error responses MUST contain a CoAP
4.xx or 5.xx Response Code.
This module uses types defined in [RFC6991] and [RFC8345]. In general, there may be an additional plain text diagnostic payload
(Section 5.5.2 of [RFC8782]) to help troubleshooting in the body of
the response unless detailed otherwise.
<CODE BEGINS> file "ietf-dots-telemetry@2020-05-04.yang" Errors returned by a DOTS server can be broken into two categories,
module ietf-dots-telemetry { those associated with the CoAP protocol itself and those generated
yang-version 1.1; during the validation of the provided data by the DOTS server.
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry";
prefix dots-telemetry;
import ietf-dots-signal-channel { The following list of common CoAP errors that are implemented by DOTS
prefix ietf-signal; servers. This list is not exhaustive, other errors defined by CoAP
reference and associated RFCs may be applicable.
"RFC 8782: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification";
}
import ietf-dots-data-channel {
prefix ietf-data;
reference
"RFC 8783: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Data Channel Specification";
}
import ietf-yang-types {
prefix yang;
reference
"Section 3 of RFC 6991";
} o 4.00 (Bad Request) is returned by the DOTS server when the DOTS
import ietf-inet-types { client has sent a request that violates the DOTS protocol
prefix inet; [RFC8782].
reference
"Section 4 of RFC 6991";
}
import ietf-network-topology {
prefix nt;
reference
"Section 6.2 of RFC 8345: A YANG Data Model for Network
Topologies";
}
organization o 4.01 (Unauthorized) is returned by the DOTS server when the DOTS
"IETF DDoS Open Threat Signaling (DOTS) Working Group"; client is not authorized to access the DOTS server [RFC8782].
contact
"WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org>
Author: Mohamed Boucadair o 4.02 (Bad Option) is returned by the DOTS server when one or more
<mailto:mohamed.boucadair@orange.com> CoAP options are unknown or malformed by the CoAP protocol layer
[RFC7252].
Author: Konda, Tirumaleswar Reddy o 4.04 (Not Found) is returned by the DOTS server when the DOTS
<mailto:TirumaleswarReddy_Konda@McAfee.com>"; client is requesting a 'mid' or 'sid' that is not valid [RFC8782].
description
"This module contains YANG definitions for the signaling
of DOTS telemetry exchanged between a DOTS client and
a DOTS server, by means of the DOTS signal channel.
Copyright (c) 2020 IETF Trust and the persons identified as o 4.05 (Method Not Allowed) is returned by the DOTS server when the
authors of the code. All rights reserved. DOTS client is requesting a resource by a method (GET etc.) that
is not supported by the DOTS server [RFC8782] [RFC7252].
Redistribution and use in source and binary forms, with or o 4.08 (Request Entity Incomplete) is returned by the DOTS server if
without modification, is permitted pursuant to, and subject one or multiple blocks of a block transfer request is missing
to the license terms contained in, the Simplified BSD License [RFC7959].
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see o 4.09 (Conflict) is returned by the DOTS server if the DOTS server
the RFC itself for full legal notices."; detects that a request conflicts with a previous request. The
response body is formatted using "application/dots+cbor", and
contains the "conflict-clause" [RFC8782].
revision 2020-05-04 { o 4.13 (Request Entity Too Large) may be returned by the DOTS server
description during a block transfer request [RFC7959].
"Initial revision.";
reference
"RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry";
} o 4.15 (Unsupported Content-Format) is returned by the DOTS server
when the Content-Format used in the request is not formatted as
"application/dots+cbor" [RFC8782].
feature dots-telemetry { o 4.22 (Unprocessable Entity) is returned by the DOTS server when
description one or more session configuration parameters are not valid
"This feature indicates that the DOTS signal channel is able [RFC8782].
to convey DOTS telemetry data between DOTS clients and
servers.";
}
typedef attack-severity { o 5.03 (Service Unavailable) is returned by the DOTS server if the
type enumeration { DOTS server is unable to handle the request. An example is the
enum none { DOTS server needs to redirect the DOTS client to use an alternate
value 1; DOTS server. The response body is formatted using "application/
description dots+cbor", and contains how to handle the 5.03 code [RFC8782].
"No effect on the DOTS client domain.";
}
enum low {
value 2;
description
"Minimal effect on the DOTS client domain.";
}
enum medium {
value 3;
description
"A subset of DOTS client domain resources are
out of service.";
}
enum high {
value 4;
description
"The DOTS client domain is under extremly severe
conditions.";
}
enum unknown {
value 5;
description
"The impact of the attack is not known.";
}
}
description
"Enumeration for attack severity.";
reference
"RFC 7970: The Incident Object Description Exchange
Format Version 2";
}
typedef unit-type { o 5.08 (Hop Limit Reached) is returned by the DOTS server if there
type enumeration { is a data path loop through upstream DOTS gateways. The response
enum packet-ps { body is formatted using plain text and contains a list of servers
value 1; that are in the data path loop [RFC8768].
description
"Packets per second (pps).";
}
enum bit-ps {
value 2;
description
"Bits per Second (bit/s).";
}
enum byte-ps {
value 3;
description
"Bytes per second (Byte/s).";
}
}
description
"Enumeration to indicate which unit type is used.";
}
typedef unit { The following additional error cases apply for the telemetry
type enumeration { extension:
enum packet-ps {
value 1;
description
"Packets per second (pps).";
}
enum bit-ps {
value 2;
description
"Bits per Second (bps).";
}
enum byte-ps {
value 3;
description
"Bytes per second (Bps).";
}
enum kilopacket-ps {
value 4;
description
"Kilo packets per second (kpps).";
}
enum kilobit-ps {
value 5;
description
"Kilobits per second (kbps).";
}
enum kilobyte-ps {
value 6;
description
"Kilobytes per second (kBps).";
}
enum megapacket-ps {
value 7;
description
"Mega packets per second (Mpps).";
}
enum megabit-ps {
value 8;
description
"Megabits per second (Mbps).";
}
enum megabyte-ps {
value 9;
description
"Megabytes per second (MBps).";
}
enum gigapacket-ps {
value 10;
description
"Giga packets per second (Gpps).";
}
enum gigabit-ps {
value 11;
description
"Gigabits per second (Gbps).";
}
enum gigabyte-ps {
value 12;
description
"Gigabytes per second (GBps).";
}
enum terapacket-ps {
value 13;
description
"Tera packets per second (Tpps).";
}
enum terabit-ps {
value 14;
description
"Terabits per second (Tbps).";
}
enum terabyte-ps {
value 15;
description
"Terabytes per second (TBps).";
} o 4.00 (Bad Request) is returned by the DOTS server when the DOTS
} client has sent a request that violates the DOTS telemetry
description extension.
"Enumeration to indicate which unit is used.";
}
typedef interval { o 4.04 (Not Found) is returned by the DOTS server when the DOTS
type enumeration { client is requesting a 'tsid' or 'tmid' that is not valid.
enum hour {
value 1;
description
"Hour.";
}
enum day {
value 2;
description
"Day.";
}
enum week {
value 3;
description
"Week.";
}
enum month {
value 4;
description
"Month.";
}
}
description
"Enumeration to indicate the overall measurement period.";
}
typedef sample { o 4.00 (Bad Request) is returned by the DOTS server when the DOTS
type enumeration { client has sent a request with invalid query types (e.g., not
enum second { supported, malformed).
value 1;
description
" A one second measurement period.";
}
enum 5-seconds {
value 2;
description
"5 seconds measurement period.";
}
enum 30-seconds {
value 3;
description
"30 seconds measurement period.";
}
enum minute {
value 4;
description
"One minute measurement period.";
}
enum 5-minutes {
value 5;
description
"5 minutes measurement period.";
}
enum 10-minutes {
value 6;
description
"10 minutes measurement period.";
}
enum 30-minutes {
value 7;
description
"30 minutes measurement period.";
}
enum hour {
value 8;
description
"One hour measurement period.";
}
}
description
"Enumeration to indicate the measurement period.";
}
typedef percentile { o 4.04 (Not Found) is returned by the DOTS server when the DOTS
type decimal64 { client has sent a request with a target query that does not match
fraction-digits 2; the target of the enclosed 'mid' as maintained by the DOTS server.
}
description
"The nth percentile of a set of data is the
value at which n percent of the data is below it.";
}
typedef query-type { 10. YANG Modules
type enumeration {
enum target-prefix {
value 1;
description
"Query based on target prefix.";
}
enum target-port {
value 2;
description
"Query based on target port number.";
}
enum target-protocol {
value 3;
description
"Query based on target protocol.";
}
enum target-fqdn {
value 4;
description
"Query based on target FQDN.";
}
enum target-uri {
value 5;
description
"Query based on target URI.";
}
enum target-alias {
value 6;
description
"Query based on target alias.";
}
enum mid {
value 7;
description
"Query based on mitigation identifier (mid).";
}
enum source-prefix {
value 8;
description
"Query based on source prefix.";
}
enum source-port {
value 9;
description
"Query based on source port number.";
}
enum source-icmp-type {
value 10;
description
"Query based on ICMP type";
}
enum content {
value 11;
description
"Query based on 'c' Uri-Query option that is used
to control the selection of configuration
and non-configuration data nodes.";
reference
"Section 4.4.2 of RFC SSSS.";
}
}
description
"Enumeration support for query types that can be used
in a GET request to filter out data.";
}
grouping percentile-config { 10.1. DOTS Signal Channel Telemetry YANG Module
description
"Configuration of low, mid, and high percentile values.";
leaf measurement-interval {
type interval;
description
"Defines the period on which percentiles are computed.";
}
leaf measurement-sample {
type sample;
description
"Defines the time distribution for measuring
values that are used to compute percentiles.";
}
leaf low-percentile {
type percentile;
default "10.00";
description
"Low percentile. If set to '0', this means low-percentiles
are disabled.";
}
leaf mid-percentile {
type percentile;
must '. >= ../low-percentile' {
error-message
"The mid-percentile must be greater than
or equal to the low-percentile.";
}
default "50.00";
description
"Mid percentile. If set to the same value as low-percentiles,
this means mid-percentiles are disabled.";
}
leaf high-percentile {
type percentile;
must '. >= ../mid-percentile' {
error-message
"The high-percentile must be greater than
or equal to the mid-percentile.";
}
default "90.00";
description
"High percentile. If set to the same value as mid-percentiles,
this means high-percentiles are disabled.";
}
}
grouping percentile { This module uses types defined in [RFC6991] and [RFC8345].
description
"Generic grouping for percentile.";
leaf low-percentile-g {
type yang:gauge64;
description
"Low percentile value.";
}
leaf mid-percentile-g {
type yang:gauge64;
description
"Mid percentile value.";
}
leaf high-percentile-g {
type yang:gauge64;
description
"High percentile value.";
}
leaf peak-g {
type yang:gauge64;
description
"Peak value.";
}
}
grouping unit-config { <CODE BEGINS> file "ietf-dots-telemetry@2020-07-03.yang"
description module ietf-dots-telemetry {
"Generic grouping for unit configuration."; yang-version 1.1;
list unit-config { namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry";
key "unit"; prefix dots-telemetry;
description
"Controls which unit types are allowed when sharing
telemetry data.";
leaf unit {
type unit-type;
description
"Can be packet-ps, bit-ps, or byte-ps.";
} import ietf-dots-signal-channel {
leaf unit-status { prefix signal;
type boolean; reference
mandatory true; "RFC UUUU: A YANG Data Model for Distributed Denial-of-Service
description Open Threat Signaling (DOTS) Signal Channel";
"Enable/disable the use of the measurement unit type."; }
} import ietf-dots-data-channel {
} prefix ietf-data;
} reference
"RFC 8783: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Data Channel Specification";
}
import ietf-yang-types {
prefix yang;
reference
"Section 3 of RFC 6991";
}
import ietf-inet-types {
prefix inet;
reference
"Section 4 of RFC 6991";
}
import ietf-network-topology {
prefix nt;
reference
"Section 6.2 of RFC 8345: A YANG Data Model for Network
Topologies";
}
import ietf-yang-structure-ext {
prefix sx;
reference
"RFC 8791: YANG Data Structure Extensions";
}
grouping traffic-unit { organization
description "IETF DDoS Open Threat Signaling (DOTS) Working Group";
"Grouping of traffic as a function of the measurement unit."; contact
leaf unit { "WG Web: <https://datatracker.ietf.org/wg/dots/>
type unit; WG List: <mailto:dots@ietf.org>
description
"The traffic can be measured using unit types: packet-ps,
bit-ps, or byte-ps. DOTS agents auto-scale to the appropriate
units (e.g., megabit-ps, kilobit-ps).";
}
uses percentile;
}
grouping traffic-unit-protocol { Author: Mohamed Boucadair
description <mailto:mohamed.boucadair@orange.com>
"Grouping of traffic of a given transport protocol as
a function of the measurement unit.";
leaf protocol {
type uint8;
description
"The transport protocol.
Values are taken from the IANA Protocol Numbers registry:
<https://www.iana.org/assignments/protocol-numbers/>.
For example, this parameter contains 6 for TCP, Author: Konda, Tirumaleswar Reddy
17 for UDP, 33 for DCCP, or 132 for SCTP."; <mailto:TirumaleswarReddy_Konda@McAfee.com>";
} description
uses traffic-unit; "This module contains YANG definitions for the signaling
} of DOTS telemetry exchanged between a DOTS client and
a DOTS server, by means of the DOTS signal channel.
grouping traffic-unit-port { Copyright (c) 2020 IETF Trust and the persons identified as
description authors of the code. All rights reserved.
"Grouping of traffic bound to a port number as
a function of the measurement unit.";
leaf port {
type inet:port-number;
description
"Port number.";
} Redistribution and use in source and binary forms, with or
uses traffic-unit; without modification, is permitted pursuant to, and subject
} to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
grouping total-connection-capacity { This version of this YANG module is part of RFC XXXX; see
description the RFC itself for full legal notices.";
"Total Connections Capacity. These attributes are
useful to detect resource consuming DDoS attacks";
leaf connection {
type uint64;
description
"The maximum number of simultaneous connections that
are allowed to the target server.";
}
leaf connection-client {
type uint64;
description
"The maximum number of simultaneous connections that
are allowed to the target server per client.";
}
leaf embryonic {
type uint64;
description
"The maximum number of simultaneous embryonic connections
that are allowed to the target server. The term 'embryonic
connection' refers to a connection whose connection handshake
is not finished. Embryonic connection is only possible in
connection-oriented transport protocols like TCP or SCTP.";
}
leaf embryonic-client {
type uint64;
description
"The maximum number of simultaneous embryonic connections
that are allowed to the target server per client.";
}
leaf connection-ps {
type uint64;
description
"The maximum number of connections allowed per second
to the target server.";
}
leaf connection-client-ps {
type uint64;
description
"The maximum number of connections allowed per second
to the target server per client.";
}
leaf request-ps {
type uint64;
description
"The maximum number of requests allowed per second
to the target server.";
}
leaf request-client-ps {
type uint64;
description
"The maximum number of requests allowed per second
to the target server per client.";
}
leaf partial-request-ps {
type uint64;
description
"The maximum number of partial requests allowed per
second to the target server.";
}
leaf partial-request-client-ps {
type uint64;
description
"The maximum number of partial requests allowed per
second to the target server per client.";
}
}
grouping total-connection-capacity-protocol { revision 2020-07-03 {
description description
"Total Connections Capacity per protocol. These attributes are "Initial revision.";
useful to detect resource consuming DDoS attacks."; reference
leaf protocol { "RFC XXXX: Distributed Denial-of-Service Open Threat
type uint8; Signaling (DOTS) Telemetry";
description }
"The transport protocol.
Values are taken from the IANA Protocol Numbers registry:
<https://www.iana.org/assignments/protocol-numbers/>.";
}
uses total-connection-capacity;
}
grouping connection { typedef attack-severity {
description type enumeration {
"A set of attributes which represent the attack enum none {
characteristics"; value 1;
leaf connection { description
type yang:gauge64; "No effect on the DOTS client domain.";
description }
"The number of simultaneous attack connections to enum low {
the target server."; value 2;
description
"Minimal effect on the DOTS client domain.";
}
enum medium {
value 3;
description
"A subset of DOTS client domain resources are
out of service.";
}
enum high {
value 4;
description
"The DOTS client domain is under extremly severe
conditions.";
}
enum unknown {
value 5;
description
"The impact of the attack is not known.";
}
}
description
"Enumeration for attack severity.";
reference
"RFC 7970: The Incident Object Description Exchange
Format Version 2";
}
} typedef unit-type {
leaf embryonic { type enumeration {
type yang:gauge64; enum packet-ps {
description value 1;
"The number of simultaneous embryonic connections to description
the target server."; "Packets per second (pps).";
} }
leaf connection-ps { enum bit-ps {
type yang:gauge64; value 2;
description description
"The number of attack connections per second to "Bits per Second (bit/s).";
the target server."; }
} enum byte-ps {
leaf request-ps { value 3;
type yang:gauge64; description
description "Bytes per second (Byte/s).";
"The number of attack requests per second to
the target server.";
}
leaf partial-request-ps {
type yang:gauge64;
description
"The number of attack partial requests to
the target server.";
}
}
grouping connection-percentile { }
description }
"Total attack connections."; description
container low-percentile-c { "Enumeration to indicate which unit type is used.";
description }
"Low percentile of attack connections.";
uses connection;
}
container mid-percentile-c {
description
"Mid percentile of attack connections.";
uses connection;
}
container high-percentile-c {
description
"High percentile of attack connections.";
uses connection;
}
container peak-c {
description
"Peak attack connections.";
uses connection; typedef unit {
} type enumeration {
} enum packet-ps {
value 1;
description
"Packets per second (pps).";
}
enum bit-ps {
value 2;
description
"Bits per Second (bps).";
}
enum byte-ps {
value 3;
description
"Bytes per second (Bps).";
}
enum kilopacket-ps {
value 4;
description
"Kilo packets per second (kpps).";
}
enum kilobit-ps {
value 5;
description
"Kilobits per second (kbps).";
}
enum kilobyte-ps {
value 6;
description
"Kilobytes per second (kBps).";
}
enum megapacket-ps {
value 7;
description
"Mega packets per second (Mpps).";
}
enum megabit-ps {
value 8;
description
"Megabits per second (Mbps).";
}
enum megabyte-ps {
value 9;
description
"Megabytes per second (MBps).";
}
enum gigapacket-ps {
value 10;
description
"Giga packets per second (Gpps).";
}
enum gigabit-ps {
value 11;
description
"Gigabits per second (Gbps).";
}
enum gigabyte-ps {
value 12;
description
"Gigabytes per second (GBps).";
}
enum terapacket-ps {
value 13;
description
"Tera packets per second (Tpps).";
}
enum terabit-ps {
value 14;
description
"Terabits per second (Tbps).";
}
enum terabyte-ps {
value 15;
description
"Terabytes per second (TBps).";
}
}
description
"Enumeration to indicate which unit is used.";
}
grouping connection-protocol { typedef interval {
description type enumeration {
"Total attack connections."; enum hour {
leaf protocol { value 1;
type uint8; description
description "Hour.";
"The transport protocol. }
Values are taken from the IANA Protocol Numbers registry: enum day {
<https://www.iana.org/assignments/protocol-numbers/>."; value 2;
} description
uses connection; "Day.";
} }
enum week {
value 3;
description
"Week.";
}
enum month {
value 4;
description
"Month.";
}
}
description
"Enumeration to indicate the overall measurement period.";
}
grouping connection-port { typedef sample {
description type enumeration {
"Total attack connections per port number."; enum second {
leaf port { value 1;
type inet:port-number; description
description " A one second measurement period.";
"Port number."; }
} enum 5-seconds {
uses connection-protocol; value 2;
} description
"5 seconds measurement period.";
}
enum 30-seconds {
value 3;
description
"30 seconds measurement period.";
}
enum minute {
value 4;
description
"One minute measurement period.";
}
enum 5-minutes {
value 5;
description
"5 minutes measurement period.";
}
enum 10-minutes {
value 6;
description
"10 minutes measurement period.";
}
enum 30-minutes {
value 7;
description
"30 minutes measurement period.";
}
enum hour {
value 8;
description
"One hour measurement period.";
}
}
description
"Enumeration to indicate the measurement period.";
}
grouping connection-protocol-percentile { typedef percentile {
description type decimal64 {
"Total attack connections per protocol."; fraction-digits 2;
list low-percentile-l { }
key "protocol"; description
description "The nth percentile of a set of data is the
"Low percentile of attack connections per protocol."; value at which n percent of the data is below it.";
uses connection-protocol; }
}
list mid-percentile-l {
key "protocol";
description
"Mid percentile of attack connections per protocol.";
uses connection-protocol;
}
list high-percentile-l {
key "protocol";
description
"High percentile of attack connections per protocol.";
uses connection-protocol;
} typedef query-type {
list peak-l { type enumeration {
key "protocol"; enum target-prefix {
description value 1;
"Peak attack connections per protocol."; description
uses connection-protocol; "Query based on target prefix.";
} }
} enum target-port {
value 2;
description
"Query based on target port number.";
}
enum target-protocol {
value 3;
description
"Query based on target protocol.";
}
enum target-fqdn {
value 4;
description
"Query based on target FQDN.";
grouping connection-protocol-port-percentile { }
description enum target-uri {
"Total attack connections per port number."; value 5;
list low-percentile-l { description
key "protocol port"; "Query based on target URI.";
description }
"Low percentile of attack connections per port number."; enum target-alias {
uses connection-port; value 6;
} description
list mid-percentile-l { "Query based on target alias.";
key "protocol port"; }
description enum mid {
"Mid percentile of attack connections per port number."; value 7;
uses connection-port; description
} "Query based on mitigation identifier (mid).";
list high-percentile-l { }
key "protocol port"; enum source-prefix {
description value 8;
"High percentile of attack connections per port number."; description
uses connection-port; "Query based on source prefix.";
} }
list peak-l { enum source-port {
key "protocol port"; value 9;
description description
"Peak attack connections per port number."; "Query based on source port number.";
uses connection-port; }
} enum source-icmp-type {
} value 10;
description
"Query based on ICMP type";
}
enum content {
value 11;
description
"Query based on 'c' Uri-Query option that is used
to control the selection of configuration
and non-configuration data nodes.";
reference
"Section 4.4.2 of RFC 8782.";
}
}
description
"Enumeration support for query types that can be used
in a GET request to filter out data.";
}
grouping attack-detail { grouping percentile-config {
description description
"Various details that describe the on-going "Configuration of low, mid, and high percentile values.";
attacks that need to be mitigated by the DOTS server. leaf measurement-interval {
The attack details need to cover well-known and common attacks type interval;
(such as a SYN Flood) along with new emerging or vendor-specific description
attacks."; "Defines the period on which percentiles are computed.";
leaf vendor-id { }
type uint32; leaf measurement-sample {
description type sample;
"Vendor ID is a security vendor's Enterprise Number."; description
} "Defines the time distribution for measuring
leaf attack-id { values that are used to compute percentiles.";
type uint32; }
description leaf low-percentile {
"Unique identifier assigned by the vendor for the attack."; type percentile;
} default "10.00";
leaf attack-name { description
type string; "Low percentile. If set to '0', this means low-percentiles
description are disabled.";
"Textual representation of attack description. Natural Language }
Processing techniques (e.g., word embedding) can possibly be used leaf mid-percentile {
to map the attack description to an attack type."; type percentile;
} must '. >= ../low-percentile' {
leaf attack-severity { error-message
type attack-severity; "The mid-percentile must be greater than
description or equal to the low-percentile.";
"Severity level of an attack. How this level is determined }
is implementation-specific."; default "50.00";
} description
leaf start-time { "Mid percentile. If set to the same value as low-percentiles,
type uint64; this means mid-percentiles are disabled.";
description }
"The time the attack started. Start time is represented in seconds leaf high-percentile {
relative to 1970-01-01T00:00:00Z in UTC time."; type percentile;
} must '. >= ../mid-percentile' {
leaf end-time { error-message
type uint64; "The high-percentile must be greater than
description or equal to the mid-percentile.";
"The time the attack ended. End time is represented in seconds }
relative to 1970-01-01T00:00:00Z in UTC time."; default "90.00";
} description
container source-count { "High percentile. If set to the same value as mid-percentiles,
description this means high-percentiles are disabled.";
"Indicates the count of unique sources involved }
in the attack."; }
uses percentile;
}
}
grouping top-talker-aggregate { grouping percentile {
description description
"Top attack sources."; "Generic grouping for percentile.";
list talker {
key "source-prefix";
description
"IPv4 or IPv6 prefix identifying the attacker(s).";
leaf spoofed-status {
type boolean;
description
"Indicates whether this address is spoofed.";
}
leaf source-prefix {
type inet:ip-prefix;
description
"IPv4 or IPv6 prefix identifying the attacker(s).";
}
list source-port-range {
key "lower-port";
description
"Port range. When only lower-port is
present, it represents a single port number.";
leaf lower-port {
type inet:port-number;
mandatory true;
description
"Lower port number of the port range.";
}
leaf upper-port {
type inet:port-number;
must '. >= ../lower-port' {
error-message
"The upper port number must be greater than
or equal to lower port number.";
}
description
"Upper port number of the port range.";
}
}
list source-icmp-type-range {
key "lower-type";
description
"ICMP type range. When only lower-type is
present, it represents a single ICMP type.";
leaf lower-type {
type uint8;
mandatory true;
description
"Lower ICMP type of the ICMP type range.";
}
leaf upper-type {
type uint8;
must '. >= ../lower-type' {
error-message
"The upper ICMP type must be greater than
or equal to lower ICMP type.";
} leaf low-percentile-g {
description type yang:gauge64;
"Upper type of the ICMP type range."; description
} "Low percentile value.";
} }
list total-attack-traffic { leaf mid-percentile-g {
key "unit"; type yang:gauge64;
description description
"Total attack traffic issued from this source."; "Mid percentile value.";
uses traffic-unit; }
} leaf high-percentile-g {
container total-attack-connection { type yang:gauge64;
description description
"Total attack connections issued from this source."; "High percentile value.";
uses connection-percentile; }
} leaf peak-g {
} type yang:gauge64;
} description
"Peak value.";
}
}
grouping top-talker { grouping unit-config {
description description
"Top attack sources."; "Generic grouping for unit configuration.";
list talker { list unit-config {
key "source-prefix"; key "unit";
description description
"IPv4 or IPv6 prefix identifying the attacker(s)."; "Controls which unit types are allowed when sharing
leaf spoofed-status { telemetry data.";
type boolean; leaf unit {
description type unit-type;
"Indicates whether this address is spoofed."; description
} "Can be packet-ps, bit-ps, or byte-ps.";
leaf source-prefix { }
type inet:ip-prefix; leaf unit-status {
description type boolean;
"IPv4 or IPv6 prefix identifying the attacker(s)."; mandatory true;
} description
list source-port-range { "Enable/disable the use of the measurement unit type.";
key "lower-port"; }
description }
"Port range. When only lower-port is }
present, it represents a single port number.";
leaf lower-port {
type inet:port-number;
mandatory true;
description
"Lower port number of the port range.";
}
leaf upper-port {
type inet:port-number;
must '. >= ../lower-port' {
error-message
"The upper port number must be greater than
or equal to lower port number.";
}
description
"Upper port number of the port range.";
}
}
list source-icmp-type-range {
key "lower-type";
description
"ICMP type range. When only lower-type is
present, it represents a single ICMP type.";
leaf lower-type {
type uint8;
mandatory true;
description
"Lower ICMP type of the ICMP type range.";
}
leaf upper-type {
type uint8;
must '. >= ../lower-type' {
error-message
"The upper ICMP type must be greater than
or equal to lower ICMP type.";
}
description
"Upper type of the ICMP type range.";
}
}
list total-attack-traffic {
key "unit";
description
"Total attack traffic issued from this source.";
uses traffic-unit;
}
container total-attack-connection {
description
"Total attack connections issued from this source.";
uses connection-protocol-percentile;
}
}
}
grouping baseline { grouping traffic-unit {
description description
"Grouping for the telemetry baseline."; "Grouping of traffic as a function of the measurement unit.";
uses ietf-data:target; leaf unit {
leaf-list alias-name { type unit;
type string; description
description "The traffic can be measured using unit types: packet-ps,
"An alias name that points to a resource."; bit-ps, or byte-ps. DOTS agents auto-scale to the appropriate
} units (e.g., megabit-ps, kilobit-ps).";
list total-traffic-normal { }
key "unit"; uses percentile;
description }
"Total traffic normal baselines.";
uses traffic-unit;
}
list total-traffic-normal-per-protocol {
key "unit protocol";
description
"Total traffic normal baselines per protocol.";
uses traffic-unit-protocol;
}
list total-traffic-normal-per-port {
key "unit port";
description
"Total traffic normal baselines per port number.";
uses traffic-unit-port;
}
list total-connection-capacity {
key "protocol";
description
"Total connection capacity.";
uses total-connection-capacity-protocol;
}
list total-connection-capacity-per-port {
key "protocol port";
description
"Total connection capacity per port number.";
leaf port {
type inet:port-number;
description
"The target port number.";
}
uses total-connection-capacity-protocol;
}
}
grouping pre-or-ongoing-mitigation { grouping traffic-unit-protocol {
description description
"Grouping for the telemetry data."; "Grouping of traffic of a given transport protocol as
list total-traffic { a function of the measurement unit.";
key "unit"; leaf protocol {
description type uint8;
"Total traffic."; description
uses traffic-unit; "The transport protocol.
} Values are taken from the IANA Protocol Numbers registry:
list total-traffic-protocol { <https://www.iana.org/assignments/protocol-numbers/>.
key "unit protocol";
description
"Total traffic per protocol.";
uses traffic-unit-protocol;
}
list total-traffic-port {
key "unit port";
description
"Total traffic per port.";
uses traffic-unit-port;
}
list total-attack-traffic {
key "unit";
description
"Total attack traffic.";
uses traffic-unit-protocol;
}
list total-attack-traffic-protocol {
key "unit protocol";
description
"Total attack traffic per protocol.";
uses traffic-unit-protocol;
}
list total-attack-traffic-port {
key "unit port";
description
"Total attack traffic per port.";
uses traffic-unit-port;
}
container total-attack-connection {
description
"Total attack connections.";
uses connection-protocol-percentile;
}
container total-attack-connection-port {
description
"Total attack connections.";
uses connection-protocol-port-percentile;
}
list attack-detail {
key "vendor-id attack-id";
description
"Provides a set of attack details.";
uses attack-detail;
container top-talker {
description
"Lists the top attack sources.";
uses top-talker;
}
}
}
augment "/ietf-signal:dots-signal/ietf-signal:message-type/" For example, this parameter contains 6 for TCP,
+ "ietf-signal:mitigation-scope/ietf-signal:scope" { 17 for UDP, 33 for DCCP, or 132 for SCTP.";
if-feature "dots-telemetry"; }
description uses traffic-unit;
"Extends mitigation scope with telemetry update data."; }
list total-traffic {
key "unit";
config false;
description
"Total traffic.";
uses traffic-unit;
}
list total-attack-traffic {
key "unit";
description
"Total attack traffic.";
uses traffic-unit;
}
container total-attack-connection {
config false;
description
"Total attack connections.";
uses connection-percentile;
}
list attack-detail {
key "vendor-id attack-id";
description
"Atatck details";
uses attack-detail;
container top-talker {
description
"Top attack sources.";
uses top-talker-aggregate;
}
}
}
augment "/ietf-signal:dots-signal/ietf-signal:message-type" { grouping traffic-unit-port {
if-feature "dots-telemetry"; description
description "Grouping of traffic bound to a port number as
"Add a new choice to enclose telemetry data in DOTS a function of the measurement unit.";
signal channel."; leaf port {
case telemetry-setup { type inet:port-number;
description description
"Indicates the message is about telemetry."; "Port number.";
container max-config-values { }
config false; uses traffic-unit;
description }
"Maximum acceptable configuration values.";
uses percentile-config;
leaf server-originated-telemetry {
type boolean;
description
"Indicates whether the DOTS server can be instructed
to send pre-or-ongoing-mitigation telemetry. If set to FALSE
or the attribute is not present, this is an indication
that the server does not support this capability.";
}
leaf telemetry-notify-interval {
type uint32 {
range "1 .. 3600";
}
must '. >= ../../min-config-values/telemetry-notify-interval' {
error-message
"The value must be greater than or equal
to the telemetry-notify-interval in the min-config-values";
}
units "seconds";
description
"Minimum number of seconds between successive
telemetry notifications.";
}
}
container min-config-values {
config false;
description
"Minimum acceptable configuration values.";
uses percentile-config;
leaf telemetry-notify-interval {
type uint32 {
range "1 .. 3600";
}
units "seconds";
description
"Minimum number of seconds between successive
telemetry notifications.";
} grouping total-connection-capacity {
} description
container supported-units { "Total Connections Capacity. These data nodes are
config false; useful to detect resource consuming DDoS attacks";
description leaf connection {
"Supported units and default activation status."; type uint64;
uses unit-config; description
} "The maximum number of simultaneous connections that
leaf-list query-type { are allowed to the target server.";
type query-type; }
config false; leaf connection-client {
description type uint64;
"Indicates which query types are supported by description
the server."; "The maximum number of simultaneous connections that
} are allowed to the target server per client.";
list telemetry { }
key "cuid tsid"; leaf embryonic {
description type uint64;
"The telemetry data per DOTS client."; description
leaf cuid { "The maximum number of simultaneous embryonic connections
type string; that are allowed to the target server. The term 'embryonic
description connection' refers to a connection whose connection handshake
"A unique identifier that is is not finished. Embryonic connection is only possible in
generated by a DOTS client to prevent connection-oriented transport protocols like TCP or SCTP.";
request collisions. It is expected that the }
cuid will remain consistent throughout the leaf embryonic-client {
lifetime of the DOTS client."; type uint64;
} description
leaf cdid { "The maximum number of simultaneous embryonic connections
type string; that are allowed to the target server per client.";
description }
"The cdid should be included by a server-domain leaf connection-ps {
DOTS gateway to propagate the client domain type uint64;
identification information from the description
gateway's client-facing-side to the gateway's "The maximum number of connections allowed per second
server-facing-side, and from the gateway's to the target server.";
server-facing-side to the DOTS server. }
leaf connection-client-ps {
type uint64;
description
"The maximum number of connections allowed per second
to the target server per client.";
}
leaf request-ps {
type uint64;
description
"The maximum number of requests allowed per second
to the target server.";
}
leaf request-client-ps {
type uint64;
description
"The maximum number of requests allowed per second
to the target server per client.";
}
leaf partial-request-ps {
type uint64;
description
"The maximum number of partial requests allowed per
second to the target server.";
}
leaf partial-request-client-ps {
type uint64;
description
"The maximum number of partial requests allowed per
second to the target server per client.";
}
}
It may be used by the final DOTS server grouping total-connection-capacity-protocol {
for policy enforcement purposes."; description
} "Total Connections Capacity per protocol. These data nodes are
leaf tsid { useful to detect resource consuming DDoS attacks.";
type uint32; leaf protocol {
description type uint8;
"An identifier for the DOTS telemetry setup description
data."; "The transport protocol.
} Values are taken from the IANA Protocol Numbers registry:
choice setup-type { <https://www.iana.org/assignments/protocol-numbers/>.";
description }
"Can be a mitigation configuration, a pipe capacity, uses total-connection-capacity;
or baseline message."; }
case telemetry-config {
description
"Uses to set low, mid, and high percentile values.";
container current-config {
description
"Current configuration values.";
uses percentile-config;
uses unit-config;
leaf server-originated-telemetry {
type boolean;
description
"Used by a DOTS client to enable/disable whether it
accepts pre-or-ongoing-mitigation telemetry from
the DOTS server.";
}
leaf telemetry-notify-interval {
type uint32 {
range "1 .. 3600";
}
units "seconds";
description
"Minimum number of seconds between successive
telemetry notifications.";
}
}
}
case pipe {
description
"Total pipe capacity of a DOTS client domain";
list total-pipe-capacity {
key "link-id unit";
description
"Total pipe capacity of a DOTS client domain.";
leaf link-id {
type nt:link-id;
description
"Identifier of an interconnection link.";
}
leaf capacity {
type uint64;
mandatory true;
description
"Pipe capacity.";
}
leaf unit {
type unit;
description
"The traffic can be measured using unit types: packets
per second (PPS), Bits per Second (BPS), and/or
bytes per second. DOTS agents auto-scale to the
appropriate units (e.g., megabit-ps, kilobit-ps).";
}
}
}
case baseline {
description
"Traffic baseline information";
list baseline {
key "id";
description
"Traffic baseline information";
leaf id {
type uint32;
must '. >= 1';
description
"A baseline entry identifier.";
}
uses baseline;
}
}
}
}
}
case telemetry {
description
"Indicates the message is about telemetry.";
list pre-or-ongoing-mitigation {
key "cuid tmid";
description
"Pre-or-ongoing-mitigation telemetry per DOTS client.";
leaf cuid {
type string;
description
"A unique identifier that is
generated by a DOTS client to prevent
request collisions. It is expected that the
cuid will remain consistent throughout the
lifetime of the DOTS client.";
}
leaf cdid {
type string;
description
"The cdid should be included by a server-domain
DOTS gateway to propagate the client domain
identification information from the
gateway's client-facing-side to the gateway's
server-facing-side, and from the gateway's
server-facing-side to the DOTS server.
It may be used by the final DOTS server grouping connection {
for policy enforcement purposes."; description
} "A set of data nodes which represent the attack
leaf tmid { characteristics";
type uint32; leaf connection {
description type yang:gauge64;
"An identifier to uniquely demux telemetry data sent description
using the same message."; "The number of simultaneous attack connections to
} the target server.";
container target { }
description leaf embryonic {
"Indicates the target."; type yang:gauge64;
uses ietf-data:target; description
leaf-list alias-name { "The number of simultaneous embryonic connections to
type string; the target server.";
description }
"An alias name that points to a resource."; leaf connection-ps {
} type yang:gauge64;
leaf-list mid-list { description
type uint32; "The number of attack connections per second to
description the target server.";
"Reference a list of associated mitigation requests."; }
} leaf request-ps {
} type yang:gauge64;
uses pre-or-ongoing-mitigation; description
} "The number of attack requests per second to
} the target server.";
} }
} leaf partial-request-ps {
<CODE ENDS> type yang:gauge64;
description
"The number of attack partial requests to
the target server.";
}
}
9.2. Vendor Attack Mapping Details YANG Module grouping connection-percentile {
description
"Total attack connections.";
container low-percentile-c {
description
"Low percentile of attack connections.";
uses connection;
}
container mid-percentile-c {
description
"Mid percentile of attack connections.";
uses connection;
}
container high-percentile-c {
description
"High percentile of attack connections.";
uses connection;
}
container peak-c {
description
"Peak attack connections.";
uses connection;
}
}
<CODE BEGINS> file "ietf-dots-mapping@2020-05-04.yang" grouping connection-protocol {
module ietf-dots-mapping { description
yang-version 1.1; "Total attack connections.";
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-mapping"; leaf protocol {
prefix dots-mapping; type uint8;
description
"The transport protocol.
Values are taken from the IANA Protocol Numbers registry:
<https://www.iana.org/assignments/protocol-numbers/>.";
}
uses connection;
}
import ietf-dots-data-channel { grouping connection-port {
prefix ietf-data; description
reference "Total attack connections per port number.";
"RFC 8783: Distributed Denial-of-Service Open Threat leaf port {
Signaling (DOTS) Data Channel Specification"; type inet:port-number;
} description
"Port number.";
}
uses connection-protocol;
}
organization grouping connection-protocol-percentile {
"IETF DDoS Open Threat Signaling (DOTS) Working Group"; description
contact "Total attack connections per protocol.";
"WG Web: <https://datatracker.ietf.org/wg/dots/> list low-percentile-l {
WG List: <mailto:dots@ietf.org> key "protocol";
description
"Low percentile of attack connections per protocol.";
uses connection-protocol;
}
list mid-percentile-l {
key "protocol";
description
"Mid percentile of attack connections per protocol.";
uses connection-protocol;
}
list high-percentile-l {
key "protocol";
description
"High percentile of attack connections per protocol.";
uses connection-protocol;
}
list peak-l {
key "protocol";
description
"Peak attack connections per protocol.";
uses connection-protocol;
}
}
Author: Mohamed Boucadair grouping connection-protocol-port-percentile {
<mailto:mohamed.boucadair@orange.com> description
"Total attack connections per port number.";
list low-percentile-l {
key "protocol port";
description
"Low percentile of attack connections per port number.";
uses connection-port;
}
list mid-percentile-l {
key "protocol port";
description
"Mid percentile of attack connections per port number.";
uses connection-port;
}
list high-percentile-l {
key "protocol port";
description
"High percentile of attack connections per port number.";
uses connection-port;
}
list peak-l {
key "protocol port";
description
"Peak attack connections per port number.";
uses connection-port;
}
}
Author: Jon Shallow grouping attack-detail {
<mailto:supjps-ietf@jpshallow.com>"; description
description "Various details that describe the on-going
"This module contains YANG definitions for the sharing attacks that need to be mitigated by the DOTS server.
DDoS attack mapping details between a DOTS client and The attack details need to cover well-known and common attacks
a DOTS server, by means of the DOTS data channel. (such as a SYN Flood) along with new emerging or vendor-specific
attacks.";
leaf vendor-id {
type uint32;
description
"Vendor ID is a security vendor's Enterprise Number.";
}
leaf attack-id {
type uint32;
description
"Unique identifier assigned by the vendor for the attack.";
}
leaf attack-description {
type string;
description
"Textual representation of attack description. Natural Language
Processing techniques (e.g., word embedding) can possibly be
used to map the attack description to an attack type.";
}
leaf attack-severity {
type attack-severity;
description
"Severity level of an attack. How this level is determined
is implementation-specific.";
}
leaf start-time {
type uint64;
description
"The time the attack started. Start time is represented in
seconds relative to 1970-01-01T00:00:00Z in UTC time.";
}
leaf end-time {
type uint64;
description
"The time the attack ended. End time is represented in seconds
relative to 1970-01-01T00:00:00Z in UTC time.";
}
container source-count {
description
"Indicates the count of unique sources involved
in the attack.";
uses percentile;
}
}
Copyright (c) 2020 IETF Trust and the persons identified as grouping top-talker-aggregate {
authors of the code. All rights reserved. description
"Top attack sources.";
list talker {
key "source-prefix";
description
"IPv4 or IPv6 prefix identifying the attacker(s).";
leaf spoofed-status {
type boolean;
description
"Indicates whether this address is spoofed.";
}
leaf source-prefix {
type inet:ip-prefix;
description
"IPv4 or IPv6 prefix identifying the attacker(s).";
}
list source-port-range {
key "lower-port";
description
"Port range. When only lower-port is
present, it represents a single port number.";
Redistribution and use in source and binary forms, with or leaf lower-port {
without modification, is permitted pursuant to, and subject type inet:port-number;
to the license terms contained in, the Simplified BSD License mandatory true;
set forth in Section 4.c of the IETF Trust's Legal Provisions description
Relating to IETF Documents "Lower port number of the port range.";
(http://trustee.ietf.org/license-info). }
leaf upper-port {
type inet:port-number;
must '. >= ../lower-port' {
error-message
"The upper port number must be greater than
or equal to lower port number.";
}
description
"Upper port number of the port range.";
}
}
list source-icmp-type-range {
key "lower-type";
description
"ICMP type range. When only lower-type is
present, it represents a single ICMP type.";
leaf lower-type {
type uint8;
mandatory true;
description
"Lower ICMP type of the ICMP type range.";
}
leaf upper-type {
type uint8;
must '. >= ../lower-type' {
error-message
"The upper ICMP type must be greater than
or equal to lower ICMP type.";
}
description
"Upper type of the ICMP type range.";
}
}
list total-attack-traffic {
key "unit";
description
"Total attack traffic issued from this source.";
uses traffic-unit;
}
container total-attack-connection {
description
"Total attack connections issued from this source.";
This version of this YANG module is part of RFC XXXX; see uses connection-percentile;
the RFC itself for full legal notices."; }
}
}
revision 2020-05-04 { grouping top-talker {
description description
"Initial revision."; "Top attack sources.";
reference list talker {
"RFC XXXX: Distributed Denial-of-Service Open Threat key "source-prefix";
Signaling (DOTS) Telemetry"; description
} "IPv4 or IPv6 prefix identifying the attacker(s).";
leaf spoofed-status {
type boolean;
description
"Indicates whether this address is spoofed.";
}
leaf source-prefix {
type inet:ip-prefix;
description
"IPv4 or IPv6 prefix identifying the attacker(s).";
}
list source-port-range {
key "lower-port";
description
"Port range. When only lower-port is
present, it represents a single port number.";
leaf lower-port {
type inet:port-number;
mandatory true;
description
"Lower port number of the port range.";
}
leaf upper-port {
type inet:port-number;
must '. >= ../lower-port' {
error-message
"The upper port number must be greater than
or equal to lower port number.";
}
description
"Upper port number of the port range.";
}
}
list source-icmp-type-range {
key "lower-type";
description
"ICMP type range. When only lower-type is
present, it represents a single ICMP type.";
leaf lower-type {
type uint8;
mandatory true;
description
"Lower ICMP type of the ICMP type range.";
}
leaf upper-type {
type uint8;
must '. >= ../lower-type' {
error-message
"The upper ICMP type must be greater than
or equal to lower ICMP type.";
}
description
"Upper type of the ICMP type range.";
}
}
list total-attack-traffic {
key "unit";
description
"Total attack traffic issued from this source.";
uses traffic-unit;
}
container total-attack-connection {
description
"Total attack connections issued from this source.";
uses connection-protocol-percentile;
}
}
}
feature dots-telemetry { grouping baseline {
description description
"This feature indicates that DOTS telemetry data can be "Grouping for the telemetry baseline.";
shared between DOTS clients and servers."; uses ietf-data:target;
} leaf-list alias-name {
type string;
description
"An alias name that points to a resource.";
}
list total-traffic-normal {
key "unit";
description
"Total traffic normal baselines.";
uses traffic-unit;
}
list total-traffic-normal-per-protocol {
key "unit protocol";
description
"Total traffic normal baselines per protocol.";
uses traffic-unit-protocol;
}
list total-traffic-normal-per-port {
key "unit port";
description
"Total traffic normal baselines per port number.";
uses traffic-unit-port;
}
list total-connection-capacity {
key "protocol";
description
"Total connection capacity.";
uses total-connection-capacity-protocol;
}
list total-connection-capacity-per-port {
key "protocol port";
description
"Total connection capacity per port number.";
leaf port {
type inet:port-number;
description
"The target port number.";
}
uses total-connection-capacity-protocol;
}
}
grouping attack-mapping { grouping pre-or-ongoing-mitigation {
description description
"A set of information used for sharing vendor attack mapping "Grouping for the telemetry data.";
information with a peer."; list total-traffic {
list vendor { key "unit";
key "vendor-id"; description
description "Total traffic.";
"Vendor attack mapping information of the client/server"; uses traffic-unit;
leaf vendor-id { }
type uint32; list total-traffic-protocol {
description key "unit protocol";
"Vendor ID is a security vendor's Enterprise Number."; description
} "Total traffic per protocol.";
list attack-mapping { uses traffic-unit-protocol;
key "attack-id"; }
description list total-traffic-port {
"Attack mapping details."; key "unit port";
leaf attack-id { description
type uint32; "Total traffic per port.";
description uses traffic-unit-port;
"Unique identifier assigned by the vendor for the attack."; }
} list total-attack-traffic {
leaf attack-name { key "unit";
type string; description
mandatory true; "Total attack traffic.";
description uses traffic-unit-protocol;
"Textual representation of attack description. Natural Language }
Processing techniques (e.g., word embedding) can possibly be used list total-attack-traffic-protocol {
to map the attack description to an attack type."; key "unit protocol";
} description
} "Total attack traffic per protocol.";
} uses traffic-unit-protocol;
} }
list total-attack-traffic-port {
key "unit port";
description
"Total attack traffic per port.";
uses traffic-unit-port;
}
container total-attack-connection {
description
"Total attack connections.";
uses connection-protocol-percentile;
}
container total-attack-connection-port {
description
"Total attack connections.";
uses connection-protocol-port-percentile;
}
list attack-detail {
key "vendor-id attack-id";
description
"Provides a set of attack details.";
uses attack-detail;
container top-talker {
description
"Lists the top attack sources.";
uses top-talker;
}
}
}
augment "/ietf-data:dots-data/ietf-data:dots-client" { sx:augment-structure "/signal:dots-signal/signal:message-type/"
if-feature "dots-telemetry"; + "signal:mitigation-scope/signal:scope" {
container vendor-mapping { description
description "Extends mitigation scope with telemetry update data.";
"Clients use this feature to share their vendor
attack mapping information with DOTS servers.";
uses attack-mapping;
}
}
augment "/ietf-data:dots-data/ietf-data:capabilities" { choice direction {
if-feature "dots-telemetry"; description
leaf vendor-mapping-enabled { "Indicates the communication direction in which the
type boolean; data nodes can be included.";
config false; case server-to-client-only {
description description
"Indicates that the server supports sharing "These data nodes appear only in a mitigation message
attack vendor mapping details with DOTS clients."; sent from the server to the client.";
} list total-traffic {
} key "unit";
description
"Total traffic.";
uses traffic-unit;
}
container total-attack-connection {
description
"Total attack connections.";
uses connection-percentile;
}
}
}
list total-attack-traffic {
key "unit";
description
"Total attack traffic.";
uses traffic-unit;
}
list attack-detail {
key "vendor-id attack-id";
description
"Attack details";
uses attack-detail;
container top-talker {
description
"Top attack sources.";
uses top-talker-aggregate;
}
}
}
sx:structure dots-telemetry {
description
"Main structure for DOTS telemetry messages.";
choice telemetry-message-type {
description
"Can be a telemetry-setup or telemetry data.";
case telemetry-setup {
description
"Indicates the message is about telemetry.";
augment "/ietf-data:dots-data" { choice direction {
if-feature "dots-telemetry"; description
container vendor-mapping { "Indicates the communication direction in which the
config false; data nodes can be included.";
description case server-to-client-only {
"Includes the list of vendor attack mapping details description
that will be shared upon request with DOTS clients."; "These data nodes appear only in a mitigation message
uses attack-mapping; sent from the server to the client.";
} container max-config-values {
} description
} "Maximum acceptable configuration values.";
<CODE ENDS> uses percentile-config;
leaf server-originated-telemetry {
type boolean;
description
"Indicates whether the DOTS server can be instructed
to send pre-or-ongoing-mitigation telemetry. If set
to FALSE or the data node is not present, this is
an indication that the server does not support this
capability.";
}
leaf telemetry-notify-interval {
type uint32 {
range "1 .. 3600";
}
must ". >= ../../min-config-values"
+ "/telemetry-notify-interval" {
error-message
"The value must be greater than or equal
to the telemetry-notify-interval in the
min-config-values";
}
units "seconds";
description
"Minimum number of seconds between successive
telemetry notifications.";
}
}
container min-config-values {
description
"Minimum acceptable configuration values.";
uses percentile-config;
leaf telemetry-notify-interval {
type uint32 {
range "1 .. 3600";
}
units "seconds";
description
"Minimum number of seconds between successive
telemetry notifications.";
}
}
container supported-units {
description
"Supported units and default activation status.";
uses unit-config;
}
leaf-list query-type {
type query-type;
description
"Indicates which query types are supported by
the server.";
}
}
}
list telemetry {
description
"The telemetry data per DOTS client.";
choice direction {
description
"Indicates the communication direction in which the
data nodes can be included.";
case server-to-client-only {
description
"These data nodes appear only in a mitigation message
sent from the server to the client.";
leaf tsid {
type uint32;
description
"An identifier for the DOTS telemetry setup
data.";
}
}
}
choice setup-type {
description
"Can be a mitigation configuration, a pipe capacity,
or baseline message.";
case telemetry-config {
description
"Uses to set low, mid, and high percentile values.";
container current-config {
description
"Current configuration values.";
uses percentile-config;
uses unit-config;
leaf server-originated-telemetry {
type boolean;
description
"Used by a DOTS client to enable/disable whether it
accepts pre-or-ongoing-mitigation telemetry from
the DOTS server.";
}
leaf telemetry-notify-interval {
type uint32 {
range "1 .. 3600";
}
units "seconds";
description
"Minimum number of seconds between successive
telemetry notifications.";
}
}
}
case pipe {
description
"Total pipe capacity of a DOTS client domain";
list total-pipe-capacity {
key "link-id unit";
description
"Total pipe capacity of a DOTS client domain.";
leaf link-id {
type nt:link-id;
description
"Identifier of an interconnection link.";
}
leaf capacity {
type uint64;
mandatory true;
description
"Pipe capacity.";
}
leaf unit {
type unit;
description
"The traffic can be measured using unit types:
packets per second (PPS), Bits per Second (BPS),
and/or bytes per second. DOTS agents auto-scale
to the appropriate units (e.g., megabit-ps,
kilobit-ps).";
}
}
}
case baseline {
description
"Traffic baseline information";
list baseline {
key "id";
description
"Traffic baseline information";
leaf id {
type uint32;
must '. >= 1';
description
"A baseline entry identifier.";
}
uses baseline;
}
}
}
}
}
case telemetry {
description
"Indicates the message is about telemetry.";
list pre-or-ongoing-mitigation {
description
"Pre-or-ongoing-mitigation telemetry per DOTS client.";
choice direction {
description
"Indicates the communication direction in which the
data nodes can be included.";
case server-to-client-only {
description
"These data nodes appear only in a mitigation message
sent from the server to the client.";
leaf tmid {
type uint32;
description
"An identifier to uniquely demux telemetry data sent
using the same message.";
}
}
}
container target {
description
"Indicates the target.";
uses ietf-data:target;
leaf-list alias-name {
type string;
description
"An alias name that points to a resource.";
10. YANG/JSON Mapping Parameters to CBOR }
leaf-list mid-list {
type uint32;
description
"Reference a list of associated mitigation requests.";
}
}
uses pre-or-ongoing-mitigation;
}
}
}
}
}
<CODE ENDS>
10.2. Vendor Attack Mapping Details YANG Module
<CODE BEGINS> file "ietf-dots-mapping@2020-06-26.yang"
module ietf-dots-mapping {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-mapping";
prefix dots-mapping;
import ietf-dots-data-channel {
prefix ietf-data;
reference
"RFC 8783: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Data Channel Specification";
}
organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org>
Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>
Author: Jon Shallow
<mailto:supjps-ietf@jpshallow.com>";
description
"This module contains YANG definitions for the sharing
DDoS attack mapping details between a DOTS client and
a DOTS server, by means of the DOTS data channel.
Copyright (c) 2020 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2020-06-26 {
description
"Initial revision.";
reference
"RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry";
}
feature dots-telemetry {
description
"This feature indicates that DOTS telemetry data can be
shared between DOTS clients and servers.";
}
grouping attack-mapping {
description
"A set of information used for sharing vendor attack mapping
information with a peer.";
list vendor {
key "vendor-id";
description
"Vendor attack mapping information of the client/server";
leaf vendor-id {
type uint32;
description
"Vendor ID is a security vendor's Enterprise Number.";
}
leaf vendor-name {
type string;
description
"The name of the vendor (e.g., company A).";
}
leaf last-updated {
type uint64;
mandatory true;
description
"The time the mapping table was updated. It is represented
in seconds relative to 1970-01-01T00:00:00Z in UTC time.";
}
list attack-mapping {
key "attack-id";
description
"Attack mapping details.";
leaf attack-id {
type uint32;
description
"Unique identifier assigned by the vendor for the attack.";
}
leaf attack-description {
type string;
mandatory true;
description
"Textual representation of attack description. Natural
Language Processing techniques (e.g., word embedding)
can possibly be used to map the attack description to
an attack type.";
}
}
}
}
augment "/ietf-data:dots-data/ietf-data:dots-client" {
if-feature "dots-telemetry";
description
"Augments the data channel with a vendor attack
mapping table of the DOTS client.";
container vendor-mapping {
description
"Used by DOTS clients to share their vendor
attack mapping information with DOTS servers.";
uses attack-mapping;
}
}
augment "/ietf-data:dots-data/ietf-data:capabilities" {
if-feature "dots-telemetry";
description
"Augments the DOTS server capabilities with a
parameter to indicate whether they can share
attack mapping details.";
leaf vendor-mapping-enabled {
type boolean;
config false;
description
"Indicates that the server supports sharing
attack vendor mapping details with DOTS clients.";
}
}
augment "/ietf-data:dots-data" {
if-feature "dots-telemetry";
description
"Augments the data channel with a vendor attack
mapping table of the DOTS server.";
container vendor-mapping {
config false;
description
"Includes the list of vendor attack mapping details
that will be shared upon request with DOTS clients.";
uses attack-mapping;
}
}
}
<CODE ENDS>
11. 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 the following table: channel MUST be mapped to CBOR types as shown in the following table:
o Implementers may use the values in: https://github.com/boucadair/ o Implementers may use the values in: https://github.com/boucadair/
draft-dots-telemetry/blob/master/mapping-table.txt draft-dots-telemetry/blob/master/mapping-table.txt
+----------------------+-------------+------+---------------+--------+ +----------------------+-------------+------+---------------+--------+
| Parameter Name | YANG | CBOR | CBOR Major | JSON | | Parameter Name | YANG | CBOR | CBOR Major | JSON |
| | Type | Key | Type & | Type | | | Type | Key | Type & | Type |
| | | | Information | | | | | | Information | |
+======================+=============+======+===============+========+ +======================+=============+======+===============+========+
| tsid | uint32 |TBA1 | 0 unsigned | Number | | tsid | uint32 |TBA1 | 0 unsigned | Number |
| telemetry | container |TBA2 | 5 map | Object | | telemetry | container |TBA2 | 5 map | Object |
| low-percentile | decimal64 |TBA3 | 6 tag 4 | | | low-percentile | decimal64 |TBA3 | 6 tag 4 | |
| | | | [-2, integer]| String | | | | | [-2, integer]| String |
| mid-percentile | decimal64 |TBA4 | 6 tag 4 | | | mid-percentile | decimal64 |TBA4 | 6 tag 4 | |
| | | | [-2, integer]| String | | | | | [-2, integer]| String |
| high-percentile | decimal64 |TBA5 | 6 tag 4 | | | high-percentile | decimal64 |TBA5 | 6 tag 4 | |
| | | | [-2, integer]| String | | | | | [-2, integer]| String |
| unit-config | list |TBA6 | 4 array | Array | | unit-config | list |TBA6 | 4 array | Array |
| unit | enumeration |TBA7 | 0 unsigned | String | | unit | enumeration |TBA7 | 0 unsigned | String |
| unit-status | boolean |TBA8 | 7 bits 20 | False | | unit-status | boolean |TBA8 | 7 bits 20 | False |
| | | | 7 bits 21 | True | | | | | 7 bits 21 | True |
| total-pipe-capability| list |TBA9 | 4 array | Array | | total-pipe-capability| list |TBA9 | 4 array | Array |
| link-id | string |TBA10 | 3 text string | String | | link-id | string |TBA10 | 3 text string | String |
| pre-or-ongoing- | list |TBA11 | 4 array | Array | | pre-or-ongoing- | list |TBA11 | 4 array | Array |
| mitigation | | | | | | mitigation | | | | |
| total-traffic-normal | list |TBA12 | 4 array | Array | | total-traffic-normal | list |TBA12 | 4 array | Array |
| low-percentile-g | yang:gauge64|TBA13 | 0 unsigned | String | | low-percentile-g | yang:gauge64|TBA13 | 0 unsigned | String |
| mid-percentile-g | yang:gauge64|TBA14 | 0 unsigned | String | | mid-percentile-g | yang:gauge64|TBA14 | 0 unsigned | String |
| high-percentile-g | yang:gauge64|TBA15 | 0 unsigned | String | | high-percentile-g | yang:gauge64|TBA15 | 0 unsigned | String |
| peak-g | yang:gauge64|TBA16 | 0 unsigned | String | | peak-g | yang:gauge64|TBA16 | 0 unsigned | String |
| total-attack-traffic | list |TBA17 | 4 array | Array | | total-attack-traffic | list |TBA17 | 4 array | Array |
| total-traffic | list |TBA18 | 4 array | Array | | total-traffic | list |TBA18 | 4 array | Array |
| total-connection- | | | | | | total-connection- | | | | |
| capacity | list |TBA19 | 4 array | Array | | capacity | list |TBA19 | 4 array | Array |
| connection | uint64 |TBA20 | 0 unsigned | String | | connection | uint64 |TBA20 | 0 unsigned | String |
| connection-client | uint64 |TBA21 | 0 unsigned | String | | connection-client | uint64 |TBA21 | 0 unsigned | String |
| embryonic | uint64 |TBA22 | 0 unsigned | String | | embryonic | uint64 |TBA22 | 0 unsigned | String |
| embryonic-client | uint64 |TBA23 | 0 unsigned | String | | embryonic-client | uint64 |TBA23 | 0 unsigned | String |
| connection-ps | uint64 |TBA24 | 0 unsigned | String | | connection-ps | uint64 |TBA24 | 0 unsigned | String |
| connection-client-ps | uint64 |TBA25 | 0 unsigned | String | | connection-client-ps | uint64 |TBA25 | 0 unsigned | String |
| request-ps | uint64 |TBA26 | 0 unsigned | String | | request-ps | uint64 |TBA26 | 0 unsigned | String |
| request-client-ps | uint64 |TBA27 | 0 unsigned | String | | request-client-ps | uint64 |TBA27 | 0 unsigned | String |
| partial-request-ps | uint64 |TBA28 | 0 unsigned | String | | partial-request-ps | uint64 |TBA28 | 0 unsigned | String |
| partial-request- | | | | | | partial-request- | | | | |
| client-ps | uint64 |TBA29 | 0 unsigned | String | | client-ps | uint64 |TBA29 | 0 unsigned | String |
| total-attack- | | | | | | total-attack- | | | | |
| connection | container |TBA30 | 5 map | Object | | connection | container |TBA30 | 5 map | Object |
| low-percentile-l | list |TBA31 | 4 array | Array | | low-percentile-l | list |TBA31 | 4 array | Array |
| mid-percentile-l | list |TBA32 | 4 array | Array | | mid-percentile-l | list |TBA32 | 4 array | Array |
| high-percentile-l | list |TBA33 | 4 array | Array | | high-percentile-l | list |TBA33 | 4 array | Array |
| peak-l | list |TBA34 | 4 array | Array | | peak-l | list |TBA34 | 4 array | Array |
| attack-detail | list |TBA35 | 4 array | Array | | attack-detail | list |TBA35 | 4 array | Array |
| id | uint32 |TBA36 | 0 unsigned | Number | | id | uint32 |TBA36 | 0 unsigned | Number |
| attack-id | uint32 |TBA37 | 0 unsigned | Number | | attack-id | uint32 |TBA37 | 0 unsigned | Number |
| attack-name | string |TBA38 | 3 text string | String | | attack-description | string |TBA38 | 3 text string | String |
| attack-severity | enumeration |TBA39 | 0 unsigned | String | | attack-severity | enumeration |TBA39 | 0 unsigned | String |
| start-time | uint64 |TBA40 | 0 unsigned | String | | start-time | uint64 |TBA40 | 0 unsigned | String |
| end-time | uint64 |TBA41 | 0 unsigned | String | | end-time | uint64 |TBA41 | 0 unsigned | String |
| source-count | container |TBA42 | 5 map | Object | | source-count | container |TBA42 | 5 map | Object |
| top-talker | container |TBA43 | 5 map | Object | | top-talker | container |TBA43 | 5 map | Object |
| spoofed-status | boolean |TBA44 | 7 bits 20 | False | | spoofed-status | boolean |TBA44 | 7 bits 20 | False |
| | | | 7 bits 21 | True | | | | | 7 bits 21 | True |
| low-percentile-c | container |TBA45 | 5 map | Object | | low-percentile-c | container |TBA45 | 5 map | Object |
| mid-percentile-c | container |TBA46 | 5 map | Object | | mid-percentile-c | container |TBA46 | 5 map | Object |
| high-percentile-c | container |TBA47 | 5 map | Object | | high-percentile-c | container |TBA47 | 5 map | Object |
| peak-c | container |TBA48 | 5 map | Object | | peak-c | container |TBA48 | 5 map | Object |
| baseline | container |TBA49 | 5 map | Object | | baseline | container |TBA49 | 5 map | Object |
| current-config | container |TBA50 | 5 map | Object | | current-config | container |TBA50 | 5 map | Object |
| max-config-values | container |TBA51 | 5 map | Object | | max-config-values | container |TBA51 | 5 map | Object |
| min-config-values | container |TBA52 | 5 map | Object | | min-config-values | container |TBA52 | 5 map | Object |
| supported-units | container |TBA53 | 5 map | Object | | supported-units | container |TBA53 | 5 map | Object |
| server-originated- | boolean |TBA54 | 7 bits 20 | False | | server-originated- | boolean |TBA54 | 7 bits 20 | False |
| telemetry | | | 7 bits 21 | True | | telemetry | | | 7 bits 21 | True |
| telemetry-notify- | uint32 |TBA55 | 0 unsigned | Number | | telemetry-notify- | uint32 |TBA55 | 0 unsigned | Number |
| interval | | | | | | interval | | | | |
| tmid | uint32 |TBA56 | 0 unsigned | Number | | tmid | uint32 |TBA56 | 0 unsigned | Number |
| measurement-interval | enumeration |TBA57 | 0 unsigned | String | | measurement-interval | enumeration |TBA57 | 0 unsigned | String |
| measurement-sample | enumeration |TBA58 | 0 unsigned | String | | measurement-sample | enumeration |TBA58 | 0 unsigned | String |
| talker | list |TBA59 | 4 array | Array | | talker | list |TBA59 | 4 array | Array |
| source-prefix | inet: |TBA60 | 3 text string | String | | source-prefix | inet: |TBA60 | 3 text string | String |
| | ip-prefix | | | | | | ip-prefix | | | |
| mid-list | leaf-list |TBA61 | 4 array | Array | | mid-list | leaf-list |TBA61 | 4 array | Array |
| | uint32 | | 0 unsigned | Number | | | uint32 | | 0 unsigned | Number |
| source-port-range | list |TBA62 | 4 array | Array | | source-port-range | list |TBA62 | 4 array | Array |
| source-icmp-type- | list |TBA63 | 4 array | Array | | source-icmp-type- | list |TBA63 | 4 array | Array |
| range | | | | | | range | | | | |
| lower-type | uint8 |TBA64 | 0 unsigned | Number | | lower-type | uint8 |TBA64 | 0 unsigned | Number |
| upper-type | uint8 |TBA65 | 0 unsigned | Number | | upper-type | uint8 |TBA65 | 0 unsigned | Number |
| target | container |TBA66 | 5 map | Object | | target | container |TBA66 | 5 map | Object |
| capacity | uint64 |TBA67 | 0 unsigned | String | | capacity | uint64 |TBA67 | 0 unsigned | String |
| protocol | uint8 |TBA68 | 0 unsigned | Number | | protocol | uint8 |TBA68 | 0 unsigned | Number |
| total-traffic- | | | | | | total-traffic- | | | | |
| normal-per-protocol | list |TBA69 | 4 array | Array | | normal-per-protocol | list |TBA69 | 4 array | Array |
| total-traffic- | | | | | | total-traffic- | | | | |
| normal-per-port | list |TBA70 | 4 array | Array | | normal-per-port | list |TBA70 | 4 array | Array |
| total-connection- | | | | | | total-connection- | | | | |
| capacity-per-port | list |TBA71 | 4 array | Array | | capacity-per-port | list |TBA71 | 4 array | Array |
| total-traffic- | | | | | | total-traffic- | | | | |
| -protocol | list |TBA72 | 4 array | Array | | -protocol | list |TBA72 | 4 array | Array |
| total-traffic- port | list |TBA73 | 4 array | Array | | total-traffic- port | list |TBA73 | 4 array | Array |
| total-attack- | | | | | | total-attack- | | | | |
| traffic-protocol | list |TBA74 | 4 array | Array | | traffic-protocol | list |TBA74 | 4 array | Array |
| total-attack- | | | | | | total-attack- | | | | |
| traffic-port | list |TBA75 | 4 array | Array | | traffic-port | list |TBA75 | 4 array | Array |
| total-attack- | | | | | | total-attack- | | | | |
| connection-port | list |TBA76 | 4 array | Array | | connection-port | list |TBA76 | 4 array | Array |
| port | inet: | | | | | port | inet: | | | |
| | port-number|TBA77 | 0 unsigned | Number | | | port-number|TBA77 | 0 unsigned | Number |
| query-type | leaf-list |TBA78 | 4 array | Array | | query-type | leaf-list |TBA78 | 4 array | Array |
| | | | 0 unsigned | String | | | | | 0 unsigned | String |
| vendor-id | uint32 |TBA79 | 0 unsigned | Number | | vendor-id | uint32 |TBA79 | 0 unsigned | Number |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| telemetry-setup | container |TBA80 | 5 map | Object | | telemetry-setup | container |TBA80 | 5 map | Object |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| total-traffic | list |TBA81 | 4 array | Array | | total-traffic | list |TBA81 | 4 array | Array |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| unit | enumeration |TBA82 | 0 unsigned | String | | total-attack-traffic | list |TBA82 | 4 array | Array |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| low-percentile-g | yang:gauge64|TBA83 | 0 unsigned | String | | total-attack- | | | | |
| ietf-dots-telemetry: | | | | | | connection | container |TBA83 | 5 map | Object |
| mid-percentile-g | yang:gauge64|TBA84 | 0 unsigned | String | | ietf-dots-telemetry: | | | | |
| ietf-dots-telemetry: | | | | | | attack-detail | list |TBA84 | 4 array | Array |
| high-percentile-g | yang:gauge64|TBA85 | 0 unsigned | String | +----------------------+-------------+------+---------------+--------+
| ietf-dots-telemetry: | | | | |
| peak-g | yang:gauge64|TBA86 | 0 unsigned | String |
| ietf-dots-telemetry: | | | | |
| total-attack-traffic | list |TBA87 | 4 array | Array |
| ietf-dots-telemetry: | | | | |
| total-attack- | | | | |
| connection | container |TBA88 | 5 map | Object |
| ietf-dots-telemetry: | | | | |
| low-percentile-c | container |TBA89 | 5 map | Object |
| ietf-dots-telemetry: | | | | |
| mid-percentile-c | container |TBA90 | 5 map | Object |
| ietf-dots-telemetry: | | | | |
| high-percentile-c | container |TBA91 | 5 map | Object |
| ietf-dots-telemetry: | | | | |
| peak-c | container |TBA92 | 5 map | Object |
| ietf-dots-telemetry: | | | | |
| connection | uint64 |TBA93 | 0 unsigned | String |
| ietf-dots-telemetry: | | | | |
| embryonic | uint64 |TBA94 | 0 unsigned | String |
| ietf-dots-telemetry: | | | | |
| connection-ps | uint64 |TBA95 | 0 unsigned | String |
| ietf-dots-telemetry: | | | | |
| request-ps | uint64 |TBA96 | 0 unsigned | String |
| ietf-dots-telemetry: | | | | |
| partial-request-ps | uint64 |TBA97 | 0 unsigned | String |
| ietf-dots-telemetry: | | | | |
| attack-detail | list |TBA98 | 4 array | Array |
| ietf-dots-telemetry: | | | | |
| id | uint32 |TBA99 | 0 unsigned | Number |
| ietf-dots-telemetry: | | | | |
| attack-id | uint32 |TBA100| 0 unsigned | Number |
| ietf-dots-telemetry: | | | | |
| attack-name | string |TBA101| 3 text string | String |
| ietf-dots-telemetry: | | | | |
| attack-severity | enumeration |TBA102| 0 unsigned | String |
| ietf-dots-telemetry: | | | | |
| start-time | uint64 |TBA103| 0 unsigned | String |
| ietf-dots-telemetry: | | | | |
| end-time | uint64 |TBA104| 0 unsigned | String |
| ietf-dots-telemetry: | | | | |
| source-count | container |TBA105| 5 map | Object |
| ietf-dots-telemetry: | | | | |
| top-talker | container |TBA106| 5 map | Object |
| ietf-dots-telemetry: | | | | |
| spoofed-status | boolean |TBA107| 7 bits 20 | False |
| | | | 7 bits 21 | True |
| ietf-dots-telemetry: | | | | |
| talker | list |TBA108| 4 array | Array |
| ietf-dots-telemetry: | inet: |TBA109| 3 text string | String |
| source-prefix | ip-prefix | | | |
| ietf-dots-telemetry: | | | | |
| source-port-range | list |TBA110| 4 array | Array |
| ietf-dots-telemetry: | | | | |
| lower-port | inet: | | | |
| | port-number|TBA111| 0 unsigned | Number |
| ietf-dots-telemetry: | | | | |
| upper-port | inet: | | | |
| | port-number|TBA112| 0 unsigned | Number |
| ietf-dots-telemetry: | | | | |
| source-icmp-type- | list |TBA113| 4 array | Array |
| range | | | | |
| ietf-dots-telemetry: | | | | |
| lower-type | uint8 |TBA114| 0 unsigned | Number |
| ietf-dots-telemetry: | | | | |
| upper-type | uint8 |TBA115| 0 unsigned | Number |
| ietf-dots-telemetry: | | | | |
| telemetry | container |TBA116| 5 map | Object |
| ietf-dots-telemetry: | | | | |
| vendor-id | uint32 |TBA117| 0 unsigned | Number |
+----------------------+-------------+------+---------------+--------+
11. IANA Considerationsr 12. IANA Considerations
11.1. DOTS Signal Channel CBOR Key Values 12.1. A New Range for Comprehension-optional Parameters
This specification requests IANA to update the allocation policy of
"DOTS Signal Channel CBOR Key Values" registry [Key-Map] as follows:
OLD:
+-------------+-------------------------+------------------------+
| Range | Registration Procedures | Note |
+=============+=========================+========================+
| 1-16383 | IETF Review | comprehension-required |
| 16384-32767 | Specification Required | comprehension-optional |
| 32768-49151 | IETF Review | comprehension-optional |
| 49152-65535 | Private Use | comprehension-optional |
+-------------+-------------------------+------------------------+
NEW:
+-------------+-------------------------+------------------------+
| Range | Registration Procedures | Note |
+=============+=========================+========================+
| 1-127 | IETF Review | comprehension-required |
| 128-255 | IETF Review | comprehension-optional |
| 256-16383 | IETF Review | comprehension-required |
| 16384-32767 | Specification Required | comprehension-optional |
| 32768-49151 | IETF Review | comprehension-optional |
| 49152-65535 | Private Use | comprehension-optional |
+-------------+-------------------------+------------------------+
12.2. 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 available at IANA "DOTS Signal Channel CBOR Key Values" registry [Key-Map].
https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel-
cbor-key-values.
The DOTS telemetry attributes defined in this specification are The DOTS telemetry attributes defined in this specification are
comprehension-optional parameters. comprehension-optional parameters.
o Note to the RFC Editor: CBOR keys are assigned from the o Note to the RFC Editor: CBOR keys are assigned from the 128-255
32768-49151 range. range (Section 12.1).
+----------------------+-------+-------+------------+---------------+ +----------------------+-------+-------+------------+---------------+
| 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 | 5 | IESG | [RFCXXXX] | | telemetry | TBA2 | 5 | 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 96, line 42 skipping to change at page 100, line 45
| client-ps | | | | | | client-ps | | | | |
| total-attack- | TBA30 | 5 | IESG | [RFCXXXX] | | total-attack- | TBA30 | 5 | IESG | [RFCXXXX] |
| connection | | | | | | connection | | | | |
| low-percentile-l | TBA31 | 4 | IESG | [RFCXXXX] | | low-percentile-l | TBA31 | 4 | IESG | [RFCXXXX] |
| mid-percentile-l | TBA32 | 4 | IESG | [RFCXXXX] | | mid-percentile-l | TBA32 | 4 | IESG | [RFCXXXX] |
| high-percentile-l | TBA33 | 4 | IESG | [RFCXXXX] | | high-percentile-l | TBA33 | 4 | IESG | [RFCXXXX] |
| peak-l | TBA34 | 4 | IESG | [RFCXXXX] | | peak-l | TBA34 | 4 | IESG | [RFCXXXX] |
| attack-detail | TBA35 | 4 | IESG | [RFCXXXX] | | attack-detail | TBA35 | 4 | IESG | [RFCXXXX] |
| id | TBA36 | 0 | IESG | [RFCXXXX] | | id | TBA36 | 0 | IESG | [RFCXXXX] |
| attack-id | TBA37 | 0 | IESG | [RFCXXXX] | | attack-id | TBA37 | 0 | IESG | [RFCXXXX] |
| attack-name | TBA38 | 3 | IESG | [RFCXXXX] | | attack-description | TBA38 | 3 | IESG | [RFCXXXX] |
| attack-severity | TBA39 | 0 | IESG | [RFCXXXX] | | attack-severity | TBA39 | 0 | IESG | [RFCXXXX] |
| start-time | TBA40 | 0 | IESG | [RFCXXXX] | | start-time | TBA40 | 0 | IESG | [RFCXXXX] |
| end-time | TBA41 | 0 | IESG | [RFCXXXX] | | end-time | TBA41 | 0 | IESG | [RFCXXXX] |
| source-count | TBA42 | 5 | IESG | [RFCXXXX] | | source-count | TBA42 | 5 | IESG | [RFCXXXX] |
| top-talker | TBA43 | 5 | IESG | [RFCXXXX] | | top-talker | TBA43 | 5 | IESG | [RFCXXXX] |
| spoofed-status | TBA44 | 7 | IESG | [RFCXXXX] | | spoofed-status | TBA44 | 7 | IESG | [RFCXXXX] |
| low-percentile-c | TBA45 | 5 | IESG | [RFCXXXX] | | low-percentile-c | TBA45 | 5 | IESG | [RFCXXXX] |
| mid-percentile-c | TBA46 | 5 | IESG | [RFCXXXX] | | mid-percentile-c | TBA46 | 5 | IESG | [RFCXXXX] |
| high-percentile-c | TBA47 | 5 | IESG | [RFCXXXX] | | high-percentile-c | TBA47 | 5 | IESG | [RFCXXXX] |
| peak-c | TBA48 | 5 | IESG | [RFCXXXX] | | peak-c | TBA48 | 5 | IESG | [RFCXXXX] |
skipping to change at page 97, line 51 skipping to change at page 102, line 6
| total-attack- | TBA76 | 4 | IESG | [RFCXXXX] | | total-attack- | TBA76 | 4 | IESG | [RFCXXXX] |
| connection-port | | | | | | connection-port | | | | |
| port | TBA77 | 0 | IESG | [RFCXXXX] | | port | TBA77 | 0 | IESG | [RFCXXXX] |
| query-type | TBA78 | 4 | IESG | [RFCXXXX] | | query-type | TBA78 | 4 | IESG | [RFCXXXX] |
| vendor-id | TBA79 | 0 | IESG | [RFCXXXX] | | vendor-id | TBA79 | 0 | IESG | [RFCXXXX] |
| ietf-dots-telemetry: | TBA80 | 5 | IESG | [RFCXXXX] | | ietf-dots-telemetry: | TBA80 | 5 | IESG | [RFCXXXX] |
| telemetry-setup | | | | | | telemetry-setup | | | | |
| ietf-dots-telemetry: | TBA81 | 0 | IESG | [RFCXXXX] | | ietf-dots-telemetry: | TBA81 | 0 | IESG | [RFCXXXX] |
| total-traffic | | | | | | total-traffic | | | | |
| ietf-dots-telemetry: | TBA82 | 0 | IESG | [RFCXXXX] | | ietf-dots-telemetry: | TBA82 | 0 | IESG | [RFCXXXX] |
| unit | | | | |
| ietf-dots-telemetry: | TBA83 | 0 | IESG | [RFCXXXX] |
| low-percentile-g | | | | |
| ietf-dots-telemetry: | TBA84 | 0 | IESG | [RFCXXXX] |
| mid-percentile-g | | | | |
| ietf-dots-telemetry: | TBA85 | 0 | IESG | [RFCXXXX] |
| high-percentile-g | | | | |
| ietf-dots-telemetry: | TBA86 | 0 | IESG | [RFCXXXX] |
| peak-g | | | | |
| ietf-dots-telemetry: | TBA87 | 0 | IESG | [RFCXXXX] |
| total-attack-traffic | | | | | | total-attack-traffic | | | | |
| ietf-dots-telemetry: | TBA88 | 0 | IESG | [RFCXXXX] | | ietf-dots-telemetry: | TBA83 | 0 | IESG | [RFCXXXX] |
| total-attack- | | | | | | total-attack- | | | | |
| connection | | | | | | connection | | | | |
| ietf-dots-telemetry: | TBA89 | 0 | IESG | [RFCXXXX] | | ietf-dots-telemetry: | TBA84 | 4 | IESG | [RFCXXXX] |
| low-percentile-c | | | | |
| ietf-dots-telemetry: | TBA90 | 0 | IESG | [RFCXXXX] |
| mid-percentile-c | | | | |
| ietf-dots-telemetry: | TBA91 | 0 | IESG | [RFCXXXX] |
| high-percentile-c | | | | |
| ietf-dots-telemetry: | TBA92 | 0 | IESG | [RFCXXXX] |
| peak-c | | | | |
| ietf-dots-telemetry: | TBA93 | 0 | IESG | [RFCXXXX] |
| connection | | | | |
| ietf-dots-telemetry: | TBA94 | 0 | IESG | [RFCXXXX] |
| embryonic | | | | |
| ietf-dots-telemetry: | TBA95 | 0 | IESG | [RFCXXXX] |
| connection-ps | | | | |
| ietf-dots-telemetry: | TBA96 | 0 | IESG | [RFCXXXX] |
| request-ps | | | | |
| ietf-dots-telemetry: | TBA97 | 0 | IESG | [RFCXXXX] |
| partial-request-ps | | | | |
| ietf-dots-telemetry: | TBA98 | 4 | IESG | [RFCXXXX] |
| attack-detail | | | | | | attack-detail | | | | |
| ietf-dots-telemetry: | TBA99 | 0 | IESG | [RFCXXXX] |
| id | | | | |
| ietf-dots-telemetry: | TBA100| 0 | IESG | [RFCXXXX] |
| attack-id | | | | |
| ietf-dots-telemetry: | TBA101| 0 | IESG | [RFCXXXX] |
| attack-name | | | | |
| ietf-dots-telemetry: | TBA102| 0 | IESG | [RFCXXXX] |
| attack-severity | | | | |
| ietf-dots-telemetry: | TBA103| 0 | IESG | [RFCXXXX] |
| start-time | | | | |
| ietf-dots-telemetry: | TBA104| 0 | IESG | [RFCXXXX] |
| end-time | | | | |
| ietf-dots-telemetry: | TBA105| 0 | IESG | [RFCXXXX] |
| source-count | | | | |
| ietf-dots-telemetry: | TBA106| 0 | IESG | [RFCXXXX] |
| top-talker | | | | |
| ietf-dots-telemetry: | TBA107| 0 | IESG | [RFCXXXX] |
| spoofed-status | | | | |
| ietf-dots-telemetry: | TBA108| 0 | IESG | [RFCXXXX] |
| talker | | | | |
| ietf-dots-telemetry: | TBA109| 0 | IESG | [RFCXXXX] |
| source-prefix | | | | |
| ietf-dots-telemetry: | | | | |
| source-port-range | TBA110| 4 | IESG | [RFCXXXX] |
| ietf-dots-telemetry: | | | | |
| lower-port | TBA111| 0 | IESG | [RFCXXXX] |
| ietf-dots-telemetry: | | | | |
| upper-port | TBA112| 0 | IESG | [RFCXXXX] |
| ietf-dots-telemetry: | | | | |
| source-icmp-type- | TBA113| 4 | IESG | [RFCXXXX] |
| range | | | | |
| ietf-dots-telemetry: | | | | |
| lower-type | TBA114| 0 | IESG | [RFCXXXX] |
| ietf-dots-telemetry: | | | | |
| upper-type | TBA115| 0 | IESG | [RFCXXXX] |
| ietf-dots-telemetry: | TBA116| 5 | IESG | [RFCXXXX] |
| telemetry | | | | |
| ietf-dots-telemetry: | TBA117| 0 | IESG | [RFCXXXX] |
| vendor-id | | | | |
+----------------------+-------+-------+------------+---------------+ +----------------------+-------+-------+------------+---------------+
11.2. DOTS Signal Channel Conflict Cause Codes 12.3. 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 available at Signal Channel Conflict Cause Codes" registry [Cause].
https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel-
conflict-cause-codes.
+------+-------------------+------------------------+-------------+ +------+-------------------+------------------------+-------------+
| Code | Label | Description | Reference | | Code | Label | Description | Reference |
+======+===================+========================+=============+ +======+===================+========================+=============+
| TBA | overlapping-pipes | Overlapping pipe scope | [RFCXXXX] | | TBA | overlapping-pipes | Overlapping pipe scope | [RFCXXXX] |
+------+-------------------+------------------------+-------------+ +------+-------------------+------------------------+-------------+
11.3. DOTS Signal Telemetry YANG Module 12.4. 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 100, line 29 skipping to change at page 103, line 17
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
12. Security Considerations 13. Security Considerations
12.1. DOTS Signal Channel Telemetry 13.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 10 of [RFC8782]. The following discusses the discussed in Section 10 of [RFC8782]. 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 101, line 30 skipping to change at page 104, line 19
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 (identified by 'tmid') from the DOTS client. telemetry data (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.
12.2. Vendor Attack Mapping 13.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 9.2 All data nodes defined in the YANG module specified in Section 10.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:
o Communicating invalid attack mapping details to the server o Communicating invalid attack mapping details to the server
('/ietf-data:dots-data/ietf-data:dots-client/dots- ('/ietf-data:dots-data/ietf-data: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 9.2 may be considered sensitive. It is thus important to Section 10.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:
o '/ietf-data:dots-data/ietf-data:dots-client/dots-telemetry:vendor- o '/ietf-data:dots-data/ietf-data:dots-client/dots-telemetry:vendor-
mapping' can be misused to infer the DDoS protection technology mapping' can be misused to infer the DDoS protection technology
deployed in a DOTS client domain. deployed in a DOTS client domain.
o '/ietf-data:dots-data/dots-telemetry:vendor-mapping' can be used o '/ietf-data:dots-data/dots-telemetry:vendor-mapping' can be used
by a compromised DOTS client to leak the attack detection 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 12.1. compromised DOTS client attacks discussed in Section 13.1.
13. Contributors 14. Contributors
The following individuals have contributed to this document: The following individuals have contributed to this document:
o Li Su, CMCC, Email: suli@chinamobile.com o Li Su, CMCC, Email: suli@chinamobile.com
o Pan Wei, Huawei, Email: william.panwei@huawei.com o Pan Wei, Huawei, Email: william.panwei@huawei.com
14. Acknowledgements 15. 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 The authors would like to thank Kaname Nishizuka, Wei Pan, and Yuuhei
Hayashi for comments and review. Hayashi 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.
15. References Many thanks to Jan Lindblad for the yangdoctors review.
15.1. Normative References 16. References
16.1. Normative References
[Enterprise-Numbers] [Enterprise-Numbers]
"Private Enterprise Numbers", May 2020, "Private Enterprise Numbers", May 2020,
<http://www.iana.org/assignments/enterprise-numbers.html>. <http://www.iana.org/assignments/enterprise-numbers.html>.
[I-D.ietf-dots-signal-call-home] [I-D.boucadair-dots-rfc8782-yang-update]
Reddy.K, T., Boucadair, M., and J. Shallow, "Distributed Boucadair, M. and J. Shallow, "A YANG Data Model for
Denial-of-Service Open Threat Signaling (DOTS) Signal Distributed Denial-of-Service Open Threat Signaling (DOTS)
Channel Call Home", draft-ietf-dots-signal-call-home-08 Signal Channel", draft-boucadair-dots-rfc8782-yang-
(work in progress), March 2020. update-01 (work in progress), July 2020.
[I-D.ietf-dots-signal-filter-control] [I-D.ietf-dots-signal-filter-control]
Nishizuka, K., Boucadair, M., Reddy.K, T., and T. Nagata, 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",
draft-ietf-dots-signal-filter-control-06 (work in draft-ietf-dots-signal-filter-control-07 (work in
progress), June 2020. progress), June 2020.
[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>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
skipping to change at page 104, line 14 skipping to change at page 107, line 10
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
[RFC8768] Boucadair, M., Reddy.K, T., and J. Shallow, "Constrained
Application Protocol (CoAP) Hop-Limit Option", RFC 8768,
DOI 10.17487/RFC8768, March 2020,
<https://www.rfc-editor.org/info/rfc8768>.
[RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P.,
Mortensen, A., and N. Teague, "Distributed Denial-of- Mortensen, A., and N. Teague, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel Service Open Threat Signaling (DOTS) Signal Channel
Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020,
<https://www.rfc-editor.org/info/rfc8782>. <https://www.rfc-editor.org/info/rfc8782>.
[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>.
15.2. Informative References [RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data
Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
June 2020, <https://www.rfc-editor.org/info/rfc8791>.
16.2. Informative References
[Cause] IANA, "DOTS Signal Channel Conflict Cause Codes",
<https://www.iana.org/assignments/dots/dots.xhtml#dots-
signal-channel-conflict-cause-codes>.
[I-D.bosh-core-new-block] [I-D.bosh-core-new-block]
Boucadair, M. and J. Shallow, "Constrained Application Boucadair, M. and J. Shallow, "Constrained Application
Protocol (CoAP) Block-Wise Transfer Options for Faster Protocol (CoAP) Block-Wise Transfer Options for Faster
Transmission", draft-bosh-core-new-block-04 (work in Transmission", draft-bosh-core-new-block-04 (work in
progress), June 2020. progress), June 2020.
[I-D.doron-dots-telemetry] [I-D.doron-dots-telemetry]
Doron, E., Reddy, T., Andreasen, F., Xia, L., and K. Doron, E., Reddy, T., Andreasen, F., Xia, L., and K.
Nishizuka, "Distributed Denial-of-Service Open Threat Nishizuka, "Distributed Denial-of-Service Open Threat
skipping to change at page 104, line 48 skipping to change at page 108, line 8
[I-D.ietf-dots-multihoming] [I-D.ietf-dots-multihoming]
Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing
Deployment Considerations for Distributed-Denial-of- Deployment Considerations for Distributed-Denial-of-
Service Open Threat Signaling (DOTS)", draft-ietf-dots- Service Open Threat Signaling (DOTS)", draft-ietf-dots-
multihoming-04 (work in progress), May 2020. multihoming-04 (work in progress), May 2020.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
L., and K. Nishizuka, "Use cases for DDoS Open Threat L., and K. Nishizuka, "Use cases for DDoS Open Threat
Signaling", draft-ietf-dots-use-cases-23 (work in Signaling", draft-ietf-dots-use-cases-25 (work in
progress), May 2020. progress), July 2020.
[Key-Map] IANA, "DOTS Signal Channel CBOR Key Values",
<https://www.iana.org/assignments/dots/dots.xhtml#dots-
signal-channel-cbor-key-values>.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998, DOI 10.17487/RFC2330, May 1998,
<https://www.rfc-editor.org/info/rfc2330>. <https://www.rfc-editor.org/info/rfc2330>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
 End of changes. 207 change blocks. 
2372 lines changed or deleted 2575 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/