< draft-ietf-dots-telemetry-07.txt   draft-ietf-dots-telemetry-08.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: October 17, 2020 McAfee Expires: November 9, 2020 McAfee
E. Doron E. Doron
Radware Ltd. Radware Ltd.
M. Chen M. Chen
CMCC CMCC
April 15, 2020 J. Shallow
May 8, 2020
Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
draft-ietf-dots-telemetry-07 draft-ietf-dots-telemetry-08
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 DDoS attack mitigation. various telemetry attributes allowing optimal Distributed Denial-of-
It specifies the normal traffic baseline and attack traffic telemetry Service attack mitigation. It specifies the normal traffic baseline
attributes a DOTS client can convey to its DOTS server in the and attack traffic telemetry attributes a DOTS client can convey to
mitigation request, the mitigation status telemetry attributes a DOTS its DOTS server in the mitigation request, the mitigation status
server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS server can communicate to a DOTS client,
telemetry attributes a DOTS client can communicate to a DOTS server. and the mitigation efficacy telemetry attributes a DOTS client can
The telemetry attributes can assist the mitigator to choose the DDoS communicate to a DOTS server. The telemetry attributes can assist
mitigation techniques and perform optimal DDoS attack mitigation. the mitigator to choose the DDoS mitigation techniques and perform
optimal DDoS attack mitigation.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 17, 2020. This Internet-Draft will expire on November 9, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. DOTS Telemetry: Overview and Purpose . . . . . . . . . . . . 5 3. DOTS Telemetry: Overview and Purpose . . . . . . . . . . . . 6
4. Generic Considerations . . . . . . . . . . . . . . . . . . . 9 4. Generic Considerations . . . . . . . . . . . . . . . . . . . 9
4.1. DOTS Client Identification . . . . . . . . . . . . . . . 9 4.1. DOTS Client Identification . . . . . . . . . . . . . . . 9
4.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . . . 9 4.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . . . 9 4.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . . . 9
4.4. Controlling Configuration Data . . . . . . . . . . . . . 9 4.4. Controlling Configuration Data . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . 19 6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 20
6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 20 6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 20
6.2.1. Convey DOTS Client Domain Pipe Capacity . . . . . . . 21 6.2.1. Convey DOTS Client Domain Pipe Capacity . . . . . . . 21
6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity . 26 6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity . 27
6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 26 6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 27
6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 27 6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 27
6.3.1. Convey DOTS Client Domain Baseline Information . . . 30 6.3.1. Convey DOTS Client Domain Baseline Information . . . 30
6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 33 6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 33
6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 33 6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 33
6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 33 6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 33
6.5. Conflict with Other DOTS Clients of the Same Domain . . . 33 6.5. Conflict with Other DOTS Clients of the Same Domain . . . 33
7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 34 7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 34
7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 36 7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 36
7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 36 7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . 44 7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 51
7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 47 8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 56
8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 51
8.1. DOTS Clients to Servers Mitigation Efficacy DOTS 8.1. DOTS Clients to Servers Mitigation Efficacy DOTS
Telemetry Attributes . . . . . . . . . . . . . . . . . . 51 Telemetry Attributes . . . . . . . . . . . . . . . . . . 56
8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry 8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry
Attributes . . . . . . . . . . . . . . . . . . . . . . . 53 Attributes . . . . . . . . . . . . . . . . . . . . . . . 58
9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 57 9. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 62
10. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 83 9.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . . 62
11. IANA Considerationsr . . . . . . . . . . . . . . . . . . . . 87 9.2. Vendor Attack Mapping Details YANG Module . . . . . . . . 89
11.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 87 10. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 92
11.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 91 11. IANA Considerationsr . . . . . . . . . . . . . . . . . . . . 96
11.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 91 11.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 96
12. Security Considerations . . . . . . . . . . . . . . . . . . . 91 11.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 100
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 91 11.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 100
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 92 12. Security Considerations . . . . . . . . . . . . . . . . . . . 101
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 92 12.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 101
15.1. Normative References . . . . . . . . . . . . . . . . . . 92 12.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 102
15.2. Informative References . . . . . . . . . . . . . . . . . 93 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 103
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 103
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 103
15.1. Normative References . . . . . . . . . . . . . . . . . . 103
15.2. Informative References . . . . . . . . . . . . . . . . . 105
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106
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 6, line 42 skipping to change at page 6, line 51
important to realize that the DOTS clients receive the required important to realize that the DOTS clients receive the required
service. For example, understanding that "I asked for mitigation of service. For example, understanding that "I asked for mitigation of
two attacks and my DOTS server detects and mitigates only one...". two attacks and my DOTS server detects and mitigates only one...".
Cases of inconsistency in attack classification between DOTS clients Cases of inconsistency in attack classification between DOTS clients
and servers can be highlighted, and maybe handled, using the DOTS and servers can be highlighted, and maybe handled, using the DOTS
telemetry attributes. telemetry attributes.
In addition, management and orchestration systems, at both DOTS In addition, management and orchestration systems, at both DOTS
client and server sides, can use DOTS telemetry as a feedback to client and server sides, can use DOTS telemetry as a feedback to
automate various control and management activities derived from automate various control and management activities derived from
signaled telemetry information . signaled telemetry information.
If the DOTS server's mitigation resources have the capabilities to If the DOTS server's mitigation resources have the capabilities to
facilitate the DOTS telemetry, the DOTS server adapts its protection facilitate the DOTS telemetry, the DOTS server adapts its protection
strategy and activates the required countermeasures immediately strategy and activates the required countermeasures immediately
(automation enabled) for the sake of optimized attack mitigation (automation enabled) for the sake of optimized attack mitigation
decisions and actions. decisions and actions.
DOTS telemetry can also be used to tune the DDoS mitigators with the DOTS telemetry can also be used to tune the DDoS mitigators with the
correct state of an attack. During the last few years, DDoS attack correct state of an attack. During the last few years, DDoS attack
detection technologies have evolved from threshold-based detection detection technologies have evolved from threshold-based detection
skipping to change at page 10, line 42 skipping to change at page 11, line 7
them, only the information related to prefixes assigned by an them, only the information related to prefixes assigned by an
upstream network to the DOTS client domain will be signaled via the upstream network to the DOTS client domain will be signaled via the
DOTS channel established with the DOTS server of that upstream DOTS channel established with the DOTS server of that upstream
network. Considerations related to whether (and how) a DOTS client network. 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
Messages exchanged between DOTS agents are serialized using Concise Telemetry messages exchanged between DOTS agents are serialized using
Binary Object Representation (CBOR). CBOR-encoded payloads are used Concise Binary Object Representation (CBOR). CBOR-encoded payloads
to carry signal channel-specific payload messages which convey are used to carry signal channel-specific payload messages which
request parameters and response information such as errors convey request parameters and response information such as errors
[I-D.ietf-dots-signal-channel]. [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). All parameters in the payload of the DOTS message types (Section 9.1). All parameters in the payload of the
signal channel are mapped to CBOR types as specified in Section 10. DOTS signal channel are mapped to CBOR types as specified in
Section 10.
This YANG module is not intended to be used via NETCONF/ RESTCONF for
DOTS server management purposes; such module is out of the scope of
this document. It serves only to provide a data model and encoding,
but not a management data model.
DOTS servers are allowed to update the non-configurable 'ro' entities The DOTS telemetry module (Section 9.1) is not intended to be used
in the responses. via NETCONF/RESTCONF for DOTS server management purposes. It serves
only to provide a data model and encoding, but not a management data
model. DOTS servers are allowed to update the non-configurable 'ro'
entities in the responses of DOTS telemetry messages.
The DOTS telemetry module (Section 9) uses "enumerations" rather than The DOTS telemetry module (Section 9.1) uses "enumerations" rather
"identities" to define units, samples, and intervals because than "identities" to define units, samples, and intervals because
otherwise the namespace identifier "ietf-dots-telemetry" must be otherwise the namespace identifier "ietf-dots-telemetry" must be
included when a telemetry attribute is included (e.g., in a included when a telemetry attribute is included (e.g., in a
mitigation efficacy update). The use of "identities" is thus mitigation efficacy update). The use of "identities" is thus
suboptimal from a message compactness standpoint. suboptimal from a message compactness standpoint.
4.8. A Note About Examples 4.8. A Note About Examples
Examples are provided for illustration purposes. The document does Examples are provided for illustration purposes. The document does
not aim to provide a comprehensive list of message examples. not aim to provide a comprehensive list of message examples.
The authoritative reference for validating telemetry messages is the The authoritative reference for validating telemetry messages is the
YANG module (Section 9) 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 [I-D.ietf-dots-signal-channel], each DOTS operation
is indicated by a path-suffix that indicates the intended operation. is 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 this Consequently, the "ietf-dots-telemetry" YANG module defined in
document (Section 9) augments the "ietf-dots-signal" with two new Section 9.1 augments the "ietf-dots-signal" with two new message
message types called "telemetry-setup" and "telemetry". The tree types called "telemetry-setup" and "telemetry". The tree structure
structure is shown in Figure 1 (more details are provided in the is shown in Figure 1 (more details are provided in the following
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}?
| ... | ...
| +--rw (setup-type)? | +--rw (setup-type)?
| +--:(telemetry-config) | +--:(telemetry-config)
| | ... | | ...
| +--:(pipe) | +--:(pipe)
| | ... | | ...
skipping to change at page 15, line 26 skipping to change at page 15, line 26
| | +--ro measurement-interval? interval | | +--ro measurement-interval? interval
| | +--ro measurement-sample? sample | | +--ro measurement-sample? sample
| | +--ro low-percentile? percentile | | +--ro low-percentile? percentile
| | +--ro mid-percentile? percentile | | +--ro mid-percentile? percentile
| | +--ro high-percentile? percentile | | +--ro high-percentile? percentile
| | +--ro telemetry-notify-interval? uint32 | | +--ro telemetry-notify-interval? uint32
| +--ro supported-units | +--ro supported-units
| | +--ro unit-config* [unit] | | +--ro unit-config* [unit]
| | +--ro unit unit-type | | +--ro unit unit-type
| | +--ro unit-status boolean | | +--ro unit-status boolean
| +--ro query-type* query-type
| +--rw telemetry* [cuid tsid] | +--rw telemetry* [cuid tsid]
| +--rw cuid string | +--rw cuid string
| +--rw cdid? string | +--rw cdid? string
| +--rw tsid uint32 | +--rw tsid uint32
| +--rw (setup-type)? | +--rw (setup-type)?
| +--:(telemetry-config) | +--:(telemetry-config)
| | +--rw current-config | | +--rw current-config
| | +--rw measurement-interval? interval | | +--rw measurement-interval? interval
| | +--rw measurement-sample? sample | | +--rw measurement-sample? sample
| | +--rw low-percentile? percentile | | +--rw low-percentile? percentile
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
[I-D.ietf-dots-signal-channel] MUST be followed for 'tsid'
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
numeric 'tsid' value. To avoid maintaining a long list of 'tsid' numeric 'tsid' value. To avoid maintaining a long list of 'tsid'
skipping to change at page 34, line 14 skipping to change at page 34, line 14
7. DOTS Pre-or-Ongoing Mitigation Telemetry 7. DOTS Pre-or-Ongoing Mitigation Telemetry
There are two broad types of DDoS attacks, one is bandwidth consuming There are two broad types of DDoS attacks, one is bandwidth consuming
attack, the other is target resource consuming attack. This section attack, the other is target resource consuming attack. This section
outlines the set of DOTS telemetry attributes (Section 7.1) that outlines the set of DOTS telemetry attributes (Section 7.1) that
covers both the types of attacks. The objective of these attributes covers both the types of attacks. The objective of these attributes
is to allow for the complete knowledge of attacks and the various is to allow for the complete knowledge of attacks and the various
particulars that can best characterize attacks. particulars that can best characterize attacks.
The "ietf-dots-telemetry" YANG module (Section 9) augments the "ietf- The "ietf-dots-telemetry" YANG module (Section 9.1) augments the
dots-signal" with a new message type called "telemetry". The tree "ietf-dots-signal" with a new message type called "telemetry". The
structure of the "telemetry" message type is shown Figure 24. tree structure of the "telemetry" message type is shown Figure 24.
The pre-or-ongoing-mitigation telemetry attributes are indicated by The pre-or-ongoing-mitigation telemetry attributes are indicated by
the path-suffix '/tm'. The '/tm' is appended to the path-prefix to the path-suffix '/tm'. The '/tm' is appended to the path-prefix to
form the URI used with a CoAP request to signal the DOTS telemetry. form the URI used with a CoAP request to signal the DOTS telemetry.
Pre-or-ongoing-mitigation telemetry attributes specified in Pre-or-ongoing-mitigation telemetry attributes specified in
Section 7.1 can be signaled between DOTS agents. Section 7.1 can be signaled between DOTS agents.
Pre-or-ongoing-mitigation telemetry attributes may be sent by a DOTS Pre-or-ongoing-mitigation telemetry attributes may be sent by a DOTS
client or a DOTS server. client or a DOTS server.
skipping to change at page 35, line 17 skipping to change at page 35, line 17
+-----------+ +-----------+ +-----------+ +-----------+
| | | |
|<=============== Telemetry (target-prefix)=============| |<=============== Telemetry (target-prefix)=============|
| | | |
|=========Mitigation Request (target-prefix)===========>| |=========Mitigation Request (target-prefix)===========>|
| | | |
Figure 23: Example of Request Correlation using Target Prefix Figure 23: Example of Request Correlation using Target Prefix
DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry
messages to the same peer more frequently than once every 'telemetry- notifications to the same peer more frequently than once every
notify-interval' (Section 6.1). If a telemetry notification is sent 'telemetry-notify-interval' (Section 6.1). If a telemetry
using a block-like transfer mechanism (e.g., notification is sent using a block-like transfer mechanism (e.g.,
[I-D.bosh-core-new-block]), this rate limit policy MUST NOT consider [I-D.bosh-core-new-block]), this rate limit policy MUST NOT consider
these individual blocks as separate notifications, but as a single these individual blocks as separate notifications, but as a single
notification. notification.
DOTS pre-or-ongoing-mitigation telemetry request and response DOTS pre-or-ongoing-mitigation telemetry request and response
messages MUST be marked as Non-Confirmable messages. messages MUST be marked as Non-Confirmable messages.
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}?
| +--rw telemetry* [cuid tsid] | +--rw telemetry* [cuid tsid]
skipping to change at page 36, line 32 skipping to change at page 36, line 32
+--rw total-attack-traffic* [unit] +--rw total-attack-traffic* [unit]
| ... | ...
+--rw total-attack-traffic-protocol* [unit protocol] +--rw total-attack-traffic-protocol* [unit protocol]
| ... | ...
+--rw total-attack-traffic-port* [unit port] +--rw total-attack-traffic-port* [unit port]
| ... | ...
+--rw total-attack-connection +--rw total-attack-connection
| ... | ...
+--rw total-attack-connection-port +--rw total-attack-connection-port
| ... | ...
+--rw attack-detail* [attack-id] +--rw attack-detail* [vendor-id attack-id]
... ...
Figure 24: Telemetry Message Type Tree Structure Figure 24: Telemetry Message Type Tree Structure
7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes 7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes
The description and motivation behind each attribute are presented in The description and motivation behind each attribute are presented in
Section 3. DOTS telemetry attributes are optionally signaled and Section 3. DOTS telemetry attributes are optionally signaled and
therefore MUST NOT be treated as mandatory fields in the DOTS signal therefore MUST NOT be treated as mandatory fields in the DOTS signal
channel protocol. channel protocol.
skipping to change at page 37, line 36 skipping to change at page 37, line 36
+--rw total-attack-traffic* [unit] +--rw total-attack-traffic* [unit]
| ... | ...
+--rw total-attack-traffic-protocol* [unit protocol] +--rw total-attack-traffic-protocol* [unit protocol]
| ... | ...
+--rw total-attack-traffic-port* [unit port] +--rw total-attack-traffic-port* [unit port]
| ... | ...
+--rw total-attack-connection +--rw total-attack-connection
| ... | ...
+--rw total-attack-connection-port +--rw total-attack-connection-port
| ... | ...
+--rw attack-detail* [attack-id] +--rw attack-detail* [vendor-id attack-id]
... ...
Figure 25: Target Tree Structure Figure 25: Target Tree Structure
At least one of the attributes 'target-prefix', 'target-fqdn', At least one of the attributes 'target-prefix', 'target-fqdn',
'target-uri', 'alias-name', or 'mid-list' MUST be present in the 'target-uri', 'alias-name', or 'mid-list' MUST be present in the
target definition. target definition.
If the target is subjected to bandwidth consuming attack, the If the target is subjected to bandwidth consuming attack, the
attributes representing the percentile values of the 'attack-id' attributes representing the percentile values of the 'attack-id'
skipping to change at page 39, line 42 skipping to change at page 39, line 42
+--rw total-attack-traffic* [unit] +--rw total-attack-traffic* [unit]
| ... | ...
+--rw total-attack-traffic-protocol* [unit protocol] +--rw total-attack-traffic-protocol* [unit protocol]
| ... | ...
+--rw total-attack-traffic-port* [unit port] +--rw total-attack-traffic-port* [unit port]
| ... | ...
+--rw total-attack-connection +--rw total-attack-connection
| ... | ...
+--rw total-attack-connection-port +--rw total-attack-connection-port
| ... | ...
+--rw attack-detail* [attack-id] +--rw attack-detail* [vendor-id attack-id]
... ...
Figure 26: Total Traffic Tree Structure Figure 26: Total Traffic Tree Structure
7.1.3. Total Attack Traffic 7.1.3. Total Attack Traffic
The 'total-attack-traffic' attribute (Figure 27) conveys the total The 'total-attack-traffic' attribute (Figure 27) conveys the total
attack traffic identified by the DOTS client domain's DMS (or DDoS attack traffic identified by the DOTS client domain's DMS (or DDoS
Detector). More granular total traffic can be conveyed in 'total- Detector). More granular total traffic can be conveyed in 'total-
attack-traffic-protocol' and 'total-attack-traffic-port'. attack-traffic-protocol' and 'total-attack-traffic-port'.
skipping to change at page 40, line 48 skipping to change at page 40, line 48
| +--rw port inet:port-number | +--rw port inet:port-number
| +--rw unit unit | +--rw unit unit
| +--rw low-percentile-g? yang:gauge64 | +--rw low-percentile-g? yang:gauge64
| +--rw mid-percentile-g? yang:gauge64 | +--rw mid-percentile-g? yang:gauge64
| +--rw high-percentile-g? yang:gauge64 | +--rw high-percentile-g? yang:gauge64
| +--rw peak-g? yang:gauge64 | +--rw peak-g? yang:gauge64
+--rw total-attack-connection +--rw total-attack-connection
| ... | ...
+--rw total-attack-connection-port +--rw total-attack-connection-port
| ... | ...
+--rw attack-detail* [attack-id] +--rw attack-detail* [vendor-id attack-id]
... ...
Figure 27: Total Attack Traffic Tree Structure Figure 27: Total Attack Traffic Tree Structure
7.1.4. Total Attack Connections 7.1.4. Total Attack Connections
If the target is subjected to resource consuming DDoS attack, the If the target is subjected to resource consuming DDoS attack, the
'total-attack-connection' attribute is used to convey the percentile 'total-attack-connection' attribute is used to convey the percentile
values of total attack connections. The following optional sub- values of total attack connections. The following optional sub-
attributes for the target per transport-protocol are included to attributes for the target per transport-protocol are included to
skipping to change at page 42, line 41 skipping to change at page 42, line 41
| | +--rw request-ps? yang:gauge64 | | +--rw request-ps? yang:gauge64
| | +--rw partial-request-ps? yang:gauge64 | | +--rw partial-request-ps? yang:gauge64
| +--rw peak-l* [protocol port] | +--rw peak-l* [protocol port]
| +--rw port inet:port-number | +--rw port inet:port-number
| +--rw protocol uint8 | +--rw protocol uint8
| +--rw connection? yang:gauge64 | +--rw connection? yang:gauge64
| +--rw embryonic? yang:gauge64 | +--rw embryonic? yang:gauge64
| +--rw connection-ps? yang:gauge64 | +--rw connection-ps? yang:gauge64
| +--rw request-ps? yang:gauge64 | +--rw request-ps? yang:gauge64
| +--rw partial-request-ps? yang:gauge64 | +--rw partial-request-ps? yang:gauge64
+--rw attack-detail* [attack-id] +--rw attack-detail* [vendor-id attack-id]
... ...
Figure 28: Total Attack Connections Tree Structure Figure 28: Total Attack Connections Tree Structure
7.1.5. Attack Details 7.1.5. Attack Details
This attribute (Figure 29) is used to signal a set of details This attribute (Figure 29) is used to signal a set of details
characterizing an attack. The following sub-attributes describing characterizing an attack. The following sub-attributes describing
the on-going attack can be signal as attack details. the on-going attack can be signal as attack details.
id: Vendor ID is a security vendor's Enterprise Number as registered vendor-id: Vendor ID is a security vendor's Enterprise Number as
with IANA [Enterprise-Numbers]. It is a four-byte integer value. registered with IANA [Enterprise-Numbers]. It is a four-byte
integer value.
attack-id: Unique identifier assigned for the attack. attack-id: Unique identifier assigned for the attack.
attack-name: Textual representation of attack description. Natural attack-name: Textual representation of the attack description.
Language Processing techniques (e.g., word embedding) can possibly Natural Language Processing techniques (e.g., word embedding) can
be used to map the attack description to an attack type. Textual possibly be used to map the attack description to an attack type.
representation of attack solves two problems: (a) avoids the need Textual representation of attack solves two problems: (a) avoids
to create mapping tables manually between vendors and (2) avoids the need to create mapping tables manually between vendors and (b)
the need to standardize attack types which keep evolving. avoids the need to standardize attack types which keep evolving.
attack-severity: Attack severity. These values are supported: attack-severity: Attack severity level. This attribute takes one of
emergency (1), critical (2), and alert (3). the values defined in Section 3.12.2 of [RFC7970].
start-time: The time the attack started. The attack's start time is start-time: The time the attack started. The attack's start time is
expressed in seconds relative to 1970-01-01T00:00Z in UTC time expressed in seconds relative to 1970-01-01T00:00Z in UTC time
(Section 2.4.1 of [RFC7049]). The CBOR encoding is modified so (Section 2.4.1 of [RFC7049]). The CBOR encoding is modified so
that the leading tag 1 (epoch-based date/time) MUST be omitted. that the leading tag 1 (epoch-based date/time) MUST be omitted.
end-time: The time the attack-id attack ended. The attack end time end-time: The time the attack ended. The attack end time is
is expressed in seconds relative to 1970-01-01T00:00Z in UTC time expressed in seconds relative to 1970-01-01T00:00Z in UTC time
(Section 2.4.1 of [RFC7049]). The CBOR encoding is modified so (Section 2.4.1 of [RFC7049]). The CBOR encoding is modified so
that the leading tag 1 (epoch-based date/time) MUST be omitted. that the leading tag 1 (epoch-based date/time) MUST be omitted.
source-count: A count of sources involved in the attack targeting source-count: A count of sources involved in the attack targeting
the victim. the victim.
top-talkers: A list of top talkers among attack sources. The top top-talkers: A list of top talkers among attack sources. The top
talkers are represented using the 'source-prefix'. talkers are represented using the 'source-prefix'.
'spoofed-status' is used whether a top talker is a spoofed IP 'spoofed-status' indicates whether a top talker is a spoofed IP
address (e.g., reflection attacks) or not. address (e.g., reflection attacks) or not.
If the target is subjected to bandwidth consuming attack, the If the target is subjected to a bandwidth consuming attack, the
attack traffic from each of the top talkers is included ('total- attack traffic from each of the top talkers is included ('total-
attack-traffic', Section 7.1.3). attack-traffic', Section 7.1.3).
If the target is subjected to resource consuming DDoS attacks, the If the target is subjected to a resource consuming DDoS attack,
same attributes defined for Section 7.1.4 are applicable for the same attributes defined in Section 7.1.4 are applicable for
representing the attack per talker. representing the attack per talker.
+--:(telemetry) {dots-telemetry}? +--:(telemetry) {dots-telemetry}?
+--rw pre-or-ongoing-mitigation* [cuid tmid] +--rw pre-or-ongoing-mitigation* [cuid tmid]
+--rw cuid string +--rw cuid string
+--rw cdid? string +--rw cdid? string
+--rw tmid uint32 +--rw tmid uint32
+--rw target +--rw target
| ... | ...
+--rw attack-detail* [attack-id] +--rw attack-detail* [vendor-id attack-id]
+--rw id? uint32 +--rw vendor-id uint32
+--rw attack-id string +--rw attack-id uint32
+--rw attack-name? string +--rw attack-name? string
+--rw attack-severity? attack-severity +--rw attack-severity? attack-severity
+--rw start-time? uint64 +--rw start-time? uint64
+--rw end-time? uint64 +--rw end-time? uint64
+--rw top-talker +--rw top-talker
+--rw talker* [source-prefix] +--rw talker* [source-prefix]
+--rw spoofed-status? boolean +--rw spoofed-status? boolean
+--rw source-prefix inet:ip-prefix +--rw source-prefix inet:ip-prefix
+--rw source-port-range* [lower-port] +--rw source-port-range* [lower-port]
| +--rw lower-port inet:port-number | +--rw lower-port inet:port-number
skipping to change at page 44, line 47 skipping to change at page 44, line 47
| ... | ...
+--rw mid-percentile-l* [protocol] +--rw mid-percentile-l* [protocol]
| ... | ...
+--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
DOTS signal channel, DOTS agents MAY use the DOTS data channel
[I-D.ietf-dots-data-channel] to exchange vendor-specific attack
mapping details (that is, {vendor identifier, attack identifier} ==>
attack name). As such, DOTS agents do not have to convey
systematically an attack name in their telemetry messages over the
DOTS signal channel. The "ietf-dots-mapping" YANG module defined in
Section 9.2) augments the "ietf-dots-data-channel". The tree
structure of this module is shown in Figure 30.
module: ietf-dots-mapping
augment /ietf-data:dots-data/ietf-data:dots-client:
+--rw vendor-mapping {dots-telemetry}?
+--rw vendor* [vendor-id]
+--rw vendor-id uint32
+--rw attack-mapping* [attack-id]
+--rw attack-id uint32
+--rw attack-name string
augment /ietf-data:dots-data/ietf-data:capabilities:
+--ro vendor-mapping-enabled? boolean {dots-telemetry}?
augment /ietf-data:dots-data:
+--ro vendor-mapping {dots-telemetry}?
+--ro vendor* [vendor-id]
+--ro vendor-id uint32
+--ro attack-mapping* [attack-id]
+--ro attack-id uint32
+--ro attack-name string
Figure 30: Vendor Attack Mapping Tree Structure
A DOTS client sends a GET request to retrieve the capabilities
supported by a DOTS server as per Section 7.1 of
[I-D.ietf-dots-data-channel]. This request is meant to assess
whether vendor attack mapping details feature is supported by the
server (i.e., check the value of 'vendor-mapping-enabled').
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
details. An example of such GET request is shown in Figure 31.
GET /restconf/data/ietf-dots-data-channel:dots-data\
/ietf-dots-mapping:vendor-mapping HTTP/1.1
Host: example.com
Accept: application/yang-data+json
Figure 31: GET to Retrieve the Vendor Attack Mappings of a DOTS
Server
A DOTS client MAY retrieve only the list of vendors supported by the
DOTS server. It does so by setting the "depth" parameter
(Section 4.8.2 of [RFC8040]) to "3" in the GET request as shown in
Figure 32. An example of a response body received from the DOTS
server as a response to such request is illustrated in Figure 33.
GET /restconf/data/ietf-dots-data-channel:dots-data\
/ietf-dots-mapping:vendor-mapping?depth=3 HTTP/1.1
Host: example.com
Accept: application/yang-data+json
Figure 32: GET to Retrieve the Vendors List used by a DOTS Server
{
"ietf-dots-mapping:vendor-mapping": {
"ietf-dots-mapping:vendor": [
{
"ietf-dots-mapping:vendor-id": 1234,
"ietf-dots-mapping:attack-mapping": []
}
]
}
}
Figure 33: Response to a GET to Retrieve the Vendors List used by a
DOTS Server
The DOTS client reiterates the above procedure regularly (e.g., once
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
reference to the specific vendor attack mapping details, the DOTS
client uses a POST request to install its vendor attack mapping
details. An example of such POST request is depicted in Figure 34.
POST /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
Host: {host}:{port}
Content-Type: application/yang-data+json
{
"ietf-dots-mapping:vendor-mapping": {
"ietf-dots-mapping:vendor": [
{
"ietf-dots-mapping:vendor-id": 345,
"ietf-dots-mapping:attack-mapping": [
{
"ietf-dots-mapping:attack-id": 1,
"ietf-dots-mapping:attack-name":
"Include a description of this attack"
},
{
"ietf-dots-mapping:attack-id": 2,
"ietf-dots-mapping:attack-name":
"Again, include a description of the attack"
}
]
}
]
}
}
Figure 34: POST to Install Vendor Attack Mapping Details
The DOTS server indicates the result of processing the POST request
using the status-line. Concretely, "201 Created" status-line MUST be
returned in the response if the DOTS server has accepted the vendor
attack mapping details. If the request is missing a mandatory
attribute or contains an invalid or unknown parameter, "400 Bad
Request" status-line MUST be returned by the DOTS server in the
response. The error-tag is set to "missing-attribute", "invalid-
value", or "unknown-element" as a function of the encountered error.
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'
is expected to be supplied, the DOTS server MUST reply with "403
Forbidden" status-line and the error-tag "access-denied". Upon
receipt of this message, the DOTS client MUST register (Section 5.1
of [I-D.ietf-dots-data-channel]).
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).
A DOTS client uses a GET request to retrieve its vendor attack
mapping details as maintained by the DOTS server (Figure 35).
GET /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw\
/ietf-dots-mapping:vendor-mapping?\
content=all HTTP/1.1
Host: example.com
Accept: application/yang-data+json
Figure 35: GET to Retrieve Installed Vendor Attack Mapping Details
When conveying attack details in DOTS telemetry messages (Sections
7.2, 7.3, and 8), DOTS agents MUST NOT include 'attack-name'
attribute except if the corresponding attack mapping details were not
shared with the peer DOTS agent (e.g., a DOTS server detects a new
attack type).
7.2. From DOTS Clients to DOTS Servers 7.2. From DOTS Clients to DOTS Servers
DOTS clients uses PUT request to signal pre-or-ongoing-mitigation DOTS clients uses PUT request to signal pre-or-ongoing-mitigation
telemetry to DOTS servers. An example of such request is shown in telemetry to DOTS servers. An example of such request is shown in
Figure 30. Figure 36.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=123" Uri-Path: "tmid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
skipping to change at page 45, line 31 skipping to change at page 49, line 31
}, },
"total-attack-traffic-protocol": [ "total-attack-traffic-protocol": [
{ {
"protocol": 17, "protocol": 17,
"unit": "megabit-ps", "unit": "megabit-ps",
"mid-percentile-g": "900" "mid-percentile-g": "900"
} }
], ],
"attack-detail": [ "attack-detail": [
{ {
"attack-id": "an-id", "vendor-id": 1234,
"attack-id": 77,
"start-time": "1957811234", "start-time": "1957811234",
"attack-severity": "emergency" "attack-severity": "high"
} }
] ]
} }
] ]
} }
} }
Figure 30: PUT to Send Pre-or-Ongoing-Mitigation Telemetry Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry
'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
[I-D.ietf-dots-signal-channel] MUST be followed for 'tmid'
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.
The relative order of two PUT requests carrying DOTS pre-or-ongoing- The relative order of two PUT requests carrying DOTS pre-or-ongoing-
skipping to change at page 46, line 39 skipping to change at page 50, line 43
How long a DOTS server maintains a 'tmid' as active or logs the How long a DOTS server maintains a 'tmid' as active or logs the
enclosed telemetry information is implementation-specific. Note that enclosed telemetry information is implementation-specific. Note that
if a 'tmid' is still active, then logging details are updated by the if a 'tmid' is still active, then logging details are updated by the
DOTS server as a function of the updates received from the peer DOTS DOTS server as a function of the updates received from the peer DOTS
client. client.
A DOTS client that lost the state of its active 'tmids' or has to set A DOTS client that lost the state of its active 'tmids' or has to set
'tmid' back to zero (e.g., crash or restart) MUST send a GET request 'tmid' back to zero (e.g., crash or restart) MUST send a GET request
to the DOTS server to retrieve the list of active 'tmid'. The DOTS to the DOTS server to retrieve the list of active 'tmid'. The DOTS
client may then delete 'tmids' that should not be active anymore client may then delete 'tmids' that should not be active anymore
(Figure 31). Sending a DELETE with no 'tmid' indicates that all (Figure 37). Sending a DELETE with no 'tmid' indicates that all
'tmids' must be deactivated (Figure 32). 'tmids' must be deactivated (Figure 38).
Header: DELETE (Code=0.04) Header: DELETE (Code=0.04)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=123" Uri-Path: "tmid=123"
Figure 31: Delete a Pre-or-Ongoing-Mitigation Telemetry Figure 37: Delete a Pre-or-Ongoing-Mitigation Telemetry
Header: DELETE (Code=0.04) Header: DELETE (Code=0.04)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Figure 32: Delete All Pre-or-Ongoing-Mitigation Telemetry Figure 38: Delete All Pre-or-Ongoing-Mitigation Telemetry
7.3. From DOTS Servers to DOTS Clients 7.3. From DOTS Servers to DOTS Clients
The pre-or-ongoing-mitigation (attack details, in particular) can The pre-or-ongoing-mitigation (attack details, in particular) can
also be signaled from DOTS servers to DOTS clients. For example, the also be signaled from DOTS servers to DOTS clients. For example, the
DOTS server co-located with a DDoS detector collects monitoring DOTS server co-located with a DDoS detector collects monitoring
information from the target network, identifies DDoS attack using information from the target network, identifies DDoS attack using
statistical analysis or deep learning techniques, and signals the statistical analysis or deep learning techniques, and signals the
attack details to the DOTS client. attack details to the DOTS client.
The DOTS client can use the attack details to decide whether to The DOTS client can use the attack details to decide whether to
trigger a DOTS mitigation request or not. Furthermore, the security trigger a DOTS mitigation request or not. Furthermore, the security
operation personnel at the DOTS client domain can use the attack operation personnel at the DOTS client domain can use the attack
details to determine the protection strategy and select the details to determine the protection strategy and select the
appropriate DOTS server for mitigating the attack. appropriate DOTS server for mitigating the attack.
In order to receive pre-or-ongoing-mitigation telemetry notifications In order to receive pre-or-ongoing-mitigation telemetry notifications
from a DOTS server, a DOTS client MUST send a PUT (followed by a GET) from a DOTS server, a DOTS client MUST send a PUT (followed by a GET)
with the target filter. An example of such PUT request is shown in with the target filter. An example of such PUT request is shown in
Figure 33. In order to avoid maintaining a long list of such Figure 39. In order to avoid maintaining a long list of such
requests, it is RECOMMENDED that DOTS clients include all targets in requests, it is RECOMMENDED that DOTS clients include all targets in
the same request. DOTS servers may be instructed to restrict the the same request. DOTS servers may be instructed to restrict the
number of pre-or-ongoing-mitigation requests per DOTS client domain. number of pre-or-ongoing-mitigation requests per DOTS client domain.
This request MUST be maintained active by the DOTS server until a This request MUST be maintained active by the DOTS server until a
delete request is received from the same DOTS client to clear this delete request is received from the same DOTS client to clear this
pre-or-ongoing-mitigation telemetry. pre-or-ongoing-mitigation telemetry.
The relative order of two PUT requests carrying DOTS pre-or-ongoing- The relative order of two PUT requests carrying DOTS pre-or-ongoing-
mitigation telemetry from a DOTS client is determined by comparing mitigation telemetry from a DOTS client is determined by comparing
their respective 'tmid' values. If such two requests have their respective 'tmid' values. If such two requests have
skipping to change at page 48, line 27 skipping to change at page 52, line 30
"target": { "target": {
"target-prefix": [ "target-prefix": [
"2001:db8::/32" "2001:db8::/32"
] ]
} }
} }
] ]
} }
} }
Figure 33: PUT to Request Pre-or-Ongoing-Mitigation Telemetry Figure 39: PUT to Request Pre-or-Ongoing-Mitigation Telemetry
DOTS clients of the same domain can request to receive pre-or- DOTS clients of the same domain can request to receive pre-or-
ongoing-mitigation telemetry bound to the same target. ongoing-mitigation telemetry bound to the same target.
The DOTS client conveys the Observe Option set to '0' in the GET The DOTS client conveys the Observe Option set to '0' in the GET
request to receive asynchronous notifications carrying pre-or- request to receive asynchronous notifications carrying pre-or-
ongoing-mitigation telemetry data from the DOTS server. The GET ongoing-mitigation telemetry data from the DOTS server. The GET
request specifies a 'tmid' (Figure 34) or not (Figure 35). request specifies a 'tmid' (Figure 40) or not (Figure 41).
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=123" Uri-Path: "tmid=123"
Observe: 0 Observe: 0
Figure 34: GET to Subscribe to Telemetry Asynchronous Notifications Figure 40: GET to Subscribe to Telemetry Asynchronous Notifications
for a Specific 'tmid' for a Specific 'tmid'
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Observe: 0 Observe: 0
Figure 35: GET to Subscribe to Telemetry Asynchronous Notifications Figure 41: GET to Subscribe to Telemetry Asynchronous Notifications
for All 'tmids' for All 'tmids'
The DOTS client can filter out the asynchronous notifications from The DOTS client can filter out the asynchronous notifications from
the DOTS server by indicating one or more Uri-Query options in its the DOTS server by indicating one or more Uri-Query options in its
GET request. A Uri-Query option can include the following GET request. An Uri-Query option can include the following
parameters: target-prefix, lower-port, upper-port, target-protocol, parameters: 'target-prefix', 'target-port', 'target-protocol',
target-fqdn, target-uri, alias-name. An example of request to 'target-fqdn', 'target-uri', 'alias-name', 'mid', and 'c' (content)
subscribe to asynchronous UDP telemetry notifications is shown in (Section 4.4). Furthermore:
Figure 36. This filter will be applied for all 'tmids'.
If more than one Uri-Query option is included in a request, these
options are interpreted in the same way as when multiple target
clauses are included in a message body.
If multiple values of a query parameter are to be included in a
request, these values MUST be included in the same Uri-Query
option and separated by a "," character without any spaces.
Range values (i.e., contiguous inclusive block) can be included
for 'target-port', 'target-protocol', and 'mid' parameters by
indicating two bound values separated by a "-" character.
Wildcard names (i.e., a name with the leftmost label is the "*"
character) can be included in 'target-fqdn' or 'target-uri'
parameters. DOTS clients MUST NOT include a name in which the "*"
character is included in a label other than the leftmost label.
"*.example.com" is an example of a valid wildcard name that can be
included as a value of the 'target-fqdn' parameter in an Uri-Query
option.
DOTS clients may also filter out the asynchronous notifications from
the DOTS server by indicating a specific source information. To that
aim, a DOTS client may include 'source-prefix', 'source-port', or
'source-icmp-type' in an Uri-Query option. The same considerations
(ranges, multiple values) specified for target clauses apply for
source clauses. Special care SHOULD be taken when using these
filters as some attacks may be hidden to the requesting DOTS client
(e.g., the attack changes its source information).
Requests with invalid query types (e.g., not supported, malformed) by
the DOTS server MUST be rejected by DOTS servers with a 4.00 (Bad
Request).
An example of request to subscribe to asynchronous UDP telemetry
notifications is shown in Figure 42. This filter will be applied for
all 'tmids'.
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Query: "target-protocol=17" Uri-Query: "target-protocol=17"
Observe: 0 Observe: 0
Figure 36: 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
[I-D.ietf-dots-signal-channel]. An example of a pre-or-ongoing- [I-D.ietf-dots-signal-channel]. An example of a pre-or-ongoing-
mitigation telemetry notification is shown in Figure 37. mitigation telemetry notification is shown in Figure 43.
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [ "pre-or-ongoing-mitigation": [
{ {
"tmid": 123, "tmid": 123,
"target": { "target": {
"target-prefix": [ "target-prefix": [
"2001:db8::1/128" "2001:db8::1/128"
] ]
skipping to change at page 50, line 26 skipping to change at page 55, line 26
17 17
], ],
"total-attack-traffic": [ "total-attack-traffic": [
{ {
"unit": "megabit-ps", "unit": "megabit-ps",
"mid-percentile-g": "900" "mid-percentile-g": "900"
} }
], ],
"attack-detail": [ "attack-detail": [
{ {
"attack-id": "an-id", "vendor-id": 1234,
"attack-id": 77,
"start-time": "1957818434", "start-time": "1957818434",
"attack-severity": "emergency" "attack-severity": "high"
} }
] ]
} }
] ]
} }
} }
Figure 37: Message Body of a Pre-or-Ongoing-Mitigation Telemetry Figure 43: Message Body of a Pre-or-Ongoing-Mitigation Telemetry
Notification from the DOTS Server Notification from the DOTS Server
A DOTS server sends the aggregate data for a target using 'total- A DOTS server sends the aggregate data for a target using 'total-
attack-traffic' attribute. The aggregate assumes that Uri-Query attack-traffic' attribute. The aggregate assumes that Uri-Query
filters are applied on the target. The DOTS server MAY include more filters are applied on the target. The DOTS server MAY include more
granular data when needed (that is, 'total-attack-traffic-protocol' granular data when needed (that is, 'total-attack-traffic-protocol'
and 'total-attack-traffic-port'). If a port filter (or protocol and 'total-attack-traffic-port'). If a port filter (or protocol
filter) is included in a request, 'total-attack-traffic-protocol' (or filter) is included in a request, 'total-attack-traffic-protocol' (or
'total-attack-traffic-port') conveys the data with the port (or 'total-attack-traffic-port') conveys the data with the port (or
protocol) filter applied. protocol) filter applied.
skipping to change at page 51, line 12 skipping to change at page 56, line 12
'top-talkers') for all targets of a domain, or when justified, send 'top-talkers') for all targets of a domain, or when justified, send
specific information (e.g., 'top-talkers') per individual targets. specific information (e.g., 'top-talkers') per individual targets.
The DOTS client may log pre-or-ongoing-mitigation telemetry data with The DOTS client may log pre-or-ongoing-mitigation telemetry data with
an alert sent to an administrator or a network controller. The DOTS an alert sent to an administrator or a network controller. The DOTS
client may send a mitigation request if the attack cannot be handled client may send a mitigation request if the attack cannot be handled
locally. locally.
A DOTS client that is not interested to receive pre-or-ongoing- A DOTS client that is not interested to receive pre-or-ongoing-
mitigation telemetry data for a target MUST send a delete request mitigation telemetry data for a target MUST send a delete request
similar to the one depicted in Figure 31. 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
[I-D.ietf-dots-signal-channel]). [I-D.ietf-dots-signal-channel]).
skipping to change at page 51, line 35 skipping to change at page 56, line 35
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"
type message defined in "ietf-dots-signal" so that these attributes type message defined in "ietf-dots-signal" so that these attributes
can be signalled by a DOTS client in a mitigation efficacy update can be signalled by a DOTS client in a mitigation efficacy update
(Figure 38). (Figure 44).
augment /ietf-signal:dots-signal/ietf-signal:message-type augment /ietf-signal:dots-signal/ietf-signal:message-type
/ietf-signal:mitigation-scope/ietf-signal:scope: /ietf-signal:mitigation-scope/ietf-signal:scope:
+--rw total-attack-traffic* [unit] {dots-telemetry}? +--rw total-attack-traffic* [unit] {dots-telemetry}?
| ... | ...
+--rw attack-detail* [attack-id] {dots-telemetry}? +--rw attack-detail* [vendor-id attack-id] {dots-telemetry}?
+--rw id? uint32 +--rw vendor-id uint32
+--rw attack-id string +--rw attack-id uint32
+--rw attack-name? string +--rw attack-name? string
+--rw attack-severity? attack-severity +--rw attack-severity? attack-severity
+--rw start-time? uint64 +--rw start-time? uint64
+--rw end-time? uint64 +--rw end-time? uint64
+--rw source-count +--rw source-count
| ... | ...
+--rw top-talker +--rw top-talker
... ...
Figure 38: Telemetry Efficacy Update Tree Structure Figure 44: Telemetry Efficacy Update Tree Structure
In order to signal telemetry data in a mitigation efficacy update, it In order to signal telemetry data in a mitigation efficacy update, it
is RECOMMENDED that the DOTS client has already established a DOTS is RECOMMENDED that the DOTS client has already established a DOTS
telemetry setup session with the server in 'idle' time. telemetry setup session with the server in 'idle' time.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
skipping to change at page 53, line 34 skipping to change at page 58, line 34
{ {
"ietf-dots-telemetry:unit": "megabit-ps", "ietf-dots-telemetry:unit": "megabit-ps",
"ietf-dots-telemetry:mid-percentile-g": "900" "ietf-dots-telemetry:mid-percentile-g": "900"
} }
] ]
} }
] ]
} }
} }
Figure 39: 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 [I-D.ietf-dots-signal-channel]). In
particular, DOTS clients can receive asynchronous notifications of particular, DOTS clients can receive asynchronous notifications of
the attack details from DOTS servers using the Observe option defined the attack details from DOTS servers using the Observe option defined
skipping to change at page 54, line 16 skipping to change at page 59, line 16
status updates sent to DOTS clients for which 'server-originated- status updates sent to DOTS clients for which 'server-originated-
telemetry' attribute is set to 'false'. telemetry' attribute is set to 'false'.
As defined in [RFC8612], the actual mitigation activities can include As defined in [RFC8612], the actual mitigation activities can include
several countermeasure mechanisms. The DOTS server signals the several countermeasure mechanisms. The DOTS server signals the
current operational status to each relevant countermeasure. A list current operational status to each relevant countermeasure. A list
of attacks detected by each countermeasure MAY also be included. The of attacks detected by each countermeasure MAY also be included. The
same attributes defined for Section 7.1.5 are applicable for same attributes defined for Section 7.1.5 are applicable for
describing the attacks detected and mitigated. describing the attacks detected and mitigated.
The "ietf-dots-telemetry" YANG module (Section 9) augments the The "ietf-dots-telemetry" YANG module (Section 9.1) augments the
"mitigation-scope" type message defined in "ietf-dots-signal" with "mitigation-scope" type message defined in "ietf-dots-signal" with
telemetry data as depicted in following tree structure: telemetry data as depicted in following tree structure:
augment /ietf-signal:dots-signal/ietf-signal:message-type augment /ietf-signal:dots-signal/ietf-signal:message-type
/ietf-signal:mitigation-scope/ietf-signal:scope: /ietf-signal:mitigation-scope/ietf-signal:scope:
+--ro total-traffic* [unit] {dots-telemetry}? +--ro total-traffic* [unit] {dots-telemetry}?
| +--ro unit unit | +--ro unit unit
| +--ro low-percentile-g? yang:gauge64 | +--ro low-percentile-g? yang:gauge64
| +--ro mid-percentile-g? yang:gauge64 | +--ro mid-percentile-g? yang:gauge64
| +--ro high-percentile-g? yang:gauge64 | +--ro high-percentile-g? yang:gauge64
skipping to change at page 54, line 47 skipping to change at page 59, line 47
| | +--ro embryonic? yang:gauge64 | | +--ro embryonic? yang:gauge64
| | +--ro connection-ps? yang:gauge64 | | +--ro connection-ps? yang:gauge64
| | +--ro request-ps? yang:gauge64 | | +--ro request-ps? yang:gauge64
| | +--ro partial-request-ps? yang:gauge64 | | +--ro partial-request-ps? yang:gauge64
| +--ro mid-percentile-c | +--ro mid-percentile-c
| | ... | | ...
| +--ro high-percentile-c | +--ro high-percentile-c
| | ... | | ...
| +--ro peak-c | +--ro peak-c
| ... | ...
+--rw attack-detail* [attack-id] {dots-telemetry}? +--rw attack-detail* [vendor-id attack-id] {dots-telemetry}?
+--rw id? uint32 +--rw vendor-id uint32
+--rw attack-id string +--rw attack-id uint32
+--rw attack-name? string +--rw attack-name? string
+--rw attack-severity? attack-severity +--rw attack-severity? attack-severity
+--rw start-time? uint64 +--rw start-time? uint64
+--rw end-time? uint64 +--rw end-time? uint64
+--rw source-count +--rw source-count
| +--rw low-percentile-g? yang:gauge64 | +--rw low-percentile-g? yang:gauge64
| +--rw mid-percentile-g? yang:gauge64 | +--rw mid-percentile-g? yang:gauge64
| +--rw high-percentile-g? yang:gauge64 | +--rw high-percentile-g? yang:gauge64
| +--rw peak-g? yang:gauge64 | +--rw peak-g? yang:gauge64
+--rw top-talker +--rw top-talker
skipping to change at page 55, line 40 skipping to change at page 60, line 40
| +--rw connection-ps? yang:gauge64 | +--rw connection-ps? yang:gauge64
| +--rw request-ps? yang:gauge64 | +--rw request-ps? yang:gauge64
| +--rw partial-request-ps? yang:gauge64 | +--rw partial-request-ps? yang:gauge64
+--rw mid-percentile-c +--rw mid-percentile-c
| ... | ...
+--rw high-percentile-c +--rw high-percentile-c
| ... | ...
+--rw peak-c +--rw peak-c
... ...
Figure 40 shows an example of an asynchronous notification of attack Figure 46 shows an example of an asynchronous notification of attack
mitigation status from the DOTS server. This notification signals mitigation status from the DOTS server. This notification signals
both the mid-percentile value of processed attack traffic and the both the mid-percentile value of processed attack traffic and the
peak percentile value of unique sources involved in the attack. peak percentile value of unique sources involved in the attack.
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"mid": 12332, "mid": 12332,
"mitigation-start": "1507818434", "mitigation-start": "1507818434",
skipping to change at page 56, line 29 skipping to change at page 61, line 29
"pkts-dropped": "333334444", "pkts-dropped": "333334444",
"pps-dropped": "432432", "pps-dropped": "432432",
"ietf-dots-telemetry:total-attack-traffic": [ "ietf-dots-telemetry:total-attack-traffic": [
{ {
"ietf-dots-telemetry:unit": "megabit-ps", "ietf-dots-telemetry:unit": "megabit-ps",
"ietf-dots-telemetry:mid-percentile-g": "900" "ietf-dots-telemetry:mid-percentile-g": "900"
} }
], ],
"ietf-dots-telemetry::attack-detail": [ "ietf-dots-telemetry::attack-detail": [
{ {
"ietf-dots-telemetry:attack-id": "another-id", "ietf-dots-telemetry:vendor-id": 1234,
"ietf-dots-telemetry:attack-id": 77,
"ietf-dots-telemetry:source-count": { "ietf-dots-telemetry:source-count": {
"ietf-dots-telemetry:peak-g": "10000" "ietf-dots-telemetry:peak-g": "10000"
} }
} }
] ]
} }
] ]
} }
} }
Figure 40: Response Body of a Mitigation Status With Telemetry Figure 46: Response Body of a Mitigation Status With Telemetry
Attributes Attributes
DOTS clients can filter out the asynchronous notifications from the DOTS clients can filter out the asynchronous notifications from the
DOTS server by indicating one or more Uri-Query options in its GET DOTS server by indicating one or more Uri-Query options in its GET
request. A Uri-Query option can include the following parameters: request. A Uri-Query option can include the following parameters:
target-prefix, lower-port, upper-port, target-protocol, target-fqdn, 'target-prefix', 'target-port', 'target-protocol', 'target-fqdn',
target-uri, alias-name. An example of request to subscribe to 'target-uri', 'alias-name', and 'c' (content) (Section 4.4). The
asynchronous notifications bound to the "http1" alias is shown in considerations discussed in Section 7.3 MUST be followed to include
Figure 41. multiple query values, ranges ('target-port', 'target-protocol'), and
wildcard name ('target-fqdn', 'target-uri').
An example of request to subscribe to asynchronous notifications
bound to the "http1" alias is shown in Figure 47.
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=12332" Uri-Path: "mid=12332"
Uri-Query: "target-alias=https1" Uri-Query: "target-alias=https1"
Observe: 0 Observe: 0
Figure 41: GET Request to Receive Asynchronous Notifications Filtered Figure 47: GET Request to Receive Asynchronous Notifications Filtered
using Uri-Query using Uri-Query
If the target query does not match the target of the enclosed 'mid' If the target query does not match the target of the enclosed 'mid'
as maintained by the DOTS server, the latter MUST respond with a 4.04 as maintained by the DOTS server, the latter MUST respond with a 4.04
(Not Found) error response code. The DOTS server MUST NOT add a new (Not Found) error response code. The DOTS server MUST NOT add a new
observe entry if this query overlaps with an existing one. observe entry if this query overlaps with an existing one.
9. YANG Module 9. YANG Modules
9.1. DOTS Signal Channel Telemetry YANG Module
This module uses types defined in [RFC6991] and [RFC8345]. This module uses types defined in [RFC6991] and [RFC8345].
<CODE BEGINS> file "ietf-dots-telemetry@2020-04-15.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 SSSS: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
skipping to change at page 58, line 42 skipping to change at page 63, line 47
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2020-04-15 { revision 2020-05-04 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Distributed Denial-of-Service Open Threat "RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry"; Signaling (DOTS) Telemetry";
} }
feature dots-telemetry { feature dots-telemetry {
description description
"This feature means that the DOTS signal channel is able "This feature indicates that the DOTS signal channel is able
to convey DOTS telemetry data between DOTS clients and to convey DOTS telemetry data between DOTS clients and
servers."; servers.";
} }
typedef attack-severity { typedef attack-severity {
type enumeration { type enumeration {
enum emergency { enum none {
value 1; value 1;
description description
"The attack is severe: emergency."; "No effect on the DOTS client domain.";
} }
enum critical { enum low {
value 2; value 2;
description description
"The attack is critical."; "Minimal effect on the DOTS client domain.";
} }
enum alert { enum medium {
value 3; value 3;
description description
"This is an alert."; "A subset of DOTS client domain resources are
out of service.";
}
enum high {
value 4;
description
"The DOTS client domain is under extremly severe
conditions.";
}
enum unknown {
value 5;
description
"The impact of the attack is not known.";
} }
} }
description description
"Enumeration for attack severity."; "Enumeration for attack severity.";
reference
"RFC 7970: The Incident Object Description Exchange
Format Version 2";
} }
typedef unit-type { typedef unit-type {
type enumeration { type enumeration {
enum packet-ps { enum packet-ps {
value 1; value 1;
description description
"Packets per second (pps)."; "Packets per second (pps).";
} }
enum bit-ps { enum bit-ps {
skipping to change at page 62, line 22 skipping to change at page 67, line 43
} }
description description
"Enumeration to indicate the overall measurement period."; "Enumeration to indicate the overall measurement period.";
} }
typedef sample { typedef sample {
type enumeration { type enumeration {
enum second { enum second {
value 1; value 1;
description description
"Second."; " A one second measurement period.";
} }
enum 5-seconds { enum 5-seconds {
value 2; value 2;
description description
"5 seconds."; "5 seconds measurement period.";
} }
enum 30-seconds { enum 30-seconds {
value 3; value 3;
description description
"30 seconds."; "30 seconds measurement period.";
} }
enum minute { enum minute {
value 4; value 4;
description description
"One minute."; "One minute measurement period.";
} }
enum 5-minutes { enum 5-minutes {
value 5; value 5;
description description
"5 minutes."; "5 minutes measurement period.";
} }
enum 10-minutes { enum 10-minutes {
value 6; value 6;
description description
"10 minutes."; "10 minutes measurement period.";
} }
enum 30-minutes { enum 30-minutes {
value 7; value 7;
description description
"30 minutes."; "30 minutes measurement period.";
} }
enum hour { enum hour {
value 8; value 8;
description description
"One hour."; "One hour measurement period.";
} }
} }
description description
"Enumeration to indicate the measurement perdiod."; "Enumeration to indicate the measurement period.";
} }
typedef percentile { typedef percentile {
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
} }
description description
"The nth percentile of a set of data is the "The nth percentile of a set of data is the
value at which n percent of the data is below it."; value at which n percent of the data is below it.";
} }
typedef query-type {
type enumeration {
enum target-prefix {
value 1;
description
"Query based on target prefix.";
}
enum target-port {
value 2;
description
"Query based on target port number.";
}
enum target-protocol {
value 3;
description
"Query based on target protocol.";
}
enum target-fqdn {
value 4;
description
"Query based on target FQDN.";
}
enum target-uri {
value 5;
description
"Query based on target URI.";
}
enum target-alias {
value 6;
description
"Query based on target alias.";
}
enum mid {
value 7;
description
"Query based on mitigation identifier (mid).";
}
enum source-prefix {
value 8;
description
"Query based on source prefix.";
}
enum source-port {
value 9;
description
"Query based on source port number.";
}
enum source-icmp-type {
value 10;
description
"Query based on ICMP type";
}
enum content {
value 11;
description
"Query based on 'c' Uri-Query option that is used
to control the selection of configuration
and non-configuration data nodes.";
reference
"Section 4.4.2 of RFC SSSS.";
}
}
description
"Enumeration support for query types that can be used
in a GET request to filter out data.";
}
grouping percentile-config { grouping percentile-config {
description description
"Configuration of low, mid, and high percentile values."; "Configuration of low, mid, and high percentile values.";
leaf measurement-interval { leaf measurement-interval {
type interval; type interval;
description description
"Defines the period on which percentiles are computed."; "Defines the period on which percentiles are computed.";
} }
leaf measurement-sample { leaf measurement-sample {
type sample; type sample;
skipping to change at page 64, line 31 skipping to change at page 71, line 21
this means high-percentiles are disabled."; this means high-percentiles are disabled.";
} }
} }
grouping percentile { grouping percentile {
description description
"Generic grouping for percentile."; "Generic grouping for percentile.";
leaf low-percentile-g { leaf low-percentile-g {
type yang:gauge64; type yang:gauge64;
description description
"Low traffic."; "Low percentile value.";
} }
leaf mid-percentile-g { leaf mid-percentile-g {
type yang:gauge64; type yang:gauge64;
description description
"Mid percentile."; "Mid percentile value.";
} }
leaf high-percentile-g { leaf high-percentile-g {
type yang:gauge64; type yang:gauge64;
description description
"High percentile."; "High percentile value.";
} }
leaf peak-g { leaf peak-g {
type yang:gauge64; type yang:gauge64;
description description
"Peak"; "Peak value.";
} }
} }
grouping unit-config { grouping unit-config {
description description
"Generic grouping for unit configuration."; "Generic grouping for unit configuration.";
list unit-config { list unit-config {
key "unit"; key "unit";
description description
"Controls which units are allowed when sharing telemetry "Controls which unit types are allowed when sharing
data."; telemetry data.";
leaf unit { leaf unit {
type unit-type; type unit-type;
description description
"Can be packet-ps, bit-ps, or byte-ps."; "Can be packet-ps, bit-ps, or byte-ps.";
} }
leaf unit-status { leaf unit-status {
type boolean; type boolean;
mandatory true; mandatory true;
description description
"Enable/disable the use of the measurement unit."; "Enable/disable the use of the measurement unit type.";
} }
} }
} }
grouping traffic-unit { grouping traffic-unit {
description description
"Grouping of traffic as a function of measurement unit."; "Grouping of traffic as a function of the measurement unit.";
leaf unit { leaf unit {
type unit; type unit;
description description
"The traffic can be measured using unit types: packets "The traffic can be measured using unit types: packet-ps,
per second (PPS), Bits per Second (BPS), and/or bit-ps, or byte-ps. DOTS agents auto-scale to the appropriate
bytes per second. DOTS agents auto-scale to the appropriate
units (e.g., megabit-ps, kilobit-ps)."; units (e.g., megabit-ps, kilobit-ps).";
} }
uses percentile; uses percentile;
} }
grouping traffic-unit-protocol { grouping traffic-unit-protocol {
description description
"Grouping of traffic of a given transport protocol as "Grouping of traffic of a given transport protocol as
a function of measurement unit."; a function of the measurement unit.";
leaf protocol { leaf protocol {
type uint8; type uint8;
description description
"The transport protocol. "The transport protocol.
Values are taken from the IANA Protocol Numbers registry: Values are taken from the IANA Protocol Numbers registry:
<https://www.iana.org/assignments/protocol-numbers/>. <https://www.iana.org/assignments/protocol-numbers/>.
For example, this field contains 6 for TCP, For example, this parameter contains 6 for TCP,
17 for UDP, 33 for DCCP, or 132 for SCTP."; 17 for UDP, 33 for DCCP, or 132 for SCTP.";
} }
uses traffic-unit; uses traffic-unit;
} }
grouping traffic-unit-port { grouping traffic-unit-port {
description description
"Grouping of traffic bound to port number as "Grouping of traffic bound to a port number as
a function of measurement unit."; a function of the measurement unit.";
leaf port { leaf port {
type inet:port-number; type inet:port-number;
description description
"Port number."; "Port number.";
} }
uses traffic-unit; uses traffic-unit;
} }
grouping total-connection-capacity { grouping total-connection-capacity {
description description
"Total Connections Capacity. If the target is subjected "Total Connections Capacity. These attributes are
to resource consuming DDoS attack, these attributes are
useful to detect resource consuming DDoS attacks"; useful to detect resource consuming DDoS attacks";
leaf connection { leaf connection {
type uint64; type uint64;
description description
"The maximum number of simultaneous connections that "The maximum number of simultaneous connections that
are allowed to the target server. The threshold is are allowed to the target server.";
transport-protocol specific because the target server
could support multiple protocols.";
} }
leaf connection-client { leaf connection-client {
type uint64; type uint64;
description description
"The maximum number of simultaneous connections that "The maximum number of simultaneous connections that
are allowed to the target server per client."; are allowed to the target server per client.";
} }
leaf embryonic { leaf embryonic {
type uint64; type uint64;
description description
"The maximum number of simultaneous embryonic connections "The maximum number of simultaneous embryonic connections
that are allowed to the target server. The term 'embryonic that are allowed to the target server. The term 'embryonic
connection' refers to a connection whose connection handshake connection' refers to a connection whose connection handshake
is not finished and embryonic connection is only possible in is not finished. Embryonic connection is only possible in
connection-oriented transport protocols like TCP or SCTP."; connection-oriented transport protocols like TCP or SCTP.";
} }
leaf embryonic-client { leaf embryonic-client {
type uint64; type uint64;
description description
"The maximum number of simultaneous embryonic connections "The maximum number of simultaneous embryonic connections
that are allowed to the target server per client."; that are allowed to the target server per client.";
} }
leaf connection-ps { leaf connection-ps {
type uint64; type uint64;
skipping to change at page 67, line 44 skipping to change at page 74, line 31
leaf partial-request-client-ps { leaf partial-request-client-ps {
type uint64; type uint64;
description description
"The maximum number of partial requests allowed per "The maximum number of partial requests allowed per
second to the target server per client."; second to the target server per client.";
} }
} }
grouping total-connection-capacity-protocol { grouping total-connection-capacity-protocol {
description description
"Total Connections Capacity per protocol. If the target is subjected "Total Connections Capacity per protocol. These attributes are
to resource consuming DDoS attack, these attributes are useful to detect resource consuming DDoS attacks.";
useful to detect resource consuming DDoS attacks";
leaf protocol { leaf protocol {
type uint8; type uint8;
description description
"The transport protocol. "The transport protocol.
Values are taken from the IANA Protocol Numbers registry: Values are taken from the IANA Protocol Numbers registry:
<https://www.iana.org/assignments/protocol-numbers/>."; <https://www.iana.org/assignments/protocol-numbers/>.";
} }
uses total-connection-capacity; uses total-connection-capacity;
} }
grouping connection { grouping connection {
description description
"A set of attributes which represent the attack "A set of attributes which represent the attack
characteristics"; characteristics";
leaf connection { leaf connection {
skipping to change at page 69, line 49 skipping to change at page 76, line 35
leaf port { leaf port {
type inet:port-number; type inet:port-number;
description description
"Port number."; "Port number.";
} }
uses connection-protocol; uses connection-protocol;
} }
grouping connection-protocol-percentile { grouping connection-protocol-percentile {
description description
"Total attack connections."; "Total attack connections per protocol.";
list low-percentile-l { list low-percentile-l {
key "protocol"; key "protocol";
description description
"Low percentile of attack connections."; "Low percentile of attack connections per protocol.";
uses connection-protocol; uses connection-protocol;
} }
list mid-percentile-l { list mid-percentile-l {
key "protocol"; key "protocol";
description description
"Mid percentile of attack connections."; "Mid percentile of attack connections per protocol.";
uses connection-protocol; uses connection-protocol;
} }
list high-percentile-l { list high-percentile-l {
key "protocol"; key "protocol";
description description
"High percentile of attack connections."; "High percentile of attack connections per protocol.";
uses connection-protocol; uses connection-protocol;
} }
list peak-l { list peak-l {
key "protocol"; key "protocol";
description description
"Peak attack connections."; "Peak attack connections per protocol.";
uses connection-protocol; uses connection-protocol;
} }
} }
grouping connection-protocol-port-percentile { grouping connection-protocol-port-percentile {
description description
"Total attack connections."; "Total attack connections per port number.";
list low-percentile-l { list low-percentile-l {
key "protocol port"; key "protocol port";
description description
"Low percentile of attack connections."; "Low percentile of attack connections per port number.";
uses connection-port; uses connection-port;
} }
list mid-percentile-l { list mid-percentile-l {
key "protocol port"; key "protocol port";
description description
"Mid percentile of attack connections."; "Mid percentile of attack connections per port number.";
uses connection-port; uses connection-port;
} }
list high-percentile-l { list high-percentile-l {
key "protocol port"; key "protocol port";
description description
"High percentile of attack connections."; "High percentile of attack connections per port number.";
uses connection-port; uses connection-port;
} }
list peak-l { list peak-l {
key "protocol port"; key "protocol port";
description description
"Peak attack connections."; "Peak attack connections per port number.";
uses connection-port; uses connection-port;
} }
} }
grouping attack-detail { grouping attack-detail {
description description
"Various information and details that describe the on-going "Various details that describe the on-going
attacks that needs 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 vendor-specific (such as a SYN Flood) along with new emerging or vendor-specific
attacks."; attacks.";
leaf id { leaf vendor-id {
type uint32; type uint32;
description description
"Vendor ID is a security vendor's Enterprise Number."; "Vendor ID is a security vendor's Enterprise Number.";
} }
leaf attack-id { leaf attack-id {
type string; type uint32;
description description
"Unique identifier assigned by the vendor for the attack."; "Unique identifier assigned by the vendor for the attack.";
} }
leaf attack-name { leaf attack-name {
type string; type string;
description description
"Textual representation of attack description. Natural Language "Textual representation of attack description. Natural Language
Processing techniques (e.g., word embedding) can possibly be used Processing techniques (e.g., word embedding) can possibly be used
to map the attack description to an attack type."; to map the attack description to an attack type.";
} }
skipping to change at page 77, line 4 skipping to change at page 83, line 38
key "unit protocol"; key "unit protocol";
description description
"Total attack traffic per protocol."; "Total attack traffic per protocol.";
uses traffic-unit-protocol; uses traffic-unit-protocol;
} }
list total-attack-traffic-port { list total-attack-traffic-port {
key "unit port"; key "unit port";
description description
"Total attack traffic per port."; "Total attack traffic per port.";
uses traffic-unit-port; uses traffic-unit-port;
} }
container total-attack-connection { container total-attack-connection {
description description
"Total attack connections."; "Total attack connections.";
uses connection-protocol-percentile; uses connection-protocol-percentile;
} }
container total-attack-connection-port { container total-attack-connection-port {
description description
"Total attack connections."; "Total attack connections.";
uses connection-protocol-port-percentile; uses connection-protocol-port-percentile;
} }
list attack-detail { list attack-detail {
key "attack-id"; key "vendor-id attack-id";
description description
"Provides a set of attack details."; "Provides a set of attack details.";
uses attack-detail; uses attack-detail;
container top-talker { container top-talker {
description description
"Lists the top attack sources."; "Lists the top attack sources.";
uses top-talker; uses top-talker;
} }
} }
} }
skipping to change at page 78, line 5 skipping to change at page 84, line 39
"Total attack traffic."; "Total attack traffic.";
uses traffic-unit; uses traffic-unit;
} }
container total-attack-connection { container total-attack-connection {
config false; config false;
description description
"Total attack connections."; "Total attack connections.";
uses connection-percentile; uses connection-percentile;
} }
list attack-detail { list attack-detail {
key "attack-id"; key "vendor-id attack-id";
description description
"Atatck details"; "Atatck details";
uses attack-detail; uses attack-detail;
container top-talker { container top-talker {
description description
"Top attack sources."; "Top attack sources.";
uses top-talker-aggregate; uses top-talker-aggregate;
} }
} }
} }
skipping to change at page 79, line 19 skipping to change at page 86, line 4
"Minimum acceptable configuration values."; "Minimum acceptable configuration values.";
uses percentile-config; uses percentile-config;
leaf telemetry-notify-interval { leaf telemetry-notify-interval {
type uint32 { type uint32 {
range "1 .. 3600"; range "1 .. 3600";
} }
units "seconds"; units "seconds";
description description
"Minimum number of seconds between successive "Minimum number of seconds between successive
telemetry notifications."; telemetry notifications.";
} }
} }
container supported-units { container supported-units {
config false; config false;
description description
"Supported units and default activation status."; "Supported units and default activation status.";
uses unit-config; uses unit-config;
} }
leaf-list query-type {
type query-type;
config false;
description
"Indicates which query types are supported by
the server.";
}
list telemetry { list telemetry {
key "cuid tsid"; key "cuid tsid";
description description
"The telemetry data per DOTS client."; "The telemetry data per DOTS client.";
leaf cuid { leaf cuid {
type string; type string;
description description
"A unique identifier that is "A unique identifier that is
generated by a DOTS client to prevent generated by a DOTS client to prevent
request collisions. It is expected that the request collisions. It is expected that the
skipping to change at page 83, line 4 skipping to change at page 89, line 40
description description
"Reference a list of associated mitigation requests."; "Reference a list of associated mitigation requests.";
} }
} }
uses pre-or-ongoing-mitigation; uses pre-or-ongoing-mitigation;
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
9.2. Vendor Attack Mapping Details YANG Module
<CODE BEGINS> file "ietf-dots-mapping@2020-05-04.yang"
module ietf-dots-mapping {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-mapping";
prefix dots-mapping;
import ietf-dots-data-channel {
prefix ietf-data;
reference
"RFC DDDD: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Data Channel Specification";
}
organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org>
Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>
Author: Jon Shallow
<mailto:supjps-ietf@jpshallow.com>";
description
"This module contains YANG definitions for the sharing
DDoS attack mapping details between a DOTS client and
a DOTS server, by means of the DOTS data channel.
Copyright (c) 2020 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2020-05-04 {
description
"Initial revision.";
reference
"RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry";
}
feature dots-telemetry {
description
"This feature indicates that DOTS telemetry data can be
shared between DOTS clients and servers.";
}
grouping attack-mapping {
description
"A set of information used for sharing vendor attack mapping
information with a peer.";
list vendor {
key "vendor-id";
description
"Vendor attack mapping information of the client/server";
leaf vendor-id {
type uint32;
description
"Vendor ID is a security vendor's Enterprise Number.";
}
list attack-mapping {
key "attack-id";
description
"Attack mapping details.";
leaf attack-id {
type uint32;
description
"Unique identifier assigned by the vendor for the attack.";
}
leaf attack-name {
type string;
mandatory true;
description
"Textual representation of attack description. Natural Language
Processing techniques (e.g., word embedding) can possibly be used
to map the attack description to an attack type.";
}
}
}
}
augment "/ietf-data:dots-data/ietf-data:dots-client" {
if-feature "dots-telemetry";
container vendor-mapping {
description
"Clients use this feature to share their vendor
attack mapping information with DOTS servers.";
uses attack-mapping;
}
}
augment "/ietf-data:dots-data/ietf-data:capabilities" {
if-feature "dots-telemetry";
leaf vendor-mapping-enabled {
type boolean;
config false;
description
"Indicates that the server supports sharing
attack vendor mapping details with DOTS clients.";
}
}
augment "/ietf-data:dots-data" {
if-feature "dots-telemetry";
container vendor-mapping {
config false;
description
"Includes the list of vendor attack mapping details
that will be shared upon request with DOTS clients.";
uses attack-mapping;
}
}
}
<CODE ENDS>
10. YANG/JSON Mapping Parameters to CBOR 10. YANG/JSON Mapping Parameters to CBOR
All DOTS telemetry parameters in the payload of the DOTS signal All DOTS telemetry parameters in the payload of the DOTS signal
channel MUST be mapped to CBOR types as shown in the following table: channel MUST be mapped to CBOR types as shown in the following table:
o Implementers may use the values in: https://github.com/boucadair/ o Implementers may use the values in: https://github.com/boucadair/
draft-dots-telemetry/blob/master/mapping-table.txt draft-dots-telemetry/blob/master/mapping-table.txt
+----------------------+-------------+------+---------------+--------+ +----------------------+-------------+------+---------------+--------+
| Parameter Name | YANG | CBOR | CBOR Major | JSON | | Parameter Name | YANG | CBOR | CBOR Major | JSON |
skipping to change at page 84, line 13 skipping to change at page 93, line 32
| partial-request- | | | | | | partial-request- | | | | |
| client-ps | uint64 |TBA29 | 0 unsigned | String | | client-ps | uint64 |TBA29 | 0 unsigned | String |
| total-attack- | | | | | | total-attack- | | | | |
| connection | container |TBA30 | 5 map | Object | | connection | container |TBA30 | 5 map | Object |
| low-percentile-l | list |TBA31 | 4 array | Array | | low-percentile-l | list |TBA31 | 4 array | Array |
| mid-percentile-l | list |TBA32 | 4 array | Array | | mid-percentile-l | list |TBA32 | 4 array | Array |
| high-percentile-l | list |TBA33 | 4 array | Array | | high-percentile-l | list |TBA33 | 4 array | Array |
| peak-l | list |TBA34 | 4 array | Array | | peak-l | list |TBA34 | 4 array | Array |
| attack-detail | list |TBA35 | 4 array | Array | | attack-detail | list |TBA35 | 4 array | Array |
| id | uint32 |TBA36 | 0 unsigned | Number | | id | uint32 |TBA36 | 0 unsigned | Number |
| attack-id | string |TBA37 | 3 text string | String | | attack-id | uint32 |TBA37 | 0 unsigned | Number |
| attack-name | string |TBA38 | 3 text string | String | | attack-name | string |TBA38 | 3 text string | String |
| attack-severity | enumeration |TBA39 | 0 unsigned | String | | attack-severity | enumeration |TBA39 | 0 unsigned | String |
| start-time | uint64 |TBA40 | 0 unsigned | String | | start-time | uint64 |TBA40 | 0 unsigned | String |
| end-time | uint64 |TBA41 | 0 unsigned | String | | end-time | uint64 |TBA41 | 0 unsigned | String |
| source-count | container |TBA42 | 5 map | Object | | source-count | container |TBA42 | 5 map | Object |
| top-talker | container |TBA43 | 5 map | Object | | top-talker | container |TBA43 | 5 map | Object |
| spoofed-status | boolean |TBA44 | 7 bits 20 | False | | spoofed-status | boolean |TBA44 | 7 bits 20 | False |
| | | | 7 bits 21 | True | | | | | 7 bits 21 | True |
| low-percentile-c | container |TBA45 | 5 map | Object | | low-percentile-c | container |TBA45 | 5 map | Object |
| mid-percentile-c | container |TBA46 | 5 map | Object | | mid-percentile-c | container |TBA46 | 5 map | Object |
skipping to change at page 85, line 20 skipping to change at page 94, line 39
| -protocol | list |TBA72 | 4 array | Array | | -protocol | list |TBA72 | 4 array | Array |
| total-traffic- port | list |TBA73 | 4 array | Array | | total-traffic- port | list |TBA73 | 4 array | Array |
| total-attack- | | | | | | total-attack- | | | | |
| traffic-protocol | list |TBA74 | 4 array | Array | | traffic-protocol | list |TBA74 | 4 array | Array |
| total-attack- | | | | | | total-attack- | | | | |
| traffic-port | list |TBA75 | 4 array | Array | | traffic-port | list |TBA75 | 4 array | Array |
| total-attack- | | | | | | total-attack- | | | | |
| connection-port | list |TBA76 | 4 array | Array | | connection-port | list |TBA76 | 4 array | Array |
| port | inet: | | | | | port | inet: | | | |
| | port-number|TBA77 | 0 unsigned | Number | | | port-number|TBA77 | 0 unsigned | Number |
| query-type | leaf-list |TBA78 | 4 array | Array |
| | | | 0 unsigned | String |
| vendor-id | uint32 |TBA79 | 0 unsigned | Number |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| telemetry-setup | container |TBA80 | 5 map | Object | | telemetry-setup | container |TBA80 | 5 map | Object |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| total-traffic | list |TBA81 | 4 array | Array | | total-traffic | list |TBA81 | 4 array | Array |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| unit | enumeration |TBA82 | 0 unsigned | String | | unit | enumeration |TBA82 | 0 unsigned | String |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| low-percentile-g | yang:gauge64|TBA83 | 0 unsigned | String | | low-percentile-g | yang:gauge64|TBA83 | 0 unsigned | String |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| mid-percentile-g | yang:gauge64|TBA84 | 0 unsigned | String | | mid-percentile-g | yang:gauge64|TBA84 | 0 unsigned | String |
skipping to change at page 86, line 14 skipping to change at page 95, line 36
| connection-ps | uint64 |TBA95 | 0 unsigned | String | | connection-ps | uint64 |TBA95 | 0 unsigned | String |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| request-ps | uint64 |TBA96 | 0 unsigned | String | | request-ps | uint64 |TBA96 | 0 unsigned | String |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| partial-request-ps | uint64 |TBA97 | 0 unsigned | String | | partial-request-ps | uint64 |TBA97 | 0 unsigned | String |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| attack-detail | list |TBA98 | 4 array | Array | | attack-detail | list |TBA98 | 4 array | Array |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| id | uint32 |TBA99 | 0 unsigned | Number | | id | uint32 |TBA99 | 0 unsigned | Number |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| attack-id | string |TBA100| 3 text string | String | | attack-id | uint32 |TBA100| 0 unsigned | Number |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| attack-name | string |TBA101| 3 text string | String | | attack-name | string |TBA101| 3 text string | String |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| attack-severity | enumeration |TBA102| 0 unsigned | String | | attack-severity | enumeration |TBA102| 0 unsigned | String |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| start-time | uint64 |TBA103| 0 unsigned | String | | start-time | uint64 |TBA103| 0 unsigned | String |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| end-time | uint64 |TBA104| 0 unsigned | String | | end-time | uint64 |TBA104| 0 unsigned | String |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| source-count | container |TBA105| 5 map | Object | | source-count | container |TBA105| 5 map | Object |
skipping to change at page 86, line 51 skipping to change at page 96, line 25
| | port-number|TBA112| 0 unsigned | Number | | | port-number|TBA112| 0 unsigned | Number |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| source-icmp-type- | list |TBA113| 4 array | Array | | source-icmp-type- | list |TBA113| 4 array | Array |
| range | | | | | | range | | | | |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| lower-type | uint8 |TBA114| 0 unsigned | Number | | lower-type | uint8 |TBA114| 0 unsigned | Number |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| upper-type | uint8 |TBA115| 0 unsigned | Number | | upper-type | uint8 |TBA115| 0 unsigned | Number |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| telemetry | container |TBA116| 5 map | Object | | telemetry | container |TBA116| 5 map | Object |
| ietf-dots-telemetry: | | | | |
| vendor-id | uint32 |TBA117| 0 unsigned | Number |
+----------------------+-------------+------+---------------+--------+ +----------------------+-------------+------+---------------+--------+
11. IANA Considerationsr 11. IANA Considerationsr
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.
skipping to change at page 88, line 17 skipping to change at page 97, line 42
| partial-request- | TBA29 | 0 | IESG | [RFCXXXX] | | partial-request- | TBA29 | 0 | IESG | [RFCXXXX] |
| client-ps | | | | | | client-ps | | | | |
| total-attack- | TBA30 | 5 | IESG | [RFCXXXX] | | total-attack- | TBA30 | 5 | IESG | [RFCXXXX] |
| connection | | | | | | connection | | | | |
| low-percentile-l | TBA31 | 4 | IESG | [RFCXXXX] | | low-percentile-l | TBA31 | 4 | IESG | [RFCXXXX] |
| mid-percentile-l | TBA32 | 4 | IESG | [RFCXXXX] | | mid-percentile-l | TBA32 | 4 | IESG | [RFCXXXX] |
| high-percentile-l | TBA33 | 4 | IESG | [RFCXXXX] | | high-percentile-l | TBA33 | 4 | IESG | [RFCXXXX] |
| peak-l | TBA34 | 4 | IESG | [RFCXXXX] | | peak-l | TBA34 | 4 | IESG | [RFCXXXX] |
| attack-detail | TBA35 | 4 | IESG | [RFCXXXX] | | attack-detail | TBA35 | 4 | IESG | [RFCXXXX] |
| id | TBA36 | 0 | IESG | [RFCXXXX] | | id | TBA36 | 0 | IESG | [RFCXXXX] |
| attack-id | TBA37 | 3 | IESG | [RFCXXXX] | | attack-id | TBA37 | 0 | IESG | [RFCXXXX] |
| attack-name | TBA38 | 3 | IESG | [RFCXXXX] | | attack-name | TBA38 | 3 | IESG | [RFCXXXX] |
| attack-severity | TBA39 | 0 | IESG | [RFCXXXX] | | attack-severity | TBA39 | 0 | IESG | [RFCXXXX] |
| start-time | TBA40 | 0 | IESG | [RFCXXXX] | | start-time | TBA40 | 0 | IESG | [RFCXXXX] |
| end-time | TBA41 | 0 | IESG | [RFCXXXX] | | end-time | TBA41 | 0 | IESG | [RFCXXXX] |
| source-count | TBA42 | 5 | IESG | [RFCXXXX] | | source-count | TBA42 | 5 | IESG | [RFCXXXX] |
| top-talker | TBA43 | 5 | IESG | [RFCXXXX] | | top-talker | TBA43 | 5 | IESG | [RFCXXXX] |
| spoofed-status | TBA44 | 7 | IESG | [RFCXXXX] | | spoofed-status | TBA44 | 7 | IESG | [RFCXXXX] |
| low-percentile-c | TBA45 | 5 | IESG | [RFCXXXX] | | low-percentile-c | TBA45 | 5 | IESG | [RFCXXXX] |
| mid-percentile-c | TBA46 | 5 | IESG | [RFCXXXX] | | mid-percentile-c | TBA46 | 5 | IESG | [RFCXXXX] |
| high-percentile-c | TBA47 | 5 | IESG | [RFCXXXX] | | high-percentile-c | TBA47 | 5 | IESG | [RFCXXXX] |
skipping to change at page 89, line 20 skipping to change at page 98, line 45
| total-traffic- | TBA72 | 4 | IESG | [RFCXXXX] | | total-traffic- | TBA72 | 4 | IESG | [RFCXXXX] |
| -protocol | | | | | | -protocol | | | | |
| total-traffic-port | TBA73 | 4 | IESG | [RFCXXXX] | | total-traffic-port | TBA73 | 4 | IESG | [RFCXXXX] |
| total-attack- | TBA74 | 4 | IESG | [RFCXXXX] | | total-attack- | TBA74 | 4 | IESG | [RFCXXXX] |
| traffic-protocol | | | | | | traffic-protocol | | | | |
| total-attack- | TBA75 | 4 | IESG | [RFCXXXX] | | total-attack- | TBA75 | 4 | IESG | [RFCXXXX] |
| traffic-port | | | | | | traffic-port | | | | |
| total-attack- | TBA76 | 4 | IESG | [RFCXXXX] | | total-attack- | TBA76 | 4 | IESG | [RFCXXXX] |
| connection-port | | | | | | connection-port | | | | |
| port | TBA77 | 0 | IESG | [RFCXXXX] | | port | TBA77 | 0 | IESG | [RFCXXXX] |
| query-type | TBA78 | 4 | IESG | [RFCXXXX] |
| vendor-id | TBA79 | 0 | IESG | [RFCXXXX] |
| ietf-dots-telemetry: | TBA80 | 5 | IESG | [RFCXXXX] | | ietf-dots-telemetry: | TBA80 | 5 | IESG | [RFCXXXX] |
| telemetry-setup | | | | | | telemetry-setup | | | | |
| ietf-dots-telemetry: | TBA81 | 0 | IESG | [RFCXXXX] | | ietf-dots-telemetry: | TBA81 | 0 | IESG | [RFCXXXX] |
| total-traffic | | | | | | total-traffic | | | | |
| ietf-dots-telemetry: | TBA82 | 0 | IESG | [RFCXXXX] | | ietf-dots-telemetry: | TBA82 | 0 | IESG | [RFCXXXX] |
| unit | | | | | | unit | | | | |
| ietf-dots-telemetry: | TBA83 | 0 | IESG | [RFCXXXX] | | ietf-dots-telemetry: | TBA83 | 0 | IESG | [RFCXXXX] |
| low-percentile-g | | | | | | low-percentile-g | | | | |
| ietf-dots-telemetry: | TBA84 | 0 | IESG | [RFCXXXX] | | ietf-dots-telemetry: | TBA84 | 0 | IESG | [RFCXXXX] |
| mid-percentile-g | | | | | | mid-percentile-g | | | | |
skipping to change at page 90, line 48 skipping to change at page 100, line 27
| upper-port | TBA112| 0 | IESG | [RFCXXXX] | | upper-port | TBA112| 0 | IESG | [RFCXXXX] |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| source-icmp-type- | TBA113| 4 | IESG | [RFCXXXX] | | source-icmp-type- | TBA113| 4 | IESG | [RFCXXXX] |
| range | | | | | | range | | | | |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| lower-type | TBA114| 0 | IESG | [RFCXXXX] | | lower-type | TBA114| 0 | IESG | [RFCXXXX] |
| ietf-dots-telemetry: | | | | | | ietf-dots-telemetry: | | | | |
| upper-type | TBA115| 0 | IESG | [RFCXXXX] | | upper-type | TBA115| 0 | IESG | [RFCXXXX] |
| ietf-dots-telemetry: | TBA116| 5 | IESG | [RFCXXXX] | | ietf-dots-telemetry: | TBA116| 5 | IESG | [RFCXXXX] |
| telemetry | | | | | | telemetry | | | | |
| ietf-dots-telemetry: | TBA117| 0 | IESG | [RFCXXXX] |
| 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 Code Label Description Reference
TBA overlapping-pipes Overlapping pipe scope [RFCXXXX] TBA overlapping-pipes Overlapping pipe scope [RFCXXXX]
11.3. DOTS Signal Telemetry YANG Module 11.3. DOTS Signal Telemetry YANG Module
This document requests IANA to register the following URI in the "ns" This document requests IANA to register the following URIs in the
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.
This document requests IANA to register the following YANG module in URI: urn:ietf:params:xml:ns:yang:ietf-dots-mapping
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG modules in
the "YANG Module Names" subregistry [RFC7950] within the "YANG the "YANG Module Names" subregistry [RFC7950] within the "YANG
Parameters" registry. Parameters" registry.
name: ietf-dots-telemetry name: ietf-dots-telemetry
namespace: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry namespace: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry
maintained by IANA: N maintained by IANA: N
prefix: dots-telemetry prefix: dots-telemetry
reference: RFC XXXX reference: RFC XXXX
name: ietf-dots-mapping
namespace: urn:ietf:params:xml:ns:yang:ietf-dots-mapping
maintained by IANA: N
prefix: dots-mapping
reference: RFC XXXX
12. Security Considerations 12. Security Considerations
Security considerations in [I-D.ietf-dots-signal-channel] need to be 12.1. DOTS Signal Channel Telemetry
taken into consideration.
Security considerations in Section 10 of
[I-D.ietf-dots-signal-channel] need to be taken into consideration.
The DOTS telemetry information includes DOTS client network topology,
DOTS client domain pipe capacity, normal traffic baseline and
connections capacity, and threat and mitigation information. Such
information is sensitive; it MUST be protected at rest by the DOTS
server domain to prevent data leakage.
DOTS clients are typically trusted devices by the DOTS client domain.
DOTS clients may be co-located on network security services (e.g.,
firewall) and a compromised security service potentially can do a lot
more damage to the network. This assumption differs from the often
held view that devices are untrusted, often referred to as the "zero-
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
prevented by monitoring and auditing DOTS clients to detect
misbehavior and to deter misuse, and by only authorizing the DOTS
client to convey the DOTS telemetry for specific target resources
(e.g., an application server is authorized to 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
variation of dealing with compromised DOTS clients as discussed in
Section 10 of [I-D.ietf-dots-signal-channel].
DOTS servers must be capable of defending themselves against DoS
attacks from compromised DOTS clients. The following non-
comprehensive list of mitigation techniques can be used by a DOTS
server to handle misbehaving DOTS clients:
o The probing rate (defined in Section 4.5 of
[I-D.ietf-dots-signal-channel]) can be used to limit the average
data rate to the DOTS server.
o Rate-limiting DOTS telemetry, including those with new 'tmid'
values, from the same DOTS client defends against DoS attacks that
would result in varying the 'tmid' to exhaust DOTS server
resources. Likewise, the DOTS server can enforce a quota and
time-limit on the number of active pre-or-ongoing-mitigation
telemetry data (identified by 'tmid') from the DOTS client.
Note also that telemetry notification interval may be used to rate-
limit the pre-or-ongoing-mitigation telemetry notifications received
by a DOTS client domain.
12.2. Vendor Attack Mapping
Security considerations in Section 10 of [I-D.ietf-dots-data-channel]
need to be taken into consideration.
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
is the default) are considered sensitive. Write operations to these
data nodes without proper protection can have a negative effect on
network operations. Appropriate security measures are recommended to
prevent illegitimate users from invoking DOTS data channel primitives
as discussed in [I-D.ietf-dots-data-channel]. Nevertheless, an
attacker who can access a DOTS client is technically capable of
undertaking various attacks, such as:
o Communicating invalid attack mapping details to the server
('/ietf-data:dots-data/ietf-data:dots-client/dots-
telemetry:vendor-mapping'), which will mislead the server when
correlating attack details.
Some of the readable data nodes in the YANG module specified in
Section 9.2 may be considered sensitive. It is thus important to
control read access to these data nodes. These are the data nodes
and their sensitivity:
o '/ietf-data:dots-data/ietf-data:dots-client/dots-telemetry:vendor-
mapping' can be misused to infer the DDoS protection technology
deployed in a DOTS client domain.
o '/ietf-data:dots-data/dots-telemetry:vendor-mapping' can be used
by a compromised DOTS client to leak the attack detection
capabilities of the DOTS server. This is a variation of the
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 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 https://tools.ietf.org/html/draft- Kaname Nishizuka co-authors of [I-D.doron-dots-telemetry] and
doron-dots-telemetry-00 draft and everyone who had contributed to everyone who had contributed to that document.
that document.
The authors would like to thank Kaname Nishizuka, Jon Shallow, Wei The authors would like to thank Kaname Nishizuka, Wei Pan, and Yuuhei
Pan and Yuuhei Hayashi for comments and review. Hayashi for comments and review.
Special thanks to Jon Shallow and Kaname Nishizuka for their
implementation and interoperability work.
15. References 15. References
15.1. Normative References 15.1. Normative References
[Enterprise-Numbers] [Enterprise-Numbers]
"Private Enterprise Numbers", 2005, <http://www.iana.org/ "Private Enterprise Numbers", May 2020,
assignments/enterprise-numbers.html>. <http://www.iana.org/assignments/enterprise-numbers.html>.
[I-D.ietf-dots-data-channel] [I-D.ietf-dots-data-channel]
Boucadair, M. and T. Reddy.K, "Distributed Denial-of- Boucadair, M. and T. Reddy.K, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Data Channel Service Open Threat Signaling (DOTS) Data Channel
Specification", draft-ietf-dots-data-channel-31 (work in Specification", draft-ietf-dots-data-channel-31 (work in
progress), July 2019. 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
skipping to change at page 93, line 31 skipping to change at page 105, line 10
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959, the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016, DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/info/rfc7959>. <https://www.rfc-editor.org/info/rfc7959>.
[RFC7970] Danyliw, R., "The Incident Object Description Exchange
Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
November 2016, <https://www.rfc-editor.org/info/rfc7970>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[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>.
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, "New Constrained Application
Protocol (CoAP) Block-Wise Transfer Options", draft-bosh- Protocol (CoAP) Block-Wise Transfer Options", draft-bosh-
core-new-block-00 (work in progress), April 2020. core-new-block-00 (work in progress), April 2020.
[I-D.doron-dots-telemetry]
Doron, E., Reddy, T., Andreasen, F., Xia, L., and K.
Nishizuka, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry Specifications", draft-doron-
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-03 (work in progress), January 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-20 (work in
skipping to change at line 4230 skipping to change at page 107, line 11
Israel Israel
Email: ehudd@radware.com Email: ehudd@radware.com
Meiling Chen Meiling Chen
CMCC CMCC
32, Xuanwumen West 32, Xuanwumen West
BeiJing, BeiJing 100053 BeiJing, BeiJing 100053
China China
Email: chenmeiling@chinamobile.com Email: chenmeiling@chinamobile.com
Jon Shallow
United Kingdom
Email: supjps-ietf@jpshallow.com
 End of changes. 148 change blocks. 
210 lines changed or deleted 743 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/