idnits 2.17.00 (12 Aug 2021) /tmp/idnits25808/draft-ietf-dots-telemetry-19.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 824 has weird spacing: '...-status boo...' == Line 840 has weird spacing: '...-status boo...' == Line 1085 has weird spacing: '...apacity uin...' == Line 1439 has weird spacing: '...er-port ine...' == Line 1802 has weird spacing: '...er-port ine...' == (8 more instances...) -- The document date (4 January 2022) is 136 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 4894, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'Enterprise-Numbers' == Outdated reference: draft-ietf-core-new-block has been published as RFC 9177 == Outdated reference: A later version (-13) exists of draft-ietf-dots-multihoming-09 == Outdated reference: A later version (-03) exists of draft-ietf-dots-robust-blocks-00 Summary: 0 errors (**), 0 flaws (~~), 10 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: 8 July 2022 Akamai 6 E. Doron 7 Radware Ltd. 8 M. Chen 9 CMCC 10 J. Shallow 11 4 January 2022 13 Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry 14 draft-ietf-dots-telemetry-19 16 Abstract 18 This document aims to enrich the DOTS signal channel protocol with 19 various telemetry attributes, allowing for optimal Distributed 20 Denial-of-Service (DDoS) attack mitigation. It specifies the normal 21 traffic baseline and attack traffic telemetry attributes a DOTS 22 client can convey to its DOTS server in the mitigation request, the 23 mitigation status telemetry attributes a DOTS server can communicate 24 to a DOTS client, and the mitigation efficacy telemetry attributes a 25 DOTS client can communicate to a DOTS server. The telemetry 26 attributes can assist the mitigator to choose the DDoS mitigation 27 techniques and perform optimal DDoS attack mitigation. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 8 July 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. DOTS Telemetry: Overview and Purpose . . . . . . . . . . . . 6 65 3.1. Need More Visibility . . . . . . . . . . . . . . . . . . 7 66 3.2. Enhanced Detection . . . . . . . . . . . . . . . . . . . 8 67 3.3. Efficient Mitigation . . . . . . . . . . . . . . . . . . 9 68 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.1. Overview of Telemetry Operations . . . . . . . . . . . . 10 70 4.2. Generic Considerations . . . . . . . . . . . . . . . . . 11 71 4.2.1. DOTS Client Identification . . . . . . . . . . . . . 11 72 4.2.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . 12 73 4.2.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . 12 74 4.2.4. Controlling Configuration Data . . . . . . . . . . . 12 75 4.3. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 12 76 4.4. DOTS Multi-homing Considerations . . . . . . . . . . . . 13 77 4.5. YANG Considerations . . . . . . . . . . . . . . . . . . . 13 78 4.6. A Note About Examples . . . . . . . . . . . . . . . . . . 14 79 5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 15 80 6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 16 81 6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 16 82 6.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 17 83 6.1.2. Conveying DOTS Telemetry Configuration . . . . . . . 19 84 6.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 22 85 6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 23 86 6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 23 87 6.2.1. Conveying DOTS Client Domain Pipe Capacity . . . . . 24 88 6.2.2. Retrieve Installed DOTS Client Domain Pipe 89 Capacity . . . . . . . . . . . . . . . . . . . . . . 30 90 6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 30 91 6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 30 92 6.3.1. Conveying DOTS Client Domain Baseline Information . . 33 93 6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 37 94 6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 37 95 6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 37 96 6.5. Conflict with Other DOTS Clients of the Same Domain . . . 37 97 7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 38 98 7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 41 99 7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 41 100 7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 42 101 7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 44 102 7.1.4. Total Attack Connections . . . . . . . . . . . . . . 46 103 7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 48 104 7.1.6. Vendor Attack Mapping . . . . . . . . . . . . . . . . 51 105 7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 55 106 7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 58 107 8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 63 108 8.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry 109 Attributes . . . . . . . . . . . . . . . . . . . . . . . 63 110 8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry 111 Attributes . . . . . . . . . . . . . . . . . . . . . . . 65 112 9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 69 113 10. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 70 114 10.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . 70 115 10.2. Vendor Attack Mapping Details YANG Module . . . . . . . 99 116 11. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 102 117 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105 118 12.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 105 119 12.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 108 120 12.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 108 121 13. Security Considerations . . . . . . . . . . . . . . . . . . . 109 122 13.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 109 123 13.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 110 124 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 111 125 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 111 126 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 112 127 16.1. Normative References . . . . . . . . . . . . . . . . . . 112 128 16.2. Informative References . . . . . . . . . . . . . . . . . 113 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 115 131 1. Introduction 133 IT organizations and service providers are facing Distributed Denial 134 of Service (DDoS) attacks that fall into two broad categories: 136 1. Network/Transport layer attacks target the victim's 137 infrastructure. These attacks are not necessarily aimed at 138 taking down the actual delivered services, but rather to prevent 139 various network elements (routers, switches, firewalls, transit 140 links, and so on) from serving legitimate users' traffic. 142 The main method of such attacks is to send a large volume or high 143 packet per second (pps) of traffic toward the victim's 144 infrastructure. Typically, attack volumes may vary from a few 145 100 Mbps to 100s of Gbps or even Tbps. Attacks are commonly 146 carried out leveraging botnets and attack reflectors for 147 amplification attacks (Section 3.1 of [RFC4732]) such as NTP 148 (Network Time Protocol), DNS (Domain Name System), SNMP (Simple 149 Network Management Protocol), or SSDP (Simple Service Discovery 150 Protocol). 152 2. Application layer attacks target various applications. Typical 153 examples include attacks against HTTP/HTTPS, DNS, SIP (Session 154 Initiation Protocol), or SMTP (Simple Mail Transfer Protocol). 155 However, all applications with their port numbers open at network 156 edges can be attractive attack targets. 158 Application layer attacks are considered more complex and hard to 159 categorize, and therefore harder to detect and mitigate 160 efficiently. 162 To compound the problem, attackers also leverage multi-vectored 163 attacks. These attacks are assembled from dynamic attack vectors 164 (Network/Application) and tactics. As such, multiple attack vectors 165 formed by multiple attack types and volumes are launched 166 simultaneously towards a victim. Multi-vector attacks are harder to 167 detect and defend against. Multiple and simultaneous mitigation 168 techniques are needed to defeat such attack campaigns. It is also 169 common for attackers to change attack vectors right after a 170 successful mitigation, burdening their opponents with changing their 171 defense methods. 173 The conclusion derived from these real scenarios is that modern 174 attacks detection and mitigation are most certainly complicated and 175 highly convoluted tasks. They demand a comprehensive knowledge of 176 the attack attributes, the normal behavior of the targeted systems 177 (including normal traffic patterns), as well as the attacker's 178 ongoing and past actions. Even more challenging, retrieving all the 179 analytics needed for detecting these attacks is not simple with the 180 industry's current reporting capabilities. 182 The DOTS signal channel protocol [RFC9132] is used to carry 183 information about a network resource or a network (or a part thereof) 184 that is under a DDoS attack. Such information is sent by a DOTS 185 client to one or multiple DOTS servers so that appropriate mitigation 186 actions are undertaken on traffic deemed suspicious. Various use 187 cases are discussed in [RFC8903]. 189 DOTS clients can be integrated within a DDoS attack detector, or 190 network and security elements that have been actively engaged with 191 ongoing attacks. The DOTS client mitigation environment determines 192 that it is no longer possible or practical for it to handle these 193 attacks itself. This can be due to a lack of resources or security 194 capabilities, as derived from the complexities and the intensity of 195 these attacks. In this circumstance, the DOTS client has invaluable 196 knowledge about the actual attacks that need to be handled by its 197 DOTS server(s). By enabling the DOTS client to share this 198 comprehensive knowledge of an ongoing attack under specific 199 circumstances, the DOTS server can drastically increase its ability 200 to accomplish successful mitigation. While the attack is being 201 handled by the mitigation resources associated with the DOTS server, 202 the DOTS server has knowledge about the ongoing attack mitigation. 203 The DOTS server can share this information with the DOTS client so 204 that the client can better assess and evaluate the actual mitigation 205 realized. 207 DOTS clients can send mitigation hints derived from attack details to 208 DOTS servers, with the full understanding that the DOTS server may 209 ignore mitigation hints, as described in [RFC8612] (Gen-004). 210 Mitigation hints will be transmitted across the DOTS signal channel, 211 as the data channel may not be functional during an attack. How a 212 DOTS server is handling normal and attack traffic attributes, and 213 mitigation hints, is implementation specific. 215 Both DOTS clients and servers can benefit from this information by 216 presenting various information in relevant management, reporting, and 217 portal systems. 219 This document defines DOTS telemetry attributes that can be conveyed 220 by DOTS clients to DOTS servers, and vice versa. The DOTS telemetry 221 attributes are not mandatory attributes of the DOTS signal channel 222 protocol [RFC9132]. Nevertheless, when DOTS telemetry attributes are 223 available to a DOTS agent, and absent any limitation by policy, it 224 can signal the attributes in order to optimize the overall mitigation 225 service provisioned using DOTS. The aforementioned policy can be, 226 for example, agreed during a service subscription (that is out of 227 scope) to identify a subset of DOTS clients among those deployed in a 228 DOTS client domain that are allowed to send or receive telemetry 229 data. 231 2. Terminology 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 235 "OPTIONAL" in this document are to be interpreted as described in BCP 236 14 [RFC2119][RFC8174] when, and only when, they appear in all 237 capitals, as shown here. 239 The reader should be familiar with the terms defined in [RFC8612]. 241 "DOTS Telemetry" is defined as the collection of attributes that are 242 used to characterize the normal traffic baseline, attacks and their 243 mitigation measures, and any related information that may help in 244 enforcing countermeasures. DOTS Telemetry is an optional set of 245 attributes that can be signaled in the DOTS signal channel protocol. 247 Telemetry Setup Identifier (tsid) is an identifier that is generated 248 by DOTS clients to uniquely identify DOTS telemetry setup 249 configuration data. 251 Telemetry Identifier (tmid) is an identifier that is generated by 252 DOTS clients to uniquely identify DOTS telemetry data that is 253 communicated prior to or during a mitigation. 255 When two telemetry requests overlap, "overlapped" lower numeric 256 'tsid' (or 'tmid') refers to the lower 'tsid' (or 'tmid') value of 257 these overlapping requests. 259 The meaning of the symbols in YANG tree diagrams are defined in 260 [RFC8340] and [RFC8791]. 262 Consistent with the convention set in Section 2 of [RFC8783], the 263 examples in Section 7.1.6 use "/restconf" as the discovered RESTCONF 264 API root path. Within these examples, some protocol header lines are 265 split into multiple lines for display purposes only. When a line 266 ends with backslash ('\') as the last character, the line is wrapped 267 for display purposes. It is to be considered to be joined to the 268 next line by deleting the backslash, the following line break, and 269 the leading whitespace of the next line. 271 3. DOTS Telemetry: Overview and Purpose 273 Timely and effective signaling of up-to-date DDoS telemetry to all 274 elements involved in the mitigation process is essential and improves 275 the overall DDoS mitigation service effectiveness. Bi-directional 276 feedback between DOTS agents is required for increased awareness by 277 each party of the attack and mitigation efforts, supporting a 278 superior and highly efficient attack mitigation service. 280 3.1. Need More Visibility 282 When signaling a mitigation request, it is most certainly beneficial 283 for DOTS clients to signal to DOTS servers any knowledge regarding 284 ongoing attacks. This can happen in cases where DOTS clients are 285 asking DOTS servers for support in defending against attacks that 286 they have already detected and/or (partially) mitigated. 288 If attacks are already detected and categorized within a DOTS client 289 domain, the DOTS server, and its associated mitigation services, can 290 proactively benefit from this information and optimize the overall 291 service delivery. It is important to note that DOTS client domains' 292 and DOTS server domains' detection and mitigation approaches can be 293 different, and can potentially result in different results and attack 294 classifications. The DDoS mitigation service treats the ongoing 295 attack details received from DOTS clients as hints and cannot 296 completely rely or trust the attack details conveyed by DOTS clients. 298 In addition to the DOTS server directly using telemetry data as 299 operational hints, the DOTS server security operation team also 300 benefits from telemetry data. A basic requirement of security 301 operation teams is to be aware of and get visibility into the attacks 302 they need to handle. This holds especially for the case of ongoing 303 attacks, where DOTS telemetry provides data about the current attack 304 status. Even if some mitigation can be automated, operational teams 305 can use the DOTS telemetry information to be prepared for attack 306 mitigation and to assign the correct resources (operation staff, 307 networking and mitigation) for the specific service. Similarly, 308 security operations personnel at the DOTS client side ask for 309 feedback about their requests for protection. Therefore, it is 310 valuable for DOTS servers to share DOTS telemetry with DOTS clients. 312 Mutual sharing of information is thus crucial for "closing the 313 mitigation loop" between DOTS clients and servers. For the server 314 side team, it is important to confirm that the same attacks that the 315 DOTS server's mitigation resources are seeing are those that a DOTS 316 client is asking for mitigation of. For the DOTS client side team, 317 it is important to realize that the DOTS clients receive the required 318 service. For example, understanding that "I asked for mitigation of 319 two attacks and my DOTS server detects and mitigates only one of 320 them". Cases of inconsistency in attack classification between DOTS 321 clients and servers can be highlighted, and maybe handled, using the 322 DOTS telemetry attributes. 324 In addition, management and orchestration systems, at both DOTS 325 client and server sides, can use DOTS telemetry as a feedback to 326 automate various control and management activities derived from 327 signaled telemetry information. 329 If the DOTS server's mitigation resources have the capabilities to 330 facilitate the DOTS telemetry, the DOTS server adapts its protection 331 strategy and activates the required countermeasures immediately 332 (automation enabled) for the sake of optimized attack mitigation 333 decisions and actions. The interface from the DOTS server to the 334 mitigator to signal the telemetry data is out of scope. 336 3.2. Enhanced Detection 338 DOTS telemetry can also be used as input for determining what values 339 to use for the tuning parameters available on the mitigation 340 resources. During the last few years, DDoS attack detection 341 technologies have evolved from threshold-based detection (that is, 342 cases when all or specific parts of traffic cross a predefined 343 threshold for a certain period of time is considered as an attack) to 344 an "anomaly detection" approach. For the latter, it is required to 345 maintain rigorous learning of "normal" behavior, and an "anomaly" (or 346 an attack) is identified and categorized based on the knowledge about 347 the normal behavior and a deviation from this normal behavior. 348 Machine learning approaches are used such that the actual traffic 349 thresholds are automatically calculated by learning the protected 350 entity's normal traffic behavior during 'idle' time (i.e., no 351 mitigation is active). The normal traffic characterization learned 352 is referred to as the "normal traffic baseline". An attack is 353 detected when the victim's actual traffic is deviating from this 354 normal baseline pattern. 356 In addition, subsequent activities toward mitigating an attack are 357 much more challenging. The ability to distinguish legitimate traffic 358 from attacker traffic on a per packet basis is complex. For example, 359 a packet may look "legitimate" and no attack signature can be 360 identified. The anomaly can be identified only after detailed 361 statistical analysis. DDoS attack mitigators use the normal baseline 362 during the mitigation of an attack to identify and categorize the 363 expected appearance of a specific traffic pattern. Particularly, the 364 mitigators use the normal baseline to recognize the "level of 365 normality" that needs to be achieved during the various mitigation 366 process. 368 Normal baseline calculation is performed based on continuous learning 369 of the normal behavior of the protected entities. The minimum 370 learning period varies from hours to days and even weeks, depending 371 on the protected application behavior. The baseline cannot be 372 learned during active attacks because attack conditions do not 373 characterize the protected entities' normal behavior. 375 If the DOTS client has calculated the normal baseline of its 376 protected entities, signaling such information to the DOTS server 377 along with the attack traffic levels provides value. The DOTS server 378 benefits from this telemetry by tuning its mitigation resources with 379 the DOTS client's normal baseline. The DOTS server mitigators use 380 the baseline to familiarize themselves with the attack victim's 381 normal behavior and target the baseline as the level of normality 382 they need to achieve. Fed with this information, the overall 383 mitigation performances is expected to be improved in terms of time 384 to mitigate, accuracy, and false-negative and false-positive rates. 386 Mitigation of attacks without having certain knowledge of normal 387 traffic can be inaccurate at best. This is especially true for 388 recursive signaling (see Section 3.2.3 of [RFC8811]). Given that 389 DOTS clients can be integrated in a highly diverse set of scenarios 390 and use cases, this emphasizes the need for knowledge of each DOTS 391 client domain behavior, especially given that common global 392 thresholds for attack detection practically cannot be realized. Each 393 DOTS client domain can have its own levels of traffic and normal 394 behavior. Without facilitating normal baseline signaling, it may be 395 very difficult for DOTS servers in some cases to detect and mitigate 396 the attacks accurately: 398 It is important to emphasize that it is practically impossible for 399 the DOTS server's mitigators to calculate the normal baseline in 400 cases where they do not have any knowledge of the traffic 401 beforehand. 403 In addition, baseline learning requires a period of time that 404 cannot be afforded during active attack. 406 Of course, this information can provided using out-of-band mechanisms 407 or manual configuration at the risk of unmaintained information 408 becoming inaccurate as the network evolves and "normal" patterns 409 change. The use of a dynamic and collaborative means between the 410 DOTS client and server to identify and share key parameters for the 411 sake of efficient DDoS protection is valuable. 413 3.3. Efficient Mitigation 415 During a high volume attack, DOTS client pipes can be totally 416 saturated. DOTS clients ask their DOTS servers to handle the attack 417 upstream so that DOTS client pipes return to a reasonable load level 418 (normal pattern, ideally). At this point, it is essential to ensure 419 that the mitigator does not overwhelm the DOTS client pipes by 420 sending back large volumes of "clean traffic", or what it believes is 421 "clean". This can happen when the mitigator has not managed to 422 detect and mitigate all the attacks launched towards the DOTS client 423 domain. 425 In this case, it can be valuable to DOTS clients to signal to DOTS 426 servers the total pipe capacity, which is the level of traffic the 427 DOTS client domain can absorb from its upstream network. Dynamic 428 updates of the condition of pipes between DOTS agents while they are 429 under a DDoS attack is essential (e.g., where multiple DOTS clients 430 share the same physical connectivity pipes). It is important to note 431 that the term "pipe" noted here does not necessary represent physical 432 pipe, but rather represents the maximum level of traffic that the 433 DOTS client domain can receive. The DOTS server should activate 434 other mechanisms to ensure it does not allow the DOTS client domain's 435 pipes to be saturated unintentionally. The rate-limit action defined 436 in [RFC8783] is a reasonable candidate to achieve this objective; the 437 DOTS client can indicate the type(s) of traffic (such as ICMP, UDP, 438 TCP port number 80) it prefers to limit. The rate-limit action can 439 be controlled via the signal channel [RFC9133] even when the pipe is 440 overwhelmed. 442 4. Design Overview 444 4.1. Overview of Telemetry Operations 446 The DOTS protocol suite is divided into two logical channels: the 447 signal channel [RFC9132] and data channel [RFC8783]. This division 448 is due to the vastly different requirements placed upon the traffic 449 they carry. The DOTS signal channel must remain available and usable 450 even in the face of attack traffic that might, e.g., saturate one 451 direction of the links involved, rendering acknowledgment-based 452 mechanisms unreliable and strongly incentivizing messages to be small 453 enough to be contained in a single IP packet (Section 2.2 of 454 [RFC8612]). In contrast, the DOTS data channel is available for 455 high-bandwidth data transfer before or after an attack, using more 456 conventional transport protocol techniques (Section 2.3 of 457 [RFC8612]). It is generally preferable to perform advance 458 configuration over the DOTS data channel, including configuring 459 aliases for static or nearly static data sets such as sets of network 460 addresses/prefixes that might be subject to related attacks. This 461 design helps to optimize the use of the DOTS signal channel for the 462 small messages that truly require reliable delivery during an attack. 464 Telemetry information has aspects that correspond to both operational 465 modes (i.e., signal and data channels): there is certainly a need to 466 convey updated information about ongoing attack traffic and targets 467 during an attack, so as to convey detailed information about 468 mitigation status and inform updates to mitigation strategy in the 469 face of adaptive attacks, but it is also useful to provide mitigation 470 services with a picture of normal or "baseline" traffic towards 471 potential targets, to aid in detecting when incoming traffic deviates 472 from normal into being an attack. Also, one might populate a 473 "database" of classifications of known types of attack so that a 474 short attack identifier can be used during attack time to describe an 475 observed attack. This specification does make provision for use of 476 the DOTS data channel for the latter function (Section 7.1.6), but 477 otherwise retains most telemetry functionality in the DOTS signal 478 channel. 480 Note that it is a functional requirement to convey information about 481 ongoing attack traffic during an attack, and information about 482 baseline traffic uses an essentially identical data structure that is 483 naturally defined to sit next to the description of attack traffic. 484 The related telemetry setup information used to parameterize actual 485 traffic data is also sent over the signal channel, out of expediency. 487 This document specifies an extension to the DOTS signal channel 488 protocol. Considerations about how to establish, maintain, and make 489 use of the DOTS signal channel are specified in [RFC9132]. 491 Once the DOTS signal channel is established, DOTS clients that 492 support the DOTS telemetry extension proceed with the telemetry setup 493 configuration (e.g., measurement interval, telemetry notification 494 interval, pipe capacity, normal traffic baseline) as detailed in 495 Section 6. DOTS agents can then include DOTS telemetry attributes 496 using the DOTS signal channel (Section 7.1). A DOTS client can use 497 separate messages to share with its DOTS server(s) a set of telemetry 498 data bound to an ongoing mitigation (Section 7.2). Also, a DOTS 499 client that is interested in receiving telemetry notifications 500 related to some of its resources follows the procedure defined in 501 Section 7.3. The DOTS client can then decide to send a mitigation 502 request if the notified attack cannot be mitigated locally within the 503 DOTS client domain. 505 Aggregate DOTS telemetry data can also be included in efficacy update 506 (Section 8.1) or mitigation update (Section 8.2) messages. 508 4.2. Generic Considerations 510 4.2.1. DOTS Client Identification 512 Following the rules in Section 4.4.1 of [RFC9132], a unique 513 identifier is generated by a DOTS client to prevent request 514 collisions ('cuid'). 516 As a reminder, [RFC9132] forbids 'cuid' to be returned in a response 517 message body. 519 4.2.2. DOTS Gateways 521 DOTS gateways may be located between DOTS clients and servers. The 522 considerations elaborated in Section 4.4.1 of [RFC9132] must be 523 followed. In particular, 'cdid' attribute is used to unambiguously 524 identify a DOTS client domain. 526 As a reminder, Section 4.4.1.3 of [RFC9132] forbids 'cdid' (if 527 present) to be returned in a response message body. 529 4.2.3. Empty URI Paths 531 Uri-Path parameters and attributes with empty values MUST NOT be 532 present in a request. The presence of such an empty value renders 533 the entire containing message invalid. 535 4.2.4. Controlling Configuration Data 537 The DOTS server follows the same considerations discussed in 538 Section of 4.5.3 of [RFC9132] for managing DOTS telemetry 539 configuration freshness and notification. 541 Likewise, a DOTS client may control the selection of configuration 542 and non-configuration data nodes when sending a GET request by means 543 of the 'c' Uri-Query option and following the procedure specified in 544 Section of 4.4.2 of [RFC9132]. These considerations are not 545 reiterated in the following sections. 547 4.3. Block-wise Transfer 549 DOTS clients can use block wise transfer [RFC7959] with the 550 recommendation detailed in Section 4.4.2 of [RFC9132] to control the 551 size of a response when the data to be returned does not fit within a 552 single datagram. 554 DOTS clients can also use CoAP Block1 Option in a PUT request 555 (Section 2.5 of [RFC7959]) to initiate large transfers, but these 556 Block1 transfers are likely to fail if the inbound "pipe" is running 557 full because the transfer requires a message from the server for each 558 block, which would likely be lost in the incoming flood. 559 Consideration needs to be made to try to fit this PUT into a single 560 transfer or to separate out the PUT into several discrete PUTs where 561 each of them fits into a single packet. 563 Q-Block1 and Q-Block2 Options that are similar to the CoAP Block1 and 564 Block2 Options, but enable robust transmissions of big blocks of data 565 with less packet interchanges using NON messages, are defined in 566 [I-D.ietf-core-new-block]. DOTS implementations can consider the use 567 of Q-Block1 and Q-Block2 Options [I-D.ietf-dots-robust-blocks]. 569 4.4. DOTS Multi-homing Considerations 571 Multi-homed DOTS clients are assumed to follow the recommendations in 572 [I-D.ietf-dots-multihoming] to select which DOTS server to contact 573 and which IP prefixes to include in a telemetry message to a given 574 peer DOTS server. For example, if each upstream network exposes a 575 DOTS server and the DOTS client maintains DOTS channels with all of 576 them, only the information related to prefixes assigned by an 577 upstream network to the DOTS client domain will be signaled via the 578 DOTS channel established with the DOTS server of that upstream 579 network. 581 Considerations related to whether (and how) a DOTS client gleans some 582 telemetry information (e.g., attack details) it receives from a first 583 DOTS server and share it with a second DOTS server are implementation 584 and deployment specific. 586 4.5. YANG Considerations 588 Telemetry messages exchanged between DOTS agents are serialized using 589 Concise Binary Object Representation (CBOR) [RFC8949]. CBOR-encoded 590 payloads are used to carry signal-channel-specific payload messages 591 which convey request parameters and response information such as 592 errors. 594 This document specifies a YANG module [RFC7950] for representing DOTS 595 telemetry message types (Section 10.1). All parameters in the 596 payload of the DOTS signal channel are mapped to CBOR types as 597 specified in Section 11. As a reminder, Section 3 of [RFC9132] 598 defines the rules for mapping YANG-modeled data to CBOR. 600 The DOTS telemetry module (Section 10.1) is not intended to be used 601 via NETCONF/RESTCONF for DOTS server management purposes. It serves 602 only to provide a data model and encoding following [RFC8791]. 603 Server deviations are strongly discouraged, as the peer DOTS agent 604 does not have means to retrieve the list of deviations and thus 605 interoperability issues are likely to be encountered. 607 The DOTS telemetry module (Section 10.1) uses "enumerations" rather 608 than "identities" to define units, samples, and intervals because 609 otherwise the namespace identifier "ietf-dots-telemetry" must be 610 included when a telemetry attribute is included (e.g., in a 611 mitigation efficacy update). The use of "identities" is thus 612 suboptimal from a message compactness standpoint; one of the key 613 requirements for DOTS Signal Channel messages. 615 The DOTS telemetry module (Section 10.1) includes some lists for 616 which no key statement is included. This behavior is compliant with 617 [RFC8791]. The reason for not including these keys is because they 618 are not included in the request message body but as mandatory Uri- 619 Paths in requests (Sections 6 and 7). Otherwise, whenever a key 620 statement is used in the module, the same definition as in 621 Section 7.8.2 of [RFC7950] is assumed. 623 The full tree diagram of the DOTS telemetry module can be generated 624 using the "pyang" tool [PYANG]. That tree is not included here 625 because it is too long (Section 3.3 of [RFC8340]). Instead, subtrees 626 are provided for the reader's convenience. 628 In order to optimize the data exchanged over the DOTS signal channel, 629 the document specifies a second YANG module ("ietf-dots-mapping", 630 Section 10.2) that augments the DOTS data channel [RFC8783]. This 631 augmentation can be used during 'idle' time to share the attack 632 mapping details (Section 7.1.5). DOTS clients can use tools, e.g., 633 YANG Library [RFC8525], to retrieve the list of features and 634 deviations supported by the DOTS server over the data channel. 636 4.6. A Note About Examples 638 Examples are provided for illustration purposes. The document does 639 not aim to provide a comprehensive list of message examples. 641 The authoritative reference for validating telemetry messages 642 exchanged over the DOTS signal channel are Sections 6, 7, and 8 643 together with the mapping table established in Section 11. The 644 structure of telemetry message bodies is represented as a YANG data 645 structure (Section 10.1). 647 JSON encoding of YANG-modeled data is used to illustrate the various 648 telemetry operations. 650 The examples use the Enterprise Number 32473 defined for 651 documentation use [RFC5612]. 653 5. Telemetry Operation Paths 655 As discussed in Section 4.2 of [RFC9132], each DOTS operation is 656 indicated by a path suffix that indicates the intended operation. 657 The operation path is appended to the path prefix to form the URI 658 used with a CoAP request to perform the desired DOTS operation. The 659 following telemetry path suffixes are defined (Table 1): 661 +-----------------+----------------+-----------+ 662 | Operation | Operation Path | Details | 663 +=================+================+===========+ 664 | Telemetry Setup | /tm-setup | Section 6 | 665 | Telemetry | /tm | Section 7 | 666 +-----------------+----------------+-----------+ 668 Table 1: DOTS Telemetry Operations 670 Consequently, the "ietf-dots-telemetry" YANG module defined in 671 Section 10.1 defines data structure to represent new DOTS message 672 types called 'telemetry-setup' and 'telemetry'. The tree structure 673 is shown in Figure 1. More details are provided in Sections 6 and 7 674 about the exact structure of 'telemetry-setup' and 'telemetry' 675 message types. 677 structure dots-telemetry: 678 +-- (telemetry-message-type)? 679 +--:(telemetry-setup) 680 | ... 681 | +-- telemetry* [] 682 | ... 683 | +-- (setup-type)? 684 | +--:(telemetry-config) 685 | | ... 686 | +--:(pipe) 687 | | ... 688 | +--:(baseline) 689 | ... 690 +--:(telemetry) 691 ... 693 Figure 1: New DOTS Message Types (YANG Tree Structure) 695 DOTS implementations MUST support the Observe Option [RFC7641] for 696 'tm' (Section 7). 698 6. DOTS Telemetry Setup Configuration 700 In reference to Figure 1, a DOTS telemetry setup message MUST include 701 only telemetry-related configuration parameters (Section 6.1) or 702 information about DOTS client domain pipe capacity (Section 6.2) or 703 telemetry traffic baseline (Section 6.3). As such, requests that 704 include a mix of telemetry configuration, pipe capacity, and traffic 705 baseline MUST be rejected by DOTS servers with a 4.00 (Bad Request). 707 A DOTS client can reset all installed DOTS telemetry setup 708 configuration data following the considerations detailed in 709 Section 6.4. 711 A DOTS server may detect conflicts when processing requests related 712 to DOTS client domain pipe capacity or telemetry traffic baseline 713 with requests from other DOTS clients of the same DOTS client domain. 714 More details are included in Section 6.5. 716 Telemetry setup configuration is bound to a DOTS client domain. DOTS 717 servers MUST NOT expect DOTS clients to send regular requests to 718 refresh the telemetry setup configuration. Any available telemetry 719 setup configuration is valid till the DOTS server ceases to service a 720 DOTS client domain. DOTS servers MUST NOT reset 'tsid' because a 721 session failed with a DOTS client. DOTS clients update their 722 telemetry setup configuration upon change of a parameter that may 723 impact attack mitigation. 725 DOTS telemetry setup configuration request and response messages are 726 marked as Confirmable messages (Section 2.1 of [RFC7252]). 728 6.1. Telemetry Configuration 730 DOTS telemetry uses several percentile values to provide a picture of 731 a traffic distribution overall, as opposed to just a single snapshot 732 of observed traffic at a single point in time. Modeling raw traffic 733 flow data as a distribution and describing that distribution entails 734 choosing a measurement period that the distribution will describe, 735 and a number of sampling intervals, or "buckets", within that 736 measurement period. Traffic within each bucket is treated as a 737 single event (i.e., averaged), and then the distribution of buckets 738 is used to describe the distribution of traffic over the measurement 739 period. A distribution can be characterized by statistical measures 740 (e.g., mean, median, and standard deviation), and also by reporting 741 the value of the distribution at various percentile levels of the 742 data set in question (e.g., "quartiles" that correspond to 25th, 743 50th, and 75th percentile). More details about percentile values and 744 their computation are found in Section 11.3 of [RFC2330]. 746 DOTS telemetry uses up to three percentile values, plus the overall 747 peak, to characterize traffic distributions. Which percentile 748 thresholds are used for these "low", "medium", and "high" percentile 749 values is configurable (with suitable defaults). 751 A DOTS client can negotiate with its server(s) a set of telemetry 752 configuration parameters to be used for telemetry. Such parameters 753 include: 755 * Percentile-related measurement parameters. In particular, 756 'measurement-interval' defines the period on which percentiles are 757 computed, while 'measurement-sample' defines the time distribution 758 for measuring values that are used to compute percentiles. 760 * Measurement units 762 * Acceptable percentile values 764 * Telemetry notification interval 766 * Acceptable Server-originated telemetry 768 6.1.1. Retrieve Current DOTS Telemetry Configuration 770 A GET request is used to obtain acceptable and current telemetry 771 configuration parameters on the DOTS server. This request may 772 include a 'cdid' Uri-Path when the request is relayed by a DOTS 773 gateway. An example of such a GET request (without gateway) is 774 depicted in Figure 2. 776 Header: GET (Code=0.01) 777 Uri-Path: ".well-known" 778 Uri-Path: "dots" 779 Uri-Path: "tm-setup" 780 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 782 Figure 2: GET to Retrieve Current and Acceptable DOTS Telemetry 783 Configuration 785 Upon receipt of such a request, and assuming no error is encountered 786 when processing the request, the DOTS server replies with a 2.05 787 (Content) response that conveys the telemetry parameters that are 788 acceptable by the DOTS server, any pipe information (Section 6.2), 789 and the current baseline information (Section 6.3) maintained by the 790 DOTS server for this DOTS client. The tree structure of the response 791 message body is provided in Figure 3. 793 DOTS servers that support the capability of sending telemetry 794 information to DOTS clients prior to or during a mitigation 795 (Section 8.2) sets 'server-originated-telemetry' under 'max-config- 796 values' to 'true' ('false' is used otherwise). If 'server- 797 originated-telemetry' is not present in a response, this is 798 equivalent to receiving a response with 'server-originated-telemetry' 799 set to 'false'. 801 structure dots-telemetry: 802 +-- (telemetry-message-type)? 803 +--:(telemetry-setup) 804 | +-- (direction)? 805 | | +--:(server-to-client-only) 806 | | +-- max-config-values 807 | | | +-- measurement-interval? interval 808 | | | +-- measurement-sample? sample 809 | | | +-- low-percentile? percentile 810 | | | +-- mid-percentile? percentile 811 | | | +-- high-percentile? percentile 812 | | | +-- server-originated-telemetry? boolean 813 | | | +-- telemetry-notify-interval? uint16 814 | | +-- min-config-values 815 | | | +-- measurement-interval? interval 816 | | | +-- measurement-sample? sample 817 | | | +-- low-percentile? percentile 818 | | | +-- mid-percentile? percentile 819 | | | +-- high-percentile? percentile 820 | | | +-- telemetry-notify-interval? uint16 821 | | +-- supported-unit-classes 822 | | | +-- unit-config* [unit] 823 | | | +-- unit unit-class 824 | | | +-- unit-status boolean 825 | | +-- supported-query-type* query-type 826 | +-- telemetry* [] 827 | +-- (direction)? 828 | | +--:(server-to-client-only) 829 | | +-- tsid? uint32 830 | +-- (setup-type)? 831 | +--:(telemetry-config) 832 | | +-- current-config 833 | | +-- measurement-interval? interval 834 | | +-- measurement-sample? sample 835 | | +-- low-percentile? percentile 836 | | +-- mid-percentile? percentile 837 | | +-- high-percentile? percentile 838 | | +-- unit-config* [unit] 839 | | | +-- unit unit-class 840 | | | +-- unit-status boolean 841 | | +-- server-originated-telemetry? boolean 842 | | +-- telemetry-notify-interval? uint16 843 | +--:(pipe) 844 | | ... 845 | +--:(baseline) 846 | ... 847 +--:(telemetry) 848 ... 850 Figure 3: Telemetry Configuration Tree Structure 852 When both 'min-config-values' and 'max-config-values' attributes are 853 present, the values carried in 'max-config-values' attributes MUST be 854 greater or equal to their counterpart in 'min-config-values' 855 attributes. 857 6.1.2. Conveying DOTS Telemetry Configuration 859 A PUT request is used to convey the configuration parameters for the 860 telemetry data (e.g., low, mid, or high percentile values). For 861 example, a DOTS client may contact its DOTS server to change the 862 default percentile values used as baseline for telemetry data. 863 Figure 3 lists the attributes that can be set by a DOTS client in 864 such a PUT request. An example of a DOTS client that modifies all 865 percentile reference values is shown in Figure 4. 867 Header: PUT (Code=0.03) 868 Uri-Path: ".well-known" 869 Uri-Path: "dots" 870 Uri-Path: "tm-setup" 871 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 872 Uri-Path: "tsid=123" 873 Content-Format: "application/dots+cbor" 875 { 876 "ietf-dots-telemetry:telemetry-setup": { 877 "telemetry": [ 878 { 879 "current-config": { 880 "low-percentile": "5.00", 881 "mid-percentile": "65.00", 882 "high-percentile": "95.00" 883 } 884 } 885 ] 886 } 887 } 888 Figure 4: PUT to Convey the DOTS Telemetry Configuration 890 'cuid' is a mandatory Uri-Path parameter for PUT requests. 892 The following additional Uri-Path parameter is defined: 894 tsid: Telemetry Setup Identifier is an identifier for the DOTS 895 telemetry setup configuration data represented as an integer. 896 This identifier MUST be generated by DOTS clients. 'tsid' 897 values MUST increase monotonically (when a new PUT is generated 898 by a DOTS client to convey new configuration parameters for the 899 telemetry). 901 The procedure specified in Section 4.4.1 of [RFC9132] for 'mid' 902 rollover MUST also be followed for 'tsid' rollover. 904 This is a mandatory attribute. 'tsid' MUST follow 'cuid'. 906 'cuid' and 'tsid' MUST NOT appear in the PUT request message body. 908 At least one configurable attribute MUST be present in the PUT 909 request. 911 A PUT request with a higher numeric 'tsid' value overrides the DOTS 912 telemetry configuration data installed by a PUT request with a lower 913 numeric 'tsid' value. To avoid maintaining a long list of 'tsid' 914 requests for requests carrying telemetry configuration data from a 915 DOTS client, the lower numeric 'tsid' MUST be automatically deleted 916 and no longer be available at the DOTS server. 918 The DOTS server indicates the result of processing the PUT request 919 using the following Response Codes: 921 * If the request is missing a mandatory attribute, does not include 922 'cuid' or 'tsid' Uri-Path parameters, or contains one or more 923 invalid or unknown parameters, 4.00 (Bad Request) MUST be returned 924 in the response. 926 * If the DOTS server does not find the 'tsid' parameter value 927 conveyed in the PUT request in its configuration data and if the 928 DOTS server has accepted the configuration parameters, then a 2.01 929 (Created) Response Code MUST be returned in the response. 931 * If the DOTS server finds the 'tsid' parameter value conveyed in 932 the PUT request in its configuration data and if the DOTS server 933 has accepted the updated configuration parameters, 2.04 (Changed) 934 MUST be returned in the response. 936 * If any of the enclosed configurable attribute values are not 937 acceptable to the DOTS server (Section 6.1.1), 4.22 (Unprocessable 938 Entity) MUST be returned in the response. 940 The DOTS client may retry and send the PUT request with updated 941 attribute values acceptable to the DOTS server. 943 By default, low percentile (10th percentile), mid percentile (50th 944 percentile), high percentile (90th percentile), and peak (100th 945 percentile) values are used to represent telemetry data. 946 Nevertheless, a DOTS client can disable some percentile types (low, 947 mid, high). In particular, setting 'low-percentile' to '0.00' 948 indicates that the DOTS client is not interested in receiving low- 949 percentiles. Likewise, setting 'mid-percentile' (or 'high- 950 percentile') to the same value as 'low-percentile' (or 'mid- 951 percentile') indicates that the DOTS client is not interested in 952 receiving mid-percentiles (or high-percentiles). For example, a DOTS 953 client can send the request depicted in Figure 5 to inform the server 954 that it is interested in receiving only high-percentiles. This 955 assumes that the client will only use that percentile type when 956 sharing telemetry data with the server. 958 Header: PUT (Code=0.03) 959 Uri-Path: ".well-known" 960 Uri-Path: "dots" 961 Uri-Path: "tm-setup" 962 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 963 Uri-Path: "tsid=124" 964 Content-Format: "application/dots+cbor" 966 { 967 "ietf-dots-telemetry:telemetry-setup": { 968 "telemetry": [ 969 { 970 "current-config": { 971 "low-percentile": "0.00", 972 "mid-percentile": "0.00", 973 "high-percentile": "95.00" 974 } 975 } 976 ] 977 } 978 } 980 Figure 5: PUT to Disable Low- and Mid-Percentiles 982 DOTS clients can also configure the unit class(es) to be used for 983 traffic-related telemetry data among the following supported unit 984 classes: packets per second, bits per second, and bytes per second. 985 Supplying both bits per second and bytes per second unit-classes is 986 allowed for a given telemetry data. However, receipt of conflicting 987 values is treated as invalid parameters and rejected with 4.00 (Bad 988 Request). 990 DOTS clients that are interested to receive pre or ongoing mitigation 991 telemetry (pre-or-ongoing-mitigation) information from a DOTS server 992 (Section 8.2) MUST set 'server-originated-telemetry' to 'true'. If 993 'server-originated-telemetry' is not present in a PUT request, this 994 is equivalent to receiving a request with 'server-originated- 995 telemetry' set to 'false'. An example of a request to enable pre-or- 996 ongoing-mitigation telemetry from DOTS servers is shown in Figure 6. 998 Header: PUT (Code=0.03) 999 Uri-Path: ".well-known" 1000 Uri-Path: "dots" 1001 Uri-Path: "tm-setup" 1002 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1003 Uri-Path: "tsid=125" 1004 Content-Format: "application/dots+cbor" 1006 { 1007 "ietf-dots-telemetry:telemetry-setup": { 1008 "telemetry": [ 1009 { 1010 "current-config": { 1011 "server-originated-telemetry": true 1012 } 1013 } 1014 ] 1015 } 1016 } 1018 Figure 6: PUT to Enable Pre-or-ongoing-mitigation Telemetry from 1019 the DOTS server 1021 6.1.3. Retrieve Installed DOTS Telemetry Configuration 1023 A DOTS client may issue a GET message with 'tsid' Uri-Path parameter 1024 to retrieve the current DOTS telemetry configuration. An example of 1025 such a request is depicted in Figure 7. 1027 Header: GET (Code=0.01) 1028 Uri-Path: ".well-known" 1029 Uri-Path: "dots" 1030 Uri-Path: "tm-setup" 1031 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1032 Uri-Path: "tsid=123" 1034 Figure 7: GET to Retrieve Current DOTS Telemetry Configuration 1036 If the DOTS server does not find the 'tsid' Uri-Path value conveyed 1037 in the GET request in its configuration data for the requesting DOTS 1038 client, it MUST respond with a 4.04 (Not Found) error Response Code. 1040 6.1.4. Delete DOTS Telemetry Configuration 1042 A DELETE request is used to delete the installed DOTS telemetry 1043 configuration data (Figure 8). 'cuid' and 'tsid' are mandatory Uri- 1044 Path parameters for such DELETE requests. 1046 Header: DELETE (Code=0.04) 1047 Uri-Path: ".well-known" 1048 Uri-Path: "dots" 1049 Uri-Path: "tm-setup" 1050 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1051 Uri-Path: "tsid=123" 1053 Figure 8: Delete Telemetry Configuration 1055 The DOTS server resets the DOTS telemetry configuration back to the 1056 default values and acknowledges a DOTS client's request to remove the 1057 DOTS telemetry configuration using 2.02 (Deleted) Response Code. A 1058 2.02 (Deleted) Response Code is returned even if the 'tsid' parameter 1059 value conveyed in the DELETE request does not exist in its 1060 configuration data before the request. 1062 Section 6.4 discusses the procedure to reset all DOTS telemetry setup 1063 configuration. 1065 6.2. Total Pipe Capacity 1067 A DOTS client can communicate to the DOTS server(s) its DOTS client 1068 domain pipe information. The tree structure of the pipe information 1069 is shown in Figure 9. 1071 structure dots-telemetry: 1072 +-- (telemetry-message-type)? 1073 +--:(telemetry-setup) 1074 | ... 1075 | +-- telemetry* [] 1076 | +-- (direction)? 1077 | | +--:(server-to-client-only) 1078 | | +-- tsid? uint32 1079 | +-- (setup-type)? 1080 | +--:(telemetry-config) 1081 | | ... 1082 | +--:(pipe) 1083 | | +-- total-pipe-capacity* [link-id unit] 1084 | | +-- link-id nt:link-id 1085 | | +-- capacity uint64 1086 | | +-- unit unit 1087 | +--:(baseline) 1088 | ... 1089 +--:(telemetry) 1090 ... 1092 Figure 9: Pipe Tree Structure 1094 A DOTS client domain pipe is defined as a list of limits of 1095 (incoming) traffic volume ('total-pipe-capacity') that can be 1096 forwarded over ingress interconnection links of a DOTS client domain. 1097 Each of these links is identified with a 'link-id' [RFC8345]. 1099 The unit used by a DOTS client when conveying pipe information is 1100 captured in the 'unit' attribute. The DOTS client MUST auto-scale so 1101 that the appropriate unit is used. That is, for a given unit class, 1102 the DOTS client uses the largest unit that gives a value greater than 1103 one. As such, only one unit per unit class is allowed. 1105 6.2.1. Conveying DOTS Client Domain Pipe Capacity 1107 Similar considerations to those specified in Section 6.1.2 are 1108 followed with one exception: 1110 The relative order of two PUT requests carrying DOTS client domain 1111 pipe attributes from a DOTS client is determined by comparing 1112 their respective 'tsid' values. If such two requests have 1113 overlapping 'link-id' and 'unit', the PUT request with higher 1114 numeric 'tsid' value will override the request with a lower 1115 numeric 'tsid' value. The overlapped lower numeric 'tsid' MUST be 1116 automatically deleted and no longer be available. 1118 DOTS clients SHOULD minimize the number of active 'tsid's used for 1119 pipe information. In order to avoid maintaining a long list of 1120 'tsid's for pipe information, it is RECOMMENDED that DOTS clients 1121 include in any request to update information related to a given link 1122 the information of other links (already communicated using a lower 1123 'tsid' value). Doing so, this update request will override these 1124 existing requests and hence optimize the number of 'tsid' request per 1125 DOTS client. 1127 * Note: This assumes that all link information can fit in one single 1128 message. 1130 As an example of configuring pipe information, a DOTS client managing 1131 a single homed domain (Figure 10) can send a PUT request (shown in 1132 Figure 11) to communicate the capacity of "link1" used to connect to 1133 its ISP. 1135 ,--,--,--. ,--,--,--. 1136 ,-' `-. ,-' `-. 1137 ( DOTS Client )=====( ISP#A ) 1138 `-. Domain ,-' link1 `-. ,-' 1139 `--'--'--' `--'--'--' 1141 Figure 10: Single Homed DOTS Client Domain 1143 Header: PUT (Code=0.03) 1144 Uri-Path: ".well-known" 1145 Uri-Path: "dots" 1146 Uri-Path: "tm-setup" 1147 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1148 Uri-Path: "tsid=126" 1149 Content-Format: "application/dots+cbor" 1151 { 1152 "ietf-dots-telemetry:telemetry-setup": { 1153 "telemetry": [ 1154 { 1155 "total-pipe-capacity": [ 1156 { 1157 "link-id": "link1", 1158 "capacity": "500", 1159 "unit": "megabit-ps" 1160 } 1161 ] 1162 } 1163 ] 1164 } 1165 } 1166 Figure 11: Example of a PUT Request to Convey Pipe Information 1167 (Single Homed) 1169 DOTS clients may be instructed to signal a link aggregate instead of 1170 individual links. For example, a DOTS client that manages a DOTS 1171 client domain having two interconnection links with an upstream ISP 1172 (Figure 12) can send a PUT request (shown in Figure 13) to 1173 communicate the aggregate link capacity with its ISP. Signaling 1174 individual or aggregate link capacity is deployment specific. 1176 ,--,--,--. ,--,--,--. 1177 ,-' `-.===== ,-' `-. 1178 ( DOTS Client ) ( ISP#C ) 1179 `-. Domain ,-'====== `-. ,-' 1180 `--'--'--' `--'--'--' 1182 Figure 12: DOTS Client Domain with Two Interconnection Links 1184 Header: PUT (Code=0.03) 1185 Uri-Path: ".well-known" 1186 Uri-Path: "dots" 1187 Uri-Path: "tm-setup" 1188 Uri-Path: "cuid=hmcpH87lmPGsSTjkhXCbin" 1189 Uri-Path: "tsid=896" 1190 Content-Format: "application/dots+cbor" 1192 { 1193 "ietf-dots-telemetry:telemetry-setup": { 1194 "telemetry": [ 1195 { 1196 "total-pipe-capacity": [ 1197 { 1198 "link-id": "aggregate", 1199 "capacity": "700", 1200 "unit": "megabit-ps" 1201 } 1202 ] 1203 } 1204 ] 1205 } 1206 } 1208 Figure 13: Example of a PUT Request to Convey Pipe Information 1209 (Aggregated Link) 1211 Now consider that the DOTS client domain was upgraded to connect to 1212 an additional ISP (e.g., ISP#B of Figure 14); the DOTS client can 1213 inform a third-party DOTS server (that is, not hosted with ISP#A and 1214 ISP#B domains) about this update by sending the PUT request depicted 1215 in Figure 15. This request also includes information related to 1216 "link1" even if that link is not upgraded. Upon receipt of this 1217 request, the DOTS server removes the request with 'tsid=126' and 1218 updates its configuration base to maintain two links (link#1 and 1219 link#2). 1221 ,--,--,--. 1222 ,-' `-. 1223 ( ISP#B ) 1224 `-. ,-' 1225 `--'--'--' 1226 || 1227 || link2 1228 ,--,--,--. ,--,--,--. 1229 ,-' `-. ,-' `-. 1230 ( DOTS Client )=====( ISP#A ) 1231 `-. Domain ,-' link1 `-. ,-' 1232 `--'--'--' `--'--'--' 1234 Figure 14: Multi-Homed DOTS Client Domain 1236 Header: PUT (Code=0.03) 1237 Uri-Path: ".well-known" 1238 Uri-Path: "dots" 1239 Uri-Path: "tm-setup" 1240 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1241 Uri-Path: "tsid=127" 1242 Content-Format: "application/dots+cbor" 1244 { 1245 "ietf-dots-telemetry:telemetry-setup": { 1246 "telemetry": [ 1247 { 1248 "total-pipe-capacity": [ 1249 { 1250 "link-id": "link1", 1251 "capacity": "500", 1252 "unit": "megabit-ps" 1253 }, 1254 { 1255 "link-id": "link2", 1256 "capacity": "500", 1257 "unit": "megabit-ps" 1258 } 1259 ] 1260 } 1261 ] 1262 } 1263 } 1265 Figure 15: Example of a PUT Request to Convey Pipe Information 1266 (Multi-Homed) 1268 A DOTS client can delete a link by sending a PUT request with the 1269 'capacity' attribute set to "0" if other links are still active for 1270 the same DOTS client domain (see Section 6.2.3 for other delete 1271 cases). For example, if a DOTS client domain re-homes (that is, it 1272 changes its ISP), the DOTS client can inform its DOTS server about 1273 this update (e.g., from the network configuration in Figure 10 to the 1274 one shown in Figure 16) by sending the PUT request depicted in 1275 Figure 17. Upon receipt of this request, and assuming no error is 1276 encountered when processing the request, the DOTS server removes 1277 "link1" from its configuration bases for this DOTS client domain. 1278 Note that if the DOTS server receives a PUT request with a 'capacity' 1279 attribute set to "0" for all included links, it MUST reject the 1280 request with a 4.00 (Bad Request). 1282 ,--,--,--. 1283 ,-' `-. 1284 ( ISP#B ) 1285 `-. ,-' 1286 `--'--'--' 1287 || 1288 || link2 1289 ,--,--,--. 1290 ,-' `-. 1291 ( DOTS Client ) 1292 `-. Domain ,-' 1293 `--'--'--' 1295 Figure 16: Multi-Homed DOTS Client Domain 1297 Header: PUT (Code=0.03) 1298 Uri-Path: ".well-known" 1299 Uri-Path: "dots" 1300 Uri-Path: "tm-setup" 1301 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1302 Uri-Path: "tsid=128" 1303 Content-Format: "application/dots+cbor" 1305 { 1306 "ietf-dots-telemetry:telemetry-setup": { 1307 "telemetry": [ 1308 { 1309 "total-pipe-capacity": [ 1310 { 1311 "link-id": "link1", 1312 "capacity": "0", 1313 "unit": "megabit-ps" 1314 }, 1315 { 1316 "link-id": "link2", 1317 "capacity": "500", 1318 "unit": "megabit-ps" 1319 } 1320 ] 1321 } 1322 ] 1323 } 1324 } 1326 Figure 17: Example of a PUT Request to Convey Pipe Information 1327 (Multi-Homed) 1329 6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity 1331 A GET request with 'tsid' Uri-Path parameter is used to retrieve a 1332 specific installed DOTS client domain pipe related information. The 1333 same procedure as defined in Section 6.1.3 is followed. 1335 To retrieve all pipe information bound to a DOTS client, the DOTS 1336 client proceeds as specified in Section 6.1.1. 1338 6.2.3. Delete Installed DOTS Client Domain Pipe Capacity 1340 A DELETE request is used to delete the installed DOTS client domain 1341 pipe related information. The same procedure as defined in 1342 Section 6.1.4 is followed. 1344 6.3. Telemetry Baseline 1346 A DOTS client can communicate to its DOTS server(s) its normal 1347 traffic baseline and connections capacity: 1349 Total traffic normal baseline: The percentile values representing 1350 the total traffic normal baseline. It can be represented for a 1351 target using 'total-traffic-normal'. 1353 The traffic normal per-protocol ('total-traffic-normal-per- 1354 protocol') baseline is represented for a target and is transport- 1355 protocol specific. 1357 The traffic normal per-port-number ('total-traffic-normal-per- 1358 port') baseline is represented for each port number bound to a 1359 target. 1361 If the DOTS client negotiated percentile values and units 1362 (Section 6.1), these negotiated parameters will be used instead of 1363 the default ones. For each used unit class, the DOTS client MUST 1364 auto-scale so that the appropriate unit is used. 1366 Total connections capacity: If the target is susceptible to 1367 resource-consuming DDoS attacks, the following optional attributes 1368 for the target per transport protocol are useful to detect 1369 resource-consuming DDoS attacks: 1371 * The maximum number of simultaneous connections that are allowed 1372 to the target. 1374 * The maximum number of simultaneous connections that are allowed 1375 to the target per client. 1377 * The maximum number of simultaneous embryonic connections that 1378 are allowed to the target. The term "embryonic connection" 1379 refers to a connection whose connection handshake is not 1380 finished. Embryonic connection is only possible in connection- 1381 oriented transport protocols like TCP or Stream Control 1382 Transmission Protocol (SCTP) [RFC4960]. 1384 * The maximum number of simultaneous embryonic connections that 1385 are allowed to the target per client. 1387 * The maximum number of connections allowed per second to the 1388 target. 1390 * The maximum number of connections allowed per second to the 1391 target per client. 1393 * The maximum number of requests (e.g., HTTP/DNS/SIP requests) 1394 allowed per second to the target. 1396 * The maximum number of requests allowed per second to the target 1397 per client. 1399 * The maximum number of outstanding partial requests allowed to 1400 the target. Attacks relying upon partial requests create a 1401 connection with a target but do not send a complete request 1402 (e.g., HTTP request). 1404 * The maximum number of outstanding partial requests allowed to 1405 the target per client. 1407 The aggregate per transport protocol is captured in 'total- 1408 connection-capacity', while port-specific capabilities are 1409 represented using 'total-connection-capacity-per-port'. 1411 Note that a target resource is identified using the attributes 1412 'target-prefix', 'target-port-range', 'target-protocol', 'target- 1413 fqdn', 'target-uri', or 'alias-name' defined in Section 4.4.1.1 of 1414 [RFC9132]. 1416 The tree structure of the normal traffic baseline is shown in 1417 Figure 18. 1419 structure dots-telemetry: 1420 +-- (telemetry-message-type)? 1421 +--:(telemetry-setup) 1422 | ... 1423 | +-- telemetry* [] 1424 | +-- (direction)? 1425 | | +--:(server-to-client-only) 1426 | | +-- tsid? uint32 1427 | +-- (setup-type)? 1428 | +--:(telemetry-config) 1429 | | ... 1430 | +--:(pipe) 1431 | | ... 1432 | +--:(baseline) 1433 | +-- baseline* [id] 1434 | +-- id 1435 | | uint32 1436 | +-- target-prefix* 1437 | | inet:ip-prefix 1438 | +-- target-port-range* [lower-port] 1439 | | +-- lower-port inet:port-number 1440 | | +-- upper-port? inet:port-number 1441 | +-- target-protocol* uint8 1442 | +-- target-fqdn* 1443 | | inet:domain-name 1444 | +-- target-uri* 1445 | | inet:uri 1446 | +-- alias-name* 1447 | | string 1448 | +-- total-traffic-normal* [unit] 1449 | | +-- unit unit 1450 | | +-- low-percentile-g? yang:gauge64 1451 | | +-- mid-percentile-g? yang:gauge64 1452 | | +-- high-percentile-g? yang:gauge64 1453 | | +-- peak-g? yang:gauge64 1454 | +-- total-traffic-normal-per-protocol* 1455 | | [unit protocol] 1456 | | +-- protocol uint8 1457 | | +-- unit unit 1458 | | +-- low-percentile-g? yang:gauge64 1459 | | +-- mid-percentile-g? yang:gauge64 1460 | | +-- high-percentile-g? yang:gauge64 1461 | | +-- peak-g? yang:gauge64 1462 | +-- total-traffic-normal-per-port* [unit port] 1463 | | +-- port inet:port-number 1464 | | +-- unit unit 1465 | | +-- low-percentile-g? yang:gauge64 1466 | | +-- mid-percentile-g? yang:gauge64 1467 | | +-- high-percentile-g? yang:gauge64 1468 | | +-- peak-g? yang:gauge64 1469 | +-- total-connection-capacity* [protocol] 1470 | | +-- protocol uint8 1471 | | +-- connection? uint64 1472 | | +-- connection-client? uint64 1473 | | +-- embryonic? uint64 1474 | | +-- embryonic-client? uint64 1475 | | +-- connection-ps? uint64 1476 | | +-- connection-client-ps? uint64 1477 | | +-- request-ps? uint64 1478 | | +-- request-client-ps? uint64 1479 | | +-- partial-request-max? uint64 1480 | | +-- partial-request-client-max? uint64 1481 | +-- total-connection-capacity-per-port* 1482 | [protocol port] 1483 | +-- port 1484 | | inet:port-number 1485 | +-- protocol uint8 1486 | +-- connection? uint64 1487 | +-- connection-client? uint64 1488 | +-- embryonic? uint64 1489 | +-- embryonic-client? uint64 1490 | +-- connection-ps? uint64 1491 | +-- connection-client-ps? uint64 1492 | +-- request-ps? uint64 1493 | +-- request-client-ps? uint64 1494 | +-- partial-request-max? uint64 1495 | +-- partial-request-client-max? uint64 1496 +--:(telemetry) 1497 ... 1499 Figure 18: Telemetry Baseline Tree Structure 1501 A DOTS client can share one or multiple normal traffic baselines 1502 (e.g., aggregate or per-prefix baselines), each are uniquely 1503 identified within the DOTS client domain with an identifier 'id'. 1504 This identifier can be used to update a baseline entry, delete a 1505 specific entry, etc. 1507 6.3.1. Conveying DOTS Client Domain Baseline Information 1509 Similar considerations to those specified in Section 6.1.2 are 1510 followed with one exception: 1512 The relative order of two PUT requests carrying DOTS client domain 1513 baseline attributes from a DOTS client is determined by comparing 1514 their respective 'tsid' values. If such two requests have 1515 overlapping targets, the PUT request with higher numeric 'tsid' 1516 value will override the request with a lower numeric 'tsid' value. 1517 The overlapped lower numeric 'tsid' MUST be automatically deleted 1518 and no longer be available. 1520 Two PUT requests from a DOTS client have overlapping targets if there 1521 is a common IP address, IP prefix, FQDN, URI, or alias-name. Also, 1522 two PUT requests from a DOTS client have overlapping targets from the 1523 perspective of the DOTS server if the addresses associated with the 1524 FQDN, URI, or alias are overlapping with each other or with 'target- 1525 prefix'. 1527 DOTS clients SHOULD minimize the number of active 'tsid's used for 1528 baseline information. In order to avoid maintaining a long list of 1529 'tsid's for baseline information, it is RECOMMENDED that DOTS clients 1530 include in a request to update information related to a given target, 1531 the information of other targets (already communicated using a lower 1532 'tsid' value) (assuming this fits within one single datagram). This 1533 update request will override these existing requests and hence 1534 optimize the number of 'tsid' request per DOTS client. 1536 If no target attribute is included in the request, this is an 1537 indication that the baseline information applies for the DOTS client 1538 domain as a whole. 1540 An example of a PUT request to convey the baseline information is 1541 shown in Figure 19. 1543 Header: PUT (Code=0.03) 1544 Uri-Path: ".well-known" 1545 Uri-Path: "dots" 1546 Uri-Path: "tm-setup" 1547 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1548 Uri-Path: "tsid=129" 1549 Content-Format: "application/dots+cbor" 1551 { 1552 "ietf-dots-telemetry:telemetry-setup": { 1553 "telemetry": [ 1554 { 1555 "baseline": [ 1556 { 1557 "id": 1, 1558 "target-prefix": [ 1559 "2001:db8:6401::1/128", 1560 "2001:db8:6401::2/128" 1561 ], 1562 "total-traffic-normal": [ 1563 { 1564 "unit": "megabit-ps", 1565 "peak-g": "60" 1566 } 1567 ] 1568 } 1569 ] 1570 } 1571 ] 1572 } 1573 } 1575 Figure 19: PUT to Conveying the DOTS Traffic Baseline 1577 The DOTS client may share protocol specific baseline information 1578 (e.g., TCP and UDP) as shown in Figure 19. 1580 Header: PUT (Code=0.03) 1581 Uri-Path: ".well-known" 1582 Uri-Path: "dots" 1583 Uri-Path: "tm-setup" 1584 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1585 Uri-Path: "tsid=130" 1586 Content-Format: "application/dots+cbor" 1588 { 1589 "ietf-dots-telemetry:telemetry-setup": { 1590 "telemetry": [ 1591 { 1592 "baseline": [ 1593 { 1594 "id": 1, 1595 "target-prefix": [ 1596 "2001:db8:6401::1/128", 1597 "2001:db8:6401::2/128" 1598 ], 1599 "total-traffic-normal-per-protocol": [ 1600 { 1601 "unit": "megabit-ps", 1602 "protocol": 6, 1603 "peak-g": "50" 1604 }, 1605 { 1606 "unit": "megabit-ps", 1607 "protocol": 17, 1608 "peak-g": "10" 1609 } 1610 ] 1611 } 1612 ] 1613 } 1614 ] 1615 } 1616 } 1618 Figure 20: PUT to Convey the DOTS Traffic Baseline (2) 1620 The normal traffic baseline information should be updated to reflect 1621 legitimate overloads (e.g., flash crowds) to prevent unnecessary 1622 mitigation. 1624 6.3.2. Retrieve Installed Normal Traffic Baseline 1626 A GET request with 'tsid' Uri-Path parameter is used to retrieve a 1627 specific installed DOTS client domain baseline traffic information. 1628 The same procedure as defined in Section 6.1.3 is followed. 1630 To retrieve all baseline information bound to a DOTS client, the DOTS 1631 client proceeds as specified in Section 6.1.1. 1633 6.3.3. Delete Installed Normal Traffic Baseline 1635 A DELETE request is used to delete the installed DOTS client domain 1636 normal traffic baseline. The same procedure as defined in 1637 Section 6.1.4 is followed. 1639 6.4. Reset Installed Telemetry Setup 1641 Upon bootstrapping (or reboot or any other event that may alter the 1642 DOTS client setup), a DOTS client MAY send a DELETE request to set 1643 the telemetry parameters to default values. Such a request does not 1644 include any 'tsid'. An example of such a request is depicted in 1645 Figure 21. 1647 Header: DELETE (Code=0.04) 1648 Uri-Path: ".well-known" 1649 Uri-Path: "dots" 1650 Uri-Path: "tm-setup" 1651 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1653 Figure 21: Delete Telemetry Configuration 1655 6.5. Conflict with Other DOTS Clients of the Same Domain 1657 A DOTS server may detect conflicts between requests conveying pipe 1658 and baseline information received from DOTS clients of the same DOTS 1659 client domain. 'conflict-information' is used to report the conflict 1660 to the DOTS client following similar conflict handling discussed in 1661 Section 4.4.1 of [RFC9132]. The conflict cause can be set to one of 1662 these values: 1664 1: Overlapping targets (Section 4.4.1 of [RFC9132]). 1666 TBA: Overlapping pipe scope (see Section 12). 1668 7. DOTS Pre-or-Ongoing Mitigation Telemetry 1670 There are two broad types of DDoS attacks: one is a bandwidth 1671 consuming attack, the other is a target-resource-consuming attack. 1672 This section outlines the set of DOTS telemetry attributes 1673 (Section 7.1) that covers both types of attack. The objective of 1674 these attributes is to allow for the complete knowledge of attacks 1675 and the various particulars that can best characterize attacks. 1677 The "ietf-dots-telemetry" YANG module (Section 10.1) defines the data 1678 structure of a new message type called 'telemetry'. The tree 1679 structure of the 'telemetry' message type is shown in Figure 24. 1681 The pre-or-ongoing-mitigation telemetry attributes are indicated by 1682 the path suffix '/tm'. The '/tm' is appended to the path prefix to 1683 form the URI used with a CoAP request to signal the DOTS telemetry. 1684 Pre-or-ongoing-mitigation telemetry attributes specified in 1685 Section 7.1 can be signaled between DOTS agents. 1687 Pre-or-ongoing-mitigation telemetry attributes may be sent by a DOTS 1688 client or a DOTS server. 1690 DOTS agents SHOULD bind pre-or-ongoing-mitigation telemetry data to 1691 mitigation requests associated with the resources under attack. In 1692 particular, a telemetry PUT request sent after a mitigation request 1693 may include a reference to that mitigation request ('mid-list') as 1694 shown in Figure 22. An example illustrating request correlation by 1695 means of 'target-prefix' is shown in Figure 23. 1697 Many of the pre-or-ongoing-mitigation telemetry data use a unit that 1698 falls under the unit class that is configured following the procedure 1699 described in Section 6.1.2. When generating telemetry data to send 1700 to a peer, the DOTS agent MUST auto-scale so that appropriate unit(s) 1701 are used. 1703 +-----------+ +-----------+ 1704 |DOTS client| |DOTS server| 1705 +-----------+ +-----------+ 1706 | | 1707 |===============Mitigation Request (mid)===============>| 1708 | | 1709 |===============Telemetry (mid-list{mid})==============>| 1710 | | 1712 Figure 22: Example of Request Correlation using 'mid' 1714 +-----------+ +-----------+ 1715 |DOTS client| |DOTS server| 1716 +-----------+ +-----------+ 1717 | | 1718 |<================Telemetry (target-prefix)=============| 1719 | | 1720 |=========Mitigation Request (target-prefix)===========>| 1721 | | 1723 Figure 23: Example of Request Correlation using Target Prefix 1725 DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry 1726 notifications to the same peer more frequently than once every 1727 'telemetry-notify-interval' (Section 6.1). If a telemetry 1728 notification is sent using a block-like transfer mechanism (e.g., 1729 [I-D.ietf-core-new-block]), this rate limit policy MUST NOT consider 1730 these individual blocks as separate notifications, but as a single 1731 notification. 1733 DOTS pre-or-ongoing-mitigation telemetry request and response 1734 messages MUST be marked as Non-Confirmable messages (Section 2.1 of 1735 [RFC7252]). 1737 structure dots-telemetry: 1738 +-- (telemetry-message-type)? 1739 +--:(telemetry-setup) 1740 | ... 1741 | +-- telemetry* [] 1742 | +-- (direction)? 1743 | | +--:(server-to-client-only) 1744 | | +-- tsid? uint32 1745 | +-- (setup-type)? 1746 | +--:(telemetry-config) 1747 | | ... 1748 | +--:(pipe) 1749 | | ... 1750 | +--:(baseline) 1751 | ... 1752 +--:(telemetry) 1753 +-- pre-or-ongoing-mitigation* [] 1754 +-- (direction)? 1755 | +--:(server-to-client-only) 1756 | +-- tmid? uint32 1757 +-- target 1758 | ... 1759 +-- total-traffic* [unit] 1760 | ... 1761 +-- total-traffic-protocol* [unit protocol] 1762 | ... 1763 +-- total-traffic-port* [unit port] 1764 | ... 1765 +-- total-attack-traffic* [unit] 1766 | ... 1767 +-- total-attack-traffic-protocol* [unit protocol] 1768 | ... 1769 +-- total-attack-traffic-port* [unit port] 1770 | ... 1771 +-- total-attack-connection-protocol* [protocol] 1772 | ... 1773 +-- total-attack-connection-port* [protocol port] 1774 | ... 1775 +-- attack-detail* [vendor-id attack-id] 1776 ... 1778 Figure 24: Telemetry Message Type Tree Structure 1780 7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes 1782 The description and motivation behind each attribute are presented in 1783 Section 3. DOTS telemetry attributes are optionally signaled and 1784 therefore MUST NOT be treated as mandatory fields in the DOTS signal 1785 channel protocol. 1787 7.1.1. Target 1789 A target resource (Figure 25) is identified using the attributes 1790 'target-prefix', 'target-port-range', 'target-protocol', 'target- 1791 fqdn', 'target-uri', 'alias-name', or a pointer to a mitigation 1792 request ('mid-list'). 1794 +--:(telemetry) 1795 +-- pre-or-ongoing-mitigation* [] 1796 +-- (direction)? 1797 | +--:(server-to-client-only) 1798 | +-- tmid? uint32 1799 +-- target 1800 | +-- target-prefix* inet:ip-prefix 1801 | +-- target-port-range* [lower-port] 1802 | | +-- lower-port inet:port-number 1803 | | +-- upper-port? inet:port-number 1804 | +-- target-protocol* uint8 1805 | +-- target-fqdn* inet:domain-name 1806 | +-- target-uri* inet:uri 1807 | +-- alias-name* string 1808 | +-- mid-list* uint32 1809 +-- total-traffic* [unit] 1810 | ... 1811 +-- total-traffic-protocol* [unit protocol] 1812 | ... 1813 +-- total-traffic-port* [unit port] 1814 | ... 1815 +-- total-attack-traffic* [unit] 1816 | ... 1817 +-- total-attack-traffic-protocol* [unit protocol] 1818 | ... 1819 +-- total-attack-traffic-port* [unit port] 1820 | ... 1821 +-- total-attack-connection-protocol* [protocol] 1822 | ... 1823 +-- total-attack-connection-port* [protocol port] 1824 | ... 1825 +-- attack-detail* [vendor-id attack-id] 1826 ... 1828 Figure 25: Target Tree Structure 1830 At least one of the attributes 'target-prefix', 'target-fqdn', 1831 'target-uri', 'alias-name', or 'mid-list' MUST be present in the 1832 target definition. 1834 If the target is susceptible to bandwidth-consuming attacks, the 1835 attributes representing the percentile values of the 'attack-id' 1836 attack traffic are included. 1838 If the target is susceptible to resource-consuming DDoS attacks, the 1839 same attributes defined in Section 7.1.4 are applicable for 1840 representing the attack. 1842 At least the 'target' attribute and one other pre-or-ongoing- 1843 mitigation attribute MUST be present in the DOTS telemetry message. 1845 7.1.2. Total Traffic 1847 The 'total-traffic' attribute (Figure 26) conveys the percentile 1848 values (including peak and current observed values) of the total 1849 observed traffic. More fine-grained information about the total 1850 traffic can be conveyed in the 'total-traffic-protocol' and 'total- 1851 traffic-port' attributes. 1853 The 'total-traffic-protocol' attribute represents the total traffic 1854 for a target and is transport-protocol specific. 1856 The 'total-traffic-port' represents the total traffic for a target 1857 per port number. 1859 +--:(telemetry) 1860 +-- pre-or-ongoing-mitigation* [] 1861 +-- (direction)? 1862 | +--:(server-to-client-only) 1863 | +-- tmid? uint32 1864 +-- target 1865 | ... 1866 +-- total-traffic* [unit] 1867 | +-- unit unit 1868 | +-- low-percentile-g? yang:gauge64 1869 | +-- mid-percentile-g? yang:gauge64 1870 | +-- high-percentile-g? yang:gauge64 1871 | +-- peak-g? yang:gauge64 1872 | +-- current-g? yang:gauge64 1873 +-- total-traffic-protocol* [unit protocol] 1874 | +-- protocol uint8 1875 | +-- unit unit 1876 | +-- low-percentile-g? yang:gauge64 1877 | +-- mid-percentile-g? yang:gauge64 1878 | +-- high-percentile-g? yang:gauge64 1879 | +-- peak-g? yang:gauge64 1880 | +-- current-g? yang:gauge64 1881 +-- total-traffic-port* [unit port] 1882 | +-- port inet:port-number 1883 | +-- unit unit 1884 | +-- low-percentile-g? yang:gauge64 1885 | +-- mid-percentile-g? yang:gauge64 1886 | +-- high-percentile-g? yang:gauge64 1887 | +-- peak-g? yang:gauge64 1888 | +-- current-g? yang:gauge64 1889 +-- total-attack-traffic* [unit] 1890 | ... 1891 +-- total-attack-traffic-protocol* [unit protocol] 1892 | ... 1893 +-- total-attack-traffic-port* [unit port] 1894 | ... 1895 +-- total-attack-connection-protocol* [protocol] 1896 | ... 1897 +-- total-attack-connection-port* [protocol port] 1898 | ... 1899 +-- attack-detail* [vendor-id attack-id] 1900 ... 1902 Figure 26: Total Traffic Tree Structure 1904 7.1.3. Total Attack Traffic 1906 The 'total-attack-traffic' attribute (Figure 27) conveys the total 1907 observed attack traffic. More fine-grained information about the 1908 total attack traffic can be conveyed in the 'total-attack-traffic- 1909 protocol' and 'total-attack-traffic-port' attributes. 1911 The 'total-attack-traffic-protocol' attribute represents the total 1912 attack traffic for a target and is transport-protocol specific. 1914 The 'total-attack-traffic-port' attribute represents the total attack 1915 traffic for a target per port number. 1917 +--:(telemetry) 1918 +-- pre-or-ongoing-mitigation* [] 1919 +-- (direction)? 1920 | +--:(server-to-client-only) 1921 | +-- tmid? uint32 1922 +-- target 1923 | ... 1924 +-- total-traffic* [unit] 1925 | ... 1926 +-- total-traffic-protocol* [unit protocol] 1927 | ... 1928 +-- total-traffic-port* [unit port] 1929 | ... 1930 +-- total-attack-traffic* [unit] 1931 | +-- unit unit 1932 | +-- low-percentile-g? yang:gauge64 1933 | +-- mid-percentile-g? yang:gauge64 1934 | +-- high-percentile-g? yang:gauge64 1935 | +-- peak-g? yang:gauge64 1936 | +-- current-g? yang:gauge64 1937 +-- total-attack-traffic-protocol* [unit protocol] 1938 | +-- protocol uint8 1939 | +-- unit unit 1940 | +-- low-percentile-g? yang:gauge64 1941 | +-- mid-percentile-g? yang:gauge64 1942 | +-- high-percentile-g? yang:gauge64 1943 | +-- peak-g? yang:gauge64 1944 | +-- current-g? yang:gauge64 1945 +-- total-attack-traffic-port* [unit port] 1946 | +-- port inet:port-number 1947 | +-- unit unit 1948 | +-- low-percentile-g? yang:gauge64 1949 | +-- mid-percentile-g? yang:gauge64 1950 | +-- high-percentile-g? yang:gauge64 1951 | +-- peak-g? yang:gauge64 1952 | +-- current-g? yang:gauge64 1953 +-- total-attack-connection-protocol* [protocol] 1954 | ... 1955 +-- total-attack-connection-port* [protocol port] 1956 | ... 1957 +-- attack-detail* [vendor-id attack-id] 1958 ... 1960 Figure 27: Total Attack Traffic Tree Structure 1962 7.1.4. Total Attack Connections 1964 If the target is susceptible to resource-consuming DDoS attacks, the 1965 'total-attack-connection-protocol' attribute is used to convey the 1966 percentile values (including peak and current observed values) of 1967 various attributes related to the total attack connections. The 1968 following optional subattributes for the target per transport 1969 protocol are included to represent the attack characteristics: 1971 * The number of simultaneous attack connections to the target. 1972 * The number of simultaneous embryonic connections to the target. 1973 * The number of attack connections per second to the target. 1974 * The number of attack requests per second to the target. 1975 * The number of attack partial requests to the target. 1977 The total attack connections per port number is represented using the 1978 'total-attack-connection-port' attribute. 1980 +--:(telemetry) 1981 +-- pre-or-ongoing-mitigation* [] 1982 +-- (direction)? 1983 | +--:(server-to-client-only) 1984 | +-- tmid? uint32 1985 +-- target 1986 | ... 1987 +-- total-traffic* [unit] 1988 | ... 1989 +-- total-traffic-protocol* [unit protocol] 1990 | ... 1991 +-- total-traffic-port* [unit port] 1992 | ... 1993 +-- total-attack-traffic* [unit] 1994 | ... 1995 +-- total-attack-traffic-protocol* [unit protocol] 1996 | ... 1997 +-- total-attack-traffic-port* [unit port] 1998 | ... 1999 +-- total-attack-connection-protocol* [protocol] 2000 | +-- protocol uint8 2001 | +-- connection-c 2002 | | +-- low-percentile-g? yang:gauge64 2003 | | +-- mid-percentile-g? yang:gauge64 2004 | | +-- high-percentile-g? yang:gauge64 2005 | | +-- peak-g? yang:gauge64 2006 | | +-- current-g? yang:gauge64 2007 | +-- embryonic-c 2008 | | +-- low-percentile-g? yang:gauge64 2009 | | +-- mid-percentile-g? yang:gauge64 2010 | | +-- high-percentile-g? yang:gauge64 2011 | | +-- peak-g? yang:gauge64 2012 | | +-- current-g? yang:gauge64 2013 | +-- connection-ps-c 2014 | | +-- low-percentile-g? yang:gauge64 2015 | | +-- mid-percentile-g? yang:gauge64 2016 | | +-- high-percentile-g? yang:gauge64 2017 | | +-- peak-g? yang:gauge64 2018 | | +-- current-g? yang:gauge64 2019 | +-- request-ps-c 2020 | | +-- low-percentile-g? yang:gauge64 2021 | | +-- mid-percentile-g? yang:gauge64 2022 | | +-- high-percentile-g? yang:gauge64 2023 | | +-- peak-g? yang:gauge64 2024 | | +-- current-g? yang:gauge64 2025 | +-- partial-request-c 2026 | +-- low-percentile-g? yang:gauge64 2027 | +-- mid-percentile-g? yang:gauge64 2028 | +-- high-percentile-g? yang:gauge64 2029 | +-- peak-g? yang:gauge64 2030 | +-- current-g? yang:gauge64 2031 +-- total-attack-connection-port* [protocol port] 2032 | +-- protocol uint8 2033 | +-- port inet:port-number 2034 | +-- connection-c 2035 | | +-- low-percentile-g? yang:gauge64 2036 | | +-- mid-percentile-g? yang:gauge64 2037 | | +-- high-percentile-g? yang:gauge64 2038 | | +-- peak-g? yang:gauge64 2039 | | +-- current-g? yang:gauge64 2040 | +-- embryonic-c 2041 | | +-- low-percentile-g? yang:gauge64 2042 | | +-- mid-percentile-g? yang:gauge64 2043 | | +-- high-percentile-g? yang:gauge64 2044 | | +-- peak-g? yang:gauge64 2045 | | +-- current-g? yang:gauge64 2046 | +-- connection-ps-c 2047 | | +-- low-percentile-g? yang:gauge64 2048 | | +-- mid-percentile-g? yang:gauge64 2049 | | +-- high-percentile-g? yang:gauge64 2050 | | +-- peak-g? yang:gauge64 2051 | | +-- current-g? yang:gauge64 2052 | +-- request-ps-c 2053 | | +-- low-percentile-g? yang:gauge64 2054 | | +-- mid-percentile-g? yang:gauge64 2055 | | +-- high-percentile-g? yang:gauge64 2056 | | +-- peak-g? yang:gauge64 2057 | | +-- current-g? yang:gauge64 2058 | +-- partial-request-c 2059 | +-- low-percentile-g? yang:gauge64 2060 | +-- mid-percentile-g? yang:gauge64 2061 | +-- high-percentile-g? yang:gauge64 2062 | +-- peak-g? yang:gauge64 2063 | +-- current-g? yang:gauge64 2064 +-- attack-detail* [vendor-id attack-id] 2065 ... 2067 Figure 28: Total Attack Connections Tree Structure 2069 7.1.5. Attack Details 2071 This attribute (depicted in Figure 29) is used to signal a set of 2072 details characterizing an attack. The following subattributes 2073 describing the ongoing attack can be signalled as attack details: 2075 vendor-id: Vendor ID is a security vendor's Enterprise Number as 2076 registered with IANA [Enterprise-Numbers]. It is a four-byte 2077 integer value. 2079 attack-id: Unique identifier assigned for the attack by a vendor. 2080 This parameter MUST be present independently whether 'attack- 2081 description' is included or not. 2083 attack-description: Textual representation of the attack 2084 description. Natural Language Processing techniques (e.g., word 2085 embedding) might provide some utility in mapping the attack 2086 description to an attack type. Textual representation of attack 2087 solves two problems: (a) avoids the need to create mapping tables 2088 manually between vendors and (b) avoids the need to standardize 2089 attack types which keep evolving. 2091 attack-severity: Attack severity level. This attribute takes one of 2092 the values defined in Section 3.12.2 of [RFC7970]. 2094 start-time: The time the attack started. The attack's start time is 2095 expressed in seconds relative to 1970-01-01T00:00Z (Section 3.4.2 2096 of [RFC8949]). The CBOR encoding is modified so that the leading 2097 tag 1 (epoch-based date/time) MUST be omitted. 2099 end-time: The time the attack ended. The attack end time is 2100 expressed in seconds relative to 1970-01-01T00:00Z (Section 3.4.2 2101 of [RFC8949]). The CBOR encoding is modified so that the leading 2102 tag 1 (epoch-based date/time) MUST be omitted. 2104 source-count: A count of sources involved in the attack targeting 2105 the victim. 2107 top-talker: A list of attack sources that are involved in an attack 2108 and which are generating an important part of the attack traffic. 2109 The top talkers are represented using the 'source-prefix'. 2111 'spoofed-status' indicates whether a top talker is a spoofed IP 2112 address (e.g., reflection attacks) or not. If no 'spoofed-status' 2113 data node is included, this means that the spoofing status is 2114 unknown. 2116 If the target is being subjected to a bandwidth-consuming attack, 2117 a statistical profile of the attack traffic from each of the top 2118 talkers is included ('total-attack-traffic', Section 7.1.3). 2120 If the target is being subjected to a resource-consuming DDoS 2121 attack, the same attributes defined in Section 7.1.4 are 2122 applicable for characterizing the attack on a per-talker basis. 2124 +--:(telemetry) 2125 +-- pre-or-ongoing-mitigation* [] 2126 +-- (direction)? 2127 | +--:(server-to-client-only) 2128 | +-- tmid? uint32 2129 +-- target 2130 | ... 2131 +-- total-traffic* [unit] 2132 | ... 2133 +-- total-traffic-protocol* [unit protocol] 2134 | ... 2135 +-- total-traffic-port* [unit port] 2136 | ... 2137 +-- total-attack-traffic* [unit] 2138 | ... 2139 +-- total-attack-traffic-protocol* [unit protocol] 2140 | ... 2141 +-- total-attack-traffic-port* [unit port] 2142 | ... 2143 +-- total-attack-connection-protocol* [protocol] 2144 | ... 2145 +-- total-attack-connection-port* [protocol port] 2146 | ... 2147 +-- attack-detail* [vendor-id attack-id] 2148 +-- vendor-id uint32 2149 +-- attack-id uint32 2150 +-- attack-description? string 2151 +-- attack-severity? attack-severity 2152 +-- start-time? uint64 2153 +-- end-time? uint64 2154 +-- source-count 2155 | +-- low-percentile-g? yang:gauge64 2156 | +-- mid-percentile-g? yang:gauge64 2157 | +-- high-percentile-g? yang:gauge64 2158 | +-- peak-g? yang:gauge64 2159 | +-- current-g? yang:gauge64 2160 +-- top-talker 2161 +-- talker* [source-prefix] 2162 +-- spoofed-status? boolean 2163 +-- source-prefix inet:ip-prefix 2164 +-- source-port-range* [lower-port] 2165 | +-- lower-port inet:port-number 2166 | +-- upper-port? inet:port-number 2167 +-- source-icmp-type-range* [lower-type] 2168 | +-- lower-type uint8 2169 | +-- upper-type? uint8 2170 +-- total-attack-traffic* [unit] 2171 | +-- unit unit 2172 | +-- low-percentile-g? yang:gauge64 2173 | +-- mid-percentile-g? yang:gauge64 2174 | +-- high-percentile-g? yang:gauge64 2175 | +-- peak-g? yang:gauge64 2176 | +-- current-g? yang:gauge64 2177 +-- total-attack-connection-protocol* 2178 [protocol] 2179 +-- protocol uint8 2180 +-- connection-c 2181 | +-- low-percentile-g? yang:gauge64 2182 | +-- mid-percentile-g? yang:gauge64 2183 | +-- high-percentile-g? yang:gauge64 2184 | +-- peak-g? yang:gauge64 2185 | +-- current-g? yang:gauge64 2186 +-- embryonic-c 2187 | +-- low-percentile-g? yang:gauge64 2188 | +-- mid-percentile-g? yang:gauge64 2189 | +-- high-percentile-g? yang:gauge64 2190 | +-- peak-g? yang:gauge64 2191 | +-- current-g? yang:gauge64 2192 +-- connection-ps-c 2193 | +-- low-percentile-g? yang:gauge64 2194 | +-- mid-percentile-g? yang:gauge64 2195 | +-- high-percentile-g? yang:gauge64 2196 | +-- peak-g? yang:gauge64 2197 | +-- current-g? yang:gauge64 2198 +-- request-ps-c 2199 | +-- low-percentile-g? yang:gauge64 2200 | +-- mid-percentile-g? yang:gauge64 2201 | +-- high-percentile-g? yang:gauge64 2202 | +-- peak-g? yang:gauge64 2203 | +-- current-g? yang:gauge64 2204 +-- partial-request-c 2205 +-- low-percentile-g? yang:gauge64 2206 +-- mid-percentile-g? yang:gauge64 2207 +-- high-percentile-g? yang:gauge64 2208 +-- peak-g? yang:gauge64 2209 +-- current-g? yang:gauge64 2211 Figure 29: Attack Detail Tree Structure 2213 In order to optimize the size of telemetry data conveyed over the 2214 DOTS signal channel, DOTS agents MAY use the DOTS data channel 2215 [RFC8783] to exchange vendor specific attack mapping details (that 2216 is, {vendor identifier, attack identifier} ==> textual representation 2217 of the attack description). As such, DOTS agents do not have to 2218 convey systematically an attack description in their telemetry 2219 messages over the DOTS signal channel. Refer to Section 7.1.6. 2221 7.1.6. Vendor Attack Mapping 2223 Multiple mappings for different vendor identifiers may be used; the 2224 DOTS agent transmitting telemetry information can elect to use one or 2225 more vendor mappings even in the same telemetry message. 2227 Note: It is possible that a DOTS server is making use of multiple 2228 DOTS mitigators; each from a different vendor. How telemetry 2229 information and vendor mappings are exchanged between DOTS servers 2230 and DOTS mitigators is outside the scope of this document. 2232 DOTS clients and servers may be provided with mappings from different 2233 vendors and so have their own different sets of vendor attack 2234 mappings. A DOTS agent MUST accept receipt of telemetry data with a 2235 vendor identifier that is different to the one it uses to transmit 2236 telemetry data. Furthermore, it is possible that the DOTS client and 2237 DOTS server are provided by the same vendor, but the vendor mapping 2238 tables are at different revisions. The DOTS client SHOULD transmit 2239 telemetry information using any vendor mapping(s) that it provided to 2240 the DOTS server (e.g., using a POST as depicted in Figure 34) and the 2241 DOTS server SHOULD use any vendor mappings(s) provided to the DOTS 2242 client when transmitting telemetry data to the peer DOTS agent. 2244 The "ietf-dots-mapping" YANG module defined in Section 10.2 augments 2245 the "ietf-dots-data-channel" [RFC8783] module. The tree structure of 2246 the "ietf-dots-mapping" module is shown in Figure 30. 2248 module: ietf-dots-mapping 2249 augment /data-channel:dots-data/data-channel:dots-client: 2250 +--rw vendor-mapping {dots-telemetry}? 2251 +--rw vendor* [vendor-id] 2252 +--rw vendor-id uint32 2253 +--rw vendor-name? string 2254 +--rw last-updated uint64 2255 +--rw attack-mapping* [attack-id] 2256 +--rw attack-id uint32 2257 +--rw attack-description string 2258 augment /data-channel:dots-data/data-channel:capabilities: 2259 +--ro vendor-mapping-enabled? boolean {dots-telemetry}? 2260 augment /data-channel:dots-data: 2261 +--ro vendor-mapping {dots-telemetry}? 2262 +--ro vendor* [vendor-id] 2263 +--ro vendor-id uint32 2264 +--ro vendor-name? string 2265 +--ro last-updated uint64 2266 +--ro attack-mapping* [attack-id] 2267 +--ro attack-id uint32 2268 +--ro attack-description string 2270 Figure 30: Vendor Attack Mapping Tree Structure 2272 A DOTS client sends a GET request to retrieve the capabilities 2273 supported by a DOTS server as per Section 7.1 of [RFC8783]. This 2274 request is meant to assess whether the capability of sharing vendor 2275 attack mapping details is supported by the server (i.e., check the 2276 value of 'vendor-mapping-enabled'). 2278 If 'vendor-mapping-enabled' is set to 'true', a DOTS client MAY send 2279 a GET request to retrieve the DOTS server's vendor attack mapping 2280 details. An example of such a GET request is shown in Figure 31. 2282 GET /restconf/data/ietf-dots-data-channel:dots-data\ 2283 /ietf-dots-mapping:vendor-mapping HTTP/1.1 2284 Host: example.com 2285 Accept: application/yang-data+json 2287 Figure 31: GET to Retrieve the Vendor Attack Mappings of a DOTS 2288 Server 2290 A DOTS client can retrieve only the list of vendors supported by the 2291 DOTS server. It does so by setting the "depth" parameter 2292 (Section 4.8.2 of [RFC8040]) to "3" in the GET request as shown in 2293 Figure 32. An example of a response body received from the DOTS 2294 server as a response to such a request is illustrated in Figure 33. 2296 GET /restconf/data/ietf-dots-data-channel:dots-data\ 2297 /ietf-dots-mapping:vendor-mapping?depth=3 HTTP/1.1 2298 Host: example.com 2299 Accept: application/yang-data+json 2301 Figure 32: GET to Retrieve the Vendors List used by a DOTS Server 2303 { 2304 "ietf-dots-mapping:vendor-mapping": { 2305 "vendor": [ 2306 { 2307 "vendor-id": 32473, 2308 "vendor-name": "mitigator-s", 2309 "last-updated": "1629898758", 2310 "attack-mapping": [] 2311 } 2312 ] 2313 } 2314 } 2316 Figure 33: Response to a GET to Retrieve the Vendors List used by 2317 a DOTS Server 2319 The DOTS client reiterates the above procedure regularly (e.g., once 2320 a week) to update the DOTS server's vendor attack mapping details. 2322 If the DOTS client concludes that the DOTS server does not have any 2323 reference to the specific vendor attack mapping details, the DOTS 2324 client uses a POST request to install its vendor attack mapping 2325 details. An example of such a POST request is depicted in Figure 34. 2327 POST /restconf/data/ietf-dots-data-channel:dots-data\ 2328 /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1 2329 Host: example.com 2330 Content-Type: application/yang-data+json 2332 { 2333 "ietf-dots-mapping:vendor-mapping": { 2334 "vendor": [ 2335 { 2336 "vendor-id": 345, 2337 "vendor-name": "mitigator-c", 2338 "last-updated": "1629898958", 2339 "attack-mapping": [ 2340 { 2341 "attack-id": 1, 2342 "attack-description": 2343 "Include a description of this attack" 2344 }, 2345 { 2346 "attack-id": 2, 2347 "attack-description": 2348 "Again, include a description of the attack" 2349 } 2350 ] 2351 } 2352 ] 2353 } 2354 } 2356 Figure 34: POST to Install Vendor Attack Mapping Details 2358 The DOTS server indicates the result of processing the POST request 2359 using the status-line. Concretely, "201 Created" status-line MUST be 2360 returned in the response if the DOTS server has accepted the vendor 2361 attack mapping details. If the request is missing a mandatory 2362 attribute or contains an invalid or unknown parameter, "400 Bad 2363 Request" status-line MUST be returned by the DOTS server in the 2364 response. The error-tag is set to "missing-attribute", "invalid- 2365 value", or "unknown-element" as a function of the encountered error. 2367 If the request is received via a server-domain DOTS gateway, but the 2368 DOTS server does not maintain a 'cdid' for this 'cuid' while a 'cdid' 2369 is expected to be supplied, the DOTS server MUST reply with "403 2370 Forbidden" status-line and the error-tag "access-denied". Upon 2371 receipt of this message, the DOTS client MUST register (Section 5.1 2372 of [RFC8783]). 2374 The DOTS client uses the PUT request to modify its vendor attack 2375 mapping details maintained by the DOTS server (e.g., add a new 2376 mapping entry, update an existing mapping). 2378 A DOTS client uses a GET request to retrieve its vendor attack 2379 mapping details as maintained by the DOTS server (Figure 35). 2381 GET /restconf/data/ietf-dots-data-channel:dots-data\ 2382 /dots-client=dz6pHjaADkaFTbjr0JGBpw\ 2383 /ietf-dots-mapping:vendor-mapping?\ 2384 content=all HTTP/1.1 2385 Host: example.com 2386 Accept: application/yang-data+json 2388 Figure 35: GET to Retrieve Installed Vendor Attack Mapping Details 2390 When conveying attack details in DOTS telemetry messages (Sections 2391 7.2, 7.3, and 8), DOTS agents MUST NOT include the 'attack- 2392 description' attribute unless the corresponding attack mapping 2393 details were not previously shared with the peer DOTS agent. 2395 7.2. From DOTS Clients to DOTS Servers 2397 DOTS clients use PUT requests to signal pre-or-ongoing-mitigation 2398 telemetry to DOTS servers. An example of such a request is shown in 2399 Figure 36. 2401 Header: PUT (Code=0.03) 2402 Uri-Path: ".well-known" 2403 Uri-Path: "dots" 2404 Uri-Path: "tm" 2405 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2406 Uri-Path: "tmid=123" 2407 Content-Format: "application/dots+cbor" 2409 { 2410 "ietf-dots-telemetry:telemetry": { 2411 "pre-or-ongoing-mitigation": [ 2412 { 2413 "target": { 2414 "target-prefix": [ 2415 "2001:db8::1/128" 2416 ] 2417 }, 2418 "total-attack-traffic-protocol": [ 2419 { 2420 "protocol": 17, 2421 "unit": "megabit-ps", 2422 "mid-percentile-g": "900" 2423 } 2424 ], 2425 "attack-detail": [ 2426 { 2427 "vendor-id": 32473, 2428 "attack-id": 77, 2429 "start-time": "1608336568", 2430 "attack-severity": "high" 2431 } 2432 ] 2433 } 2434 ] 2435 } 2436 } 2438 Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry 2440 'cuid' is a mandatory Uri-Path parameter for DOTS PUT requests. 2442 The following additional Uri-Path parameter is defined: 2444 tmid: Telemetry Identifier is an identifier for the DOTS pre-or- 2445 ongoing-mitigation telemetry data represented as an integer. 2446 This identifier MUST be generated by DOTS clients. 'tmid' values 2447 MUST increase monotonically (when a new PUT is generated by a 2448 DOTS client to convey pre-or-ongoing-mitigation telemetry). 2450 The procedure specified in Section 4.4.1 of [RFC9132] for 'mid' 2451 rollover MUST be followed for 'tmid' rollover. 2453 This is a mandatory attribute. 'tmid' MUST follow 'cuid'. 2455 'cuid' and 'tmid' MUST NOT appear in the PUT request message body. 2457 At least the 'target' attribute and another pre-or-ongoing-mitigation 2458 attribute (Section 7.1) MUST be present in the PUT request. If only 2459 the 'target' attribute is present, this request is handled as per 2460 Section 7.3. 2462 The relative order of two PUT requests carrying DOTS pre-or-ongoing- 2463 mitigation telemetry from a DOTS client is determined by comparing 2464 their respective 'tmid' values. If two such requests have an 2465 overlapping 'target', the PUT request with higher numeric 'tmid' 2466 value will override the request with a lower numeric 'tmid' value. 2467 The overlapped lower numeric 'tmid' MUST be automatically deleted and 2468 no longer be available. 2470 The DOTS server indicates the result of processing a PUT request 2471 using CoAP Response Codes. In particular, the 2.04 (Changed) 2472 Response Code is returned if the DOTS server has accepted the pre-or- 2473 ongoing-mitigation telemetry. The 5.03 (Service Unavailable) 2474 Response Code is returned if the DOTS server has erred. 5.03 uses the 2475 Max-Age Option to indicate the number of seconds after which to 2476 retry. 2478 How long a DOTS server maintains a 'tmid' as active or logs the 2479 enclosed telemetry information is implementation specific. Note that 2480 if a 'tmid' is still active, then logging details are updated by the 2481 DOTS server as a function of the updates received from the peer DOTS 2482 client. 2484 A DOTS client that lost the state of its active 'tmid's or has to set 2485 'tmid' back to zero (e.g., crash or restart) MUST send a GET request 2486 to the DOTS server to retrieve the list of active 'tmid' values. The 2487 DOTS client may then delete 'tmid's that should not be active anymore 2488 (Figure 37). Sending a DELETE with no 'tmid' indicates that all 2489 'tmid's must be deactivated (Figure 38). 2491 Header: DELETE (Code=0.04) 2492 Uri-Path: ".well-known" 2493 Uri-Path: "dots" 2494 Uri-Path: "tm" 2495 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2496 Uri-Path: "tmid=123" 2497 Figure 37: Delete a Pre-or-Ongoing-Mitigation Telemetry 2499 Header: DELETE (Code=0.04) 2500 Uri-Path: ".well-known" 2501 Uri-Path: "dots" 2502 Uri-Path: "tm" 2503 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2505 Figure 38: Delete All Pre-or-Ongoing-Mitigation Telemetry 2507 7.3. From DOTS Servers to DOTS Clients 2509 The pre-or-ongoing-mitigation data (attack details, in particular) 2510 can also be signaled from DOTS servers to DOTS clients. For example, 2511 a DOTS server co-located with a DDoS detector can collect monitoring 2512 information from the target network, identify a DDoS attack using 2513 statistical analysis or deep learning techniques, and signal the 2514 attack details to the DOTS client. 2516 The DOTS client can use the attack details to decide whether to 2517 trigger a DOTS mitigation request or not. Furthermore, the security 2518 operations personnel at the DOTS client domain can use the attack 2519 details to determine the protection strategy and select the 2520 appropriate DOTS server for mitigating the attack. 2522 In order to receive pre-or-ongoing-mitigation telemetry notifications 2523 from a DOTS server, a DOTS client MUST send a PUT (followed by a GET) 2524 with the target filter. An example of such a PUT request is shown in 2525 Figure 39. In order to avoid maintaining a long list of such 2526 requests, it is RECOMMENDED that DOTS clients include all targets in 2527 the same request (assuming this fits within one single datagram). 2528 DOTS servers may be instructed to restrict the number of pre-or- 2529 ongoing-mitigation requests per DOTS client domain. The PUT request 2530 MUST be maintained in an active state by the DOTS server until a 2531 delete request is received from the same DOTS client to clear this 2532 pre-or-ongoing-mitigation telemetry or when the DOTS client is 2533 considered inactive (e.g., Section 3.5 of [RFC8783]). 2535 The relative order of two PUT requests carrying DOTS pre-or-ongoing- 2536 mitigation telemetry from a DOTS client is determined by comparing 2537 their respective 'tmid' values. If such two requests have 2538 overlapping 'target', the PUT request with higher numeric 'tmid' 2539 value will override the request with a lower numeric 'tmid' value. 2540 The overlapped lower numeric 'tmid' MUST be automatically deleted and 2541 no longer be available. 2543 Header: PUT (Code=0.03) 2544 Uri-Path: ".well-known" 2545 Uri-Path: "dots" 2546 Uri-Path: "tm" 2547 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2548 Uri-Path: "tmid=567" 2549 Content-Format: "application/dots+cbor" 2551 { 2552 "ietf-dots-telemetry:telemetry": { 2553 "pre-or-ongoing-mitigation": [ 2554 { 2555 "target": { 2556 "target-prefix": [ 2557 "2001:db8::/32" 2558 ] 2559 } 2560 } 2561 ] 2562 } 2563 } 2565 Figure 39: PUT to Request Pre-or-Ongoing-Mitigation Telemetry 2567 DOTS clients of the same domain can request to receive pre-or- 2568 ongoing-mitigation telemetry bound to the same target without being 2569 considered to be "overlapping" and in conflict. 2571 Once the PUT request to instantiate request state on the server has 2572 succeeded, the DOTS client issues a GET request to receive ongoing 2573 telemtry updates. The client uses the Observe Option, set to '0' 2574 (register), in the GET request to receive asynchronous notifications 2575 carrying pre-or-ongoing-mitigation telemetry data from the DOTS 2576 server. The GET request can specify a specific 'tmid' (Figure 40) or 2577 omit the 'tmid' (Figure 41) to receive updates on all active requests 2578 from that client. 2580 Header: GET (Code=0.01) 2581 Uri-Path: ".well-known" 2582 Uri-Path: "dots" 2583 Uri-Path: "tm" 2584 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2585 Uri-Path: "tmid=567" 2586 Observe: 0 2588 Figure 40: GET to Subscribe to Telemetry Asynchronous 2589 Notifications for a Specific 'tmid' 2591 Header: GET (Code=0.01) 2592 Uri-Path: ".well-known" 2593 Uri-Path: "dots" 2594 Uri-Path: "tm" 2595 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2596 Observe: 0 2598 Figure 41: GET to Subscribe to Telemetry Asynchronous 2599 Notifications for All 'tmids' 2601 The DOTS client can use a filter to request a subset of the 2602 asynchronous notifications from the DOTS server by indicating one or 2603 more Uri-Query options in its GET request. A Uri-Query option can 2604 include the following parameters to restrict the notifications based 2605 on the attack target: 'target-prefix', 'target-port', 'target- 2606 protocol', 'target-fqdn', 'target-uri', 'alias-name', 'mid', and 'c' 2607 (content) (Section 4.2.4). Furthermore: 2609 If more than one Uri-Query option is included in a request, these 2610 options are interpreted in the same way as when multiple target 2611 attributes are included in a message body (Section 4.4.1 of 2612 [RFC9132]). 2614 If multiple values of a query parameter are to be included in a 2615 request, these values MUST be included in the same Uri-Query 2616 option and separated by a "," character without any spaces. 2618 Range values (i.e., a contiguous inclusive block) can be included 2619 for the 'target-port', 'target-protocol', and 'mid' parameters by 2620 indicating the two boundary values separated by a "-" character. 2622 Wildcard names (i.e., a name with the leftmost label is the "*" 2623 character) can be included in 'target-fqdn' or 'target-uri' 2624 parameters. DOTS clients MUST NOT include a name in which the "*" 2625 character is included in a label other than the leftmost label. 2626 "*.example.com" is an example of a valid wildcard name that can be 2627 included as a value of the 'target-fqdn' parameter in an Uri-Query 2628 option. 2630 DOTS clients may also filter out the asynchronous notifications from 2631 the DOTS server by indicating information about a specific attack 2632 source. To that aim, a DOTS client may include 'source-prefix', 2633 'source-port', or 'source-icmp-type' in a Uri-Query option. The same 2634 considerations (ranges, multiple values) specified for target 2635 attributes apply for source attributes. Special care SHOULD be taken 2636 when using these filters as their use may cause some attacks may be 2637 hidden to the requesting DOTS client (e.g., if the attack changes its 2638 source information). 2640 Requests with invalid query types (e.g., not supported, malformed) 2641 received by the DOTS server MUST be rejected with a 4.00 (Bad 2642 Request) response code. 2644 An example of a request to subscribe to asynchronous telemetry 2645 notifications regarding UDP traffic is shown in Figure 42. This 2646 filter will be applied for all 'tmid's. 2648 Header: GET (Code=0.01) 2649 Uri-Path: ".well-known" 2650 Uri-Path: "dots" 2651 Uri-Path: "tm" 2652 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2653 Uri-Query: "target-protocol=17" 2654 Observe: 0 2656 Figure 42: GET Request to Receive Telemetry Asynchronous 2657 Notifications Filtered using Uri-Query 2659 The DOTS server will send asynchronous notifications to the DOTS 2660 client when an attack event is detected following similar 2661 considerations as in Section 4.4.2.1 of [RFC9132]. An example of a 2662 pre-or-ongoing-mitigation telemetry notification is shown in 2663 Figure 43. 2665 { 2666 "ietf-dots-telemetry:telemetry": { 2667 "pre-or-ongoing-mitigation": [ 2668 { 2669 "tmid": 567, 2670 "target": { 2671 "target-prefix": [ 2672 "2001:db8::1/128" 2673 ] 2674 }, 2675 "target-protocol": [ 2676 17 2677 ], 2678 "total-attack-traffic": [ 2679 { 2680 "unit": "megabit-ps", 2681 "mid-percentile-g": "900" 2682 } 2683 ], 2684 "attack-detail": [ 2685 { 2686 "vendor-id": 32473, 2687 "attack-id": 77, 2688 "start-time": "1618339785", 2689 "attack-severity": "high" 2690 } 2691 ] 2692 } 2693 ] 2694 } 2695 } 2697 Figure 43: Message Body of a Pre-or-Ongoing-Mitigation Telemetry 2698 Notification from the DOTS Server 2700 A DOTS server sends the aggregate data for a target using 'total- 2701 attack-traffic' attribute. The aggregate assumes that Uri-Query 2702 filters are applied on the target. The DOTS server MAY include more 2703 fine-grained data when needed (that is, 'total-attack-traffic- 2704 protocol' and 'total-attack-traffic-port'). If a port filter (or 2705 protocol filter) is included in a request, 'total-attack-traffic- 2706 protocol' (or 'total-attack-traffic-port') conveys the data with the 2707 port (or protocol) filter applied. 2709 A DOTS server may aggregate pre-or-ongoing-mitigation data (e.g., 2710 'top-talker') for all targets of a domain, or when justified, send 2711 specific information (e.g., 'top-talker') per individual targets. 2713 The DOTS client may log pre-or-ongoing-mitigation telemetry data with 2714 an alert sent to an administrator or a network controller. The DOTS 2715 client may send a mitigation request if the attack cannot be handled 2716 locally. 2718 A DOTS client that is not interested to receive pre-or-ongoing- 2719 mitigation telemetry data for a target sends a delete request similar 2720 to the one depicted in Figure 37. 2722 8. DOTS Telemetry Mitigation Status Update 2724 8.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry 2725 Attributes 2727 The mitigation efficacy telemetry attributes can be signaled from 2728 DOTS clients to DOTS servers as part of the periodic mitigation 2729 efficacy updates to the server (Section 4.4.3 of [RFC9132]). 2731 Total Attack Traffic: The overall attack traffic as observed from 2732 the DOTS client perspective during an active mitigation. See 2733 Figure 27. 2735 Attack Details: The overall attack details as observed from the DOTS 2736 client perspective during an active mitigation. See 2737 Section 7.1.5. 2739 The "ietf-dots-telemetry" YANG module (Section 10.1) augments the 2740 'mitigation-scope' message type defined in the "ietf-dots-signal" 2741 module [RFC9132] so that these attributes can be signalled by a DOTS 2742 client in a mitigation efficacy update (Figure 44). 2744 augment-structure /dots-signal:dots-signal/dots-signal:message-type 2745 /dots-signal:mitigation-scope/dots-signal:scope: 2746 +-- total-attack-traffic* [unit] 2747 | +-- unit unit 2748 | +-- low-percentile-g? yang:gauge64 2749 | +-- mid-percentile-g? yang:gauge64 2750 | +-- high-percentile-g? yang:gauge64 2751 | +-- peak-g? yang:gauge64 2752 | +-- current-g? yang:gauge64 2753 +-- attack-detail* [vendor-id attack-id] 2754 +-- vendor-id uint32 2755 +-- attack-id uint32 2756 +-- attack-description? string 2757 +-- attack-severity? attack-severity 2758 +-- start-time? uint64 2759 +-- end-time? uint64 2760 +-- source-count 2761 | +-- low-percentile-g? yang:gauge64 2762 | +-- mid-percentile-g? yang:gauge64 2763 | +-- high-percentile-g? yang:gauge64 2764 | +-- peak-g? yang:gauge64 2765 | +-- current-g? yang:gauge64 2766 +-- top-talker 2767 +-- talker* [source-prefix] 2768 +-- spoofed-status? boolean 2769 +-- source-prefix inet:ip-prefix 2770 +-- source-port-range* [lower-port] 2771 | +-- lower-port inet:port-number 2772 | +-- upper-port? inet:port-number 2773 +-- source-icmp-type-range* [lower-type] 2774 | +-- lower-type uint8 2775 | +-- upper-type? uint8 2776 +-- total-attack-traffic* [unit] 2777 | +-- unit unit 2778 | +-- low-percentile-g? yang:gauge64 2779 | +-- mid-percentile-g? yang:gauge64 2780 | +-- high-percentile-g? yang:gauge64 2781 | +-- peak-g? yang:gauge64 2782 | +-- current-g? yang:gauge64 2783 +-- total-attack-connection 2784 +-- connection-c 2785 | +-- low-percentile-g? yang:gauge64 2786 | +-- mid-percentile-g? yang:gauge64 2787 | +-- high-percentile-g? yang:gauge64 2788 | +-- peak-g? yang:gauge64 2789 | +-- current-g? yang:gauge64 2790 +-- embryonic-c 2791 | ... 2792 +-- connection-ps-c 2793 | ... 2794 +-- request-ps-c 2795 | ... 2796 +-- partial-request-c 2797 ... 2799 Figure 44: Telemetry Efficacy Update Tree Structure 2801 In order to signal telemetry data in a mitigation efficacy update, it 2802 is RECOMMENDED that the DOTS client has already established a DOTS 2803 telemetry setup session with the server in 'idle' time. Such a 2804 session is primary meant to assess whether the peer DOTS server 2805 supports telemetry extensions and, thus, prevent message processing 2806 failure (Section 3.1 of [RFC9132]). 2808 An example of an efficacy update with telemetry attributes is 2809 depicted in Figure 45. 2811 Header: PUT (Code=0.03) 2812 Uri-Path: ".well-known" 2813 Uri-Path: "dots" 2814 Uri-Path: "mitigate" 2815 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2816 Uri-Path: "mid=123" 2817 If-Match: 2818 Content-Format: "application/dots+cbor" 2820 { 2821 "ietf-dots-signal-channel:mitigation-scope": { 2822 "scope": [ 2823 { 2824 "alias-name": [ 2825 "https1", 2826 "https2" 2827 ], 2828 "attack-status": "under-attack", 2829 "ietf-dots-telemetry:total-attack-traffic": [ 2830 { 2831 "unit": "megabit-ps", 2832 "mid-percentile-g": "900" 2833 } 2834 ] 2835 } 2836 ] 2837 } 2838 } 2840 Figure 45: An Example of Mitigation Efficacy Update with 2841 Telemetry Attributes 2843 8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry 2844 Attributes 2846 The mitigation status telemetry attributes can be signaled from the 2847 DOTS server to the DOTS client as part of the periodic mitigation 2848 status update (Section 4.4.2 of [RFC9132]). In particular, DOTS 2849 clients can receive asynchronous notifications of the attack details 2850 from DOTS servers using the Observe option defined in [RFC7641]. 2852 In order to make use of this feature, DOTS clients MUST establish a 2853 telemetry session with the DOTS server in 'idle' time and MUST set 2854 the 'server-originated-telemetry' attribute to 'true'. 2856 DOTS servers MUST NOT include telemetry attributes in mitigation 2857 status updates sent to DOTS clients for telemetry sessions in which 2858 the 'server-originated-telemetry' attribute is set to 'false'. 2860 As defined in [RFC8612], the actual mitigation activities can include 2861 several countermeasure mechanisms. The DOTS server signals the 2862 current operational status of relevant countermeasures. A list of 2863 attacks detected by these countermeasures MAY also be included. The 2864 same attributes defined in Section 7.1.5 are applicable for 2865 describing the attacks detected and mitigated at the DOTS server 2866 domain. 2868 The "ietf-dots-telemetry" YANG module (Section 10.1) augments the 2869 'mitigation-scope' message type defined in "ietf-dots-signal" 2870 [RFC9132] with telemetry data as depicted in Figure 46. 2872 augment-structure /dots-signal:dots-signal/dots-signal:message-type 2873 /dots-signal:mitigation-scope/dots-signal:scope: 2874 +-- (direction)? 2875 | +--:(server-to-client-only) 2876 | +-- total-traffic* [unit] 2877 | | +-- unit unit 2878 | | +-- low-percentile-g? yang:gauge64 2879 | | +-- mid-percentile-g? yang:gauge64 2880 | | +-- high-percentile-g? yang:gauge64 2881 | | +-- peak-g? yang:gauge64 2882 | | +-- current-g? yang:gauge64 2883 | +-- total-attack-connection 2884 | +-- connection-c 2885 | | +-- low-percentile-g? yang:gauge64 2886 | | +-- mid-percentile-g? yang:gauge64 2887 | | +-- high-percentile-g? yang:gauge64 2888 | | +-- peak-g? yang:gauge64 2889 | | +-- current-g? yang:gauge64 2890 | +-- embryonic-c 2891 | | ... 2892 | +-- connection-ps-c 2893 | | ... 2894 | +-- request-ps-c 2895 | | ... 2896 | +-- partial-request-c 2897 | ... 2898 +-- total-attack-traffic* [unit] 2899 | +-- unit unit 2900 | +-- low-percentile-g? yang:gauge64 2901 | +-- mid-percentile-g? yang:gauge64 2902 | +-- high-percentile-g? yang:gauge64 2903 | +-- peak-g? yang:gauge64 2904 | +-- current-g? yang:gauge64 2905 +-- attack-detail* [vendor-id attack-id] 2906 +-- vendor-id uint32 2907 +-- attack-id uint32 2908 +-- attack-description? string 2909 +-- attack-severity? attack-severity 2910 +-- start-time? uint64 2911 +-- end-time? uint64 2912 +-- source-count 2913 | +-- low-percentile-g? yang:gauge64 2914 | +-- mid-percentile-g? yang:gauge64 2915 | +-- high-percentile-g? yang:gauge64 2916 | +-- peak-g? yang:gauge64 2917 | +-- current-g? yang:gauge64 2918 +-- top-talker 2919 +-- talker* [source-prefix] 2920 +-- spoofed-status? boolean 2921 +-- source-prefix inet:ip-prefix 2922 +-- source-port-range* [lower-port] 2923 | +-- lower-port inet:port-number 2924 | +-- upper-port? inet:port-number 2925 +-- source-icmp-type-range* [lower-type] 2926 | +-- lower-type uint8 2927 | +-- upper-type? uint8 2928 +-- total-attack-traffic* [unit] 2929 | +-- unit unit 2930 | +-- low-percentile-g? yang:gauge64 2931 | +-- mid-percentile-g? yang:gauge64 2932 | +-- high-percentile-g? yang:gauge64 2933 | +-- peak-g? yang:gauge64 2934 | +-- current-g? yang:gauge64 2935 +-- total-attack-connection 2936 +-- connection-c 2937 | +-- low-percentile-g? yang:gauge64 2938 | +-- mid-percentile-g? yang:gauge64 2939 | +-- high-percentile-g? yang:gauge64 2940 | +-- peak-g? yang:gauge64 2941 | +-- current-g? yang:gauge64 2942 +-- embryonic-c 2943 | ... 2944 +-- connection-ps-c 2945 | ... 2946 +-- request-ps-c 2947 | ... 2948 +-- partial-request-c 2949 ... 2951 Figure 46: DOTS Servers to Clients Mitigation Status Telemetry 2952 Tree Structure 2954 Figure 47 shows an example of an asynchronous notification of attack 2955 mitigation status from the DOTS server. This notification signals 2956 both the mid-percentile value of processed attack traffic and the 2957 peak count of unique sources involved in the attack. 2959 { 2960 "ietf-dots-signal-channel:mitigation-scope": { 2961 "scope": [ 2962 { 2963 "mid": 12332, 2964 "mitigation-start": "1507818434", 2965 "alias-name": [ 2966 "https1", 2967 "https2" 2968 ], 2969 "lifetime": 1600, 2970 "status": "attack-successfully-mitigated", 2971 "bytes-dropped": "134334555", 2972 "bps-dropped": "43344", 2973 "pkts-dropped": "333334444", 2974 "pps-dropped": "432432", 2975 "ietf-dots-telemetry:total-attack-traffic": [ 2976 { 2977 "unit": "megabit-ps", 2978 "mid-percentile-g": "752" 2979 } 2980 ], 2981 "ietf-dots-telemetry:attack-detail": [ 2982 { 2983 "vendor-id": 32473, 2984 "attack-id": 77, 2985 "source-count": { 2986 "peak-g": "12683" 2987 } 2988 } 2989 ] 2990 } 2991 ] 2992 } 2993 } 2995 Figure 47: Response Body of a Mitigation Status With Telemetry 2996 Attributes 2998 DOTS clients can filter out the asynchronous notifications from the 2999 DOTS server by indicating one or more Uri-Query options in its GET 3000 request. A Uri-Query option can include the following parameters: 3001 'target-prefix', 'target-port', 'target-protocol', 'target-fqdn', 3002 'target-uri', 'alias-name', and 'c' (content) (Section 4.2.4). The 3003 considerations discussed in Section 7.3 MUST be followed to include 3004 multiple query values, ranges ('target-port', 'target-protocol'), and 3005 wildcard names ('target-fqdn', 'target-uri'). 3007 An example of request to subscribe to asynchronous notifications 3008 bound to the "http1" alias is shown in Figure 48. 3010 Header: GET (Code=0.01) 3011 Uri-Path: ".well-known" 3012 Uri-Path: "dots" 3013 Uri-Path: "mitigate" 3014 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 3015 Uri-Path: "mid=12332" 3016 Uri-Query: "target-alias=https1" 3017 Observe: 0 3019 Figure 48: GET Request to Receive Asynchronous Notifications 3020 Filtered using Uri- Query 3022 If the target query does not match the target of the enclosed 'mid' 3023 as maintained by the DOTS server, the latter MUST respond with a 4.04 3024 (Not Found) error Response Code. The DOTS server MUST NOT add a new 3025 observe entry if this query overlaps with an existing one. In such a 3026 case, the DOTS server replies with 4.09 (Conflict). 3028 9. Error Handling 3030 A list of common CoAP errors that are implemented by DOTS servers are 3031 provided in Section 9 of [RFC9132]. The following additional error 3032 cases apply for the telemetry extension: 3034 * 4.00 (Bad Request) is returned by the DOTS server when the DOTS 3035 client has sent a request that violates the DOTS telemetry 3036 extension. 3038 * 4.04 (Not Found) is returned by the DOTS server when the DOTS 3039 client is requesting a 'tsid' or 'tmid' that is not valid. 3041 * 4.00 (Bad Request) is returned by the DOTS server when the DOTS 3042 client has sent a request with invalid query types (e.g., not 3043 supported, malformed). 3045 * 4.04 (Not Found) is returned by the DOTS server when the DOTS 3046 client has sent a request with a target query that does not match 3047 the target of the enclosed 'mid' as maintained by the DOTS server. 3049 10. YANG Modules 3051 10.1. DOTS Signal Channel Telemetry YANG Module 3053 This module uses types defined in [RFC6991] and [RFC8345]. 3055 file "ietf-dots-telemetry@2021-11-29.yang" 3056 module ietf-dots-telemetry { 3057 yang-version 1.1; 3058 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry"; 3059 prefix dots-telemetry; 3061 import ietf-dots-signal-channel { 3062 prefix dots-signal; 3063 reference 3064 "RFC 9132: Distributed Denial-of-Service Open Threat Signaling 3065 (DOTS) Signal Channel Specification"; 3066 } 3067 import ietf-dots-data-channel { 3068 prefix data-channel; 3069 reference 3070 "RFC 8783: Distributed Denial-of-Service Open Threat 3071 Signaling (DOTS) Data Channel Specification"; 3072 } 3073 import ietf-yang-types { 3074 prefix yang; 3075 reference 3076 "Section 3 of RFC 6991"; 3077 } 3078 import ietf-inet-types { 3079 prefix inet; 3080 reference 3081 "Section 4 of RFC 6991"; 3082 } 3083 import ietf-network-topology { 3084 prefix nt; 3085 reference 3086 "Section 6.2 of RFC 8345: A YANG Data Model for Network 3087 Topologies"; 3088 } 3089 import ietf-yang-structure-ext { 3090 prefix sx; 3091 reference 3092 "RFC 8791: YANG Data Structure Extensions"; 3093 } 3095 organization 3096 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 3097 contact 3098 "WG Web: 3099 WG List: 3101 Author: Mohamed Boucadair 3102 3104 Author: Konda, Tirumaleswar Reddy 3105 "; 3106 description 3107 "This module contains YANG definitions for the signaling 3108 of DOTS telemetry data exchanged between a DOTS client and 3109 a DOTS server by means of the DOTS signal channel. 3111 Copyright (c) 2021 IETF Trust and the persons identified as 3112 authors of the code. All rights reserved. 3114 Redistribution and use in source and binary forms, with or 3115 without modification, is permitted pursuant to, and subject 3116 to the license terms contained in, the Simplified BSD License 3117 set forth in Section 4.c of the IETF Trust's Legal Provisions 3118 Relating to IETF Documents 3119 (http://trustee.ietf.org/license-info). 3121 This version of this YANG module is part of RFC XXXX; see 3122 the RFC itself for full legal notices."; 3124 revision 2021-11-29 { 3125 description 3126 "Initial revision."; 3127 reference 3128 "RFC XXXX: Distributed Denial-of-Service Open Threat 3129 Signaling (DOTS) Telemetry"; 3130 } 3132 typedef attack-severity { 3133 type enumeration { 3134 enum none { 3135 value 1; 3136 description 3137 "No effect on the DOTS client domain."; 3138 } 3139 enum low { 3140 value 2; 3141 description 3142 "Minimal effect on the DOTS client domain."; 3143 } 3144 enum medium { 3145 value 3; 3146 description 3147 "A subset of DOTS client domain resources are 3148 out of service."; 3149 } 3150 enum high { 3151 value 4; 3152 description 3153 "The DOTS client domain is under extremly severe 3154 conditions."; 3155 } 3156 enum unknown { 3157 value 5; 3158 description 3159 "The impact of the attack is not known."; 3160 } 3161 } 3162 description 3163 "Enumeration for attack severity."; 3164 reference 3165 "RFC 7970: The Incident Object Description Exchange 3166 Format Version 2, Section 3.12.2"; 3167 } 3169 typedef unit-class { 3170 type enumeration { 3171 enum packet-ps { 3172 value 1; 3173 description 3174 "Packets per second (pps)."; 3175 } 3176 enum bit-ps { 3177 value 2; 3178 description 3179 "Bits per Second (bit/s)."; 3180 } 3181 enum byte-ps { 3182 value 3; 3183 description 3184 "Bytes per second (Byte/s)."; 3185 } 3186 } 3187 description 3188 "Enumeration to indicate which unit class is used. 3189 These classes are supported: pps, bit/s, and Byte/s."; 3190 } 3192 typedef unit { 3193 type enumeration { 3194 enum packet-ps { 3195 value 1; 3196 description 3197 "Packets per second (pps)."; 3198 } 3199 enum bit-ps { 3200 value 2; 3201 description 3202 "Bits per Second (bps)."; 3203 } 3204 enum byte-ps { 3205 value 3; 3206 description 3207 "Bytes per second (Bps)."; 3208 } 3209 enum kilopacket-ps { 3210 value 4; 3211 description 3212 "Kilo packets per second (kpps)."; 3213 } 3214 enum kilobit-ps { 3215 value 5; 3216 description 3217 "Kilobits per second (kbps)."; 3218 } 3219 enum kilobyte-ps { 3220 value 6; 3221 description 3222 "Kilobytes per second (kBps)."; 3223 } 3224 enum megapacket-ps { 3225 value 7; 3226 description 3227 "Mega packets per second (Mpps)."; 3228 } 3229 enum megabit-ps { 3230 value 8; 3231 description 3232 "Megabits per second (Mbps)."; 3233 } 3234 enum megabyte-ps { 3235 value 9; 3236 description 3237 "Megabytes per second (MBps)."; 3238 } 3239 enum gigapacket-ps { 3240 value 10; 3241 description 3242 "Giga packets per second (Gpps)."; 3243 } 3244 enum gigabit-ps { 3245 value 11; 3246 description 3247 "Gigabits per second (Gbps)."; 3248 } 3249 enum gigabyte-ps { 3250 value 12; 3251 description 3252 "Gigabytes per second (GBps)."; 3253 } 3254 enum terapacket-ps { 3255 value 13; 3256 description 3257 "Tera packets per second (Tpps)."; 3258 } 3259 enum terabit-ps { 3260 value 14; 3261 description 3262 "Terabits per second (Tbps)."; 3263 } 3264 enum terabyte-ps { 3265 value 15; 3266 description 3267 "Terabytes per second (TBps)."; 3268 } 3269 enum petapacket-ps { 3270 value 16; 3271 description 3272 "Peta packets per second (Ppps)."; 3273 } 3274 enum petabit-ps { 3275 value 17; 3276 description 3277 "Petabits per second (Pbps)."; 3278 } 3279 enum petabyte-ps { 3280 value 18; 3281 description 3282 "Petabytes per second (PBps)."; 3283 } 3284 enum exapacket-ps { 3285 value 19; 3286 description 3287 "Exa packets per second (Epps)."; 3288 } 3289 enum exabit-ps { 3290 value 20; 3291 description 3292 "Exabits per second (Ebps)."; 3293 } 3294 enum exabyte-ps { 3295 value 21; 3296 description 3297 "Exabytes per second (EBps)."; 3298 } 3299 enum zettapacket-ps { 3300 value 22; 3301 description 3302 "Zetta packets per second (Zpps)."; 3303 } 3304 enum zettabit-ps { 3305 value 23; 3306 description 3307 "Zettabits per second (Zbps)."; 3308 } 3309 enum zettabyte-ps { 3310 value 24; 3311 description 3312 "Zettabytes per second (ZBps)."; 3313 } 3314 } 3315 description 3316 "Enumeration to indicate which unit is used. 3317 Only one unit per unit class is used owing to 3318 unit auto-scaling."; 3319 } 3321 typedef interval { 3322 type enumeration { 3323 enum 5-minutes { 3324 value 1; 3325 description 3326 "5 minutes."; 3327 } 3328 enum 10-minutes { 3329 value 2; 3330 description 3331 "10 minutes."; 3333 } 3334 enum 30-minutes { 3335 value 3; 3336 description 3337 "30 minutes."; 3338 } 3339 enum hour { 3340 value 4; 3341 description 3342 "Hour."; 3343 } 3344 enum day { 3345 value 5; 3346 description 3347 "Day."; 3348 } 3349 enum week { 3350 value 6; 3351 description 3352 "Week."; 3353 } 3354 enum month { 3355 value 7; 3356 description 3357 "Month."; 3358 } 3359 } 3360 description 3361 "Enumeration to indicate the overall measurement period."; 3362 } 3364 typedef sample { 3365 type enumeration { 3366 enum second { 3367 value 1; 3368 description 3369 "A one-second measurement period."; 3370 } 3371 enum 5-seconds { 3372 value 2; 3373 description 3374 "5-second measurement period."; 3375 } 3376 enum 30-seconds { 3377 value 3; 3378 description 3379 "30-second measurement period."; 3380 } 3381 enum minute { 3382 value 4; 3383 description 3384 "One-minute measurement period."; 3385 } 3386 enum 5-minutes { 3387 value 5; 3388 description 3389 "5-minute measurement period."; 3390 } 3391 enum 10-minutes { 3392 value 6; 3393 description 3394 "10-minute measurement period."; 3395 } 3396 enum 30-minutes { 3397 value 7; 3398 description 3399 "30-minute measurement period."; 3400 } 3401 enum hour { 3402 value 8; 3403 description 3404 "One-hour measurement period."; 3405 } 3406 } 3407 description 3408 "Enumeration to indicate the sampling period."; 3409 } 3411 typedef percentile { 3412 type decimal64 { 3413 fraction-digits 2; 3414 } 3415 description 3416 "The nth percentile of a set of data is the 3417 value at which n percent of the data is below it."; 3418 } 3420 typedef query-type { 3421 type enumeration { 3422 enum target-prefix { 3423 value 1; 3424 description 3425 "Query based on target prefix."; 3426 } 3427 enum target-port { 3428 value 2; 3429 description 3430 "Query based on target port number."; 3431 } 3432 enum target-protocol { 3433 value 3; 3434 description 3435 "Query based on target protocol."; 3436 } 3437 enum target-fqdn { 3438 value 4; 3439 description 3440 "Query based on target FQDN."; 3441 } 3442 enum target-uri { 3443 value 5; 3444 description 3445 "Query based on target URI."; 3446 } 3447 enum target-alias { 3448 value 6; 3449 description 3450 "Query based on target alias."; 3451 } 3452 enum mid { 3453 value 7; 3454 description 3455 "Query based on mitigation identifier (mid)."; 3456 } 3457 enum source-prefix { 3458 value 8; 3459 description 3460 "Query based on source prefix."; 3461 } 3462 enum source-port { 3463 value 9; 3464 description 3465 "Query based on source port number."; 3466 } 3467 enum source-icmp-type { 3468 value 10; 3469 description 3470 "Query based on ICMP type"; 3471 } 3472 enum content { 3473 value 11; 3474 description 3475 "Query based on 'c' Uri-Query option that is used 3476 to control the selection of configuration 3477 and non-configuration data nodes."; 3478 reference 3479 "Section 4.4.2 of RFC UUUU."; 3480 } 3481 } 3482 description 3483 "Enumeration of support for query types that can be used 3484 in a GET request to filter out data. Requests with 3485 invalid query types (e.g., not supported, malformed) 3486 received by the DOTS server are rejected with 3487 a 4.00 (Bad Request) response code."; 3488 } 3490 grouping telemetry-parameters { 3491 description 3492 "A grouping that includes a set of parameters that 3493 are used to prepare the reported telemetry data. 3495 The grouping indicates a measurement interval, 3496 a measurement sample period, and low/mid/high 3497 percentile values."; 3498 leaf measurement-interval { 3499 type interval; 3500 description 3501 "Defines the period on which percentiles are computed."; 3502 } 3503 leaf measurement-sample { 3504 type sample; 3505 description 3506 "Defines the time distribution for measuring 3507 values that are used to compute percentiles. 3509 The measurement sample value must be less than the 3510 measurement interval value."; 3511 } 3512 leaf low-percentile { 3513 type percentile; 3514 default "10.00"; 3515 description 3516 "Low percentile. If set to '0', this means low-percentiles 3517 are disabled."; 3518 } 3519 leaf mid-percentile { 3520 type percentile; 3521 must '. >= ../low-percentile' { 3522 error-message 3523 "The mid-percentile must be greater than 3524 or equal to the low-percentile."; 3526 } 3527 default "50.00"; 3528 description 3529 "Mid percentile. If set to the same value as low-percentile, 3530 this means mid-percentiles are disabled."; 3531 } 3532 leaf high-percentile { 3533 type percentile; 3534 must '. >= ../mid-percentile' { 3535 error-message 3536 "The high-percentile must be greater than 3537 or equal to the mid-percentile."; 3538 } 3539 default "90.00"; 3540 description 3541 "High percentile. If set to the same value as mid-percentile, 3542 this means high-percentiles are disabled."; 3543 } 3544 } 3546 grouping percentile-and-peak { 3547 description 3548 "Generic grouping for percentile and peak values."; 3549 leaf low-percentile-g { 3550 type yang:gauge64; 3551 description 3552 "Low percentile value."; 3553 } 3554 leaf mid-percentile-g { 3555 type yang:gauge64; 3556 description 3557 "Mid percentile value."; 3558 } 3559 leaf high-percentile-g { 3560 type yang:gauge64; 3561 description 3562 "High percentile value."; 3563 } 3564 leaf peak-g { 3565 type yang:gauge64; 3566 description 3567 "Peak value."; 3568 } 3569 } 3571 grouping percentile-peak-and-current { 3572 description 3573 "Generic grouping for percentile and peak values."; 3575 uses percentile-and-peak; 3576 leaf current-g { 3577 type yang:gauge64; 3578 description 3579 "Current value."; 3580 } 3581 } 3583 grouping unit-config { 3584 description 3585 "Generic grouping for unit configuration."; 3586 list unit-config { 3587 key "unit"; 3588 description 3589 "Controls which unit classes are allowed when sharing 3590 telemetry data."; 3591 leaf unit { 3592 type unit-class; 3593 description 3594 "Can be packet-ps, bit-ps, or byte-ps."; 3595 } 3596 leaf unit-status { 3597 type boolean; 3598 mandatory true; 3599 description 3600 "Enable/disable the use of the measurement unit class."; 3601 } 3602 } 3603 } 3605 grouping traffic-unit { 3606 description 3607 "Grouping of traffic as a function of the measurement unit."; 3608 leaf unit { 3609 type unit; 3610 description 3611 "The traffic can be measured using unit classes: packet-ps, 3612 bit-ps, or byte-ps. DOTS agents auto-scale to the 3613 appropriate units (e.g., megabit-ps, kilobit-ps)."; 3614 } 3615 uses percentile-and-peak; 3616 } 3618 grouping traffic-unit-all { 3619 description 3620 "Grouping of traffic as a function of the measurement unit, 3621 including current values."; 3622 uses traffic-unit; 3623 leaf current-g { 3624 type yang:gauge64; 3625 description 3626 "Current observed value."; 3627 } 3628 } 3630 grouping traffic-unit-protocol { 3631 description 3632 "Grouping of traffic of a given transport protocol as 3633 a function of the measurement unit."; 3634 leaf protocol { 3635 type uint8; 3636 description 3637 "The transport protocol. 3638 Values are taken from the IANA Protocol Numbers registry: 3639 . 3641 For example, this parameter contains 6 for TCP, 3642 17 for UDP, 33 for DCCP, or 132 for SCTP."; 3643 } 3644 uses traffic-unit; 3645 } 3647 grouping traffic-unit-protocol-all { 3648 description 3649 "Grouping of traffic of a given transport protocol as 3650 a function of the measurement unit, including current 3651 values."; 3652 uses traffic-unit-protocol; 3653 leaf current-g { 3654 type yang:gauge64; 3655 description 3656 "Current observed value."; 3657 } 3658 } 3660 grouping traffic-unit-port { 3661 description 3662 "Grouping of traffic bound to a port number as 3663 a function of the measurement unit."; 3664 leaf port { 3665 type inet:port-number; 3666 description 3667 "Port number used by a transport protocol."; 3668 } 3669 uses traffic-unit; 3670 } 3671 grouping traffic-unit-port-all { 3672 description 3673 "Grouping of traffic bound to a port number as 3674 a function of the measurement unit, including 3675 current values."; 3676 uses traffic-unit-port; 3677 leaf current-g { 3678 type yang:gauge64; 3679 description 3680 "Current observed value."; 3681 } 3682 } 3684 grouping total-connection-capacity { 3685 description 3686 "Total connection capacities for various types of 3687 connections, as well as overall capacity. These data nodes are 3688 useful to detect resource-consuming DDoS attacks."; 3689 leaf connection { 3690 type uint64; 3691 description 3692 "The maximum number of simultaneous connections that 3693 are allowed to the target server."; 3694 } 3695 leaf connection-client { 3696 type uint64; 3697 description 3698 "The maximum number of simultaneous connections that 3699 are allowed to the target server per client."; 3700 } 3701 leaf embryonic { 3702 type uint64; 3703 description 3704 "The maximum number of simultaneous embryonic connections 3705 that are allowed to the target server. The term 'embryonic 3706 connection' refers to a connection whose connection 3707 handshake is not finished. Embryonic connections are only 3708 possible in connection-oriented transport protocols like 3709 TCP or SCTP."; 3710 } 3711 leaf embryonic-client { 3712 type uint64; 3713 description 3714 "The maximum number of simultaneous embryonic connections 3715 that are allowed to the target server per client."; 3716 } 3717 leaf connection-ps { 3718 type uint64; 3719 description 3720 "The maximum number of new connections allowed per second 3721 to the target server."; 3722 } 3723 leaf connection-client-ps { 3724 type uint64; 3725 description 3726 "The maximum number of new connections allowed per second 3727 to the target server per client."; 3728 } 3729 leaf request-ps { 3730 type uint64; 3731 description 3732 "The maximum number of requests allowed per second 3733 to the target server."; 3734 } 3735 leaf request-client-ps { 3736 type uint64; 3737 description 3738 "The maximum number of requests allowed per second 3739 to the target server per client."; 3740 } 3741 leaf partial-request-max { 3742 type uint64; 3743 description 3744 "The maximum number of outstanding partial requests 3745 that are allowed to the target server."; 3746 } 3747 leaf partial-request-client-max { 3748 type uint64; 3749 description 3750 "The maximum number of outstanding partial requests 3751 that are allowed to the target server per client."; 3752 } 3753 } 3755 grouping total-connection-capacity-protocol { 3756 description 3757 "Total connections capacity per protocol. These data nodes are 3758 useful to detect resource consuming DDoS attacks."; 3759 leaf protocol { 3760 type uint8; 3761 description 3762 "The transport protocol. 3763 Values are taken from the IANA Protocol Numbers registry: 3764 ."; 3765 } 3766 uses total-connection-capacity; 3768 } 3770 grouping connection-percentile-and-peak { 3771 description 3772 "A set of data nodes which represent the attack 3773 characteristics."; 3774 container connection-c { 3775 uses percentile-and-peak; 3776 description 3777 "The number of simultaneous attack connections to 3778 the target server."; 3779 } 3780 container embryonic-c { 3781 uses percentile-and-peak; 3782 description 3783 "The number of simultaneous embryonic connections to 3784 the target server."; 3785 } 3786 container connection-ps-c { 3787 uses percentile-and-peak; 3788 description 3789 "The number of attack connections per second to 3790 the target server."; 3791 } 3792 container request-ps-c { 3793 uses percentile-and-peak; 3794 description 3795 "The number of attack requests per second to 3796 the target server."; 3797 } 3798 container partial-request-c { 3799 uses percentile-and-peak; 3800 description 3801 "The number of attack partial requests to 3802 the target server."; 3803 } 3804 } 3806 grouping connection-all { 3807 description 3808 "Total attack connections including current values."; 3809 container connection-c { 3810 uses percentile-peak-and-current; 3811 description 3812 "The number of simultaneous attack connections to 3813 the target server."; 3814 } 3815 container embryonic-c { 3816 uses percentile-peak-and-current; 3817 description 3818 "The number of simultaneous embryonic connections to 3819 the target server."; 3820 } 3821 container connection-ps-c { 3822 uses percentile-peak-and-current; 3823 description 3824 "The number of attack connections per second to 3825 the target server."; 3826 } 3827 container request-ps-c { 3828 uses percentile-peak-and-current; 3829 description 3830 "The number of attack requests per second to 3831 the target server."; 3832 } 3833 container partial-request-c { 3834 uses percentile-peak-and-current; 3835 description 3836 "The number of attack partial requests to 3837 the target server."; 3838 } 3839 } 3841 grouping connection-protocol { 3842 description 3843 "Total attack connections."; 3844 leaf protocol { 3845 type uint8; 3846 description 3847 "The transport protocol. 3848 Values are taken from the IANA Protocol Numbers registry: 3849 ."; 3850 } 3851 uses connection-percentile-and-peak; 3852 } 3854 grouping connection-port { 3855 description 3856 "Total attack connections per port number."; 3857 leaf protocol { 3858 type uint8; 3859 description 3860 "The transport protocol. 3861 Values are taken from the IANA Protocol Numbers registry: 3862 ."; 3863 } 3864 leaf port { 3865 type inet:port-number; 3866 description 3867 "Port number."; 3868 } 3869 uses connection-percentile-and-peak; 3870 } 3872 grouping connection-protocol-all { 3873 description 3874 "Total attack connections per protocol, including current 3875 values."; 3876 leaf protocol { 3877 type uint8; 3878 description 3879 "The transport protocol. 3880 Values are taken from the IANA Protocol Numbers registry: 3881 ."; 3882 } 3883 uses connection-all; 3884 } 3886 grouping connection-protocol-port-all { 3887 description 3888 "Total attack connections per port number, including current 3889 values."; 3890 leaf protocol { 3891 type uint8; 3892 description 3893 "The transport protocol. 3894 Values are taken from the IANA Protocol Numbers registry: 3895 ."; 3896 } 3897 leaf port { 3898 type inet:port-number; 3899 description 3900 "Port number."; 3901 } 3902 uses connection-all; 3903 } 3905 grouping attack-detail { 3906 description 3907 "Various details that describe the on-going 3908 attacks that need to be mitigated by the DOTS server. 3909 The attack details need to cover well-known and common attacks 3910 (such as a SYN Flood) along with new emerging or 3911 vendor-specific attacks."; 3913 leaf vendor-id { 3914 type uint32; 3915 description 3916 "Vendor ID is a security vendor's Enterprise Number as 3917 as registered with IANA."; 3918 reference 3919 "IANA: Private Enterprise Numbers"; 3920 } 3921 leaf attack-id { 3922 type uint32; 3923 description 3924 "Unique identifier assigned by the vendor for the attack."; 3925 } 3926 leaf attack-description { 3927 type string; 3928 description 3929 "Textual representation of attack description. Natural 3930 Language Processing techniques (e.g., word embedding) 3931 might provide some utility in mapping the attack 3932 description to an attack type."; 3933 } 3934 leaf attack-severity { 3935 type attack-severity; 3936 description 3937 "Severity level of an attack. How this level is determined 3938 is implementation-specific."; 3939 } 3940 leaf start-time { 3941 type uint64; 3942 description 3943 "The time the attack started. Start time is represented in 3944 seconds relative to 1970-01-01T00:00:00Z."; 3945 } 3946 leaf end-time { 3947 type uint64; 3948 description 3949 "The time the attack ended. End time is represented in 3950 seconds relative to 1970-01-01T00:00:00Z."; 3951 } 3952 container source-count { 3953 description 3954 "Indicates the count of unique sources involved 3955 in the attack."; 3956 uses percentile-and-peak; 3957 leaf current-g { 3958 type yang:gauge64; 3959 description 3960 "Current observed value."; 3962 } 3963 } 3964 } 3966 grouping talker { 3967 description 3968 "Defines generic data related to top-talkers."; 3969 leaf spoofed-status { 3970 type boolean; 3971 description 3972 "When set to 'true', it indicates whether this address 3973 is spoofed."; 3974 } 3975 leaf source-prefix { 3976 type inet:ip-prefix; 3977 description 3978 "IPv4 or IPv6 prefix identifying the attacker(s)."; 3979 } 3980 list source-port-range { 3981 key "lower-port"; 3982 description 3983 "Port range. When only lower-port is 3984 present, it represents a single port number."; 3985 leaf lower-port { 3986 type inet:port-number; 3987 description 3988 "Lower port number of the port range."; 3989 } 3990 leaf upper-port { 3991 type inet:port-number; 3992 must '. >= ../lower-port' { 3993 error-message 3994 "The upper port number must be greater than 3995 or equal to lower port number."; 3996 } 3997 description 3998 "Upper port number of the port range."; 3999 } 4000 } 4001 list source-icmp-type-range { 4002 key "lower-type"; 4003 description 4004 "ICMP type range. When only lower-type is 4005 present, it represents a single ICMP type."; 4006 leaf lower-type { 4007 type uint8; 4008 description 4009 "Lower ICMP type of the ICMP type range."; 4011 } 4012 leaf upper-type { 4013 type uint8; 4014 must '. >= ../lower-type' { 4015 error-message 4016 "The upper ICMP type must be greater than 4017 or equal to lower ICMP type."; 4018 } 4019 description 4020 "Upper type of the ICMP type range."; 4021 } 4022 } 4023 list total-attack-traffic { 4024 key "unit"; 4025 description 4026 "Total attack traffic issued from this source."; 4027 uses traffic-unit-all; 4028 } 4029 } 4031 grouping top-talker-aggregate { 4032 description 4033 "An aggregate of top attack sources. This aggregate is 4034 typically used when included in a mitigation request."; 4035 list talker { 4036 key "source-prefix"; 4037 description 4038 "Refers to a top-talker that is identified by an IPv4 4039 or IPv6 prefix identifying the attacker(s)."; 4040 uses talker; 4041 container total-attack-connection { 4042 description 4043 "Total attack connections issued from this source."; 4044 uses connection-all; 4045 } 4046 } 4047 } 4049 grouping top-talker { 4050 description 4051 "Top attack sources with detailed per-protocol 4052 structure."; 4053 list talker { 4054 key "source-prefix"; 4055 description 4056 "Refers to a top-talker that is identified by an IPv4 4057 or IPv6 prefix identifying the attacker(s)."; 4058 uses talker; 4059 list total-attack-connection-protocol { 4060 key "protocol"; 4061 description 4062 "Total attack connections issued from this source."; 4063 uses connection-protocol-all; 4064 } 4065 } 4066 } 4068 grouping baseline { 4069 description 4070 "Grouping for the telemetry baseline."; 4071 uses data-channel:target; 4072 leaf-list alias-name { 4073 type string; 4074 description 4075 "An alias name that points to an IP resource. 4076 An IP resource can be be a router, a host, 4077 an IoT object, a server, etc."; 4078 } 4079 list total-traffic-normal { 4080 key "unit"; 4081 description 4082 "Total traffic normal baselines."; 4083 uses traffic-unit; 4084 } 4085 list total-traffic-normal-per-protocol { 4086 key "unit protocol"; 4087 description 4088 "Total traffic normal baselines per protocol."; 4089 uses traffic-unit-protocol; 4090 } 4091 list total-traffic-normal-per-port { 4092 key "unit port"; 4093 description 4094 "Total traffic normal baselines per port number."; 4095 uses traffic-unit-port; 4096 } 4097 list total-connection-capacity { 4098 key "protocol"; 4099 description 4100 "Total connection capacity."; 4101 uses total-connection-capacity-protocol; 4102 } 4103 list total-connection-capacity-per-port { 4104 key "protocol port"; 4105 description 4106 "Total connection capacity per port number."; 4108 leaf port { 4109 type inet:port-number; 4110 description 4111 "The target port number."; 4112 } 4113 uses total-connection-capacity-protocol; 4114 } 4115 } 4117 grouping pre-or-ongoing-mitigation { 4118 description 4119 "Grouping for the telemetry data."; 4120 list total-traffic { 4121 key "unit"; 4122 description 4123 "Total traffic."; 4124 uses traffic-unit-all; 4125 } 4126 list total-traffic-protocol { 4127 key "unit protocol"; 4128 description 4129 "Total traffic per protocol."; 4130 uses traffic-unit-protocol-all; 4131 } 4132 list total-traffic-port { 4133 key "unit port"; 4134 description 4135 "Total traffic per port number."; 4136 uses traffic-unit-port-all; 4137 } 4138 list total-attack-traffic { 4139 key "unit"; 4140 description 4141 "Total attack traffic."; 4142 uses traffic-unit-all; 4143 } 4144 list total-attack-traffic-protocol { 4145 key "unit protocol"; 4146 description 4147 "Total attack traffic per protocol."; 4148 uses traffic-unit-protocol-all; 4149 } 4150 list total-attack-traffic-port { 4151 key "unit port"; 4152 description 4153 "Total attack traffic per port number."; 4154 uses traffic-unit-port-all; 4155 } 4156 list total-attack-connection-protocol { 4157 key "protocol"; 4158 description 4159 "Total attack connections."; 4160 uses connection-protocol-all; 4161 } 4162 list total-attack-connection-port { 4163 key "protocol port"; 4164 description 4165 "Total attack connections per target port number."; 4166 uses connection-protocol-port-all; 4167 } 4168 list attack-detail { 4169 key "vendor-id attack-id"; 4170 description 4171 "Provides a set of attack details."; 4172 uses attack-detail; 4173 container top-talker { 4174 description 4175 "Lists the top attack sources."; 4176 uses top-talker; 4177 } 4178 } 4179 } 4181 sx:augment-structure "/dots-signal:dots-signal" 4182 + "/dots-signal:message-type" 4183 + "/dots-signal:mitigation-scope" 4184 + "/dots-signal:scope" { 4185 description 4186 "Extends mitigation scope with telemetry update data."; 4187 choice direction { 4188 description 4189 "Indicates the communication direction in which the 4190 data nodes can be included."; 4191 case server-to-client-only { 4192 description 4193 "These data nodes appear only in a mitigation message 4194 sent from the server to the client."; 4195 list total-traffic { 4196 key "unit"; 4197 description 4198 "Total traffic."; 4199 uses traffic-unit-all; 4200 } 4201 container total-attack-connection { 4202 description 4203 "Total attack connections."; 4205 uses connection-all; 4206 } 4207 } 4208 } 4209 list total-attack-traffic { 4210 key "unit"; 4211 description 4212 "Total attack traffic."; 4213 uses traffic-unit-all; 4214 } 4215 list attack-detail { 4216 key "vendor-id attack-id"; 4217 description 4218 "Attack details"; 4219 uses attack-detail; 4220 container top-talker { 4221 description 4222 "Top attack sources."; 4223 uses top-talker-aggregate; 4224 } 4225 } 4226 } 4227 sx:structure dots-telemetry { 4228 description 4229 "Main structure for DOTS telemetry messages."; 4230 choice telemetry-message-type { 4231 description 4232 "Can be a telemetry-setup or telemetry data."; 4233 case telemetry-setup { 4234 description 4235 "Indicates the message is about telemetry steup."; 4236 choice direction { 4237 description 4238 "Indicates the communication direction in which the 4239 data nodes can be included."; 4240 case server-to-client-only { 4241 description 4242 "These data nodes appear only in a mitigation message 4243 sent from the server to the client."; 4244 container max-config-values { 4245 description 4246 "Maximum acceptable configuration values."; 4247 uses telemetry-parameters; 4248 leaf server-originated-telemetry { 4249 type boolean; 4250 default "false"; 4251 description 4252 "Indicates whether the DOTS server can be 4253 instructed to send pre-or-ongoing-mitigation 4254 telemetry. If set to 'false' or the data node 4255 is not present, this is an indication that 4256 the server does not support this capability."; 4257 } 4258 leaf telemetry-notify-interval { 4259 type uint16 { 4260 range "1 .. 3600"; 4261 } 4262 units "seconds"; 4263 must '. >= ../../min-config-values' 4264 + '/telemetry-notify-interval' { 4265 error-message 4266 "The value must be greater than or equal 4267 to the telemetry-notify-interval in the 4268 min-config-values"; 4269 } 4270 description 4271 "Minimum number of seconds between successive 4272 telemetry notifications."; 4273 } 4274 } 4275 container min-config-values { 4276 description 4277 "Minimum acceptable configuration values."; 4278 uses telemetry-parameters; 4279 leaf telemetry-notify-interval { 4280 type uint16 { 4281 range "1 .. 3600"; 4282 } 4283 units "seconds"; 4284 description 4285 "Minimum number of seconds between successive 4286 telemetry notifications."; 4287 } 4288 } 4289 container supported-unit-classes { 4290 description 4291 "Supported unit classes and default activation 4292 status."; 4293 uses unit-config; 4294 } 4295 leaf-list supported-query-type { 4296 type query-type; 4297 description 4298 "Indicates which query types are supported by 4299 the server. If the server does not announce 4300 the query types it supports, the client will 4301 be unable to use any of the potential 4302 query-type values to reduce the returned data 4303 content from the server."; 4304 } 4305 } 4306 } 4307 list telemetry { 4308 description 4309 "The telemetry data per DOTS client. The keys 4310 of the list are 'cuid' and 'tsid', but these keys are 4311 not represented here because these keys are conveyed 4312 as mandatory Uri-Paths in requests. Omitting keys 4313 is compliant with RFC8791."; 4314 choice direction { 4315 description 4316 "Indicates the communication direction in which the 4317 data nodes can be included."; 4318 case server-to-client-only { 4319 description 4320 "These data nodes appear only in a mitigation message 4321 sent from the server to the client."; 4322 leaf tsid { 4323 type uint32; 4324 description 4325 "A client-assigned identifier for the DOTS 4326 telemetry setup data."; 4327 } 4328 } 4329 } 4330 choice setup-type { 4331 description 4332 "Can be a mitigation configuration, a pipe capacity, 4333 or baseline message."; 4334 case telemetry-config { 4335 description 4336 "Used to set telemetry parameters such as setting 4337 low, mid, and high percentile values."; 4338 container current-config { 4339 description 4340 "Current telemetry configuration values."; 4341 uses telemetry-parameters; 4342 uses unit-config; 4343 leaf server-originated-telemetry { 4344 type boolean; 4345 description 4346 "Used by a DOTS client to enable/disable whether 4347 it requests pre-or-ongoing-mitigation telemetry 4348 from the DOTS server."; 4350 } 4351 leaf telemetry-notify-interval { 4352 type uint16 { 4353 range "1 .. 3600"; 4354 } 4355 units "seconds"; 4356 description 4357 "Minimum number of seconds between successive 4358 telemetry notifications."; 4359 } 4360 } 4361 } 4362 case pipe { 4363 description 4364 "Total pipe capacity of a DOTS client domain."; 4365 list total-pipe-capacity { 4366 key "link-id unit"; 4367 description 4368 "Total pipe capacity of a DOTS client domain."; 4369 leaf link-id { 4370 type nt:link-id; 4371 description 4372 "Identifier of an interconnection link of 4373 the DOTS client domain."; 4374 } 4375 leaf capacity { 4376 type uint64; 4377 mandatory true; 4378 description 4379 "Pipe capacity. This attribute is mandatory when 4380 total-pipe-capacity is included in a message."; 4381 } 4382 leaf unit { 4383 type unit; 4384 description 4385 "The traffic can be measured using unit classes: 4386 packets per second (pps), bits per second 4387 (bit/s), and/or bytes per second (Byte/s). 4389 For a given unit class, the DOTS agents 4390 auto-scales to the appropriate units (e.g., 4391 megabit-ps, kilobit-ps)."; 4392 } 4393 } 4394 } 4395 case baseline { 4396 description 4397 "Traffic baseline information of a DOTS client 4398 domain."; 4399 list baseline { 4400 key "id"; 4401 description 4402 "Traffic baseline information of a DOTS client 4403 domain."; 4404 leaf id { 4405 type uint32; 4406 must '. >= 1'; 4407 description 4408 "An identifier that uniquely identifies a 4409 baseline entry communicated by a DOTS client."; 4410 } 4411 uses baseline; 4412 } 4413 } 4414 } 4415 } 4416 } 4417 case telemetry { 4418 description 4419 "Telemetry information."; 4420 list pre-or-ongoing-mitigation { 4421 description 4422 "Pre-or-ongoing-mitigation telemetry per DOTS client. 4423 The keys of the list are 'cuid' and 'tmid', but these 4424 keys are not represented here because these keys are 4425 conveyed as mandatory Uri-Paths in requests. 4426 Omitting keys is compliant with RFC8791."; 4427 choice direction { 4428 description 4429 "Indicates the communication direction in which the 4430 data nodes can be included."; 4431 case server-to-client-only { 4432 description 4433 "These data nodes appear only in a mitigation message 4434 sent from the server to the client."; 4435 leaf tmid { 4436 type uint32; 4437 description 4438 "A client-assigned identifier for the DOTS 4439 telemetry data."; 4440 } 4441 } 4442 } 4443 container target { 4444 description 4445 "Indicates the target. At least one of the attributes 4446 'target-prefix', 'target-fqdn', 'target-uri', 4447 'alias-name', or 'mid-list' must be present in the 4448 target definition."; 4449 uses data-channel:target; 4450 leaf-list alias-name { 4451 type string; 4452 description 4453 "An alias name that points to a resource."; 4454 } 4455 leaf-list mid-list { 4456 type uint32; 4457 description 4458 "Reference a list of associated mitigation 4459 requests."; 4460 reference 4461 "RFC 9132: Distributed Denial-of-Service Open Threat 4462 Signaling (DOTS) Signal Channel 4463 Specification, Section 4.4.1"; 4464 } 4465 } 4466 uses pre-or-ongoing-mitigation; 4467 } 4468 } 4469 } 4470 } 4471 } 4472 4474 10.2. Vendor Attack Mapping Details YANG Module 4476 file "ietf-dots-mapping@2020-06-26.yang" 4477 module ietf-dots-mapping { 4478 yang-version 1.1; 4479 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-mapping"; 4480 prefix dots-mapping; 4482 import ietf-dots-data-channel { 4483 prefix data-channel; 4484 reference 4485 "RFC 8783: Distributed Denial-of-Service Open Threat 4486 Signaling (DOTS) Data Channel Specification"; 4487 } 4489 organization 4490 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 4491 contact 4492 "WG Web: 4493 WG List: 4494 Author: Mohamed Boucadair 4495 4497 Author: Jon Shallow 4498 "; 4499 description 4500 "This module contains YANG definitions for the sharing 4501 DDoS attack mapping details between a DOTS client and 4502 a DOTS server, by means of the DOTS data channel. 4504 Copyright (c) 2021 IETF Trust and the persons identified as 4505 authors of the code. All rights reserved. 4507 Redistribution and use in source and binary forms, with or 4508 without modification, is permitted pursuant to, and subject 4509 to the license terms contained in, the Simplified BSD License 4510 set forth in Section 4.c of the IETF Trust's Legal Provisions 4511 Relating to IETF Documents 4512 (http://trustee.ietf.org/license-info). 4514 This version of this YANG module is part of RFC XXXX; see 4515 the RFC itself for full legal notices."; 4517 revision 2020-06-26 { 4518 description 4519 "Initial revision."; 4520 reference 4521 "RFC XXXX: Distributed Denial-of-Service Open Threat 4522 Signaling (DOTS) Telemetry"; 4523 } 4525 feature dots-telemetry { 4526 description 4527 "This feature indicates that DOTS telemetry data can be 4528 shared between DOTS clients and servers."; 4529 } 4531 grouping attack-mapping { 4532 description 4533 "A set of information used for sharing vendor attack mapping 4534 information with a peer."; 4535 list vendor { 4536 key "vendor-id"; 4537 description 4538 "Vendor attack mapping information of the client/server"; 4539 leaf vendor-id { 4540 type uint32; 4541 description 4542 "Vendor ID is a security vendor's Enterprise Number as 4543 registered with IANA."; 4544 reference 4545 "IANA: Private Enterprise Numbers"; 4546 } 4547 leaf vendor-name { 4548 type string; 4549 description 4550 "The name of the vendor (e.g., company A)."; 4551 } 4552 leaf last-updated { 4553 type uint64; 4554 mandatory true; 4555 description 4556 "The time the mapping table was updated. It is represented 4557 in seconds relative to 1970-01-01T00:00:00Z."; 4558 } 4559 list attack-mapping { 4560 key "attack-id"; 4561 description 4562 "Attack mapping details."; 4563 leaf attack-id { 4564 type uint32; 4565 description 4566 "Unique identifier assigned by the vendor for the 4567 attack."; 4568 } 4569 leaf attack-description { 4570 type string; 4571 mandatory true; 4572 description 4573 "Textual representation of attack description. Natural 4574 Language Processing techniques (e.g., word embedding) 4575 might provide some utility in mapping the attack 4576 description to an attack type."; 4577 } 4578 } 4579 } 4580 } 4582 augment "/data-channel:dots-data/data-channel:dots-client" { 4583 if-feature "dots-telemetry"; 4584 description 4585 "Augments the data channel with a vendor attack 4586 mapping table of the DOTS client."; 4587 container vendor-mapping { 4588 description 4589 "Used by DOTS clients to share their vendor 4590 attack mapping information with DOTS servers."; 4591 uses attack-mapping; 4592 } 4593 } 4595 augment "/data-channel:dots-data/data-channel:capabilities" { 4596 if-feature "dots-telemetry"; 4597 description 4598 "Augments the DOTS server capabilities with a 4599 parameter to indicate whether they can share 4600 attack mapping details."; 4601 leaf vendor-mapping-enabled { 4602 type boolean; 4603 config false; 4604 description 4605 "Indicates that the DOTS server supports sharing 4606 attack vendor mapping details with DOTS clients."; 4607 } 4608 } 4610 augment "/data-channel:dots-data" { 4611 if-feature "dots-telemetry"; 4612 description 4613 "Augments the data channel with a vendor attack 4614 mapping table of the DOTS server."; 4615 container vendor-mapping { 4616 config false; 4617 description 4618 "Includes the list of vendor attack mapping details 4619 that will be shared upon request with DOTS clients."; 4620 uses attack-mapping; 4621 } 4622 } 4623 } 4624 4626 11. YANG/JSON Mapping Parameters to CBOR 4628 All DOTS telemetry parameters in the payload of the DOTS signal 4629 channel MUST be mapped to CBOR types as shown in Table 2: 4631 * Note: Implementers must check that the mapping output provided by 4632 their YANG-to-CBOR encoding schemes is aligned with the content of 4633 Table 2. 4635 +----------------------+-------------+------+---------------+--------+ 4636 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 4637 | | Type | Key | Type & | Type | 4638 | | | | Information | | 4639 +======================+=============+======+===============+========+ 4640 | tsid | uint32 |TBA1 | 0 unsigned | Number | 4641 | telemetry | list |TBA2 | 4 array | Array | 4642 | low-percentile | decimal64 |TBA3 | 6 tag 4 | | 4643 | | | | [-2, integer]| String | 4644 | mid-percentile | decimal64 |TBA4 | 6 tag 4 | | 4645 | | | | [-2, integer]| String | 4646 | high-percentile | decimal64 |TBA5 | 6 tag 4 | | 4647 | | | | [-2, integer]| String | 4648 | unit-config | list |TBA6 | 4 array | Array | 4649 | unit | enumeration |TBA7 | 0 unsigned | String | 4650 | unit-status | boolean |TBA8 | 7 bits 20 | False | 4651 | | | | 7 bits 21 | True | 4652 | total-pipe-capacity | list |TBA9 | 4 array | Array | 4653 | link-id | string |TBA10 | 3 text string | String | 4654 | pre-or-ongoing- | list |TBA11 | 4 array | Array | 4655 | mitigation | | | | | 4656 | total-traffic-normal | list |TBA12 | 4 array | Array | 4657 | low-percentile-g | yang:gauge64|TBA13 | 0 unsigned | String | 4658 | mid-percentile-g | yang:gauge64|TBA14 | 0 unsigned | String | 4659 | high-percentile-g | yang:gauge64|TBA15 | 0 unsigned | String | 4660 | peak-g | yang:gauge64|TBA16 | 0 unsigned | String | 4661 | total-attack-traffic | list |TBA17 | 4 array | Array | 4662 | total-traffic | list |TBA18 | 4 array | Array | 4663 | total-connection- | | | | | 4664 | capacity | list |TBA19 | 4 array | Array | 4665 | connection | uint64 |TBA20 | 0 unsigned | String | 4666 | connection-client | uint64 |TBA21 | 0 unsigned | String | 4667 | embryonic | uint64 |TBA22 | 0 unsigned | String | 4668 | embryonic-client | uint64 |TBA23 | 0 unsigned | String | 4669 | connection-ps | uint64 |TBA24 | 0 unsigned | String | 4670 | connection-client-ps | uint64 |TBA25 | 0 unsigned | String | 4671 | request-ps | uint64 |TBA26 | 0 unsigned | String | 4672 | request-client-ps | uint64 |TBA27 | 0 unsigned | String | 4673 | partial-request-max | uint64 |TBA28 | 0 unsigned | String | 4674 | partial-request- | | | | | 4675 | client-max | uint64 |TBA29 | 0 unsigned | String | 4676 | total-attack- | | | | | 4677 | connection | container |TBA30 | 5 map | Object | 4678 | connection-c | container |TBA31 | 5 map | Object | 4679 | embryonic-c | container |TBA32 | 5 map | Object | 4680 | connection-ps-c | container |TBA33 | 5 map | Object | 4681 | request-ps-c | container |TBA34 | 5 map | Object | 4682 | attack-detail | list |TBA35 | 4 array | Array | 4683 | id | uint32 |TBA36 | 0 unsigned | Number | 4684 | attack-id | uint32 |TBA37 | 0 unsigned | Number | 4685 | attack-description | string |TBA38 | 3 text string | String | 4686 | attack-severity | enumeration |TBA39 | 0 unsigned | String | 4687 | start-time | uint64 |TBA40 | 0 unsigned | String | 4688 | end-time | uint64 |TBA41 | 0 unsigned | String | 4689 | source-count | container |TBA42 | 5 map | Object | 4690 | top-talker | container |TBA43 | 5 map | Object | 4691 | spoofed-status | boolean |TBA44 | 7 bits 20 | False | 4692 | | | | 7 bits 21 | True | 4693 | partial-request-c | container |TBA45 | 5 map | Object | 4694 | total-attack- | | | | | 4695 | connection-protocol | list |TBA46 | 4 array | Array | 4696 | baseline | list |TBA49 | 4 array | Array | 4697 | current-config | container |TBA50 | 5 map | Object | 4698 | max-config-values | container |TBA51 | 5 map | Object | 4699 | min-config-values | container |TBA52 | 5 map | Object | 4700 |supported-unit-classes| container |TBA53 | 5 map | Object | 4701 | server-originated- | boolean |TBA54 | 7 bits 20 | False | 4702 | telemetry | | | 7 bits 21 | True | 4703 | telemetry-notify- | uint16 |TBA55 | 0 unsigned | Number | 4704 | interval | | | | | 4705 | tmid | uint32 |TBA56 | 0 unsigned | Number | 4706 | measurement-interval | enumeration |TBA57 | 0 unsigned | String | 4707 | measurement-sample | enumeration |TBA58 | 0 unsigned | String | 4708 | talker | list |TBA59 | 4 array | Array | 4709 | source-prefix | inet: |TBA60 | 3 text string | String | 4710 | | ip-prefix | | | | 4711 | mid-list | leaf-list |TBA61 | 4 array | Array | 4712 | | uint32 | | 0 unsigned | Number | 4713 | source-port-range | list |TBA62 | 4 array | Array | 4714 | source-icmp-type- | list |TBA63 | 4 array | Array | 4715 | range | | | | | 4716 | target | container |TBA64 | 5 map | Object | 4717 | capacity | uint64 |TBA65 | 0 unsigned | String | 4718 | protocol | uint8 |TBA66 | 0 unsigned | Number | 4719 | total-traffic- | | | | | 4720 | normal-per-protocol | list |TBA67 | 4 array | Array | 4721 | total-traffic- | | | | | 4722 | normal-per-port | list |TBA68 | 4 array | Array | 4723 | total-connection- | | | | | 4724 | capacity-per-port | list |TBA69 | 4 array | Array | 4725 | total-traffic- | | | | | 4726 | protocol | list |TBA70 | 4 array | Array | 4727 | total-traffic-port | list |TBA71 | 4 array | Array | 4728 | total-attack- | | | | | 4729 | traffic-protocol | list |TBA72 | 4 array | Array | 4730 | total-attack- | | | | | 4731 | traffic-port | list |TBA73 | 4 array | Array | 4732 | total-attack- | | | | | 4733 | connection-port | list |TBA74 | 4 array | Array | 4734 | port | inet: | | | | 4735 | | port-number|TBA75 | 0 unsigned | Number | 4736 | supported-query-type | leaf-list |TBA76 | 4 array | Array | 4737 | | | | 0 unsigned | String | 4738 | vendor-id | uint32 |TBA77 | 0 unsigned | Number | 4739 | ietf-dots-telemetry: | | | | | 4740 | telemetry-setup | container |TBA78 | 5 map | Object | 4741 | ietf-dots-telemetry: | | | | | 4742 | total-traffic | list |TBA79 | 4 array | Array | 4743 | ietf-dots-telemetry: | | | | | 4744 | total-attack-traffic | list |TBA80 | 4 array | Array | 4745 | ietf-dots-telemetry: | | | | | 4746 | total-attack- | | | | | 4747 | connection | container |TBA81 | 5 map | Object | 4748 | ietf-dots-telemetry: | | | | | 4749 | attack-detail | list |TBA82 | 4 array | Array | 4750 | ietf-dots-telemetry: | | | | | 4751 | telemetry | container |TBA83 | 5 map | Object | 4752 | current-g | yang:gauge64|TBA84 | 0 unsigned | String | 4753 | lower-type | uint8 |32771 | 0 unsigned | Number | 4754 | upper-type | uint8 |32772 | 0 unsigned | Number | 4755 +----------------------+-------------+------+---------------+--------+ 4757 Table 2: YANG/JSON Mapping Parameters to CBOR 4759 12. IANA Considerations 4761 12.1. DOTS Signal Channel CBOR Key Values 4763 This specification registers the DOTS telemetry attributes in the 4764 IANA "DOTS Signal Channel CBOR Key Values" registry [Key-Map]. 4766 The DOTS telemetry attributes defined in this specification are 4767 comprehension-optional parameters. 4769 * Note to the RFC Editor: CBOR keys are assigned from the "128-255" 4770 range. This specification meets the requirements listed in 4771 Section 3.1 [RFC9132] for assignments in the "128-255" range. 4773 +----------------------+-------+-------+------------+---------------+ 4774 | Parameter Name | CBOR | CBOR | Change | Specification | 4775 | | Key | Major | Controller | Document(s) | 4776 | | Value | Type | | | 4777 +======================+=======+=======+============+===============+ 4778 | tsid | TBA1 | 0 | IESG | [RFCXXXX] | 4779 | telemetry | TBA2 | 4 | IESG | [RFCXXXX] | 4780 | low-percentile | TBA3 | 6tag4 | IESG | [RFCXXXX] | 4781 | mid-percentile | TBA4 | 6tag4 | IESG | [RFCXXXX] | 4782 | high-percentile | TBA5 | 6tag4 | IESG | [RFCXXXX] | 4783 | unit-config | TBA6 | 4 | IESG | [RFCXXXX] | 4784 | unit | TBA7 | 0 | IESG | [RFCXXXX] | 4785 | unit-status | TBA8 | 7 | IESG | [RFCXXXX] | 4786 | total-pipe-capacity | TBA9 | 4 | IESG | [RFCXXXX] | 4787 | link-id | TBA10 | 3 | IESG | [RFCXXXX] | 4788 | pre-or-ongoing- | TBA11 | 4 | IESG | [RFCXXXX] | 4789 | mitigation | | | | | 4790 | total-traffic-normal | TBA12 | 4 | IESG | [RFCXXXX] | 4791 | low-percentile-g | TBA13 | 0 | IESG | [RFCXXXX] | 4792 | mid-percentile-g | TBA14 | 0 | IESG | [RFCXXXX] | 4793 | high-percentile-g | TBA15 | 0 | IESG | [RFCXXXX] | 4794 | peak-g | TBA16 | 0 | IESG | [RFCXXXX] | 4795 | total-attack-traffic | TBA17 | 4 | IESG | [RFCXXXX] | 4796 | total-traffic | TBA18 | 4 | IESG | [RFCXXXX] | 4797 | total-connection- | TBA19 | 4 | IESG | [RFCXXXX] | 4798 | capacity | | | | | 4799 | connection | TBA20 | 0 | IESG | [RFCXXXX] | 4800 | connection-client | TBA21 | 0 | IESG | [RFCXXXX] | 4801 | embryonic | TBA22 | 0 | IESG | [RFCXXXX] | 4802 | embryonic-client | TBA23 | 0 | IESG | [RFCXXXX] | 4803 | connection-ps | TBA24 | 0 | IESG | [RFCXXXX] | 4804 | connection-client-ps | TBA25 | 0 | IESG | [RFCXXXX] | 4805 | request-ps | TBA26 | 0 | IESG | [RFCXXXX] | 4806 | request-client-ps | TBA27 | 0 | IESG | [RFCXXXX] | 4807 | partial-request-max | TBA28 | 0 | IESG | [RFCXXXX] | 4808 | partial-request- | TBA29 | 0 | IESG | [RFCXXXX] | 4809 | client-max | | | | | 4810 | total-attack- | TBA30 | 5 | IESG | [RFCXXXX] | 4811 | connection | | | | | 4812 | connection-c | TBA31 | 5 | IESG | [RFCXXXX] | 4813 | embryonic-c | TBA32 | 5 | IESG | [RFCXXXX] | 4814 | connection-ps-c | TBA33 | 5 | IESG | [RFCXXXX] | 4815 | request-ps-c | TBA34 | 5 | IESG | [RFCXXXX] | 4816 | attack-detail | TBA35 | 4 | IESG | [RFCXXXX] | 4817 | id | TBA36 | 0 | IESG | [RFCXXXX] | 4818 | attack-id | TBA37 | 0 | IESG | [RFCXXXX] | 4819 | attack-description | TBA38 | 3 | IESG | [RFCXXXX] | 4820 | attack-severity | TBA39 | 0 | IESG | [RFCXXXX] | 4821 | start-time | TBA40 | 0 | IESG | [RFCXXXX] | 4822 | end-time | TBA41 | 0 | IESG | [RFCXXXX] | 4823 | source-count | TBA42 | 5 | IESG | [RFCXXXX] | 4824 | top-talker | TBA43 | 5 | IESG | [RFCXXXX] | 4825 | spoofed-status | TBA44 | 7 | IESG | [RFCXXXX] | 4826 | partial-request-c | TBA45 | 5 | IESG | [RFCXXXX] | 4827 | total-attack- | TBA46 | 4 | IESG | [RFCXXXX] | 4828 | connection-protocol | | | | | 4829 | baseline | TBA49 | 4 | IESG | [RFCXXXX] | 4830 | current-config | TBA50 | 5 | IESG | [RFCXXXX] | 4831 | max-config-value | TBA51 | 5 | IESG | [RFCXXXX] | 4832 | min-config-values | TBA52 | 5 | IESG | [RFCXXXX] | 4833 |supported-unit-classes| TBA53 | 5 | IESG | [RFCXXXX] | 4834 | server-originated- | TBA54 | 7 | IESG | [RFCXXXX] | 4835 | telemetry | | | | | 4836 | telemetry-notify- | TBA55 | 0 | IESG | [RFCXXXX] | 4837 | interval | | | | | 4838 | tmid | TBA56 | 0 | IESG | [RFCXXXX] | 4839 | measurement-interval | TBA57 | 0 | IESG | [RFCXXXX] | 4840 | measurement-sample | TBA58 | 0 | IESG | [RFCXXXX] | 4841 | talker | TBA59 | 4 | IESG | [RFCXXXX] | 4842 | source-prefix | TBA60 | 3 | IESG | [RFCXXXX] | 4843 | mid-list | TBA61 | 4 | IESG | [RFCXXXX] | 4844 | source-port-range | TBA62 | 4 | IESG | [RFCXXXX] | 4845 | source-icmp-type- | TBA63 | 4 | IESG | [RFCXXXX] | 4846 | range | | | | | 4847 | target | TBA64 | 5 | IESG | [RFCXXXX] | 4848 | capacity | TBA65 | 0 | IESG | [RFCXXXX] | 4849 | protocol | TBA66 | 0 | IESG | [RFCXXXX] | 4850 | total-traffic- | TBA67 | 4 | IESG | [RFCXXXX] | 4851 | normal-per-protocol | | | | | 4852 | total-traffic- | TBA68 | 4 | IESG | [RFCXXXX] | 4853 | normal-per-port | | | | | 4854 | total-connection- | TBA69 | 4 | IESG | [RFCXXXX] | 4855 | capacity-per-port | | | | | 4856 | total-traffic- | TBA70 | 4 | IESG | [RFCXXXX] | 4857 | protocol | | | | | 4858 | total-traffic-port | TBA71 | 4 | IESG | [RFCXXXX] | 4859 | total-attack- | TBA72 | 4 | IESG | [RFCXXXX] | 4860 | traffic-protocol | | | | | 4861 | total-attack- | TBA73 | 4 | IESG | [RFCXXXX] | 4862 | traffic-port | | | | | 4863 | total-attack- | TBA74 | 4 | IESG | [RFCXXXX] | 4864 | connection-port | | | | | 4865 | port | TBA75 | 0 | IESG | [RFCXXXX] | 4866 | supported-query-type | TBA76 | 4 | IESG | [RFCXXXX] | 4867 | vendor-id | TBA77 | 0 | IESG | [RFCXXXX] | 4868 | ietf-dots-telemetry: | TBA78 | 5 | IESG | [RFCXXXX] | 4869 | telemetry-setup | | | | | 4870 | ietf-dots-telemetry: | TBA79 | 4 | IESG | [RFCXXXX] | 4871 | total-traffic | | | | | 4872 | ietf-dots-telemetry: | TBA80 | 4 | IESG | [RFCXXXX] | 4873 | total-attack-traffic | | | | | 4874 | ietf-dots-telemetry: | TBA81 | 5 | IESG | [RFCXXXX] | 4875 | total-attack- | | | | | 4876 | connection | | | | | 4877 | ietf-dots-telemetry: | TBA82 | 4 | IESG | [RFCXXXX] | 4878 | attack-detail | | | | | 4879 | ietf-dots-telemetry: | TBA83 | 5 | IESG | [RFCXXXX] | 4880 | telemetry | | | | | 4881 | current-g | TBA84 | 0 | IESG | [RFCXXXX] | 4882 +----------------------+-------+-------+------------+---------------+ 4884 Table 3: Registered DOTS Signal Channel CBOR Key Values 4886 12.2. DOTS Signal Channel Conflict Cause Codes 4888 This specification requests IANA to assign a new code from the "DOTS 4889 Signal Channel Conflict Cause Codes" registry [Cause]. 4891 +------+-------------------+------------------------+-------------+ 4892 | Code | Label | Description | Reference | 4893 +======+===================+========================+=============+ 4894 | TBA | overlapping-pipes | Overlapping pipe scope | [RFCXXXX] | 4895 +------+-------------------+------------------------+-------------+ 4897 Table 4: Registered DOTS Signal Channel Conflict Cause Code 4899 12.3. DOTS Signal Telemetry YANG Module 4901 This document requests IANA to register the following URIs in the 4902 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 4904 URI: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry 4905 Registrant Contact: The IESG. 4906 XML: N/A; the requested URI is an XML namespace. 4908 URI: urn:ietf:params:xml:ns:yang:ietf-dots-mapping 4909 Registrant Contact: The IESG. 4910 XML: N/A; the requested URI is an XML namespace. 4912 This document requests IANA to register the following YANG modules in 4913 the "YANG Module Names" subregistry [RFC6020] within the "YANG 4914 Parameters" registry. 4916 name: ietf-dots-telemetry 4917 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry 4918 maintained by IANA: N 4919 prefix: dots-telemetry 4920 reference: RFC XXXX 4922 name: ietf-dots-mapping 4923 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-mapping 4924 maintained by IANA: N 4925 prefix: dots-mapping 4926 reference: RFC XXXX 4928 13. Security Considerations 4930 13.1. DOTS Signal Channel Telemetry 4932 The security considerations for the DOTS signal channel protocol are 4933 discussed in Section 11 of [RFC9132]. The following discusses the 4934 security considerations that are specific to the DOTS signal channel 4935 extension defined in this document. 4937 The DOTS telemetry information includes DOTS client network topology, 4938 DOTS client domain pipe capacity, normal traffic baseline and 4939 connections capacity, and threat and mitigation information. Such 4940 information is sensitive; it MUST be protected at rest by the DOTS 4941 server domain to prevent data leakage. Note that sharing this 4942 sensitive data with a trusted DOTS server does not introduce any new 4943 significant considerations other that the need for the aforementioned 4944 protection. Such a DOTS server is already trusted to have access to 4945 that kind of information by being in the position to observe and 4946 mitigate attacks. 4948 DOTS clients are typically considered to be trusted devices by the 4949 DOTS client domain. DOTS clients may be co-located on network 4950 security services (e.g., firewall devices), and a compromised 4951 security service potentially can do a lot more damage to the network 4952 than just the DOTS client component. This assumption differs from 4953 the often held view that devices are untrusted, often referred to as 4954 the "zero-trust model". A compromised DOTS client can send fake DOTS 4955 telemetry data to a DOTS server to mislead the DOTS server. This 4956 attack can be prevented by monitoring and auditing DOTS clients to 4957 detect misbehavior and to deter misuse, and by only authorizing the 4958 DOTS client to convey DOTS telemetry information for specific target 4959 resources (e.g., an application server is authorized to exchange DOTS 4960 telemetry for its IP addresses but a DDoS mitigator can exchange DOTS 4961 telemetry for any target resource in the network). As a reminder, 4962 this is a variation of dealing with compromised DOTS clients as 4963 discussed in Section 11 of [RFC9132]. 4965 DOTS servers must be capable of defending themselves against DoS 4966 attacks from compromised DOTS clients. The following non- 4967 comprehensive list of mitigation techniques can be used by a DOTS 4968 server to handle misbehaving DOTS clients: 4970 * The probing rate (defined in Section 4.5 of [RFC9132]) can be used 4971 to limit the average data rate to the DOTS server. 4973 * Rate-limiting DOTS telemetry, including those with new 'tmid' 4974 values, from the same DOTS client defends against DoS attacks that 4975 would result in varying the 'tmid' to exhaust DOTS server 4976 resources. Likewise, the DOTS server can enforce a quota and 4977 time-limit on the number of active pre-or-ongoing-mitigation 4978 telemetry data items (identified by 'tmid') from the DOTS client. 4980 Note also that telemetry notification interval may be used to rate- 4981 limit the pre-or-ongoing-mitigation telemetry notifications received 4982 by a DOTS client domain. 4984 13.2. Vendor Attack Mapping 4986 The security considerations for the DOTS data channel protocol are 4987 discussed in Section 10 of [RFC8783]. The following discusses the 4988 security considerations that are specific to the DOTS data channel 4989 extension defined in this document. 4991 All data nodes defined in the YANG module specified in Section 10.2 4992 which can be created, modified, and deleted (i.e., config true, which 4993 is the default) are considered sensitive. Write operations to these 4994 data nodes without proper protection can have a negative effect on 4995 network operations. Appropriate security measures are recommended to 4996 prevent illegitimate users from invoking DOTS data channel primitives 4997 as discussed in [RFC8783]. Nevertheless, an attacker who can access 4998 a DOTS client is technically capable of undertaking various attacks, 4999 such as: 5001 * Communicating invalid attack mapping details to the server 5002 ('/data-channel:dots-data/data-channel:dots-client/dots- 5003 telemetry:vendor-mapping'), which will mislead the server when 5004 correlating attack details. 5006 Some of the readable data nodes in the YANG module specified in 5007 Section 10.2 may be considered sensitive. It is thus important to 5008 control read access to these data nodes. These are the data nodes 5009 and their sensitivity: 5011 * '/data-channel:dots-data/data-channel:dots-client/dots- 5012 telemetry:vendor-mapping' can be misused to infer the DDoS 5013 protection technology deployed in a DOTS client domain. 5015 * '/data-channel:dots-data/dots-telemetry:vendor-mapping' can be 5016 used by a compromised DOTS client to leak the attack detection 5017 capabilities of the DOTS server. This is a variation of the 5018 compromised DOTS client attacks discussed in Section 13.1. 5020 14. Contributors 5022 The following individuals have contributed to this document: 5024 * Li Su, CMCC, Email: suli@chinamobile.com 5026 * Pan Wei, Huawei, Email: william.panwei@huawei.com 5028 15. Acknowledgements 5030 The authors would like to thank Flemming Andreasen, Liang Xia, and 5031 Kaname Nishizuka co-authors of [I-D.doron-dots-telemetry] and 5032 everyone who had contributed to that document. 5034 The authors would like to thank Kaname Nishizuka, Wei Pan, and Yuuhei 5035 Hayashi for comments and review. 5037 Special thanks to Jon Shallow and Kaname Nishizuka for their 5038 implementation and interoperability work. 5040 Many thanks to Jan Lindblad for the yangdoctors review and Nagendra 5041 Nainar for the opsdir review. 5043 Thanks to Benjamin Kaduk for the detailed AD review. 5045 16. References 5047 16.1. Normative References 5049 [Enterprise-Numbers] 5050 "Private Enterprise Numbers", 4 May 2020, 5051 . 5053 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5054 Requirement Levels", BCP 14, RFC 2119, 5055 DOI 10.17487/RFC2119, March 1997, 5056 . 5058 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 5059 DOI 10.17487/RFC3688, January 2004, 5060 . 5062 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 5063 the Network Configuration Protocol (NETCONF)", RFC 6020, 5064 DOI 10.17487/RFC6020, October 2010, 5065 . 5067 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 5068 RFC 6991, DOI 10.17487/RFC6991, July 2013, 5069 . 5071 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 5072 Application Protocol (CoAP)", RFC 7252, 5073 DOI 10.17487/RFC7252, June 2014, 5074 . 5076 [RFC7641] Hartke, K., "Observing Resources in the Constrained 5077 Application Protocol (CoAP)", RFC 7641, 5078 DOI 10.17487/RFC7641, September 2015, 5079 . 5081 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 5082 RFC 7950, DOI 10.17487/RFC7950, August 2016, 5083 . 5085 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 5086 the Constrained Application Protocol (CoAP)", RFC 7959, 5087 DOI 10.17487/RFC7959, August 2016, 5088 . 5090 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 5091 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 5092 November 2016, . 5094 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 5095 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 5096 . 5098 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5099 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5100 May 2017, . 5102 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 5103 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 5104 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 5105 2018, . 5107 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 5108 Denial-of-Service Open Threat Signaling (DOTS) Data 5109 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 5110 May 2020, . 5112 [RFC8791] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Data 5113 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 5114 June 2020, . 5116 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 5117 Representation (CBOR)", STD 94, RFC 8949, 5118 DOI 10.17487/RFC8949, December 2020, 5119 . 5121 [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, 5122 "Distributed Denial-of-Service Open Threat Signaling 5123 (DOTS) Signal Channel Specification", RFC 9132, 5124 DOI 10.17487/RFC9132, September 2021, 5125 . 5127 16.2. Informative References 5129 [Cause] IANA, "DOTS Signal Channel Conflict Cause Codes", 5130 . 5133 [I-D.doron-dots-telemetry] 5134 Doron, E., Reddy, T., Andreasen, F., (Frank), L. X., and 5135 K. Nishizuka, "Distributed Denial-of-Service Open Threat 5136 Signaling (DOTS) Telemetry Specifications", Work in 5137 Progress, Internet-Draft, draft-doron-dots-telemetry-00, 5138 30 October 2016, . 5141 [I-D.ietf-core-new-block] 5142 Boucadair, M. and J. Shallow, "Constrained Application 5143 Protocol (CoAP) Block-Wise Transfer Options Supporting 5144 Robust Transmission", Work in Progress, Internet-Draft, 5145 draft-ietf-core-new-block-14, 26 May 2021, 5146 . 5149 [I-D.ietf-dots-multihoming] 5150 Boucadair, M., Reddy, T., and W. Pan, "Multi-homing 5151 Deployment Considerations for Distributed-Denial-of- 5152 Service Open Threat Signaling (DOTS)", Work in Progress, 5153 Internet-Draft, draft-ietf-dots-multihoming-09, 2 December 5154 2021, . 5157 [I-D.ietf-dots-robust-blocks] 5158 Boucadair, M. and J. Shallow, "Distributed Denial-of- 5159 Service Open Threat Signaling (DOTS) Signal Channel 5160 Configuration Attributes for Robust Block Transmission", 5161 Work in Progress, Internet-Draft, draft-ietf-dots-robust- 5162 blocks-00, 23 August 2021, 5163 . 5166 [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", 5167 . 5170 [PYANG] "pyang", November 2020, 5171 . 5173 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 5174 "Framework for IP Performance Metrics", RFC 2330, 5175 DOI 10.17487/RFC2330, May 1998, 5176 . 5178 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 5179 Denial-of-Service Considerations", RFC 4732, 5180 DOI 10.17487/RFC4732, December 2006, 5181 . 5183 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 5184 RFC 4960, DOI 10.17487/RFC4960, September 2007, 5185 . 5187 [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for 5188 Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 5189 2009, . 5191 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 5192 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 5193 . 5195 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 5196 and R. Wilton, "YANG Library", RFC 8525, 5197 DOI 10.17487/RFC8525, March 2019, 5198 . 5200 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 5201 Threat Signaling (DOTS) Requirements", RFC 8612, 5202 DOI 10.17487/RFC8612, May 2019, 5203 . 5205 [RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., 5206 Teague, N., and R. Compton, "DDoS Open Threat Signaling 5207 (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, 5208 August 2020, . 5210 [RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 5211 L., and K. Nishizuka, "Use Cases for DDoS Open Threat 5212 Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021, 5213 . 5215 [RFC9133] Nishizuka, K., Boucadair, M., Reddy.K, T., and T. Nagata, 5216 "Controlling Filtering Rules Using Distributed Denial-of- 5217 Service Open Threat Signaling (DOTS) Signal Channel", 5218 RFC 9133, DOI 10.17487/RFC9133, September 2021, 5219 . 5221 Authors' Addresses 5222 Mohamed Boucadair (editor) 5223 Orange 5224 35000 Rennes 5225 France 5227 Email: mohamed.boucadair@orange.com 5229 Tirumaleswar Reddy (editor) 5230 Akamai 5231 Embassy Golf Link Business Park 5232 Bangalore 560071 5233 Karnataka 5234 India 5236 Email: kondtir@gmail.com 5238 Ehud Doron 5239 Radware Ltd. 5240 Raoul Wallenberg Street 5241 Tel-Aviv 69710 5242 Israel 5244 Email: ehudd@radware.com 5246 Meiling Chen 5247 CMCC 5248 32, Xuanwumen West 5249 BeiJing 5250 BeiJing, 100053 5251 China 5253 Email: chenmeiling@chinamobile.com 5255 Jon Shallow 5256 United Kingdom 5258 Email: supjps-ietf@jpshallow.com