idnits 2.17.00 (12 Aug 2021) /tmp/idnits30792/draft-ietf-dots-telemetry-18.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 824 has weird spacing: '...-status boo...' == Line 840 has weird spacing: '...-status boo...' == Line 1081 has weird spacing: '...apacity uin...' == Line 1435 has weird spacing: '...er-port ine...' == Line 1798 has weird spacing: '...er-port ine...' == (8 more instances...) -- The document date (13 December 2021) is 158 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 4885, 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 (~~), 12 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: 16 June 2022 Akamai 6 E. Doron 7 Radware Ltd. 8 M. Chen 9 CMCC 10 J. Shallow 11 13 December 2021 13 Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry 14 draft-ietf-dots-telemetry-18 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 16 June 2022. 46 Copyright Notice 48 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . . 111 127 16.1. Normative References . . . . . . . . . . . . . . . . . . 111 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 that common global thresholds for 392 attack detection practically cannot be realized. Each DOTS client 393 domain can have its own levels of traffic and normal behavior. 394 Without facilitating normal baseline signaling, it may be very 395 difficult for DOTS servers in some cases to detect and mitigate the 396 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 is 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 for 'tm' 696 (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 has a validity timeout of the DOTS association 720 with a DOTS client domain. DOTS servers MUST NOT reset 'tsid' 721 because a session failed with a DOTS client. DOTS clients update 722 their telemetry setup configuration upon change of a parameter that 723 may 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=569" 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. 986 DOTS clients that are interested to receive pre or ongoing mitigation 987 telemetry (pre-or-ongoing-mitigation) information from a DOTS server 988 (Section 8.2) MUST set 'server-originated-telemetry' to 'true'. If 989 'server-originated-telemetry' is not present in a PUT request, this 990 is equivalent to receiving a request with 'server-originated- 991 telemetry' set to 'false'. An example of a request to enable pre-or- 992 ongoing-mitigation telemetry from DOTS servers is shown in Figure 6. 994 Header: PUT (Code=0.03) 995 Uri-Path: ".well-known" 996 Uri-Path: "dots" 997 Uri-Path: "tm-setup" 998 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 999 Uri-Path: "tsid=569" 1000 Content-Format: "application/dots+cbor" 1002 { 1003 "ietf-dots-telemetry:telemetry-setup": { 1004 "telemetry": [ 1005 { 1006 "current-config": { 1007 "server-originated-telemetry": true 1008 } 1009 } 1010 ] 1011 } 1012 } 1014 Figure 6: PUT to Enable Pre-or-ongoing-mitigation Telemetry from 1015 the DOTS server 1017 6.1.3. Retrieve Installed DOTS Telemetry Configuration 1019 A DOTS client may issue a GET message with 'tsid' Uri-Path parameter 1020 to retrieve the current DOTS telemetry configuration. An example of 1021 such a request is depicted in Figure 7. 1023 Header: GET (Code=0.01) 1024 Uri-Path: ".well-known" 1025 Uri-Path: "dots" 1026 Uri-Path: "tm-setup" 1027 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1028 Uri-Path: "tsid=123" 1030 Figure 7: GET to Retrieve Current DOTS Telemetry Configuration 1032 If the DOTS server does not find the 'tsid' Uri-Path value conveyed 1033 in the GET request in its configuration data for the requesting DOTS 1034 client, it MUST respond with a 4.04 (Not Found) error Response Code. 1036 6.1.4. Delete DOTS Telemetry Configuration 1038 A DELETE request is used to delete the installed DOTS telemetry 1039 configuration data (Figure 8). 'cuid' and 'tsid' are mandatory Uri- 1040 Path parameters for such DELETE requests. 1042 Header: DELETE (Code=0.04) 1043 Uri-Path: ".well-known" 1044 Uri-Path: "dots" 1045 Uri-Path: "tm-setup" 1046 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1047 Uri-Path: "tsid=123" 1049 Figure 8: Delete Telemetry Configuration 1051 The DOTS server resets the DOTS telemetry configuration back to the 1052 default values and acknowledges a DOTS client's request to remove the 1053 DOTS telemetry configuration using 2.02 (Deleted) Response Code. A 1054 2.02 (Deleted) Response Code is returned even if the 'tsid' parameter 1055 value conveyed in the DELETE request does not exist in its 1056 configuration data before the request. 1058 Section 6.4 discusses the procedure to reset all DOTS telemetry setup 1059 configuration. 1061 6.2. Total Pipe Capacity 1063 A DOTS client can communicate to the DOTS server(s) its DOTS client 1064 domain pipe information. The tree structure of the pipe information 1065 is shown in Figure 9. 1067 structure dots-telemetry: 1068 +-- (telemetry-message-type)? 1069 +--:(telemetry-setup) 1070 | ... 1071 | +-- telemetry* [] 1072 | +-- (direction)? 1073 | | +--:(server-to-client-only) 1074 | | +-- tsid? uint32 1075 | +-- (setup-type)? 1076 | +--:(telemetry-config) 1077 | | ... 1078 | +--:(pipe) 1079 | | +-- total-pipe-capacity* [link-id unit] 1080 | | +-- link-id nt:link-id 1081 | | +-- capacity uint64 1082 | | +-- unit unit 1083 | +--:(baseline) 1084 | ... 1085 +--:(telemetry) 1086 ... 1088 Figure 9: Pipe Tree Structure 1090 A DOTS client domain pipe is defined as a list of limits of 1091 (incoming) traffic volume ('total-pipe-capacity') that can be 1092 forwarded over ingress interconnection links of a DOTS client domain. 1093 Each of these links is identified with a 'link-id' [RFC8345]. 1095 The unit used by a DOTS client when conveying pipe information is 1096 captured in the 'unit' attribute. The DOTS client MUST auto-scale so 1097 that the appropriate unit is used. That is, for a given unit class, 1098 the DOTS client uses the largest unit that gives a value greater than 1099 one. As such, only one unit per unit class is allowed. 1101 6.2.1. Conveying DOTS Client Domain Pipe Capacity 1103 Similar considerations to those specified in Section 6.1.2 are 1104 followed with one exception: 1106 The relative order of two PUT requests carrying DOTS client domain 1107 pipe attributes from a DOTS client is determined by comparing 1108 their respective 'tsid' values. If such two requests have 1109 overlapping 'link-id' and 'unit', the PUT request with higher 1110 numeric 'tsid' value will override the request with a lower 1111 numeric 'tsid' value. The overlapped lower numeric 'tsid' MUST be 1112 automatically deleted and no longer be available. 1114 DOTS clients SHOULD minimize the number of active 'tsid's used for 1115 pipe information. In order to avoid maintaining a long list of 1116 'tsid's for pipe information, it is RECOMMENDED that DOTS clients 1117 include in any request to update information related to a given link 1118 the information of other links (already communicated using a lower 1119 'tsid' value). Doing so, this update request will override these 1120 existing requests and hence optimize the number of 'tsid' request per 1121 DOTS client. 1123 * Note: This assumes that all link information can fit in one single 1124 message. 1126 As an example of configuring pipe information, a DOTS client managing 1127 a single homed domain (Figure 10) can send a PUT request (shown in 1128 Figure 11) to communicate the capacity of "link1" used to connect to 1129 its ISP. 1131 ,--,--,--. ,--,--,--. 1132 ,-' `-. ,-' `-. 1133 ( DOTS Client )=====( ISP#A ) 1134 `-. Domain ,-' link1 `-. ,-' 1135 `--'--'--' `--'--'--' 1137 Figure 10: Single Homed DOTS Client Domain 1139 Header: PUT (Code=0.03) 1140 Uri-Path: ".well-known" 1141 Uri-Path: "dots" 1142 Uri-Path: "tm-setup" 1143 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1144 Uri-Path: "tsid=457" 1145 Content-Format: "application/dots+cbor" 1147 { 1148 "ietf-dots-telemetry:telemetry-setup": { 1149 "telemetry": [ 1150 { 1151 "total-pipe-capacity": [ 1152 { 1153 "link-id": "link1", 1154 "capacity": "500", 1155 "unit": "megabit-ps" 1156 } 1157 ] 1158 } 1159 ] 1160 } 1161 } 1162 Figure 11: Example of a PUT Request to Convey Pipe Information 1163 (Single Homed) 1165 DOTS clients may be instructed to signal a link aggregate instead of 1166 individual links. For example, a DOTS client that manages a DOTS 1167 client domain having two interconnection links with an upstream ISP 1168 (Figure 12) can send a PUT request (shown in Figure 13) to 1169 communicate the aggregate link capacity with its ISP. Signaling 1170 individual or aggregate link capacity is deployment specific. 1172 ,--,--,--. ,--,--,--. 1173 ,-' `-.===== ,-' `-. 1174 ( DOTS Client ) ( ISP#C ) 1175 `-. Domain ,-'====== `-. ,-' 1176 `--'--'--' `--'--'--' 1178 Figure 12: DOTS Client Domain with Two Interconnection Links 1180 Header: PUT (Code=0.03) 1181 Uri-Path: ".well-known" 1182 Uri-Path: "dots" 1183 Uri-Path: "tm-setup" 1184 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1185 Uri-Path: "tsid=896" 1186 Content-Format: "application/dots+cbor" 1188 { 1189 "ietf-dots-telemetry:telemetry-setup": { 1190 "telemetry": [ 1191 { 1192 "total-pipe-capacity": [ 1193 { 1194 "link-id": "aggregate", 1195 "capacity": "700", 1196 "unit": "megabit-ps" 1197 } 1198 ] 1199 } 1200 ] 1201 } 1202 } 1204 Figure 13: Example of a PUT Request to Convey Pipe Information 1205 (Aggregated Link) 1207 Now consider that the DOTS client domain was upgraded to connect to 1208 an additional ISP (e.g., ISP#B of Figure 14); the DOTS client can 1209 inform a third-party DOTS server (that is, not hosted with ISP#A and 1210 ISP#B domains) about this update by sending the PUT request depicted 1211 in Figure 15. This request also includes information related to 1212 "link1" even if that link is not upgraded. Upon receipt of this 1213 request, the DOTS server removes the request with 'tsid=457' and 1214 updates its configuration base to maintain two links (link#1 and 1215 link#2). 1217 ,--,--,--. 1218 ,-' `-. 1219 ( ISP#B ) 1220 `-. ,-' 1221 `--'--'--' 1222 || 1223 || link2 1224 ,--,--,--. ,--,--,--. 1225 ,-' `-. ,-' `-. 1226 ( DOTS Client )=====( ISP#A ) 1227 `-. Domain ,-' link1 `-. ,-' 1228 `--'--'--' `--'--'--' 1230 Figure 14: Multi-Homed DOTS Client Domain 1232 Header: PUT (Code=0.03) 1233 Uri-Path: ".well-known" 1234 Uri-Path: "dots" 1235 Uri-Path: "tm-setup" 1236 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1237 Uri-Path: "tsid=458" 1238 Content-Format: "application/dots+cbor" 1240 { 1241 "ietf-dots-telemetry:telemetry-setup": { 1242 "telemetry": [ 1243 { 1244 "total-pipe-capacity": [ 1245 { 1246 "link-id": "link1", 1247 "capacity": "500", 1248 "unit": "megabit-ps" 1249 }, 1250 { 1251 "link-id": "link2", 1252 "capacity": "500", 1253 "unit": "megabit-ps" 1254 } 1255 ] 1256 } 1257 ] 1258 } 1259 } 1261 Figure 15: Example of a PUT Request to Convey Pipe Information 1262 (Multi-Homed) 1264 A DOTS client can delete a link by sending a PUT request with the 1265 'capacity' attribute set to "0" if other links are still active for 1266 the same DOTS client domain (see Section 6.2.3 for other delete 1267 cases). For example, if a DOTS client domain re-homes (that is, it 1268 changes its ISP), the DOTS client can inform its DOTS server about 1269 this update (e.g., from the network configuration in Figure 10 to the 1270 one shown in Figure 16) by sending the PUT request depicted in 1271 Figure 17. Upon receipt of this request, and assuming no error is 1272 encountered when processing the request, the DOTS server removes 1273 "link1" from its configuration bases for this DOTS client domain. 1274 Note that if the DOTS server receives a PUT request with a 'capacity' 1275 attribute set to "0" for all included links, it MUST reject the 1276 request with a 4.00 (Bad Request). 1278 ,--,--,--. 1279 ,-' `-. 1280 ( ISP#B ) 1281 `-. ,-' 1282 `--'--'--' 1283 || 1284 || link2 1285 ,--,--,--. 1286 ,-' `-. 1287 ( DOTS Client ) 1288 `-. Domain ,-' 1289 `--'--'--' 1291 Figure 16: Multi-Homed DOTS Client Domain 1293 Header: PUT (Code=0.03) 1294 Uri-Path: ".well-known" 1295 Uri-Path: "dots" 1296 Uri-Path: "tm-setup" 1297 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1298 Uri-Path: "tsid=459" 1299 Content-Format: "application/dots+cbor" 1301 { 1302 "ietf-dots-telemetry:telemetry-setup": { 1303 "telemetry": [ 1304 { 1305 "total-pipe-capacity": [ 1306 { 1307 "link-id": "link1", 1308 "capacity": "0", 1309 "unit": "megabit-ps" 1310 }, 1311 { 1312 "link-id": "link2", 1313 "capacity": "500", 1314 "unit": "megabit-ps" 1315 } 1316 ] 1317 } 1318 ] 1319 } 1320 } 1322 Figure 17: Example of a PUT Request to Convey Pipe Information 1323 (Multi-Homed) 1325 6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity 1327 A GET request with 'tsid' Uri-Path parameter is used to retrieve a 1328 specific installed DOTS client domain pipe related information. The 1329 same procedure as defined in Section 6.1.3 is followed. 1331 To retrieve all pipe information bound to a DOTS client, the DOTS 1332 client proceeds as specified in Section 6.1.1. 1334 6.2.3. Delete Installed DOTS Client Domain Pipe Capacity 1336 A DELETE request is used to delete the installed DOTS client domain 1337 pipe related information. The same procedure as defined in 1338 Section 6.1.4 is followed. 1340 6.3. Telemetry Baseline 1342 A DOTS client can communicate to its DOTS server(s) its normal 1343 traffic baseline and connections capacity: 1345 Total traffic normal baseline: The percentile values representing 1346 the total traffic normal baseline. It can be represented for a 1347 target using 'total-traffic-normal'. 1349 The traffic normal per-protocol ('total-traffic-normal-per- 1350 protocol') baseline is represented for a target and is transport- 1351 protocol specific. 1353 The traffic normal per-port-number ('total-traffic-normal-per- 1354 port') baseline is represented for each port number bound to a 1355 target. 1357 If the DOTS client negotiated percentile values and units 1358 (Section 6.1), these negotiated parameters will be used instead of 1359 the default ones. For each used unit class, the DOTS client MUST 1360 auto-scale so that the appropriate unit is used. 1362 Total connections capacity: If the target is susceptible to 1363 resource-consuming DDoS attacks, the following optional attributes 1364 for the target per transport protocol are useful to detect 1365 resource-consuming DDoS attacks: 1367 * The maximum number of simultaneous connections that are allowed 1368 to the target. 1370 * The maximum number of simultaneous connections that are allowed 1371 to the target per client. 1373 * The maximum number of simultaneous embryonic connections that 1374 are allowed to the target. The term "embryonic connection" 1375 refers to a connection whose connection handshake is not 1376 finished. Embryonic connection is only possible in connection- 1377 oriented transport protocols like TCP or Stream Control 1378 Transmission Protocol (SCTP) [RFC4960]. 1380 * The maximum number of simultaneous embryonic connections that 1381 are allowed to the target per client. 1383 * The maximum number of connections allowed per second to the 1384 target. 1386 * The maximum number of connections allowed per second to the 1387 target per client. 1389 * The maximum number of requests (e.g., HTTP/DNS/SIP requests) 1390 allowed per second to the target. 1392 * The maximum number of requests allowed per second to the target 1393 per client. 1395 * The maximum number of outstanding partial requests allowed to 1396 the target. Attacks relying upon partial requests create a 1397 connection with a target but do not send a complete request 1398 (e.g., HTTP request). 1400 * The maximum number of outstanding partial requests allowed to 1401 the target per client. 1403 The aggregate per transport protocol is captured in 'total- 1404 connection-capacity', while port-specific capabilities are 1405 represented using 'total-connection-capacity-per-port'. 1407 Note that a target resource is identified using the attributes 1408 'target-prefix', 'target-port-range', 'target-protocol', 'target- 1409 fqdn', 'target-uri', or 'alias-name' defined in Section 4.4.1.1 of 1410 [RFC9132]. 1412 The tree structure of the normal traffic baseline is shown in 1413 Figure 18. 1415 structure dots-telemetry: 1416 +-- (telemetry-message-type)? 1417 +--:(telemetry-setup) 1418 | ... 1419 | +-- telemetry* [] 1420 | +-- (direction)? 1421 | | +--:(server-to-client-only) 1422 | | +-- tsid? uint32 1423 | +-- (setup-type)? 1424 | +--:(telemetry-config) 1425 | | ... 1426 | +--:(pipe) 1427 | | ... 1428 | +--:(baseline) 1429 | +-- baseline* [id] 1430 | +-- id 1431 | | uint32 1432 | +-- target-prefix* 1433 | | inet:ip-prefix 1434 | +-- target-port-range* [lower-port] 1435 | | +-- lower-port inet:port-number 1436 | | +-- upper-port? inet:port-number 1437 | +-- target-protocol* uint8 1438 | +-- target-fqdn* 1439 | | inet:domain-name 1440 | +-- target-uri* 1441 | | inet:uri 1442 | +-- alias-name* 1443 | | string 1444 | +-- total-traffic-normal* [unit] 1445 | | +-- unit unit 1446 | | +-- low-percentile-g? yang:gauge64 1447 | | +-- mid-percentile-g? yang:gauge64 1448 | | +-- high-percentile-g? yang:gauge64 1449 | | +-- peak-g? yang:gauge64 1450 | +-- total-traffic-normal-per-protocol* 1451 | | [unit protocol] 1452 | | +-- protocol uint8 1453 | | +-- unit unit 1454 | | +-- low-percentile-g? yang:gauge64 1455 | | +-- mid-percentile-g? yang:gauge64 1456 | | +-- high-percentile-g? yang:gauge64 1457 | | +-- peak-g? yang:gauge64 1458 | +-- total-traffic-normal-per-port* [unit port] 1459 | | +-- port inet:port-number 1460 | | +-- unit unit 1461 | | +-- low-percentile-g? yang:gauge64 1462 | | +-- mid-percentile-g? yang:gauge64 1463 | | +-- high-percentile-g? yang:gauge64 1464 | | +-- peak-g? yang:gauge64 1465 | +-- total-connection-capacity* [protocol] 1466 | | +-- protocol uint8 1467 | | +-- connection? uint64 1468 | | +-- connection-client? uint64 1469 | | +-- embryonic? uint64 1470 | | +-- embryonic-client? uint64 1471 | | +-- connection-ps? uint64 1472 | | +-- connection-client-ps? uint64 1473 | | +-- request-ps? uint64 1474 | | +-- request-client-ps? uint64 1475 | | +-- partial-request-max? uint64 1476 | | +-- partial-request-client-max? uint64 1477 | +-- total-connection-capacity-per-port* 1478 | [protocol port] 1479 | +-- port 1480 | | inet:port-number 1481 | +-- protocol uint8 1482 | +-- connection? uint64 1483 | +-- connection-client? uint64 1484 | +-- embryonic? uint64 1485 | +-- embryonic-client? uint64 1486 | +-- connection-ps? uint64 1487 | +-- connection-client-ps? uint64 1488 | +-- request-ps? uint64 1489 | +-- request-client-ps? uint64 1490 | +-- partial-request-max? uint64 1491 | +-- partial-request-client-max? uint64 1492 +--:(telemetry) 1493 ... 1495 Figure 18: Telemetry Baseline Tree Structure 1497 A DOTS client can share one or multiple normal traffic baselines 1498 (e.g., aggregate or per-prefix baselines), each are uniquely 1499 identified within the DOTS client domain with an identifier 'id'. 1500 This identifier can be used to update a baseline entry, delete a 1501 specific entry, etc. 1503 6.3.1. Conveying DOTS Client Domain Baseline Information 1505 Similar considerations to those specified in Section 6.1.2 are 1506 followed with one exception: 1508 The relative order of two PUT requests carrying DOTS client domain 1509 baseline attributes from a DOTS client is determined by comparing 1510 their respective 'tsid' values. If such two requests have 1511 overlapping targets, the PUT request with higher numeric 'tsid' 1512 value will override the request with a lower numeric 'tsid' value. 1513 The overlapped lower numeric 'tsid' MUST be automatically deleted 1514 and no longer be available. 1516 Two PUT requests from a DOTS client have overlapping targets if there 1517 is a common IP address, IP prefix, FQDN, URI, or alias-name. Also, 1518 two PUT requests from a DOTS client have overlapping targets from the 1519 perspective of the DOTS server if the addresses associated with the 1520 FQDN, URI, or alias are overlapping with each other or with 'target- 1521 prefix'. 1523 DOTS clients SHOULD minimize the number of active 'tsid's used for 1524 baseline information. In order to avoid maintaining a long list of 1525 'tsid's for baseline information, it is RECOMMENDED that DOTS clients 1526 include in a request to update information related to a given target, 1527 the information of other targets (already communicated using a lower 1528 'tsid' value) (assuming this fits within one single datagram). This 1529 update request will override these existing requests and hence 1530 optimize the number of 'tsid' request per DOTS client. 1532 If no target attribute is included in the request, this is an 1533 indication that the baseline information applies for the DOTS client 1534 domain as a whole. 1536 An example of a PUT request to convey the baseline information is 1537 shown in Figure 19. 1539 Header: PUT (Code=0.03) 1540 Uri-Path: ".well-known" 1541 Uri-Path: "dots" 1542 Uri-Path: "tm-setup" 1543 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1544 Uri-Path: "tsid=126" 1545 Content-Format: "application/dots+cbor" 1547 { 1548 "ietf-dots-telemetry:telemetry-setup": { 1549 "telemetry": [ 1550 { 1551 "baseline": [ 1552 { 1553 "id": 1, 1554 "target-prefix": [ 1555 "2001:db8:6401::1/128", 1556 "2001:db8:6401::2/128" 1557 ], 1558 "total-traffic-normal": [ 1559 { 1560 "unit": "megabit-ps", 1561 "peak-g": "60" 1562 } 1563 ] 1564 } 1565 ] 1566 } 1567 ] 1568 } 1569 } 1571 Figure 19: PUT to Conveying the DOTS Traffic Baseline 1573 The DOTS client may share protocol specific baseline information 1574 (e.g., TCP and UDP) as shown in Figure 19. 1576 Header: PUT (Code=0.03) 1577 Uri-Path: ".well-known" 1578 Uri-Path: "dots" 1579 Uri-Path: "tm-setup" 1580 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1581 Uri-Path: "tsid=128" 1582 Content-Format: "application/dots+cbor" 1584 { 1585 "ietf-dots-telemetry:telemetry-setup": { 1586 "telemetry": [ 1587 { 1588 "baseline": [ 1589 { 1590 "id": 1, 1591 "target-prefix": [ 1592 "2001:db8:6401::1/128", 1593 "2001:db8:6401::2/128" 1594 ], 1595 "total-traffic-normal-per-protocol": [ 1596 { 1597 "unit": "megabit-ps", 1598 "protocol": 6, 1599 "peak-g": "50" 1600 }, 1601 { 1602 "unit": "megabit-ps", 1603 "protocol": 17, 1604 "peak-g": "10" 1605 } 1606 ] 1607 } 1608 ] 1609 } 1610 ] 1611 } 1612 } 1614 Figure 20: PUT to Convey the DOTS Traffic Baseline (2) 1616 The normal traffic baseline information should be updated to reflect 1617 legitimate overloads (e.g., flash crowds) to prevent unnecessary 1618 mitigation. 1620 6.3.2. Retrieve Installed Normal Traffic Baseline 1622 A GET request with 'tsid' Uri-Path parameter is used to retrieve a 1623 specific installed DOTS client domain baseline traffic information. 1624 The same procedure as defined in Section 6.1.3 is followed. 1626 To retrieve all baseline information bound to a DOTS client, the DOTS 1627 client proceeds as specified in Section 6.1.1. 1629 6.3.3. Delete Installed Normal Traffic Baseline 1631 A DELETE request is used to delete the installed DOTS client domain 1632 normal traffic baseline. The same procedure as defined in 1633 Section 6.1.4 is followed. 1635 6.4. Reset Installed Telemetry Setup 1637 Upon bootstrapping (or reboot or any other event that may alter the 1638 DOTS client setup), a DOTS client MAY send a DELETE request to set 1639 the telemetry parameters to default values. Such a request does not 1640 include any 'tsid'. An example of such a request is depicted in 1641 Figure 21. 1643 Header: DELETE (Code=0.04) 1644 Uri-Path: ".well-known" 1645 Uri-Path: "dots" 1646 Uri-Path: "tm-setup" 1647 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1649 Figure 21: Delete Telemetry Configuration 1651 6.5. Conflict with Other DOTS Clients of the Same Domain 1653 A DOTS server may detect conflicts between requests conveying pipe 1654 and baseline information received from DOTS clients of the same DOTS 1655 client domain. 'conflict-information' is used to report the conflict 1656 to the DOTS client following similar conflict handling discussed in 1657 Section 4.4.1 of [RFC9132]. The conflict cause can be set to one of 1658 these values: 1660 1: Overlapping targets (Section 4.4.1 of [RFC9132]). 1662 TBA: Overlapping pipe scope (see Section 12). 1664 7. DOTS Pre-or-Ongoing Mitigation Telemetry 1666 There are two broad types of DDoS attacks: one is a bandwidth 1667 consuming attack, the other is a target-resource-consuming attack. 1668 This section outlines the set of DOTS telemetry attributes 1669 (Section 7.1) that covers both types of attack. The objective of 1670 these attributes is to allow for the complete knowledge of attacks 1671 and the various particulars that can best characterize attacks. 1673 The "ietf-dots-telemetry" YANG module (Section 10.1) defines the data 1674 structure of a new message type called 'telemetry'. The tree 1675 structure of the 'telemetry' message type is shown in Figure 24. 1677 The pre-or-ongoing-mitigation telemetry attributes are indicated by 1678 the path suffix '/tm'. The '/tm' is appended to the path prefix to 1679 form the URI used with a CoAP request to signal the DOTS telemetry. 1680 Pre-or-ongoing-mitigation telemetry attributes specified in 1681 Section 7.1 can be signaled between DOTS agents. 1683 Pre-or-ongoing-mitigation telemetry attributes may be sent by a DOTS 1684 client or a DOTS server. 1686 DOTS agents SHOULD bind pre-or-ongoing-mitigation telemetry data to 1687 mitigation requests associated with the resources under attack. In 1688 particular, a telemetry PUT request sent after a mitigation request 1689 may include a reference to that mitigation request ('mid-list') as 1690 shown in Figure 22. An example illustrating request correlation by 1691 means of 'target-prefix' is shown in Figure 23. 1693 Many of the pre-or-ongoing-mitigation telemetry data use a unit that 1694 falls under the unit class that is configured following the procedure 1695 described in Section 6.1.2. When generating telemetry data to send 1696 to a peer, the DOTS agent MUST auto-scale so that appropriate unit(s) 1697 are used. 1699 +-----------+ +-----------+ 1700 |DOTS client| |DOTS server| 1701 +-----------+ +-----------+ 1702 | | 1703 |===============Mitigation Request (mid)===============>| 1704 | | 1705 |===============Telemetry (mid-list{mid})==============>| 1706 | | 1708 Figure 22: Example of Request Correlation using 'mid' 1710 +-----------+ +-----------+ 1711 |DOTS client| |DOTS server| 1712 +-----------+ +-----------+ 1713 | | 1714 |<================Telemetry (target-prefix)=============| 1715 | | 1716 |=========Mitigation Request (target-prefix)===========>| 1717 | | 1719 Figure 23: Example of Request Correlation using Target Prefix 1721 DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry 1722 notifications to the same peer more frequently than once every 1723 'telemetry-notify-interval' (Section 6.1). If a telemetry 1724 notification is sent using a block-like transfer mechanism (e.g., 1725 [I-D.ietf-core-new-block]), this rate limit policy MUST NOT consider 1726 these individual blocks as separate notifications, but as a single 1727 notification. 1729 DOTS pre-or-ongoing-mitigation telemetry request and response 1730 messages MUST be marked as Non-Confirmable messages (Section 2.1 of 1731 [RFC7252]). 1733 structure dots-telemetry: 1734 +-- (telemetry-message-type)? 1735 +--:(telemetry-setup) 1736 | ... 1737 | +-- telemetry* [] 1738 | +-- (direction)? 1739 | | +--:(server-to-client-only) 1740 | | +-- tsid? uint32 1741 | +-- (setup-type)? 1742 | +--:(telemetry-config) 1743 | | ... 1744 | +--:(pipe) 1745 | | ... 1746 | +--:(baseline) 1747 | ... 1748 +--:(telemetry) 1749 +-- pre-or-ongoing-mitigation* [] 1750 +-- (direction)? 1751 | +--:(server-to-client-only) 1752 | +-- tmid? uint32 1753 +-- target 1754 | ... 1755 +-- total-traffic* [unit] 1756 | ... 1757 +-- total-traffic-protocol* [unit protocol] 1758 | ... 1759 +-- total-traffic-port* [unit port] 1760 | ... 1761 +-- total-attack-traffic* [unit] 1762 | ... 1763 +-- total-attack-traffic-protocol* [unit protocol] 1764 | ... 1765 +-- total-attack-traffic-port* [unit port] 1766 | ... 1767 +-- total-attack-connection-protocol* [protocol] 1768 | ... 1769 +-- total-attack-connection-port* [protocol port] 1770 | ... 1771 +-- attack-detail* [vendor-id attack-id] 1772 ... 1774 Figure 24: Telemetry Message Type Tree Structure 1776 7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes 1778 The description and motivation behind each attribute are presented in 1779 Section 3. DOTS telemetry attributes are optionally signaled and 1780 therefore MUST NOT be treated as mandatory fields in the DOTS signal 1781 channel protocol. 1783 7.1.1. Target 1785 A target resource (Figure 25) is identified using the attributes 1786 'target-prefix', 'target-port-range', 'target-protocol', 'target- 1787 fqdn', 'target-uri', 'alias-name', or a pointer to a mitigation 1788 request ('mid-list'). 1790 +--:(telemetry) 1791 +-- pre-or-ongoing-mitigation* [] 1792 +-- (direction)? 1793 | +--:(server-to-client-only) 1794 | +-- tmid? uint32 1795 +-- target 1796 | +-- target-prefix* inet:ip-prefix 1797 | +-- target-port-range* [lower-port] 1798 | | +-- lower-port inet:port-number 1799 | | +-- upper-port? inet:port-number 1800 | +-- target-protocol* uint8 1801 | +-- target-fqdn* inet:domain-name 1802 | +-- target-uri* inet:uri 1803 | +-- alias-name* string 1804 | +-- mid-list* uint32 1805 +-- total-traffic* [unit] 1806 | ... 1807 +-- total-traffic-protocol* [unit protocol] 1808 | ... 1809 +-- total-traffic-port* [unit port] 1810 | ... 1811 +-- total-attack-traffic* [unit] 1812 | ... 1813 +-- total-attack-traffic-protocol* [unit protocol] 1814 | ... 1815 +-- total-attack-traffic-port* [unit port] 1816 | ... 1817 +-- total-attack-connection-protocol* [protocol] 1818 | ... 1819 +-- total-attack-connection-port* [protocol port] 1820 | ... 1821 +-- attack-detail* [vendor-id attack-id] 1822 ... 1824 Figure 25: Target Tree Structure 1826 At least one of the attributes 'target-prefix', 'target-fqdn', 1827 'target-uri', 'alias-name', or 'mid-list' MUST be present in the 1828 target definition. 1830 If the target is susceptible to bandwidth-consuming attacks, the 1831 attributes representing the percentile values of the 'attack-id' 1832 attack traffic are included. 1834 If the target is susceptible to resource-consuming DDoS attacks, the 1835 same attributes defined in Section 7.1.4 are applicable for 1836 representing the attack. 1838 At least the 'target' attribute and one other pre-or-ongoing- 1839 mitigation attribute MUST be present in the DOTS telemetry message. 1841 7.1.2. Total Traffic 1843 The 'total-traffic' attribute (Figure 26) conveys the percentile 1844 values (including peak and current observed values) of the total 1845 observed traffic. More fine-grained information about the total 1846 traffic can be conveyed in the 'total-traffic-protocol' and 'total- 1847 traffic-port' attributes. 1849 The 'total-traffic-protocol' attribute represents the total traffic 1850 for a target and is transport-protocol specific. 1852 The 'total-traffic-port' represents the total traffic for a target 1853 per port number. 1855 +--:(telemetry) 1856 +-- pre-or-ongoing-mitigation* [] 1857 +-- (direction)? 1858 | +--:(server-to-client-only) 1859 | +-- tmid? uint32 1860 +-- target 1861 | ... 1862 +-- total-traffic* [unit] 1863 | +-- unit unit 1864 | +-- low-percentile-g? yang:gauge64 1865 | +-- mid-percentile-g? yang:gauge64 1866 | +-- high-percentile-g? yang:gauge64 1867 | +-- peak-g? yang:gauge64 1868 | +-- current-g? yang:gauge64 1869 +-- total-traffic-protocol* [unit protocol] 1870 | +-- protocol uint8 1871 | +-- unit unit 1872 | +-- low-percentile-g? yang:gauge64 1873 | +-- mid-percentile-g? yang:gauge64 1874 | +-- high-percentile-g? yang:gauge64 1875 | +-- peak-g? yang:gauge64 1876 | +-- current-g? yang:gauge64 1877 +-- total-traffic-port* [unit port] 1878 | +-- port inet:port-number 1879 | +-- unit unit 1880 | +-- low-percentile-g? yang:gauge64 1881 | +-- mid-percentile-g? yang:gauge64 1882 | +-- high-percentile-g? yang:gauge64 1883 | +-- peak-g? yang:gauge64 1884 | +-- current-g? yang:gauge64 1885 +-- total-attack-traffic* [unit] 1886 | ... 1887 +-- total-attack-traffic-protocol* [unit protocol] 1888 | ... 1889 +-- total-attack-traffic-port* [unit port] 1890 | ... 1891 +-- total-attack-connection-protocol* [protocol] 1892 | ... 1893 +-- total-attack-connection-port* [protocol port] 1894 | ... 1895 +-- attack-detail* [vendor-id attack-id] 1896 ... 1898 Figure 26: Total Traffic Tree Structure 1900 7.1.3. Total Attack Traffic 1902 The 'total-attack-traffic' attribute (Figure 27) conveys the total 1903 observed attack traffic. More fine-grained information about the 1904 total attack traffic can be conveyed in the 'total-attack-traffic- 1905 protocol' and 'total-attack-traffic-port' attributes. 1907 The 'total-attack-traffic-protocol' attribute represents the total 1908 attack traffic for a target and is transport-protocol specific. 1910 The 'total-attack-traffic-port' attribute represents the total attack 1911 traffic for a target per port number. 1913 +--:(telemetry) 1914 +-- pre-or-ongoing-mitigation* [] 1915 +-- (direction)? 1916 | +--:(server-to-client-only) 1917 | +-- tmid? uint32 1918 +-- target 1919 | ... 1920 +-- total-traffic* [unit] 1921 | ... 1922 +-- total-traffic-protocol* [unit protocol] 1923 | ... 1924 +-- total-traffic-port* [unit port] 1925 | ... 1926 +-- total-attack-traffic* [unit] 1927 | +-- unit unit 1928 | +-- low-percentile-g? yang:gauge64 1929 | +-- mid-percentile-g? yang:gauge64 1930 | +-- high-percentile-g? yang:gauge64 1931 | +-- peak-g? yang:gauge64 1932 | +-- current-g? yang:gauge64 1933 +-- total-attack-traffic-protocol* [unit protocol] 1934 | +-- protocol uint8 1935 | +-- unit unit 1936 | +-- low-percentile-g? yang:gauge64 1937 | +-- mid-percentile-g? yang:gauge64 1938 | +-- high-percentile-g? yang:gauge64 1939 | +-- peak-g? yang:gauge64 1940 | +-- current-g? yang:gauge64 1941 +-- total-attack-traffic-port* [unit port] 1942 | +-- port inet:port-number 1943 | +-- unit unit 1944 | +-- low-percentile-g? yang:gauge64 1945 | +-- mid-percentile-g? yang:gauge64 1946 | +-- high-percentile-g? yang:gauge64 1947 | +-- peak-g? yang:gauge64 1948 | +-- current-g? yang:gauge64 1949 +-- total-attack-connection-protocol* [protocol] 1950 | ... 1951 +-- total-attack-connection-port* [protocol port] 1952 | ... 1953 +-- attack-detail* [vendor-id attack-id] 1954 ... 1956 Figure 27: Total Attack Traffic Tree Structure 1958 7.1.4. Total Attack Connections 1960 If the target is susceptible to resource-consuming DDoS attacks, the 1961 'total-attack-connection-protocol' attribute is used to convey the 1962 percentile values (including peak and current observed values) of 1963 various attributes related to the total attack connections. The 1964 following optional subattributes for the target per transport 1965 protocol are included to represent the attack characteristics: 1967 * The number of simultaneous attack connections to the target. 1968 * The number of simultaneous embryonic connections to the target. 1969 * The number of attack connections per second to the target. 1970 * The number of attack requests per second to the target. 1971 * The number of attack partial requests to the target. 1973 The total attack connections per port number is represented using the 1974 'total-attack-connection-port' attribute. 1976 +--:(telemetry) 1977 +-- pre-or-ongoing-mitigation* [] 1978 +-- (direction)? 1979 | +--:(server-to-client-only) 1980 | +-- tmid? uint32 1981 +-- target 1982 | ... 1983 +-- total-traffic* [unit] 1984 | ... 1985 +-- total-traffic-protocol* [unit protocol] 1986 | ... 1987 +-- total-traffic-port* [unit port] 1988 | ... 1989 +-- total-attack-traffic* [unit] 1990 | ... 1991 +-- total-attack-traffic-protocol* [unit protocol] 1992 | ... 1993 +-- total-attack-traffic-port* [unit port] 1994 | ... 1995 +-- total-attack-connection-protocol* [protocol] 1996 | +-- protocol uint8 1997 | +-- connection-c 1998 | | +-- low-percentile-g? yang:gauge64 1999 | | +-- mid-percentile-g? yang:gauge64 2000 | | +-- high-percentile-g? yang:gauge64 2001 | | +-- peak-g? yang:gauge64 2002 | | +-- current-g? yang:gauge64 2003 | +-- embryonic-c 2004 | | +-- low-percentile-g? yang:gauge64 2005 | | +-- mid-percentile-g? yang:gauge64 2006 | | +-- high-percentile-g? yang:gauge64 2007 | | +-- peak-g? yang:gauge64 2008 | | +-- current-g? yang:gauge64 2009 | +-- connection-ps-c 2010 | | +-- low-percentile-g? yang:gauge64 2011 | | +-- mid-percentile-g? yang:gauge64 2012 | | +-- high-percentile-g? yang:gauge64 2013 | | +-- peak-g? yang:gauge64 2014 | | +-- current-g? yang:gauge64 2015 | +-- request-ps-c 2016 | | +-- low-percentile-g? yang:gauge64 2017 | | +-- mid-percentile-g? yang:gauge64 2018 | | +-- high-percentile-g? yang:gauge64 2019 | | +-- peak-g? yang:gauge64 2020 | | +-- current-g? yang:gauge64 2021 | +-- partial-request-c 2022 | +-- low-percentile-g? yang:gauge64 2023 | +-- mid-percentile-g? yang:gauge64 2024 | +-- high-percentile-g? yang:gauge64 2025 | +-- peak-g? yang:gauge64 2026 | +-- current-g? yang:gauge64 2027 +-- total-attack-connection-port* [protocol port] 2028 | +-- protocol uint8 2029 | +-- port inet:port-number 2030 | +-- connection-c 2031 | | +-- low-percentile-g? yang:gauge64 2032 | | +-- mid-percentile-g? yang:gauge64 2033 | | +-- high-percentile-g? yang:gauge64 2034 | | +-- peak-g? yang:gauge64 2035 | | +-- current-g? yang:gauge64 2036 | +-- embryonic-c 2037 | | +-- low-percentile-g? yang:gauge64 2038 | | +-- mid-percentile-g? yang:gauge64 2039 | | +-- high-percentile-g? yang:gauge64 2040 | | +-- peak-g? yang:gauge64 2041 | | +-- current-g? yang:gauge64 2042 | +-- connection-ps-c 2043 | | +-- low-percentile-g? yang:gauge64 2044 | | +-- mid-percentile-g? yang:gauge64 2045 | | +-- high-percentile-g? yang:gauge64 2046 | | +-- peak-g? yang:gauge64 2047 | | +-- current-g? yang:gauge64 2048 | +-- request-ps-c 2049 | | +-- low-percentile-g? yang:gauge64 2050 | | +-- mid-percentile-g? yang:gauge64 2051 | | +-- high-percentile-g? yang:gauge64 2052 | | +-- peak-g? yang:gauge64 2053 | | +-- current-g? yang:gauge64 2054 | +-- partial-request-c 2055 | +-- low-percentile-g? yang:gauge64 2056 | +-- mid-percentile-g? yang:gauge64 2057 | +-- high-percentile-g? yang:gauge64 2058 | +-- peak-g? yang:gauge64 2059 | +-- current-g? yang:gauge64 2060 +-- attack-detail* [vendor-id attack-id] 2061 ... 2063 Figure 28: Total Attack Connections Tree Structure 2065 7.1.5. Attack Details 2067 This attribute (depicted in Figure 29) is used to signal a set of 2068 details characterizing an attack. The following subattributes 2069 describing the ongoing attack can be signalled as attack details: 2071 vendor-id: Vendor ID is a security vendor's Enterprise Number as 2072 registered with IANA [Enterprise-Numbers]. It is a four-byte 2073 integer value. 2075 attack-id: Unique identifier assigned for the attack by a vendor. 2077 attack-description: Textual representation of the attack 2078 description. Natural Language Processing techniques (e.g., word 2079 embedding) might provide some utility in mapping the attack 2080 description to an attack type. Textual representation of attack 2081 solves two problems: (a) avoids the need to create mapping tables 2082 manually between vendors and (b) avoids the need to standardize 2083 attack types which keep evolving. 2085 attack-severity: Attack severity level. This attribute takes one of 2086 the values defined in Section 3.12.2 of [RFC7970]. 2088 start-time: The time the attack started. The attack's start time is 2089 expressed in seconds relative to 1970-01-01T00:00Z (Section 3.4.2 2090 of [RFC8949]). The CBOR encoding is modified so that the leading 2091 tag 1 (epoch-based date/time) MUST be omitted. 2093 end-time: The time the attack ended. The attack end time is 2094 expressed in seconds relative to 1970-01-01T00:00Z (Section 3.4.2 2095 of [RFC8949]). The CBOR encoding is modified so that the leading 2096 tag 1 (epoch-based date/time) MUST be omitted. 2098 source-count: A count of sources involved in the attack targeting 2099 the victim. 2101 top-talker: A list of attack sources that are involved in an attack 2102 and which are generating an important part of the attack traffic. 2103 The top talkers are represented using the 'source-prefix'. 2105 'spoofed-status' indicates whether a top talker is a spoofed IP 2106 address (e.g., reflection attacks) or not. If no 'spoofed-status' 2107 data node is included, this means that the spoofing status is 2108 unknown. 2110 If the target is being subjected to a bandwidth-consuming attack, 2111 a statistical profile of the attack traffic from each of the top 2112 talkers is included ('total-attack-traffic', Section 7.1.3). 2114 If the target is being subjected to a resource-consuming DDoS 2115 attack, the same attributes defined in Section 7.1.4 are 2116 applicable for characterizing the attack on a per-talker basis. 2118 +--:(telemetry) 2119 +-- pre-or-ongoing-mitigation* [] 2120 +-- (direction)? 2121 | +--:(server-to-client-only) 2122 | +-- tmid? uint32 2123 +-- target 2124 | ... 2125 +-- total-traffic* [unit] 2126 | ... 2127 +-- total-traffic-protocol* [unit protocol] 2128 | ... 2129 +-- total-traffic-port* [unit port] 2130 | ... 2131 +-- total-attack-traffic* [unit] 2132 | ... 2133 +-- total-attack-traffic-protocol* [unit protocol] 2134 | ... 2135 +-- total-attack-traffic-port* [unit port] 2136 | ... 2137 +-- total-attack-connection-protocol* [protocol] 2138 | ... 2139 +-- total-attack-connection-port* [protocol port] 2140 | ... 2141 +-- attack-detail* [vendor-id attack-id] 2142 +-- vendor-id uint32 2143 +-- attack-id uint32 2144 +-- attack-description? string 2145 +-- attack-severity? attack-severity 2146 +-- start-time? uint64 2147 +-- end-time? uint64 2148 +-- source-count 2149 | +-- low-percentile-g? yang:gauge64 2150 | +-- mid-percentile-g? yang:gauge64 2151 | +-- high-percentile-g? yang:gauge64 2152 | +-- peak-g? yang:gauge64 2153 | +-- current-g? yang:gauge64 2154 +-- top-talker 2155 +-- talker* [source-prefix] 2156 +-- spoofed-status? boolean 2157 +-- source-prefix inet:ip-prefix 2158 +-- source-port-range* [lower-port] 2159 | +-- lower-port inet:port-number 2160 | +-- upper-port? inet:port-number 2161 +-- source-icmp-type-range* [lower-type] 2162 | +-- lower-type uint8 2163 | +-- upper-type? uint8 2164 +-- total-attack-traffic* [unit] 2165 | +-- unit unit 2166 | +-- low-percentile-g? yang:gauge64 2167 | +-- mid-percentile-g? yang:gauge64 2168 | +-- high-percentile-g? yang:gauge64 2169 | +-- peak-g? yang:gauge64 2170 | +-- current-g? yang:gauge64 2171 +-- total-attack-connection-protocol* 2172 [protocol] 2173 +-- protocol uint8 2174 +-- connection-c 2175 | +-- low-percentile-g? yang:gauge64 2176 | +-- mid-percentile-g? yang:gauge64 2177 | +-- high-percentile-g? yang:gauge64 2178 | +-- peak-g? yang:gauge64 2179 | +-- current-g? yang:gauge64 2180 +-- embryonic-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 +-- connection-ps-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 +-- request-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 +-- partial-request-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 2205 Figure 29: Attack Detail Tree Structure 2207 In order to optimize the size of telemetry data conveyed over the 2208 DOTS signal channel, DOTS agents MAY use the DOTS data channel 2209 [RFC8783] to exchange vendor specific attack mapping details (that 2210 is, {vendor identifier, attack identifier} ==> textual representation 2211 of the attack description). As such, DOTS agents do not have to 2212 convey systematically an attack description in their telemetry 2213 messages over the DOTS signal channel. Refer to Section 7.1.6. 2215 7.1.6. Vendor Attack Mapping 2217 Multiple mappings for different vendor identifiers may be used; the 2218 DOTS agent transmitting telemetry information can elect to use one or 2219 more vendor mappings even in the same telemetry message. 2221 Note: It is possible that a DOTS server is making use of multiple 2222 DOTS mitigators; each from a different vendor. How telemetry 2223 information and vendor mappings are exchanged between DOTS servers 2224 and DOTS mitigators is outside the scope of this document. 2226 DOTS clients and servers may be provided with mappings from different 2227 vendors and so have their own different sets of vendor attack 2228 mappings. A DOTS agent MUST accept receipt of telemetry data with a 2229 vendor identifier that is different to the one it uses to transmit 2230 telemetry data. Furthermore, it is possible that the DOTS client and 2231 DOTS server are provided by the same vendor, but the vendor mapping 2232 tables are at different revisions. The DOTS client SHOULD transmit 2233 telemetry information using any vendor mapping(s) that it provided to 2234 the DOTS server (e.g., using a POST as depicted in Figure 34) and the 2235 DOTS server SHOULD use any vendor mappings(s) provided to the DOTS 2236 client when transmitting telemetry data to the peer DOTS agent. 2238 The "ietf-dots-mapping" YANG module defined in Section 10.2 augments 2239 the "ietf-dots-data-channel" [RFC8783] module. The tree structure of 2240 the "ietf-dots-mapping" module is shown in Figure 30. 2242 module: ietf-dots-mapping 2243 augment /data-channel:dots-data/data-channel:dots-client: 2244 +--rw vendor-mapping {dots-telemetry}? 2245 +--rw vendor* [vendor-id] 2246 +--rw vendor-id uint32 2247 +--rw vendor-name? string 2248 +--rw last-updated uint64 2249 +--rw attack-mapping* [attack-id] 2250 +--rw attack-id uint32 2251 +--rw attack-description string 2252 augment /data-channel:dots-data/data-channel:capabilities: 2253 +--ro vendor-mapping-enabled? boolean {dots-telemetry}? 2254 augment /data-channel:dots-data: 2255 +--ro vendor-mapping {dots-telemetry}? 2256 +--ro vendor* [vendor-id] 2257 +--ro vendor-id uint32 2258 +--ro vendor-name? string 2259 +--ro last-updated uint64 2260 +--ro attack-mapping* [attack-id] 2261 +--ro attack-id uint32 2262 +--ro attack-description string 2264 Figure 30: Vendor Attack Mapping Tree Structure 2266 A DOTS client sends a GET request to retrieve the capabilities 2267 supported by a DOTS server as per Section 7.1 of [RFC8783]. This 2268 request is meant to assess whether the capability of sharing vendor 2269 attack mapping details is supported by the server (i.e., check the 2270 value of 'vendor-mapping-enabled'). 2272 If 'vendor-mapping-enabled' is set to 'true', A DOTS client MAY send 2273 a GET request to retrieve the DOTS server's vendor attack mapping 2274 details. An example of such a GET request is shown in Figure 31. 2276 GET /restconf/data/ietf-dots-data-channel:dots-data\ 2277 /ietf-dots-mapping:vendor-mapping HTTP/1.1 2278 Host: example.com 2279 Accept: application/yang-data+json 2281 Figure 31: GET to Retrieve the Vendor Attack Mappings of a DOTS 2282 Server 2284 A DOTS client can retrieve only the list of vendors supported by the 2285 DOTS server. It does so by setting the "depth" parameter 2286 (Section 4.8.2 of [RFC8040]) to "3" in the GET request as shown in 2287 Figure 32. An example of a response body received from the DOTS 2288 server as a response to such a request is illustrated in Figure 33. 2290 GET /restconf/data/ietf-dots-data-channel:dots-data\ 2291 /ietf-dots-mapping:vendor-mapping?depth=3 HTTP/1.1 2292 Host: example.com 2293 Accept: application/yang-data+json 2295 Figure 32: GET to Retrieve the Vendors List used by a DOTS Server 2297 { 2298 "ietf-dots-mapping:vendor-mapping": { 2299 "vendor": [ 2300 { 2301 "vendor-id": 32473, 2302 "vendor-name": "mitigator-s", 2303 "last-updated": "1629898758", 2304 "attack-mapping": [] 2305 } 2306 ] 2307 } 2308 } 2310 Figure 33: Response to a GET to Retrieve the Vendors List used by 2311 a DOTS Server 2313 The DOTS client reiterates the above procedure regularly (e.g., once 2314 a week) to update the DOTS server's vendor attack mapping details. 2316 If the DOTS client concludes that the DOTS server does not have any 2317 reference to the specific vendor attack mapping details, the DOTS 2318 client uses a POST request to install its vendor attack mapping 2319 details. An example of such a POST request is depicted in Figure 34. 2321 POST /restconf/data/ietf-dots-data-channel:dots-data\ 2322 /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1 2323 Host: example.com 2324 Content-Type: application/yang-data+json 2326 { 2327 "ietf-dots-mapping:vendor-mapping": { 2328 "vendor": [ 2329 { 2330 "vendor-id": 345, 2331 "vendor-name": "mitigator-c", 2332 "last-updated": "1629898958", 2333 "attack-mapping": [ 2334 { 2335 "attack-id": 1, 2336 "attack-description": 2337 "Include a description of this attack" 2338 }, 2339 { 2340 "attack-id": 2, 2341 "attack-description": 2342 "Again, include a description of the attack" 2343 } 2344 ] 2345 } 2346 ] 2347 } 2348 } 2350 Figure 34: POST to Install Vendor Attack Mapping Details 2352 The DOTS server indicates the result of processing the POST request 2353 using the status-line. Concretely, "201 Created" status-line MUST be 2354 returned in the response if the DOTS server has accepted the vendor 2355 attack mapping details. If the request is missing a mandatory 2356 attribute or contains an invalid or unknown parameter, "400 Bad 2357 Request" status-line MUST be returned by the DOTS server in the 2358 response. The error-tag is set to "missing-attribute", "invalid- 2359 value", or "unknown-element" as a function of the encountered error. 2361 If the request is received via a server-domain DOTS gateway, but the 2362 DOTS server does not maintain a 'cdid' for this 'cuid' while a 'cdid' 2363 is expected to be supplied, the DOTS server MUST reply with "403 2364 Forbidden" status-line and the error-tag "access-denied". Upon 2365 receipt of this message, the DOTS client MUST register (Section 5.1 2366 of [RFC8783]). 2368 The DOTS client uses the PUT request to modify its vendor attack 2369 mapping details maintained by the DOTS server (e.g., add a new 2370 mapping). 2372 A DOTS client uses a GET request to retrieve its vendor attack 2373 mapping details as maintained by the DOTS server (Figure 35). 2375 GET /restconf/data/ietf-dots-data-channel:dots-data\ 2376 /dots-client=dz6pHjaADkaFTbjr0JGBpw\ 2377 /ietf-dots-mapping:vendor-mapping?\ 2378 content=all HTTP/1.1 2379 Host: example.com 2380 Accept: application/yang-data+json 2382 Figure 35: GET to Retrieve Installed Vendor Attack Mapping Details 2384 When conveying attack details in DOTS telemetry messages (Sections 2385 7.2, 7.3, and 8), DOTS agents MUST NOT include the 'attack- 2386 description' attribute unless the corresponding attack mapping 2387 details were not previously shared with the peer DOTS agent. 2389 7.2. From DOTS Clients to DOTS Servers 2391 DOTS clients use PUT requests to signal pre-or-ongoing-mitigation 2392 telemetry to DOTS servers. An example of such a request is shown in 2393 Figure 36. 2395 Header: PUT (Code=0.03) 2396 Uri-Path: ".well-known" 2397 Uri-Path: "dots" 2398 Uri-Path: "tm" 2399 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2400 Uri-Path: "tmid=123" 2401 Content-Format: "application/dots+cbor" 2403 { 2404 "ietf-dots-telemetry:telemetry": { 2405 "pre-or-ongoing-mitigation": [ 2406 { 2407 "target": { 2408 "target-prefix": [ 2409 "2001:db8::1/128" 2410 ] 2411 }, 2412 "total-attack-traffic-protocol": [ 2413 { 2414 "protocol": 17, 2415 "unit": "megabit-ps", 2416 "mid-percentile-g": "900" 2417 } 2418 ], 2419 "attack-detail": [ 2420 { 2421 "vendor-id": 32473, 2422 "attack-id": 77, 2423 "start-time": "1608336568", 2424 "attack-severity": "high" 2425 } 2426 ] 2427 } 2428 ] 2429 } 2430 } 2432 Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry 2434 'cuid' is a mandatory Uri-Path parameter for DOTS PUT requests. 2436 The following additional Uri-Path parameter is defined: 2438 tmid: Telemetry Identifier is an identifier for the DOTS pre-or- 2439 ongoing-mitigation telemetry data represented as an integer. 2440 This identifier MUST be generated by DOTS clients. 'tmid' values 2441 MUST increase monotonically (when a new PUT is generated by a 2442 DOTS client to convey pre-or-ongoing-mitigation telemetry). 2444 The procedure specified in Section 4.4.1 of [RFC9132] for 'mid' 2445 rollover MUST be followed for 'tmid' rollover. 2447 This is a mandatory attribute. 'tmid' MUST follow 'cuid'. 2449 'cuid' and 'tmid' MUST NOT appear in the PUT request message body. 2451 At least the 'target' attribute and another pre-or-ongoing-mitigation 2452 attribute (Section 7.1) MUST be present in the PUT request. If only 2453 the 'target' attribute is present, this request is handled as per 2454 Section 7.3. 2456 The relative order of two PUT requests carrying DOTS pre-or-ongoing- 2457 mitigation telemetry from a DOTS client is determined by comparing 2458 their respective 'tmid' values. If two such requests have an 2459 overlapping 'target', the PUT request with higher numeric 'tmid' 2460 value will override the request with a lower numeric 'tmid' value. 2461 The overlapped lower numeric 'tmid' MUST be automatically deleted and 2462 no longer be available. 2464 The DOTS server indicates the result of processing a PUT request 2465 using CoAP Response Codes. In particular, the 2.04 (Changed) 2466 Response Code is returned if the DOTS server has accepted the pre-or- 2467 ongoing-mitigation telemetry. The 5.03 (Service Unavailable) 2468 Response Code is returned if the DOTS server has erred. 5.03 uses the 2469 Max-Age Option to indicate the number of seconds after which to 2470 retry. 2472 How long a DOTS server maintains a 'tmid' as active or logs the 2473 enclosed telemetry information is implementation specific. Note that 2474 if a 'tmid' is still active, then logging details are updated by the 2475 DOTS server as a function of the updates received from the peer DOTS 2476 client. 2478 A DOTS client that lost the state of its active 'tmid's or has to set 2479 'tmid' back to zero (e.g., crash or restart) MUST send a GET request 2480 to the DOTS server to retrieve the list of active 'tmid' values. The 2481 DOTS client may then delete 'tmid's that should not be active anymore 2482 (Figure 37). Sending a DELETE with no 'tmid' indicates that all 2483 'tmid's must be deactivated (Figure 38). 2485 Header: DELETE (Code=0.04) 2486 Uri-Path: ".well-known" 2487 Uri-Path: "dots" 2488 Uri-Path: "tm" 2489 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2490 Uri-Path: "tmid=123" 2491 Figure 37: Delete a Pre-or-Ongoing-Mitigation Telemetry 2493 Header: DELETE (Code=0.04) 2494 Uri-Path: ".well-known" 2495 Uri-Path: "dots" 2496 Uri-Path: "tm" 2497 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2499 Figure 38: Delete All Pre-or-Ongoing-Mitigation Telemetry 2501 7.3. From DOTS Servers to DOTS Clients 2503 The pre-or-ongoing-mitigation data (attack details, in particular) 2504 can also be signaled from DOTS servers to DOTS clients. For example, 2505 a DOTS server co-located with a DDoS detector can collect monitoring 2506 information from the target network, identify a DDoS attack using 2507 statistical analysis or deep learning techniques, and signal the 2508 attack details to the DOTS client. 2510 The DOTS client can use the attack details to decide whether to 2511 trigger a DOTS mitigation request or not. Furthermore, the security 2512 operations personnel at the DOTS client domain can use the attack 2513 details to determine the protection strategy and select the 2514 appropriate DOTS server for mitigating the attack. 2516 In order to receive pre-or-ongoing-mitigation telemetry notifications 2517 from a DOTS server, a DOTS client MUST send a PUT (followed by a GET) 2518 with the target filter. An example of such a PUT request is shown in 2519 Figure 39. In order to avoid maintaining a long list of such 2520 requests, it is RECOMMENDED that DOTS clients include all targets in 2521 the same request (assuming this fits within one single datagram). 2522 DOTS servers may be instructed to restrict the number of pre-or- 2523 ongoing-mitigation requests per DOTS client domain. The PUT request 2524 MUST be maintained in an active state by the DOTS server until a 2525 delete request is received from the same DOTS client to clear this 2526 pre-or-ongoing-mitigation telemetry or when the DOTS client is 2527 considered inactive (e.g., Section 3.5 of [RFC8783]). 2529 The relative order of two PUT requests carrying DOTS pre-or-ongoing- 2530 mitigation telemetry from a DOTS client is determined by comparing 2531 their respective 'tmid' values. If such two requests have 2532 overlapping 'target', the PUT request with higher numeric 'tmid' 2533 value will override the request with a lower numeric 'tmid' value. 2534 The overlapped lower numeric 'tmid' MUST be automatically deleted and 2535 no longer be available. 2537 Header: PUT (Code=0.03) 2538 Uri-Path: ".well-known" 2539 Uri-Path: "dots" 2540 Uri-Path: "tm" 2541 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2542 Uri-Path: "tmid=567" 2543 Content-Format: "application/dots+cbor" 2545 { 2546 "ietf-dots-telemetry:telemetry": { 2547 "pre-or-ongoing-mitigation": [ 2548 { 2549 "target": { 2550 "target-prefix": [ 2551 "2001:db8::/32" 2552 ] 2553 } 2554 } 2555 ] 2556 } 2557 } 2559 Figure 39: PUT to Request Pre-or-Ongoing-Mitigation Telemetry 2561 DOTS clients of the same domain can request to receive pre-or- 2562 ongoing-mitigation telemetry bound to the same target without being 2563 considered to be "overlapping" and in conflict. 2565 Once the PUT request to instantiate request state on the server has 2566 succeeded, the DOTS client issues a GET request to receive ongoing 2567 telemtry updates. The client uses the Observe Option, set to '0' 2568 (register), in the GET request to receive asynchronous notifications 2569 carrying pre-or-ongoing-mitigation telemetry data from the DOTS 2570 server. The GET request can specify a specific 'tmid' (Figure 40) or 2571 omit the 'tmid' (Figure 41) to receive updates on all active requests 2572 from that client. 2574 Header: GET (Code=0.01) 2575 Uri-Path: ".well-known" 2576 Uri-Path: "dots" 2577 Uri-Path: "tm" 2578 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2579 Uri-Path: "tmid=567" 2580 Observe: 0 2582 Figure 40: GET to Subscribe to Telemetry Asynchronous 2583 Notifications for a Specific 'tmid' 2585 Header: GET (Code=0.01) 2586 Uri-Path: ".well-known" 2587 Uri-Path: "dots" 2588 Uri-Path: "tm" 2589 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2590 Observe: 0 2592 Figure 41: GET to Subscribe to Telemetry Asynchronous 2593 Notifications for All 'tmids' 2595 The DOTS client can use a filter to request a subset of the 2596 asynchronous notifications from the DOTS server by indicating one or 2597 more Uri-Query options in its GET request. A Uri-Query option can 2598 include the following parameters to restrict the notifications based 2599 on the attack target: 'target-prefix', 'target-port', 'target- 2600 protocol', 'target-fqdn', 'target-uri', 'alias-name', 'mid', and 'c' 2601 (content) (Section 4.2.4). Furthermore: 2603 If more than one Uri-Query option is included in a request, these 2604 options are interpreted in the same way as when multiple target 2605 attributes are included in a message body (Section 4.4.1 of 2606 [RFC9132]). 2608 If multiple values of a query parameter are to be included in a 2609 request, these values MUST be included in the same Uri-Query 2610 option and separated by a "," character without any spaces. 2612 Range values (i.e., a contiguous inclusive block) can be included 2613 for the 'target-port', 'target-protocol', and 'mid' parameters by 2614 indicating the two boundary values separated by a "-" character. 2616 Wildcard names (i.e., a name with the leftmost label is the "*" 2617 character) can be included in 'target-fqdn' or 'target-uri' 2618 parameters. DOTS clients MUST NOT include a name in which the "*" 2619 character is included in a label other than the leftmost label. 2620 "*.example.com" is an example of a valid wildcard name that can be 2621 included as a value of the 'target-fqdn' parameter in an Uri-Query 2622 option. 2624 DOTS clients may also filter out the asynchronous notifications from 2625 the DOTS server by indicating information about a specific attack 2626 source. To that aim, a DOTS client may include 'source-prefix', 2627 'source-port', or 'source-icmp-type' in a Uri-Query option. The same 2628 considerations (ranges, multiple values) specified for target 2629 attributes apply for source attributes. Special care SHOULD be taken 2630 when using these filters as their use may cause some attacks may be 2631 hidden to the requesting DOTS client (e.g., if the attack changes its 2632 source information). 2634 Requests with invalid query types (e.g., not supported, malformed) 2635 received by the DOTS server MUST be rejected with a 4.00 (Bad 2636 Request) response code. 2638 An example of a request to subscribe to asynchronous telemetry 2639 notifications regarding UDP traffic is shown in Figure 42. This 2640 filter will be applied for all 'tmid's. 2642 Header: GET (Code=0.01) 2643 Uri-Path: ".well-known" 2644 Uri-Path: "dots" 2645 Uri-Path: "tm" 2646 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2647 Uri-Query: "target-protocol=17" 2648 Observe: 0 2650 Figure 42: GET Request to Receive Telemetry Asynchronous 2651 Notifications Filtered using Uri-Query 2653 The DOTS server will send asynchronous notifications to the DOTS 2654 client when an attack event is detected following similar 2655 considerations as in Section 4.4.2.1 of [RFC9132]. An example of a 2656 pre-or-ongoing-mitigation telemetry notification is shown in 2657 Figure 43. 2659 { 2660 "ietf-dots-telemetry:telemetry": { 2661 "pre-or-ongoing-mitigation": [ 2662 { 2663 "tmid": 567, 2664 "target": { 2665 "target-prefix": [ 2666 "2001:db8::1/128" 2667 ] 2668 }, 2669 "target-protocol": [ 2670 17 2671 ], 2672 "total-attack-traffic": [ 2673 { 2674 "unit": "megabit-ps", 2675 "mid-percentile-g": "900" 2676 } 2677 ], 2678 "attack-detail": [ 2679 { 2680 "vendor-id": 32473, 2681 "attack-id": 77, 2682 "start-time": "1618339785", 2683 "attack-severity": "high" 2684 } 2685 ] 2686 } 2687 ] 2688 } 2689 } 2691 Figure 43: Message Body of a Pre-or-Ongoing-Mitigation Telemetry 2692 Notification from the DOTS Server 2694 A DOTS server sends the aggregate data for a target using 'total- 2695 attack-traffic' attribute. The aggregate assumes that Uri-Query 2696 filters are applied on the target. The DOTS server MAY include more 2697 fine-grained data when needed (that is, 'total-attack-traffic- 2698 protocol' and 'total-attack-traffic-port'). If a port filter (or 2699 protocol filter) is included in a request, 'total-attack-traffic- 2700 protocol' (or 'total-attack-traffic-port') conveys the data with the 2701 port (or protocol) filter applied. 2703 A DOTS server may aggregate pre-or-ongoing-mitigation data (e.g., 2704 'top-talker') for all targets of a domain, or when justified, send 2705 specific information (e.g., 'top-talker') per individual targets. 2707 The DOTS client may log pre-or-ongoing-mitigation telemetry data with 2708 an alert sent to an administrator or a network controller. The DOTS 2709 client may send a mitigation request if the attack cannot be handled 2710 locally. 2712 A DOTS client that is not interested to receive pre-or-ongoing- 2713 mitigation telemetry data for a target sends a delete request similar 2714 to the one depicted in Figure 37. 2716 8. DOTS Telemetry Mitigation Status Update 2718 8.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry 2719 Attributes 2721 The mitigation efficacy telemetry attributes can be signaled from 2722 DOTS clients to DOTS servers as part of the periodic mitigation 2723 efficacy updates to the server (Section 4.4.3 of [RFC9132]). 2725 Total Attack Traffic: The overall attack traffic as observed from 2726 the DOTS client perspective during an active mitigation. See 2727 Figure 27. 2729 Attack Details: The overall attack details as observed from the DOTS 2730 client perspective during an active mitigation. See 2731 Section 7.1.5. 2733 The "ietf-dots-telemetry" YANG module (Section 10.1) augments the 2734 'mitigation-scope' message type defined in the "ietf-dots-signal" 2735 module [RFC9132] so that these attributes can be signalled by a DOTS 2736 client in a mitigation efficacy update (Figure 44). 2738 augment-structure /dots-signal:dots-signal/dots-signal:message-type 2739 /dots-signal:mitigation-scope/dots-signal:scope: 2740 +-- total-attack-traffic* [unit] 2741 | +-- unit unit 2742 | +-- low-percentile-g? yang:gauge64 2743 | +-- mid-percentile-g? yang:gauge64 2744 | +-- high-percentile-g? yang:gauge64 2745 | +-- peak-g? yang:gauge64 2746 | +-- current-g? yang:gauge64 2747 +-- attack-detail* [vendor-id attack-id] 2748 +-- vendor-id uint32 2749 +-- attack-id uint32 2750 +-- attack-description? string 2751 +-- attack-severity? attack-severity 2752 +-- start-time? uint64 2753 +-- end-time? uint64 2754 +-- source-count 2755 | +-- low-percentile-g? yang:gauge64 2756 | +-- mid-percentile-g? yang:gauge64 2757 | +-- high-percentile-g? yang:gauge64 2758 | +-- peak-g? yang:gauge64 2759 | +-- current-g? yang:gauge64 2760 +-- top-talker 2761 +-- talker* [source-prefix] 2762 +-- spoofed-status? boolean 2763 +-- source-prefix inet:ip-prefix 2764 +-- source-port-range* [lower-port] 2765 | +-- lower-port inet:port-number 2766 | +-- upper-port? inet:port-number 2767 +-- source-icmp-type-range* [lower-type] 2768 | +-- lower-type uint8 2769 | +-- upper-type? uint8 2770 +-- total-attack-traffic* [unit] 2771 | +-- unit unit 2772 | +-- low-percentile-g? yang:gauge64 2773 | +-- mid-percentile-g? yang:gauge64 2774 | +-- high-percentile-g? yang:gauge64 2775 | +-- peak-g? yang:gauge64 2776 | +-- current-g? yang:gauge64 2777 +-- total-attack-connection 2778 +-- connection-c 2779 | +-- low-percentile-g? yang:gauge64 2780 | +-- mid-percentile-g? yang:gauge64 2781 | +-- high-percentile-g? yang:gauge64 2782 | +-- peak-g? yang:gauge64 2783 | +-- current-g? yang:gauge64 2784 +-- embryonic-c 2785 | ... 2786 +-- connection-ps-c 2787 | ... 2788 +-- request-ps-c 2789 | ... 2790 +-- partial-request-c 2791 ... 2793 Figure 44: Telemetry Efficacy Update Tree Structure 2795 In order to signal telemetry data in a mitigation efficacy update, it 2796 is RECOMMENDED that the DOTS client has already established a DOTS 2797 telemetry setup session with the server in 'idle' time. 2799 An example of an efficacy update with telemetry attributes is 2800 depicted in Figure 45. 2802 Header: PUT (Code=0.03) 2803 Uri-Path: ".well-known" 2804 Uri-Path: "dots" 2805 Uri-Path: "mitigate" 2806 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2807 Uri-Path: "mid=123" 2808 If-Match: 2809 Content-Format: "application/dots+cbor" 2811 { 2812 "ietf-dots-signal-channel:mitigation-scope": { 2813 "scope": [ 2814 { 2815 "alias-name": [ 2816 "https1", 2817 "https2" 2818 ], 2819 "attack-status": "under-attack", 2820 "ietf-dots-telemetry:total-attack-traffic": [ 2821 { 2822 "unit": "megabit-ps", 2823 "mid-percentile-g": "900" 2824 } 2825 ] 2826 } 2827 ] 2828 } 2829 } 2831 Figure 45: An Example of Mitigation Efficacy Update with 2832 Telemetry Attributes 2834 8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry 2835 Attributes 2837 The mitigation status telemetry attributes can be signaled from the 2838 DOTS server to the DOTS client as part of the periodic mitigation 2839 status update (Section 4.4.2 of [RFC9132]). In particular, DOTS 2840 clients can receive asynchronous notifications of the attack details 2841 from DOTS servers using the Observe option defined in [RFC7641]. 2843 In order to make use of this feature, DOTS clients MUST establish a 2844 telemetry session with the DOTS server in 'idle' time and MUST set 2845 the 'server-originated-telemetry' attribute to 'true'. 2847 DOTS servers MUST NOT include telemetry attributes in mitigation 2848 status updates sent to DOTS clients for telemetry sessions in which 2849 the 'server-originated-telemetry' attribute is set to 'false'. 2851 As defined in [RFC8612], the actual mitigation activities can include 2852 several countermeasure mechanisms. The DOTS server signals the 2853 current operational status of relevant countermeasures. A list of 2854 attacks detected by these countermeasures MAY also be included. The 2855 same attributes defined in Section 7.1.5 are applicable for 2856 describing the attacks detected and mitigated at the DOTS server 2857 domain. 2859 The "ietf-dots-telemetry" YANG module (Section 10.1) augments the 2860 'mitigation-scope' message type defined in "ietf-dots-signal" 2861 [RFC9132] with telemetry data as depicted in the following tree 2862 structure: 2864 augment-structure /dots-signal:dots-signal/dots-signal:message-type 2865 /dots-signal:mitigation-scope/dots-signal:scope: 2866 +-- (direction)? 2867 | +--:(server-to-client-only) 2868 | +-- total-traffic* [unit] 2869 | | +-- unit unit 2870 | | +-- low-percentile-g? yang:gauge64 2871 | | +-- mid-percentile-g? yang:gauge64 2872 | | +-- high-percentile-g? yang:gauge64 2873 | | +-- peak-g? yang:gauge64 2874 | | +-- current-g? yang:gauge64 2875 | +-- total-attack-connection 2876 | +-- connection-c 2877 | | +-- low-percentile-g? yang:gauge64 2878 | | +-- mid-percentile-g? yang:gauge64 2879 | | +-- high-percentile-g? yang:gauge64 2880 | | +-- peak-g? yang:gauge64 2881 | | +-- current-g? yang:gauge64 2882 | +-- embryonic-c 2883 | | ... 2884 | +-- connection-ps-c 2885 | | ... 2886 | +-- request-ps-c 2887 | | ... 2888 | +-- partial-request-c 2889 | ... 2890 +-- total-attack-traffic* [unit] 2891 | +-- unit unit 2892 | +-- low-percentile-g? yang:gauge64 2893 | +-- mid-percentile-g? yang:gauge64 2894 | +-- high-percentile-g? yang:gauge64 2895 | +-- peak-g? yang:gauge64 2896 | +-- current-g? yang:gauge64 2897 +-- attack-detail* [vendor-id attack-id] 2898 +-- vendor-id uint32 2899 +-- attack-id uint32 2900 +-- attack-description? string 2901 +-- attack-severity? attack-severity 2902 +-- start-time? uint64 2903 +-- end-time? uint64 2904 +-- source-count 2905 | +-- low-percentile-g? yang:gauge64 2906 | +-- mid-percentile-g? yang:gauge64 2907 | +-- high-percentile-g? yang:gauge64 2908 | +-- peak-g? yang:gauge64 2909 | +-- current-g? yang:gauge64 2910 +-- top-talker 2911 +-- talker* [source-prefix] 2912 +-- spoofed-status? boolean 2913 +-- source-prefix inet:ip-prefix 2914 +-- source-port-range* [lower-port] 2915 | +-- lower-port inet:port-number 2916 | +-- upper-port? inet:port-number 2917 +-- source-icmp-type-range* [lower-type] 2918 | +-- lower-type uint8 2919 | +-- upper-type? uint8 2920 +-- total-attack-traffic* [unit] 2921 | +-- unit unit 2922 | +-- low-percentile-g? yang:gauge64 2923 | +-- mid-percentile-g? yang:gauge64 2924 | +-- high-percentile-g? yang:gauge64 2925 | +-- peak-g? yang:gauge64 2926 | +-- current-g? yang:gauge64 2927 +-- total-attack-connection 2928 +-- connection-c 2929 | +-- low-percentile-g? yang:gauge64 2930 | +-- mid-percentile-g? yang:gauge64 2931 | +-- high-percentile-g? yang:gauge64 2932 | +-- peak-g? yang:gauge64 2933 | +-- current-g? yang:gauge64 2934 +-- embryonic-c 2935 | ... 2936 +-- connection-ps-c 2937 | ... 2938 +-- request-ps-c 2939 | ... 2940 +-- partial-request-c 2941 ... 2943 Figure 46 shows an example of an asynchronous notification of attack 2944 mitigation status from the DOTS server. This notification signals 2945 both the mid-percentile value of processed attack traffic and the 2946 peak count of unique sources involved in the attack. 2948 { 2949 "ietf-dots-signal-channel:mitigation-scope": { 2950 "scope": [ 2951 { 2952 "mid": 12332, 2953 "mitigation-start": "1507818434", 2954 "alias-name": [ 2955 "https1", 2956 "https2" 2957 ], 2958 "lifetime": 1600, 2959 "status": "attack-successfully-mitigated", 2960 "bytes-dropped": "134334555", 2961 "bps-dropped": "43344", 2962 "pkts-dropped": "333334444", 2963 "pps-dropped": "432432", 2964 "ietf-dots-telemetry:total-attack-traffic": [ 2965 { 2966 "unit": "megabit-ps", 2967 "mid-percentile-g": "752" 2968 } 2969 ], 2970 "ietf-dots-telemetry:attack-detail": [ 2971 { 2972 "vendor-id": 32473, 2973 "attack-id": 77, 2974 "source-count": { 2975 "peak-g": "12683" 2976 } 2977 } 2978 ] 2979 } 2980 ] 2981 } 2982 } 2984 Figure 46: Response Body of a Mitigation Status With Telemetry 2985 Attributes 2987 DOTS clients can filter out the asynchronous notifications from the 2988 DOTS server by indicating one or more Uri-Query options in its GET 2989 request. A Uri-Query option can include the following parameters: 2990 'target-prefix', 'target-port', 'target-protocol', 'target-fqdn', 2991 'target-uri', 'alias-name', and 'c' (content) (Section 4.2.4). The 2992 considerations discussed in Section 7.3 MUST be followed to include 2993 multiple query values, ranges ('target-port', 'target-protocol'), and 2994 wildcard names ('target-fqdn', 'target-uri'). 2996 An example of request to subscribe to asynchronous notifications 2997 bound to the "http1" alias is shown in Figure 47. 2999 Header: GET (Code=0.01) 3000 Uri-Path: ".well-known" 3001 Uri-Path: "dots" 3002 Uri-Path: "mitigate" 3003 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 3004 Uri-Path: "mid=12332" 3005 Uri-Query: "target-alias=https1" 3006 Observe: 0 3008 Figure 47: GET Request to Receive Asynchronous Notifications 3009 Filtered using Uri- Query 3011 If the target query does not match the target of the enclosed 'mid' 3012 as maintained by the DOTS server, the latter MUST respond with a 4.04 3013 (Not Found) error Response Code. The DOTS server MUST NOT add a new 3014 observe entry if this query overlaps with an existing one. In such a 3015 case, the DOTS server replies with 4.09 (Conflict). 3017 9. Error Handling 3019 A list of common CoAP errors that are implemented by DOTS servers are 3020 provided in Section 9 of [RFC9132]. The following additional error 3021 cases apply for the telemetry extension: 3023 * 4.00 (Bad Request) is returned by the DOTS server when the DOTS 3024 client has sent a request that violates the DOTS telemetry 3025 extension. 3027 * 4.04 (Not Found) is returned by the DOTS server when the DOTS 3028 client is requesting a 'tsid' or 'tmid' that is not valid. 3030 * 4.00 (Bad Request) is returned by the DOTS server when the DOTS 3031 client has sent a request with invalid query types (e.g., not 3032 supported, malformed). 3034 * 4.04 (Not Found) is returned by the DOTS server when the DOTS 3035 client has sent a request with a target query that does not match 3036 the target of the enclosed 'mid' as maintained by the DOTS server. 3038 10. YANG Modules 3040 10.1. DOTS Signal Channel Telemetry YANG Module 3042 This module uses types defined in [RFC6991] and [RFC8345]. 3044 file "ietf-dots-telemetry@2021-11-29.yang" 3045 module ietf-dots-telemetry { 3046 yang-version 1.1; 3047 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry"; 3048 prefix dots-telemetry; 3050 import ietf-dots-signal-channel { 3051 prefix dots-signal; 3052 reference 3053 "RFC 9132: Distributed Denial-of-Service Open Threat Signaling 3054 (DOTS) Signal Channel Specification"; 3055 } 3056 import ietf-dots-data-channel { 3057 prefix data-channel; 3058 reference 3059 "RFC 8783: Distributed Denial-of-Service Open Threat 3060 Signaling (DOTS) Data Channel Specification"; 3061 } 3062 import ietf-yang-types { 3063 prefix yang; 3064 reference 3065 "Section 3 of RFC 6991"; 3066 } 3067 import ietf-inet-types { 3068 prefix inet; 3069 reference 3070 "Section 4 of RFC 6991"; 3071 } 3072 import ietf-network-topology { 3073 prefix nt; 3074 reference 3075 "Section 6.2 of RFC 8345: A YANG Data Model for Network 3076 Topologies"; 3077 } 3078 import ietf-yang-structure-ext { 3079 prefix sx; 3080 reference 3081 "RFC 8791: YANG Data Structure Extensions"; 3082 } 3084 organization 3085 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 3086 contact 3087 "WG Web: 3088 WG List: 3090 Author: Mohamed Boucadair 3091 3093 Author: Konda, Tirumaleswar Reddy 3094 "; 3095 description 3096 "This module contains YANG definitions for the signaling 3097 of DOTS telemetry data exchanged between a DOTS client and 3098 a DOTS server by means of the DOTS signal channel. 3100 Copyright (c) 2021 IETF Trust and the persons identified as 3101 authors of the code. All rights reserved. 3103 Redistribution and use in source and binary forms, with or 3104 without modification, is permitted pursuant to, and subject 3105 to the license terms contained in, the Simplified BSD License 3106 set forth in Section 4.c of the IETF Trust's Legal Provisions 3107 Relating to IETF Documents 3108 (http://trustee.ietf.org/license-info). 3110 This version of this YANG module is part of RFC XXXX; see 3111 the RFC itself for full legal notices."; 3113 revision 2021-11-29 { 3114 description 3115 "Initial revision."; 3116 reference 3117 "RFC XXXX: Distributed Denial-of-Service Open Threat 3118 Signaling (DOTS) Telemetry"; 3119 } 3121 typedef attack-severity { 3122 type enumeration { 3123 enum none { 3124 value 1; 3125 description 3126 "No effect on the DOTS client domain."; 3127 } 3128 enum low { 3129 value 2; 3130 description 3131 "Minimal effect on the DOTS client domain."; 3132 } 3133 enum medium { 3134 value 3; 3135 description 3136 "A subset of DOTS client domain resources are 3137 out of service."; 3138 } 3139 enum high { 3140 value 4; 3141 description 3142 "The DOTS client domain is under extremly severe 3143 conditions."; 3144 } 3145 enum unknown { 3146 value 5; 3147 description 3148 "The impact of the attack is not known."; 3149 } 3150 } 3151 description 3152 "Enumeration for attack severity."; 3153 reference 3154 "RFC 7970: The Incident Object Description Exchange 3155 Format Version 2, Section 3.12.2"; 3156 } 3158 typedef unit-class { 3159 type enumeration { 3160 enum packet-ps { 3161 value 1; 3162 description 3163 "Packets per second (pps)."; 3164 } 3165 enum bit-ps { 3166 value 2; 3167 description 3168 "Bits per Second (bit/s)."; 3169 } 3170 enum byte-ps { 3171 value 3; 3172 description 3173 "Bytes per second (Byte/s)."; 3174 } 3175 } 3176 description 3177 "Enumeration to indicate which unit class is used. 3178 These classes are supported: pps, bit/s, and Byte/s."; 3179 } 3180 typedef unit { 3181 type enumeration { 3182 enum packet-ps { 3183 value 1; 3184 description 3185 "Packets per second (pps)."; 3186 } 3187 enum bit-ps { 3188 value 2; 3189 description 3190 "Bits per Second (bps)."; 3191 } 3192 enum byte-ps { 3193 value 3; 3194 description 3195 "Bytes per second (Bps)."; 3196 } 3197 enum kilopacket-ps { 3198 value 4; 3199 description 3200 "Kilo packets per second (kpps)."; 3201 } 3202 enum kilobit-ps { 3203 value 5; 3204 description 3205 "Kilobits per second (kbps)."; 3206 } 3207 enum kilobyte-ps { 3208 value 6; 3209 description 3210 "Kilobytes per second (kBps)."; 3211 } 3212 enum megapacket-ps { 3213 value 7; 3214 description 3215 "Mega packets per second (Mpps)."; 3216 } 3217 enum megabit-ps { 3218 value 8; 3219 description 3220 "Megabits per second (Mbps)."; 3221 } 3222 enum megabyte-ps { 3223 value 9; 3224 description 3225 "Megabytes per second (MBps)."; 3226 } 3227 enum gigapacket-ps { 3228 value 10; 3229 description 3230 "Giga packets per second (Gpps)."; 3231 } 3232 enum gigabit-ps { 3233 value 11; 3234 description 3235 "Gigabits per second (Gbps)."; 3236 } 3237 enum gigabyte-ps { 3238 value 12; 3239 description 3240 "Gigabytes per second (GBps)."; 3241 } 3242 enum terapacket-ps { 3243 value 13; 3244 description 3245 "Tera packets per second (Tpps)."; 3246 } 3247 enum terabit-ps { 3248 value 14; 3249 description 3250 "Terabits per second (Tbps)."; 3251 } 3252 enum terabyte-ps { 3253 value 15; 3254 description 3255 "Terabytes per second (TBps)."; 3256 } 3257 enum petapacket-ps { 3258 value 16; 3259 description 3260 "Peta packets per second (Ppps)."; 3261 } 3262 enum petabit-ps { 3263 value 17; 3264 description 3265 "Petabits per second (Pbps)."; 3266 } 3267 enum petabyte-ps { 3268 value 18; 3269 description 3270 "Petabytes per second (PBps)."; 3271 } 3272 enum exapacket-ps { 3273 value 19; 3274 description 3275 "Exa packets per second (Epps)."; 3277 } 3278 enum exabit-ps { 3279 value 20; 3280 description 3281 "Exabits per second (Ebps)."; 3282 } 3283 enum exabyte-ps { 3284 value 21; 3285 description 3286 "Exabytes per second (EBps)."; 3287 } 3288 enum zettapacket-ps { 3289 value 22; 3290 description 3291 "Zetta packets per second (Zpps)."; 3292 } 3293 enum zettabit-ps { 3294 value 23; 3295 description 3296 "Zettabits per second (Zbps)."; 3297 } 3298 enum zettabyte-ps { 3299 value 24; 3300 description 3301 "Zettabytes per second (ZBps)."; 3302 } 3303 } 3304 description 3305 "Enumeration to indicate which unit is used. 3306 Only one unit per unit class is used owing to 3307 unit auto-scaling."; 3308 } 3310 typedef interval { 3311 type enumeration { 3312 enum 5-minutes { 3313 value 1; 3314 description 3315 "5 minutes."; 3316 } 3317 enum 10-minutes { 3318 value 2; 3319 description 3320 "10 minutes."; 3321 } 3322 enum 30-minutes { 3323 value 3; 3324 description 3325 "30 minutes."; 3326 } 3327 enum hour { 3328 value 4; 3329 description 3330 "Hour."; 3331 } 3332 enum day { 3333 value 5; 3334 description 3335 "Day."; 3336 } 3337 enum week { 3338 value 6; 3339 description 3340 "Week."; 3341 } 3342 enum month { 3343 value 7; 3344 description 3345 "Month."; 3346 } 3347 } 3348 description 3349 "Enumeration to indicate the overall measurement period."; 3350 } 3352 typedef sample { 3353 type enumeration { 3354 enum second { 3355 value 1; 3356 description 3357 "A one-second measurement period."; 3358 } 3359 enum 5-seconds { 3360 value 2; 3361 description 3362 "5-second measurement period."; 3363 } 3364 enum 30-seconds { 3365 value 3; 3366 description 3367 "30-second measurement period."; 3368 } 3369 enum minute { 3370 value 4; 3371 description 3372 "One-minute measurement period."; 3374 } 3375 enum 5-minutes { 3376 value 5; 3377 description 3378 "5-minute measurement period."; 3379 } 3380 enum 10-minutes { 3381 value 6; 3382 description 3383 "10-minute measurement period."; 3384 } 3385 enum 30-minutes { 3386 value 7; 3387 description 3388 "30-minute measurement period."; 3389 } 3390 enum hour { 3391 value 8; 3392 description 3393 "One-hour measurement period."; 3394 } 3395 } 3396 description 3397 "Enumeration to indicate the sampling period."; 3398 } 3400 typedef percentile { 3401 type decimal64 { 3402 fraction-digits 2; 3403 } 3404 description 3405 "The nth percentile of a set of data is the 3406 value at which n percent of the data is below it."; 3407 } 3409 typedef query-type { 3410 type enumeration { 3411 enum target-prefix { 3412 value 1; 3413 description 3414 "Query based on target prefix."; 3415 } 3416 enum target-port { 3417 value 2; 3418 description 3419 "Query based on target port number."; 3420 } 3421 enum target-protocol { 3422 value 3; 3423 description 3424 "Query based on target protocol."; 3425 } 3426 enum target-fqdn { 3427 value 4; 3428 description 3429 "Query based on target FQDN."; 3430 } 3431 enum target-uri { 3432 value 5; 3433 description 3434 "Query based on target URI."; 3435 } 3436 enum target-alias { 3437 value 6; 3438 description 3439 "Query based on target alias."; 3440 } 3441 enum mid { 3442 value 7; 3443 description 3444 "Query based on mitigation identifier (mid)."; 3445 } 3446 enum source-prefix { 3447 value 8; 3448 description 3449 "Query based on source prefix."; 3450 } 3451 enum source-port { 3452 value 9; 3453 description 3454 "Query based on source port number."; 3455 } 3456 enum source-icmp-type { 3457 value 10; 3458 description 3459 "Query based on ICMP type"; 3460 } 3461 enum content { 3462 value 11; 3463 description 3464 "Query based on 'c' Uri-Query option that is used 3465 to control the selection of configuration 3466 and non-configuration data nodes."; 3467 reference 3468 "Section 4.4.2 of RFC UUUU."; 3469 } 3471 } 3472 description 3473 "Enumeration of support for query types that can be used 3474 in a GET request to filter out data. Requests with 3475 invalid query types (e.g., not supported, malformed) 3476 received by the DOTS server are rejected with 3477 a 4.00 (Bad Request) response code."; 3478 } 3480 grouping telemetry-parameters { 3481 description 3482 "A grouping that includes a set of parameters that 3483 are used to prepare the reported telemetry data. 3485 The grouping indicates a measurement interval, 3486 a measurement sample period, and low/mid/high 3487 percentile values."; 3488 leaf measurement-interval { 3489 type interval; 3490 description 3491 "Defines the period on which percentiles are computed."; 3492 } 3493 leaf measurement-sample { 3494 type sample; 3495 description 3496 "Defines the time distribution for measuring 3497 values that are used to compute percentiles. 3499 The measurement sample value must be less than the 3500 measurement interval value."; 3501 } 3502 leaf low-percentile { 3503 type percentile; 3504 default "10.00"; 3505 description 3506 "Low percentile. If set to '0', this means low-percentiles 3507 are disabled."; 3508 } 3509 leaf mid-percentile { 3510 type percentile; 3511 must '. >= ../low-percentile' { 3512 error-message 3513 "The mid-percentile must be greater than 3514 or equal to the low-percentile."; 3515 } 3516 default "50.00"; 3517 description 3518 "Mid percentile. If set to the same value as low-percentile, 3519 this means mid-percentiles are disabled."; 3520 } 3521 leaf high-percentile { 3522 type percentile; 3523 must '. >= ../mid-percentile' { 3524 error-message 3525 "The high-percentile must be greater than 3526 or equal to the mid-percentile."; 3527 } 3528 default "90.00"; 3529 description 3530 "High percentile. If set to the same value as mid-percentile, 3531 this means high-percentiles are disabled."; 3532 } 3533 } 3535 grouping percentile-and-peak { 3536 description 3537 "Generic grouping for percentile and peak values."; 3538 leaf low-percentile-g { 3539 type yang:gauge64; 3540 description 3541 "Low percentile value."; 3542 } 3543 leaf mid-percentile-g { 3544 type yang:gauge64; 3545 description 3546 "Mid percentile value."; 3547 } 3548 leaf high-percentile-g { 3549 type yang:gauge64; 3550 description 3551 "High percentile value."; 3552 } 3553 leaf peak-g { 3554 type yang:gauge64; 3555 description 3556 "Peak value."; 3557 } 3558 } 3560 grouping percentile-peak-and-current { 3561 description 3562 "Generic grouping for percentile and peak values."; 3563 uses percentile-and-peak; 3564 leaf current-g { 3565 type yang:gauge64; 3566 description 3567 "Current value."; 3568 } 3569 } 3571 grouping unit-config { 3572 description 3573 "Generic grouping for unit configuration."; 3574 list unit-config { 3575 key "unit"; 3576 description 3577 "Controls which unit classes are allowed when sharing 3578 telemetry data."; 3579 leaf unit { 3580 type unit-class; 3581 description 3582 "Can be packet-ps, bit-ps, or byte-ps."; 3583 } 3584 leaf unit-status { 3585 type boolean; 3586 mandatory true; 3587 description 3588 "Enable/disable the use of the measurement unit class."; 3589 } 3590 } 3591 } 3593 grouping traffic-unit { 3594 description 3595 "Grouping of traffic as a function of the measurement unit."; 3596 leaf unit { 3597 type unit; 3598 description 3599 "The traffic can be measured using unit classes: packet-ps, 3600 bit-ps, or byte-ps. DOTS agents auto-scale to the 3601 appropriate units (e.g., megabit-ps, kilobit-ps)."; 3602 } 3603 uses percentile-and-peak; 3604 } 3606 grouping traffic-unit-all { 3607 description 3608 "Grouping of traffic as a function of the measurement unit, 3609 including current values."; 3610 uses traffic-unit; 3611 leaf current-g { 3612 type yang:gauge64; 3613 description 3614 "Current observed value."; 3616 } 3617 } 3619 grouping traffic-unit-protocol { 3620 description 3621 "Grouping of traffic of a given transport protocol as 3622 a function of the measurement unit."; 3623 leaf protocol { 3624 type uint8; 3625 description 3626 "The transport protocol. 3627 Values are taken from the IANA Protocol Numbers registry: 3628 . 3630 For example, this parameter contains 6 for TCP, 3631 17 for UDP, 33 for DCCP, or 132 for SCTP."; 3632 } 3633 uses traffic-unit; 3634 } 3636 grouping traffic-unit-protocol-all { 3637 description 3638 "Grouping of traffic of a given transport protocol as 3639 a function of the measurement unit, including current 3640 values."; 3641 uses traffic-unit-protocol; 3642 leaf current-g { 3643 type yang:gauge64; 3644 description 3645 "Current observed value."; 3646 } 3647 } 3649 grouping traffic-unit-port { 3650 description 3651 "Grouping of traffic bound to a port number as 3652 a function of the measurement unit."; 3653 leaf port { 3654 type inet:port-number; 3655 description 3656 "Port number used by a transport protocol."; 3657 } 3658 uses traffic-unit; 3659 } 3661 grouping traffic-unit-port-all { 3662 description 3663 "Grouping of traffic bound to a port number as 3664 a function of the measurement unit, including 3665 current values."; 3666 uses traffic-unit-port; 3667 leaf current-g { 3668 type yang:gauge64; 3669 description 3670 "Current observed value."; 3671 } 3672 } 3674 grouping total-connection-capacity { 3675 description 3676 "Total connection capacities for various types of 3677 connections, as well as overall capacity. These data nodes are 3678 useful to detect resource-consuming DDoS attacks."; 3679 leaf connection { 3680 type uint64; 3681 description 3682 "The maximum number of simultaneous connections that 3683 are allowed to the target server."; 3684 } 3685 leaf connection-client { 3686 type uint64; 3687 description 3688 "The maximum number of simultaneous connections that 3689 are allowed to the target server per client."; 3690 } 3691 leaf embryonic { 3692 type uint64; 3693 description 3694 "The maximum number of simultaneous embryonic connections 3695 that are allowed to the target server. The term 'embryonic 3696 connection' refers to a connection whose connection 3697 handshake is not finished. Embryonic connections are only 3698 possible in connection-oriented transport protocols like 3699 TCP or SCTP."; 3700 } 3701 leaf embryonic-client { 3702 type uint64; 3703 description 3704 "The maximum number of simultaneous embryonic connections 3705 that are allowed to the target server per client."; 3706 } 3707 leaf connection-ps { 3708 type uint64; 3709 description 3710 "The maximum number of new connections allowed per second 3711 to the target server."; 3713 } 3714 leaf connection-client-ps { 3715 type uint64; 3716 description 3717 "The maximum number of new connections allowed per second 3718 to the target server per client."; 3719 } 3720 leaf request-ps { 3721 type uint64; 3722 description 3723 "The maximum number of requests allowed per second 3724 to the target server."; 3725 } 3726 leaf request-client-ps { 3727 type uint64; 3728 description 3729 "The maximum number of requests allowed per second 3730 to the target server per client."; 3731 } 3732 leaf partial-request-max { 3733 type uint64; 3734 description 3735 "The maximum number of outstanding partial requests 3736 that are allowed to the target server."; 3737 } 3738 leaf partial-request-client-max { 3739 type uint64; 3740 description 3741 "The maximum number of outstanding partial requests 3742 that are allowed to the target server per client."; 3743 } 3744 } 3746 grouping total-connection-capacity-protocol { 3747 description 3748 "Total connections capacity per protocol. These data nodes are 3749 useful to detect resource consuming DDoS attacks."; 3750 leaf protocol { 3751 type uint8; 3752 description 3753 "The transport protocol. 3754 Values are taken from the IANA Protocol Numbers registry: 3755 ."; 3756 } 3757 uses total-connection-capacity; 3758 } 3760 grouping connection-percentile-and-peak { 3761 description 3762 "A set of data nodes which represent the attack 3763 characteristics."; 3764 container connection-c { 3765 uses percentile-and-peak; 3766 description 3767 "The number of simultaneous attack connections to 3768 the target server."; 3769 } 3770 container embryonic-c { 3771 uses percentile-and-peak; 3772 description 3773 "The number of simultaneous embryonic connections to 3774 the target server."; 3775 } 3776 container connection-ps-c { 3777 uses percentile-and-peak; 3778 description 3779 "The number of attack connections per second to 3780 the target server."; 3781 } 3782 container request-ps-c { 3783 uses percentile-and-peak; 3784 description 3785 "The number of attack requests per second to 3786 the target server."; 3787 } 3788 container partial-request-c { 3789 uses percentile-and-peak; 3790 description 3791 "The number of attack partial requests to 3792 the target server."; 3793 } 3794 } 3796 grouping connection-all { 3797 description 3798 "Total attack connections including current values."; 3799 container connection-c { 3800 uses percentile-peak-and-current; 3801 description 3802 "The number of simultaneous attack connections to 3803 the target server."; 3804 } 3805 container embryonic-c { 3806 uses percentile-peak-and-current; 3807 description 3808 "The number of simultaneous embryonic connections to 3809 the target server."; 3810 } 3811 container connection-ps-c { 3812 uses percentile-peak-and-current; 3813 description 3814 "The number of attack connections per second to 3815 the target server."; 3816 } 3817 container request-ps-c { 3818 uses percentile-peak-and-current; 3819 description 3820 "The number of attack requests per second to 3821 the target server."; 3822 } 3823 container partial-request-c { 3824 uses percentile-peak-and-current; 3825 description 3826 "The number of attack partial requests to 3827 the target server."; 3828 } 3829 } 3831 grouping connection-protocol { 3832 description 3833 "Total attack connections."; 3834 leaf protocol { 3835 type uint8; 3836 description 3837 "The transport protocol. 3838 Values are taken from the IANA Protocol Numbers registry: 3839 ."; 3840 } 3841 uses connection-percentile-and-peak; 3842 } 3844 grouping connection-port { 3845 description 3846 "Total attack connections per port number."; 3847 leaf protocol { 3848 type uint8; 3849 description 3850 "The transport protocol. 3851 Values are taken from the IANA Protocol Numbers registry: 3852 ."; 3853 } 3854 leaf port { 3855 type inet:port-number; 3856 description 3857 "Port number."; 3858 } 3859 uses connection-percentile-and-peak; 3860 } 3862 grouping connection-protocol-all { 3863 description 3864 "Total attack connections per protocol, including current 3865 values."; 3866 leaf protocol { 3867 type uint8; 3868 description 3869 "The transport protocol. 3870 Values are taken from the IANA Protocol Numbers registry: 3871 ."; 3872 } 3873 uses connection-all; 3874 } 3876 grouping connection-protocol-port-all { 3877 description 3878 "Total attack connections per port number, including current 3879 values."; 3880 leaf protocol { 3881 type uint8; 3882 description 3883 "The transport protocol. 3884 Values are taken from the IANA Protocol Numbers registry: 3885 ."; 3886 } 3887 leaf port { 3888 type inet:port-number; 3889 description 3890 "Port number."; 3891 } 3892 uses connection-all; 3893 } 3895 grouping attack-detail { 3896 description 3897 "Various details that describe the on-going 3898 attacks that need to be mitigated by the DOTS server. 3899 The attack details need to cover well-known and common attacks 3900 (such as a SYN Flood) along with new emerging or 3901 vendor-specific attacks."; 3902 leaf vendor-id { 3903 type uint32; 3904 description 3905 "Vendor ID is a security vendor's Enterprise Number as 3906 as registered with IANA."; 3907 reference 3908 "IANA: Private Enterprise Numbers"; 3909 } 3910 leaf attack-id { 3911 type uint32; 3912 description 3913 "Unique identifier assigned by the vendor for the attack."; 3914 } 3915 leaf attack-description { 3916 type string; 3917 description 3918 "Textual representation of attack description. Natural 3919 Language Processing techniques (e.g., word embedding) 3920 might provide some utility in mapping the attack 3921 description to an attack type."; 3922 } 3923 leaf attack-severity { 3924 type attack-severity; 3925 description 3926 "Severity level of an attack. How this level is determined 3927 is implementation-specific."; 3928 } 3929 leaf start-time { 3930 type uint64; 3931 description 3932 "The time the attack started. Start time is represented in 3933 seconds relative to 1970-01-01T00:00:00Z."; 3934 } 3935 leaf end-time { 3936 type uint64; 3937 description 3938 "The time the attack ended. End time is represented in 3939 seconds relative to 1970-01-01T00:00:00Z."; 3940 } 3941 container source-count { 3942 description 3943 "Indicates the count of unique sources involved 3944 in the attack."; 3945 uses percentile-and-peak; 3946 leaf current-g { 3947 type yang:gauge64; 3948 description 3949 "Current observed value."; 3950 } 3951 } 3952 } 3953 grouping talker { 3954 description 3955 "Defines generic data related to top-talkers."; 3956 leaf spoofed-status { 3957 type boolean; 3958 description 3959 "When set to 'true', it indicates whether this address 3960 is spoofed."; 3961 } 3962 leaf source-prefix { 3963 type inet:ip-prefix; 3964 description 3965 "IPv4 or IPv6 prefix identifying the attacker(s)."; 3966 } 3967 list source-port-range { 3968 key "lower-port"; 3969 description 3970 "Port range. When only lower-port is 3971 present, it represents a single port number."; 3972 leaf lower-port { 3973 type inet:port-number; 3974 description 3975 "Lower port number of the port range."; 3976 } 3977 leaf upper-port { 3978 type inet:port-number; 3979 must '. >= ../lower-port' { 3980 error-message 3981 "The upper port number must be greater than 3982 or equal to lower port number."; 3983 } 3984 description 3985 "Upper port number of the port range."; 3986 } 3987 } 3988 list source-icmp-type-range { 3989 key "lower-type"; 3990 description 3991 "ICMP type range. When only lower-type is 3992 present, it represents a single ICMP type."; 3993 leaf lower-type { 3994 type uint8; 3995 description 3996 "Lower ICMP type of the ICMP type range."; 3997 } 3998 leaf upper-type { 3999 type uint8; 4000 must '. >= ../lower-type' { 4001 error-message 4002 "The upper ICMP type must be greater than 4003 or equal to lower ICMP type."; 4004 } 4005 description 4006 "Upper type of the ICMP type range."; 4007 } 4008 } 4009 list total-attack-traffic { 4010 key "unit"; 4011 description 4012 "Total attack traffic issued from this source."; 4013 uses traffic-unit-all; 4014 } 4015 } 4017 grouping top-talker-aggregate { 4018 description 4019 "An aggregate of top attack sources. This aggregate is 4020 typically used when included in a mitigation request."; 4021 list talker { 4022 key "source-prefix"; 4023 description 4024 "Refers to a top-talker that is identified by an IPv4 4025 or IPv6 prefix identifying the attacker(s)."; 4026 uses talker; 4027 container total-attack-connection { 4028 description 4029 "Total attack connections issued from this source."; 4030 uses connection-all; 4031 } 4032 } 4033 } 4035 grouping top-talker { 4036 description 4037 "Top attack sources with detailed per-protocol 4038 structure."; 4039 list talker { 4040 key "source-prefix"; 4041 description 4042 "Refers to a top-talker that is identified by an IPv4 4043 or IPv6 prefix identifying the attacker(s)."; 4044 uses talker; 4045 list total-attack-connection-protocol { 4046 key "protocol"; 4047 description 4048 "Total attack connections issued from this source."; 4050 uses connection-protocol-all; 4051 } 4052 } 4053 } 4055 grouping baseline { 4056 description 4057 "Grouping for the telemetry baseline."; 4058 uses data-channel:target; 4059 leaf-list alias-name { 4060 type string; 4061 description 4062 "An alias name that points to an IP resource. 4063 An IP resource can be be a router, a host, 4064 an IoT object, a server, etc."; 4065 } 4066 list total-traffic-normal { 4067 key "unit"; 4068 description 4069 "Total traffic normal baselines."; 4070 uses traffic-unit; 4071 } 4072 list total-traffic-normal-per-protocol { 4073 key "unit protocol"; 4074 description 4075 "Total traffic normal baselines per protocol."; 4076 uses traffic-unit-protocol; 4077 } 4078 list total-traffic-normal-per-port { 4079 key "unit port"; 4080 description 4081 "Total traffic normal baselines per port number."; 4082 uses traffic-unit-port; 4083 } 4084 list total-connection-capacity { 4085 key "protocol"; 4086 description 4087 "Total connection capacity."; 4088 uses total-connection-capacity-protocol; 4089 } 4090 list total-connection-capacity-per-port { 4091 key "protocol port"; 4092 description 4093 "Total connection capacity per port number."; 4094 leaf port { 4095 type inet:port-number; 4096 description 4097 "The target port number."; 4099 } 4100 uses total-connection-capacity-protocol; 4101 } 4102 } 4104 grouping pre-or-ongoing-mitigation { 4105 description 4106 "Grouping for the telemetry data."; 4107 list total-traffic { 4108 key "unit"; 4109 description 4110 "Total traffic."; 4111 uses traffic-unit-all; 4112 } 4113 list total-traffic-protocol { 4114 key "unit protocol"; 4115 description 4116 "Total traffic per protocol."; 4117 uses traffic-unit-protocol-all; 4118 } 4119 list total-traffic-port { 4120 key "unit port"; 4121 description 4122 "Total traffic per port number."; 4123 uses traffic-unit-port-all; 4124 } 4125 list total-attack-traffic { 4126 key "unit"; 4127 description 4128 "Total attack traffic."; 4129 uses traffic-unit-all; 4130 } 4131 list total-attack-traffic-protocol { 4132 key "unit protocol"; 4133 description 4134 "Total attack traffic per protocol."; 4135 uses traffic-unit-protocol-all; 4136 } 4137 list total-attack-traffic-port { 4138 key "unit port"; 4139 description 4140 "Total attack traffic per port number."; 4141 uses traffic-unit-port-all; 4142 } 4143 list total-attack-connection-protocol { 4144 key "protocol"; 4145 description 4146 "Total attack connections."; 4148 uses connection-protocol-all; 4149 } 4150 list total-attack-connection-port { 4151 key "protocol port"; 4152 description 4153 "Total attack connections per target port number."; 4154 uses connection-protocol-port-all; 4155 } 4156 list attack-detail { 4157 key "vendor-id attack-id"; 4158 description 4159 "Provides a set of attack details."; 4160 uses attack-detail; 4161 container top-talker { 4162 description 4163 "Lists the top attack sources."; 4164 uses top-talker; 4165 } 4166 } 4167 } 4169 sx:augment-structure "/dots-signal:dots-signal" 4170 + "/dots-signal:message-type" 4171 + "/dots-signal:mitigation-scope" 4172 + "/dots-signal:scope" { 4173 description 4174 "Extends mitigation scope with telemetry update data."; 4175 choice direction { 4176 description 4177 "Indicates the communication direction in which the 4178 data nodes can be included."; 4179 case server-to-client-only { 4180 description 4181 "These data nodes appear only in a mitigation message 4182 sent from the server to the client."; 4183 list total-traffic { 4184 key "unit"; 4185 description 4186 "Total traffic."; 4187 uses traffic-unit-all; 4188 } 4189 container total-attack-connection { 4190 description 4191 "Total attack connections."; 4192 uses connection-all; 4193 } 4194 } 4195 } 4196 list total-attack-traffic { 4197 key "unit"; 4198 description 4199 "Total attack traffic."; 4200 uses traffic-unit-all; 4201 } 4202 list attack-detail { 4203 key "vendor-id attack-id"; 4204 description 4205 "Attack details"; 4206 uses attack-detail; 4207 container top-talker { 4208 description 4209 "Top attack sources."; 4210 uses top-talker-aggregate; 4211 } 4212 } 4213 } 4214 sx:structure dots-telemetry { 4215 description 4216 "Main structure for DOTS telemetry messages."; 4217 choice telemetry-message-type { 4218 description 4219 "Can be a telemetry-setup or telemetry data."; 4220 case telemetry-setup { 4221 description 4222 "Indicates the message is about telemetry steup."; 4223 choice direction { 4224 description 4225 "Indicates the communication direction in which the 4226 data nodes can be included."; 4227 case server-to-client-only { 4228 description 4229 "These data nodes appear only in a mitigation message 4230 sent from the server to the client."; 4231 container max-config-values { 4232 description 4233 "Maximum acceptable configuration values."; 4234 uses telemetry-parameters; 4235 leaf server-originated-telemetry { 4236 type boolean; 4237 default "false"; 4238 description 4239 "Indicates whether the DOTS server can be 4240 instructed to send pre-or-ongoing-mitigation 4241 telemetry. If set to 'false' or the data node 4242 is not present, this is an indication that 4243 the server does not support this capability."; 4245 } 4246 leaf telemetry-notify-interval { 4247 type uint16 { 4248 range "1 .. 3600"; 4249 } 4250 units "seconds"; 4251 must '. >= ../../min-config-values' 4252 + '/telemetry-notify-interval' { 4253 error-message 4254 "The value must be greater than or equal 4255 to the telemetry-notify-interval in the 4256 min-config-values"; 4257 } 4258 description 4259 "Minimum number of seconds between successive 4260 telemetry notifications."; 4261 } 4262 } 4263 container min-config-values { 4264 description 4265 "Minimum acceptable configuration values."; 4266 uses telemetry-parameters; 4267 leaf telemetry-notify-interval { 4268 type uint16 { 4269 range "1 .. 3600"; 4270 } 4271 units "seconds"; 4272 description 4273 "Minimum number of seconds between successive 4274 telemetry notifications."; 4275 } 4276 } 4277 container supported-unit-classes { 4278 description 4279 "Supported unit classes and default activation 4280 status."; 4281 uses unit-config; 4282 } 4283 leaf-list supported-query-type { 4284 type query-type; 4285 description 4286 "Indicates which query types are supported by 4287 the server. If the server does not announce 4288 the query types it supports, the client will 4289 be unable to use any of the potential 4290 query-type values to reduce the returned data 4291 content from the server."; 4292 } 4294 } 4295 } 4296 list telemetry { 4297 description 4298 "The telemetry data per DOTS client. The keys 4299 of the list are 'cuid' and 'tsid', but these keys are 4300 not represented here because these keys are conveyed 4301 as mandatory Uri-Paths in requests. Omitting keys 4302 is compliant with RFC8791."; 4303 choice direction { 4304 description 4305 "Indicates the communication direction in which the 4306 data nodes can be included."; 4307 case server-to-client-only { 4308 description 4309 "These data nodes appear only in a mitigation message 4310 sent from the server to the client."; 4311 leaf tsid { 4312 type uint32; 4313 description 4314 "A client-assigned identifier for the DOTS 4315 telemetry setup data."; 4316 } 4317 } 4318 } 4319 choice setup-type { 4320 description 4321 "Can be a mitigation configuration, a pipe capacity, 4322 or baseline message."; 4323 case telemetry-config { 4324 description 4325 "Used to set telemetry parameters such as setting 4326 low, mid, and high percentile values."; 4327 container current-config { 4328 description 4329 "Current telemetry configuration values."; 4330 uses telemetry-parameters; 4331 uses unit-config; 4332 leaf server-originated-telemetry { 4333 type boolean; 4334 description 4335 "Used by a DOTS client to enable/disable whether 4336 it requests pre-or-ongoing-mitigation telemetry 4337 from the DOTS server."; 4338 } 4339 leaf telemetry-notify-interval { 4340 type uint16 { 4341 range "1 .. 3600"; 4343 } 4344 units "seconds"; 4345 description 4346 "Minimum number of seconds between successive 4347 telemetry notifications."; 4348 } 4349 } 4350 } 4351 case pipe { 4352 description 4353 "Total pipe capacity of a DOTS client domain."; 4354 list total-pipe-capacity { 4355 key "link-id unit"; 4356 description 4357 "Total pipe capacity of a DOTS client domain."; 4358 leaf link-id { 4359 type nt:link-id; 4360 description 4361 "Identifier of an interconnection link of 4362 the DOTS client domain."; 4363 } 4364 leaf capacity { 4365 type uint64; 4366 mandatory true; 4367 description 4368 "Pipe capacity. This attribute is mandatory when 4369 total-pipe-capacity is included in a message."; 4370 } 4371 leaf unit { 4372 type unit; 4373 description 4374 "The traffic can be measured using unit classes: 4375 packets per second (pps), bits per second 4376 (bit/s), and/or bytes per second (Byte/s). 4378 For a given unit class, the DOTS agents 4379 auto-scales to the appropriate units (e.g., 4380 megabit-ps, kilobit-ps)."; 4381 } 4382 } 4383 } 4384 case baseline { 4385 description 4386 "Traffic baseline information of a DOTS client 4387 domain."; 4388 list baseline { 4389 key "id"; 4390 description 4391 "Traffic baseline information of a DOTS client 4392 domain."; 4393 leaf id { 4394 type uint32; 4395 must '. >= 1'; 4396 description 4397 "An identifier that uniquely identifies a 4398 baseline entry communicated by a DOTS client."; 4399 } 4400 uses baseline; 4401 } 4402 } 4403 } 4404 } 4405 } 4406 case telemetry { 4407 description 4408 "Telemetry information."; 4409 list pre-or-ongoing-mitigation { 4410 description 4411 "Pre-or-ongoing-mitigation telemetry per DOTS client. 4412 The keys of the list are 'cuid' and 'tmid', but these 4413 keys are not represented here because these keys are 4414 conveyed as mandatory Uri-Paths in requests. 4415 Omitting keys is compliant with RFC8791."; 4416 choice direction { 4417 description 4418 "Indicates the communication direction in which the 4419 data nodes can be included."; 4420 case server-to-client-only { 4421 description 4422 "These data nodes appear only in a mitigation message 4423 sent from the server to the client."; 4424 leaf tmid { 4425 type uint32; 4426 description 4427 "A client-assigned identifier for the DOTS 4428 telemetry data."; 4429 } 4430 } 4431 } 4432 container target { 4433 description 4434 "Indicates the target. At least one of the attributes 4435 'target-prefix', 'target-fqdn', 'target-uri', 4436 'alias-name', or 'mid-list' must be present in the 4437 target definition."; 4438 uses data-channel:target; 4439 leaf-list alias-name { 4440 type string; 4441 description 4442 "An alias name that points to a resource."; 4443 } 4444 leaf-list mid-list { 4445 type uint32; 4446 description 4447 "Reference a list of associated mitigation 4448 requests."; 4449 reference 4450 "RFC 9132: Distributed Denial-of-Service Open Threat 4451 Signaling (DOTS) Signal Channel 4452 Specification, Section 4.4.1"; 4453 } 4454 } 4455 uses pre-or-ongoing-mitigation; 4456 } 4457 } 4458 } 4459 } 4460 } 4461 4463 10.2. Vendor Attack Mapping Details YANG Module 4465 file "ietf-dots-mapping@2020-06-26.yang" 4466 module ietf-dots-mapping { 4467 yang-version 1.1; 4468 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-mapping"; 4469 prefix dots-mapping; 4471 import ietf-dots-data-channel { 4472 prefix data-channel; 4473 reference 4474 "RFC 8783: Distributed Denial-of-Service Open Threat 4475 Signaling (DOTS) Data Channel Specification"; 4476 } 4478 organization 4479 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 4480 contact 4481 "WG Web: 4482 WG List: 4484 Author: Mohamed Boucadair 4485 4487 Author: Jon Shallow 4488 "; 4489 description 4490 "This module contains YANG definitions for the sharing 4491 DDoS attack mapping details between a DOTS client and 4492 a DOTS server, by means of the DOTS data channel. 4494 Copyright (c) 2021 IETF Trust and the persons identified as 4495 authors of the code. All rights reserved. 4497 Redistribution and use in source and binary forms, with or 4498 without modification, is permitted pursuant to, and subject 4499 to the license terms contained in, the Simplified BSD License 4500 set forth in Section 4.c of the IETF Trust's Legal Provisions 4501 Relating to IETF Documents 4502 (http://trustee.ietf.org/license-info). 4504 This version of this YANG module is part of RFC XXXX; see 4505 the RFC itself for full legal notices."; 4507 revision 2020-06-26 { 4508 description 4509 "Initial revision."; 4510 reference 4511 "RFC XXXX: Distributed Denial-of-Service Open Threat 4512 Signaling (DOTS) Telemetry"; 4513 } 4515 feature dots-telemetry { 4516 description 4517 "This feature indicates that DOTS telemetry data can be 4518 shared between DOTS clients and servers."; 4519 } 4521 grouping attack-mapping { 4522 description 4523 "A set of information used for sharing vendor attack mapping 4524 information with a peer."; 4525 list vendor { 4526 key "vendor-id"; 4527 description 4528 "Vendor attack mapping information of the client/server"; 4529 leaf vendor-id { 4530 type uint32; 4531 description 4532 "Vendor ID is a security vendor's Enterprise Number as 4533 registered with IANA."; 4534 reference 4535 "IANA: Private Enterprise Numbers"; 4536 } 4537 leaf vendor-name { 4538 type string; 4539 description 4540 "The name of the vendor (e.g., company A)."; 4541 } 4542 leaf last-updated { 4543 type uint64; 4544 mandatory true; 4545 description 4546 "The time the mapping table was updated. It is represented 4547 in seconds relative to 1970-01-01T00:00:00Z."; 4548 } 4549 list attack-mapping { 4550 key "attack-id"; 4551 description 4552 "Attack mapping details."; 4553 leaf attack-id { 4554 type uint32; 4555 description 4556 "Unique identifier assigned by the vendor for the 4557 attack."; 4558 } 4559 leaf attack-description { 4560 type string; 4561 mandatory true; 4562 description 4563 "Textual representation of attack description. Natural 4564 Language Processing techniques (e.g., word embedding) 4565 might provide some utility in mapping the attack 4566 description to an attack type."; 4567 } 4568 } 4569 } 4570 } 4572 augment "/data-channel:dots-data/data-channel:dots-client" { 4573 if-feature "dots-telemetry"; 4574 description 4575 "Augments the data channel with a vendor attack 4576 mapping table of the DOTS client."; 4577 container vendor-mapping { 4578 description 4579 "Used by DOTS clients to share their vendor 4580 attack mapping information with DOTS servers."; 4581 uses attack-mapping; 4582 } 4584 } 4586 augment "/data-channel:dots-data/data-channel:capabilities" { 4587 if-feature "dots-telemetry"; 4588 description 4589 "Augments the DOTS server capabilities with a 4590 parameter to indicate whether they can share 4591 attack mapping details."; 4592 leaf vendor-mapping-enabled { 4593 type boolean; 4594 config false; 4595 description 4596 "Indicates that the DOTS server supports sharing 4597 attack vendor mapping details with DOTS clients."; 4598 } 4599 } 4601 augment "/data-channel:dots-data" { 4602 if-feature "dots-telemetry"; 4603 description 4604 "Augments the data channel with a vendor attack 4605 mapping table of the DOTS server."; 4606 container vendor-mapping { 4607 config false; 4608 description 4609 "Includes the list of vendor attack mapping details 4610 that will be shared upon request with DOTS clients."; 4611 uses attack-mapping; 4612 } 4613 } 4614 } 4615 4617 11. YANG/JSON Mapping Parameters to CBOR 4619 All DOTS telemetry parameters in the payload of the DOTS signal 4620 channel MUST be mapped to CBOR types as shown in Table 2: 4622 * Note: Implementers must check that the mapping output provided by 4623 their YANG-to-CBOR encoding schemes is aligned with the content of 4624 Table 2. 4626 +----------------------+-------------+------+---------------+--------+ 4627 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 4628 | | Type | Key | Type & | Type | 4629 | | | | Information | | 4630 +======================+=============+======+===============+========+ 4631 | tsid | uint32 |TBA1 | 0 unsigned | Number | 4632 | telemetry | list |TBA2 | 4 array | Array | 4633 | low-percentile | decimal64 |TBA3 | 6 tag 4 | | 4634 | | | | [-2, integer]| String | 4635 | mid-percentile | decimal64 |TBA4 | 6 tag 4 | | 4636 | | | | [-2, integer]| String | 4637 | high-percentile | decimal64 |TBA5 | 6 tag 4 | | 4638 | | | | [-2, integer]| String | 4639 | unit-config | list |TBA6 | 4 array | Array | 4640 | unit | enumeration |TBA7 | 0 unsigned | String | 4641 | unit-status | boolean |TBA8 | 7 bits 20 | False | 4642 | | | | 7 bits 21 | True | 4643 | total-pipe-capacity | list |TBA9 | 4 array | Array | 4644 | link-id | string |TBA10 | 3 text string | String | 4645 | pre-or-ongoing- | list |TBA11 | 4 array | Array | 4646 | mitigation | | | | | 4647 | total-traffic-normal | list |TBA12 | 4 array | Array | 4648 | low-percentile-g | yang:gauge64|TBA13 | 0 unsigned | String | 4649 | mid-percentile-g | yang:gauge64|TBA14 | 0 unsigned | String | 4650 | high-percentile-g | yang:gauge64|TBA15 | 0 unsigned | String | 4651 | peak-g | yang:gauge64|TBA16 | 0 unsigned | String | 4652 | total-attack-traffic | list |TBA17 | 4 array | Array | 4653 | total-traffic | list |TBA18 | 4 array | Array | 4654 | total-connection- | | | | | 4655 | capacity | list |TBA19 | 4 array | Array | 4656 | connection | uint64 |TBA20 | 0 unsigned | String | 4657 | connection-client | uint64 |TBA21 | 0 unsigned | String | 4658 | embryonic | uint64 |TBA22 | 0 unsigned | String | 4659 | embryonic-client | uint64 |TBA23 | 0 unsigned | String | 4660 | connection-ps | uint64 |TBA24 | 0 unsigned | String | 4661 | connection-client-ps | uint64 |TBA25 | 0 unsigned | String | 4662 | request-ps | uint64 |TBA26 | 0 unsigned | String | 4663 | request-client-ps | uint64 |TBA27 | 0 unsigned | String | 4664 | partial-request-max | uint64 |TBA28 | 0 unsigned | String | 4665 | partial-request- | | | | | 4666 | client-max | uint64 |TBA29 | 0 unsigned | String | 4667 | total-attack- | | | | | 4668 | connection | container |TBA30 | 5 map | Object | 4669 | connection-c | container |TBA31 | 5 map | Object | 4670 | embryonic-c | container |TBA32 | 5 map | Object | 4671 | connection-ps-c | container |TBA33 | 5 map | Object | 4672 | request-ps-c | container |TBA34 | 5 map | Object | 4673 | attack-detail | list |TBA35 | 4 array | Array | 4674 | id | uint32 |TBA36 | 0 unsigned | Number | 4675 | attack-id | uint32 |TBA37 | 0 unsigned | Number | 4676 | attack-description | string |TBA38 | 3 text string | String | 4677 | attack-severity | enumeration |TBA39 | 0 unsigned | String | 4678 | start-time | uint64 |TBA40 | 0 unsigned | String | 4679 | end-time | uint64 |TBA41 | 0 unsigned | String | 4680 | source-count | container |TBA42 | 5 map | Object | 4681 | top-talker | container |TBA43 | 5 map | Object | 4682 | spoofed-status | boolean |TBA44 | 7 bits 20 | False | 4683 | | | | 7 bits 21 | True | 4684 | partial-request-c | container |TBA45 | 5 map | Object | 4685 | total-attack- | | | | | 4686 | connection-protocol | list |TBA46 | 4 array | Array | 4687 | baseline | list |TBA49 | 4 array | Array | 4688 | current-config | container |TBA50 | 5 map | Object | 4689 | max-config-values | container |TBA51 | 5 map | Object | 4690 | min-config-values | container |TBA52 | 5 map | Object | 4691 |supported-unit-classes| container |TBA53 | 5 map | Object | 4692 | server-originated- | boolean |TBA54 | 7 bits 20 | False | 4693 | telemetry | | | 7 bits 21 | True | 4694 | telemetry-notify- | uint32 |TBA55 | 0 unsigned | Number | 4695 | interval | | | | | 4696 | tmid | uint32 |TBA56 | 0 unsigned | Number | 4697 | measurement-interval | enumeration |TBA57 | 0 unsigned | String | 4698 | measurement-sample | enumeration |TBA58 | 0 unsigned | String | 4699 | talker | list |TBA59 | 4 array | Array | 4700 | source-prefix | inet: |TBA60 | 3 text string | String | 4701 | | ip-prefix | | | | 4702 | mid-list | leaf-list |TBA61 | 4 array | Array | 4703 | | uint32 | | 0 unsigned | Number | 4704 | source-port-range | list |TBA62 | 4 array | Array | 4705 | source-icmp-type- | list |TBA63 | 4 array | Array | 4706 | range | | | | | 4707 | target | container |TBA64 | 5 map | Object | 4708 | capacity | uint64 |TBA65 | 0 unsigned | String | 4709 | protocol | uint8 |TBA66 | 0 unsigned | Number | 4710 | total-traffic- | | | | | 4711 | normal-per-protocol | list |TBA67 | 4 array | Array | 4712 | total-traffic- | | | | | 4713 | normal-per-port | list |TBA68 | 4 array | Array | 4714 | total-connection- | | | | | 4715 | capacity-per-port | list |TBA69 | 4 array | Array | 4716 | total-traffic- | | | | | 4717 | protocol | list |TBA70 | 4 array | Array | 4718 | total-traffic-port | list |TBA71 | 4 array | Array | 4719 | total-attack- | | | | | 4720 | traffic-protocol | list |TBA72 | 4 array | Array | 4721 | total-attack- | | | | | 4722 | traffic-port | list |TBA73 | 4 array | Array | 4723 | total-attack- | | | | | 4724 | connection-port | list |TBA74 | 4 array | Array | 4725 | port | inet: | | | | 4726 | | port-number|TBA75 | 0 unsigned | Number | 4727 | supported-query-type | leaf-list |TBA76 | 4 array | Array | 4728 | | | | 0 unsigned | String | 4729 | vendor-id | uint32 |TBA77 | 0 unsigned | Number | 4730 | ietf-dots-telemetry: | | | | | 4731 | telemetry-setup | container |TBA78 | 5 map | Object | 4732 | ietf-dots-telemetry: | | | | | 4733 | total-traffic | list |TBA79 | 4 array | Array | 4734 | ietf-dots-telemetry: | | | | | 4735 | total-attack-traffic | list |TBA80 | 4 array | Array | 4736 | ietf-dots-telemetry: | | | | | 4737 | total-attack- | | | | | 4738 | connection | container |TBA81 | 5 map | Object | 4739 | ietf-dots-telemetry: | | | | | 4740 | attack-detail | list |TBA82 | 4 array | Array | 4741 | ietf-dots-telemetry: | | | | | 4742 | telemetry | container |TBA83 | 5 map | Object | 4743 | current-g | yang:gauge64|TBA84 | 0 unsigned | String | 4744 | lower-type | uint8 |32771 | 0 unsigned | Number | 4745 | upper-type | uint8 |32772 | 0 unsigned | Number | 4746 +----------------------+-------------+------+---------------+--------+ 4748 Table 2: YANG/JSON Mapping Parameters to CBOR 4750 12. IANA Considerations 4752 12.1. DOTS Signal Channel CBOR Key Values 4754 This specification registers the DOTS telemetry attributes in the 4755 IANA "DOTS Signal Channel CBOR Key Values" registry [Key-Map]. 4757 The DOTS telemetry attributes defined in this specification are 4758 comprehension-optional parameters. 4760 * Note to the RFC Editor: CBOR keys are assigned from the "128-255" 4761 range. This specification meets the requirements listed in 4762 Section 3.1 [RFC9132] for assignments in the "128-255" range. 4764 +----------------------+-------+-------+------------+---------------+ 4765 | Parameter Name | CBOR | CBOR | Change | Specification | 4766 | | Key | Major | Controller | Document(s) | 4767 | | Value | Type | | | 4768 +======================+=======+=======+============+===============+ 4769 | tsid | TBA1 | 0 | IESG | [RFCXXXX] | 4770 | telemetry | TBA2 | 4 | IESG | [RFCXXXX] | 4771 | low-percentile | TBA3 | 6tag4 | IESG | [RFCXXXX] | 4772 | mid-percentile | TBA4 | 6tag4 | IESG | [RFCXXXX] | 4773 | high-percentile | TBA5 | 6tag4 | IESG | [RFCXXXX] | 4774 | unit-config | TBA6 | 4 | IESG | [RFCXXXX] | 4775 | unit | TBA7 | 0 | IESG | [RFCXXXX] | 4776 | unit-status | TBA8 | 7 | IESG | [RFCXXXX] | 4777 | total-pipe-capacity | TBA9 | 4 | IESG | [RFCXXXX] | 4778 | link-id | TBA10 | 3 | IESG | [RFCXXXX] | 4779 | pre-or-ongoing- | TBA11 | 4 | IESG | [RFCXXXX] | 4780 | mitigation | | | | | 4781 | total-traffic-normal | TBA12 | 4 | IESG | [RFCXXXX] | 4782 | low-percentile-g | TBA13 | 0 | IESG | [RFCXXXX] | 4783 | mid-percentile-g | TBA14 | 0 | IESG | [RFCXXXX] | 4784 | high-percentile-g | TBA15 | 0 | IESG | [RFCXXXX] | 4785 | peak-g | TBA16 | 0 | IESG | [RFCXXXX] | 4786 | total-attack-traffic | TBA17 | 4 | IESG | [RFCXXXX] | 4787 | total-traffic | TBA18 | 4 | IESG | [RFCXXXX] | 4788 | total-connection- | TBA19 | 4 | IESG | [RFCXXXX] | 4789 | capacity | | | | | 4790 | connection | TBA20 | 0 | IESG | [RFCXXXX] | 4791 | connection-client | TBA21 | 0 | IESG | [RFCXXXX] | 4792 | embryonic | TBA22 | 0 | IESG | [RFCXXXX] | 4793 | embryonic-client | TBA23 | 0 | IESG | [RFCXXXX] | 4794 | connection-ps | TBA24 | 0 | IESG | [RFCXXXX] | 4795 | connection-client-ps | TBA25 | 0 | IESG | [RFCXXXX] | 4796 | request-ps | TBA26 | 0 | IESG | [RFCXXXX] | 4797 | request-client-ps | TBA27 | 0 | IESG | [RFCXXXX] | 4798 | partial-request-max | TBA28 | 0 | IESG | [RFCXXXX] | 4799 | partial-request- | TBA29 | 0 | IESG | [RFCXXXX] | 4800 | client-max | | | | | 4801 | total-attack- | TBA30 | 5 | IESG | [RFCXXXX] | 4802 | connection | | | | | 4803 | connection-c | TBA31 | 5 | IESG | [RFCXXXX] | 4804 | embryonic-c | TBA32 | 5 | IESG | [RFCXXXX] | 4805 | connection-ps-c | TBA33 | 5 | IESG | [RFCXXXX] | 4806 | request-ps-c | TBA34 | 5 | IESG | [RFCXXXX] | 4807 | attack-detail | TBA35 | 4 | IESG | [RFCXXXX] | 4808 | id | TBA36 | 0 | IESG | [RFCXXXX] | 4809 | attack-id | TBA37 | 0 | IESG | [RFCXXXX] | 4810 | attack-description | TBA38 | 3 | IESG | [RFCXXXX] | 4811 | attack-severity | TBA39 | 0 | IESG | [RFCXXXX] | 4812 | start-time | TBA40 | 0 | IESG | [RFCXXXX] | 4813 | end-time | TBA41 | 0 | IESG | [RFCXXXX] | 4814 | source-count | TBA42 | 5 | IESG | [RFCXXXX] | 4815 | top-talker | TBA43 | 5 | IESG | [RFCXXXX] | 4816 | spoofed-status | TBA44 | 7 | IESG | [RFCXXXX] | 4817 | partial-request-c | TBA45 | 5 | IESG | [RFCXXXX] | 4818 | total-attack- | TBA46 | 4 | IESG | [RFCXXXX] | 4819 | connection-protocol | | | | | 4820 | baseline | TBA49 | 4 | IESG | [RFCXXXX] | 4821 | current-config | TBA50 | 5 | IESG | [RFCXXXX] | 4822 | max-config-value | TBA51 | 5 | IESG | [RFCXXXX] | 4823 | min-config-values | TBA52 | 5 | IESG | [RFCXXXX] | 4824 |supported-unit-classes| TBA53 | 5 | IESG | [RFCXXXX] | 4825 | server-originated- | TBA54 | 7 | IESG | [RFCXXXX] | 4826 | telemetry | | | | | 4827 | telemetry-notify- | TBA55 | 0 | IESG | [RFCXXXX] | 4828 | interval | | | | | 4829 | tmid | TBA56 | 0 | IESG | [RFCXXXX] | 4830 | measurement-interval | TBA57 | 0 | IESG | [RFCXXXX] | 4831 | measurement-sample | TBA58 | 0 | IESG | [RFCXXXX] | 4832 | talker | TBA59 | 4 | IESG | [RFCXXXX] | 4833 | source-prefix | TBA60 | 3 | IESG | [RFCXXXX] | 4834 | mid-list | TBA61 | 4 | IESG | [RFCXXXX] | 4835 | source-port-range | TBA62 | 4 | IESG | [RFCXXXX] | 4836 | source-icmp-type- | TBA63 | 4 | IESG | [RFCXXXX] | 4837 | range | | | | | 4838 | target | TBA64 | 5 | IESG | [RFCXXXX] | 4839 | capacity | TBA65 | 0 | IESG | [RFCXXXX] | 4840 | protocol | TBA66 | 0 | IESG | [RFCXXXX] | 4841 | total-traffic- | TBA67 | 4 | IESG | [RFCXXXX] | 4842 | normal-per-protocol | | | | | 4843 | total-traffic- | TBA68 | 4 | IESG | [RFCXXXX] | 4844 | normal-per-port | | | | | 4845 | total-connection- | TBA69 | 4 | IESG | [RFCXXXX] | 4846 | capacity-per-port | | | | | 4847 | total-traffic- | TBA70 | 4 | IESG | [RFCXXXX] | 4848 | protocol | | | | | 4849 | total-traffic-port | TBA71 | 4 | IESG | [RFCXXXX] | 4850 | total-attack- | TBA72 | 4 | IESG | [RFCXXXX] | 4851 | traffic-protocol | | | | | 4852 | total-attack- | TBA73 | 4 | IESG | [RFCXXXX] | 4853 | traffic-port | | | | | 4854 | total-attack- | TBA74 | 4 | IESG | [RFCXXXX] | 4855 | connection-port | | | | | 4856 | port | TBA75 | 0 | IESG | [RFCXXXX] | 4857 | supported-query-type | TBA76 | 4 | IESG | [RFCXXXX] | 4858 | vendor-id | TBA77 | 0 | IESG | [RFCXXXX] | 4859 | ietf-dots-telemetry: | TBA78 | 5 | IESG | [RFCXXXX] | 4860 | telemetry-setup | | | | | 4861 | ietf-dots-telemetry: | TBA79 | 4 | IESG | [RFCXXXX] | 4862 | total-traffic | | | | | 4863 | ietf-dots-telemetry: | TBA80 | 4 | IESG | [RFCXXXX] | 4864 | total-attack-traffic | | | | | 4865 | ietf-dots-telemetry: | TBA81 | 5 | IESG | [RFCXXXX] | 4866 | total-attack- | | | | | 4867 | connection | | | | | 4868 | ietf-dots-telemetry: | TBA82 | 4 | IESG | [RFCXXXX] | 4869 | attack-detail | | | | | 4870 | ietf-dots-telemetry: | TBA83 | 5 | IESG | [RFCXXXX] | 4871 | telemetry | | | | | 4872 | current-g | TBA84 | 0 | IESG | [RFCXXXX] | 4873 +----------------------+-------+-------+------------+---------------+ 4875 Table 3: Registered DOTS Signal Channel CBOR Key Values 4877 12.2. DOTS Signal Channel Conflict Cause Codes 4879 This specification requests IANA to assign a new code from the "DOTS 4880 Signal Channel Conflict Cause Codes" registry [Cause]. 4882 +------+-------------------+------------------------+-------------+ 4883 | Code | Label | Description | Reference | 4884 +======+===================+========================+=============+ 4885 | TBA | overlapping-pipes | Overlapping pipe scope | [RFCXXXX] | 4886 +------+-------------------+------------------------+-------------+ 4888 Table 4: Registered DOTS Signal Channel Conflict Cause Code 4890 12.3. DOTS Signal Telemetry YANG Module 4892 This document requests IANA to register the following URIs in the 4893 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 4895 URI: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry 4896 Registrant Contact: The IESG. 4897 XML: N/A; the requested URI is an XML namespace. 4899 URI: urn:ietf:params:xml:ns:yang:ietf-dots-mapping 4900 Registrant Contact: The IESG. 4901 XML: N/A; the requested URI is an XML namespace. 4903 This document requests IANA to register the following YANG modules in 4904 the "YANG Module Names" subregistry [RFC6020] within the "YANG 4905 Parameters" registry. 4907 name: ietf-dots-telemetry 4908 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry 4909 maintained by IANA: N 4910 prefix: dots-telemetry 4911 reference: RFC XXXX 4913 name: ietf-dots-mapping 4914 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-mapping 4915 maintained by IANA: N 4916 prefix: dots-mapping 4917 reference: RFC XXXX 4919 13. Security Considerations 4921 13.1. DOTS Signal Channel Telemetry 4923 The security considerations for the DOTS signal channel protocol are 4924 discussed in Section 11 of [RFC9132]. The following discusses the 4925 security considerations that are specific to the DOTS signal channel 4926 extension defined in this document. 4928 The DOTS telemetry information includes DOTS client network topology, 4929 DOTS client domain pipe capacity, normal traffic baseline and 4930 connections capacity, and threat and mitigation information. Such 4931 information is sensitive; it MUST be protected at rest by the DOTS 4932 server domain to prevent data leakage. Note that sharing this 4933 sensitive data with a trusted DOTS server does not introduce any new 4934 significant considerations other that the need for the aforementioned 4935 protection. Such a DOTS server is already trusted to have access to 4936 that kind of information by being in the position to observe and 4937 mitigate attacks. 4939 DOTS clients are typically considered to be trusted devices by the 4940 DOTS client domain. DOTS clients may be co-located on network 4941 security services (e.g., firewall devices), and a compromised 4942 security service potentially can do a lot more damage to the network 4943 than just the DOTS client component. This assumption differs from 4944 the often held view that devices are untrusted, often referred to as 4945 the "zero-trust model". A compromised DOTS client can send fake DOTS 4946 telemetry data to a DOTS server to mislead the DOTS server. This 4947 attack can be prevented by monitoring and auditing DOTS clients to 4948 detect misbehavior and to deter misuse, and by only authorizing the 4949 DOTS client to convey DOTS telemetry information for specific target 4950 resources (e.g., an application server is authorized to exchange DOTS 4951 telemetry for its IP addresses but a DDoS mitigator can exchange DOTS 4952 telemetry for any target resource in the network). As a reminder, 4953 this is a variation of dealing with compromised DOTS clients as 4954 discussed in Section 11 of [RFC9132]. 4956 DOTS servers must be capable of defending themselves against DoS 4957 attacks from compromised DOTS clients. The following non- 4958 comprehensive list of mitigation techniques can be used by a DOTS 4959 server to handle misbehaving DOTS clients: 4961 * The probing rate (defined in Section 4.5 of [RFC9132]) can be used 4962 to limit the average data rate to the DOTS server. 4964 * Rate-limiting DOTS telemetry, including those with new 'tmid' 4965 values, from the same DOTS client defends against DoS attacks that 4966 would result in varying the 'tmid' to exhaust DOTS server 4967 resources. Likewise, the DOTS server can enforce a quota and 4968 time-limit on the number of active pre-or-ongoing-mitigation 4969 telemetry data items (identified by 'tmid') from the DOTS client. 4971 Note also that telemetry notification interval may be used to rate- 4972 limit the pre-or-ongoing-mitigation telemetry notifications received 4973 by a DOTS client domain. 4975 13.2. Vendor Attack Mapping 4977 The security considerations for the DOTS data channel protocol are 4978 discussed in Section 10 of [RFC8783]. The following discusses the 4979 security considerations that are specific to the DOTS data channel 4980 extension defined in this document. 4982 All data nodes defined in the YANG module specified in Section 10.2 4983 which can be created, modified, and deleted (i.e., config true, which 4984 is the default) are considered sensitive. Write operations to these 4985 data nodes without proper protection can have a negative effect on 4986 network operations. Appropriate security measures are recommended to 4987 prevent illegitimate users from invoking DOTS data channel primitives 4988 as discussed in [RFC8783]. Nevertheless, an attacker who can access 4989 a DOTS client is technically capable of undertaking various attacks, 4990 such as: 4992 * Communicating invalid attack mapping details to the server 4993 ('/data-channel:dots-data/data-channel:dots-client/dots- 4994 telemetry:vendor-mapping'), which will mislead the server when 4995 correlating attack details. 4997 Some of the readable data nodes in the YANG module specified in 4998 Section 10.2 may be considered sensitive. It is thus important to 4999 control read access to these data nodes. These are the data nodes 5000 and their sensitivity: 5002 * '/data-channel:dots-data/data-channel:dots-client/dots- 5003 telemetry:vendor-mapping' can be misused to infer the DDoS 5004 protection technology deployed in a DOTS client domain. 5006 * '/data-channel:dots-data/dots-telemetry:vendor-mapping' can be 5007 used by a compromised DOTS client to leak the attack detection 5008 capabilities of the DOTS server. This is a variation of the 5009 compromised DOTS client attacks discussed in Section 13.1. 5011 14. Contributors 5013 The following individuals have contributed to this document: 5015 * Li Su, CMCC, Email: suli@chinamobile.com 5017 * Pan Wei, Huawei, Email: william.panwei@huawei.com 5019 15. Acknowledgements 5021 The authors would like to thank Flemming Andreasen, Liang Xia, and 5022 Kaname Nishizuka co-authors of [I-D.doron-dots-telemetry] and 5023 everyone who had contributed to that document. 5025 The authors would like to thank Kaname Nishizuka, Wei Pan, and Yuuhei 5026 Hayashi for comments and review. 5028 Special thanks to Jon Shallow and Kaname Nishizuka for their 5029 implementation and interoperability work. 5031 Many thanks to Jan Lindblad for the yangdoctors review and Nagendra 5032 Nainar for the opsdir review. 5034 Thanks to Benjamin Kaduk for the detailed AD review. 5036 16. References 5038 16.1. Normative References 5040 [Enterprise-Numbers] 5041 "Private Enterprise Numbers", 4 May 2020, 5042 . 5044 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5045 Requirement Levels", BCP 14, RFC 2119, 5046 DOI 10.17487/RFC2119, March 1997, 5047 . 5049 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 5050 DOI 10.17487/RFC3688, January 2004, 5051 . 5053 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 5054 the Network Configuration Protocol (NETCONF)", RFC 6020, 5055 DOI 10.17487/RFC6020, October 2010, 5056 . 5058 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 5059 RFC 6991, DOI 10.17487/RFC6991, July 2013, 5060 . 5062 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 5063 Application Protocol (CoAP)", RFC 7252, 5064 DOI 10.17487/RFC7252, June 2014, 5065 . 5067 [RFC7641] Hartke, K., "Observing Resources in the Constrained 5068 Application Protocol (CoAP)", RFC 7641, 5069 DOI 10.17487/RFC7641, September 2015, 5070 . 5072 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 5073 RFC 7950, DOI 10.17487/RFC7950, August 2016, 5074 . 5076 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 5077 the Constrained Application Protocol (CoAP)", RFC 7959, 5078 DOI 10.17487/RFC7959, August 2016, 5079 . 5081 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 5082 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 5083 November 2016, . 5085 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 5086 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 5087 . 5089 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5090 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5091 May 2017, . 5093 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 5094 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 5095 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 5096 2018, . 5098 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 5099 Denial-of-Service Open Threat Signaling (DOTS) Data 5100 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 5101 May 2020, . 5103 [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data 5104 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 5105 June 2020, . 5107 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 5108 Representation (CBOR)", STD 94, RFC 8949, 5109 DOI 10.17487/RFC8949, December 2020, 5110 . 5112 [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, 5113 "Distributed Denial-of-Service Open Threat Signaling 5114 (DOTS) Signal Channel Specification", RFC 9132, 5115 DOI 10.17487/RFC9132, September 2021, 5116 . 5118 16.2. Informative References 5120 [Cause] IANA, "DOTS Signal Channel Conflict Cause Codes", 5121 . 5124 [I-D.doron-dots-telemetry] 5125 Doron, E., Reddy, T., Andreasen, F., (Frank), L. X., and 5126 K. Nishizuka, "Distributed Denial-of-Service Open Threat 5127 Signaling (DOTS) Telemetry Specifications", Work in 5128 Progress, Internet-Draft, draft-doron-dots-telemetry-00, 5129 30 October 2016, . 5132 [I-D.ietf-core-new-block] 5133 Boucadair, M. and J. Shallow, "Constrained Application 5134 Protocol (CoAP) Block-Wise Transfer Options Supporting 5135 Robust Transmission", Work in Progress, Internet-Draft, 5136 draft-ietf-core-new-block-14, 26 May 2021, 5137 . 5140 [I-D.ietf-dots-multihoming] 5141 Boucadair, M., Reddy, T., and W. Pan, "Multi-homing 5142 Deployment Considerations for Distributed-Denial-of- 5143 Service Open Threat Signaling (DOTS)", Work in Progress, 5144 Internet-Draft, draft-ietf-dots-multihoming-09, 2 December 5145 2021, . 5148 [I-D.ietf-dots-robust-blocks] 5149 Boucadair, M. and J. Shallow, "Distributed Denial-of- 5150 Service Open Threat Signaling (DOTS) Signal Channel 5151 Configuration Attributes for Robust Block Transmission", 5152 Work in Progress, Internet-Draft, draft-ietf-dots-robust- 5153 blocks-00, 23 August 2021, 5154 . 5157 [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", 5158 . 5161 [PYANG] "pyang", November 2020, 5162 . 5164 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 5165 "Framework for IP Performance Metrics", RFC 2330, 5166 DOI 10.17487/RFC2330, May 1998, 5167 . 5169 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 5170 Denial-of-Service Considerations", RFC 4732, 5171 DOI 10.17487/RFC4732, December 2006, 5172 . 5174 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 5175 RFC 4960, DOI 10.17487/RFC4960, September 2007, 5176 . 5178 [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for 5179 Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 5180 2009, . 5182 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 5183 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 5184 . 5186 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 5187 and R. Wilton, "YANG Library", RFC 8525, 5188 DOI 10.17487/RFC8525, March 2019, 5189 . 5191 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 5192 Threat Signaling (DOTS) Requirements", RFC 8612, 5193 DOI 10.17487/RFC8612, May 2019, 5194 . 5196 [RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., 5197 Teague, N., and R. Compton, "DDoS Open Threat Signaling 5198 (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, 5199 August 2020, . 5201 [RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 5202 L., and K. Nishizuka, "Use Cases for DDoS Open Threat 5203 Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021, 5204 . 5206 [RFC9133] Nishizuka, K., Boucadair, M., Reddy.K, T., and T. Nagata, 5207 "Controlling Filtering Rules Using Distributed Denial-of- 5208 Service Open Threat Signaling (DOTS) Signal Channel", 5209 RFC 9133, DOI 10.17487/RFC9133, September 2021, 5210 . 5212 Authors' Addresses 5214 Mohamed Boucadair (editor) 5215 Orange 5216 35000 Rennes 5217 France 5219 Email: mohamed.boucadair@orange.com 5221 Tirumaleswar Reddy (editor) 5222 Akamai 5223 Embassy Golf Link Business Park 5224 Bangalore 560071 5225 Karnataka 5226 India 5228 Email: kondtir@gmail.com 5230 Ehud Doron 5231 Radware Ltd. 5232 Raoul Wallenberg Street 5233 Tel-Aviv 69710 5234 Israel 5236 Email: ehudd@radware.com 5238 Meiling Chen 5239 CMCC 5240 32, Xuanwumen West 5241 BeiJing 5242 BeiJing, 100053 5243 China 5245 Email: chenmeiling@chinamobile.com 5247 Jon Shallow 5248 United Kingdom 5250 Email: supjps-ietf@jpshallow.com