< draft-ietf-dots-telemetry-10.txt   draft-ietf-dots-telemetry-11.txt >
DOTS M. Boucadair, Ed. DOTS M. Boucadair, Ed.
Internet-Draft Orange Internet-Draft Orange
Updates: 8782 (if approved) T. Reddy, Ed. Intended status: Standards Track T. Reddy, Ed.
Intended status: Standards Track McAfee Expires: January 28, 2021 McAfee
Expires: January 11, 2021 E. Doron E. Doron
Radware Ltd. Radware Ltd.
M. Chen M. Chen
CMCC CMCC
J. Shallow J. Shallow
July 10, 2020 July 27, 2020
Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
draft-ietf-dots-telemetry-10 draft-ietf-dots-telemetry-11
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 January 11, 2021. This Internet-Draft will expire on January 28, 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 26 skipping to change at page 2, line 26
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
3.1. Need More Visibility . . . . . . . . . . . . . . . . . . 6 3.1. Need More Visibility . . . . . . . . . . . . . . . . . . 6
3.2. Enahnced Detection . . . . . . . . . . . . . . . . . . . 7 3.2. Enhanced Detection . . . . . . . . . . . . . . . . . . . 7
3.3. Efficient Mitigation . . . . . . . . . . . . . . . . . . 9 3.3. Efficient Mitigation . . . . . . . . . . . . . . . . . . 9
4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 9 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Overview of Telemetry Operations . . . . . . . . . . . . 9 4.1. Overview of Telemetry Operations . . . . . . . . . . . . 9
4.2. Generic Considerations . . . . . . . . . . . . . . . . . 10 4.2. Generic Considerations . . . . . . . . . . . . . . . . . 10
4.2.1. DOTS Client Identification . . . . . . . . . . . . . 10 4.2.1. DOTS Client Identification . . . . . . . . . . . . . 10
4.2.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . 10 4.2.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . 10
4.2.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . 10 4.2.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . 10
4.2.4. Controlling Configuration Data . . . . . . . . . . . 10 4.2.4. Controlling Configuration Data . . . . . . . . . . . 10
4.3. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 11 4.3. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 11
4.4. DOTS Multi-homing Considerations . . . . . . . . . . . . 11 4.4. DOTS Multi-homing Considerations . . . . . . . . . . . . 11
4.5. YANG Considerations . . . . . . . . . . . . . . . . . . . 11 4.5. YANG Considerations . . . . . . . . . . . . . . . . . . . 11
4.6. A Note About Examples . . . . . . . . . . . . . . . . . . 12 4.6. A Note About Examples . . . . . . . . . . . . . . . . . . 12
5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 12 5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 12
6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 13 6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 13
6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 14 6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 14
6.1.1. Retrieve Current DOTS 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 . . . 20
6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 20 6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 20
6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 20 6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 21
6.2.1. Convey DOTS Client Domain Pipe Capacity . . . . . . . 21 6.2.1. Convey DOTS Client Domain Pipe Capacity . . . . . . . 22
6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity . 27 6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity . 27
6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 27 6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 27
6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 27 6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 28
6.3.1. Convey DOTS Client Domain Baseline Information . . . 30 6.3.1. Convey DOTS Client Domain Baseline Information . . . 31
6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 33 6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 34
6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 33 6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 34
6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 33 6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 34
6.5. Conflict with Other DOTS Clients of the Same Domain . . . 33 6.5. Conflict with Other DOTS Clients of the Same Domain . . . 34
7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 34 7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 35
7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 36 7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 37
7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 37 7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 38
7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 38 7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 39
7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 39 7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 40
7.1.4. Total Attack Connections . . . . . . . . . . . . . . 41 7.1.4. Total Attack Connections . . . . . . . . . . . . . . 42
7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 44 7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 45
7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 50 7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 51
7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 53 7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 54
8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 58 8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 59
8.1. DOTS Clients to Servers Mitigation Efficacy DOTS 8.1. DOTS Clients to Servers Mitigation Efficacy DOTS
Telemetry Attributes . . . . . . . . . . . . . . . . . . 58 Telemetry Attributes . . . . . . . . . . . . . . . . . . 59
8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry 8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry
Attributes . . . . . . . . . . . . . . . . . . . . . . . 60 Attributes . . . . . . . . . . . . . . . . . . . . . . . 61
9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 64 9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 65
10. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 66 10. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 65
10.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . 66 10.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . 65
10.2. Vendor Attack Mapping Details YANG Module . . . . . . . 93 10.2. Vendor Attack Mapping Details YANG Module . . . . . . . 93
11. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 96 11. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 96
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 99 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 98
12.1. A New Range for Comprehension-optional Parameters . . . 99 12.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 98
12.2. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 99 12.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 101
12.3. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 102 12.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 101
12.4. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 102 13. Security Considerations . . . . . . . . . . . . . . . . . . . 102
13. Security Considerations . . . . . . . . . . . . . . . . . . . 103 13.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 102
13.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 103 13.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 103
13.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 104 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 104
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 105 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 104
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 104
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 105 16.1. Normative References . . . . . . . . . . . . . . . . . . 104
16.1. Normative References . . . . . . . . . . . . . . . . . . 105 16.2. Informative References . . . . . . . . . . . . . . . . . 106
16.2. Informative References . . . . . . . . . . . . . . . . . 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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 4, line 43 skipping to change at page 4, line 43
The conclusion derived from these real scenarios is that modern The conclusion derived from these real scenarios is that modern
attacks detection and mitigation are most certainly complicated and attacks detection and mitigation are most certainly complicated and
highly convoluted tasks. They demand a comprehensive knowledge of highly convoluted tasks. They demand a comprehensive knowledge of
the attack attributes, the targeted normal behavior (including, the attack attributes, the targeted normal behavior (including,
normal traffic patterns), as well as the attacker's on-going and past normal traffic patterns), as well as the attacker's on-going and past
actions. Even more challenging, retrieving all the analytics needed actions. Even more challenging, retrieving all the analytics needed
for detecting these attacks is not simple to obtain with the for detecting these attacks is not simple to obtain with the
industry's current capabilities. industry's current capabilities.
The DOTS signal channel protocol [RFC8782] is used to carry The DOTS signal channel protocol [I-D.boucadair-dots-rfc8782-bis] is
information about a network resource or a network (or a part thereof) used to carry information about a network resource or a network (or a
that is under a DDoS attack. Such information is sent by a DOTS part thereof) that is under a DDoS attack. Such information is sent
client to one or multiple DOTS servers so that appropriate mitigation by a DOTS client to one or multiple DOTS servers so that appropriate
actions are undertaken on traffic deemed suspicious. Various use mitigation actions are undertaken on traffic deemed suspicious.
cases are discussed in [I-D.ietf-dots-use-cases]. Various use cases are discussed in [I-D.ietf-dots-use-cases].
Typically, DOTS clients can be integrated within a DDoS attack Typically, DOTS clients can be integrated within a DDoS attack
detector, or network and security elements that have been actively detector, or network and security elements that have been actively
engaged with ongoing attacks. The DOTS client mitigation environment engaged with ongoing attacks. The DOTS client mitigation environment
determines that it is no longer possible or practical for it to determines that it is no longer possible or practical for it to
handle these attacks. This can be due to a lack of resources or handle these attacks. This can be due to a lack of resources or
security capabilities, as derived from the complexities and the security capabilities, as derived from the complexities and the
intensity of these attacks. In this circumstance, the DOTS client intensity of these attacks. In this circumstance, the DOTS client
has invaluable knowledge about the actual attacks that need to be has invaluable knowledge about the actual attacks that need to be
handled by its DOTS server(s). By enabling the DOTS client to share handled by its DOTS server(s). By enabling the DOTS client to share
skipping to change at page 5, line 25 skipping to change at page 5, line 25
DOTS server can share this information with the DOTS client so that DOTS server can share this information with the DOTS client so that
the client can better assess and evaluate the actual mitigation the client can better assess and evaluate the actual mitigation
realized. realized.
DOTS clients can send mitigation hints derived from attack details to DOTS clients can send mitigation hints derived from attack details to
DOTS servers, with the full understanding that 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 clients and servers 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 attributes of the DOTS signal channel attributes are not mandatory attributes of the DOTS signal channel
protocol [RFC8782]. Nevertheless, when DOTS telemetry attributes are protocol [I-D.boucadair-dots-rfc8782-bis]. Nevertheless, when DOTS
available to a DOTS agent, and absent any policy, it can signal the telemetry attributes are available to a DOTS agent, and absent any
attributes in order to optimize the overall mitigation service policy, it can signal the attributes in order to optimize the overall
provisioned using DOTS. mitigation service 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.
Telemetry Setup Identifier (tsid) is an identifier that is generated
by DOTS clients to uniquely identify DOTS telemetry setup
configuration data.
Telemetry Identifier (tmid) is an identifier that is generated by
DOTS clients to uniquely identify DOTS telemetry data that is
communicated prior or during a mitigation.
The meaning of the symbols in YANG tree diagrams are defined in The meaning of the symbols in YANG tree diagrams are defined in
[RFC8340] and [RFC8791]. [RFC8340] and [RFC8791].
3. DOTS Telemetry: Overview and Purpose 3. DOTS Telemetry: Overview and Purpose
Timely and effective signaling of up-to-date DDoS telemetry to all Timely and effective signaling of up-to-date DDoS telemetry to all
elements involved in the mitigation process is essential and improves elements involved in the mitigation process is essential and improves
the overall DDoS mitigation service effectiveness. Bi-directional the overall DDoS mitigation service effectiveness. Bi-directional
feedback between DOTS agents is required for an increased awareness feedback between DOTS agents is required for an increased awareness
of each party, supporting superior and highly efficient attack of each party, supporting superior and highly efficient attack
skipping to change at page 7, line 24 skipping to change at page 7, line 32
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 3.2. Enhanced 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
defined threshold for a certain period of time is considered as an predefined 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
actual traffic thresholds are automatically calculated by learning actual traffic thresholds are automatically calculated by learning
the protected entity normal traffic behavior during idle time. The the protected entity normal traffic behavior during idle time. The
normal traffic characterization learned is referred to as the "normal normal traffic characterization learned is referred to as the "normal
traffic baseline". An attack is detected when the victim's actual traffic baseline". An attack is detected when the victim's actual
traffic is deviating from this normal baseline. traffic is deviating from this normal baseline.
skipping to change at page 8, line 28 skipping to change at page 8, line 35
resources with the DOTS client's normal baseline. The DOTS server resources with the DOTS client's normal baseline. The DOTS server
mitigators use the baseline to familiarize themselves with the attack mitigators use the baseline to familiarize themselves with the attack
victim's normal behavior and target the baseline as the level of victim's normal behavior and target the baseline as the level of
normality they need to achieve. Fed with this inforamtion, the normality they need to achieve. Fed with this inforamtion, the
overall mitigation performances is expected to be improved in terms overall mitigation performances is expected to be improved in terms
of time to mitigate, accuracy, false-negative, and false-positive. of time to mitigate, accuracy, false-negative, and false-positive.
Mitigation of attacks without having certain knowledge of normal Mitigation of attacks without having certain knowledge of normal
traffic can be inaccurate at best. This is especially true for traffic can be inaccurate at best. This is especially true for
recursive signaling (see Section 3.2.3 in [I-D.ietf-dots-use-cases]). recursive signaling (see Section 3.2.3 in [I-D.ietf-dots-use-cases]).
In addition, the highly diverse types of use-cases where DOTS clients In addition, the highly diverse types of use cases where DOTS clients
are integrated also emphasize the need for knowledge of each DOTS are integrated also emphasize the need for knowledge of each DOTS
client domain behavior. Consequently, common global thresholds for client domain behavior. Consequently, common global thresholds for
attack detection practically cannot be realized. Each DOTS client attack detection practically cannot be realized. Each DOTS client
domain can have its own levels of traffic and normal behavior. domain can have its own levels of traffic and normal behavior.
Without facilitating normal baseline signaling, it may be very Without facilitating normal baseline signaling, it may be very
difficult for DOTS servers in some cases to detect and mitigate the difficult for DOTS servers in some cases to detect and mitigate the
attacks accurately: attacks accurately:
It is important to emphasize that it is practically impossible for It is important to emphasize that it is practically impossible for
the DOTS server's mitigators to calculate the normal baseline in the DOTS server's mitigators to calculate the normal baseline in
skipping to change at page 9, line 30 skipping to change at page 9, line 37
under a DDoS attack is essential (e.g., where multiple DOTS clients under a DDoS attack is essential (e.g., where multiple DOTS clients
share the same physical connectivity pipes). It is important to note share the same physical connectivity pipes). It is important to note
that the term "pipe" noted here does not necessary represent physical that the term "pipe" noted here does not necessary represent physical
pipe, but rather represents the maximum level of traffic that the pipe, but rather represents the maximum level of traffic that the
DOTS client domain can receive. The DOTS server should activate DOTS client domain can receive. The DOTS server should activate
other mechanisms to ensure it does not allow the DOTS client domain's other mechanisms to ensure it does not allow the DOTS client domain's
pipes to be saturated unintentionally. The rate-limit action defined pipes to be saturated unintentionally. The rate-limit action defined
in [RFC8783] is a reasonable candidate to achieve this objective; the 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.
4. Design Overview 4. Design Overview
4.1. Overview of Telemetry Operations 4.1. Overview of Telemetry Operations
This document specifies an extension to the DOTS signal channel This document specifies an extension to the DOTS signal channel
protocol. Considerations about how to establish, maintain, and make protocol. Considerations about how to establish, maintain, and make
use of the DOTS signal channel are specified in [RFC8782]. use of the DOTS signal channel are specified in
[I-D.boucadair-dots-rfc8782-bis].
Once the DOTS signal channel is established, DOTS clients that Once the DOTS signal channel is established, DOTS clients that
support the DOTS telemetry extension proceed with the telemetry setup support the DOTS telemetry extension proceed with the telemetry setup
configuration (e.g., measurement interval, telemetry notification configuration (e.g., measurement interval, telemetry notification
interface, pipe capacity, normal traffic baseline) as detailed in interface, pipe capacity, normal traffic baseline) as detailed in
Section 6. DOTS agents can then include DOTS telemetry attributes Section 6. DOTS agents can then include DOTS telemetry attributes
using the DOTS signal channel (Section 7.1). Typically, a DOTS using the DOTS signal channel (Section 7.1). Typically, a DOTS
client can use separate messages to share with its DOTS server(s) a 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). set of telemetry data bound to an ongoing mitigation (Section 7.2).
Also, a DOTS client that is interested to receive telemetry Also, a DOTS client that is interested to receive telemetry
skipping to change at page 10, line 14 skipping to change at page 10, line 22
mitigation request if the notified attack cannot be mitigated locally mitigation request if the notified attack cannot be mitigated locally
within the DOTS client domain. within the DOTS client domain.
Aggregate DOTS telemetry data can also be included in efficacy update Aggregate DOTS telemetry data can also be included in efficacy update
(Section 8.1) or mitigation update (Section 8.2) messages. (Section 8.1) or mitigation update (Section 8.2) messages.
4.2. Generic Considerations 4.2. Generic Considerations
4.2.1. DOTS Client Identification 4.2.1. DOTS Client Identification
Following the rules in Section 4.4.1 of [RFC8782], a unique Following the rules in Section 5.4.1 of
identifier is generated by a DOTS client to prevent request [I-D.boucadair-dots-rfc8782-bis], a unique identifier is generated by
collisions ('cuid'). a DOTS client to prevent request collisions ('cuid').
As a reminder, [RFC8782] forbids 'cuid' to be returned in a response As a reminder, [I-D.boucadair-dots-rfc8782-bis] forbids 'cuid' to be
message body. returned in a response message body.
4.2.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 5.4.1 of
followed. In particular, 'cdid' attribute is used to unambiguously [I-D.boucadair-dots-rfc8782-bis] must be followed. In particular,
identify a DOTS client domain. 'cdid' attribute is used to unambiguously identify a DOTS client
domain.
As a reminder, [RFC8782] forbids 'cdid' (if present) to be returned As a reminder, [I-D.boucadair-dots-rfc8782-bis] forbids 'cdid' (if
in a response message body. present) to be returned in a response message body.
4.2.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.2.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 5.5.3 of [I-D.boucadair-dots-rfc8782-bis] for managing
configuration freshness and notification. DOTS telemetry configuration freshness and notification.
Likewise, a DOTS client may control the selection of configuration Likewise, a DOTS client may control the selection of configuration
and non-configuration data nodes when sending a GET request by means and non-configuration data nodes when sending a GET request by means
of the 'c' Uri-Query option and following the procedure specified in of the 'c' Uri-Query option and following the procedure specified in
Section of 4.4.2 of [RFC8782]. These considerations are not re- Section of 5.4.2 of [I-D.boucadair-dots-rfc8782-bis]. These
iterated in the following sections. considerations are not reiterated in the following sections.
4.3. Block-wise Transfer 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 5.4.2 of
size of a response when the data to be returned does not fit within a [I-D.boucadair-dots-rfc8782-bis] to control the size of a response
single datagram. when the data to be returned does not fit within a 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
skipping to change at page 11, line 40 skipping to change at page 11, line 46
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. network.
Considerations related to whether (and how) a DOTS client gleans some Considerations related to whether (and how) a DOTS client gleans some
telemetry information (e.g., attack details) it receives from a first telemetry information (e.g., attack details) it receives from a first
DOTS server and share it with a second DOTS server are implementation DOTS server and share it with a second DOTS server are implementation
and deployment-specific. and deployment specific.
4.5. YANG Considerations 4.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) [RFC7252]. CBOR-encoded Concise Binary Object Representation (CBOR) [RFC7049]. CBOR-encoded
payloads are used to carry signal channel-specific payload messages payloads are used to carry signal channel specific payload messages
which convey request parameters and response information such as which convey request parameters and response information such as
errors. errors.
This document specifies a YANG module for representing DOTS telemetry This document specifies a YANG module [RFC7950] for representing DOTS
message types (Section 10.1). All parameters in the payload of the telemetry message types (Section 10.1). All parameters in the
DOTS signal channel are mapped to CBOR types as specified in payload of the DOTS signal channel are mapped to CBOR types as
Section 11. specified in Section 11.
The DOTS telemetry module (Section 10.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 following [RFC8791]. only to provide a data model and encoding following [RFC8791].
The DOTS telemetry module (Section 10.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
skipping to change at page 12, line 29 skipping to change at page 12, line 34
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 10.1) and the mapping table established in YANG module (Section 10.1) and the mapping table established in
Section 11. 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 5.2 of [I-D.boucadair-dots-rfc8782-bis], each
indicated by a path-suffix that indicates the intended operation. DOTS operation is indicated by a path suffix that indicates the
The operation path is appended to the path-prefix to form the URI intended operation. The operation path is appended to the path
used with a CoAP request to perform the desired DOTS operation. The prefix to form the URI used with a CoAP request to perform the
following telemetry path-suffixes are defined (Table 1): desired DOTS operation. The 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 10.1 defines data structure to represent new DOTS 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 Sections 6 and 7 is shown in Figure 1. More details are provided in Sections 6 and 7
about the exact structure of "telemetry-setup" and "telemetry" about the exact structure of 'telemetry-setup' and 'telemetry'
message types. message types.
structure dots-telemetry: structure dots-telemetry:
+-- (telemetry-message-type)? +-- (telemetry-message-type)?
+--:(telemetry-setup) +--:(telemetry-setup)
| ... | ...
| +-- telemetry* [] | +-- telemetry* []
| ... | ...
| +-- (setup-type)? | +-- (setup-type)?
| +--:(telemetry-config) | +--:(telemetry-config)
skipping to change at page 17, line 12 skipping to change at page 17, line 40
The following additional Uri-Path parameter is defined: The following additional Uri-Path parameter is defined:
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 5.4.1 of
followed for 'tsid' rollover. [I-D.boucadair-dots-rfc8782-bis] MUST be followed for 'tsid'
rollover.
This is a mandatory attribute. 'tsid' MUST follow 'cuid'. 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
skipping to change at page 17, line 51 skipping to change at page 18, line 31
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.
The DOTS client may re-try and send the PUT request with updated The DOTS client may retry and send the PUT request with updated
attribute values acceptable to the DOTS server. attribute values acceptable to the DOTS server.
By default, low percentile (10th percentile), mid percentile (50th By default, low percentile (10th percentile), mid percentile (50th
percentile), high percentile (90th percentile), and peak (100th percentile), high percentile (90th percentile), and peak (100th
percentile) values are used to represent telemetry data. percentile) values are used to represent telemetry data.
Nevertheless, a DOTS client can disable some percentile types (low, Nevertheless, a DOTS client can disable some percentile types (low,
mid, high). In particular, setting 'low-percentile' to '0.00' mid, high). In particular, setting 'low-percentile' to '0.00'
indicates that the DOTS client is not interested in receiving low- indicates that the DOTS client is not interested in receiving low-
percentiles. Likewise, setting 'mid-percentile' (or 'high- percentiles. Likewise, setting 'mid-percentile' (or 'high-
percentile') to the same value as 'low-percentile' (or 'mid- percentile') to the same value as 'low-percentile' (or 'mid-
skipping to change at page 18, line 48 skipping to change at page 19, line 33
] ]
} }
} }
Figure 5: PUT to Disable Low- and Mid-Percentiles Figure 5: PUT to Disable Low- and Mid-Percentiles
DOTS clients can also configure the unit type(s) to be used for DOTS clients can also configure the unit type(s) to be used for
traffic-related telemetry data. Typically, the supported unit types traffic-related telemetry data. Typically, the supported unit types
are: packets per second, bits per second, and bytes per second. are: packets per second, bits per second, and bytes per second.
DOTS clients that are interested to receive pre- or ongoing DOTS clients that are interested to receive pre or ongoing mitigation
mitigation telemetry (pre-or-ongoing-mitigation) information from a telemetry (pre-or-ongoing-mitigation) information from a DOTS server
DOTS server (Section 8.2) MUST set 'server-originated-telemetry' to (Section 8.2) MUST set 'server-originated-telemetry' to 'true'. If
'true'. If 'server-originated-telemetry' is not present in a PUT 'server-originated-telemetry' is not present in a PUT request, this
request, this is equivalent to receiving a request with 'server- is equivalent to receiving a request with 'server-originated-
originated-telemetry' set to 'false'. An example of a request to telemetry' set to 'false'. An example of a request to enable pre-or-
enable pre-or-ongoing-mitigation telemetry from DOTS servers is shown ongoing-mitigation telemetry from DOTS servers is shown in Figure 6.
in Figure 6.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=569" Uri-Path: "tsid=569"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
skipping to change at page 21, line 29 skipping to change at page 22, line 6
| | +-- capacity uint64 | | +-- capacity uint64
| | +-- unit unit | | +-- unit unit
| +--:(baseline) | +--:(baseline)
| ... | ...
+--:(telemetry) +--:(telemetry)
... ...
Figure 9: Pipe Tree Structure Figure 9: Pipe Tree Structure
A DOTS client domain pipe is defined as a list of limits 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
captured in 'unit' attribute. captured in 'unit' attribute.
6.2.1. Convey DOTS Client Domain Pipe Capacity 6.2.1. Convey DOTS Client Domain Pipe Capacity
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
pipe attributes from a DOTS client is determined by comparing pipe attributes from a DOTS client is determined by comparing
their respective 'tsid' values. If such two requests have their respective 'tsid' values. If such two requests have
overlapping "link-id" and "unit", the PUT request with higher overlapping 'link-id' and 'unit', the PUT request with higher
numeric 'tsid' value will override the request with a lower numeric 'tsid' value will override the request with a lower
numeric 'tsid' value. The overlapped lower numeric 'tsid' MUST be numeric 'tsid' value. The overlapped lower numeric 'tsid' MUST be
automatically deleted and no longer be available. automatically deleted and no longer be available.
DOTS clients SHOULD minimize the number of active 'tsids' used for DOTS clients SHOULD minimize the number of active 'tsids' used for
pipe information. Typically, in order to avoid maintaining a long pipe information. Typically, in order to avoid maintaining a long
list of 'tsids' for pipe information, it is RECOMMENDED that DOTS list of 'tsids' for pipe information, it is RECOMMENDED that DOTS
clients include in any request to update information related to a clients include in any request to update information related to a
given link the information of other links (already communicated using given link the information of other links (already communicated using
a lower 'tsid' value). Doing so, this update request will override a lower 'tsid' value). Doing so, this update request will override
skipping to change at page 23, line 10 skipping to change at page 23, line 37
} }
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 that manages a DOTS individual links. For example, a DOTS client that manages a DOTS
client domain having two interconnection links with an upstream ISP client domain having two interconnection links with an upstream ISP
(Figure 12) can send a PUT request (shown in Figure 13) to (Figure 12) can send a PUT request (shown in Figure 13) to
communicate the aggregate link capacity with its ISP. 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 ,-'====== `-. ,-'
`--'--'--' `--'--'--' `--'--'--' `--'--'--'
Figure 12: DOTS Client Domain with Two Interconnection Links Figure 12: DOTS Client Domain with Two Interconnection Links
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
skipping to change at page 26, line 4 skipping to change at page 26, line 15
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, and assuming no error is Figure 17. Upon receipt of this request, and assuming no error is
encountered when processing the request, the DOTS server removes encountered when processing the request, the DOTS server removes
"link1" from its configuration bases for this DOTS client domain. "link1" from its configuration bases for this DOTS client domain.
Note that if the DOTS server receives a PUT request with a 'capacity'
attribute set to "0" for all included links, it MUST reject the
request with a 4.00 (Bad Request).
,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
( ISP#B ) ( ISP#B )
`-. ,-' `-. ,-'
`--'--'--' `--'--'--'
|| ||
|| link2 || link2
,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
skipping to change at page 27, line 43 skipping to change at page 28, line 28
The traffic normal per port number ('total-traffic-normal-per- The traffic normal per port number ('total-traffic-normal-per-
port') baseline is represented for each port number bound to a port') baseline is represented for each port number bound to a
target. target.
If the DOTS client negotiated percentile values and units If the DOTS client negotiated percentile values and units
(Section 6.1), these negotiated values will be used instead of the (Section 6.1), these negotiated values will be used instead of the
default ones. default ones.
Total connections capacity: If the target is subjected to resource Total connections capacity: If the target is subjected to resource
consuming DDoS attacks, the following optional attributes for the consuming DDoS attacks, the following optional attributes for the
target per transport-protocol are useful to detect resource target per transport protocol are useful to detect resource
consuming DDoS attacks: consuming DDoS attacks:
* The maximum number of simultaneous connections that are allowed * The maximum number of simultaneous connections that are allowed
to the target. to the target.
* The maximum number of simultaneous connections that are allowed * The maximum number of simultaneous connections that are allowed
to the target per client. to the target per client.
* The maximum number of simultaneous embryonic connections that * The maximum number of simultaneous embryonic connections that
are allowed to the target. The term "embryonic connection" are allowed to the target. The term "embryonic connection"
skipping to change at page 28, line 35 skipping to change at page 29, line 20
* The maximum number of partial requests allowed per second to * The maximum number of partial requests allowed per second to
the target. Attacks relying upon partial requests create a the target. Attacks relying upon partial requests create a
connection with a target but do not send a complete request connection with a target but do not send a complete request
(e.g., 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 normal traffic baseline is shown in The tree structure of the normal traffic baseline is shown in
Figure 18. Figure 18.
structure dots-telemetry: structure dots-telemetry:
+-- (telemetry-message-type)? +-- (telemetry-message-type)?
+--:(telemetry-setup) +--:(telemetry-setup)
| ... | ...
| +-- telemetry* [] | +-- telemetry* []
skipping to change at page 30, line 43 skipping to change at page 31, line 28
their respective 'tsid' values. If such two requests have their respective 'tsid' values. If such two requests have
overlapping targets, the PUT request with higher numeric 'tsid' overlapping targets, the PUT request with higher numeric 'tsid'
value will override the request with a lower numeric 'tsid' value. value will override the request with a lower numeric 'tsid' value.
The overlapped lower numeric 'tsid' MUST be automatically deleted The overlapped lower numeric 'tsid' MUST be automatically deleted
and no longer be available. and no longer be available.
Two PUT requests from a DOTS client have overlapping targets if there Two PUT requests from a DOTS client have overlapping targets if there
is a common IP address, IP prefix, FQDN, URI, or alias-name. Also, is a common IP address, IP prefix, FQDN, URI, or alias-name. Also,
two PUT requests from a DOTS client have overlapping targets if the two PUT requests from a DOTS client have overlapping targets if the
addresses associated with the FQDN, URI, or alias are overlapping addresses associated with the FQDN, URI, or alias are overlapping
with each other or with target-prefix. with each other or with 'target-prefix'.
DOTS clients SHOULD minimize the number of active 'tsids' used for DOTS clients SHOULD minimize the number of active 'tsids' used for
baseline information. Typically, in order to avoid maintaining a baseline information. Typically, in order to avoid maintaining a
long list of 'tsids' for baseline information, it is RECOMMENDED that long list of 'tsids' for baseline information, it is RECOMMENDED that
DOTS clients include in a request to update information related to a DOTS clients include in a request to update information related to a
given target, the information of other targets (already communicated given target, the information of other targets (already communicated
using a lower 'tsid' value) (assuming this fits within one single using a lower 'tsid' value) (assuming this fits within one single
datagram). This update request will override these existing requests datagram). This update request will override these existing requests
and hence optimize the number of 'tsid' request per DOTS client. and hence optimize the number of 'tsid' request per DOTS client.
If no target clause in included in the request, this is an indication If no target clause is included in the request, this is an indication
that the baseline information applies for the DOTS client domain as a that the baseline information applies for the DOTS client domain as a
whole. whole.
An example of a PUT request to convey the baseline information is An example of a PUT request to convey the baseline information is
shown in Figure 19. shown in Figure 19.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
skipping to change at page 31, line 48 skipping to change at page 32, line 39
] ]
} }
] ]
} }
] ]
} }
} }
Figure 19: PUT to Convey the DOTS Traffic Baseline Figure 19: PUT to Convey the DOTS Traffic Baseline
The DOTS client may share protocol-specific baseline information The DOTS client may share protocol specific baseline information
(e.g., TCP and UDP) as shown in Figure 19. (e.g., TCP and UDP) as shown in Figure 19.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=128" Uri-Path: "tsid=128"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
skipping to change at page 33, line 42 skipping to change at page 34, line 42
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Figure 21: Delete Telemetry Configuration Figure 21: Delete Telemetry Configuration
6.5. Conflict with Other DOTS Clients of the Same Domain 6.5. Conflict with Other DOTS Clients of the Same Domain
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 5.4.1 of [I-D.boucadair-dots-rfc8782-bis]. The conflict
these values: cause can be set to one of these values:
1: Overlapping targets (Section 4.4.1 of [RFC8782]). 1: Overlapping targets (Section 5.4.1 of
[I-D.boucadair-dots-rfc8782-bis]).
TBA: Overlapping pipe scope (see Section 12). 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 10.1) defines the data The "ietf-dots-telemetry" YANG module (Section 10.1) defines the data
structure of a new message type called "telemetry". The tree structure of a new message type called 'telemetry'. The tree
structure of the "telemetry" message type is shown in Figure 24. structure of the 'telemetry' message type is shown in Figure 24.
The pre-or-ongoing-mitigation telemetry attributes are indicated by The pre-or-ongoing-mitigation telemetry attributes are indicated by
the path-suffix '/tm'. The '/tm' is appended to the path-prefix to the path suffix '/tm'. The '/tm' is appended to the path prefix to
form the URI used with a CoAP request to signal the DOTS telemetry. form the URI used with a CoAP request to signal the DOTS telemetry.
Pre-or-ongoing-mitigation telemetry attributes specified in Pre-or-ongoing-mitigation telemetry attributes specified in
Section 7.1 can be signaled between DOTS agents. Section 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
skipping to change at page 38, line 17 skipping to change at page 39, line 17
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.
If the target is subjected to resource consuming DDoS attacks, the If the target is subjected to resource consuming DDoS attacks, the
same attributes defined for Section 7.1.4 are applicable for same attributes defined for Section 7.1.4 are applicable for
representing the attack. representing the attack.
This is an optional sub-attribute. This is an optional subattribute.
7.1.2. Total Traffic 7.1.2. Total Traffic
The 'total-traffic' attribute (Figure 26) conveys the percentile The 'total-traffic' attribute (Figure 26) conveys the percentile
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.
skipping to change at page 39, line 50 skipping to change at page 40, line 50
+-- total-attack-connection-port +-- total-attack-connection-port
| ... | ...
+-- attack-detail* [vendor-id attack-id] +-- attack-detail* [vendor-id attack-id]
... ...
Figure 26: Total Traffic Tree Structure Figure 26: Total Traffic Tree Structure
7.1.3. Total Attack Traffic 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 DDoS Mitigation
Detector). More granular total traffic can be conveyed in 'total- System (or DDoS Detector). More granular total traffic can be
attack-traffic-protocol' and 'total-attack-traffic-port'. conveyed in 'total-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) +--:(telemetry)
+-- pre-or-ongoing-mitigation* [] +-- pre-or-ongoing-mitigation* []
+-- (direction)? +-- (direction)?
skipping to change at page 41, line 52 skipping to change at page 42, line 52
| ... | ...
+-- 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
attributes for the target per transport-protocol are included to subattributes 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.
skipping to change at page 44, line 8 skipping to change at page 45, line 8
| +-- request-ps? yang:gauge64 | +-- request-ps? yang:gauge64
| +-- partial-request-ps? yang:gauge64 | +-- partial-request-ps? yang:gauge64
+-- attack-detail* [vendor-id attack-id] +-- attack-detail* [vendor-id attack-id]
... ...
Figure 28: Total Attack Connections Tree Structure Figure 28: Total Attack Connections Tree Structure
7.1.5. Attack Details 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 subattributes describing the
the on-going attack can be signal as attack details. ongoing 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-description: Textual representation of the attack attack-description: Textual representation of the attack
description. Natural Language Processing techniques (e.g., word description. Natural Language Processing techniques (e.g., word
embedding) can possibly be used to map the attack description to embedding) can possibly be used to map the attack description to
skipping to change at page 46, line 45 skipping to change at page 47, line 45
+-- connection? yang:gauge64 +-- connection? yang:gauge64
+-- embryonic? yang:gauge64 +-- embryonic? yang:gauge64
+-- connection-ps? yang:gauge64 +-- connection-ps? yang:gauge64
+-- request-ps? yang:gauge64 +-- request-ps? yang:gauge64
+-- partial-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 description). is, {vendor identifier, attack identifier} ==> attack description).
As such, DOTS agents do not have to convey systematically an attack As such, DOTS agents do not have to convey systematically an attack
description in their telemetry messages over the DOTS signal channel. description in their telemetry messages over the DOTS signal channel.
Multiple mappings for different vendor identifiers may be used; the Multiple mappings for different vendor identifiers may be used; the
DOTS agent transmitting telemetry information can elect to use one or DOTS agent transmitting telemetry information can elect to use one or
more vendor mappings even in the same telemetry message. more vendor mappings even in the same telemetry message.
Note: It is possible that a DOTS server is making use of multiple Note: It is possible that a DOTS server is making use of multiple
DOTS mitigators; each from a different vendor. How telemetry DOTS mitigators; each from a different vendor. How telemetry
skipping to change at page 52, line 5 skipping to change at page 53, line 5
'cuid' is a mandatory Uri-Path parameter for PUT requests. 'cuid' is a mandatory Uri-Path parameter for PUT requests.
The following additional Uri-Path parameter is defined: The following additional Uri-Path parameter is defined:
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 5.4.1 of
followed for 'tmid' rollover. [I-D.boucadair-dots-rfc8782-bis] MUST be followed for 'tmid'
rollover.
This is a mandatory attribute. 'tmid' MUST follow 'cuid'. This is a mandatory attribute. 'tmid' MUST follow 'cuid'.
'cuid' and 'tmid' MUST NOT appear in the PUT request message body. 'cuid' and 'tmid' MUST NOT appear in the PUT request message body.
At least '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
skipping to change at page 52, line 30 skipping to change at page 53, line 31
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. In particular, the 2.04 (Changed) using CoAP Response Codes. In particular, the 2.04 (Changed)
Response Code is returned if the DOTS server has accepted the pre-or- Response Code is returned if the DOTS server has accepted the pre-or-
ongoing-mitigation telemetry. The 5.03 (Service Unavailable) ongoing-mitigation telemetry. The 5.03 (Service Unavailable)
Response Code is returned if the DOTS server has erred. 5.03 uses Response Code is returned if the DOTS server has erred. 5.03 uses
Max-Age option to indicate the number of seconds after which to Max-Age Option to indicate the number of seconds after which to
retry. 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
client may then delete 'tmids' that should not be active anymore client may then delete 'tmids' that should not be active anymore
(Figure 37). Sending a DELETE with no 'tmid' indicates that all (Figure 37). Sending a DELETE with no 'tmid' indicates that all
'tmids' must be deactivated (Figure 38). 'tmids' must be deactivated (Figure 38).
skipping to change at page 55, line 17 skipping to change at page 56, line 17
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. A 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.2.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
skipping to change at page 55, line 45 skipping to change at page 56, line 45
character) can be included in 'target-fqdn' or 'target-uri' character) can be included in 'target-fqdn' or 'target-uri'
parameters. DOTS clients MUST NOT include a name in which the "*" parameters. DOTS clients MUST NOT include a name in which the "*"
character is included in a label other than the leftmost label. character is included in a label other than the leftmost label.
"*.example.com" is an example of a valid wildcard name that can be "*.example.com" is an example of a valid wildcard name that can be
included as a value of the 'target-fqdn' parameter in an Uri-Query included as a value of the 'target-fqdn' parameter in an Uri-Query
option. option.
DOTS clients may also filter out the asynchronous notifications from DOTS clients may also filter out the asynchronous notifications from
the DOTS server by indicating a specific source information. To that the DOTS server by indicating a specific source information. To that
aim, a DOTS client may include 'source-prefix', 'source-port', or aim, a DOTS client may include 'source-prefix', 'source-port', or
'source-icmp-type' in an Uri-Query option. The same considerations 'source-icmp-type' in a Uri-Query option. The same considerations
(ranges, multiple values) specified for target clauses apply for (ranges, multiple values) specified for target clauses apply for
source clauses. Special care SHOULD be taken when using these source clauses. Special care SHOULD be taken when using these
filters as some attacks may be hidden to the requesting DOTS client filters as some attacks may be hidden to the requesting DOTS client
(e.g., the attack changes its source information). (e.g., the attack changes its source information).
Requests with invalid query types (e.g., not supported, malformed) by Requests with invalid query types (e.g., not supported, malformed) by
the DOTS server MUST be rejected by DOTS servers with a 4.00 (Bad the DOTS server MUST be rejected by DOTS servers with a 4.00 (Bad
Request). Request).
An example of request to subscribe to asynchronous UDP telemetry An example of request to subscribe to asynchronous UDP telemetry
skipping to change at page 56, line 26 skipping to change at page 57, line 26
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Query: "target-protocol=17" Uri-Query: "target-protocol=17"
Observe: 0 Observe: 0
Figure 42: GET Request to Receive Telemetry Asynchronous Figure 42: GET Request to Receive Telemetry Asynchronous
Notifications Filtered using Uri-Query Notifications Filtered using Uri-Query
The DOTS server will send asynchronous notifications to the DOTS The DOTS server will send asynchronous notifications to the DOTS
client when an attack event is detected following 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 5.4.2.1 of
pre-or-ongoing-mitigation telemetry notification is shown in [I-D.boucadair-dots-rfc8782-bis]. An example of a pre-or-ongoing-
Figure 43. mitigation telemetry notification is shown in Figure 43.
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [ "pre-or-ongoing-mitigation": [
{ {
"tmid": 567, "tmid": 567,
"target": { "target": {
"target-prefix": [ "target-prefix": [
"2001:db8::1/128" "2001:db8::1/128"
] ]
skipping to change at page 58, line 21 skipping to change at page 59, line 21
mitigation telemetry data for a target MUST send a delete request mitigation telemetry data for a target MUST send a delete request
similar to the one depicted in Figure 37. similar to the one depicted in Figure 37.
8. DOTS Telemetry Mitigation Status Update 8. DOTS Telemetry Mitigation Status Update
8.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry 8.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry
Attributes Attributes
The mitigation efficacy telemetry attributes can be signaled from The mitigation efficacy telemetry attributes can be signaled from
DOTS clients to DOTS servers as part of the periodic mitigation DOTS clients to DOTS servers as part of the periodic mitigation
efficacy updates to the server (Section 5.3.4 of [RFC8782]). efficacy updates to the server (Section 6.3.4 of
[I-D.boucadair-dots-rfc8782-bis]).
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 (Section 10.1) augments the The "ietf-dots-telemetry" YANG module (Section 10.1) augments the
"mitigation-scope" message type defined in "ietf-dots-signal" 'mitigation-scope' message type defined in "ietf-dots-signal"
[I-D.boucadair-dots-rfc8782-yang-update] so that these attributes can [I-D.boucadair-dots-rfc8782-bis] so that these attributes can be
be signalled by a DOTS client in a mitigation efficacy update signalled by a DOTS client in a mitigation efficacy update
(Figure 44). (Figure 44).
augment-structure /signal:dots-signal/signal:message-type augment-structure /signal:dots-signal/signal:message-type
/signal:mitigation-scope/signal:scope: /signal:mitigation-scope/signal:scope:
+-- total-attack-traffic* [unit] +-- total-attack-traffic* [unit]
| +-- unit unit | +-- unit unit
| +-- low-percentile-g? yang:gauge64 | +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64 | +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64 | +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64 | +-- peak-g? yang:gauge64
skipping to change at page 60, line 42 skipping to change at page 61, line 42
} }
Figure 45: An Example of Mitigation Efficacy Update with Telemetry Figure 45: An Example of Mitigation Efficacy Update with Telemetry
Attributes Attributes
8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry 8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry
Attributes Attributes
The mitigation status telemetry attributes can be signaled from the The mitigation status telemetry attributes can be signaled from the
DOTS server to the DOTS client as part of the periodic mitigation DOTS server to the DOTS client as part of the periodic mitigation
status update (Section 5.3.3 of [RFC8782]). In particular, DOTS status update (Section 6.3.3 of [I-D.boucadair-dots-rfc8782-bis]).
clients can receive asynchronous notifications of the attack details In particular, DOTS clients can receive asynchronous notifications of
from DOTS servers using the Observe option defined in [RFC7641]. the attack details from DOTS servers using the Observe option defined
in [RFC7641].
In order to make use of this feature, DOTS clients MUST establish a In order to make use of this feature, DOTS clients MUST establish a
telemetry 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 of relevant countermeasures. A list of current operational status of relevant countermeasures. A list of
attacks detected by each countermeasure MAY also be included. The attacks detected by each countermeasure MAY also be included. The
same attributes defined in Section 7.1.5 are applicable for same attributes defined in Section 7.1.5 are applicable for
describing the attacks detected and mitigated at the DOTS server describing the attacks detected and mitigated at the DOTS server
domain. domain.
The "ietf-dots-telemetry" YANG module (Section 10.1) augments the The "ietf-dots-telemetry" YANG module (Section 10.1) augments the
"mitigation-scope" message type defined in "ietf-dots-signal" 'mitigation-scope' message type defined in "ietf-dots-signal"
[I-D.boucadair-dots-rfc8782-yang-update] with telemetry data as [I-D.boucadair-dots-rfc8782-bis] with telemetry data as depicted in
depicted in the following tree structure: the following tree structure:
augment-structure /signal:dots-signal/signal:message-type augment-structure /signal:dots-signal/signal:message-type
/signal:mitigation-scope/signal:scope: /signal:mitigation-scope/signal:scope:
+-- (direction)? +-- (direction)?
| +--:(server-to-client-only) | +--:(server-to-client-only)
| +-- total-traffic* [unit] | +-- total-traffic* [unit]
| | +-- unit unit | | +-- unit unit
| | +-- low-percentile-g? yang:gauge64 | | +-- low-percentile-g? yang:gauge64
| | +-- mid-percentile-g? yang:gauge64 | | +-- mid-percentile-g? yang:gauge64
| | +-- high-percentile-g? yang:gauge64 | | +-- high-percentile-g? yang:gauge64
skipping to change at page 64, line 27 skipping to change at page 65, line 27
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. Error Handling 9. Error Handling
This section is a summary of the Error Code responses that can be A list of common CoAP errors that are implemented by DOTS servers are
returned by a DOTS server. These error responses MUST contain a CoAP provided in Section 6 of [I-D.boucadair-dots-rfc8782-bis]. The
4.xx or 5.xx Response Code. following additional error cases apply for the telemetry extension:
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.
Errors returned by a DOTS server can be broken into two categories,
those associated with the CoAP protocol itself and those generated
during the validation of the provided data by the DOTS server.
The following list of common CoAP errors that are implemented by DOTS
servers. This list is not exhaustive, other errors defined by CoAP
and associated RFCs may be applicable.
o 4.00 (Bad Request) is returned by the DOTS server when the DOTS
client has sent a request that violates the DOTS protocol
[RFC8782].
o 4.01 (Unauthorized) is returned by the DOTS server when the DOTS
client is not authorized to access the DOTS server [RFC8782].
o 4.02 (Bad Option) is returned by the DOTS server when one or more
CoAP options are unknown or malformed by the CoAP protocol layer
[RFC7252].
o 4.04 (Not Found) is returned by the DOTS server when the DOTS
client is requesting a 'mid' or 'sid' that is not valid [RFC8782].
o 4.05 (Method Not Allowed) is returned by the DOTS server when the
DOTS client is requesting a resource by a method (GET etc.) that
is not supported by the DOTS server [RFC8782] [RFC7252].
o 4.08 (Request Entity Incomplete) is returned by the DOTS server if
one or multiple blocks of a block transfer request is missing
[RFC7959].
o 4.09 (Conflict) is returned by the DOTS server if the DOTS server
detects that a request conflicts with a previous request. The
response body is formatted using "application/dots+cbor", and
contains the "conflict-clause" [RFC8782].
o 4.13 (Request Entity Too Large) may be returned by the DOTS server
during a block transfer request [RFC7959].
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].
o 4.22 (Unprocessable Entity) is returned by the DOTS server when
one or more session configuration parameters are not valid
[RFC8782].
o 5.03 (Service Unavailable) is returned by the DOTS server if the
DOTS server is unable to handle the request. An example is the
DOTS server needs to redirect the DOTS client to use an alternate
DOTS server. The response body is formatted using "application/
dots+cbor", and contains how to handle the 5.03 code [RFC8782].
o 5.08 (Hop Limit Reached) is returned by the DOTS server if there
is a data path loop through upstream DOTS gateways. The response
body is formatted using plain text and contains a list of servers
that are in the data path loop [RFC8768].
The following additional error cases apply for the telemetry
extension:
o 4.00 (Bad Request) is returned by the DOTS server when the DOTS o 4.00 (Bad Request) is returned by the DOTS server when the DOTS
client has sent a request that violates the DOTS telemetry client has sent a request that violates the DOTS telemetry
extension. extension.
o 4.04 (Not Found) is returned by the DOTS server when the DOTS o 4.04 (Not Found) is returned by the DOTS server when the DOTS
client is requesting a 'tsid' or 'tmid' that is not valid. client is requesting a 'tsid' or 'tmid' that is not valid.
o 4.00 (Bad Request) is returned by the DOTS server when the DOTS o 4.00 (Bad Request) is returned by the DOTS server when the DOTS
client has sent a request with invalid query types (e.g., not client has sent a request with invalid query types (e.g., not
skipping to change at page 66, line 28 skipping to change at page 66, line 12
<CODE BEGINS> file "ietf-dots-telemetry@2020-07-03.yang" <CODE BEGINS> file "ietf-dots-telemetry@2020-07-03.yang"
module ietf-dots-telemetry { module ietf-dots-telemetry {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry"; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry";
prefix dots-telemetry; prefix dots-telemetry;
import ietf-dots-signal-channel { import ietf-dots-signal-channel {
prefix signal; prefix signal;
reference reference
"RFC UUUU: A YANG Data Model for Distributed Denial-of-Service "RFC UUUU: Distributed Denial-of-Service Open Threat Signaling
Open Threat Signaling (DOTS) Signal Channel"; (DOTS) Signal Channel Specification";
} }
import ietf-dots-data-channel { import ietf-dots-data-channel {
prefix ietf-data; prefix ietf-data;
reference reference
"RFC 8783: Distributed Denial-of-Service Open Threat "RFC 8783: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Data Channel Specification"; Signaling (DOTS) Data Channel Specification";
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
skipping to change at page 67, line 24 skipping to change at page 67, line 10
WG List: <mailto:dots@ietf.org> WG List: <mailto:dots@ietf.org>
Author: Mohamed Boucadair Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Author: Konda, Tirumaleswar Reddy Author: Konda, Tirumaleswar Reddy
<mailto:TirumaleswarReddy_Konda@McAfee.com>"; <mailto:TirumaleswarReddy_Konda@McAfee.com>";
description description
"This module contains YANG definitions for the signaling "This module contains YANG definitions for the signaling
of DOTS telemetry exchanged between a DOTS client and of DOTS telemetry exchanged between a DOTS client and
a DOTS server, by means of the DOTS signal channel. a DOTS server by means of the DOTS signal channel.
Copyright (c) 2020 IETF Trust and the persons identified as Copyright (c) 2020 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
skipping to change at page 99, line 9 skipping to change at page 98, line 43
| total-attack-traffic | list |TBA82 | 4 array | Array | | total-attack-traffic | list |TBA82 | 4 array | Array |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| total-attack- | | | | | | total-attack- | | | | |
| connection | container |TBA83 | 5 map | Object | | connection | container |TBA83 | 5 map | Object |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| attack-detail | list |TBA84 | 4 array | Array | | attack-detail | list |TBA84 | 4 array | Array |
+----------------------+-------------+------+---------------+--------+ +----------------------+-------------+------+---------------+--------+
12. IANA Considerations 12. IANA Considerations
12.1. A New Range for Comprehension-optional Parameters 12.1. DOTS Signal Channel CBOR Key Values
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 [Key-Map]. IANA "DOTS Signal Channel CBOR Key Values" registry [Key-Map].
The DOTS telemetry attributes defined in this specification are The DOTS telemetry attributes defined in this specification are
comprehension-optional parameters. comprehension-optional parameters.
o Note to the RFC Editor: CBOR keys are assigned from the 128-255 o Note to the RFC Editor: CBOR keys are assigned from the 128-255
range (Section 12.1). range.
+----------------------+-------+-------+------------+---------------+ +----------------------+-------+-------+------------+---------------+
| 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 102, line 14 skipping to change at page 101, line 22
| total-traffic | | | | | | total-traffic | | | | |
| ietf-dots-telemetry: | TBA82 | 0 | IESG | [RFCXXXX] | | ietf-dots-telemetry: | TBA82 | 0 | IESG | [RFCXXXX] |
| total-attack-traffic | | | | | | total-attack-traffic | | | | |
| ietf-dots-telemetry: | TBA83 | 0 | IESG | [RFCXXXX] | | ietf-dots-telemetry: | TBA83 | 0 | IESG | [RFCXXXX] |
| total-attack- | | | | | | total-attack- | | | | |
| connection | | | | | | connection | | | | |
| ietf-dots-telemetry: | TBA84 | 4 | IESG | [RFCXXXX] | | ietf-dots-telemetry: | TBA84 | 4 | IESG | [RFCXXXX] |
| attack-detail | | | | | | attack-detail | | | | |
+----------------------+-------+-------+------------+---------------+ +----------------------+-------+-------+------------+---------------+
12.3. DOTS Signal Channel Conflict Cause Codes 12.2. DOTS Signal Channel Conflict Cause Codes
This specification requests IANA to assign a new code from the "DOTS This specification requests IANA to assign a new code from the "DOTS
Signal Channel Conflict Cause Codes" registry [Cause]. Signal Channel Conflict Cause Codes" registry [Cause].
+------+-------------------+------------------------+-------------+ +------+-------------------+------------------------+-------------+
| Code | Label | Description | Reference | | Code | Label | Description | Reference |
+======+===================+========================+=============+ +======+===================+========================+=============+
| TBA | overlapping-pipes | Overlapping pipe scope | [RFCXXXX] | | TBA | overlapping-pipes | Overlapping pipe scope | [RFCXXXX] |
+------+-------------------+------------------------+-------------+ +------+-------------------+------------------------+-------------+
12.4. DOTS Signal Telemetry YANG Module 12.3. DOTS Signal Telemetry YANG Module
This document requests IANA to register the following URIs in the This document requests IANA to register the following URIs in the
"ns" subregistry within the "IETF XML Registry" [RFC3688]: "ns" subregistry within the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry URI: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-dots-mapping URI: urn:ietf:params:xml:ns:yang:ietf-dots-mapping
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG modules in This document requests IANA to register the following YANG modules in
the "YANG Module Names" subregistry [RFC7950] within the "YANG the "YANG Module Names" subregistry [RFC6020] within the "YANG
Parameters" registry. Parameters" registry.
name: ietf-dots-telemetry name: ietf-dots-telemetry
namespace: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry namespace: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry
maintained by IANA: N maintained by IANA: N
prefix: dots-telemetry prefix: dots-telemetry
reference: RFC XXXX reference: RFC XXXX
name: ietf-dots-mapping name: ietf-dots-mapping
namespace: urn:ietf:params:xml:ns:yang:ietf-dots-mapping namespace: urn:ietf:params:xml:ns:yang:ietf-dots-mapping
maintained by IANA: N maintained by IANA: N
prefix: dots-mapping prefix: dots-mapping
reference: RFC XXXX reference: RFC XXXX
13. Security Considerations 13. Security Considerations
13.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 12 of [I-D.boucadair-dots-rfc8782-bis]. The
security considerations that are specific to the DOTS signal channel following discusses the security considerations that are specific to
extension defined in this document. the DOTS signal channel 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
server domain to prevent data leakage. server domain to prevent data leakage.
DOTS clients are typically trusted devices by the DOTS client domain. DOTS clients are typically trusted devices by the DOTS client domain.
DOTS clients may be co-located on network security services (e.g., DOTS clients may be co-located on network security services (e.g.,
firewall) and a compromised security service potentially can do a lot firewall) and a compromised security service potentially can do a lot
skipping to change at page 103, line 46 skipping to change at page 102, line 46
held view that devices are untrusted, often referred to as the "zero- held view that devices are untrusted, often referred to as the "zero-
trust model". A compromised DOTS client can send fake DOTS telemetry trust model". A compromised DOTS client can send fake DOTS telemetry
data to a DOTS server to mislead the DOTS server. This attack can be data to a DOTS server to mislead the DOTS server. This attack can be
prevented by monitoring and auditing DOTS clients to detect prevented by monitoring and auditing DOTS clients to detect
misbehavior and to deter misuse, and by only authorizing the DOTS misbehavior and to deter misuse, and by only authorizing the DOTS
client to convey the DOTS telemetry for specific target resources client to convey the DOTS telemetry for specific target resources
(e.g., an application server is authorized to exchange DOTS telemetry (e.g., an application server is authorized to exchange DOTS telemetry
for its IP addresses but a DDoS mitigator can exchange DOTS telemetry for its IP addresses but a DDoS mitigator can exchange DOTS telemetry
for any target resource in the network). As a reminder, this is for any target resource in the network). As a reminder, this is
variation of dealing with compromised DOTS clients as discussed in variation of dealing with compromised DOTS clients as discussed in
Section 10 of [RFC8782]. Section 12 of [I-D.boucadair-dots-rfc8782-bis].
DOTS servers must be capable of defending themselves against DoS DOTS servers must be capable of defending themselves against DoS
attacks from compromised DOTS clients. The following non- attacks from compromised DOTS clients. The following non-
comprehensive list of mitigation techniques can be used by a DOTS comprehensive list of mitigation techniques can be used by a DOTS
server to handle misbehaving DOTS clients: server to handle misbehaving DOTS clients:
o The probing rate (defined in Section 4.5 of [RFC8782]) can be used o The probing rate (defined in Section 5.5 of
to limit the average data rate to the DOTS server. [I-D.boucadair-dots-rfc8782-bis]) can be used to limit the average
data rate to the DOTS server.
o Rate-limiting DOTS telemetry, including those with new 'tmid' o Rate-limiting DOTS telemetry, including those with new 'tmid'
values, from the same DOTS client defends against DoS attacks that values, from the same DOTS client defends against DoS attacks that
would result in varying the 'tmid' to exhaust DOTS server would result in varying the 'tmid' to exhaust DOTS server
resources. Likewise, the DOTS server can enforce a quota and 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
skipping to change at page 105, line 27 skipping to change at page 104, line 27
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.
Many thanks to Jan Lindblad for the yangdoctors review. Many thanks to Jan Lindblad for the yangdoctors review and Nagendra
Nainar for the opsdir review.
16. References 16. References
16.1. Normative 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.boucadair-dots-rfc8782-yang-update] [I-D.boucadair-dots-rfc8782-bis]
Boucadair, M. and J. Shallow, "A YANG Data Model for Boucadair, M., Ed., Shallow, J., and T. Reddy.K,
Distributed Denial-of-Service Open Threat Signaling (DOTS) "Distributed Denial-of-Service Open Threat Signaling
Signal Channel", draft-boucadair-dots-rfc8782-yang- (DOTS) Signal Channel Specification",
update-01 (work in progress), July 2020. <https://tools.ietf.org/html/draft-boucadair-dots-rfc8782-
bis-00>.
[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-07 (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>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[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 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
skipping to change at page 107, line 15 skipping to change at page 106, line 19
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>. 2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8768] Boucadair, M., Reddy.K, T., and J. Shallow, "Constrained [RFC8768] Boucadair, M., Reddy.K, T., and J. Shallow, "Constrained
Application Protocol (CoAP) Hop-Limit Option", RFC 8768, Application Protocol (CoAP) Hop-Limit Option", RFC 8768,
DOI 10.17487/RFC8768, March 2020, DOI 10.17487/RFC8768, March 2020,
<https://www.rfc-editor.org/info/rfc8768>. <https://www.rfc-editor.org/info/rfc8768>.
[RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P.,
Mortensen, A., and N. Teague, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel
Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020,
<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>.
[RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data [RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data
Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
June 2020, <https://www.rfc-editor.org/info/rfc8791>. June 2020, <https://www.rfc-editor.org/info/rfc8791>.
16.2. Informative References 16.2. Informative References
 End of changes. 82 change blocks. 
270 lines changed or deleted 199 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/