< draft-ietf-dots-telemetry-21.txt   draft-ietf-dots-telemetry-22.txt >
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Intended status: Standards Track T. Reddy.K, Ed. Intended status: Standards Track T. Reddy.K, Ed.
Expires: 7 August 2022 Akamai Expires: 7 August 2022 Akamai
E. Doron E. Doron
Radware Ltd. Radware Ltd.
M. Chen M. Chen
CMCC CMCC
J. Shallow J. Shallow
3 February 2022 3 February 2022
Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
draft-ietf-dots-telemetry-21 draft-ietf-dots-telemetry-22
Abstract Abstract
This document aims to enrich the DOTS signal channel protocol with This document aims to enrich the DOTS signal channel protocol with
various telemetry attributes, allowing for optimal Distributed various telemetry attributes, allowing for optimal Distributed
Denial-of-Service (DDoS) attack mitigation. It specifies the normal Denial-of-Service (DDoS) attack mitigation. It specifies the normal
traffic baseline and attack traffic telemetry attributes a DOTS traffic baseline and attack traffic telemetry attributes a DOTS
client can convey to its DOTS server in the mitigation request, the client can convey to its DOTS server in the mitigation request, the
mitigation status telemetry attributes a DOTS server can communicate mitigation status telemetry attributes a DOTS server can communicate
to a DOTS client, and the mitigation efficacy telemetry attributes a to a DOTS client, and the mitigation efficacy telemetry attributes a
skipping to change at page 2, line 22 skipping to change at page 2, line 22
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. DOTS Telemetry: Overview and Purpose . . . . . . . . . . . . 7 3. DOTS Telemetry: Overview and Purpose . . . . . . . . . . . . 7
3.1. Need More Visibility . . . . . . . . . . . . . . . . . . 7 3.1. Need More Visibility . . . . . . . . . . . . . . . . . . 7
3.2. Enhanced Detection . . . . . . . . . . . . . . . . . . . 8 3.2. Enhanced Detection . . . . . . . . . . . . . . . . . . . 8
3.3. Efficient Mitigation . . . . . . . . . . . . . . . . . . 10 3.3. Efficient Mitigation . . . . . . . . . . . . . . . . . . 10
4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Overview of Telemetry Operations . . . . . . . . . . . . 10 4.1. Overview of Telemetry Operations . . . . . . . . . . . . 11
4.2. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 12 4.2. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 12
4.3. DOTS Multi-homing Considerations . . . . . . . . . . . . 12 4.3. DOTS Multi-homing Considerations . . . . . . . . . . . . 13
4.4. YANG Considerations . . . . . . . . . . . . . . . . . . . 12 4.4. YANG Considerations . . . . . . . . . . . . . . . . . . . 13
5. Generic Considerations . . . . . . . . . . . . . . . . . . . 14 5. Generic Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. DOTS Client Identification . . . . . . . . . . . . . . . 14 5.1. DOTS Client Identification . . . . . . . . . . . . . . . 14
5.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . . . 14 5.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . . . 14 5.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . . . 15
5.4. Controlling Configuration Data . . . . . . . . . . . . . 14 5.4. Controlling Configuration Data . . . . . . . . . . . . . 15
5.5. Message Validation . . . . . . . . . . . . . . . . . . . 15 5.5. Message Validation . . . . . . . . . . . . . . . . . . . 15
5.6. A Note About Examples . . . . . . . . . . . . . . . . . . 15 5.6. A Note About Examples . . . . . . . . . . . . . . . . . . 15
6. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 15 6. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 16
7. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 16 7. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 17
7.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 17 7.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 17
7.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 18 7.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 18
7.1.2. Conveying DOTS Telemetry Configuration . . . . . . . 20 7.1.2. Conveying DOTS Telemetry Configuration . . . . . . . 20
7.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 23 7.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 24
7.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 24 7.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 25
7.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 24 7.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 25
7.2.1. Conveying DOTS Client Domain Pipe Capacity . . . . . 25 7.2.1. Conveying DOTS Client Domain Pipe Capacity . . . . . 26
7.2.2. Retrieve Installed DOTS Client Domain Pipe 7.2.2. Retrieve Installed DOTS Client Domain Pipe
Capacity . . . . . . . . . . . . . . . . . . . . . . 31 Capacity . . . . . . . . . . . . . . . . . . . . . . 32
7.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 31 7.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 32
7.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 31 7.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 32
7.3.1. Conveying DOTS Client Domain Baseline Information . . 34 7.3.1. Conveying DOTS Client Domain Baseline Information . . 35
7.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 38 7.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 39
7.3.3. Delete Installed Normal Traffic Baseline . . . . . . 38 7.3.3. Delete Installed Normal Traffic Baseline . . . . . . 39
7.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 38 7.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 39
7.5. Conflict with Other DOTS Clients of the Same Domain . . . 38 7.5. Conflict with Other DOTS Clients of the Same Domain . . . 39
8. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 39 8. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 40
8.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 41 8.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 42
8.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 42 8.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 43
8.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 43 8.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 44
8.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 45 8.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 46
8.1.4. Total Attack Connections . . . . . . . . . . . . . . 47 8.1.4. Total Attack Connections . . . . . . . . . . . . . . 48
8.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 49 8.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 50
8.1.6. Vendor Attack Mapping . . . . . . . . . . . . . . . . 52 8.1.6. Vendor Attack Mapping . . . . . . . . . . . . . . . . 53
8.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 56 8.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 57
8.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 59 8.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 60
9. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 64 9. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 65
9.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry 9.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry
Attributes . . . . . . . . . . . . . . . . . . . . . . . 64 Attributes . . . . . . . . . . . . . . . . . . . . . . . 65
9.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry 9.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry
Attributes . . . . . . . . . . . . . . . . . . . . . . . 66 Attributes . . . . . . . . . . . . . . . . . . . . . . . 67
10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 70 10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 71
11. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 71 11. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 72
11.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . 71 11.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . 72
11.2. Vendor Attack Mapping Details YANG Module . . . . . . . 101 11.2. Vendor Attack Mapping Details YANG Module . . . . . . . 102
12. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 105 12. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 106
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 108 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 109
13.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 108 13.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 109
13.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 110 13.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 111
13.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 111 13.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 112
14. Security Considerations . . . . . . . . . . . . . . . . . . . 111 14. Security Considerations . . . . . . . . . . . . . . . . . . . 112
14.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 112 14.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 113
14.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 113 14.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 114
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 114 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 115
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 114 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 115
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 114 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 115
17.1. Normative References . . . . . . . . . . . . . . . . . . 114 17.1. Normative References . . . . . . . . . . . . . . . . . . 115
17.2. Informative References . . . . . . . . . . . . . . . . . 116 17.2. Informative References . . . . . . . . . . . . . . . . . 117
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 119
1. Introduction 1. Introduction
IT organizations and service providers are facing Distributed Denial IT organizations and service providers are facing Distributed Denial
of Service (DDoS) attacks that fall into two broad categories: of Service (DDoS) attacks that fall into two broad categories:
1. Network/Transport layer attacks target the victim's 1. Network/Transport layer attacks target the victim's
infrastructure. These attacks are not necessarily aimed at infrastructure. These attacks are not necessarily aimed at
taking down the actual delivered services, but rather to prevent taking down the actual delivered services, but rather to prevent
various network elements (routers, switches, firewalls, transit various network elements (routers, switches, firewalls, transit
skipping to change at page 5, line 46 skipping to change at page 5, line 46
by DOTS clients to DOTS servers, and vice versa. The DOTS telemetry by DOTS clients to DOTS servers, and vice versa. The DOTS telemetry
attributes are not mandatory attributes of the DOTS signal channel attributes are not mandatory attributes of the DOTS signal channel
protocol [RFC9132]. When no limitation policy is provided to a DOTS protocol [RFC9132]. When no limitation policy is provided to a DOTS
agent, it can signal available telemetry attributes to it peers in agent, it can signal available telemetry attributes to it peers in
order to optimize the overall mitigation service provisioned using order to optimize the overall mitigation service provisioned using
DOTS. The aforementioned policy can be, for example, agreed during a DOTS. The aforementioned policy can be, for example, agreed during a
service subscription (that is out of scope) to identify a subset of service subscription (that is out of scope) to identify a subset of
DOTS clients among those deployed in a DOTS client domain that are DOTS clients among those deployed in a DOTS client domain that are
allowed to send or receive telemetry data. allowed to send or receive telemetry data.
Also, the document specifies a YANG module (Section 11.2) that
augments the DOTS data channel [RFC8783] with attack details
information. Sharing such details during 'idle' time is meant to
optimize the data exchanged over the DOTS signal channel.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The reader should be familiar with the terms defined in [RFC8612]. The reader should be familiar with the terms defined in [RFC8612].
skipping to change at page 7, line 9 skipping to change at page 7, line 18
split into multiple lines for display purposes only. When a line split into multiple lines for display purposes only. When a line
ends with backslash ('\') as the last character, the line is wrapped ends with backslash ('\') as the last character, the line is wrapped
for display purposes. It is considered to be joined to the next line for display purposes. It is considered to be joined to the next line
by deleting the backslash, the following line break, and the leading by deleting the backslash, the following line break, and the leading
whitespace of the next line. whitespace of the next line.
3. DOTS Telemetry: Overview and Purpose 3. DOTS Telemetry: Overview and Purpose
Timely and effective signaling of up-to-date DDoS telemetry to all Timely and effective signaling of up-to-date DDoS telemetry to all
elements involved in the mitigation process is essential and improves elements involved in the mitigation process is essential and improves
the overall DDoS mitigation service effectiveness. Bi-directional the overall DDoS mitigation service effectiveness. Bidirectional
feedback between DOTS agents is required for increased awareness by feedback between DOTS agents is required for increased awareness by
each party of the attack and mitigation efforts, supporting a each party of the attack and mitigation efforts, supporting a
superior and highly efficient attack mitigation service. superior and highly efficient attack mitigation service.
3.1. Need More Visibility 3.1. Need More Visibility
When signaling a mitigation request, it is most certainly beneficial When signaling a mitigation request, it is most certainly beneficial
for DOTS clients to signal to DOTS servers any knowledge regarding for DOTS clients to signal to DOTS servers any knowledge regarding
ongoing attacks. This can happen in cases where DOTS clients are ongoing attacks. This can happen in cases where DOTS clients are
asking DOTS servers for support in defending against attacks that asking DOTS servers for support in defending against attacks that
skipping to change at page 8, line 10 skipping to change at page 8, line 32
DOTS server's mitigation resources are seeing are those that a DOTS DOTS server's mitigation resources are seeing are those that a DOTS
client is asking for mitigation of. For the DOTS client side team, client is asking for mitigation of. For the DOTS client side team,
it is important to realize that the DOTS clients receive the required it is important to realize that the DOTS clients receive the required
service. For example, understanding that "I asked for mitigation of service. For example, understanding that "I asked for mitigation of
two attacks and my DOTS server detects and mitigates only one of two attacks and my DOTS server detects and mitigates only one of
them". Cases of inconsistency in attack classification between DOTS them". Cases of inconsistency in attack classification between DOTS
clients and servers can be highlighted, and maybe handled, using the clients and servers can be highlighted, and maybe handled, using the
DOTS telemetry attributes. DOTS telemetry attributes.
In addition, management and orchestration systems, at both DOTS In addition, management and orchestration systems, at both DOTS
client and server sides, can use DOTS telemetry as a feedback to client and server sides, can use DOTS telemetry as 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. The interface from the DOTS server to the decisions and actions. The interface from the DOTS server to the
mitigator to signal the telemetry data is out of scope. mitigator to signal the telemetry data is out of scope.
skipping to change at page 8, line 43 skipping to change at page 9, line 16
Statistical and artificial intelligence algorithms (e.g., machine Statistical and artificial intelligence algorithms (e.g., machine
learning) are used such that the actual traffic thresholds are learning) are used such that the actual traffic thresholds are
automatically calculated by learning the protected entity's normal automatically calculated by learning the protected entity's normal
traffic behavior during 'idle' time (i.e., no mitigation is active). traffic behavior during 'idle' time (i.e., no mitigation is active).
The normal traffic characterization learned is referred to as the The normal traffic characterization learned is referred to as the
"normal traffic baseline". An attack is detected when the victim's "normal traffic baseline". An attack is detected when the victim's
actual traffic is deviating from this normal baseline pattern. actual traffic is deviating from this normal baseline pattern.
In addition, subsequent activities toward mitigating an attack are In addition, subsequent activities toward mitigating an attack are
much more challenging. The ability to distinguish legitimate traffic much more challenging. The ability to distinguish legitimate traffic
from attacker traffic on a per packet basis is complex. For example, from attacker traffic on a per-packet basis is complex. For example,
a packet may look "legitimate" and no attack signature can be a packet may look "legitimate" and no attack signature can be
identified. The anomaly can be identified only after detailed identified. The anomaly can be identified only after detailed
statistical analysis. DDoS attack mitigators use the normal baseline statistical analysis. DDoS attack mitigators use the normal baseline
during the mitigation of an attack to identify and categorize the during the mitigation of an attack to identify and categorize the
expected appearance of a specific traffic pattern. Particularly, the expected appearance of a specific traffic pattern. Particularly, the
mitigators use the normal baseline to recognize the "level of mitigators use the normal baseline to recognize the "level of
normality" that needs to be achieved during the various mitigation normality" that needs to be achieved during the various mitigation
process. process.
Normal baseline calculation is performed based on continuous learning Normal baseline calculation is performed based on continuous learning
skipping to change at page 10, line 19 skipping to change at page 10, line 34
upstream so that DOTS client pipes return to a reasonable load level upstream so that DOTS client pipes return to a reasonable load level
(normal pattern, ideally). At this point, it is essential to ensure (normal pattern, ideally). At this point, it is essential to ensure
that the mitigator does not overwhelm the DOTS client pipes by that the mitigator does not overwhelm the DOTS client pipes by
sending back large volumes of "clean traffic", or what it believes is sending back large volumes of "clean traffic", or what it believes is
"clean". This can happen when the mitigator has not managed to "clean". This can happen when the mitigator has not managed to
detect and mitigate all the attacks launched towards the DOTS client detect and mitigate all the attacks launched towards the DOTS client
domain. domain.
In this case, it can be valuable to DOTS clients to signal to DOTS In this case, it can be valuable to DOTS clients to signal to DOTS
servers the total pipe capacity, which is the level of traffic the servers the total pipe capacity, which is the level of traffic the
DOTS client domain can absorb from its upstream network. Dynamic DOTS client domain can absorb from its upstream network. This
updates of the condition of pipes between DOTS agents while they are usually is the circuit size which includes all the packet overheads.
under a DDoS attack is essential (e.g., where multiple DOTS clients Dynamic updates of the condition of pipes between DOTS agents while
share the same physical connectivity pipes). The DOTS server should they are under a DDoS attack is essential (e.g., where multiple DOTS
activate other mechanisms to ensure it does not allow the DOTS client clients share the same physical connectivity pipes). The DOTS server
domain's pipes to be saturated unintentionally. The rate-limit should activate other mechanisms to ensure it does not allow the DOTS
action defined in [RFC8783] is a reasonable candidate to achieve this client domain's pipes to be saturated unintentionally. The rate-
objective; the DOTS client can indicate the type(s) of traffic (such limit action defined in [RFC8783] is a reasonable candidate to
as ICMP, UDP, TCP port number 80) it prefers to limit. The rate- achieve this objective; the DOTS client can indicate the type(s) of
limit action can be controlled via the signal channel [RFC9133] even traffic (such as ICMP, UDP, TCP port number 80) it prefers to limit.
when the pipe is overwhelmed. The rate-limit action can be controlled via the signal channel
[RFC9133] even when the pipe is overwhelmed.
4. Design Overview 4. Design Overview
4.1. Overview of Telemetry Operations 4.1. Overview of Telemetry Operations
The DOTS protocol suite is divided into two logical channels: the The DOTS protocol suite is divided into two logical channels: the
signal channel [RFC9132] and data channel [RFC8783]. This division signal channel [RFC9132] and data channel [RFC8783]. This division
is due to the vastly different requirements placed upon the traffic is due to the vastly different requirements placed upon the traffic
they carry. The DOTS signal channel must remain available and usable they carry. The DOTS signal channel must remain available and usable
even in the face of attack traffic that might, e.g., saturate one even in the face of attack traffic that might, e.g., saturate one
direction of the links involved, rendering acknowledgment-based direction of the links involved, rendering acknowledgment-based
mechanisms unreliable and strongly incentivizing messages to be small mechanisms unreliable and strongly incentivizing messages to be small
enough to be contained in a single IP packet (Section 2.2 of enough to be contained in a single IP packet (Section 2.2 of
skipping to change at page 88, line 51 skipping to change at page 89, line 51
leaf port { leaf port {
type inet:port-number; type inet:port-number;
description description
"Port number."; "Port number.";
} }
uses connection-all; uses connection-all;
} }
grouping attack-detail { grouping attack-detail {
description description
"Various details that describe the on-going "Various details that describe the ongoing
attacks that need to be mitigated by the DOTS server. attacks that need to be mitigated by the DOTS server.
The attack details need to cover well-known and common attacks The attack details need to cover well-known and common attacks
(such as a SYN Flood) along with new emerging or (such as a SYN Flood) along with new emerging or
vendor-specific attacks."; vendor-specific attacks.";
leaf vendor-id { leaf vendor-id {
type uint32; type uint32;
description description
"Vendor ID is a security vendor's Private Enterprise Number "Vendor ID is a security vendor's Private Enterprise Number
as registered with IANA."; as registered with IANA.";
reference reference
skipping to change at page 93, line 11 skipping to change at page 94, line 11
} }
grouping baseline { grouping baseline {
description description
"Grouping for the telemetry baseline."; "Grouping for the telemetry baseline.";
uses data-channel:target; uses data-channel:target;
leaf-list alias-name { leaf-list alias-name {
type string; type string;
description description
"An alias name that points to an IP resource. "An alias name that points to an IP resource.
An IP resource can be be a router, a host, An IP resource can be a router, a host,
an IoT object, a server, etc."; an IoT object, a server, etc.";
} }
list total-traffic-normal { list total-traffic-normal {
key "unit"; key "unit";
description description
"Total traffic normal baselines."; "Total traffic normal baselines.";
uses traffic-unit; uses traffic-unit;
} }
list total-traffic-normal-per-protocol { list total-traffic-normal-per-protocol {
key "unit protocol"; key "unit protocol";
skipping to change at page 112, line 13 skipping to change at page 113, line 13
14. Security Considerations 14. Security Considerations
14.1. DOTS Signal Channel Telemetry 14.1. DOTS Signal Channel Telemetry
The security considerations for the DOTS signal channel protocol are The security considerations for the DOTS signal channel protocol are
discussed in Section 11 of [RFC9132]. The following discusses the discussed in Section 11 of [RFC9132]. The following discusses the
security considerations that are specific to the DOTS signal channel security considerations that are specific to the DOTS signal channel
extension defined in this document. extension defined in this document.
The DOTS telemetry information includes DOTS client network topology, The DOTS telemetry information includes DOTS client network topology,
DOTS client domain pipe capacity, normal traffic baseline and DOTS client domain pipe capacity, normal traffic baseline and
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. Note that sharing this server domain to prevent data leakage. Note that sharing this
sensitive data with a trusted DOTS server does not introduce any new sensitive data with a trusted DOTS server does not introduce any new
significant considerations other that the need for the aforementioned significant considerations other that the need for the aforementioned
protection. Such a DOTS server is already trusted to have access to protection. Such a DOTS server is already trusted to have access to
that kind of information by being in the position to observe and that kind of information by being in the position to observe and
mitigate attacks. mitigate attacks.
DOTS clients are typically considered to be trusted devices by the DOTS clients are typically considered to be trusted devices by the
DOTS client domain. DOTS clients may be co-located on network DOTS client domain. DOTS clients may be co-located on network
skipping to change at page 114, line 33 skipping to change at page 115, line 33
implementation and interoperability work. implementation and interoperability work.
Many thanks to Jan Lindblad for the yangdoctors review, Nagendra Many thanks to Jan Lindblad for the yangdoctors review, Nagendra
Nainar for the opsdir review, James Gruessing for the artart review, Nainar for the opsdir review, James Gruessing for the artart review,
Michael Scharf for the tsv-art review, Ted Lemon for the int-dir Michael Scharf for the tsv-art review, Ted Lemon for the int-dir
review, and Robert Sparks for the gen-art review. review, and Robert Sparks for the gen-art review.
Thanks to Benjamin Kaduk for the detailed AD review. Thanks to Benjamin Kaduk for the detailed AD review.
Thanks to Roman Danyliw, Eric Vyncke, Francesca Palombini, Warren Thanks to Roman Danyliw, Eric Vyncke, Francesca Palombini, Warren
Kumari, and Erik Kline for the IESG review. Kumari, Erik Kline, Lars Eggert, and Robert Wilton for the IESG
review.
17. References 17. References
17.1. Normative References 17.1. Normative References
[Private-Enterprise-Numbers] [Private-Enterprise-Numbers]
"Private Enterprise Numbers", 4 May 2020, "Private Enterprise Numbers", 4 May 2020,
<https://www.iana.org/assignments/enterprise-numbers>. <https://www.iana.org/assignments/enterprise-numbers>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 End of changes. 20 change blocks. 
72 lines changed or deleted 78 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/