idnits 2.17.1 draft-ietf-dots-telemetry-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 85 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 852 has weird spacing: '...apacity uin...' == Line 1173 has weird spacing: '...er-port ine...' == Line 1385 has weird spacing: '...er-port ine...' -- The document date (February 7, 2020) is 1530 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 3198, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'Enterprise-Numbers' == Outdated reference: A later version (-14) exists of draft-ietf-dots-signal-call-home-07 == Outdated reference: A later version (-07) exists of draft-ietf-dots-signal-filter-control-02 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-13) exists of draft-ietf-dots-multihoming-03 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-20 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS M. Boucadair, Ed. 3 Internet-Draft Orange 4 Intended status: Standards Track T. Reddy, Ed. 5 Expires: August 10, 2020 McAfee 6 E. Doron 7 Radware Ltd. 8 M. Chen 9 CMCC 10 February 7, 2020 12 Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry 13 draft-ietf-dots-telemetry-02 15 Abstract 17 This document aims to enrich DOTS signal channel protocol with 18 various telemetry attributes allowing optimal DDoS attack mitigation. 19 This document specifies the normal traffic baseline and attack 20 traffic telemetry attributes a DOTS client can convey to its DOTS 21 server in the mitigation request, the mitigation status telemetry 22 attributes a DOTS server can communicate to a DOTS client, and the 23 mitigation efficacy telemetry attributes a DOTS client can 24 communicate to a DOTS server. The telemetry attributes can assist 25 the mitigator to choose the DDoS mitigation techniques and perform 26 optimal DDoS attack mitigation. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 10, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. DOTS Telemetry: Overview and Purpose . . . . . . . . . . . . 6 65 4. Generic Considerations . . . . . . . . . . . . . . . . . . . 9 66 4.1. DOTS Client Identification . . . . . . . . . . . . . . . 9 67 4.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . . . 9 68 4.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . . . 9 69 4.4. Controlling Configuration Data . . . . . . . . . . . . . 9 70 4.5. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 10 71 4.6. DOTS Multi-homing Considerations . . . . . . . . . . . . 10 72 4.7. YANG Considerations . . . . . . . . . . . . . . . . . . . 10 73 4.8. A Note About Examples . . . . . . . . . . . . . . . . . . 10 74 5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 11 75 6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 12 76 6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 12 77 6.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 12 78 6.1.2. Convey DOTS Telemetry Configuration . . . . . . . . . 15 79 6.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 18 80 6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 18 81 6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 19 82 6.2.1. Convey DOTS Client Domain Pipe Capacity . . . . . . . 20 83 6.2.2. Retrieve DOTS Client Domain Pipe Capacity . . . . . . 25 84 6.2.3. Delete DOTS Client Domain Pipe Capacity . . . . . . . 25 85 6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 26 86 6.3.1. Convey DOTS Client Domain Baseline Information . . . 28 87 6.3.2. Retrieve Normal Traffic Baseline . . . . . . . . . . 29 88 6.3.3. Delete Normal Traffic Baseline . . . . . . . . . . . 29 89 6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 29 90 6.5. Conflict with Other DOTS Clients of the Same Domain . . . 30 91 7. DOTS Pre-mitigation Telemetry . . . . . . . . . . . . . . . . 30 92 7.1. Pre-mitigation DOTS Telemetry Attributes . . . . . . . . 31 93 7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 31 94 7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 32 95 7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 33 96 7.1.4. Total Attack Connections . . . . . . . . . . . . . . 34 97 7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 36 98 7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 38 99 7.3. From DOTS Servers to DOTS Client . . . . . . . . . . . . 39 100 8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 42 101 8.1. DOTS Client to Server Mitigation Efficacy DOTS Telemetry 102 Attributes . . . . . . . . . . . . . . . . . . . . . . . 42 103 8.2. DOTS Server to Client Mitigation Status DOTS Telemetry 104 Attributes . . . . . . . . . . . . . . . . . . . . . . . 43 105 9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 46 106 10. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 67 107 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 108 11.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 69 109 11.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 70 110 11.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 71 111 12. Security Considerations . . . . . . . . . . . . . . . . . . . 71 112 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 71 113 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 71 114 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 115 15.1. Normative References . . . . . . . . . . . . . . . . . . 72 116 15.2. Informative References . . . . . . . . . . . . . . . . . 73 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74 119 1. Introduction 121 Distributed Denial of Service (DDoS) attacks have become more vicious 122 and sophisticated in almost all aspects of their maneuvers and 123 malevolent intentions. IT organizations and service providers are 124 facing DDoS attacks that fall into two broad categories: Network/ 125 Transport layer attacks and Application layer attacks: 127 o Network/Transport layer attacks target the victim's 128 infrastructure. These attacks are not necessarily aimed at taking 129 down the actual delivered services, but rather to eliminate 130 various network elements (routers, switches, firewalls, transit 131 links, and so on) from serving legitimate user traffic. 133 The main method of such attacks is to send a large volume or high 134 PPS of traffic toward the victim's infrastructure. Typically, 135 attack volumes may vary from a few 100 Mbps/PPS to 100s of Gbps or 136 even Tbps. Attacks are commonly carried out leveraging botnets 137 and attack reflectors for amplification attacks such as NTP 138 (Network Time Protocol), DNS (Domain Name System), SNMP (Simple 139 Network Management Protocol), or SSDP (Simple Service Discovery 140 Protoco). 142 o Application layer attacks target various applications. Typical 143 examples include attacks against HTTP/HTTPS, DNS, SIP (Session 144 Initiation Protocol), or SMTP (Simple Mail Transfer Protocol). 145 However, all valid applications with their port numbers open at 146 network edges can be attractive attack targets. 148 Application layer attacks are considered more complex and hard to 149 categorize, therefore harder to detect and mitigate efficiently. 151 To compound the problem, attackers also leverage multi-vectored 152 attacks. These attacks are assembled from dynamic attack vectors 153 (Network/Application) and tactics. As such, multiple attack vectors 154 formed by multiple attack types and volumes are launched 155 simultaneously towards a victim. Multi-vector attacks are harder to 156 detect and defend. Multiple and simultaneous mitigation techniques 157 are needed to defeat such attack campaigns. It is also common for 158 attackers to change attack vectors right after a successful 159 mitigation, burdening their opponents with changing their defense 160 methods. 162 The ultimate conclusion derived from these real scenarios is that 163 modern attacks detection and mitigation are most certainly 164 complicated and highly convoluted tasks. They demand a comprehensive 165 knowledge of the attack attributes, the targeted normal behavior/ 166 traffic patterns, as well as the attacker's on-going and past 167 actions. Even more challenging, retrieving all the analytics needed 168 for detecting these attacks is not simple to obtain with the 169 industry's current capabilities. 171 The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is 172 used to carry information about a network resource or a network (or a 173 part thereof) that is under a DDoS attack. Such information is sent 174 by a DOTS client to one or multiple DOTS servers so that appropriate 175 mitigation actions are undertaken on traffic deemed suspicious. 176 Various use cases are discussed in [I-D.ietf-dots-use-cases]. 178 Typically, DOTS clients can be integrated within a DDoS attack 179 detector, or network and security elements that have been actively 180 engaged with ongoing attacks. The DOTS client mitigation environment 181 determines that it is no longer possible or practical for it to 182 handle these attacks. This can be due to lack of resources or 183 security capabilities, as derived from the complexities and the 184 intensity of these attacks. In this circumstance, the DOTS client 185 has invaluable knowledge about the actual attacks that need to be 186 handled by its DOTS server(s). By enabling the DOTS client to share 187 this comprehensive knowledge of an ongoing attack under specific 188 circumstances, the DOTS server can drastically increase its ability 189 to accomplish successful mitigation. While the attack is being 190 handled by the DOTS server associated mitigation resources, the DOTS 191 server has the knowledge about the ongoing attack mitigation. The 192 DOTS server can share this information with the DOTS client so that 193 the client can better assess and evaluate the actual mitigation 194 realized. 196 In some deployments, DOTS clients can send mitigation hints derived 197 from attack details to DOTS servers, with the full understanding that 198 the DOTS server may ignore mitigation hints, as described in 199 [RFC8612] (Gen-004). Mitigation hints will be transmitted across the 200 DOTS signal channel, as the data channel may not be functional during 201 an attack. How a DOTS server is handling normal and attack traffic 202 attributes, and mitigation hints is implementation-specific. 204 Both DOTS client and server can benefit this information by 205 presenting various information in relevant management, reporting, and 206 portal systems. 208 This document defines DOTS telemetry attributes the DOTS client can 209 convey to the DOTS server, and vice versa. The DOTS telemetry 210 attributes are not mandatory fields. Nevertheless, when DOTS 211 telemetry attributes are available to a DOTS agent, and absent any 212 policy, it can signal the attributes in order to optimize the overall 213 mitigation service provisioned using DOTS. Some of the DOTS 214 telemetry data is not shared during an attack time. 216 2. Terminology 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 220 "OPTIONAL" in this document are to be interpreted as described in BCP 221 14 [RFC2119][RFC8174] when, and only when, they appear in all 222 capitals, as shown here. 224 The reader should be familiar with the terms defined in [RFC8612]. 226 "DOTS Telemetry" is defined as the collection of attributes that are 227 used to characterize normal traffic baseline, attacks and their 228 mitigation measures, and any related information that may help in 229 enforcing countermeasures. The DOTS Telemetry is an optional set of 230 attributes that can be signaled in the DOTS signal channel protocol. 232 The meaning of the symbols in YANG tree diagrams is defined in 233 [RFC8340]. 235 3. DOTS Telemetry: Overview and Purpose 237 When signaling a mitigation request, it is most certainly beneficial 238 for the DOTS client to signal to the DOTS server any knowledge 239 regarding ongoing attacks. This can happen in cases where DOTS 240 clients are asking the DOTS server for support in defending against 241 attacks that they have already detected and/or mitigated. These 242 actions taken by DOTS clients are referred to as "signaling the DOTS 243 Telemetry". 245 If attacks are already detected and categorized by the DOTS client 246 domain, the DOTS server, and its associated mitigation services, can 247 proactively benefit this information and optimize the overall service 248 delivered. It is important to note that DOTS client and server 249 detection and mitigation approaches can be different, and can 250 potentially outcome different results and attack classifications. 251 The DDoS mitigation service treats the ongoing attack details from 252 the client as hints and cannot completely rely or trust the attack 253 details conveyed by the DOTS client. 255 A basic requirement of security operation teams is to be aware and 256 get visibility into the attacks they need to handle. The DOTS server 257 security operation teams benefit from the DOTS telemetry, especially 258 from the reports of ongoing attacks. Even if some mitigation can be 259 automated, operational teams can use the DOTS telemetry to be 260 prepared for attack mitigation and to assign the correct resources 261 (operation staff, networking and mitigation) for the specific 262 service. Similarly, security operation personnel at the DOTS client 263 side ask for feedback about their requests for protection. 264 Therefore, it is valuable for the DOTS server to share DOTS telemetry 265 with the DOTS client. 267 Thus mutual sharing of information is crucial for "closing the 268 mitigation loop" between the DOTS client and server. For the server 269 side team, it is important to realize that the same attacks that the 270 DOTS server's mitigation resources are seeing are those that the DOTS 271 client is asking to mitigate. For the DOTS client side team, it is 272 important to realize that the DOTS clients receive the required 273 service. For example, understanding that "I asked for mitigation of 274 two attacks and my DOTS server detects and mitigates only one...". 275 Cases of inconsistency in attack classification between DOTS client 276 and server can be high-lighted, and maybe handled, using the DOTS 277 telemetry attributes. 279 In addition, management and orchestration systems, at both DOTS 280 client and server sides, can potentially use DOTS telemetry as a 281 feedback to automate various control and management activities 282 derived from ongoing information signaled. 284 If the DOTS server's mitigation resources have the capabilities to 285 facilitate the DOTS telemetry, the DOTS server adopts its protection 286 strategy and activates the required countermeasures immediately 287 (automation enabled). The overall results of this adoption are 288 optimized attack mitigation decisions and actions. 290 The DOTS telemetry can also be used to tune the DDoS mitigators with 291 the correct state of the attack. During the last few years, DDoS 292 attack detection technologies have evolved from threshold-based 293 detection (that is, cases when all or specific parts of traffic cross 294 a pre-defined threshold for a certain period of time is considered as 295 an attack) to an "anomaly detection" approach. In anomaly detection, 296 the main idea is to maintain rigorous learning of "normal" behavior 297 and where an "anomaly" (or an attack) is identified and categorized 298 based on the knowledge about the normal behavior and a deviation from 299 this normal behavior. Machine learning approaches are used such that 300 the actual "traffic thresholds" are "automatically calculated" by 301 learning the protected entity normal traffic behavior during peace 302 time. The normal traffic characterization learned is referred to as 303 the "normal traffic baseline". An attack is detected when the 304 victim's actual traffic is deviating from this normal baseline. 306 In addition, subsequent activities toward mitigating an attack are 307 much more challenging. The ability to distinguish legitimate traffic 308 from attacker traffic on a per packet basis is complex. This 309 complexity originates from the fact that the packet itself may look 310 "legitimate" and no attack signature can be identified. The anomaly 311 can be identified only after detailed statistical analysis. DDoS 312 attack mitigators use the normal baseline during the mitigation of an 313 attack to identify and categorize the expected appearance of a 314 specific traffic pattern. Particularly the mitigators use the normal 315 baseline to recognize the "level of normality" needs to be achieved 316 during the various mitigation process. 318 Normal baseline calculation is performed based on continuous learning 319 of the normal behavior of the protected entities. The minimum 320 learning period varies from hours to days and even weeks, depending 321 on the protected application behavior. The baseline cannot be 322 learned during active attacks because attack conditions do not 323 characterize the protected entities' normal behavior. 325 If the DOTS client has calculated the normal baseline of its 326 protected entities, signaling this attribute to the DOTS server along 327 with the attack traffic levels is significantly valuable. The DOTS 328 server benefits from this telemetry by tuning its mitigation 329 resources with the DOTS client's normal baseline. The DOTS server 330 mitigators use the baseline to familiarize themselves with the attack 331 victim's normal behavior and target the baseline as the level of 332 normality they need to achieve. Consequently, the overall mitigation 333 performances obtained are dramatically improved in terms of time to 334 mitigate, accuracy, false-negative, false-positive, and other 335 measures. 337 Mitigation of attacks without having certain knowledge of normal 338 traffic can be inaccurate at best. This is especially true for 339 recursive signaling (see Section 3.2.3 in [I-D.ietf-dots-use-cases]). 340 In addition, the highly diverse types of use-cases where DOTS clients 341 are integrated also emphasize the need for knowledge of client 342 behavior. Consequently, common global thresholds for attack 343 detection practically cannot be realized. Each DOTS client can have 344 its own levels of traffic and normal behavior. Without facilitating 345 normal baseline signaling, it may be very difficult for DOTS servers 346 in some cases to detect and mitigate the attacks accurately: 348 It is important to emphasize that it is practically impossible for 349 the server's mitigators to calculate the normal baseline in cases 350 where they do not have any knowledge of the traffic beforehand. 352 In addition, baseline learning requires a period of time that 353 cannot be afforded during active attack. 355 Of course, this information can provided using out-of-band 356 mechanisms or manual configuration at the risk to maintain 357 inaccurate information as the network evolves and "normal" 358 patterns change. The use of a dynamic and collaborative means 359 between the DOTS client and server to identify and share key 360 parameters for the sake of efficient DDoS protection is valuable. 362 During a high volume attack, DOTS client pipes can be totally 363 saturated. The DOTS client asks the DOTS server to handle the attack 364 upstream so that DOTS client pipes return to a reasonable load level 365 (normal pattern, ideally). At this point, it is essential to ensure 366 that the mitigator does not overwhelm the DOTS client pipes by 367 sending back "clean traffic", or what it believes is "clean". This 368 can happen when the mitigator has not managed to detect and mitigate 369 all the attacks launched towards the client. In this case, it can be 370 valuable to clients to signal to server the "Total pipe capacity", 371 which is the level of traffic the DOTS client domain can absorb from 372 the upstream network. Dynamic updates of the condition of pipes 373 between DOTS agents while they are under a DDoS attack is essential. 374 For example, where multiple DOTS clients share the same physical 375 connectivity pipes. It is important to note, that the term "pipe" 376 noted here does not necessary represent physical pipe, but rather 377 represents the maximum level of traffic that the DOTS client domain 378 can receive. The DOTS server should activate other mechanisms to 379 ensure it does not allow the client's pipes to be saturated 380 unintentionally. The rate-limit action defined in 381 [I-D.ietf-dots-data-channel] is a reasonable candidate to achieve 382 this objective; the client can ask for the type of traffic (such as 383 ICMP, UDP, TCP port number 80) it prefers to limit. The rate-limit 384 action can be controlled via the signal-channel 385 [I-D.ietf-dots-signal-filter-control] even when the pipe is 386 overwhelmed. 388 To summarize: 390 Timely and effective signaling of up-to-date DOTS telemetry to all 391 elements involved in the mitigation process is essential and 392 absolutely improves the overall service effectiveness. Bi- 393 directional feedback between DOTS agents is required for the 394 increased awareness of each party, supporting superior and highly 395 efficient attack mitigation service. 397 4. Generic Considerations 399 4.1. DOTS Client Identification 401 Following the rules in [I-D.ietf-dots-signal-channel], a unique 402 identifier is generated by a DOTS client to prevent request 403 collisions ('cuid'). 405 4.2. DOTS Gateways 407 DOTS gateways may be located between DOTS clients and servers. The 408 considerations elaborated in [I-D.ietf-dots-signal-channel] must be 409 followed. In particular, 'cdid' attribute is used to unambiguously 410 identify a DOTS client domain. 412 4.3. Empty URI Paths 414 Uri-Path parameters and attributes with empty values MUST NOT be 415 present in a request and render an entire message invalid. 417 4.4. Controlling Configuration Data 419 The DOTS server follows the same considerations discussed in 420 Section of 4.5.3 of [I-D.ietf-dots-signal-channel] for managing DOTS 421 telemetry configuration freshness and notification. Likewise, a DOTS 422 client may control the selection of configuration and non- 423 configuration data nodes when sending a GET request by means of the 424 'c' Uri-Query option and following the procedure specified in 425 Section of 4.4.2 of [I-D.ietf-dots-signal-channel]. These 426 considerations are not re-iterated in the following sections. 428 4.5. Block-wise Transfer 430 DOTS clients can use Block-wise transfer [RFC7959] with the 431 recommendation detailed in Section 4.4.2 of 432 [I-D.ietf-dots-signal-channel] to control the size of a response when 433 the data to be returned does not fit within a single datagram. 435 DOTS clients can also use Block1 Option in a PUT request (see 436 Section 2.5 of [RFC7959]) to initiate large transfers, but these 437 Block1 transfers will fail if the inbound "pipe" is running full, so 438 consideration needs to be made to try to fit this PUT into a single 439 transfer, or to separate out the PUT into several discrete PUTs where 440 each of them fits into a single packet. 442 4.6. DOTS Multi-homing Considerations 444 Multi-homed DOTS clients are assumed to follow the recommendations in 445 [I-D.ietf-dots-multihoming] to select which DOTS server to contact 446 and which IP prefixes to include in a telemetry message to a given 447 peer DOTS server. For example, if each upstream network exposes a 448 DOTS server and the DOTS client maintains DOTS channels with all of 449 them, only the information related to prefixes assigned by an 450 upstream network to the DOTS client domain will be signaled via the 451 DOTS channel established with the DOTS server of that upstream 452 network. Considerations related to whether (and how) a DOTS client 453 gleans some telemetry information (e.g., attack details) it receives 454 from a first DOTS server and share it with a second DOTS server are 455 implementation- and deployment-specific. 457 4.7. YANG Considerations 459 Messages exchanged between DOTS agents are serialized using Concise 460 Binary Object Representation (CBOR). CBOR-encoded payloads are used 461 to carry signal channel-specific payload messages which convey 462 request parameters and response information such as errors 463 [I-D.ietf-dots-signal-channel]. 465 This document specifies a YANG module for representing DOTS telemetry 466 message types (Section 9). All parameters in the payload of the DOTS 467 signal channel are mapped to CBOR types as specified in Section 10. 469 4.8. A Note About Examples 471 Examples are provided for illustration purposes. The document does 472 not aim to provide a comprehensive list of message examples. 474 The authoritative reference for validating telemetry messages is the 475 YANG module (Section 9) and the mapping table established in 476 Section 10. 478 5. Telemetry Operation Paths 480 As discussed in [I-D.ietf-dots-signal-channel], each DOTS operation 481 is indicated by a path-suffix that indicates the intended operation. 482 The operation path is appended to the path-prefix to form the URI 483 used with a CoAP request to perform the desired DOTS operation. The 484 following telemetry path-suffixes are defined (Table 1): 486 +-----------------+----------------+-----------+ 487 | Operation | Operation Path | Details | 488 +-----------------+----------------+-----------+ 489 | Telemetry Setup | /tm-setup | Section 6 | 490 | Telemetry | /tm | Section 7 | 491 +-----------------+----------------+-----------+ 493 Table 1: DOTS Telemetry Operations 495 Consequently, the "ietf-dots-telemetry" YANG module defined in this 496 document (Section 9) augments the "ietf-dots-signal" with two new 497 message types called "telemetry-setup" and "telemetry". The tree 498 structure is shown in Figure 1 (more details are provided in the 499 following sections about the exact structure of "telemetry-setup" and 500 "telemetry" message types). 502 augment /ietf-signal:dots-signal/ietf-signal:message-type: 503 +--:(telemetry-setup) {dots-telemetry}? 504 | ... 505 | +--rw (setup-type)? 506 | +--:(telemetry-config) 507 | | ... 508 | +--:(pipe) 509 | | ... 510 | +--:(baseline) 511 | ... 512 +--:(telemetry) {dots-telemetry}? 513 ... 515 Figure 1: New DOTS Message Types (YANG Tree Structure) 517 6. DOTS Telemetry Setup Configuration 519 In reference to Figure 1, a DOTS telemetry setup message MUST include 520 only telemetry-related configuration parameters (Section 6.1) or 521 information about DOTS client domain pipe capacity (Section 6.2) or 522 telemetry traffic baseline (Section 6.3). As such, requests that 523 include a mix of telemetry configuration, pipe capacity, or traffic 524 baseline MUST be rejected by DOTS servers with a 4.00 (Bad Request). 526 A DOTS client can reset all installed DOTS telemetry setup 527 configuration data following the considerations detailed in 528 Section 6.4. 530 A DOTS server may detect conflicts when processing requests related 531 to DOTS client domain pipe capacity or telemetry traffic baseline 532 with requests from other DOTS clients of the same DOTS client domain. 533 More details are included in Section 6.5. 535 DOTS telemetry setup configuration request and response messages are 536 marked as Confirmable messages. 538 6.1. Telemetry Configuration 540 A DOTS client can negotiate with its server(s) a set of telemetry 541 configuration parameters to be used for telemetry. Such parameters 542 include: 544 o Percentile-related measurement parameters 546 o Measurement units 548 o Acceptable percentile values 550 o Telemetry notification interval 552 o Acceptable Server-originated telemetry 554 Section 11.3 of [RFC2330] includes more details about computing 555 percentiles. 557 6.1.1. Retrieve Current DOTS Telemetry Configuration 559 A GET request is used to obtain acceptable and current telemetry 560 configuration parameters on the DOTS server. This request may 561 include a 'cdid' Path-URI when the request is relayed by a DOTS 562 gateway. An example of such request is depicted in Figure 2. 564 Header: GET (Code=0.01) 565 Uri-Path: ".well-known" 566 Uri-Path: "dots" 567 Uri-Path: "tm-setup" 568 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 570 Figure 2: GET to Retrieve Current and Acceptable DOTS Telemetry 571 Configuration 573 Upon receipt of such request, the DOTS server replies with a 2.05 574 (Content) response that conveys the current and telemetry parameters 575 acceptable by the DOTS server. The tree structure of the response 576 message body is provided in Figure 3. Note that the response also 577 includes any pipe (Section 6.2) and baseline information 578 (Section 6.3) maintained by the DOTS server for this DOTS client. 580 DOTS servers that support the capability of sending pre-mitigation 581 telemetry information to DOTS clients (Section 8.2) sets 'server- 582 originated-telemetry' under 'max-config-values' to 'true' ('false' is 583 used otherwise). If 'server-originated-telemetry' is not present in 584 a response, this is equivalent to receiving a request with 'server- 585 originated-telemetry'' set to 'false'. 587 augment /ietf-signal:dots-signal/ietf-signal:message-type: 588 +--:(telemetry-setup) {dots-telemetry}? 589 | +--rw telemetry* [cuid tsid] 590 | ... 591 | +--rw (setup-type)? 592 | +--:(telemetry-config) 593 | | +--rw current-config 594 | | | +--rw measurement-interval? interval 595 | | | +--rw measurement-sample? sample 596 | | | +--rw low-percentile? percentile 597 | | | +--rw mid-percentile? percentile 598 | | | +--rw high-percentile? percentile 599 | | | +--rw unit-config* [unit] 600 | | | | +--rw unit unit 601 | | | | +--rw unit-status? boolean 602 | | | +--rw server-originated-telemetry? boolean 603 | | | +--rw telemetry-notify-interval? uint32 604 | | +--ro max-config-values 605 | | | +--ro measurement-interval? interval 606 | | | +--ro measurement-sample? sample 607 | | | +--ro low-percentile? percentile 608 | | | +--ro mid-percentile? percentile 609 | | | +--ro high-percentile? percentile 610 | | | +--ro server-originated-telemetry? boolean 611 | | | +--ro telemetry-notify-interval? uint32 612 | | +--ro min-config-values 613 | | | +--ro measurement-interval? interval 614 | | | +--ro measurement-sample? sample 615 | | | +--ro low-percentile? percentile 616 | | | +--ro mid-percentile? percentile 617 | | | +--ro high-percentile? percentile 618 | | | +--ro telemetry-notify-interval? uint32 619 | | +--ro supported-units 620 | | +--ro unit-config* [unit] 621 | | +--ro unit unit 622 | | +--ro unit-status? boolean 623 | +--:(pipe) 624 | ... 625 | +--:(baseline) 626 | ... 627 +--:(telemetry) {dots-telemetry}? 628 +--rw pre-mitigation* [cuid tmid] 629 ... 631 Figure 3: Telemetry Configuration Tree Structure 633 6.1.2. Convey DOTS Telemetry Configuration 635 PUT request is used to convey the configuration parameters for the 636 telemetry data (e.g., low, mid, or high percentile values). For 637 example, a DOTS client may contact its DOTS server to change the 638 default percentile values used as baseline for telemetry data. 639 Figure 3 lists the attributes that can be set by a DOTS client in 640 such PUT request. An example of a DOTS client that modifies all 641 percentile reference values is shown in Figure 4. 643 Header: PUT (Code=0.03) 644 Uri-Path: ".well-known" 645 Uri-Path: "dots" 646 Uri-Path: "tm-setup" 647 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 648 Uri-Path: "tsid=123" 649 Content-Format: "application/dots+cbor" 651 { 652 "ietf-dots-telemetry:telemetry-setup": { 653 "telemetry": [ 654 { 655 "current-config": { 656 "low-percentile": 5.00, 657 "mid-percentile": 65.00, 658 "high-percentile": 95.00 659 } 660 } 661 ] 662 } 663 } 665 Figure 4: PUT to Convey the DOTS Telemetry Configuration 667 'cuid' is a mandatory Uri-Path parameter for PUT requests. 669 The following additional Uri-Path parameter is defined: 671 tsid: Telemetry Setup Identifier is an identifier for the DOTS 672 telemetry setup configuration data represented as an integer. 673 This identifier MUST be generated by DOTS clients. 'tsid' 674 values MUST increase monotonically (when a new PUT is generated 675 by a DOTS client to convey new configuration parameters for the 676 telemetry). 678 This is a mandatory attribute. 680 At least one configurable attribute MUST be present in the PUT 681 request. 683 The PUT request with a higher numeric 'tsid' value overrides the DOTS 684 telemetry configuration data installed by a PUT request with a lower 685 numeric 'tsid' value. To avoid maintaining a long list of 'tsid' 686 requests for requests carrying telemetry configuration data from a 687 DOTS client, the lower numeric 'tsid' MUST be automatically deleted 688 and no longer be available at the DOTS server. 690 The DOTS server indicates the result of processing the PUT request 691 using the following response codes: 693 o If the request is missing a mandatory attribute, does not include 694 'cuid' or 'tsid' Uri-Path parameters, or contains one or more 695 invalid or unknown parameters, 4.00 (Bad Request) MUST be returned 696 in the response. 698 o If the DOTS server does not find the 'tsid' parameter value 699 conveyed in the PUT request in its configuration data and if the 700 DOTS server has accepted the configuration parameters, then a 701 response code 2.01 (Created) MUST be returned in the response. 703 o If the DOTS server finds the 'tsid' parameter value conveyed in 704 the PUT request in its configuration data and if the DOTS server 705 has accepted the updated configuration parameters, 2.04 (Changed) 706 MUST be returned in the response. 708 o If any of the enclosed configurable attribute values are not 709 acceptable to the DOTS server (Section 6.1.1), 4.22 (Unprocessable 710 Entity) MUST be returned in the response. 712 The DOTS client may re-try and send the PUT request with updated 713 attribute values acceptable to the DOTS server. 715 By default, low percentile (10th percentile), mid percentile (50th 716 percentile), high percentile (90th percentile), and peak (100th 717 percentile) values are used to represent telemetry data. 718 Nevertheless, a DOTS client can disable some percentile types (low, 719 mid, high). In particular, setting 'low-percentile' to '0.00' 720 indicates that the DOTS client is not interested in receiving low- 721 percentiles. Likewise, setting 'mid-percentile' (or 'high- 722 percentile') to the same value as 'low-percentile' (or 'mid- 723 percentile') indicates that the DOTS client is not interested in 724 receiving mid-percentiles (or high-percentiles). For example, a DOTS 725 client can send the request depicted in Figure 5 to inform the server 726 that it is interested in receiving only high-percentiles. This 727 assumes that the client will only use that percentile type when 728 sharing telemetry data with the server. 730 Header: PUT (Code=0.03) 731 Uri-Path: ".well-known" 732 Uri-Path: "dots" 733 Uri-Path: "tm-setup" 734 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 735 Uri-Path: "tsid=569" 736 Content-Format: "application/dots+cbor" 738 { 739 "ietf-dots-telemetry:telemetry-setup": { 740 "telemetry": [ 741 { 742 "current-config": { 743 "low-percentile": 0.00, 744 "mid-percentile": 0.00, 745 "high-percentile": 95.00 746 } 747 } 748 ] 749 } 750 } 752 Figure 5: PUT to Disable Low- and Mid-Percentiles 754 DOTS clients can also configure the unit(s) to be used for traffic- 755 related telemetry data. Typically, the supported units are: packets 756 per second (PPS) or kilo packets per second (Kpps) and Bits per 757 Second (BPS), and kilobytes per second or megabytes per second or 758 gigabytes per second. 760 DOTS clients that are interested to receive pre-mitigation telemetry 761 information from a DOTS server (Section 8.2) MUST set 'server- 762 originated-telemetry' to 'true'. If 'server-originated-telemetry' is 763 not present in a PUT request, this is equivalent to receiving a 764 request with 'server-originated-telemetry'' set to 'false'. An 765 example of a reques to enable pre-mitigation telemetry from DOTS 766 servers is shown in Figure 6. 768 Header: PUT (Code=0.03) 769 Uri-Path: ".well-known" 770 Uri-Path: "dots" 771 Uri-Path: "tm-setup" 772 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 773 Uri-Path: "tsid=569" 774 Content-Format: "application/dots+cbor" 776 { 777 "ietf-dots-telemetry:telemetry-setup": { 778 "telemetry": [ 779 { 780 "current-config": { 781 "server-originated-telemetry": true 782 } 783 } 784 ] 785 } 786 } 788 Figure 6: PUT to Enable Pre-mitigation Telemetry from the DOTS server 790 6.1.3. Retrieve Installed DOTS Telemetry Configuration 792 A DOTS client may issue a GET message with 'tsid' Uri-Path parameter 793 to retrieve the current DOTS telemetry configuration. An example of 794 such request is depicted in Figure 7. 796 Header: GET (Code=0.01) 797 Uri-Path: ".well-known" 798 Uri-Path: "dots" 799 Uri-Path: "tm-setup" 800 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 801 Uri-Path: "tsid=123" 803 Figure 7: GET to Retrieve Current DOTS Telemetry Configuration 805 If the DOTS server does not find the 'tsid' Uri-Path value conveyed 806 in the GET request in its configuration data for the requesting DOTS 807 client, it MUST respond with a 4.04 (Not Found) error response code. 809 6.1.4. Delete DOTS Telemetry Configuration 811 A DELETE request is used to delete the installed DOTS telemetry 812 configuration data (Figure 8). 'cuid' and 'tsid' are mandatory Uri- 813 Path parameters for such DELETE requests. 815 Header: DELETE (Code=0.04) 816 Uri-Path: ".well-known" 817 Uri-Path: "dots" 818 Uri-Path: "tm-setup" 819 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 820 Uri-Path: "tsid=123" 822 Figure 8: Delete Telemetry Configuration 824 The DOTS server resets the DOTS telemetry configuration back to the 825 default values and acknowledges a DOTS client's request to remove the 826 DOTS telemetry configuration using 2.02 (Deleted) response code. A 827 2.02 (Deleted) Response Code is returned even if the 'tsid' parameter 828 value conveyed in the DELETE request does not exist in its 829 configuration data before the request. 831 Section 6.4 discusses the procedure to reset all DOTS telemetry setup 832 configuration. 834 6.2. Total Pipe Capacity 836 A DOTS client can communicate to its server(s) its DOTS client domain 837 pipe information. The tree structure of the pipe information is 838 shown in Figure 9. 840 augment /ietf-signal:dots-signal/ietf-signal:message-type: 841 +--:(telemetry-setup) {dots-telemetry}? 842 | +--rw telemetry* [cuid tsid] 843 | +--rw cuid string 844 | +--rw cdid? string 845 | +--rw tsid uint32 846 | +--rw (setup-type)? 847 | +--:(telemetry-config) 848 | | ... 849 | +--:(pipe) 850 | | +--rw total-pipe-capacity* [link-id unit] 851 | | +--rw link-id nt:link-id 852 | | +--rw capacity uint64 853 | | +--rw unit unit 854 | +--:(baseline) 855 | ... 856 +--:(telemetry) {dots-telemetry}? 857 +--rw pre-mitigation* [cuid tmid] 858 ... 860 Figure 9: Pipe Tree Structure 862 A DOTS client domain pipe is defined as a list of limits of 863 (incoming) traffic volume (total-pipe-capacity") that can be 864 forwarded over ingress interconnection links of a DOTS client domain. 865 Each of these links is identified with a "link-id" [RFC8345]. 867 This limit can be expressed in packets per second (PPS) or kilo 868 packets per second (Kpps) and Bits per Second (BPS), and in kilobytes 869 per second or megabytes per second or gigabytes per second. The unit 870 used by a DOTS client when conveying pipe information is captured in 871 'unit' attribute. 873 6.2.1. Convey DOTS Client Domain Pipe Capacity 875 Similar considerations to those specified in Section 6.1.2 are 876 followed with one exception: 878 The relative order of two PUT requests carrying DOTS client domain 879 pipe attributes from a DOTS client is determined by comparing 880 their respective 'tsid' values. If such two requests have 881 overlapping "link-id" and "unit", the PUT request with higher 882 numeric 'tsid' value will override the request with a lower 883 numeric 'tsid' value. The overlapped lower numeric 'tsid' MUST be 884 automatically deleted and no longer be available. 886 DOTS clients SHOULD minimize the number of active 'tsids' used for 887 pipe information. Typically, in order to avoid maintaining a long 888 list of 'tsids' for pipe information, it is RECOMMENDED that DOTS 889 clients include in any request to update information related to a 890 given link the information of other links (already communicated using 891 a lower 'tsid' value). Doing so, this update request will override 892 these existing requests and hence optimize the number of 'tsid' 893 request per DOTS client. 895 o Note: This assumes that all link information can fit in one single 896 message. 898 For example, a DOTS client managing a single homed domain (Figure 10) 899 can send a PUT request (shown in Figure 11) to communicate the 900 capacity of "link1" used to connect to its ISP. 902 ,--,--,--. ,--,--,--. 903 ,-' `-. ,-' `-. 904 ( DOTS Client )=====( ISP#A ) 905 `-. Domain ,-' link1 `-. ,-' 906 `--'--'--' `--'--'--' 908 Figure 10: Single Homed DOTS Client Domain 910 Header: PUT (Code=0.03) 911 Uri-Path: ".well-known" 912 Uri-Path: "dots" 913 Uri-Path: "tm-setup" 914 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 915 Uri-Path: "tsid=457" 916 Content-Format: "application/dots+cbor" 918 { 919 "ietf-dots-telemetry:telemetry-setup": { 920 "telemetry": [ 921 { 922 "total-pipe-capacity": [ 923 { 924 "link-id": "link1", 925 "capacity": 500, 926 "unit": "megabytes-ps" 927 } 928 ] 929 } 930 ] 931 } 932 } 934 Figure 11: Example of a PUT Request to Convey Pipe Information 935 (Single Homed) 937 DOTS clients may be instructed to signal a link aggregate instead of 938 individual links. For example, a DOTS client managing a DOTS client 939 domain having two interconnection links with an upstream ISP 940 (Figure 12) can send a PUT request (shown in Figure 13) to 941 communicate the aggregate link capacity with its ISP. Signalling 942 individual or aggregate link capacity is deployment-specific. 944 ,--,--,--. ,--,--,--. 945 ,-' `-.===== ,-' `-. 946 ( DOTS Client ) ( ISP#C ) 947 `-. Domain ,-'====== `-. ,-' 948 `--'--'--' `--'--'--' 950 Figure 12: DOTS Client Domain with Two Interconnection Links 952 Header: PUT (Code=0.03) 953 Uri-Path: ".well-known" 954 Uri-Path: "dots" 955 Uri-Path: "tm-setup" 956 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 957 Uri-Path: "tsid=896" 958 Content-Format: "application/dots+cbor" 960 { 961 "ietf-dots-telemetry:telemetry-setup": { 962 "telemetry": [ 963 { 964 "total-pipe-capacity": [ 965 { 966 "link-id": "aggregate", 967 "capacity": 700, 968 "unit": "megabytes-ps" 969 } 970 ] 971 } 972 ] 973 } 974 } 976 Figure 13: Example of a PUT Request to Convey Pipe Information 977 (Aggregated Link) 979 Now consider that the DOTS client domain was upgraded to connect to 980 an additional ISP (ISP#B of Figure 14), the DOTS client can inform a 981 third-party DOTS server (that is, not hosted with ISP#A and ISP#B 982 domains) about this update by sending the PUT request depicted in 983 Figure 15. This request also includes information related to "link1" 984 even if that link is not upgraded. Upon receipt of this request, the 985 DOTS server removes the request with 'tsid=457' and updates its 986 configuration base to maintain two links (link#1 and link#2). 988 ,--,--,--. 989 ,-' `-. 990 ( ISP#B ) 991 `-. ,-' 992 `--'--'--' 993 || 994 || link2 995 ,--,--,--. ,--,--,--. 996 ,-' `-. ,-' `-. 997 ( DOTS Client )=====( ISP#A ) 998 `-. Domain ,-' link1 `-. ,-' 999 `--'--'--' `--'--'--' 1001 Figure 14: Multi-Homed DOTS Client Domain 1003 Header: PUT (Code=0.03) 1004 Uri-Path: ".well-known" 1005 Uri-Path: "dots" 1006 Uri-Path: "tm-setup" 1007 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1008 Uri-Path: "tsid=458" 1009 Content-Format: "application/dots+cbor" 1011 { 1012 "ietf-dots-telemetry:telemetry-setup": { 1013 "telemetry": [ 1014 { 1015 "total-pipe-capacity": [ 1016 { 1017 "link-id": "link1", 1018 "capacity": 500, 1019 "unit": "megabytes-ps" 1020 }, 1021 { 1022 "link-id": "link2", 1023 "capacity": 500, 1024 "unit": "megabytes-ps" 1025 } 1026 ] 1027 } 1028 ] 1029 } 1030 } 1032 Figure 15: Example of a PUT Request to Convey Pipe Information 1033 (Multi-Homed) 1035 A DOTS client can delete a link by sending a PUT request with the 1036 'capacity' attribute set to "0" if other links are still active for 1037 the same DOTS client domain (see Section 6.2.3 for other delete 1038 cases). For example, if a DOTS client domain re-homes (that is, it 1039 changes its ISP), the DOTS client can inform its DOTS server about 1040 this update (e.g., from the network configuration in Figure 10 to the 1041 one shown in Figure 16) by sending the PUT request depicted in 1042 Figure 17. Upon receipt of this request, the DOTS server removes 1043 "link1" from its configuration bases for this DOTS client domain. 1045 ,--,--,--. 1046 ,-' `-. 1047 ( ISP#B ) 1048 `-. ,-' 1049 `--'--'--' 1050 || 1051 || link2 1052 ,--,--,--. 1053 ,-' `-. 1054 ( DOTS Client ) 1055 `-. Domain ,-' 1056 `--'--'--' 1058 Figure 16: Multi-Homed DOTS Client Domain 1060 Header: PUT (Code=0.03) 1061 Uri-Path: ".well-known" 1062 Uri-Path: "dots" 1063 Uri-Path: "tm-setup" 1064 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1065 Uri-Path: "tsid=459" 1066 Content-Format: "application/dots+cbor" 1068 { 1069 "ietf-dots-telemetry:telemetry-setup": { 1070 "telemetry": [ 1071 { 1072 "total-pipe-capacity": [ 1073 { 1074 "link-id": "link1", 1075 "capacity": 0, 1076 "unit": "megabytes-ps" 1077 }, 1078 { 1079 "link-id": "link2", 1080 "capacity": 500, 1081 "unit": "megabytes-ps" 1082 } 1083 ] 1084 } 1085 ] 1086 } 1087 } 1089 Figure 17: Example of a PUT Request to Convey Pipe Information 1090 (Multi-Homed) 1092 6.2.2. Retrieve DOTS Client Domain Pipe Capacity 1094 A GET request with 'tsid' Uri-Path parameter is used to retrieve a 1095 specific installed DOTS client domain pipe related information. The 1096 same procedure as defined in (Section 6.1.3) is followed. 1098 To retrieve all pipe information bound to a DOTS client, the DOTS 1099 client proceeds as specified in Section 6.1.1. 1101 6.2.3. Delete DOTS Client Domain Pipe Capacity 1103 A DELETE request is used to delete the installed DOTS client domain 1104 pipe related information. The same procedure as defined in 1105 (Section 6.1.4) is followed. 1107 6.3. Telemetry Baseline 1109 A DOTS client can communicate to its server(s) its normal traffic 1110 baseline and total connections capacity: 1112 Total Traffic Normal Baseline: The percentile values representing 1113 the total traffic normal baseline. 1115 The traffic normal baseline is represented for a target and is 1116 transport-protocol specific. 1118 If the DOTS client negotiated percentile values and units 1119 (Section 6.1), these negotiated values will be used instead of the 1120 default ones. 1122 Total Connections Capacity: If the target is subjected to resource 1123 consuming DDoS attacks, the following optional attributes for the 1124 target per transport-protocol are useful to detect resource 1125 consuming DDoS attacks: 1127 Total Connections Capacity: 1129 * The maximum number of simultaneous connections that are allowed 1130 to the target. 1131 * The maximum number of simultaneous connections that are allowed 1132 to the target per client. 1133 * The maximum number of simultaneous embryonic connections that 1134 are allowed to the target. The term "embryonic connection" 1135 refers to a connection whose connection handshake is not 1136 finished and embryonic connection is only possible in 1137 connection-oriented transport protocols like TCP or SCTP. 1138 * The maximum number of simultaneous embryonic connections that 1139 are allowed to the target per client. 1140 * The maximum number of connections allowed per second to the 1141 target. 1142 * The maximum number of connections allowed per second to the 1143 target per client. 1144 * The maximum number of requests allowed per second to the 1145 target. 1146 * The maximum number of requests allowed per second to the target 1147 per client. 1148 * The maximum number of partial requests allowed per second to 1149 the target. 1150 * The maximum number of partial requests allowed per second to 1151 the target per client. 1153 The threshold is transport-protocol. 1155 The tree structure of the baseline is shown in Figure 18. 1157 augment /ietf-signal:dots-signal/ietf-signal:message-type: 1158 +--:(telemetry-setup) {dots-telemetry}? 1159 | +--rw telemetry* [cuid tsid] 1160 | +--rw cuid string 1161 | +--rw cdid? string 1162 | +--rw tsid uint32 1163 | +--rw (setup-type)? 1164 | +--:(telemetry-config) 1165 | | ... 1166 | +--:(pipe) 1167 | | ... 1168 | +--:(baseline) 1169 | +--rw baseline* [id] 1170 | +--rw id uint32 1171 | +--rw target-prefix* inet:ip-prefix 1172 | +--rw target-port-range* [lower-port] 1173 | | +--rw lower-port inet:port-number 1174 | | +--rw upper-port? inet:port-number 1175 | +--rw target-protocol* uint8 1176 | +--rw target-fqdn* inet:domain-name 1177 | +--rw target-uri* inet:uri 1178 | +--rw total-traffic-normal-baseline* [unit protocol] 1179 | | +--rw unit unit 1180 | | +--rw protocol uint8 1181 | | +--rw low-percentile-g? yang:gauge64 1182 | | +--rw mid-percentile-g? yang:gauge64 1183 | | +--rw high-percentile-g? yang:gauge64 1184 | | +--rw peak-g? yang:gauge64 1185 | +--rw total-connection-capacity* [protocol] 1186 | +--rw protocol uint8 1187 | +--rw connection? uint64 1188 | +--rw connection-client? uint64 1189 | +--rw embryonic? uint64 1190 | +--rw embryonic-client? uint64 1191 | +--rw connection-ps? uint64 1192 | +--rw connection-client-ps? uint64 1193 | +--rw request-ps? uint64 1194 | +--rw request-client-ps? uint64 1195 | +--rw partial-request-ps? uint64 1196 | +--rw partial-request-client-ps? uint64 1197 +--:(telemetry) {dots-telemetry}? 1198 +--rw pre-mitigation* [cuid tmid] 1199 ... 1201 Figure 18: Telemetry Baseline Tree Structure 1203 6.3.1. Convey DOTS Client Domain Baseline Information 1205 Similar considerations to those specified in Section 6.1.2 are 1206 followed with one exception: 1208 The relative order of two PUT requests carrying DOTS client domain 1209 baseline attributes from a DOTS client is determined by comparing 1210 their respective 'tsid' values. If such two requests have 1211 overlapping targets, the PUT request with higher numeric 'tsid' 1212 value will override the request with a lower numeric 'tsid' value. 1213 The overlapped lower numeric 'tsid' MUST be automatically deleted 1214 and no longer be available. 1216 Two PUT requests from a DOTS client have overlapping targets if there 1217 is a common IP address, IP prefix, FQDN, or URI. 1219 DOTS clients SHOULD minimize the number of active 'tsids' used for 1220 baseline information. Typically, in order to avoid maintaining a 1221 long list of 'tsids' for baseline information, it is RECOMMENDED that 1222 DOTS clients include in a request to update information related to a 1223 given target, the information of other targets (already communicated 1224 using a lower 'tsid' value) (assuming this fits within one single 1225 datagram). This update request will override these existing requests 1226 and hence optimize the number of 'tsid' request per DOTS client. 1228 If no target clause in included in the request, this is an indication 1229 that the baseline information applies for the DOTS client domain as a 1230 whole. 1232 An example of a PUT request to convey the baseline information is 1233 shown in Figure 19. 1235 Header: PUT (Code=0.03) 1236 Uri-Path: ".well-known" 1237 Uri-Path: "dots" 1238 Uri-Path: "tm-setup" 1239 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1240 Uri-Path: "tsid=126" 1241 Content-Format: "application/dots+cbor" 1243 { 1244 "ietf-dots-telemetry:telemetry": { 1245 "baseline": { 1246 "id": 1, 1247 "target-prefix": [ 1248 "2001:db8:6401::1/128", 1249 "2001:db8:6401::2/128" 1250 ], 1251 "total-traffic-normal-baseline": { 1252 "unit": "megabytes-ps", 1253 "protocol": 6, 1254 "peak-g": "50" 1255 } 1256 } 1257 } 1258 } 1260 Figure 19: PUT to Convey the DOTS Traffic Baseline 1262 6.3.2. Retrieve Normal Traffic Baseline 1264 A GET request with 'tsid' Uri-Path parameter is used to retrieve a 1265 specific installed DOTS client domain baseline traffic information. 1266 The same procedure as defined in (Section 6.1.3) is followed. 1268 To retrieve all baseline information bound to a DOTS client, the DOTS 1269 client proceeds as specified in Section 6.1.1. 1271 6.3.3. Delete Normal Traffic Baseline 1273 A DELETE request is used to delete the installed DOTS client domain 1274 normal traffic baseline. The same procedure as defined in 1275 (Section 6.1.4) is followed. 1277 6.4. Reset Installed Telemetry Setup 1279 Upon bootstrapping (or reboot or any other event that may alter the 1280 DOTS client setup), a DOTS client MAY send a DELETE request to set 1281 the telemetry parameters to default values. Such a request does not 1282 include any 'tsid'. An example of such request is depicted in 1283 Figure 20. 1285 Header: DELETE (Code=0.04) 1286 Uri-Path: ".well-known" 1287 Uri-Path: "dots" 1288 Uri-Path: "tm-setup" 1289 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1291 Figure 20: Delete Telemetry Configuration 1293 6.5. Conflict with Other DOTS Clients of the Same Domain 1295 A DOTS server may detect conflicts between requests to convey pipe 1296 and baseline information received from DOTS clients of the same DOTS 1297 client domain. 'conflict-information' is used to report the conflict 1298 to the DOTS client following similar conflict handling discussed in 1299 Section 4.4.1 of [I-D.ietf-dots-signal-channel]. The conflict cause 1300 can be set to one of these values: 1302 1: Overlapping targets (already defined in 1303 [I-D.ietf-dots-signal-channel]). 1305 TBA: Overlapping pipe scope (see Section 11). 1307 7. DOTS Pre-mitigation Telemetry 1309 There are two broad types of DDoS attacks, one is bandwidth consuming 1310 attack, the other is target resource consuming attack. This section 1311 outlines the set of DOTS telemetry attributes (Section 7.1) that 1312 covers both the types of attacks. The ultimate objective of these 1313 attributes is to allow for the complete knowledge of attacks and the 1314 various particulars that can best characterize attacks. 1316 The "ietf-dots-telemetry" YANG module (Section 9) augments the "ietf- 1317 dots-signal" with a new message type called "telemetry". The tree 1318 structure of the "telemetry" message type is shown Figure 21. 1320 The pre-mitigation telemetry attributes are indicated by the path- 1321 suffix '/tm'. The '/tm' is appended to the path-prefix to form the 1322 URI used with a CoAP request to signal the DOTS telemetry. Pre- 1323 mitigation telemetry attributes specified in Section 7.1 can be 1324 signaled between DOTS agents. 1326 Pre-mitigation telemetry attributes may be sent by a DOTS client or a 1327 DOTS server. 1329 DOTS agents MUST bind pre-mitigation telemetry data with mitigation 1330 requests relying upon the target clause. 1332 DOTS agents MUST NOT sent pre-mitigation telemetry messages to the 1333 same peer more frequently than once every 'telemetry-notify-interval' 1334 (Section 6.1). 1336 DOTS pre-mitigation telemetry request and response messages MUST be 1337 marked as Non-Confirmable messages. 1339 o Notes: How long a pre-mitgation id can be maintained by a peer? 1341 augment /ietf-signal:dots-signal/ietf-signal:message-type: 1342 +--:(telemetry-setup) {dots-telemetry}? 1343 | +--rw telemetry* [cuid tsid] 1344 | ... 1345 +--:(telemetry) {dots-telemetry}? 1346 +--rw pre-mitigation* [cuid tmid] 1347 +--rw cuid string 1348 +--rw cdid? string 1349 +--rw tmid uint32 1350 +--rw target 1351 | ... 1352 +--rw total-traffic* [unit protocol] 1353 | ... 1354 +--rw total-attack-traffic* [unit protocol] 1355 | ... 1356 +--rw total-attack-connection 1357 | ... 1358 +--rw attack-detail 1359 ... 1361 Figure 21: Telemetry Message Type Tree Structure 1363 7.1. Pre-mitigation DOTS Telemetry Attributes 1365 The description and motivation behind each attribute are presented in 1366 Section 3. DOTS telemetry attributes are optionally signaled and 1367 therefore MUST NOT be treated as mandatory fields in the DOTS signal 1368 channel protocol. 1370 7.1.1. Target 1372 A target resource (Figure 22) is identified using the attributes 1373 'target-prefix', 'target-port-range', 'target-protocol', 'target- 1374 fqdn', 'target-uri', or 'alias-name' defined in the base DOTS signal 1375 channel protocol. 1377 +--:(telemetry) {dots-telemetry}? 1378 +--rw pre-mitigation* [cuid tmid] 1379 +--rw cuid string 1380 +--rw cdid? string 1381 +--rw tmid uint32 1382 +--rw target 1383 | +--rw target-prefix* inet:ip-prefix 1384 | +--rw target-port-range* [lower-port] 1385 | | +--rw lower-port inet:port-number 1386 | | +--rw upper-port? inet:port-number 1387 | +--rw target-protocol* uint8 1388 | +--rw target-fqdn* inet:domain-name 1389 | +--rw target-uri* inet:uri 1390 | +--rw alias-name* string 1391 +--rw total-traffic* [unit protocol] 1392 | ... 1393 +--rw total-attack-traffic* [unit protocol] 1394 | ... 1395 +--rw total-attack-connection 1396 | ... 1397 +--rw attack-detail 1398 ... 1400 Figure 22: Target Tree Structure 1402 At least one of the attributes 'target-prefix', 'target-fqdn', 1403 'target-uri', or 'alias-name' MUST be present in the attack details. 1405 If the target is subjected to bandwidth consuming attack, the 1406 attributes representing the percentile values of the 'attack-id' 1407 attack traffic are included. 1409 If the target is subjected to resource consuming DDoS attacks, the 1410 same attributes defined for Section 7.1.4 are applicable for 1411 representing the attack. 1413 This is an optional sub-attribute. 1415 7.1.2. Total Traffic 1417 This attribute (Figure 23) conveys the percentile values of total 1418 traffic observed during a DDoS attack. 1420 The total traffic is represented for a target and is transport- 1421 protocol specific. 1423 +--:(telemetry) {dots-telemetry}? 1424 +--rw pre-mitigation* [cuid tmid] 1425 +--rw cuid string 1426 +--rw cdid? string 1427 +--rw tmid uint32 1428 +--rw target 1429 | ... 1430 +--rw total-traffic* [unit protocol] 1431 | +--rw unit unit 1432 | +--rw protocol uint8 1433 | +--rw low-percentile-g? yang:gauge64 1434 | +--rw mid-percentile-g? yang:gauge64 1435 | +--rw high-percentile-g? yang:gauge64 1436 | +--rw peak-g? yang:gauge64 1437 +--rw total-attack-traffic* [unit protocol] 1438 | ... 1439 +--rw total-attack-connection 1440 | ... 1441 +--rw attack-detail 1442 ... 1444 Figure 23: Total Traffic Tree Structure 1446 7.1.3. Total Attack Traffic 1448 This attribute (Figure 24) conveys the total attack traffic 1449 identified by the DOTS client domain's DMS (or DDoS Detector). 1451 The total attack traffic is represented for a target and is 1452 transport-protocol specific. 1454 +--:(telemetry) {dots-telemetry}? 1455 +--rw pre-mitigation* [cuid tmid] 1456 +--rw cuid string 1457 +--rw cdid? string 1458 +--rw tmid uint32 1459 +--rw target 1460 | ... 1461 +--rw total-traffic* [unit protocol] 1462 | ... 1463 +--rw total-attack-traffic* [unit protocol] 1464 | +--rw unit unit 1465 | +--rw protocol uint8 1466 | +--rw low-percentile-g? yang:gauge64 1467 | +--rw mid-percentile-g? yang:gauge64 1468 | +--rw high-percentile-g? yang:gauge64 1469 | +--rw peak-g? yang:gauge64 1470 +--rw total-attack-connection 1471 | ... 1472 +--rw attack-detail 1473 ... 1475 Figure 24: Total Attack Traffic Tree Structure 1477 7.1.4. Total Attack Connections 1479 If the target is subjected to resource consuming DDoS attack, this 1480 attribute is used to convey the percentile values of total attack 1481 connections. The following optional sub-attributes for the target 1482 per transport-protocol are included to represent the attack 1483 characteristics: 1485 o The number of simultaneous attack connections to the target. 1486 o The number of simultaneous embryonic connections to the target. 1487 o The number of attack connections per second to the target. 1488 o The number of attack requests to the target. 1490 +--:(telemetry) {dots-telemetry}? 1491 +--rw pre-mitigation* [cuid tmid] 1492 +--rw cuid string 1493 +--rw cdid? string 1494 +--rw tmid uint32 1495 +--rw target 1496 | ... 1497 +--rw total-traffic* [unit protocol] 1498 | ... 1499 +--rw total-attack-traffic* [unit protocol] 1500 | ... 1501 +--rw total-attack-connection 1502 | +--rw low-percentile-l* [protocol] 1503 | | +--rw protocol uint8 1504 | | +--rw connection? yang:gauge64 1505 | | +--rw embryonic? yang:gauge64 1506 | | +--rw connection-ps? yang:gauge64 1507 | | +--rw request-ps? yang:gauge64 1508 | | +--rw partial-request-ps? yang:gauge64 1509 | +--rw mid-percentile-l* [protocol] 1510 | | +--rw protocol uint8 1511 | | +--rw connection? yang:gauge64 1512 | | +--rw embryonic? yang:gauge64 1513 | | +--rw connection-ps? yang:gauge64 1514 | | +--rw request-ps? yang:gauge64 1515 | | +--rw partial-request-ps? yang:gauge64 1516 | +--rw high-percentile-l* [protocol] 1517 | | +--rw protocol uint8 1518 | | +--rw connection? yang:gauge64 1519 | | +--rw embryonic? yang:gauge64 1520 | | +--rw connection-ps? yang:gauge64 1521 | | +--rw request-ps? yang:gauge64 1522 | | +--rw partial-request-ps? yang:gauge64 1523 | +--rw peak-l* [protocol] 1524 | +--rw protocol uint8 1525 | +--rw connection? yang:gauge64 1526 | +--rw embryonic? yang:gauge64 1527 | +--rw connection-ps? yang:gauge64 1528 | +--rw request-ps? yang:gauge64 1529 | +--rw partial-request-ps? yang:gauge64 1530 +--rw attack-detail 1531 ... 1533 Figure 25: Total Attack Connections Tree Structure 1535 7.1.5. Attack Details 1537 This attribute (Figure 26) is used to signal a set of details 1538 characterizing an attack. The following optional sub-attributes 1539 describing the on-going attack can be signal as attack details. 1541 id: Vendor ID is a security vendor's Enterprise Number as registered 1542 with IANA [Enterprise-Numbers]. It is a four-byte integer value. 1544 attack-id: Unique identifier assigned by the vendor for the attack. 1546 attack-name: Textual representation of attack description. Natural 1547 Language Processing techniques (e.g., word embedding) can possibly 1548 be used to map the attack description to an attack type. Textual 1549 representation of attack solves two problems: (a) avoids the need 1550 to create mapping tables manually between vendors and (2) avoids 1551 the need to standardize attack types which keep evolving. 1553 attack-severity: Attack severity. These values are supported: 1554 Emergency (1), critical (2), and alert (3). 1556 start-time: The time the attack started. The attack's start time is 1557 expressed in seconds relative to 1970-01-01T00:00Z in UTC time 1558 (Section 2.4.1 of [RFC7049]). The CBOR encoding is modified so 1559 that the leading tag 1 (epoch-based date/time) MUST be omitted. 1561 end-time: The time the attack-id attack ended. The attack end time 1562 is expressed in seconds relative to 1970-01-01T00:00Z in UTC time 1563 (Section 2.4.1 of [RFC7049]). The CBOR encoding is modified so 1564 that the leading tag 1 (epoch-based date/time) MUST be omitted. 1566 Source-count: A count of sources involved in the attack targeting 1567 the victim. 1569 Top-talkers: A list of top talkers among attack sources. The top 1570 talkers are represented using the 'source-prefix' defined in 1571 [I-D.ietf-dots-signal-call-home]. 1573 'spoofed-status' is used whether a top talker is a spoofed IP 1574 address (e.g., reflection attacks) or not. 1576 If the target is subjected to bandwidth consuming attack, the 1577 attack traffic from each of the top talkers is included ('total- 1578 attack-traffic', Section 7.1.3). 1580 If the target is subjected to resource consuming DDoS attacks, the 1581 same attributes defined for Section 7.1.4 are applicable for 1582 representing the attack per talker. 1584 +--:(telemetry) {dots-telemetry}? 1585 +--rw pre-mitigation* [cuid tmid] 1586 +--rw cuid string 1587 +--rw cdid? string 1588 +--rw tmid uint32 1589 +--rw target 1590 | ... 1591 +--rw total-traffic* [unit protocol] 1592 | ... 1593 +--rw total-attack-traffic* [unit protocol] 1594 | ... 1595 +--rw total-attack-connection 1596 | ... 1597 +--rw attack-detail 1598 +--rw id? uint32 1599 +--rw attack-id? string 1600 +--rw attack-name? string 1601 +--rw attack-severity? attack-severity 1602 +--rw start-time? uint64 1603 +--rw end-time? uint64 1604 +--rw source-count 1605 | +--rw low-percentile-g? yang:gauge64 1606 | +--rw mid-percentile-g? yang:gauge64 1607 | +--rw high-percentile-g? yang:gauge64 1608 | +--rw peak-g? yang:gauge64 1609 +--rw top-talker 1610 +--rw source-prefix* [source-prefix] 1611 +--rw spoofed-status? boolean 1612 +--rw source-prefix inet:ip-prefix 1613 +--rw total-attack-traffic* [unit] 1614 | +--rw unit unit 1615 | +--rw low-percentile-g? yang:gauge64 1616 | +--rw mid-percentile-g? yang:gauge64 1617 | +--rw high-percentile-g? yang:gauge64 1618 | +--rw peak-g? yang:gauge64 1619 +--rw total-attack-connection 1620 +--rw low-percentile-l* [protocol] 1621 | ... 1622 +--rw mid-percentile-l* [protocol] 1623 | ... 1624 +--rw high-percentile-l* [protocol] 1625 | ... 1626 +--rw peak-l* [protocol] 1627 ... 1629 Figure 26: Attack Detail Tree Structure 1631 7.2. From DOTS Clients to DOTS Servers 1633 DOTS clients uses PUT request to signal pre-mitigation telemetry to 1634 DOTS servers. An example of such request is shown in Figure 27. 1636 Header: PUT (Code=0.03) 1637 Uri-Path: ".well-known" 1638 Uri-Path: "dots" 1639 Uri-Path: "tm" 1640 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1641 Uri-Path: "tmid=123" 1642 Content-Format: "application/dots+cbor" 1644 { 1645 "ietf-dots-telemetry:telemetry": { 1646 "target": [ 1647 { 1648 "target-prefix": [ 1649 "2001:db8::1/128" 1650 ] 1651 "total-attack-traffic": [ 1652 { 1653 "protocol": 17, 1654 "unit": "megabytes-ps", 1655 "mid-percentile-g": "900" 1656 } 1657 ], 1658 "attack-detail": { 1659 "start-time": "1957811234", 1660 "attack-severity": "emergency" 1661 } 1662 } 1663 ] 1664 } 1665 } 1667 Figure 27: PUT to Send Pre-Mitigation Telemetry 1669 'cuid' is a mandatory Uri-Path parameter for PUT requests. 1671 The following additional Uri-Path parameter is defined: 1673 tmid: Telemetry Identifier is an identifier for the DOTS pre- 1674 mitigation telemetry data represented as an integer. This 1675 identifier MUST be generated by DOTS clients. 'tsid' values MUST 1676 increase monotonically (when a new PUT is generated by a DOTS 1677 client to convey pre-mitigation telemetry). 1679 This is a mandatory attribute. 1681 At least 'target' attribute and another pre-mitigation attributes 1682 (Section 7.1) MUST be present in the PUT request. If only the 1683 'target' attribute is present, this request is handled as per 1684 Section 7.3. 1686 The relative order of two PUT requests carrying DOTS pre-mitigation 1687 telemetry from a DOTS client is determined by comparing their 1688 respective 'tmid' values. If such two requests have overlapping 1689 'target', the PUT request with higher numeric 'tmid' value will 1690 override the request with a lower numeric 'tmid' value. The 1691 overlapped lower numeric 'tmid' MUST be automatically deleted and no 1692 longer be available. 1694 <> 1696 <> 1698 7.3. From DOTS Servers to DOTS Client 1700 The pre-mitigation (attack details, in particular) can also be 1701 signaled from DOTS servers to DOTS clients. For example, the DOTS 1702 server co-located with a DDoS detector collects monitoring 1703 information from the target network, identifies DDoS attack using 1704 statistical analysis or deep learning techniques, and signals the 1705 attack details to the DOTS client. 1707 The DOTS client can use the attack details to decide whether to 1708 trigger a DOTS mitigation request or not. Furthermore, the security 1709 operation personnel at the DOTS client domain can use the attack 1710 details to determine the protection strategy and select the 1711 appropriate DOTS server for mitigating the attack. 1713 In order to receive pre-mitigation telemetry notifications from a 1714 DOTS server, a DOTS client MUST send a PUT (followed by a GET) with 1715 the target filter. An example of such request is shown in Figure 28. 1716 In order to avoid maintaining a long list of such requests, it is 1717 RECOMMENDED that DOTS clients include all targets in the same 1718 request. DOTS servers may be instructed to restrict the number of 1719 pre-mitigation requests per DOTS client domain. 1721 Header: PUT (Code=0.03) 1722 Uri-Path: ".well-known" 1723 Uri-Path: "dots" 1724 Uri-Path: "tm" 1725 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1726 Uri-Path: "tmid=123" 1727 Content-Format: "application/dots+cbor" 1729 { 1730 "ietf-dots-telemetry:telemetry": { 1731 "target": { 1732 { 1733 "target-prefix": [ 1734 "2001:db8::/32" 1735 ] 1736 } 1737 } 1738 } 1739 } 1741 Figure 28: PUT to Request Pre-Mitigation Telemetry 1743 <<>> 1746 DOTS clients of the same domain can request to receive pre-mitigation 1747 telemetry bound to the same target. 1749 Then, the DOTS client conveys the Observe Option set to '0' in the 1750 GET request to receive asynchronous notifications carrying pre- 1751 mitigation telemetry data from the DOTS server. The GET request 1752 specify a 'tmid' (Figure 29) or not (Figure 30). 1754 Header: GET (Code=0.01) 1755 Uri-Path: ".well-known" 1756 Uri-Path: "dots" 1757 Uri-Path: "tm" 1758 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1759 Uri-Path: "tmid=123" 1760 Observe: 0 1762 Figure 29: GET to Subscribe to Telemetry Asynchronous Notifications 1763 for a Specific 'tmid' 1765 Header: GET (Code=0.01) 1766 Uri-Path: ".well-known" 1767 Uri-Path: "dots" 1768 Uri-Path: "tm" 1769 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1770 Observe: 0 1772 Figure 30: GET to Subscribe to Telemetry Asynchronous Notifications 1773 for All 'tmids' 1775 The DOTS server will then send asynchronous notifications to the DOTS 1776 client when an event if following similar considerations as in 1777 Section 4.4.2.1 of [I-D.ietf-dots-signal-channel]. An example of a 1778 pre-mitugation telemetry notification is shown in Figure 31. 1780 { 1781 "ietf-dots-telemetry:telemetry": { 1782 "target": [ 1783 { 1784 "tmid": 123, 1785 "target-prefix": [ 1786 "2001:db8::1/128" 1787 ] 1788 "total-attack-traffic": [ 1789 { 1790 "protocol": 17, 1791 "unit": "megabytes-ps", 1792 "mid-percentile-g": "900" 1793 } 1794 ], 1795 "attack-detail": { 1796 "start-time": "1957818434", 1797 "attack-severity": "emergency" 1798 } 1799 } 1800 ] 1801 } 1802 } 1804 Figure 31: Message Body of a Pre-mitigation Telemetry Notification 1805 from the DOTS Server 1807 A DOTS server may aggregate pre-mitigation data (e.g., 'top-talkers') 1808 for all targets of a domain, or when justified, send specific 1809 information (e.g., 'top-talkers') per individual targets. 1811 The DOTS client may log pre-mitigation telemetry data with an alert 1812 to an administrator or a network controller. The DOTS client may 1813 send a mitigation request if the attack cannot be handled locally. 1815 8. DOTS Telemetry Mitigation Status Update 1817 8.1. DOTS Client to Server Mitigation Efficacy DOTS Telemetry 1818 Attributes 1820 The mitigation efficacy telemetry attributes can be signaled from 1821 DOTS clients to DOTS servers as part of the periodic mitigation 1822 efficacy updates to the server (Section 5.3.4 of 1823 [I-D.ietf-dots-signal-channel]). 1825 Total Attack Traffic: The overall attack traffic as observed from 1826 the DOTS client perspective during an active mitigation. See 1827 Figure 24. 1829 Attack Details: The overall attack details as observed from the 1830 DOTS client perspective during an active mitigation. See 1831 Section 7.1.5. 1833 The "ietf-dots-telemetry" YANG module augments the "mitigation-scope" 1834 type message defined in "ietf-dots-signal" so that these attributes 1835 can be signalled by a DOTS client in a mitigation efficacy update 1836 (Figure 32). 1838 augment /ietf-signal:dots-signal/ietf-signal:message-type 1839 /ietf-signal:mitigation-scope/ietf-signal:scope: 1840 +--rw total-attack-traffic* [unit] {dots-telemetry}? 1841 | ... 1842 +--rw attack-detail {dots-telemetry}? 1843 +--rw id? uint32 1844 +--rw attack-id? string 1845 +--rw attack-name? string 1846 +--rw attack-severity? attack-severity 1847 +--rw start-time? uint64 1848 +--rw end-time? uint64 1849 +--rw source-count 1850 | ... 1851 +--rw top-talker 1852 ... 1854 Figure 32: Telemetry Efficacy Update Tree Structure 1856 In order to signal telemetry data in a mitigation efficacy update, it 1857 is RECOMMENDED that the DOTS client has already established a DOTS 1858 telemetry setup session with the server in 'idle' time. 1860 Header: PUT (Code=0.03) 1861 Uri-Path: ".well-known" 1862 Uri-Path: "dots" 1863 Uri-Path: "mitigate" 1864 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1865 Uri-Path: "mid=123" 1866 If-Match: 1867 Content-Format: "application/dots+cbor" 1869 { 1870 "ietf-dots-signal-channel:mitigation-scope": { 1871 "scope": [ 1872 { 1873 "alias-name": [ 1874 "myserver" 1875 ], 1876 "attack-status": "under-attack", 1877 "ietf-dots-telemetry:total-attack-traffic": [ 1878 { 1879 "ietf-dots-telemetry:unit": "megabytes-ps", 1880 "ietf-dots-telemetry:mid-percentile-g": "900" 1881 } 1882 ] 1883 } 1884 ] 1885 } 1886 } 1888 Figure 33: An Example of Mitigation Efficacy Update with Telemetry 1889 Attributes 1891 8.2. DOTS Server to Client Mitigation Status DOTS Telemetry Attributes 1893 The mitigation status telemetry attributes can be signaled from the 1894 DOTS server to the DOTS client as part of the periodic mitigation 1895 status update (Section 5.3.3 of [I-D.ietf-dots-signal-channel]). In 1896 particular, DOTS clients can receive asynchronous notifications of 1897 the attack details from DOTS servers using the Observe option defined 1898 in [RFC7641]. 1900 In order to make use of this feature, DOTS clients MUST establish a 1901 telemetry setup session with the DOTS server in 'idle' time and MUST 1902 set the 'server-originated-telemetry' attribute to 'true'. 1904 DOTS servers MUST NOT include telemetry attributes in mitigation 1905 status updates sent to DOTS clients for which 'server-originated- 1906 telemetry' attribute is set to 'false'. 1908 As defined in [RFC8612], the actual mitigation activities can include 1909 several countermeasure mechanisms. The DOTS server signals the 1910 current operational status to each relevant countermeasure. A list 1911 of attacks detected by each countermeasure MAY also be included. The 1912 same attributes defined for Section 7.1.5 are applicable for 1913 describing the attacks detected and mitigated. 1915 The "ietf-dots-telemetry" YANG module (Section 9) augments the 1916 "mitigation-scope" type message defined in "ietf-dots-signal" with 1917 telemetry data as depicted in following tree structure: 1919 augment /ietf-signal:dots-signal/ietf-signal:message-type 1920 /ietf-signal:mitigation-scope/ietf-signal:scope: 1921 +--ro total-traffic* [unit protocol] {dots-telemetry}? 1922 | +--ro unit unit 1923 | +--ro protocol uint8 1924 | +--ro low-percentile-g? yang:gauge64 1925 | +--ro mid-percentile-g? yang:gauge64 1926 | +--ro high-percentile-g? yang:gauge64 1927 | +--ro peak-g? yang:gauge64 1928 +--rw total-attack-traffic* [unit] {dots-telemetry}? 1929 | +--rw unit unit 1930 | +--rw low-percentile-g? yang:gauge64 1931 | +--rw mid-percentile-g? yang:gauge64 1932 | +--rw high-percentile-g? yang:gauge64 1933 | +--rw peak-g? yang:gauge64 1934 +--ro total-attack-connection {dots-telemetry}? 1935 | +--ro low-percentile-c 1936 | | +--ro connection? yang:gauge64 1937 | | +--ro embryonic? yang:gauge64 1938 | | +--ro connection-ps? yang:gauge64 1939 | | +--ro request-ps? yang:gauge64 1940 | | +--ro partial-request-ps? yang:gauge64 1941 | +--ro mid-percentile-c 1942 | | ... 1943 | +--ro high-percentile-c 1944 | | ... 1945 | +--ro peak-c 1946 | ... 1947 +--rw attack-detail {dots-telemetry}? 1948 +--rw id? uint32 1949 +--rw attack-id? string 1950 +--rw attack-name? string 1951 +--rw attack-severity? attack-severity 1952 +--rw start-time? uint64 1953 +--rw end-time? uint64 1954 +--rw source-count 1955 | +--rw low-percentile-g? yang:gauge64 1956 | +--rw mid-percentile-g? yang:gauge64 1957 | +--rw high-percentile-g? yang:gauge64 1958 | +--rw peak-g? yang:gauge64 1959 +--rw top-talker 1960 +--rw source-prefix* [source-prefix] 1961 +--rw spoofed-status? boolean 1962 +--rw source-prefix inet:ip-prefix 1963 +--rw total-attack-traffic* [unit] 1964 | +--rw unit unit 1965 | +--rw low-percentile-g? yang:gauge64 1966 | +--rw mid-percentile-g? yang:gauge64 1967 | +--rw high-percentile-g? yang:gauge64 1968 | +--rw peak-g? yang:gauge64 1969 +--rw total-attack-connection 1970 +--rw low-percentile-c 1971 | +--rw connection? yang:gauge64 1972 | +--rw embryonic? yang:gauge64 1973 | +--rw connection-ps? yang:gauge64 1974 | +--rw request-ps? yang:gauge64 1975 | +--rw partial-request-ps? yang:gauge64 1976 +--rw mid-percentile-c 1977 | ... 1978 +--rw high-percentile-c 1979 | ... 1980 +--rw peak-c 1981 ... 1983 Figure 34 shows an example of an asynchronous notification of attack 1984 mitigation status from the DOTS server. This notification signals 1985 both the mid-percentile value of processed attack traffic and the 1986 peak percentile value of unique sources involved in the attack. 1988 { 1989 "ietf-dots-signal-channel:mitigation-scope": { 1990 "scope": [ 1991 { 1992 "mid": 12332, 1993 "mitigation-start": "1507818434", 1994 "alias-name": [ 1995 "myserver" 1996 ], 1997 "lifetime": 1600, 1998 "status": "attack-successfully-mitigated", 1999 "bytes-dropped": "134334555", 2000 "bps-dropped": "43344", 2001 "pkts-dropped": "333334444", 2002 "pps-dropped": "432432", 2003 "ietf-dots-telemetry:total-attack-traffic": [ 2004 { 2005 "ietf-dots-telemetry:unit": "megabytes-ps", 2006 "ietf-dots-telemetry:mid-percentile-g": "900" 2007 } 2008 ], 2009 "ietf-dots-telemetry::attack-detail": { 2010 "ietf-dots-telemetry:source-count": { 2011 "ietf-dots-telemetry:peak-g": "10000" 2012 } 2013 } 2014 } 2015 ] 2016 } 2017 } 2019 Figure 34: Response Body of a Mitigation Status With Telemetry 2020 Attributes 2022 9. YANG Module 2024 This module uses types defined in [RFC6991] and [RFC8345]. 2026 file "ietf-dots-telemetry@2020-01-23.yang" 2027 module ietf-dots-telemetry { 2028 yang-version 1.1; 2029 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry"; 2030 prefix dots-telemetry; 2032 import ietf-dots-signal-channel { 2033 prefix ietf-signal; 2034 reference 2035 "RFC SSSS: Distributed Denial-of-Service Open Threat 2036 Signaling (DOTS) Signal Channel Specification"; 2037 } 2038 import ietf-dots-data-channel { 2039 prefix ietf-data; 2040 reference 2041 "RFC DDDD: Distributed Denial-of-Service Open Threat 2042 Signaling (DOTS) Data Channel Specification"; 2043 } 2044 import ietf-yang-types { 2045 prefix yang; 2046 reference 2047 "Section 3 of RFC 6991"; 2048 } 2049 import ietf-inet-types { 2050 prefix inet; 2051 reference 2052 "Section 4 of RFC 6991"; 2053 } 2054 import ietf-network-topology { 2055 prefix nt; 2056 reference 2057 "Section 6.2 of RFC 8345: A YANG Data Model for Network 2058 Topologies"; 2059 } 2061 organization 2062 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 2063 contact 2064 "WG Web: 2065 WG List: 2067 Author: Mohamed Boucadair 2068 2070 Author: Konda, Tirumaleswar Reddy 2071 "; 2072 description 2073 "This module contains YANG definitions for the signaling 2074 of DOTS telemetry exchanged between a DOTS client and 2075 a DOTS server, by means of the DOTS signal channel. 2077 Copyright (c) 2020 IETF Trust and the persons identified as 2078 authors of the code. All rights reserved. 2080 Redistribution and use in source and binary forms, with or 2081 without modification, is permitted pursuant to, and subject 2082 to the license terms contained in, the Simplified BSD License 2083 set forth in Section 4.c of the IETF Trust's Legal Provisions 2084 Relating to IETF Documents 2085 (http://trustee.ietf.org/license-info). 2087 This version of this YANG module is part of RFC XXXX; see 2088 the RFC itself for full legal notices."; 2090 revision 2020-01-23 { 2091 description 2092 "Initial revision."; 2093 reference 2094 "RFC XXXX: Distributed Denial-of-Service Open Threat 2095 Signaling (DOTS) Telemetry"; 2096 } 2098 feature dots-telemetry { 2099 description 2100 "This feature means that the DOTS signal channel is able 2101 to convey DOTS telemetry data between DOTS clients and 2102 servers."; 2103 } 2105 typedef attack-severity { 2106 type enumeration { 2107 enum emergency { 2108 value 1; 2109 description 2110 "The attack is severe: emergency."; 2111 } 2112 enum critical { 2113 value 2; 2114 description 2115 "The attack is critical."; 2116 } 2117 enum alert { 2118 value 3; 2119 description 2120 "This is an alert."; 2121 } 2122 } 2123 description 2124 "Enumeration for attack severity."; 2125 } 2127 typedef unit { 2128 type enumeration { 2129 enum pps { 2130 value 1; 2131 description 2132 "Packets per second (PPS)."; 2133 } 2134 enum kilo-pps { 2135 value 2; 2136 description 2137 "Kilo packets per second (Kpps)."; 2138 } 2139 enum bps { 2140 value 3; 2141 description 2142 "Bit per Second (BPS)."; 2143 } 2144 enum kilobyte-ps { 2145 value 4; 2146 description 2147 "Kilobyte per second."; 2148 } 2149 enum megabyte-ps { 2150 value 5; 2151 description 2152 "Megabyte per second."; 2153 } 2154 enum gigabit-ps { 2155 value 6; 2156 description 2157 "Gigabit per second."; 2158 } 2159 enum gigabyte-ps { 2160 value 7; 2161 description 2162 "Gigabyte per second."; 2163 } 2164 enum terabit-ps { 2165 value 8; 2166 description 2167 "Terabit per second."; 2168 } 2169 } 2170 description 2171 "Enumeration to indicate which unit is used."; 2172 } 2174 typedef interval { 2175 type enumeration { 2176 enum hour { 2177 value 1; 2178 description 2179 "Hour."; 2181 } 2182 enum day { 2183 value 2; 2184 description 2185 "Day."; 2186 } 2187 enum week { 2188 value 3; 2189 description 2190 "Week."; 2191 } 2192 enum month { 2193 value 4; 2194 description 2195 "Month."; 2196 } 2197 } 2198 description 2199 "Enumeration to indicate the overall measurement period."; 2200 } 2202 typedef sample { 2203 type enumeration { 2204 enum second { 2205 value 1; 2206 description 2207 "Second."; 2208 } 2209 enum 5-seconds { 2210 value 2; 2211 description 2212 "5 seconds."; 2213 } 2214 enum 30-seconds { 2215 value 3; 2216 description 2217 "30 seconds."; 2218 } 2219 enum minute { 2220 value 4; 2221 description 2222 "One minute."; 2223 } 2224 enum 5-minutes { 2225 value 5; 2226 description 2227 "5 minutes."; 2228 } 2229 enum 10-minutes { 2230 value 6; 2231 description 2232 "10 minutes."; 2233 } 2234 enum 30-minutes { 2235 value 7; 2236 description 2237 "30 minutes."; 2238 } 2239 enum hour { 2240 value 8; 2241 description 2242 "One hour."; 2243 } 2244 } 2245 description 2246 "Enumeration to indicate the measurement perdiod."; 2247 } 2249 typedef percentile { 2250 type decimal64 { 2251 fraction-digits 2; 2252 } 2253 description 2254 "The nth percentile of a set of data is the 2255 value at which n percent of the data is below it."; 2256 } 2258 grouping percentile-config { 2259 description 2260 "Configuration of low, mid, and high percentile values."; 2261 leaf measurement-interval { 2262 type interval; 2263 description 2264 "Defines the period on which percentiles are computed."; 2265 } 2266 leaf measurement-sample { 2267 type sample; 2268 description 2269 "Defines the time distribution for measuring 2270 values that are used to compute percentiles.."; 2271 } 2272 leaf low-percentile { 2273 type percentile; 2274 default "10.00"; 2275 description 2276 "Low percentile. If set to '0', this means low-percentiles 2277 are disabled."; 2278 } 2279 leaf mid-percentile { 2280 type percentile; 2281 must '. >= ../low-percentile' { 2282 error-message 2283 "The mid-percentile must be greater than 2284 or equal to the low-percentile."; 2285 } 2286 default "50.00"; 2287 description 2288 "Mid percentile. If set to the same value as low-percentiles, 2289 this means mid-percentiles are disabled."; 2290 } 2291 leaf high-percentile { 2292 type percentile; 2293 must '. >= ../mid-percentile' { 2294 error-message 2295 "The high-percentile must be greater than 2296 or equal to the mid-percentile."; 2297 } 2298 default "90.00"; 2299 description 2300 "High percentile. If set to the same value as mid-percentiles, 2301 this means high-percentiles are disabled."; 2302 } 2303 } 2305 grouping percentile { 2306 description 2307 "Generic grouping for percentile."; 2308 leaf low-percentile-g { 2309 type yang:gauge64; 2310 description 2311 "Low traffic."; 2312 } 2313 leaf mid-percentile-g { 2314 type yang:gauge64; 2315 description 2316 "Mid percentile."; 2317 } 2318 leaf high-percentile-g { 2319 type yang:gauge64; 2320 description 2321 "High percentile."; 2322 } 2323 leaf peak-g { 2324 type yang:gauge64; 2325 description 2326 "Peak"; 2327 } 2328 } 2330 grouping unit-config { 2331 description 2332 "Generic grouping for unit configuration."; 2333 list unit-config { 2334 key "unit"; 2335 description 2336 "Controls which units are allowed when sharing telemetry 2337 data."; 2338 leaf unit { 2339 type unit; 2340 description 2341 "The traffic can be measured in packets per 2342 second (PPS) or kilo packets per second (Kpps) and Bits per 2343 Second (BPS), and kilobytes per second or megabytes per second 2344 or gigabytes per second."; 2345 } 2346 leaf unit-status { 2347 type boolean; 2348 description 2349 "Enable/disable the use of the measurement unit."; 2350 } 2351 } 2352 } 2354 grouping traffic-unit { 2355 description 2356 "Grouping of traffic as a function of measurement unit."; 2357 leaf unit { 2358 type unit; 2359 description 2360 "The traffic can be measured in packets per 2361 second (PPS) or kilo packets per second (Kpps) and Bits per 2362 Second (BPS), and kilobytes per second or megabytes per second 2363 or gigabytes per second."; 2364 } 2365 uses percentile; 2366 } 2368 grouping traffic-unit-protocol { 2369 description 2370 "Grouping of traffic of a given transport protocol as 2371 a function of measurement unit."; 2372 leaf unit { 2373 type unit; 2374 description 2375 "The traffic can be measured in packets per 2376 second (PPS) or kilo packets per second (Kpps) and Bits per 2377 Second (BPS), and kilobytes per second or megabytes per second 2378 or gigabytes per second."; 2379 } 2380 leaf protocol { 2381 type uint8; 2382 description 2383 "The transport protocol. 2384 Values are taken from the IANA Protocol Numbers registry: 2385 . 2387 For example, this field contains 6 for TCP, 2388 17 for UDP, 33 for DCCP, or 132 for SCTP."; 2389 } 2390 uses percentile; 2391 } 2393 grouping total-connection-capacity { 2394 description 2395 "Total Connections Capacity. If the target is subjected 2396 to resource consuming DDoS attack, these attributes are 2397 useful to detect resource consuming DDoS attacks"; 2398 leaf connection { 2399 type uint64; 2400 description 2401 "The maximum number of simultaneous connections that 2402 are allowed to the target server. The threshold is 2403 transport-protocol specific because the target server 2404 could support multiple protocols."; 2405 } 2406 leaf connection-client { 2407 type uint64; 2408 description 2409 "The maximum number of simultaneous connections that 2410 are allowed to the target server per client."; 2411 } 2412 leaf embryonic { 2413 type uint64; 2414 description 2415 "The maximum number of simultaneous embryonic connections 2416 that are allowed to the target server. The term 'embryonic 2417 connection' refers to a connection whose connection handshake 2418 is not finished and embryonic connection is only possible in 2419 connection-oriented transport protocols like TCP or SCTP."; 2420 } 2421 leaf embryonic-client { 2422 type uint64; 2423 description 2424 "The maximum number of simultaneous embryonic connections 2425 that are allowed to the target server per client."; 2426 } 2427 leaf connection-ps { 2428 type uint64; 2429 description 2430 "The maximum number of connections allowed per second 2431 to the target server."; 2432 } 2433 leaf connection-client-ps { 2434 type uint64; 2435 description 2436 "The maximum number of connections allowed per second 2437 to the target server per client."; 2438 } 2439 leaf request-ps { 2440 type uint64; 2441 description 2442 "The maximum number of requests allowed per second 2443 to the target server."; 2444 } 2445 leaf request-client-ps { 2446 type uint64; 2447 description 2448 "The maximum number of requests allowed per second 2449 to the target server per client."; 2450 } 2451 leaf partial-request-ps { 2452 type uint64; 2453 description 2454 "The maximum number of partial requests allowed per 2455 second to the target server."; 2456 } 2457 leaf partial-request-client-ps { 2458 type uint64; 2459 description 2460 "The maximum number of partial requests allowed per 2461 second to the target server per client."; 2462 } 2463 } 2465 grouping connection { 2466 description 2467 "A set of attributes which represent the attack 2468 characteristics"; 2470 leaf connection { 2471 type yang:gauge64; 2472 description 2473 "The number of simultaneous attack connections to 2474 the target server."; 2475 } 2476 leaf embryonic { 2477 type yang:gauge64; 2478 description 2479 "The number of simultaneous embryonic connections to 2480 the target server."; 2481 } 2482 leaf connection-ps { 2483 type yang:gauge64; 2484 description 2485 "The number of attack connections per second to 2486 the target server."; 2487 } 2488 leaf request-ps { 2489 type yang:gauge64; 2490 description 2491 "The number of attack requests per second to 2492 the target server."; 2493 } 2494 leaf partial-request-ps { 2495 type yang:gauge64; 2496 description 2497 "The number of attack partial requests to 2498 the target server."; 2499 } 2500 } 2502 grouping connection-percentile { 2503 description 2504 "Total attack connections."; 2505 container low-percentile-c { 2506 description 2507 "Low percentile of attack connections."; 2508 uses connection; 2509 } 2510 container mid-percentile-c { 2511 description 2512 "Mid percentile of attack connections."; 2513 uses connection; 2514 } 2515 container high-percentile-c { 2516 description 2517 "High percentile of attack connections."; 2519 uses connection; 2520 } 2521 container peak-c { 2522 description 2523 "Peak attack connections."; 2524 uses connection; 2525 } 2526 } 2528 grouping connection-protocol-percentile { 2529 description 2530 "Total attack connections."; 2531 list low-percentile-l { 2532 key "protocol"; 2533 description 2534 "Low percentile of attack connections."; 2535 leaf protocol { 2536 type uint8; 2537 description 2538 "The transport protocol. 2539 Values are taken from the IANA Protocol Numbers registry: 2540 ."; 2541 } 2542 uses connection; 2543 } 2544 list mid-percentile-l { 2545 key "protocol"; 2546 description 2547 "Mid percentile of attack connections."; 2548 leaf protocol { 2549 type uint8; 2550 description 2551 "The transport protocol. 2552 Values are taken from the IANA Protocol Numbers registry: 2553 ."; 2554 } 2555 uses connection; 2556 } 2557 list high-percentile-l { 2558 key "protocol"; 2559 description 2560 "Highg percentile of attack connections."; 2561 leaf protocol { 2562 type uint8; 2563 description 2564 "The transport protocol. 2565 Values are taken from the IANA Protocol Numbers registry: 2566 ."; 2568 } 2569 uses connection; 2570 } 2571 list peak-l { 2572 key "protocol"; 2573 description 2574 "Peak attack connections."; 2575 leaf protocol { 2576 type uint8; 2577 description 2578 "The transport protocol. 2579 Values are taken from the IANA Protocol Numbers registry: 2580 ."; 2581 } 2582 uses connection; 2583 } 2584 } 2586 grouping attack-detail { 2587 description 2588 "Various information and details that describe the on-going 2589 attacks that needs to be mitigated by the DOTS server. 2590 The attack details need to cover well-known and common attacks 2591 (such as a SYN Flood) along with new emerging or vendor-specific 2592 attacks."; 2593 leaf id { 2594 type uint32; 2595 description 2596 "Vendor ID is a security vendor's Enterprise Number."; 2597 } 2598 leaf attack-id { 2599 type string; 2600 description 2601 "Unique identifier assigned by the vendor for the attack."; 2602 } 2603 leaf attack-name { 2604 type string; 2605 description 2606 "Textual representation of attack description. Natural Language 2607 Processing techniques (e.g., word embedding) can possibly be used 2608 to map the attack description to an attack type."; 2609 } 2610 leaf attack-severity { 2611 type attack-severity; 2612 description 2613 "Severity level of an attack"; 2614 } 2615 leaf start-time { 2616 type uint64; 2617 description 2618 "The time the attack started. Start time is represented in seconds 2619 relative to 1970-01-01T00:00:00Z in UTC time."; 2620 } 2621 leaf end-time { 2622 type uint64; 2623 description 2624 "The time the attack ended. End time is represented in seconds 2625 relative to 1970-01-01T00:00:00Z in UTC time."; 2626 } 2627 container source-count { 2628 description 2629 "Indicates the count of unique sources involved 2630 in the attack."; 2631 uses percentile; 2632 } 2633 } 2635 grouping top-talker-aggregate { 2636 description 2637 "Top attack sources."; 2638 list source-prefix { 2639 key "source-prefix"; 2640 description 2641 "IPv4 or IPv6 prefix identifying the attacker(s)."; 2642 leaf spoofed-status { 2643 type boolean; 2644 description 2645 "Indicates whether this address is spoofed."; 2646 } 2647 leaf source-prefix { 2648 type inet:ip-prefix; 2649 description 2650 "IPv4 or IPv6 prefix identifying the attacker(s)."; 2651 } 2652 list total-attack-traffic { 2653 key "unit"; 2654 description 2655 "Total attack traffic issued from this source."; 2656 uses traffic-unit; 2657 } 2658 container total-attack-connection { 2659 description 2660 "Total attack connections issued from this source."; 2661 uses connection-percentile; 2662 } 2663 } 2665 } 2667 grouping top-talker { 2668 description 2669 "Top attack sources."; 2670 list source-prefix { 2671 key "source-prefix"; 2672 description 2673 "IPv4 or IPv6 prefix identifying the attacker(s)."; 2674 leaf spoofed-status { 2675 type boolean; 2676 description 2677 "Indicates whether this address is spoofed."; 2678 } 2679 leaf source-prefix { 2680 type inet:ip-prefix; 2681 description 2682 "IPv4 or IPv6 prefix identifying the attacker(s)."; 2683 } 2684 list total-attack-traffic { 2685 key "unit"; 2686 description 2687 "Total attack traffic issued from this source."; 2688 uses traffic-unit; 2689 } 2690 container total-attack-connection { 2691 description 2692 "Total attack connections issued from this source."; 2693 uses connection-protocol-percentile; 2694 } 2695 } 2696 } 2698 grouping baseline { 2699 description 2700 "Grouping for the telemetry baseline."; 2701 uses ietf-data:target; 2702 leaf-list alias-name { 2703 type string; 2704 description 2705 "An alias name that points to a resource."; 2706 } 2707 list total-traffic-normal-baseline { 2708 key "unit protocol"; 2709 description 2710 "Total traffic normal baselines."; 2711 uses traffic-unit-protocol; 2712 } 2713 list total-connection-capacity { 2714 key "protocol"; 2715 description 2716 "Total connection capacity."; 2717 leaf protocol { 2718 type uint8; 2719 description 2720 "The transport protocol. 2721 Values are taken from the IANA Protocol Numbers registry: 2722 ."; 2723 } 2724 uses total-connection-capacity; 2725 } 2726 } 2728 grouping pre-mitigation { 2729 description 2730 "Grouping for the telemetry data."; 2731 list total-traffic { 2732 key "unit protocol"; 2733 description 2734 "Total traffic."; 2735 uses traffic-unit-protocol; 2736 } 2737 list total-attack-traffic { 2738 key "unit protocol"; 2739 description 2740 "Total attack traffic per protocol."; 2741 uses traffic-unit-protocol; 2742 } 2743 container total-attack-connection { 2744 description 2745 "Total attack connections."; 2746 uses connection-protocol-percentile; 2747 } 2748 container attack-detail { 2749 description 2750 "Attack details."; 2751 uses attack-detail; 2752 container top-talker { 2753 description 2754 "Top attack sources."; 2755 uses top-talker; 2756 } 2757 } 2758 } 2760 augment "/ietf-signal:dots-signal/ietf-signal:message-type/" 2761 + "ietf-signal:mitigation-scope/ietf-signal:scope" { 2762 if-feature "dots-telemetry"; 2763 description 2764 "Extends mitigation scope with telemetry update data."; 2765 list total-traffic { 2766 key "unit protocol"; 2767 config false; 2768 description 2769 "Total traffic."; 2770 uses traffic-unit-protocol; 2771 } 2772 list total-attack-traffic { 2773 key "unit"; 2774 description 2775 "Total attack traffic."; 2776 uses traffic-unit; 2777 } 2778 container total-attack-connection { 2779 config false; 2780 description 2781 "Total attack connections."; 2782 uses connection-percentile; 2783 } 2784 container attack-detail { 2785 description 2786 "Atatck details"; 2787 uses attack-detail; 2788 container top-talker { 2789 description 2790 "Top attack sources."; 2791 uses top-talker-aggregate; 2792 } 2793 } 2794 } 2796 augment "/ietf-signal:dots-signal/ietf-signal:message-type" { 2797 if-feature "dots-telemetry"; 2798 description 2799 "Add a new choice to enclose telemetry data in DOTS 2800 signal channel."; 2801 case telemetry-setup { 2802 description 2803 "Indicates the message is about telemetry."; 2804 list telemetry { 2805 key "cuid tsid"; 2806 description 2807 "The telemetry data per DOTS client."; 2808 leaf cuid { 2809 type string; 2810 description 2811 "A unique identifier that is 2812 generated by a DOTS client to prevent 2813 request collisions. It is expected that the 2814 cuid will remain consistent throughout the 2815 lifetime of the DOTS client."; 2816 } 2817 leaf cdid { 2818 type string; 2819 description 2820 "The cdid should be included by a server-domain 2821 DOTS gateway to propagate the client domain 2822 identification information from the 2823 gateway's client-facing-side to the gateway's 2824 server-facing-side, and from the gateway's 2825 server-facing-side to the DOTS server. 2827 It may be used by the final DOTS server 2828 for policy enforcement purposes."; 2829 } 2830 leaf tsid { 2831 type uint32; 2832 description 2833 "An identifier for the DOTS telemetry setup 2834 data."; 2835 } 2836 choice setup-type { 2837 description 2838 "Can be a mitigation configuration, a pipe capacity, 2839 or baseline message."; 2840 case telemetry-config { 2841 description 2842 "Uses to set low, mid, and high percentile values."; 2843 container current-config { 2844 description 2845 "Current configuration values."; 2846 uses percentile-config; 2847 uses unit-config; 2848 leaf server-originated-telemetry { 2849 type boolean; 2850 description 2851 "Used by a DOTS client to enable/disable whether it 2852 accepts pre-mitigation telemetry from the DOTS 2853 server."; 2854 } 2855 leaf telemetry-notify-interval { 2856 type uint32 { 2857 range "1 .. 3600"; 2858 } 2859 units "seconds"; 2860 description 2861 "Minimum number of seconds between successive 2862 telemetry notifications."; 2863 } 2864 } 2865 container max-config-values { 2866 config false; 2867 description 2868 "Maximum acceptable configuration values."; 2869 uses percentile-config; 2870 // Check if this is right place for indciating this capability 2871 leaf server-originated-telemetry { 2872 type boolean; 2873 description 2874 "Indicates whether the DOTS server can be instructed 2875 to send pre-mitigation telemetry. If set to FALSE 2876 or the attribute is not present, this is an indication 2877 that the server does not support this capability."; 2878 } 2879 leaf telemetry-notify-interval { 2880 type uint32 { 2881 range "1 .. 3600"; 2882 } 2883 units "seconds"; 2884 description 2885 "Minimum number of seconds between successive 2886 telemetry notifications."; 2887 } 2888 } 2889 container min-config-values { 2890 config false; 2891 description 2892 "Minimum acceptable configuration values."; 2893 uses percentile-config; 2894 leaf telemetry-notify-interval { 2895 type uint32 { 2896 range "1 .. 3600"; 2897 } 2898 units "seconds"; 2899 description 2900 "Minimum number of seconds between successive 2901 telemetry notifications."; 2902 } 2903 } 2904 container supported-units { 2905 config false; 2906 description 2907 "Supported units and default activation status."; 2908 uses unit-config; 2909 } 2910 } 2911 case pipe { 2912 description 2913 "Total pipe capacity of a DOTS client domain"; 2914 list total-pipe-capacity { 2915 key "link-id unit"; 2916 description 2917 "Total pipe capacity of a DOTS client domain."; 2918 leaf link-id { 2919 type nt:link-id; 2920 description 2921 "Identifier of an interconnection link."; 2922 } 2923 leaf capacity { 2924 type uint64; 2925 mandatory true; 2926 description 2927 "Pipe capacity."; 2928 } 2929 leaf unit { 2930 type unit; 2931 description 2932 "The traffic can be measured in packets per 2933 second (PPS) or kilo packets per second (Kpps) and Bits per 2934 Second (BPS), and kilobytes per second or megabytes per second 2935 or gigabytes per second."; 2936 } 2937 } 2938 } 2939 case baseline { 2940 description 2941 "Traffic baseline information"; 2942 list baseline { 2943 key "id"; 2944 description 2945 "Traffic baseline information"; 2946 leaf id { 2947 type uint32; 2948 must '. >= 1'; 2949 description 2950 "A baseline entry identifier."; 2951 } 2952 uses baseline; 2954 } 2955 } 2956 } 2957 } 2958 } 2959 case telemetry { 2960 description 2961 "Indicates the message is about telemetry."; 2962 list pre-mitigation { 2963 key "cuid tmid"; 2964 description 2965 "Pre-mitigation telemetry per DOTS client."; 2966 leaf cuid { 2967 type string; 2968 description 2969 "A unique identifier that is 2970 generated by a DOTS client to prevent 2971 request collisions. It is expected that the 2972 cuid will remain consistent throughout the 2973 lifetime of the DOTS client."; 2974 } 2975 leaf cdid { 2976 type string; 2977 description 2978 "The cdid should be included by a server-domain 2979 DOTS gateway to propagate the client domain 2980 identification information from the 2981 gateway's client-facing-side to the gateway's 2982 server-facing-side, and from the gateway's 2983 server-facing-side to the DOTS server. 2985 It may be used by the final DOTS server 2986 for policy enforcement purposes."; 2987 } 2988 leaf tmid { 2989 type uint32; 2990 description 2991 "An identifier to uniquely demux telemetry data send using 2992 the same message."; 2993 } 2994 container target { 2995 description 2996 "Indicates the target."; 2997 uses ietf-data:target; 2998 leaf-list alias-name { 2999 type string; 3000 description 3001 "An alias name that points to a resource."; 3003 } 3004 } 3005 uses pre-mitigation; 3006 } 3007 } 3008 } 3009 } 3010 3012 10. YANG/JSON Mapping Parameters to CBOR 3014 All DOTS telemetry parameters in the payload of the DOTS signal 3015 channel MUST be mapped to CBOR types as shown in the following table: 3017 o Some of these attributes should be prepended with "ietf-dots- 3018 telemetry:" 3020 o Implementers may use the values in: https://github.com/boucadair/ 3021 draft-dots-telemetry/blob/master/mapping-table.txt 3023 +----------------------+-------------+------+---------------+--------+ 3024 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 3025 | | Type | Key | Type & | Type | 3026 | | | | Information | | 3027 +----------------------+-------------+------+---------------+--------+ 3028 | ietf-dots-telemetry: | | | | | 3029 | telemetry | container |TBA1 | 5 map | Object | 3030 | tsid | uint32 |TBA2 | 0 unsigned | Number | 3031 | telemetry-config | container |TBA3 | 5 map | Object | 3032 | low-percentile | decimal64 |TBA4 | 6 tag 4 | | 3033 | | | | [-2, integer]| String | 3034 | mid-percentile | decimal64 |TBA5 | 6 tag 4 | | 3035 | | | | [-2, integer]| String | 3036 | high-percentile | decimal64 |TBA6 | 6 tag 4 | | 3037 | | | | [-2, integer]| String | 3038 | unit-config | list |TBA7 | 4 array | Array | 3039 | unit | enumeration |TBA8 | 0 unsigned | String | 3040 | unit-status | boolean |TBA9 | 7 bits 20 | False | 3041 | | | | 7 bits 21 | True | 3042 | total-pipe-capability| list |TBA10 | 4 array | Array | 3043 | pipe | uint64 |TBA11 | 0 unsigned | String | 3044 | pre-mitigation | list |TBA12 | 4 array | Array | 3045 | ietf-dots-telemetry: | | | | | 3046 | telemetry-setup | container |TBA13 | 5 map | Object | 3047 | total-traffic- | | | | | 3048 | normal-baseline | list |TBA14 | 4 array | Array | 3049 | low-percentile-g | yang:gauge64|TBA15 | 0 unsigned | String | 3050 | mid-percentile-g | yang:gauge64|TBA16 | 0 unsigned | String | 3051 | high-percentile-g | yang:gauge64|TBA17 | 0 unsigned | String | 3052 | peak-g | yang:gauge64|TBA18 | 0 unsigned | String | 3053 | total-attack-traffic | list |TBA19 | 4 array | Array | 3054 | total-traffic | list |TBA20 | 4 array | Array | 3055 | total-connection- | | | | | 3056 | capacity | list |TBA21 | 4 array | Array | 3057 | connection | uint64 |TBA22 | 0 unsigned | String | 3058 | connection-client | uint64 |TBA23 | 0 unsigned | String | 3059 | embryonic | uint64 |TBA24 | 0 unsigned | String | 3060 | embryonic-client | uint64 |TBA25 | 0 unsigned | String | 3061 | connection-ps | uint64 |TBA26 | 0 unsigned | String | 3062 | connection-client-ps | uint64 |TBA27 | 0 unsigned | String | 3063 | request-ps | uint64 |TBA28 | 0 unsigned | String | 3064 | request-client-ps | uint64 |TBA29 | 0 unsigned | String | 3065 | partial-request-ps | uint64 |TBA30 | 0 unsigned | String | 3066 | partial-request- | | | | | 3067 | client-ps | uint64 |TBA31 | 0 unsigned | String | 3068 | total-attack- | | | | | 3069 | connection | container |TBA32 | 5 map | Object | 3070 | low-percentile-l | list |TBA33 | 4 array | Array | 3071 | mid-percentile-l | list |TBA34 | 4 array | Array | 3072 | high-percentile-l | list |TBA35 | 4 array | Array | 3073 | peak-l | list |TBA36 | 4 array | Array | 3074 | attack-detail | container |TBA37 | 5 map | Object | 3075 | id | uint32 |TBA38 | 0 unsigned | Number | 3076 | attack-id | string |TBA39 | 3 text string | String | 3077 | attack-name | string |TBA40 | 3 text string | String | 3078 | attack-severity | enumeration |TBA41 | 0 unsigned | String | 3079 | start-time | uint64 |TBA42 | 0 unsigned | String | 3080 | end-time | uint64 |TBA43 | 0 unsigned | String | 3081 | source-count | container |TBA44 | 5 map | Object | 3082 | top-talker | container |TBA45 | 5 map | Object | 3083 | spoofed-status | boolean |TBA46 | 7 bits 20 | False | 3084 | | | | 7 bits 21 | True | 3085 | low-percentile-c | container |TBA47 | 5 map | Object | 3086 | mid-percentile-c | container |TBA48 | 5 map | Object | 3087 | high-percentile-c | container |TBA49 | 5 map | Object | 3088 | peak-c | container |TBA50 | 5 map | Object | 3089 | baseline | container |TBA51 | 5 map | Object | 3090 | current-config | container |TBA52 | 5 map | Object | 3091 | max-config-values | container |TBA53 | 5 map | Object | 3092 | min-config-values | container |TBA54 | 5 map | Object | 3093 | supported-units | container |TBA55 | 5 map | Object | 3094 | server-originated- | boolean |TBA56 | 7 bits 20 | False | 3095 | telemetry | | | 7 bits 21 | True | 3096 | telemetry-notify- | uint32 |TBA57 | 0 unsigned | Number | 3097 | interval | | | | | 3098 | tmid | uint32 |TBA58 | 0 unsigned | Number | 3099 +----------------------+-------------+------+---------------+--------+ 3101 11. IANA Considerations 3103 11.1. DOTS Signal Channel CBOR Key Values 3105 This specification registers the DOTS telemetry attributes in the 3106 IANA "DOTS Signal Channel CBOR Key Values" registry available at 3107 https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel- 3108 cbor-key-values. 3110 The DOTS telemetry attributes defined in this specification are 3111 comprehension-optional parameters. 3113 o Note to the RFC Editor: (1) CBOR keys are assigned from the 3114 32768-49151 range. (2) Please assign the following suggested 3115 values. 3117 +----------------------+-------+-------+------------+---------------+ 3118 | Parameter Name | CBOR | CBOR | Change | Specification | 3119 | | Key | Major | Controller | Document(s) | 3120 | | Value | Type | | | 3121 +----------------------+-------+-------+------------+---------------+ 3122 | ietf-dots-telemetry: | TBA1 | 5 | IESG | [RFCXXXX] | 3123 | telemetry | | | | | 3124 | tsid | TBA2 | 0 | IESG | [RFCXXXX] | 3125 | telemetry-config | TBA3 | 5 | IESG | [RFCXXXX] | 3126 | low-percentile | TBA4 | 6tag4 | IESG | [RFCXXXX] | 3127 | mid-percentile | TBA5 | 6tag4 | IESG | [RFCXXXX] | 3128 | high-percentile | TBA6 | 6tag4 | IESG | [RFCXXXX] | 3129 | unit-config | TBA7 | 4 | IESG | [RFCXXXX] | 3130 | unit | TBA8 | 0 | IESG | [RFCXXXX] | 3131 | unit-status | TBA9 | 7 | IESG | [RFCXXXX] | 3132 | total-pipe-capability| TBA10 | 4 | IESG | [RFCXXXX] | 3133 | pipe | TBA11 | 0 | IESG | [RFCXXXX] | 3134 | pre-mitigation | TBA12 | 4 | IESG | [RFCXXXX] | 3135 | ietf-dots-telemetry: | TBA13 | 5 | IESG | [RFCXXXX] | 3136 | telemetry-setup | | | | | 3137 | total-traffic- | TBA14 | 4 | IESG | [RFCXXXX] | 3138 | normal-baseline | | | | | 3139 | low-percentile-g | TBA15 | 0 | IESG | [RFCXXXX] | 3140 | mid-percentile-g | TBA16 | 0 | IESG | [RFCXXXX] | 3141 | high-percentile-g | TBA17 | 0 | IESG | [RFCXXXX] | 3142 | peak-g | TBA18 | 0 | IESG | [RFCXXXX] | 3143 | total-attack-traffic | TBA19 | 4 | IESG | [RFCXXXX] | 3144 | total-traffic | TBA20 | 4 | IESG | [RFCXXXX] | 3145 | total-connection- | TBA21 | 4 | IESG | [RFCXXXX] | 3146 | capacity | | | | | 3147 | connection | TBA22 | 0 | IESG | [RFCXXXX] | 3148 | connection-client | TBA23 | 0 | IESG | [RFCXXXX] | 3149 | embryonic | TBA24 | 0 | IESG | [RFCXXXX] | 3150 | embryonic-client | TBA25 | 0 | IESG | [RFCXXXX] | 3151 | connection-ps | TBA26 | 0 | IESG | [RFCXXXX] | 3152 | connection-client-ps | TBA27 | 0 | IESG | [RFCXXXX] | 3153 | request-ps | TBA28 | 0 | IESG | [RFCXXXX] | 3154 | request-client-ps | TBA29 | 0 | IESG | [RFCXXXX] | 3155 | partial-request-ps | TBA30 | 0 | IESG | [RFCXXXX] | 3156 | partial-request- | TBA31 | 0 | IESG | [RFCXXXX] | 3157 | client-ps | | | | | 3158 | total-attack- | TBA32 | 5 | IESG | [RFCXXXX] | 3159 | connection | | | | | 3160 | low-percentile-l | TBA33 | 4 | IESG | [RFCXXXX] | 3161 | mid-percentile-l | TBA34 | 4 | IESG | [RFCXXXX] | 3162 | high-percentile-l | TBA35 | 4 | IESG | [RFCXXXX] | 3163 | peak-l | TBA36 | 4 | IESG | [RFCXXXX] | 3164 | attack-detail | TBA37 | 5 | IESG | [RFCXXXX] | 3165 | id | TBA38 | 0 | IESG | [RFCXXXX] | 3166 | attack-id | TBA39 | 3 | IESG | [RFCXXXX] | 3167 | attack-name | TBA40 | 3 | IESG | [RFCXXXX] | 3168 | attack-severity | TBA41 | 0 | IESG | [RFCXXXX] | 3169 | start-time | TBA42 | 0 | IESG | [RFCXXXX] | 3170 | end-time | TBA43 | 0 | IESG | [RFCXXXX] | 3171 | source-count | TBA44 | 5 | IESG | [RFCXXXX] | 3172 | top-talker | TBA45 | 5 | IESG | [RFCXXXX] | 3173 | spoofed-status | TBA46 | 7 | IESG | [RFCXXXX] | 3174 | low-percentile-c | TBA47 | 5 | IESG | [RFCXXXX] | 3175 | mid-percentile-c | TBA48 | 5 | IESG | [RFCXXXX] | 3176 | high-percentile-c | TBA49 | 5 | IESG | [RFCXXXX] | 3177 | peak-c | TBA50 | 5 | IESG | [RFCXXXX] | 3178 | ietf-dots-signal-cha | TBA51 | 5 | IESG | [RFCXXXX] | 3179 | current-config | TBA52 | 5 | IESG | [RFCXXXX] | 3180 | max-config-value | TBA53 | 5 | IESG | [RFCXXXX] | 3181 | min-config-values | TBA54 | 5 | IESG | [RFCXXXX] | 3182 | supported-units | TBA55 | 5 | IESG | [RFCXXXX] | 3183 | server-originated- | TBA56 | 7 | IESG | [RFCXXXX] | 3184 | telemetry | | | | | 3185 | telemetry-notify- | TBA57 | 0 | IESG | [RFCXXXX] | 3186 | interval | | | | | 3187 | tmid | TBA58 | 0 | IESG | [RFCXXXX] | 3188 +----------------------+-------+-------+------------+---------------+ 3190 11.2. DOTS Signal Channel Conflict Cause Codes 3192 This specification requests IANA to assign a new code from the "DOTS 3193 Signal Channel Conflict Cause Codes" registry available at 3194 https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel- 3195 conflict-cause-codes. 3197 Code Label Description Reference 3198 TBA overlapping-pipes Overlapping pipe scope [RFCXXXX] 3200 11.3. DOTS Signal Telemetry YANG Module 3202 This document requests IANA to register the following URI in the "ns" 3203 subregistry within the "IETF XML Registry" [RFC3688]: 3205 URI: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry 3206 Registrant Contact: The IESG. 3207 XML: N/A; the requested URI is an XML namespace. 3209 This document requests IANA to register the following YANG module in 3210 the "YANG Module Names" subregistry [RFC7950] within the "YANG 3211 Parameters" registry. 3213 name: ietf-dots-telemetry 3214 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry 3215 maintained by IANA: N 3216 prefix: dots-telemetry 3217 reference: RFC XXXX 3219 12. Security Considerations 3221 Security considerations in [I-D.ietf-dots-signal-channel] need to be 3222 taken into consideration. 3224 13. Contributors 3226 The following individuals have contributed to this document: 3228 o Li Su, CMCC, Email: suli@chinamobile.com 3230 o Jin Peng, CMCC, Email: pengjin@chinamobile.com 3232 o Pan Wei, Huawei, Email: william.panwei@huawei.com 3234 14. Acknowledgements 3236 The authors would like to thank Flemming Andreasen, Liang Xia, and 3237 Kaname Nishizuka co-authors of https://tools.ietf.org/html/draft- 3238 doron-dots-telemetry-00 draft and everyone who had contributed to 3239 that document. 3241 Authors would like to thank Kaname Nishizuka, Jon Shallow, Wei Pan 3242 and Yuuhei Hayashi for comments and review. 3244 15. References 3246 15.1. Normative References 3248 [Enterprise-Numbers] 3249 "Private Enterprise Numbers", 2005, . 3252 [I-D.ietf-dots-data-channel] 3253 Boucadair, M. and T. Reddy.K, "Distributed Denial-of- 3254 Service Open Threat Signaling (DOTS) Data Channel 3255 Specification", draft-ietf-dots-data-channel-31 (work in 3256 progress), July 2019. 3258 [I-D.ietf-dots-signal-call-home] 3259 Reddy.K, T., Boucadair, M., and J. Shallow, "Distributed 3260 Denial-of-Service Open Threat Signaling (DOTS) Signal 3261 Channel Call Home", draft-ietf-dots-signal-call-home-07 3262 (work in progress), November 2019. 3264 [I-D.ietf-dots-signal-channel] 3265 Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and 3266 N. Teague, "Distributed Denial-of-Service Open Threat 3267 Signaling (DOTS) Signal Channel Specification", draft- 3268 ietf-dots-signal-channel-41 (work in progress), January 3269 2020. 3271 [I-D.ietf-dots-signal-filter-control] 3272 Nishizuka, K., Boucadair, M., Reddy.K, T., and T. Nagata, 3273 "Controlling Filtering Rules Using Distributed Denial-of- 3274 Service Open Threat Signaling (DOTS) Signal Channel", 3275 draft-ietf-dots-signal-filter-control-02 (work in 3276 progress), September 2019. 3278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3279 Requirement Levels", BCP 14, RFC 2119, 3280 DOI 10.17487/RFC2119, March 1997, 3281 . 3283 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3284 DOI 10.17487/RFC3688, January 2004, 3285 . 3287 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3288 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3289 . 3291 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 3292 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 3293 October 2013, . 3295 [RFC7641] Hartke, K., "Observing Resources in the Constrained 3296 Application Protocol (CoAP)", RFC 7641, 3297 DOI 10.17487/RFC7641, September 2015, 3298 . 3300 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3301 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3302 . 3304 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 3305 the Constrained Application Protocol (CoAP)", RFC 7959, 3306 DOI 10.17487/RFC7959, August 2016, 3307 . 3309 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3310 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3311 May 2017, . 3313 15.2. Informative References 3315 [I-D.ietf-dots-multihoming] 3316 Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing 3317 Deployment Considerations for Distributed-Denial-of- 3318 Service Open Threat Signaling (DOTS)", draft-ietf-dots- 3319 multihoming-03 (work in progress), January 2020. 3321 [I-D.ietf-dots-use-cases] 3322 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 3323 L., and K. Nishizuka, "Use cases for DDoS Open Threat 3324 Signaling", draft-ietf-dots-use-cases-20 (work in 3325 progress), September 2019. 3327 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 3328 "Framework for IP Performance Metrics", RFC 2330, 3329 DOI 10.17487/RFC2330, May 1998, 3330 . 3332 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 3333 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 3334 . 3336 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 3337 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 3338 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 3339 2018, . 3341 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 3342 Threat Signaling (DOTS) Requirements", RFC 8612, 3343 DOI 10.17487/RFC8612, May 2019, 3344 . 3346 Authors' Addresses 3348 Mohamed Boucadair (editor) 3349 Orange 3350 Rennes 35000 3351 France 3353 Email: mohamed.boucadair@orange.com 3355 Tirumaleswar Reddy (editor) 3356 McAfee, Inc. 3357 Embassy Golf Link Business Park 3358 Bangalore, Karnataka 560071 3359 India 3361 Email: kondtir@gmail.com 3363 Ehud Doron 3364 Radware Ltd. 3365 Raoul Wallenberg Street 3366 Tel-Aviv 69710 3367 Israel 3369 Email: ehudd@radware.com 3371 Meiling Chen 3372 CMCC 3373 32, Xuanwumen West 3374 BeiJing, BeiJing 100053 3375 China 3377 Email: chenmeiling@chinamobile.com