< draft-ietf-dots-telemetry-08.txt   draft-ietf-dots-telemetry-09.txt >
DOTS M. Boucadair, Ed. DOTS M. Boucadair, Ed.
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track T. Reddy, Ed. Intended status: Standards Track T. Reddy, Ed.
Expires: November 9, 2020 McAfee Expires: December 21, 2020 McAfee
E. Doron E. Doron
Radware Ltd. Radware Ltd.
M. Chen M. Chen
CMCC CMCC
J. Shallow J. Shallow
May 8, 2020 June 19, 2020
Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
draft-ietf-dots-telemetry-08 draft-ietf-dots-telemetry-09
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 November 9, 2020. This Internet-Draft will expire on December 21, 2020.
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 40 skipping to change at page 2, line 40
4.5. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 10 4.5. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 10
4.6. DOTS Multi-homing Considerations . . . . . . . . . . . . 10 4.6. DOTS Multi-homing Considerations . . . . . . . . . . . . 10
4.7. YANG Considerations . . . . . . . . . . . . . . . . . . . 11 4.7. YANG Considerations . . . . . . . . . . . . . . . . . . . 11
4.8. A Note About Examples . . . . . . . . . . . . . . . . . . 11 4.8. A Note About Examples . . . . . . . . . . . . . . . . . . 11
5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 11 5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 11
6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 12 6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 12
6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 13 6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 13
6.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 13 6.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 13
6.1.2. Convey DOTS Telemetry Configuration . . . . . . . . . 16 6.1.2. Convey DOTS Telemetry Configuration . . . . . . . . . 16
6.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 19 6.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 19
6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 20 6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 19
6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 20 6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 20
6.2.1. Convey DOTS Client Domain Pipe Capacity . . . . . . . 21 6.2.1. Convey DOTS Client Domain Pipe Capacity . . . . . . . 21
6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity . 27 6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity . 26
6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 27 6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 26
6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 27 6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 27
6.3.1. Convey DOTS Client Domain Baseline Information . . . 30 6.3.1. Convey DOTS Client Domain Baseline Information . . . 30
6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 33 6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 33
6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 33 6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 33
6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 33 6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 33
6.5. Conflict with Other DOTS Clients of the Same Domain . . . 33 6.5. Conflict with Other DOTS Clients of the Same Domain . . . 33
7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 34 7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 34
7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 36 7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 36
7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 36 7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 36
7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 38 7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 38
7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 39 7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 39
7.1.4. Total Attack Connections . . . . . . . . . . . . . . 41 7.1.4. Total Attack Connections . . . . . . . . . . . . . . 41
7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 42 7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 42
7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 48 7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 48
7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 51 7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 51
8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 56 8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 56
8.1. DOTS Clients to Servers Mitigation Efficacy DOTS 8.1. DOTS Clients to Servers Mitigation Efficacy DOTS
Telemetry Attributes . . . . . . . . . . . . . . . . . . 56 Telemetry Attributes . . . . . . . . . . . . . . . . . . 56
8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry 8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry
Attributes . . . . . . . . . . . . . . . . . . . . . . . 58 Attributes . . . . . . . . . . . . . . . . . . . . . . . 57
9. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 62 9. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 61
9.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . . 62 9.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . . 61
9.2. Vendor Attack Mapping Details YANG Module . . . . . . . . 89 9.2. Vendor Attack Mapping Details YANG Module . . . . . . . . 88
10. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 92 10. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 91
11. IANA Considerationsr . . . . . . . . . . . . . . . . . . . . 96 11. IANA Considerationsr . . . . . . . . . . . . . . . . . . . . 95
11.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 96 11.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 95
11.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 100 11.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 99
11.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 100 11.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 99
12. Security Considerations . . . . . . . . . . . . . . . . . . . 101 12. Security Considerations . . . . . . . . . . . . . . . . . . . 100
12.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 101 12.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 100
12.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 102 12.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 101
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 103 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 102
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 103 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 102
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 103 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 102
15.1. Normative References . . . . . . . . . . . . . . . . . . 103 15.1. Normative References . . . . . . . . . . . . . . . . . . 102
15.2. Informative References . . . . . . . . . . . . . . . . . 105 15.2. Informative References . . . . . . . . . . . . . . . . . 104
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 105
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 27 skipping to change at page 4, line 27
attacks. These attacks are assembled from dynamic attack vectors attacks. These attacks are assembled from dynamic attack vectors
(Network/Application) and tactics. As such, multiple attack vectors (Network/Application) and tactics. As such, multiple attack vectors
formed by multiple attack types and volumes are launched formed by multiple attack types and volumes are launched
simultaneously towards a victim. Multi-vector attacks are harder to simultaneously towards a victim. Multi-vector attacks are harder to
detect and defend. Multiple and simultaneous mitigation techniques detect and defend. Multiple and simultaneous mitigation techniques
are needed to defeat such attack campaigns. It is also common for are needed to defeat such attack campaigns. It is also common for
attackers to change attack vectors right after a successful attackers to change attack vectors right after a successful
mitigation, burdening their opponents with changing their defense mitigation, burdening their opponents with changing their defense
methods. methods.
The ultimate conclusion derived from these real scenarios is that The conclusion derived from these real scenarios is that modern
modern attacks detection and mitigation are most certainly attacks detection and mitigation are most certainly complicated and
complicated and highly convoluted tasks. They demand a comprehensive highly convoluted tasks. They demand a comprehensive knowledge of
knowledge of the attack attributes, the targeted normal behavior the attack attributes, the targeted normal behavior (including,
(including, normal traffic patterns), as well as the attacker's on- normal traffic patterns), as well as the attacker's on-going and past
going and past actions. Even more challenging, retrieving all the actions. Even more challenging, retrieving all the analytics needed
analytics needed for detecting these attacks is not simple to obtain for detecting these attacks is not simple to obtain with the
with the industry's current capabilities. industry's current capabilities.
The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is The DOTS signal channel protocol [RFC8782] is used to carry
used to carry information about a network resource or a network (or a information about a network resource or a network (or a part thereof)
part thereof) that is under a DDoS attack. Such information is sent that is under a DDoS attack. Such information is sent by a DOTS
by a DOTS client to one or multiple DOTS servers so that appropriate client to one or multiple DOTS servers so that appropriate mitigation
mitigation actions are undertaken on traffic deemed suspicious. actions are undertaken on traffic deemed suspicious. Various use
Various use cases are discussed in [I-D.ietf-dots-use-cases]. 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 9, line 6 skipping to change at page 9, line 6
the "total pipe capacity", which is the level of traffic the DOTS the "total pipe capacity", which is the level of traffic the DOTS
client domain can absorb from its upstream network. Dynamic updates client domain can absorb from its upstream network. Dynamic updates
of the condition of pipes between DOTS agents while they are under a of the condition of pipes between DOTS agents while they are under a
DDoS attack is essential (e.g., where multiple DOTS clients share the DDoS attack is essential (e.g., where multiple DOTS clients share the
same physical connectivity pipes). It is important to note that the same physical connectivity pipes). It is important to note that the
term "pipe" noted here does not necessary represent physical pipe, term "pipe" noted here does not necessary represent physical pipe,
but rather represents the maximum level of traffic that the DOTS but rather represents the maximum level of traffic that the DOTS
client domain can receive. The DOTS server should activate other client domain can receive. The DOTS server should activate other
mechanisms to ensure it does not allow the DOTS client domain's pipes mechanisms to ensure it does not allow the DOTS client domain's pipes
to be saturated unintentionally. The rate-limit action defined in to be saturated unintentionally. The rate-limit action defined in
[I-D.ietf-dots-data-channel] is a reasonable candidate to achieve [RFC8783] is a reasonable candidate to achieve this objective; the
this objective; the DOTS client can ask for the type(s) of traffic DOTS client can ask for the type(s) of traffic (such as ICMP, UDP,
(such as ICMP, UDP, TCP port number 80) it prefers to limit. The TCP port number 80) it prefers to limit. The rate-limit action can
rate-limit action can be controlled via the signal-channel be controlled via the signal-channel
[I-D.ietf-dots-signal-filter-control] even when the pipe is [I-D.ietf-dots-signal-filter-control] even when the pipe is
overwhelmed. overwhelmed.
To summarize: To summarize:
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 elements involved in the mitigation process is essential and
absolutely improves the overall DDoS mitigation service absolutely improves the overall DDoS mitigation service
effectiveness. Bi-directional feedback between DOTS agents is effectiveness. Bi-directional feedback between DOTS agents is
required for an increased awareness of each party, supporting required for an increased awareness of each party, supporting
superior and highly efficient attack mitigation service. superior and highly efficient attack mitigation service.
4. Generic Considerations 4. Generic Considerations
4.1. DOTS Client Identification 4.1. DOTS Client Identification
Following the rules in [I-D.ietf-dots-signal-channel], a unique Following the rules in Section 4.4.1 of [RFC8782], a unique
identifier is generated by a DOTS client to prevent request identifier is generated by a DOTS client to prevent request
collisions ('cuid'). collisions ('cuid').
As a reminder, [I-D.ietf-dots-signal-channel] forbids 'cuid' to be As a reminder, [RFC8782] forbids 'cuid' to be returned in a response
returned in a response message body. message body.
4.2. DOTS Gateways 4.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 [I-D.ietf-dots-signal-channel] must be considerations elaborated in Section 4.4.1 of [RFC8782] must be
followed. In particular, 'cdid' attribute is used to unambiguously followed. In particular, 'cdid' attribute is used to unambiguously
identify a DOTS client domain. identify a DOTS client domain.
As a reminder, [I-D.ietf-dots-signal-channel] forbids 'cdid' (if As a reminder, [RFC8782] forbids 'cdid' (if present) to be returned
present) to be returned in a response message body. in a response message body.
4.3. Empty URI Paths 4.3. Empty URI Paths
Uri-Path parameters and attributes with empty values MUST NOT be Uri-Path parameters and attributes with empty values MUST NOT be
present in a request and render an entire message invalid. present in a request and render an entire message invalid.
4.4. Controlling Configuration Data 4.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 [I-D.ietf-dots-signal-channel] for managing DOTS Section of 4.5.3 of [RFC8782] for managing DOTS telemetry
telemetry configuration freshness and notification. Likewise, a DOTS configuration freshness and notification. Likewise, a DOTS client
client may control the selection of configuration and non- may control the selection of configuration and non-configuration data
configuration data nodes when sending a GET request by means of the nodes when sending a GET request by means of the 'c' Uri-Query option
'c' Uri-Query option and following the procedure specified in and following the procedure specified in Section of 4.4.2 of
Section of 4.4.2 of [I-D.ietf-dots-signal-channel]. These [RFC8782]. These considerations are not re-iterated in the following
considerations are not re-iterated in the following sections. sections.
4.5. Block-wise Transfer 4.5. 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 recommendation detailed in Section 4.4.2 of [RFC8782] to control the
[I-D.ietf-dots-signal-channel] to control the size of a response when size of a response when the data to be returned does not fit within a
the data to be returned does not fit within a single datagram. single datagram.
DOTS clients can also use Block1 Option in a PUT request (see DOTS clients can also use CoAP Block1 Option in a PUT request (see
Section 2.5 of [RFC7959]) to initiate large transfers, but these Section 2.5 of [RFC7959]) to initiate large transfers, but these
Block1 transfers will fail if the inbound "pipe" is running full, so Block1 transfers will fail if the inbound "pipe" is running full, so
consideration needs to be made to try to fit this PUT into a single consideration needs to be made to try to fit this PUT into a single
transfer, or to separate out the PUT into several discrete PUTs where transfer, or to separate out the PUT into several discrete PUTs where
each of them fits into a single packet. each of them fits into a single packet.
Block3 and Block 4 options that are similar to the CoAP Block1 and Block3 and Block 4 Options that are similar to the CoAP Block1 and
Block2 options, but enable faster transmissions of big blocks of data Block2 Options, but enable faster transmissions of big blocks of data
with less packet interchanges, are defined in with less packet interchanges, are defined in
[I-D.bosh-core-new-block]. DOTS implementations can consider the use [I-D.bosh-core-new-block]. DOTS implementations can consider the use
of Block3 and Block 4 options. of Block3 and Block 4 Options.
4.6. DOTS Multi-homing Considerations 4.6. DOTS Multi-homing Considerations
Multi-homed DOTS clients are assumed to follow the recommendations in Multi-homed DOTS clients are assumed to follow the recommendations in
[I-D.ietf-dots-multihoming] to select which DOTS server to contact [I-D.ietf-dots-multihoming] to select which DOTS server to contact
and which IP prefixes to include in a telemetry message to a given and which IP prefixes to include in a telemetry message to a given
peer DOTS server. For example, if each upstream network exposes a peer DOTS server. For example, if each upstream network exposes a
DOTS server and the DOTS client maintains DOTS channels with all of DOTS server and the DOTS client maintains DOTS channels with all of
them, only the information related to prefixes assigned by an them, only the information related to prefixes assigned by an
upstream network to the DOTS client domain will be signaled via the upstream network to the DOTS client domain will be signaled via the
skipping to change at page 11, line 10 skipping to change at page 11, line 10
network. Considerations related to whether (and how) a DOTS client network. Considerations related to whether (and how) a DOTS client
gleans some telemetry information (e.g., attack details) it receives gleans some telemetry information (e.g., attack details) it receives
from a first DOTS server and share it with a second DOTS server are from a first DOTS server and share it with a second DOTS server are
implementation and deployment-specific. implementation and deployment-specific.
4.7. YANG Considerations 4.7. YANG Considerations
Telemetry messages exchanged between DOTS agents are serialized using Telemetry messages exchanged between DOTS agents are serialized using
Concise Binary Object Representation (CBOR). CBOR-encoded payloads Concise Binary Object Representation (CBOR). CBOR-encoded payloads
are used to carry signal channel-specific payload messages which are used to carry signal channel-specific payload messages which
convey request parameters and response information such as errors convey request parameters and response information such as errors.
[I-D.ietf-dots-signal-channel].
This document specifies a YANG module for representing DOTS telemetry This document specifies a YANG module for representing DOTS telemetry
message types (Section 9.1). All parameters in the payload of the message types (Section 9.1). All parameters in the payload of the
DOTS signal channel are mapped to CBOR types as specified in DOTS signal channel are mapped to CBOR types as specified in
Section 10. Section 10.
The DOTS telemetry module (Section 9.1) is not intended to be used The DOTS telemetry module (Section 9.1) is not intended to be used
via NETCONF/RESTCONF for DOTS server management purposes. It serves via NETCONF/RESTCONF for DOTS server management purposes. It serves
only to provide a data model and encoding, but not a management data only to provide a data model and encoding, but not a management data
model. DOTS servers are allowed to update the non-configurable 'ro' model. DOTS servers are allowed to update the non-configurable 'ro'
skipping to change at page 11, line 42 skipping to change at page 11, line 41
Examples are provided for illustration purposes. The document does Examples are provided for illustration purposes. The document does
not aim to provide a comprehensive list of message examples. not aim to provide a comprehensive list of message examples.
The authoritative reference for validating telemetry messages is the The authoritative reference for validating telemetry messages is the
YANG module (Section 9.1) and the mapping table established in YANG module (Section 9.1) and the mapping table established in
Section 10. Section 10.
5. Telemetry Operation Paths 5. Telemetry Operation Paths
As discussed in [I-D.ietf-dots-signal-channel], each DOTS operation As discussed in Section 4.2 of [RFC8782], each DOTS operation is
is indicated by a path-suffix that indicates the intended operation. indicated by a path-suffix that indicates the intended operation.
The operation path is appended to the path-prefix to form the URI The operation path is appended to the path-prefix to form the URI
used with a CoAP request to perform the desired DOTS operation. The used with a CoAP request to perform the desired DOTS operation. The
following telemetry path-suffixes are defined (Table 1): following telemetry path-suffixes are defined (Table 1):
+-----------------+----------------+-----------+ +-----------------+----------------+-----------+
| Operation | Operation Path | Details | | Operation | Operation Path | Details |
+-----------------+----------------+-----------+ +=================+================+===========+
| Telemetry Setup | /tm-setup | Section 6 | | Telemetry Setup | /tm-setup | Section 6 |
| Telemetry | /tm | Section 7 | | Telemetry | /tm | Section 7 |
+-----------------+----------------+-----------+ +-----------------+----------------+-----------+
Table 1: DOTS Telemetry Operations Table 1: DOTS Telemetry Operations
Consequently, the "ietf-dots-telemetry" YANG module defined in Consequently, the "ietf-dots-telemetry" YANG module defined in
Section 9.1 augments the "ietf-dots-signal" with two new message Section 9.1 augments the "ietf-dots-signal" with two new message
types called "telemetry-setup" and "telemetry". The tree structure types called "telemetry-setup" and "telemetry". The tree structure
is shown in Figure 1 (more details are provided in the following is shown in Figure 1 (more details are provided in the following
sections about the exact structure of "telemetry-setup" and sections about the exact structure of "telemetry-setup" and
"telemetry" message types). "telemetry" message types).
augment /ietf-signal:dots-signal/ietf-signal:message-type: augment /ietf-signal:dots-signal/ietf-signal:message-type:
+--:(telemetry-setup) {dots-telemetry}? +--:(telemetry-setup) {dots-telemetry}?
skipping to change at page 17, line 7 skipping to change at page 17, line 7
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 The procedure specified in Section 4.4.1 of [RFC8782] MUST be
[I-D.ietf-dots-signal-channel] MUST be followed for 'tsid' followed for 'tsid' rollover.
rollover.
This is a mandatory attribute. This is a mandatory attribute.
'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
skipping to change at page 27, line 9 skipping to change at page 26, line 41
} }
} }
Figure 17: Example of a PUT Request to Convey Pipe Information Figure 17: Example of a PUT Request to Convey Pipe Information
(Multi-Homed) (Multi-Homed)
6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity 6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity
A GET request with 'tsid' Uri-Path parameter is used to retrieve a A GET request with 'tsid' Uri-Path parameter is used to retrieve a
specific installed DOTS client domain pipe related information. The specific installed DOTS client domain pipe related information. The
same procedure as defined in (Section 6.1.3) is followed. same procedure as defined in Section 6.1.3 is followed.
To retrieve all pipe information bound to a DOTS client, the DOTS To retrieve all pipe information bound to a DOTS client, the DOTS
client proceeds as specified in Section 6.1.1. client proceeds as specified in Section 6.1.1.
6.2.3. Delete Installed DOTS Client Domain Pipe Capacity 6.2.3. Delete Installed DOTS Client Domain Pipe Capacity
A DELETE request is used to delete the installed DOTS client domain A DELETE request is used to delete the installed DOTS client domain
pipe related information. The same procedure as defined in pipe related information. The same procedure as defined in
(Section 6.1.4) is followed. Section 6.1.4 is followed.
6.3. Telemetry Baseline 6.3. Telemetry Baseline
A DOTS client can communicate to its server(s) its normal traffic A DOTS client can communicate to its server(s) its normal traffic
baseline and connections capacity: baseline and connections capacity:
Total traffic normal baseline: The percentile values representing Total traffic normal baseline: The percentile values representing
the total traffic normal baseline. It can be represented for a the total traffic normal baseline. It can be represented for a
target using 'total-traffic-normal'. target using 'total-traffic-normal'.
skipping to change at page 33, line 9 skipping to change at page 33, line 9
Figure 20: PUT to Convey the DOTS Traffic Baseline (2) Figure 20: PUT to Convey the DOTS Traffic Baseline (2)
The traffic baseline information should be updated to reflect The traffic baseline information should be updated to reflect
legitimate overloads (e.g., flash crowds) to prevent unnecessary legitimate overloads (e.g., flash crowds) to prevent unnecessary
mitigation. mitigation.
6.3.2. Retrieve Installed Normal Traffic Baseline 6.3.2. Retrieve Installed Normal Traffic Baseline
A GET request with 'tsid' Uri-Path parameter is used to retrieve a A GET request with 'tsid' Uri-Path parameter is used to retrieve a
specific installed DOTS client domain baseline traffic information. specific installed DOTS client domain baseline traffic information.
The same procedure as defined in (Section 6.1.3) is followed. The same procedure as defined in Section 6.1.3 is followed.
To retrieve all baseline information bound to a DOTS client, the DOTS To retrieve all baseline information bound to a DOTS client, the DOTS
client proceeds as specified in Section 6.1.1. client proceeds as specified in Section 6.1.1.
6.3.3. Delete Installed Normal Traffic Baseline 6.3.3. Delete Installed Normal Traffic Baseline
A DELETE request is used to delete the installed DOTS client domain A DELETE request is used to delete the installed DOTS client domain
normal traffic baseline. The same procedure as defined in normal traffic baseline. The same procedure as defined in
(Section 6.1.4) is followed. Section 6.1.4 is followed.
6.4. Reset Installed Telemetry Setup 6.4. Reset Installed Telemetry Setup
Upon bootstrapping (or reboot or any other event that may alter the Upon bootstrapping (or reboot or any other event that may alter the
DOTS client setup), a DOTS client MAY send a DELETE request to set DOTS client setup), a DOTS client MAY send a DELETE request to set
the telemetry parameters to default values. Such a request does not the telemetry parameters to default values. Such a request does not
include any 'tsid'. An example of such request is depicted in include any 'tsid'. An example of such request is depicted in
Figure 21. Figure 21.
Header: DELETE (Code=0.04) Header: DELETE (Code=0.04)
skipping to change at page 33, line 42 skipping to change at page 33, 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 [I-D.ietf-dots-signal-channel]. The conflict cause Section 4.4.1 of [RFC8782]. The conflict cause can be set to one of
can be set to one of these values: these values:
1: Overlapping targets (already defined in 1: Overlapping targets (Section 4.4.1 of [RFC8782]).
[I-D.ietf-dots-signal-channel]).
TBA: Overlapping pipe scope (see Section 11). TBA: Overlapping pipe scope (see Section 11).
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
skipping to change at page 44, line 49 skipping to change at page 44, line 49
| ... | ...
+--rw high-percentile-l* [protocol] +--rw high-percentile-l* [protocol]
| ... | ...
+--rw peak-l* [protocol] +--rw peak-l* [protocol]
... ...
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
[I-D.ietf-dots-data-channel] to exchange vendor-specific attack [RFC8783] to exchange vendor-specific attack mapping details (that
mapping details (that is, {vendor identifier, attack identifier} ==> is, {vendor identifier, attack identifier} ==> attack name). As
attack name). As such, DOTS agents do not have to convey such, DOTS agents do not have to convey systematically an attack name
systematically an attack name in their telemetry messages over the in their telemetry messages over the DOTS signal channel. The "ietf-
DOTS signal channel. The "ietf-dots-mapping" YANG module defined in dots-mapping" YANG module defined in Section 9.2) augments the "ietf-
Section 9.2) augments the "ietf-dots-data-channel". The tree dots-data-channel". The tree structure of this module is shown in
structure of this module is shown in Figure 30. Figure 30.
module: ietf-dots-mapping module: ietf-dots-mapping
augment /ietf-data:dots-data/ietf-data:dots-client: augment /ietf-data:dots-data/ietf-data:dots-client:
+--rw vendor-mapping {dots-telemetry}? +--rw vendor-mapping {dots-telemetry}?
+--rw vendor* [vendor-id] +--rw vendor* [vendor-id]
+--rw vendor-id uint32 +--rw vendor-id uint32
+--rw attack-mapping* [attack-id] +--rw attack-mapping* [attack-id]
+--rw attack-id uint32 +--rw attack-id uint32
+--rw attack-name string +--rw attack-name string
augment /ietf-data:dots-data/ietf-data:capabilities: augment /ietf-data:dots-data/ietf-data:capabilities:
skipping to change at page 45, line 29 skipping to change at page 45, line 29
+--ro vendor-mapping {dots-telemetry}? +--ro vendor-mapping {dots-telemetry}?
+--ro vendor* [vendor-id] +--ro vendor* [vendor-id]
+--ro vendor-id uint32 +--ro vendor-id uint32
+--ro attack-mapping* [attack-id] +--ro attack-mapping* [attack-id]
+--ro attack-id uint32 +--ro attack-id uint32
+--ro attack-name string +--ro attack-name string
Figure 30: Vendor Attack Mapping Tree Structure Figure 30: Vendor Attack Mapping Tree Structure
A DOTS client sends a GET request to retrieve the capabilities A DOTS client sends a GET request to retrieve the capabilities
supported by a DOTS server as per Section 7.1 of supported by a DOTS server as per Section 7.1 of [RFC8783]. This
[I-D.ietf-dots-data-channel]. This request is meant to assess request is meant to assess whether vendor attack mapping details
whether vendor attack mapping details feature is supported by the feature is supported by the server (i.e., check the value of 'vendor-
server (i.e., check the value of 'vendor-mapping-enabled'). mapping-enabled').
If 'vendor-mapping-enabled' is set to 'true', A DOTS client MAY send If 'vendor-mapping-enabled' is set to 'true', A DOTS client MAY send
a GET request to retrieve the DOTS server's vendor attack mapping a GET request to retrieve the DOTS server's vendor attack mapping
details. An example of such GET request is shown in Figure 31. details. An example of such GET request is shown in Figure 31.
GET /restconf/data/ietf-dots-data-channel:dots-data\ GET /restconf/data/ietf-dots-data-channel:dots-data\
/ietf-dots-mapping:vendor-mapping HTTP/1.1 /ietf-dots-mapping:vendor-mapping HTTP/1.1
Host: example.com Host: example.com
Accept: application/yang-data+json Accept: application/yang-data+json
skipping to change at page 47, line 7 skipping to change at page 47, line 7
The DOTS client reiterates the above procedure regularly (e.g., once The DOTS client reiterates the above procedure regularly (e.g., once
a week) to update the DOTS server's vendor attack mapping details. a week) to update the DOTS server's vendor attack mapping details.
If the DOTS client concludes that the DOTS server does not have any If the DOTS client concludes that the DOTS server does not have any
reference to the specific vendor attack mapping details, the DOTS reference to the specific vendor attack mapping details, the DOTS
client uses a POST request to install its vendor attack mapping client uses a POST request to install its vendor attack mapping
details. An example of such POST request is depicted in Figure 34. details. An example of such POST request is depicted in Figure 34.
POST /restconf/data/ietf-dots-data-channel:dots-data\ POST /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1 /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
Host: {host}:{port} Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-mapping:vendor-mapping": { "ietf-dots-mapping:vendor-mapping": {
"ietf-dots-mapping:vendor": [ "ietf-dots-mapping:vendor": [
{ {
"ietf-dots-mapping:vendor-id": 345, "ietf-dots-mapping:vendor-id": 345,
"ietf-dots-mapping:attack-mapping": [ "ietf-dots-mapping:attack-mapping": [
{ {
"ietf-dots-mapping:attack-id": 1, "ietf-dots-mapping:attack-id": 1,
skipping to change at page 47, line 48 skipping to change at page 47, line 48
attribute or contains an invalid or unknown parameter, "400 Bad attribute or contains an invalid or unknown parameter, "400 Bad
Request" status-line MUST be returned by the DOTS server in the Request" status-line MUST be returned by the DOTS server in the
response. The error-tag is set to "missing-attribute", "invalid- response. The error-tag is set to "missing-attribute", "invalid-
value", or "unknown-element" as a function of the encountered error. value", or "unknown-element" as a function of the encountered error.
If the request is received via a server-domain DOTS gateway, but the If the request is received via a server-domain DOTS gateway, but the
DOTS server does not maintain a 'cdid' for this 'cuid' while a 'cdid' DOTS server does not maintain a 'cdid' for this 'cuid' while a 'cdid'
is expected to be supplied, the DOTS server MUST reply with "403 is expected to be supplied, the DOTS server MUST reply with "403
Forbidden" status-line and the error-tag "access-denied". Upon Forbidden" status-line and the error-tag "access-denied". Upon
receipt of this message, the DOTS client MUST register (Section 5.1 receipt of this message, the DOTS client MUST register (Section 5.1
of [I-D.ietf-dots-data-channel]). of [RFC8783]).
The DOTS client uses the PUT request to modify its vendor attack The DOTS client uses the PUT request to modify its vendor attack
mapping details maintained by the DOTS server (e.g., add a new mapping details maintained by the DOTS server (e.g., add a new
mapping). mapping).
A DOTS client uses a GET request to retrieve its vendor attack A DOTS client uses a GET request to retrieve its vendor attack
mapping details as maintained by the DOTS server (Figure 35). mapping details as maintained by the DOTS server (Figure 35).
GET /restconf/data/ietf-dots-data-channel:dots-data\ GET /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw\ /dots-client=dz6pHjaADkaFTbjr0JGBpw\
skipping to change at page 50, line 5 skipping to change at page 50, 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 The procedure specified in Section 4.4.1 of [RFC8782] MUST be
[I-D.ietf-dots-signal-channel] MUST be followed for 'tmid' followed for 'tmid' rollover.
rollover.
This is a mandatory attribute. This is a mandatory attribute.
'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.
skipping to change at page 54, line 26 skipping to change at page 54, 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 considerations as in Section 4.4.2.1 of [RFC8782]. An example of a
[I-D.ietf-dots-signal-channel]. An example of a pre-or-ongoing- pre-or-ongoing-mitigation telemetry notification is shown in
mitigation telemetry notification is shown in Figure 43. Figure 43.
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [ "pre-or-ongoing-mitigation": [
{ {
"tmid": 123, "tmid": 123,
"target": { "target": {
"target-prefix": [ "target-prefix": [
"2001:db8::1/128" "2001:db8::1/128"
] ]
skipping to change at page 56, line 21 skipping to change at page 56, 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 efficacy updates to the server (Section 5.3.4 of [RFC8782]).
[I-D.ietf-dots-signal-channel]).
Total Attack Traffic: The overall attack traffic as observed from Total Attack Traffic: The overall attack traffic as observed from
the DOTS client perspective during an active mitigation. See the DOTS client perspective during an active mitigation. See
Figure 27. Figure 27.
Attack Details: The overall attack details as observed from the Attack Details: The overall attack details as observed from the
DOTS client perspective during an active mitigation. See DOTS client perspective during an active mitigation. See
Section 7.1.5. Section 7.1.5.
The "ietf-dots-telemetry" YANG module augments the "mitigation-scope" The "ietf-dots-telemetry" YANG module augments the "mitigation-scope"
skipping to change at page 58, line 42 skipping to change at page 57, line 46
} }
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 [I-D.ietf-dots-signal-channel]). In status update (Section 5.3.3 of [RFC8782]). In particular, DOTS
particular, DOTS clients can receive asynchronous notifications of clients can receive asynchronous notifications of the attack details
the attack details from DOTS servers using the Observe option defined from DOTS servers using the Observe option defined in [RFC7641].
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
skipping to change at page 62, line 40 skipping to change at page 61, line 40
<CODE BEGINS> file "ietf-dots-telemetry@2020-05-04.yang" <CODE BEGINS> file "ietf-dots-telemetry@2020-05-04.yang"
module ietf-dots-telemetry { module ietf-dots-telemetry {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry"; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry";
prefix dots-telemetry; prefix dots-telemetry;
import ietf-dots-signal-channel { import ietf-dots-signal-channel {
prefix ietf-signal; prefix ietf-signal;
reference reference
"RFC SSSS: Distributed Denial-of-Service Open Threat "RFC 8782: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
} }
import ietf-dots-data-channel { import ietf-dots-data-channel {
prefix ietf-data; prefix ietf-data;
reference reference
"RFC DDDD: 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
"Section 3 of RFC 6991"; "Section 3 of RFC 6991";
} }
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
skipping to change at page 90, line 4 skipping to change at page 89, line 4
<CODE BEGINS> file "ietf-dots-mapping@2020-05-04.yang" <CODE BEGINS> file "ietf-dots-mapping@2020-05-04.yang"
module ietf-dots-mapping { module ietf-dots-mapping {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-mapping"; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-mapping";
prefix dots-mapping; prefix dots-mapping;
import ietf-dots-data-channel { import ietf-dots-data-channel {
prefix ietf-data; prefix ietf-data;
reference reference
"RFC DDDD: Distributed Denial-of-Service Open Threat "RFC 8783: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Data Channel Specification"; Signaling (DOTS) Data Channel Specification";
} }
organization organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group"; "IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/dots/> "WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org> WG List: <mailto:dots@ietf.org>
Author: Mohamed Boucadair Author: Mohamed Boucadair
skipping to change at page 92, line 35 skipping to change at page 91, line 35
All DOTS telemetry parameters in the payload of the DOTS signal All DOTS telemetry parameters in the payload of the DOTS signal
channel MUST be mapped to CBOR types as shown in the following table: channel MUST be mapped to CBOR types as shown in the following table:
o Implementers may use the values in: https://github.com/boucadair/ o Implementers may use the values in: https://github.com/boucadair/
draft-dots-telemetry/blob/master/mapping-table.txt draft-dots-telemetry/blob/master/mapping-table.txt
+----------------------+-------------+------+---------------+--------+ +----------------------+-------------+------+---------------+--------+
| Parameter Name | YANG | CBOR | CBOR Major | JSON | | Parameter Name | YANG | CBOR | CBOR Major | JSON |
| | Type | Key | Type & | Type | | | Type | Key | Type & | Type |
| | | | Information | | | | | | Information | |
+----------------------+-------------+------+---------------+--------+ +======================+=============+======+===============+========+
| tsid | uint32 |TBA1 | 0 unsigned | Number | | tsid | uint32 |TBA1 | 0 unsigned | Number |
| telemetry | container |TBA2 | 5 map | Object | | telemetry | container |TBA2 | 5 map | Object |
| low-percentile | decimal64 |TBA3 | 6 tag 4 | | | low-percentile | decimal64 |TBA3 | 6 tag 4 | |
| | | | [-2, integer]| String | | | | | [-2, integer]| String |
| mid-percentile | decimal64 |TBA4 | 6 tag 4 | | | mid-percentile | decimal64 |TBA4 | 6 tag 4 | |
| | | | [-2, integer]| String | | | | | [-2, integer]| String |
| high-percentile | decimal64 |TBA5 | 6 tag 4 | | | high-percentile | decimal64 |TBA5 | 6 tag 4 | |
| | | | [-2, integer]| String | | | | | [-2, integer]| String |
| unit-config | list |TBA6 | 4 array | Array | | unit-config | list |TBA6 | 4 array | Array |
| unit | enumeration |TBA7 | 0 unsigned | String | | unit | enumeration |TBA7 | 0 unsigned | String |
skipping to change at page 96, line 41 skipping to change at page 95, line 41
11.1. DOTS Signal Channel CBOR Key Values 11.1. DOTS Signal Channel CBOR Key Values
This specification registers the DOTS telemetry attributes in the This specification registers the DOTS telemetry attributes in the
IANA "DOTS Signal Channel CBOR Key Values" registry available at IANA "DOTS Signal Channel CBOR Key Values" registry available at
https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel- https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel-
cbor-key-values. cbor-key-values.
The DOTS telemetry attributes defined in this specification are The DOTS telemetry attributes defined in this specification are
comprehension-optional parameters. comprehension-optional parameters.
o Note to the RFC Editor: (1) CBOR keys are assigned from the o Note to the RFC Editor: CBOR keys are assigned from the
32768-49151 range. (2) Please assign the following suggested 32768-49151 range.
values.
+----------------------+-------+-------+------------+---------------+ +----------------------+-------+-------+------------+---------------+
| Parameter Name | CBOR | CBOR | Change | Specification | | Parameter Name | CBOR | CBOR | Change | Specification |
| | Key | Major | Controller | Document(s) | | | Key | Major | Controller | Document(s) |
| | Value | Type | | | | | Value | Type | | |
+----------------------+-------+-------+------------+---------------+ +======================+=======+=======+============+===============+
| tsid | TBA1 | 0 | IESG | [RFCXXXX] | | tsid | TBA1 | 0 | IESG | [RFCXXXX] |
| telemetry | TBA2 | 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] |
| high-percentile | TBA5 | 6tag4 | IESG | [RFCXXXX] | | high-percentile | TBA5 | 6tag4 | IESG | [RFCXXXX] |
| unit-config | TBA6 | 4 | IESG | [RFCXXXX] | | unit-config | TBA6 | 4 | IESG | [RFCXXXX] |
| unit | TBA7 | 0 | IESG | [RFCXXXX] | | unit | TBA7 | 0 | IESG | [RFCXXXX] |
| unit-status | TBA8 | 7 | IESG | [RFCXXXX] | | unit-status | TBA8 | 7 | IESG | [RFCXXXX] |
| total-pipe-capability| TBA9 | 4 | IESG | [RFCXXXX] | | total-pipe-capability| TBA9 | 4 | IESG | [RFCXXXX] |
| link-id | TBA10 | 3 | IESG | [RFCXXXX] | | link-id | TBA10 | 3 | IESG | [RFCXXXX] |
skipping to change at page 100, line 38 skipping to change at page 99, line 37
| vendor-id | | | | | | vendor-id | | | | |
+----------------------+-------+-------+------------+---------------+ +----------------------+-------+-------+------------+---------------+
11.2. DOTS Signal Channel Conflict Cause Codes 11.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 available at Signal Channel Conflict Cause Codes" registry available at
https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel- https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel-
conflict-cause-codes. conflict-cause-codes.
Code Label Description Reference +------+-------------------+------------------------+-------------+
TBA overlapping-pipes Overlapping pipe scope [RFCXXXX] | Code | Label | Description | Reference |
+======+===================+========================+=============+
| TBA | overlapping-pipes | Overlapping pipe scope | [RFCXXXX] |
+------+-------------------+------------------------+-------------+
11.3. DOTS Signal Telemetry YANG Module 11.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.
skipping to change at page 101, line 33 skipping to change at page 100, line 33
name: ietf-dots-mapping name: ietf-dots-mapping
namespace: urn:ietf:params:xml:ns:yang:ietf-dots-mapping namespace: urn:ietf:params:xml:ns:yang:ietf-dots-mapping
maintained by IANA: N maintained by IANA: N
prefix: dots-mapping prefix: dots-mapping
reference: RFC XXXX reference: RFC XXXX
12. Security Considerations 12. Security Considerations
12.1. DOTS Signal Channel Telemetry 12.1. DOTS Signal Channel Telemetry
Security considerations in Section 10 of The security considerations for the DOTS signal channel protocol are
[I-D.ietf-dots-signal-channel] need to be taken into consideration. discussed in Section 10 of [RFC8782]. The following discusses the
security considerations that are specific to 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 102, line 7 skipping to change at page 101, line 9
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 [I-D.ietf-dots-signal-channel]. Section 10 of [RFC8782].
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 o The probing rate (defined in Section 4.5 of [RFC8782]) can be used
[I-D.ietf-dots-signal-channel]) can be used to limit the average to limit the average data rate to the DOTS server.
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
by a DOTS client domain. by a DOTS client domain.
12.2. Vendor Attack Mapping 12.2. Vendor Attack Mapping
Security considerations in Section 10 of [I-D.ietf-dots-data-channel] The security considerations for the DOTS data channel protocol are
need to be taken into consideration. discussed in Section 10 of [RFC8783]. The following discusses the
security considerations that are specific to the DOTS data channel
extension defined in this document.
All data nodes defined in the YANG module specified in Section 9.2 All data nodes defined in the YANG module specified in Section 9.2
which can be created, modified, and deleted (i.e., config true, which which can be created, modified, and deleted (i.e., config true, which
is the default) are considered sensitive. Write operations to these is the default) are considered sensitive. Write operations to these
data nodes without proper protection can have a negative effect on data nodes without proper protection can have a negative effect on
network operations. Appropriate security measures are recommended to network operations. Appropriate security measures are recommended to
prevent illegitimate users from invoking DOTS data channel primitives prevent illegitimate users from invoking DOTS data channel primitives
as discussed in [I-D.ietf-dots-data-channel]. Nevertheless, an as discussed in [RFC8783]. Nevertheless, an attacker who can access
attacker who can access a DOTS client is technically capable of a DOTS client is technically capable of undertaking various attacks,
undertaking various attacks, such as: such as:
o Communicating invalid attack mapping details to the server o Communicating invalid attack mapping details to the server
('/ietf-data:dots-data/ietf-data:dots-client/dots- ('/ietf-data:dots-data/ietf-data:dots-client/dots-
telemetry:vendor-mapping'), which will mislead the server when telemetry:vendor-mapping'), which will mislead the server when
correlating attack details. correlating attack details.
Some of the readable data nodes in the YANG module specified in Some of the readable data nodes in the YANG module specified in
Section 9.2 may be considered sensitive. It is thus important to Section 9.2 may be considered sensitive. It is thus important to
control read access to these data nodes. These are the data nodes control read access to these data nodes. These are the data nodes
and their sensitivity: and their sensitivity:
skipping to change at page 103, line 22 skipping to change at page 102, line 25
by a compromised DOTS client to leak the attack detection by a compromised DOTS client to leak the attack detection
capabilities of the DOTS server. This is a variation of the capabilities of the DOTS server. This is a variation of the
compromised DOTS client attacks discussed in Section 12.1. compromised DOTS client attacks discussed in Section 12.1.
13. Contributors 13. Contributors
The following individuals have contributed to this document: The following individuals have contributed to this document:
o Li Su, CMCC, Email: suli@chinamobile.com o Li Su, CMCC, Email: suli@chinamobile.com
o Jin Peng, CMCC, Email: pengjin@chinamobile.com
o Pan Wei, Huawei, Email: william.panwei@huawei.com o Pan Wei, Huawei, Email: william.panwei@huawei.com
14. Acknowledgements 14. Acknowledgements
The authors would like to thank Flemming Andreasen, Liang Xia, and The authors would like to thank Flemming Andreasen, Liang Xia, and
Kaname Nishizuka co-authors of [I-D.doron-dots-telemetry] and Kaname Nishizuka co-authors of [I-D.doron-dots-telemetry] and
everyone who had contributed to that document. everyone who had contributed to that document.
The authors would like to thank Kaname Nishizuka, Wei Pan, and Yuuhei The authors would like to thank Kaname Nishizuka, Wei Pan, and Yuuhei
Hayashi for comments and review. Hayashi for comments and review.
skipping to change at page 103, line 46 skipping to change at page 102, line 47
implementation and interoperability work. implementation and interoperability work.
15. References 15. References
15.1. Normative References 15.1. Normative References
[Enterprise-Numbers] [Enterprise-Numbers]
"Private Enterprise Numbers", May 2020, "Private Enterprise Numbers", May 2020,
<http://www.iana.org/assignments/enterprise-numbers.html>. <http://www.iana.org/assignments/enterprise-numbers.html>.
[I-D.ietf-dots-data-channel]
Boucadair, M. and T. Reddy.K, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Data Channel
Specification", draft-ietf-dots-data-channel-31 (work in
progress), July 2019.
[I-D.ietf-dots-signal-call-home] [I-D.ietf-dots-signal-call-home]
Reddy.K, T., Boucadair, M., and J. Shallow, "Distributed Reddy.K, T., Boucadair, M., and J. Shallow, "Distributed
Denial-of-Service Open Threat Signaling (DOTS) Signal Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel Call Home", draft-ietf-dots-signal-call-home-08 Channel Call Home", draft-ietf-dots-signal-call-home-08
(work in progress), March 2020. (work in progress), March 2020.
[I-D.ietf-dots-signal-channel]
Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and
N. Teague, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification", draft-
ietf-dots-signal-channel-41 (work in progress), January
2020.
[I-D.ietf-dots-signal-filter-control] [I-D.ietf-dots-signal-filter-control]
Nishizuka, K., Boucadair, M., Reddy.K, T., and T. Nagata, Nishizuka, K., Boucadair, M., Reddy.K, T., and T. Nagata,
"Controlling Filtering Rules Using Distributed Denial-of- "Controlling Filtering Rules Using Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel", Service Open Threat Signaling (DOTS) Signal Channel",
draft-ietf-dots-signal-filter-control-03 (work in draft-ietf-dots-signal-filter-control-06 (work in
progress), March 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>.
skipping to change at page 105, line 27 skipping to change at page 104, line 14
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>. 2018, <https://www.rfc-editor.org/info/rfc8345>.
[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
Denial-of-Service Open Threat Signaling (DOTS) Data
Channel Specification", RFC 8783, DOI 10.17487/RFC8783,
May 2020, <https://www.rfc-editor.org/info/rfc8783>.
15.2. Informative References 15.2. Informative References
[I-D.bosh-core-new-block] [I-D.bosh-core-new-block]
Boucadair, M. and J. Shallow, "New Constrained Application Boucadair, M. and J. Shallow, "Constrained Application
Protocol (CoAP) Block-Wise Transfer Options", draft-bosh- Protocol (CoAP) Block-Wise Transfer Options for Faster
core-new-block-00 (work in progress), April 2020. Transmission", draft-bosh-core-new-block-04 (work in
progress), June 2020.
[I-D.doron-dots-telemetry] [I-D.doron-dots-telemetry]
Doron, E., Reddy, T., Andreasen, F., Xia, L., and K. Doron, E., Reddy, T., Andreasen, F., Xia, L., and K.
Nishizuka, "Distributed Denial-of-Service Open Threat Nishizuka, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry Specifications", draft-doron- Signaling (DOTS) Telemetry Specifications", draft-doron-
dots-telemetry-00 (work in progress), October 2016. dots-telemetry-00 (work in progress), October 2016.
[I-D.ietf-dots-multihoming] [I-D.ietf-dots-multihoming]
Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing
Deployment Considerations for Distributed-Denial-of- Deployment Considerations for Distributed-Denial-of-
Service Open Threat Signaling (DOTS)", draft-ietf-dots- Service Open Threat Signaling (DOTS)", draft-ietf-dots-
multihoming-03 (work in progress), January 2020. multihoming-04 (work in progress), May 2020.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
L., and K. Nishizuka, "Use cases for DDoS Open Threat L., and K. Nishizuka, "Use cases for DDoS Open Threat
Signaling", draft-ietf-dots-use-cases-20 (work in Signaling", draft-ietf-dots-use-cases-23 (work in
progress), September 2019. progress), May 2020.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998, DOI 10.17487/RFC2330, May 1998,
<https://www.rfc-editor.org/info/rfc2330>. <https://www.rfc-editor.org/info/rfc2330>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
 End of changes. 58 change blocks. 
154 lines changed or deleted 150 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/