idnits 2.17.00 (12 Aug 2021) /tmp/idnits39190/draft-ietf-dots-telemetry-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 195 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 642 has weird spacing: '...-status boo...' == Line 657 has weird spacing: '...-status boo...' == Line 897 has weird spacing: '...apacity uin...' == Line 1233 has weird spacing: '...er-port ine...' == Line 1570 has weird spacing: '...er-port ine...' == (4 more instances...) -- The document date (April 15, 2020) is 765 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 4046, but not defined == Unused Reference: 'I-D.ietf-dots-signal-call-home' is defined on line 4106, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Enterprise-Numbers' == Outdated reference: draft-ietf-dots-data-channel has been published as RFC 8783 == Outdated reference: draft-ietf-dots-signal-call-home has been published as RFC 9066 == Outdated reference: draft-ietf-dots-signal-channel has been published as RFC 8782 == Outdated reference: draft-ietf-dots-signal-filter-control has been published as RFC 9133 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-04) exists of draft-bosh-core-new-block-00 == Outdated reference: A later version (-13) exists of draft-ietf-dots-multihoming-03 == Outdated reference: draft-ietf-dots-use-cases has been published as RFC 8903 Summary: 2 errors (**), 0 flaws (~~), 16 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: October 17, 2020 McAfee 6 E. Doron 7 Radware Ltd. 8 M. Chen 9 CMCC 10 April 15, 2020 12 Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry 13 draft-ietf-dots-telemetry-07 15 Abstract 17 This document aims to enrich DOTS signal channel protocol with 18 various telemetry attributes allowing optimal DDoS attack mitigation. 19 It specifies the normal traffic baseline and attack traffic telemetry 20 attributes a DOTS client can convey to its DOTS server in the 21 mitigation request, the mitigation status telemetry attributes a DOTS 22 server can communicate to a DOTS client, and the mitigation efficacy 23 telemetry attributes a DOTS client can communicate to a DOTS server. 24 The telemetry attributes can assist the mitigator to choose the DDoS 25 mitigation techniques and perform optimal DDoS attack mitigation. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 17, 2020. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. DOTS Telemetry: Overview and Purpose . . . . . . . . . . . . 5 64 4. Generic Considerations . . . . . . . . . . . . . . . . . . . 9 65 4.1. DOTS Client Identification . . . . . . . . . . . . . . . 9 66 4.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . . . 9 67 4.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . . . 9 68 4.4. Controlling Configuration Data . . . . . . . . . . . . . 9 69 4.5. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 10 70 4.6. DOTS Multi-homing Considerations . . . . . . . . . . . . 10 71 4.7. YANG Considerations . . . . . . . . . . . . . . . . . . . 10 72 4.8. A Note About Examples . . . . . . . . . . . . . . . . . . 11 73 5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 11 74 6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 12 75 6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 13 76 6.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 13 77 6.1.2. Convey DOTS Telemetry Configuration . . . . . . . . . 16 78 6.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 19 79 6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 19 80 6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 20 81 6.2.1. Convey DOTS Client Domain Pipe Capacity . . . . . . . 21 82 6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity . 26 83 6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 26 84 6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 27 85 6.3.1. Convey DOTS Client Domain Baseline Information . . . 30 86 6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 33 87 6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 33 88 6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 33 89 6.5. Conflict with Other DOTS Clients of the Same Domain . . . 33 90 7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 34 91 7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 36 92 7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 36 93 7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 38 94 7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 39 95 7.1.4. Total Attack Connections . . . . . . . . . . . . . . 41 96 7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 42 98 7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 44 99 7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 47 100 8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 51 101 8.1. DOTS Clients to Servers Mitigation Efficacy DOTS 102 Telemetry Attributes . . . . . . . . . . . . . . . . . . 51 103 8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry 104 Attributes . . . . . . . . . . . . . . . . . . . . . . . 53 105 9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 57 106 10. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 83 107 11. IANA Considerationsr . . . . . . . . . . . . . . . . . . . . 87 108 11.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 87 109 11.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 91 110 11.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 91 111 12. Security Considerations . . . . . . . . . . . . . . . . . . . 91 112 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 91 113 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 92 114 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 92 115 15.1. Normative References . . . . . . . . . . . . . . . . . . 92 116 15.2. Informative References . . . . . . . . . . . . . . . . . 93 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94 119 1. Introduction 121 Distributed Denial of Service (DDoS) attacks have become more 122 sophisticated. IT organizations and service providers are facing 123 DDoS attacks that fall into two broad categories: 125 1. Network/Transport layer attacks target the victim's 126 infrastructure. These attacks are not necessarily aimed at 127 taking down the actual delivered services, but rather to 128 eliminate various network elements (routers, switches, firewalls, 129 transit links, and so on) from serving legitimate users traffic. 131 The main method of such attacks is to send a large volume or high 132 packet per second (pps) of traffic toward the victim's 133 infrastructure. Typically, attack volumes may vary from a few 134 100 Mbps to 100s of Gbps or even Tbps. Attacks are commonly 135 carried out leveraging botnets and attack reflectors for 136 amplification attacks such as NTP (Network Time Protocol), DNS 137 (Domain Name System), SNMP (Simple Network Management Protocol), 138 or SSDP (Simple Service Discovery Protocol). 140 2. Application layer attacks target various applications. Typical 141 examples include attacks against HTTP/HTTPS, DNS, SIP (Session 142 Initiation Protocol), or SMTP (Simple Mail Transfer Protocol). 143 However, all applications with their port numbers open at network 144 edges can be attractive attack targets. 146 Application layer attacks are considered more complex and hard to 147 categorize, therefore harder to detect and mitigate efficiently. 149 To compound the problem, attackers also leverage multi-vectored 150 attacks. These attacks are assembled from dynamic attack vectors 151 (Network/Application) and tactics. As such, multiple attack vectors 152 formed by multiple attack types and volumes are launched 153 simultaneously towards a victim. Multi-vector attacks are harder to 154 detect and defend. Multiple and simultaneous mitigation techniques 155 are needed to defeat such attack campaigns. It is also common for 156 attackers to change attack vectors right after a successful 157 mitigation, burdening their opponents with changing their defense 158 methods. 160 The ultimate conclusion derived from these real scenarios is that 161 modern attacks detection and mitigation are most certainly 162 complicated and highly convoluted tasks. They demand a comprehensive 163 knowledge of the attack attributes, the targeted normal behavior 164 (including, normal traffic patterns), as well as the attacker's on- 165 going and past actions. Even more challenging, retrieving all the 166 analytics needed for detecting these attacks is not simple to obtain 167 with the industry's current capabilities. 169 The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is 170 used to carry information about a network resource or a network (or a 171 part thereof) that is under a DDoS attack. Such information is sent 172 by a DOTS client to one or multiple DOTS servers so that appropriate 173 mitigation actions are undertaken on traffic deemed suspicious. 174 Various use cases are discussed in [I-D.ietf-dots-use-cases]. 176 Typically, DOTS clients can be integrated within a DDoS attack 177 detector, or network and security elements that have been actively 178 engaged with ongoing attacks. The DOTS client mitigation environment 179 determines that it is no longer possible or practical for it to 180 handle these attacks. This can be due to a lack of resources or 181 security capabilities, as derived from the complexities and the 182 intensity of these attacks. In this circumstance, the DOTS client 183 has invaluable knowledge about the actual attacks that need to be 184 handled by its DOTS server(s). By enabling the DOTS client to share 185 this comprehensive knowledge of an ongoing attack under specific 186 circumstances, the DOTS server can drastically increase its ability 187 to accomplish successful mitigation. While the attack is being 188 handled by the DOTS server associated mitigation resources, the DOTS 189 server has the knowledge about the ongoing attack mitigation. The 190 DOTS server can share this information with the DOTS client so that 191 the client can better assess and evaluate the actual mitigation 192 realized. 194 DOTS clients can send mitigation hints derived from attack details to 195 DOTS servers, with the full understanding that the DOTS server may 196 ignore mitigation hints, as described in [RFC8612] (Gen-004). 197 Mitigation hints will be transmitted across the DOTS signal channel, 198 as the data channel may not be functional during an attack. How a 199 DOTS server is handling normal and attack traffic attributes, and 200 mitigation hints is implementation-specific. 202 Both DOTS client and server can benefit this information by 203 presenting various information in relevant management, reporting, and 204 portal systems. 206 This document defines DOTS telemetry attributes that can be conveyed 207 by DOTS clients to DOTS servers, and vice versa. The DOTS telemetry 208 attributes are not mandatory fields. Nevertheless, when DOTS 209 telemetry attributes are available to a DOTS agent, and absent any 210 policy, it can signal the attributes in order to optimize the overall 211 mitigation service provisioned using DOTS. Some of the DOTS 212 telemetry data is not shared during an attack time. 214 2. Terminology 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 218 "OPTIONAL" in this document are to be interpreted as described in BCP 219 14 [RFC2119][RFC8174] when, and only when, they appear in all 220 capitals, as shown here. 222 The reader should be familiar with the terms defined in [RFC8612]. 224 "DOTS Telemetry" is defined as the collection of attributes that are 225 used to characterize normal traffic baseline, attacks and their 226 mitigation measures, and any related information that may help in 227 enforcing countermeasures. The DOTS Telemetry is an optional set of 228 attributes that can be signaled in the DOTS signal channel protocol. 230 The meaning of the symbols in YANG tree diagrams is defined in 231 [RFC8340]. 233 3. DOTS Telemetry: Overview and Purpose 235 When signaling a mitigation request, it is most certainly beneficial 236 for DOTS clients to signal to DOTS servers any knowledge regarding 237 ongoing attacks. This can happen in cases where DOTS clients are 238 asking DOTS servers for support in defending against attacks that 239 they have already detected and/or mitigated. These actions taken by 240 DOTS clients are referred to as "signaling the DOTS Telemetry". 242 If attacks are already detected and categorized within a DOTS client 243 domain, the DOTS server, and its associated mitigation services, can 244 proactively benefit this information and optimize the overall service 245 delivery. It is important to note that DOTS clients and servers 246 detection and mitigation approaches can be different, and can 247 potentially outcome different results and attack classifications. 248 The DDoS mitigation service treats the ongoing attack details 249 received from DOTS clients as hints and cannot completely rely or 250 trust the attack details conveyed by DOTS clients. 252 A basic requirement of security operation teams is to be aware and 253 get visibility into the attacks they need to handle. The DOTS server 254 security operation teams benefit from the DOTS telemetry, especially 255 from the reports of ongoing attacks. Even if some mitigation can be 256 automated, operational teams can use the DOTS telemetry to be 257 prepared for attack mitigation and to assign the correct resources 258 (operation staff, networking and mitigation) for the specific 259 service. Similarly, security operation personnel at the DOTS client 260 side ask for feedback about their requests for protection. 261 Therefore, it is valuable for DOTS servers to share DOTS telemetry 262 with DOTS clients. 264 Mutual sharing of information is thus crucial for "closing the 265 mitigation loop" between DOTS clients and servers. For the server 266 side team, it is important to realize that the same attacks that the 267 DOTS server's mitigation resources are seeing are those that a DOTS 268 client is asking to mitigate. For the DOTS client side team, it is 269 important to realize that the DOTS clients receive the required 270 service. For example, understanding that "I asked for mitigation of 271 two attacks and my DOTS server detects and mitigates only one...". 272 Cases of inconsistency in attack classification between DOTS clients 273 and servers can be highlighted, and maybe handled, using the DOTS 274 telemetry attributes. 276 In addition, management and orchestration systems, at both DOTS 277 client and server sides, can use DOTS telemetry as a feedback to 278 automate various control and management activities derived from 279 signaled telemetry information . 281 If the DOTS server's mitigation resources have the capabilities to 282 facilitate the DOTS telemetry, the DOTS server adapts its protection 283 strategy and activates the required countermeasures immediately 284 (automation enabled) for the sake of optimized attack mitigation 285 decisions and actions. 287 DOTS telemetry can also be used to tune the DDoS mitigators with the 288 correct state of an attack. During the last few years, DDoS attack 289 detection technologies have evolved from threshold-based detection 290 (that is, cases when all or specific parts of traffic cross a pre- 291 defined threshold for a certain period of time is considered as an 292 attack) to an "anomaly detection" approach. For the latter, it is 293 required to maintain rigorous learning of "normal" behavior and where 294 an "anomaly" (or an attack) is identified and categorized based on 295 the knowledge about the normal behavior and a deviation from this 296 normal behavior. Machine learning approaches are used such that the 297 actual traffic thresholds are automatically calculated by learning 298 the protected entity normal traffic behavior during idle time. The 299 normal traffic characterization learned is referred to as the "normal 300 traffic baseline". An attack is detected when the victim's actual 301 traffic is deviating from this normal baseline. 303 In addition, subsequent activities toward mitigating an attack are 304 much more challenging. The ability to distinguish legitimate traffic 305 from attacker traffic on a per packet basis is complex. For example, 306 a packet may look "legitimate" and no attack signature can be 307 identified. The anomaly can be identified only after detailed 308 statistical analysis. DDoS attack mitigators use the normal baseline 309 during the mitigation of an attack to identify and categorize the 310 expected appearance of a specific traffic pattern. Particularly, the 311 mitigators use the normal baseline to recognize the "level of 312 normality" needs to be achieved during the various mitigation 313 process. 315 Normal baseline calculation is performed based on continuous learning 316 of the normal behavior of the protected entities. The minimum 317 learning period varies from hours to days and even weeks, depending 318 on the protected application behavior. The baseline cannot be 319 learned during active attacks because attack conditions do not 320 characterize the protected entities' normal behavior. 322 If the DOTS client has calculated the normal baseline of its 323 protected entities, signaling such information to the DOTS server 324 along with the attack traffic levels is significantly valuable. The 325 DOTS server benefits from this telemetry by tuning its mitigation 326 resources with the DOTS client's normal baseline. The DOTS server 327 mitigators use the baseline to familiarize themselves with the attack 328 victim's normal behavior and target the baseline as the level of 329 normality they need to achieve. Fed with this inforamtion, the 330 overall mitigation performances is expected to be improved in terms 331 of time to mitigate, accuracy, false-negative, and false-positive. 333 Mitigation of attacks without having certain knowledge of normal 334 traffic can be inaccurate at best. This is especially true for 335 recursive signaling (see Section 3.2.3 in [I-D.ietf-dots-use-cases]). 336 In addition, the highly diverse types of use-cases where DOTS clients 337 are integrated also emphasize the need for knowledge of each DOTS 338 client domain behavior. Consequently, common global thresholds for 339 attack detection practically cannot be realized. Each DOTS client 340 domain can have its own levels of traffic and normal behavior. 341 Without facilitating normal baseline signaling, it may be very 342 difficult for DOTS servers in some cases to detect and mitigate the 343 attacks accurately: 345 It is important to emphasize that it is practically impossible for 346 the DOTS server's mitigators to calculate the normal baseline in 347 cases where they do not have any knowledge of the traffic 348 beforehand. 350 In addition, baseline learning requires a period of time that 351 cannot be afforded during active attack. 353 Of course, this information can provided using out-of-band 354 mechanisms or manual configuration at the risk to maintain 355 inaccurate information as the network evolves and "normal" 356 patterns change. The use of a dynamic and collaborative means 357 between the DOTS client and server to identify and share key 358 parameters for the sake of efficient DDoS protection is valuable. 360 During a high volume attack, DOTS client pipes can be totally 361 saturated. DOTS clients ask their DOTS servers to handle the attack 362 upstream so that DOTS client pipes return to a reasonable load level 363 (normal pattern, ideally). At this point, it is essential to ensure 364 that the mitigator does not overwhelm the DOTS client pipes by 365 sending back "clean traffic", or what it believes is "clean". This 366 can happen when the mitigator has not managed to detect and mitigate 367 all the attacks launched towards the DOTS client domain. In this 368 case, it can be valuable to DOTS clients to signal to DOTS servers 369 the "total pipe capacity", which is the level of traffic the DOTS 370 client domain can absorb from its upstream network. Dynamic updates 371 of the condition of pipes between DOTS agents while they are under a 372 DDoS attack is essential (e.g., where multiple DOTS clients share the 373 same physical connectivity pipes). It is important to note that the 374 term "pipe" noted here does not necessary represent physical pipe, 375 but rather represents the maximum level of traffic that the DOTS 376 client domain can receive. The DOTS server should activate other 377 mechanisms to ensure it does not allow the DOTS client domain's pipes 378 to be saturated unintentionally. The rate-limit action defined in 379 [I-D.ietf-dots-data-channel] is a reasonable candidate to achieve 380 this objective; the DOTS client can ask for the type(s) of traffic 381 (such as ICMP, UDP, TCP port number 80) it prefers to limit. The 382 rate-limit action can be controlled via the signal-channel 383 [I-D.ietf-dots-signal-filter-control] even when the pipe is 384 overwhelmed. 386 To summarize: 388 Timely and effective signaling of up-to-date DDoS telemetry to all 389 elements involved in the mitigation process is essential and 390 absolutely improves the overall DDoS mitigation service 391 effectiveness. Bi-directional feedback between DOTS agents is 392 required for an increased awareness of each party, supporting 393 superior and highly efficient attack mitigation service. 395 4. Generic Considerations 397 4.1. DOTS Client Identification 399 Following the rules in [I-D.ietf-dots-signal-channel], a unique 400 identifier is generated by a DOTS client to prevent request 401 collisions ('cuid'). 403 As a reminder, [I-D.ietf-dots-signal-channel] forbids 'cuid' to be 404 returned in a response message body. 406 4.2. DOTS Gateways 408 DOTS gateways may be located between DOTS clients and servers. The 409 considerations elaborated in [I-D.ietf-dots-signal-channel] must be 410 followed. In particular, 'cdid' attribute is used to unambiguously 411 identify a DOTS client domain. 413 As a reminder, [I-D.ietf-dots-signal-channel] forbids 'cdid' (if 414 present) to be returned in a response message body. 416 4.3. Empty URI Paths 418 Uri-Path parameters and attributes with empty values MUST NOT be 419 present in a request and render an entire message invalid. 421 4.4. Controlling Configuration Data 423 The DOTS server follows the same considerations discussed in 424 Section of 4.5.3 of [I-D.ietf-dots-signal-channel] for managing DOTS 425 telemetry configuration freshness and notification. Likewise, a DOTS 426 client may control the selection of configuration and non- 427 configuration data nodes when sending a GET request by means of the 428 'c' Uri-Query option and following the procedure specified in 429 Section of 4.4.2 of [I-D.ietf-dots-signal-channel]. These 430 considerations are not re-iterated in the following sections. 432 4.5. Block-wise Transfer 434 DOTS clients can use Block-wise transfer [RFC7959] with the 435 recommendation detailed in Section 4.4.2 of 436 [I-D.ietf-dots-signal-channel] to control the size of a response when 437 the data to be returned does not fit within a single datagram. 439 DOTS clients can also use Block1 Option in a PUT request (see 440 Section 2.5 of [RFC7959]) to initiate large transfers, but these 441 Block1 transfers will fail if the inbound "pipe" is running full, so 442 consideration needs to be made to try to fit this PUT into a single 443 transfer, or to separate out the PUT into several discrete PUTs where 444 each of them fits into a single packet. 446 Block3 and Block 4 options that are similar to the CoAP Block1 and 447 Block2 options, but enable faster transmissions of big blocks of data 448 with less packet interchanges, are defined in 449 [I-D.bosh-core-new-block]. DOTS implementations can consider the use 450 of Block3 and Block 4 options. 452 4.6. DOTS Multi-homing Considerations 454 Multi-homed DOTS clients are assumed to follow the recommendations in 455 [I-D.ietf-dots-multihoming] to select which DOTS server to contact 456 and which IP prefixes to include in a telemetry message to a given 457 peer DOTS server. For example, if each upstream network exposes a 458 DOTS server and the DOTS client maintains DOTS channels with all of 459 them, only the information related to prefixes assigned by an 460 upstream network to the DOTS client domain will be signaled via the 461 DOTS channel established with the DOTS server of that upstream 462 network. Considerations related to whether (and how) a DOTS client 463 gleans some telemetry information (e.g., attack details) it receives 464 from a first DOTS server and share it with a second DOTS server are 465 implementation and deployment-specific. 467 4.7. YANG Considerations 469 Messages exchanged between DOTS agents are serialized using Concise 470 Binary Object Representation (CBOR). CBOR-encoded payloads are used 471 to carry signal channel-specific payload messages which convey 472 request parameters and response information such as errors 473 [I-D.ietf-dots-signal-channel]. 475 This document specifies a YANG module for representing DOTS telemetry 476 message types (Section 9). All parameters in the payload of the DOTS 477 signal channel are mapped to CBOR types as specified in Section 10. 479 This YANG module is not intended to be used via NETCONF/ RESTCONF for 480 DOTS server management purposes; such module is out of the scope of 481 this document. It serves only to provide a data model and encoding, 482 but not a management data model. 484 DOTS servers are allowed to update the non-configurable 'ro' entities 485 in the responses. 487 The DOTS telemetry module (Section 9) uses "enumerations" rather than 488 "identities" to define units, samples, and intervals because 489 otherwise the namespace identifier "ietf-dots-telemetry" must be 490 included when a telemetry attribute is included (e.g., in a 491 mitigation efficacy update). The use of "identities" is thus 492 suboptimal from a message compactness standpoint. 494 4.8. A Note About Examples 496 Examples are provided for illustration purposes. The document does 497 not aim to provide a comprehensive list of message examples. 499 The authoritative reference for validating telemetry messages is the 500 YANG module (Section 9) and the mapping table established in 501 Section 10. 503 5. Telemetry Operation Paths 505 As discussed in [I-D.ietf-dots-signal-channel], each DOTS operation 506 is indicated by a path-suffix that indicates the intended operation. 507 The operation path is appended to the path-prefix to form the URI 508 used with a CoAP request to perform the desired DOTS operation. The 509 following telemetry path-suffixes are defined (Table 1): 511 +-----------------+----------------+-----------+ 512 | Operation | Operation Path | Details | 513 +-----------------+----------------+-----------+ 514 | Telemetry Setup | /tm-setup | Section 6 | 515 | Telemetry | /tm | Section 7 | 516 +-----------------+----------------+-----------+ 518 Table 1: DOTS Telemetry Operations 520 Consequently, the "ietf-dots-telemetry" YANG module defined in this 521 document (Section 9) augments the "ietf-dots-signal" with two new 522 message types called "telemetry-setup" and "telemetry". The tree 523 structure is shown in Figure 1 (more details are provided in the 524 following sections about the exact structure of "telemetry-setup" and 525 "telemetry" message types). 527 augment /ietf-signal:dots-signal/ietf-signal:message-type: 528 +--:(telemetry-setup) {dots-telemetry}? 529 | ... 530 | +--rw (setup-type)? 531 | +--:(telemetry-config) 532 | | ... 533 | +--:(pipe) 534 | | ... 535 | +--:(baseline) 536 | ... 537 +--:(telemetry) {dots-telemetry}? 538 ... 540 Figure 1: New DOTS Message Types (YANG Tree Structure) 542 6. DOTS Telemetry Setup Configuration 544 In reference to Figure 1, a DOTS telemetry setup message MUST include 545 only telemetry-related configuration parameters (Section 6.1) or 546 information about DOTS client domain pipe capacity (Section 6.2) or 547 telemetry traffic baseline (Section 6.3). As such, requests that 548 include a mix of telemetry configuration, pipe capacity, or traffic 549 baseline MUST be rejected by DOTS servers with a 4.00 (Bad Request). 551 A DOTS client can reset all installed DOTS telemetry setup 552 configuration data following the considerations detailed in 553 Section 6.4. 555 A DOTS server may detect conflicts when processing requests related 556 to DOTS client domain pipe capacity or telemetry traffic baseline 557 with requests from other DOTS clients of the same DOTS client domain. 558 More details are included in Section 6.5. 560 Telemetry setup configuration is bound to a DOTS client domain. DOTS 561 servers MUST NOT expect DOTS clients to send regular requests to 562 refresh the telemetry setup configuration. Any available telemetry 563 setup configuration has a validity timeout of the DOTS association 564 with a DOTS client domain. DOTS servers MUST NOT reset 'tsid' 565 because a session failed with a DOTS client. DOTS clients update 566 their telemetry setup configuration upon change of a parameter that 567 may impact attack mitigation. 569 DOTS telemetry setup configuration request and response messages are 570 marked as Confirmable messages. 572 6.1. Telemetry Configuration 574 A DOTS client can negotiate with its server(s) a set of telemetry 575 configuration parameters to be used for telemetry. Such parameters 576 include: 578 o Percentile-related measurement parameters 580 o Measurement units 582 o Acceptable percentile values 584 o Telemetry notification interval 586 o Acceptable Server-originated telemetry 588 Section 11.3 of [RFC2330] includes more details about computing 589 percentiles. 591 6.1.1. Retrieve Current DOTS Telemetry Configuration 593 A GET request is used to obtain acceptable and current telemetry 594 configuration parameters on the DOTS server. This request may 595 include a 'cdid' Path-URI when the request is relayed by a DOTS 596 gateway. An example of such request is depicted in Figure 2. 598 Header: GET (Code=0.01) 599 Uri-Path: ".well-known" 600 Uri-Path: "dots" 601 Uri-Path: "tm-setup" 602 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 604 Figure 2: GET to Retrieve Current and Acceptable DOTS Telemetry 605 Configuration 607 Upon receipt of such request, the DOTS server replies with a 2.05 608 (Content) response that conveys the current and telemetry parameters 609 acceptable by the DOTS server. The tree structure of the response 610 message body is provided in Figure 3. Note that the response also 611 includes any pipe (Section 6.2) and baseline information 612 (Section 6.3) maintained by the DOTS server for this DOTS client. 614 DOTS servers that support the capability of sending telemetry 615 information to DOTS clients prior or during a mitigation 616 (Section 8.2) sets 'server-originated-telemetry' under 'max-config- 617 values' to 'true' ('false' is used otherwise). If 'server- 618 originated-telemetry' is not present in a response, this is 619 equivalent to receiving a request with 'server-originated-telemetry' 620 set to 'false'. 622 augment /ietf-signal:dots-signal/ietf-signal:message-type: 623 +--:(telemetry-setup) {dots-telemetry}? 624 | +--ro max-config-values 625 | | +--ro measurement-interval? interval 626 | | +--ro measurement-sample? sample 627 | | +--ro low-percentile? percentile 628 | | +--ro mid-percentile? percentile 629 | | +--ro high-percentile? percentile 630 | | +--ro server-originated-telemetry? boolean 631 | | +--ro telemetry-notify-interval? uint32 632 | +--ro min-config-values 633 | | +--ro measurement-interval? interval 634 | | +--ro measurement-sample? sample 635 | | +--ro low-percentile? percentile 636 | | +--ro mid-percentile? percentile 637 | | +--ro high-percentile? percentile 638 | | +--ro telemetry-notify-interval? uint32 639 | +--ro supported-units 640 | | +--ro unit-config* [unit] 641 | | +--ro unit unit-type 642 | | +--ro unit-status boolean 643 | +--rw telemetry* [cuid tsid] 644 | +--rw cuid string 645 | +--rw cdid? string 646 | +--rw tsid uint32 647 | +--rw (setup-type)? 648 | +--:(telemetry-config) 649 | | +--rw current-config 650 | | +--rw measurement-interval? interval 651 | | +--rw measurement-sample? sample 652 | | +--rw low-percentile? percentile 653 | | +--rw mid-percentile? percentile 654 | | +--rw high-percentile? percentile 655 | | +--rw unit-config* [unit] 656 | | | +--rw unit unit-type 657 | | | +--rw unit-status boolean 658 | | +--rw server-originated-telemetry? boolean 659 | | +--rw telemetry-notify-interval? uint32 660 | +--:(pipe) 661 | ... 662 | +--:(baseline) 663 | ... 664 +--:(telemetry) {dots-telemetry}? 665 +--rw pre-or-ongoing-mitigation* [cuid tmid] 666 ... 668 Figure 3: Telemetry Configuration Tree Structure 670 When both 'min-config-values' and 'max-config-values' attributes are 671 present, the values carried in 'max-config-values' attributes MUST be 672 greater or equal to their counterpart in 'min-config-values' 673 attributes. 675 6.1.2. Convey DOTS Telemetry Configuration 677 PUT request is used to convey the configuration parameters for the 678 telemetry data (e.g., low, mid, or high percentile values). For 679 example, a DOTS client may contact its DOTS server to change the 680 default percentile values used as baseline for telemetry data. 681 Figure 3 lists the attributes that can be set by a DOTS client in 682 such PUT request. An example of a DOTS client that modifies all 683 percentile reference values is shown in Figure 4. 685 Header: PUT (Code=0.03) 686 Uri-Path: ".well-known" 687 Uri-Path: "dots" 688 Uri-Path: "tm-setup" 689 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 690 Uri-Path: "tsid=123" 691 Content-Format: "application/dots+cbor" 693 { 694 "ietf-dots-telemetry:telemetry-setup": { 695 "telemetry": [ 696 { 697 "current-config": { 698 "low-percentile": "5.00", 699 "mid-percentile": "65.00", 700 "high-percentile": "95.00" 701 } 702 } 703 ] 704 } 705 } 707 Figure 4: PUT to Convey the DOTS Telemetry Configuration 709 'cuid' is a mandatory Uri-Path parameter for PUT requests. 711 The following additional Uri-Path parameter is defined: 713 tsid: Telemetry Setup Identifier is an identifier for the DOTS 714 telemetry setup configuration data represented as an integer. 715 This identifier MUST be generated by DOTS clients. 'tsid' 716 values MUST increase monotonically (when a new PUT is generated 717 by a DOTS client to convey new configuration parameters for the 718 telemetry). 720 This is a mandatory attribute. 722 'cuid' and 'tsid' MUST NOT appear in the PUT request message body. 724 At least one configurable attribute MUST be present in the PUT 725 request. 727 The PUT request with a higher numeric 'tsid' value overrides the DOTS 728 telemetry configuration data installed by a PUT request with a lower 729 numeric 'tsid' value. To avoid maintaining a long list of 'tsid' 730 requests for requests carrying telemetry configuration data from a 731 DOTS client, the lower numeric 'tsid' MUST be automatically deleted 732 and no longer be available at the DOTS server. 734 The DOTS server indicates the result of processing the PUT request 735 using the following response codes: 737 o If the request is missing a mandatory attribute, does not include 738 'cuid' or 'tsid' Uri-Path parameters, or contains one or more 739 invalid or unknown parameters, 4.00 (Bad Request) MUST be returned 740 in the response. 742 o If the DOTS server does not find the 'tsid' parameter value 743 conveyed in the PUT request in its configuration data and if the 744 DOTS server has accepted the configuration parameters, then a 745 response code 2.01 (Created) MUST be returned in the response. 747 o If the DOTS server finds the 'tsid' parameter value conveyed in 748 the PUT request in its configuration data and if the DOTS server 749 has accepted the updated configuration parameters, 2.04 (Changed) 750 MUST be returned in the response. 752 o If any of the enclosed configurable attribute values are not 753 acceptable to the DOTS server (Section 6.1.1), 4.22 (Unprocessable 754 Entity) MUST be returned in the response. 756 The DOTS client may re-try and send the PUT request with updated 757 attribute values acceptable to the DOTS server. 759 By default, low percentile (10th percentile), mid percentile (50th 760 percentile), high percentile (90th percentile), and peak (100th 761 percentile) values are used to represent telemetry data. 762 Nevertheless, a DOTS client can disable some percentile types (low, 763 mid, high). In particular, setting 'low-percentile' to '0.00' 764 indicates that the DOTS client is not interested in receiving low- 765 percentiles. Likewise, setting 'mid-percentile' (or 'high- 766 percentile') to the same value as 'low-percentile' (or 'mid- 767 percentile') indicates that the DOTS client is not interested in 768 receiving mid-percentiles (or high-percentiles). For example, a DOTS 769 client can send the request depicted in Figure 5 to inform the server 770 that it is interested in receiving only high-percentiles. This 771 assumes that the client will only use that percentile type when 772 sharing telemetry data with the server. 774 Header: PUT (Code=0.03) 775 Uri-Path: ".well-known" 776 Uri-Path: "dots" 777 Uri-Path: "tm-setup" 778 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 779 Uri-Path: "tsid=569" 780 Content-Format: "application/dots+cbor" 782 { 783 "ietf-dots-telemetry:telemetry-setup": { 784 "telemetry": [ 785 { 786 "current-config": { 787 "low-percentile": "0.00", 788 "mid-percentile": "0.00", 789 "high-percentile": "95.00" 790 } 791 } 792 ] 793 } 794 } 796 Figure 5: PUT to Disable Low- and Mid-Percentiles 798 DOTS clients can also configure the unit type(s) to be used for 799 traffic-related telemetry data. Typically, the supported unit types 800 are: packets per second, bits per second, and bytes per second. 802 DOTS clients that are interested to receive pre- or ongoing 803 mitigation telemetry (pre-or-ongoing-mitigation) information from a 804 DOTS server (Section 8.2) MUST set 'server-originated-telemetry' to 805 'true'. If 'server-originated-telemetry' is not present in a PUT 806 request, this is equivalent to receiving a request with 'server- 807 originated-telemetry' set to 'false'. An example of a request to 808 enable pre-or-ongoing-mitigation telemetry from DOTS servers is shown 809 in Figure 6. 811 Header: PUT (Code=0.03) 812 Uri-Path: ".well-known" 813 Uri-Path: "dots" 814 Uri-Path: "tm-setup" 815 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 816 Uri-Path: "tsid=569" 817 Content-Format: "application/dots+cbor" 819 { 820 "ietf-dots-telemetry:telemetry-setup": { 821 "telemetry": [ 822 { 823 "current-config": { 824 "server-originated-telemetry": true 825 } 826 } 827 ] 828 } 829 } 831 Figure 6: PUT to Enable Pre-or-ongoing-mitigation Telemetry from the 832 DOTS server 834 6.1.3. Retrieve Installed DOTS Telemetry Configuration 836 A DOTS client may issue a GET message with 'tsid' Uri-Path parameter 837 to retrieve the current DOTS telemetry configuration. An example of 838 such request is depicted in Figure 7. 840 Header: GET (Code=0.01) 841 Uri-Path: ".well-known" 842 Uri-Path: "dots" 843 Uri-Path: "tm-setup" 844 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 845 Uri-Path: "tsid=123" 847 Figure 7: GET to Retrieve Current DOTS Telemetry Configuration 849 If the DOTS server does not find the 'tsid' Uri-Path value conveyed 850 in the GET request in its configuration data for the requesting DOTS 851 client, it MUST respond with a 4.04 (Not Found) error response code. 853 6.1.4. Delete DOTS Telemetry Configuration 855 A DELETE request is used to delete the installed DOTS telemetry 856 configuration data (Figure 8). 'cuid' and 'tsid' are mandatory Uri- 857 Path parameters for such DELETE requests. 859 Header: DELETE (Code=0.04) 860 Uri-Path: ".well-known" 861 Uri-Path: "dots" 862 Uri-Path: "tm-setup" 863 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 864 Uri-Path: "tsid=123" 866 Figure 8: Delete Telemetry Configuration 868 The DOTS server resets the DOTS telemetry configuration back to the 869 default values and acknowledges a DOTS client's request to remove the 870 DOTS telemetry configuration using 2.02 (Deleted) response code. A 871 2.02 (Deleted) Response Code is returned even if the 'tsid' parameter 872 value conveyed in the DELETE request does not exist in its 873 configuration data before the request. 875 Section 6.4 discusses the procedure to reset all DOTS telemetry setup 876 configuration. 878 6.2. Total Pipe Capacity 880 A DOTS client can communicate to its server(s) its DOTS client domain 881 pipe information. The tree structure of the pipe information is 882 shown in Figure 9. 884 augment /ietf-signal:dots-signal/ietf-signal:message-type: 885 +--:(telemetry-setup) {dots-telemetry}? 886 | ... 887 | +--rw telemetry* [cuid tsid] 888 | +--rw cuid string 889 | +--rw cdid? string 890 | +--rw tsid uint32 891 | +--rw (setup-type)? 892 | +--:(telemetry-config) 893 | | ... 894 | +--:(pipe) 895 | | +--rw total-pipe-capacity* [link-id unit] 896 | | +--rw link-id nt:link-id 897 | | +--rw capacity uint64 898 | | +--rw unit unit 899 | +--:(baseline) 900 | ... 901 +--:(telemetry) {dots-telemetry}? 902 +--rw pre-or-ongoing-mitigation* [cuid tmid] 903 ... 905 Figure 9: Pipe Tree Structure 907 A DOTS client domain pipe is defined as a list of limits of 908 (incoming) traffic volume (total-pipe-capacity") that can be 909 forwarded over ingress interconnection links of a DOTS client domain. 910 Each of these links is identified with a "link-id" [RFC8345]. 912 The unit used by a DOTS client when conveying pipe information is 913 captured in 'unit' attribute. 915 6.2.1. Convey DOTS Client Domain Pipe Capacity 917 Similar considerations to those specified in Section 6.1.2 are 918 followed with one exception: 920 The relative order of two PUT requests carrying DOTS client domain 921 pipe attributes from a DOTS client is determined by comparing 922 their respective 'tsid' values. If such two requests have 923 overlapping "link-id" and "unit", the PUT request with higher 924 numeric 'tsid' value will override the request with a lower 925 numeric 'tsid' value. The overlapped lower numeric 'tsid' MUST be 926 automatically deleted and no longer be available. 928 DOTS clients SHOULD minimize the number of active 'tsids' used for 929 pipe information. Typically, in order to avoid maintaining a long 930 list of 'tsids' for pipe information, it is RECOMMENDED that DOTS 931 clients include in any request to update information related to a 932 given link the information of other links (already communicated using 933 a lower 'tsid' value). Doing so, this update request will override 934 these existing requests and hence optimize the number of 'tsid' 935 request per DOTS client. 937 o Note: This assumes that all link information can fit in one single 938 message. 940 For example, a DOTS client managing a single homed domain (Figure 10) 941 can send a PUT request (shown in Figure 11) to communicate the 942 capacity of "link1" used to connect to its ISP. 944 ,--,--,--. ,--,--,--. 945 ,-' `-. ,-' `-. 946 ( DOTS Client )=====( ISP#A ) 947 `-. Domain ,-' link1 `-. ,-' 948 `--'--'--' `--'--'--' 950 Figure 10: Single Homed DOTS Client Domain 952 Header: PUT (Code=0.03) 953 Uri-Path: ".well-known" 954 Uri-Path: "dots" 955 Uri-Path: "tm-setup" 956 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 957 Uri-Path: "tsid=457" 958 Content-Format: "application/dots+cbor" 960 { 961 "ietf-dots-telemetry:telemetry-setup": { 962 "telemetry": [ 963 { 964 "total-pipe-capacity": [ 965 { 966 "link-id": "link1", 967 "capacity": "500", 968 "unit": "megabit-ps" 969 } 970 ] 971 } 972 ] 973 } 974 } 976 Figure 11: Example of a PUT Request to Convey Pipe Information 977 (Single Homed) 979 DOTS clients may be instructed to signal a link aggregate instead of 980 individual links. For example, a DOTS client managing a DOTS client 981 domain having two interconnection links with an upstream ISP 982 (Figure 12) can send a PUT request (shown in Figure 13) to 983 communicate the aggregate link capacity with its ISP. Signalling 984 individual or aggregate link capacity is deployment-specific. 986 ,--,--,--. ,--,--,--. 987 ,-' `-.===== ,-' `-. 988 ( DOTS Client ) ( ISP#C ) 989 `-. Domain ,-'====== `-. ,-' 990 `--'--'--' `--'--'--' 992 Figure 12: DOTS Client Domain with Two Interconnection Links 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=896" 1000 Content-Format: "application/dots+cbor" 1002 { 1003 "ietf-dots-telemetry:telemetry-setup": { 1004 "telemetry": [ 1005 { 1006 "total-pipe-capacity": [ 1007 { 1008 "link-id": "aggregate", 1009 "capacity": "700", 1010 "unit": "megabit-ps" 1011 } 1012 ] 1013 } 1014 ] 1015 } 1016 } 1018 Figure 13: Example of a PUT Request to Convey Pipe Information 1019 (Aggregated Link) 1021 Now consider that the DOTS client domain was upgraded to connect to 1022 an additional ISP (ISP#B of Figure 14), the DOTS client can inform a 1023 third-party DOTS server (that is, not hosted with ISP#A and ISP#B 1024 domains) about this update by sending the PUT request depicted in 1025 Figure 15. This request also includes information related to "link1" 1026 even if that link is not upgraded. Upon receipt of this request, the 1027 DOTS server removes the request with 'tsid=457' and updates its 1028 configuration base to maintain two links (link#1 and link#2). 1030 ,--,--,--. 1031 ,-' `-. 1032 ( ISP#B ) 1033 `-. ,-' 1034 `--'--'--' 1035 || 1036 || link2 1037 ,--,--,--. ,--,--,--. 1038 ,-' `-. ,-' `-. 1039 ( DOTS Client )=====( ISP#A ) 1040 `-. Domain ,-' link1 `-. ,-' 1041 `--'--'--' `--'--'--' 1043 Figure 14: Multi-Homed DOTS Client Domain 1045 Header: PUT (Code=0.03) 1046 Uri-Path: ".well-known" 1047 Uri-Path: "dots" 1048 Uri-Path: "tm-setup" 1049 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1050 Uri-Path: "tsid=458" 1051 Content-Format: "application/dots+cbor" 1053 { 1054 "ietf-dots-telemetry:telemetry-setup": { 1055 "telemetry": [ 1056 { 1057 "total-pipe-capacity": [ 1058 { 1059 "link-id": "link1", 1060 "capacity": "500", 1061 "unit": "megabit-ps" 1062 }, 1063 { 1064 "link-id": "link2", 1065 "capacity": "500", 1066 "unit": "megabit-ps" 1067 } 1068 ] 1069 } 1070 ] 1071 } 1072 } 1074 Figure 15: Example of a PUT Request to Convey Pipe Information 1075 (Multi-Homed) 1077 A DOTS client can delete a link by sending a PUT request with the 1078 'capacity' attribute set to "0" if other links are still active for 1079 the same DOTS client domain (see Section 6.2.3 for other delete 1080 cases). For example, if a DOTS client domain re-homes (that is, it 1081 changes its ISP), the DOTS client can inform its DOTS server about 1082 this update (e.g., from the network configuration in Figure 10 to the 1083 one shown in Figure 16) by sending the PUT request depicted in 1084 Figure 17. Upon receipt of this request, the DOTS server removes 1085 "link1" from its configuration bases for this DOTS client domain. 1087 ,--,--,--. 1088 ,-' `-. 1089 ( ISP#B ) 1090 `-. ,-' 1091 `--'--'--' 1092 || 1093 || link2 1094 ,--,--,--. 1095 ,-' `-. 1096 ( DOTS Client ) 1097 `-. Domain ,-' 1098 `--'--'--' 1100 Figure 16: Multi-Homed DOTS Client Domain 1102 Header: PUT (Code=0.03) 1103 Uri-Path: ".well-known" 1104 Uri-Path: "dots" 1105 Uri-Path: "tm-setup" 1106 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1107 Uri-Path: "tsid=459" 1108 Content-Format: "application/dots+cbor" 1110 { 1111 "ietf-dots-telemetry:telemetry-setup": { 1112 "telemetry": [ 1113 { 1114 "total-pipe-capacity": [ 1115 { 1116 "link-id": "link1", 1117 "capacity": "0", 1118 "unit": "megabit-ps" 1119 }, 1120 { 1121 "link-id": "link2", 1122 "capacity": "500", 1123 "unit": "megabit-ps" 1124 } 1125 ] 1126 } 1127 ] 1128 } 1129 } 1131 Figure 17: Example of a PUT Request to Convey Pipe Information 1132 (Multi-Homed) 1134 6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity 1136 A GET request with 'tsid' Uri-Path parameter is used to retrieve a 1137 specific installed DOTS client domain pipe related information. The 1138 same procedure as defined in (Section 6.1.3) is followed. 1140 To retrieve all pipe information bound to a DOTS client, the DOTS 1141 client proceeds as specified in Section 6.1.1. 1143 6.2.3. Delete Installed DOTS Client Domain Pipe Capacity 1145 A DELETE request is used to delete the installed DOTS client domain 1146 pipe related information. The same procedure as defined in 1147 (Section 6.1.4) is followed. 1149 6.3. Telemetry Baseline 1151 A DOTS client can communicate to its server(s) its normal traffic 1152 baseline and connections capacity: 1154 Total traffic normal baseline: The percentile values representing 1155 the total traffic normal baseline. It can be represented for a 1156 target using 'total-traffic-normal'. 1158 The traffic normal per protocol ('total-traffic-normal-per- 1159 protocol') baseline is represented for a target and is transport- 1160 protocol specific. 1162 The traffic normal per port number ('total-traffic-normal-per- 1163 port') baseline is represented for each port number bound to a 1164 target. 1166 If the DOTS client negotiated percentile values and units 1167 (Section 6.1), these negotiated values will be used instead of the 1168 default ones. 1170 Total connections capacity: If the target is subjected to resource 1171 consuming DDoS attacks, the following optional attributes for the 1172 target per transport-protocol are useful to detect resource 1173 consuming DDoS attacks: 1175 * The maximum number of simultaneous connections that are allowed 1176 to the target. 1178 * The maximum number of simultaneous connections that are allowed 1179 to the target per client. 1181 * The maximum number of simultaneous embryonic connections that 1182 are allowed to the target. The term "embryonic connection" 1183 refers to a connection whose connection handshake is not 1184 finished. Embryonic connection is only possible in connection- 1185 oriented transport protocols like TCP or SCTP. 1187 * The maximum number of simultaneous embryonic connections that 1188 are allowed to the target per client. 1190 * The maximum number of connections allowed per second to the 1191 target. 1193 * The maximum number of connections allowed per second to the 1194 target per client. 1196 * The maximum number of requests allowed per second to the 1197 target. 1199 * The maximum number of requests allowed per second to the target 1200 per client. 1202 * The maximum number of partial requests allowed per second to 1203 the target. Attacks relying upon partial requests create a 1204 connection with a target but do not send a complete request 1205 (e.g., HTTP request). 1207 * The maximum number of partial requests allowed per second to 1208 the target per client. 1210 The aggregate per transport protocol is captured in 'total- 1211 connection-capacity', while port-specific capabilities are 1212 represented using 'total-connection-capacity-per-port'. 1214 The tree structure of the baseline is shown in Figure 18. 1216 augment /ietf-signal:dots-signal/ietf-signal:message-type: 1217 +--:(telemetry-setup) {dots-telemetry}? 1218 | ... 1219 | +--rw telemetry* [cuid tsid] 1220 | +--rw cuid string 1221 | +--rw cdid? string 1222 | +--rw tsid uint32 1223 | +--rw (setup-type)? 1224 | +--:(telemetry-config) 1225 | | ... 1226 | +--:(pipe) 1227 | | ... 1228 | +--:(baseline) 1229 | +--rw baseline* [id] 1230 | +--rw id uint32 1231 | +--rw target-prefix* inet:ip-prefix 1232 | +--rw target-port-range* [lower-port] 1233 | | +--rw lower-port inet:port-number 1234 | | +--rw upper-port? inet:port-number 1235 | +--rw target-protocol* uint8 1236 | +--rw target-fqdn* inet:domain-name 1237 | +--rw target-uri* inet:uri 1238 | +--rw alias-name* string 1239 | +--rw total-traffic-normal* [unit] 1240 | | +--rw unit unit 1241 | | +--rw low-percentile-g? yang:gauge64 1242 | | +--rw mid-percentile-g? yang:gauge64 1243 | | +--rw high-percentile-g? yang:gauge64 1244 | | +--rw peak-g? yang:gauge64 1245 | +--rw total-traffic-normal-per-protocol* [unit protocol] 1246 | | +--rw unit unit 1247 | | +--rw protocol uint8 1248 | | +--rw low-percentile-g? yang:gauge64 1249 | | +--rw mid-percentile-g? yang:gauge64 1250 | | +--rw high-percentile-g? yang:gauge64 1251 | | +--rw peak-g? yang:gauge64 1252 | +--rw total-traffic-normal-per-port* [unit port] 1253 | | +--rw port inet:port-number 1254 | | +--rw unit unit 1255 | | +--rw low-percentile-g? yang:gauge64 1256 | | +--rw mid-percentile-g? yang:gauge64 1257 | | +--rw high-percentile-g? yang:gauge64 1258 | | +--rw peak-g? yang:gauge64 1259 | +--rw total-connection-capacity* [protocol] 1260 | | +--rw protocol uint8 1261 | | +--rw connection? uint64 1262 | | +--rw connection-client? uint64 1263 | | +--rw embryonic? uint64 1264 | | +--rw embryonic-client? uint64 1265 | | +--rw connection-ps? uint64 1266 | | +--rw connection-client-ps? uint64 1267 | | +--rw request-ps? uint64 1268 | | +--rw request-client-ps? uint64 1269 | | +--rw partial-request-ps? uint64 1270 | | +--rw partial-request-client-ps? uint64 1271 | +--rw total-connection-capacity-per-port* [protocol port] 1272 | +--rw protocol uint8 1273 | +--rw port inet:port-number 1274 | +--rw connection? uint64 1275 | +--rw connection-client? uint64 1276 | +--rw embryonic? uint64 1277 | +--rw embryonic-client? uint64 1278 | +--rw connection-ps? uint64 1279 | +--rw connection-client-ps? uint64 1280 | +--rw request-ps? uint64 1281 | +--rw request-client-ps? uint64 1282 | +--rw partial-request-ps? uint64 1283 | +--rw partial-request-client-ps? uint64 1284 +--:(telemetry) {dots-telemetry}? 1285 +--rw pre-or-ongoing-mitigation* [cuid tmid] 1286 ... 1288 Figure 18: Telemetry Baseline Tree Structure 1290 6.3.1. Convey DOTS Client Domain Baseline Information 1292 Similar considerations to those specified in Section 6.1.2 are 1293 followed with one exception: 1295 The relative order of two PUT requests carrying DOTS client domain 1296 baseline attributes from a DOTS client is determined by comparing 1297 their respective 'tsid' values. If such two requests have 1298 overlapping targets, the PUT request with higher numeric 'tsid' 1299 value will override the request with a lower numeric 'tsid' value. 1300 The overlapped lower numeric 'tsid' MUST be automatically deleted 1301 and no longer be available. 1303 Two PUT requests from a DOTS client have overlapping targets if there 1304 is a common IP address, IP prefix, FQDN, URI, or alias-name. Also, 1305 two PUT requests from a DOTS client have overlapping targets if the 1306 addresses associated with the FQDN, URI, or alias are overlapping 1307 with each other or with target-prefix. 1309 DOTS clients SHOULD minimize the number of active 'tsids' used for 1310 baseline information. Typically, in order to avoid maintaining a 1311 long list of 'tsids' for baseline information, it is RECOMMENDED that 1312 DOTS clients include in a request to update information related to a 1313 given target, the information of other targets (already communicated 1314 using a lower 'tsid' value) (assuming this fits within one single 1315 datagram). This update request will override these existing requests 1316 and hence optimize the number of 'tsid' request per DOTS client. 1318 If no target clause in included in the request, this is an indication 1319 that the baseline information applies for the DOTS client domain as a 1320 whole. 1322 An example of a PUT request to convey the baseline information is 1323 shown in Figure 19. 1325 Header: PUT (Code=0.03) 1326 Uri-Path: ".well-known" 1327 Uri-Path: "dots" 1328 Uri-Path: "tm-setup" 1329 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1330 Uri-Path: "tsid=126" 1331 Content-Format: "application/dots+cbor" 1333 { 1334 "ietf-dots-telemetry:telemetry-setup": { 1335 "telemetry": [ 1336 { 1337 "baseline": [ 1338 { 1339 "id": 1, 1340 "target-prefix": [ 1341 "2001:db8:6401::1/128", 1342 "2001:db8:6401::2/128" 1343 ], 1344 "total-traffic-normal": [ 1345 { 1346 "unit": "megabit-ps", 1347 "peak-g": "60" 1348 } 1349 ] 1350 } 1351 ] 1352 } 1353 ] 1354 } 1355 } 1357 Figure 19: PUT to Convey the DOTS Traffic Baseline 1359 The DOTS client may share protocol-specific baseline information 1360 (e.g., TCP and UDP) as shown in Figure 19. 1362 Header: PUT (Code=0.03) 1363 Uri-Path: ".well-known" 1364 Uri-Path: "dots" 1365 Uri-Path: "tm-setup" 1366 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1367 Uri-Path: "tsid=128" 1368 Content-Format: "application/dots+cbor" 1370 { 1371 "ietf-dots-telemetry:telemetry-setup": { 1372 "telemetry": [ 1373 { 1374 "baseline": [ 1375 { 1376 "id": 1, 1377 "target-prefix": [ 1378 "2001:db8:6401::1/128", 1379 "2001:db8:6401::2/128" 1380 ], 1381 "total-traffic-normal-per-protocol": [ 1382 { 1383 "unit": "megabit-ps", 1384 "protocol": 6, 1385 "peak-g": "50" 1386 }, 1387 { 1388 "unit": "megabit-ps", 1389 "protocol": 17, 1390 "peak-g": "10" 1391 } 1392 ] 1393 } 1394 ] 1395 } 1396 ] 1397 } 1398 } 1400 Figure 20: PUT to Convey the DOTS Traffic Baseline (2) 1402 The traffic baseline information should be updated to reflect 1403 legitimate overloads (e.g., flash crowds) to prevent unnecessary 1404 mitigation. 1406 6.3.2. Retrieve Installed Normal Traffic Baseline 1408 A GET request with 'tsid' Uri-Path parameter is used to retrieve a 1409 specific installed DOTS client domain baseline traffic information. 1410 The same procedure as defined in (Section 6.1.3) is followed. 1412 To retrieve all baseline information bound to a DOTS client, the DOTS 1413 client proceeds as specified in Section 6.1.1. 1415 6.3.3. Delete Installed Normal Traffic Baseline 1417 A DELETE request is used to delete the installed DOTS client domain 1418 normal traffic baseline. The same procedure as defined in 1419 (Section 6.1.4) is followed. 1421 6.4. Reset Installed Telemetry Setup 1423 Upon bootstrapping (or reboot or any other event that may alter the 1424 DOTS client setup), a DOTS client MAY send a DELETE request to set 1425 the telemetry parameters to default values. Such a request does not 1426 include any 'tsid'. An example of such request is depicted in 1427 Figure 21. 1429 Header: DELETE (Code=0.04) 1430 Uri-Path: ".well-known" 1431 Uri-Path: "dots" 1432 Uri-Path: "tm-setup" 1433 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1435 Figure 21: Delete Telemetry Configuration 1437 6.5. Conflict with Other DOTS Clients of the Same Domain 1439 A DOTS server may detect conflicts between requests to convey pipe 1440 and baseline information received from DOTS clients of the same DOTS 1441 client domain. 'conflict-information' is used to report the conflict 1442 to the DOTS client following similar conflict handling discussed in 1443 Section 4.4.1 of [I-D.ietf-dots-signal-channel]. The conflict cause 1444 can be set to one of these values: 1446 1: Overlapping targets (already defined in 1447 [I-D.ietf-dots-signal-channel]). 1449 TBA: Overlapping pipe scope (see Section 11). 1451 7. DOTS Pre-or-Ongoing Mitigation Telemetry 1453 There are two broad types of DDoS attacks, one is bandwidth consuming 1454 attack, the other is target resource consuming attack. This section 1455 outlines the set of DOTS telemetry attributes (Section 7.1) that 1456 covers both the types of attacks. The objective of these attributes 1457 is to allow for the complete knowledge of attacks and the various 1458 particulars that can best characterize attacks. 1460 The "ietf-dots-telemetry" YANG module (Section 9) augments the "ietf- 1461 dots-signal" with a new message type called "telemetry". The tree 1462 structure of the "telemetry" message type is shown Figure 24. 1464 The pre-or-ongoing-mitigation telemetry attributes are indicated by 1465 the path-suffix '/tm'. The '/tm' is appended to the path-prefix to 1466 form the URI used with a CoAP request to signal the DOTS telemetry. 1467 Pre-or-ongoing-mitigation telemetry attributes specified in 1468 Section 7.1 can be signaled between DOTS agents. 1470 Pre-or-ongoing-mitigation telemetry attributes may be sent by a DOTS 1471 client or a DOTS server. 1473 DOTS agents SHOULD bind pre-or-ongoing-mitigation telemetry data with 1474 mitigation requests relying upon the target clause. In particular, a 1475 telemetry PUT request sent after a mitigation request may include a 1476 reference to that mitigation request ('mid-list') as shown in 1477 Figure 22. An example illustrating requests correlation by means of 1478 'target-prefix' is shown in Figure 23. 1480 When generating telemetry data to send to a peer, the DOTS agent must 1481 auto-scale so that appropriate unit(s) are used. 1483 +-----------+ +-----------+ 1484 |DOTS client| |DOTS server| 1485 +-----------+ +-----------+ 1486 | | 1487 |=========Mitigation Request (mid)=====================>| 1488 | | 1489 |================ Telemetry (mid-list{mid})============>| 1490 | | 1492 Figure 22: Example of Request Correlation using 'mid' 1494 +-----------+ +-----------+ 1495 |DOTS client| |DOTS server| 1496 +-----------+ +-----------+ 1497 | | 1498 |<=============== Telemetry (target-prefix)=============| 1499 | | 1500 |=========Mitigation Request (target-prefix)===========>| 1501 | | 1503 Figure 23: Example of Request Correlation using Target Prefix 1505 DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry 1506 messages to the same peer more frequently than once every 'telemetry- 1507 notify-interval' (Section 6.1). If a telemetry notification is sent 1508 using a block-like transfer mechanism (e.g., 1509 [I-D.bosh-core-new-block]), this rate limit policy MUST NOT consider 1510 these individual blocks as separate notifications, but as a single 1511 notification. 1513 DOTS pre-or-ongoing-mitigation telemetry request and response 1514 messages MUST be marked as Non-Confirmable messages. 1516 augment /ietf-signal:dots-signal/ietf-signal:message-type: 1517 +--:(telemetry-setup) {dots-telemetry}? 1518 | +--rw telemetry* [cuid tsid] 1519 | ... 1520 +--:(telemetry) {dots-telemetry}? 1521 +--rw pre-or-ongoing-mitigation* [cuid tmid] 1522 +--rw cuid string 1523 +--rw cdid? string 1524 +--rw tmid uint32 1525 +--rw target 1526 | ... 1527 +--rw total-traffic* [unit] 1528 | ... 1529 +--rw total-traffic-protocol* [unit protocol] 1530 | ... 1531 +--rw total-traffic-port* [unit port] 1532 | ... 1533 +--rw total-attack-traffic* [unit] 1534 | ... 1535 +--rw total-attack-traffic-protocol* [unit protocol] 1536 | ... 1537 +--rw total-attack-traffic-port* [unit port] 1538 | ... 1539 +--rw total-attack-connection 1540 | ... 1541 +--rw total-attack-connection-port 1542 | ... 1543 +--rw attack-detail* [attack-id] 1544 ... 1546 Figure 24: Telemetry Message Type Tree Structure 1548 7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes 1550 The description and motivation behind each attribute are presented in 1551 Section 3. DOTS telemetry attributes are optionally signaled and 1552 therefore MUST NOT be treated as mandatory fields in the DOTS signal 1553 channel protocol. 1555 7.1.1. Target 1557 A target resource (Figure 25) is identified using the attributes 1558 'target-prefix', 'target-port-range', 'target-protocol', 'target- 1559 fqdn', 'target-uri', 'alias-name', or a pointer to a mitigation 1560 request ('mid-list'). 1562 +--:(telemetry) {dots-telemetry}? 1563 +--rw pre-or-ongoing-mitigation* [cuid tmid] 1564 +--rw cuid string 1565 +--rw cdid? string 1566 +--rw tmid uint32 1567 +--rw target 1568 | +--rw target-prefix* inet:ip-prefix 1569 | +--rw target-port-range* [lower-port] 1570 | | +--rw lower-port inet:port-number 1571 | | +--rw upper-port? inet:port-number 1572 | +--rw target-protocol* uint8 1573 | +--rw target-fqdn* inet:domain-name 1574 | +--rw target-uri* inet:uri 1575 | +--rw alias-name* string 1576 | +--rw mid-list* uint32 1577 +--rw total-traffic* [unit] 1578 | ... 1579 +--rw total-traffic-protocol* [unit protocol] 1580 | ... 1581 +--rw total-traffic-port* [unit port] 1582 | ... 1583 +--rw total-attack-traffic* [unit] 1584 | ... 1585 +--rw total-attack-traffic-protocol* [unit protocol] 1586 | ... 1587 +--rw total-attack-traffic-port* [unit port] 1588 | ... 1589 +--rw total-attack-connection 1590 | ... 1591 +--rw total-attack-connection-port 1592 | ... 1593 +--rw attack-detail* [attack-id] 1594 ... 1596 Figure 25: Target Tree Structure 1598 At least one of the attributes 'target-prefix', 'target-fqdn', 1599 'target-uri', 'alias-name', or 'mid-list' MUST be present in the 1600 target definition. 1602 If the target is subjected to bandwidth consuming attack, the 1603 attributes representing the percentile values of the 'attack-id' 1604 attack traffic are included. 1606 If the target is subjected to resource consuming DDoS attacks, the 1607 same attributes defined for Section 7.1.4 are applicable for 1608 representing the attack. 1610 This is an optional sub-attribute. 1612 7.1.2. Total Traffic 1614 The 'total-traffic' attribute (Figure 26) conveys the percentile 1615 values of total traffic observed during a DDoS attack. More granular 1616 total traffic can be conveyed in 'total-traffic-protocol' and 'total- 1617 traffic-port'. 1619 The 'total-traffic-protocol' represents the total traffic for a 1620 target and is transport-protocol specific. 1622 The 'total-traffic-port' represents the total traffic for a target 1623 per port number. 1625 +--:(telemetry) {dots-telemetry}? 1626 +--rw pre-or-ongoing-mitigation* [cuid tmid] 1627 +--rw cuid string 1628 +--rw cdid? string 1629 +--rw tmid uint32 1630 +--rw target 1631 | ... 1632 +--rw total-traffic* [unit] 1633 | +--rw unit unit 1634 | +--rw low-percentile-g? yang:gauge64 1635 | +--rw mid-percentile-g? yang:gauge64 1636 | +--rw high-percentile-g? yang:gauge64 1637 | +--rw peak-g? yang:gauge64 1638 +--rw total-traffic-protocol* [unit protocol] 1639 | +--rw protocol uint8 1640 | +--rw unit unit 1641 | +--rw low-percentile-g? yang:gauge64 1642 | +--rw mid-percentile-g? yang:gauge64 1643 | +--rw high-percentile-g? yang:gauge64 1644 | +--rw peak-g? yang:gauge64 1645 +--rw total-traffic-port* [unit port] 1646 | +--rw port inet:port-number 1647 | +--rw unit unit 1648 | +--rw low-percentile-g? yang:gauge64 1649 | +--rw mid-percentile-g? yang:gauge64 1650 | +--rw high-percentile-g? yang:gauge64 1651 | +--rw peak-g? yang:gauge64 1652 +--rw total-attack-traffic* [unit] 1653 | ... 1654 +--rw total-attack-traffic-protocol* [unit protocol] 1655 | ... 1656 +--rw total-attack-traffic-port* [unit port] 1657 | ... 1658 +--rw total-attack-connection 1659 | ... 1660 +--rw total-attack-connection-port 1661 | ... 1662 +--rw attack-detail* [attack-id] 1663 ... 1665 Figure 26: Total Traffic Tree Structure 1667 7.1.3. Total Attack Traffic 1669 The 'total-attack-traffic' attribute (Figure 27) conveys the total 1670 attack traffic identified by the DOTS client domain's DMS (or DDoS 1671 Detector). More granular total traffic can be conveyed in 'total- 1672 attack-traffic-protocol' and 'total-attack-traffic-port'. 1674 The 'total-attack-traffic-protocol' represents the total attack 1675 traffic for a target and is transport-protocol specific. 1677 The 'total-attack-traffic-port' represents the total attack traffic 1678 for a target per port number. 1680 +--:(telemetry) {dots-telemetry}? 1681 +--rw pre-or-ongoing-mitigation* [cuid tmid] 1682 +--rw cuid string 1683 +--rw cdid? string 1684 +--rw tmid uint32 1685 +--rw target 1686 | ... 1687 +--rw total-traffic* [unit] 1688 | ... 1689 +--rw total-traffic-protocol* [unit protocol] 1690 | ... 1691 +--rw total-traffic-port* [unit port] 1692 | ... 1693 +--rw total-attack-traffic* [unit] 1694 | +--rw unit unit 1695 | +--rw low-percentile-g? yang:gauge64 1696 | +--rw mid-percentile-g? yang:gauge64 1697 | +--rw high-percentile-g? yang:gauge64 1698 | +--rw peak-g? yang:gauge64 1699 +--rw total-attack-traffic-protocol* [unit protocol] 1700 | +--rw protocol uint8 1701 | +--rw unit unit 1702 | +--rw low-percentile-g? yang:gauge64 1703 | +--rw mid-percentile-g? yang:gauge64 1704 | +--rw high-percentile-g? yang:gauge64 1705 | +--rw peak-g? yang:gauge64 1706 +--rw total-attack-traffic-port* [unit port] 1707 | +--rw port inet:port-number 1708 | +--rw unit unit 1709 | +--rw low-percentile-g? yang:gauge64 1710 | +--rw mid-percentile-g? yang:gauge64 1711 | +--rw high-percentile-g? yang:gauge64 1712 | +--rw peak-g? yang:gauge64 1713 +--rw total-attack-connection 1714 | ... 1715 +--rw total-attack-connection-port 1716 | ... 1717 +--rw attack-detail* [attack-id] 1718 ... 1720 Figure 27: Total Attack Traffic Tree Structure 1722 7.1.4. Total Attack Connections 1724 If the target is subjected to resource consuming DDoS attack, the 1725 'total-attack-connection' attribute is used to convey the percentile 1726 values of total attack connections. The following optional sub- 1727 attributes for the target per transport-protocol are included to 1728 represent the attack characteristics: 1730 o The number of simultaneous attack connections to the target. 1731 o The number of simultaneous embryonic connections to the target. 1732 o The number of attack connections per second to the target. 1733 o The number of attack requests to the target. 1735 The total attack connections per port number is represented using 1736 'total-attack-connection-port' attribute. 1738 +--:(telemetry) {dots-telemetry}? 1739 +--rw pre-or-ongoing-mitigation* [cuid tmid] 1740 +--rw cuid string 1741 +--rw cdid? string 1742 +--rw tmid uint32 1743 +--rw target 1744 | ... 1745 +--rw total-attack-connection 1746 | +--rw low-percentile-l* [protocol] 1747 | | +--rw protocol uint8 1748 | | +--rw connection? yang:gauge64 1749 | | +--rw embryonic? yang:gauge64 1750 | | +--rw connection-ps? yang:gauge64 1751 | | +--rw request-ps? yang:gauge64 1752 | | +--rw partial-request-ps? yang:gauge64 1753 | +--rw mid-percentile-l* [protocol] 1754 | | +--rw protocol uint8 1755 | | +--rw connection? yang:gauge64 1756 | | +--rw embryonic? yang:gauge64 1757 | | +--rw connection-ps? yang:gauge64 1758 | | +--rw request-ps? yang:gauge64 1759 | | +--rw partial-request-ps? yang:gauge64 1760 | +--rw high-percentile-l* [protocol] 1761 | | +--rw protocol uint8 1762 | | +--rw connection? yang:gauge64 1763 | | +--rw embryonic? yang:gauge64 1764 | | +--rw connection-ps? yang:gauge64 1765 | | +--rw request-ps? yang:gauge64 1766 | | +--rw partial-request-ps? yang:gauge64 1767 | +--rw peak-l* [protocol] 1768 | +--rw protocol uint8 1769 | +--rw connection? yang:gauge64 1770 | +--rw embryonic? yang:gauge64 1771 | +--rw connection-ps? yang:gauge64 1772 | +--rw request-ps? yang:gauge64 1773 | +--rw partial-request-ps? yang:gauge64 1774 +--rw total-attack-connection-port 1775 | +--rw low-percentile-l* [protocol port] 1776 | | +--rw port inet:port-number 1777 | | +--rw protocol uint8 1778 | | +--rw connection? yang:gauge64 1779 | | +--rw embryonic? yang:gauge64 1780 | | +--rw connection-ps? yang:gauge64 1781 | | +--rw request-ps? yang:gauge64 1782 | | +--rw partial-request-ps? yang:gauge64 1783 | +--rw mid-percentile-l* [protocol port] 1784 | | +--rw port inet:port-number 1785 | | +--rw protocol uint8 1786 | | +--rw connection? yang:gauge64 1787 | | +--rw embryonic? yang:gauge64 1788 | | +--rw connection-ps? yang:gauge64 1789 | | +--rw request-ps? yang:gauge64 1790 | | +--rw partial-request-ps? yang:gauge64 1791 | +--rw high-percentile-l* [protocol port] 1792 | | +--rw port inet:port-number 1793 | | +--rw protocol uint8 1794 | | +--rw connection? yang:gauge64 1795 | | +--rw embryonic? yang:gauge64 1796 | | +--rw connection-ps? yang:gauge64 1797 | | +--rw request-ps? yang:gauge64 1798 | | +--rw partial-request-ps? yang:gauge64 1799 | +--rw peak-l* [protocol port] 1800 | +--rw port inet:port-number 1801 | +--rw protocol uint8 1802 | +--rw connection? yang:gauge64 1803 | +--rw embryonic? yang:gauge64 1804 | +--rw connection-ps? yang:gauge64 1805 | +--rw request-ps? yang:gauge64 1806 | +--rw partial-request-ps? yang:gauge64 1807 +--rw attack-detail* [attack-id] 1808 ... 1810 Figure 28: Total Attack Connections Tree Structure 1812 7.1.5. Attack Details 1814 This attribute (Figure 29) is used to signal a set of details 1815 characterizing an attack. The following sub-attributes describing 1816 the on-going attack can be signal as attack details. 1818 id: Vendor ID is a security vendor's Enterprise Number as registered 1819 with IANA [Enterprise-Numbers]. It is a four-byte integer value. 1821 attack-id: Unique identifier assigned for the attack. 1823 attack-name: Textual representation of attack description. Natural 1824 Language Processing techniques (e.g., word embedding) can possibly 1825 be used to map the attack description to an attack type. Textual 1826 representation of attack solves two problems: (a) avoids the need 1827 to create mapping tables manually between vendors and (2) avoids 1828 the need to standardize attack types which keep evolving. 1830 attack-severity: Attack severity. These values are supported: 1831 emergency (1), critical (2), and alert (3). 1833 start-time: The time the attack started. The attack's start time is 1834 expressed in seconds relative to 1970-01-01T00:00Z in UTC time 1835 (Section 2.4.1 of [RFC7049]). The CBOR encoding is modified so 1836 that the leading tag 1 (epoch-based date/time) MUST be omitted. 1838 end-time: The time the attack-id attack ended. The attack end time 1839 is expressed in seconds relative to 1970-01-01T00:00Z in UTC time 1840 (Section 2.4.1 of [RFC7049]). The CBOR encoding is modified so 1841 that the leading tag 1 (epoch-based date/time) MUST be omitted. 1843 source-count: A count of sources involved in the attack targeting 1844 the victim. 1846 top-talkers: A list of top talkers among attack sources. The top 1847 talkers are represented using the 'source-prefix'. 1849 'spoofed-status' is used whether a top talker is a spoofed IP 1850 address (e.g., reflection attacks) or not. 1852 If the target is subjected to bandwidth consuming attack, the 1853 attack traffic from each of the top talkers is included ('total- 1854 attack-traffic', Section 7.1.3). 1856 If the target is subjected to resource consuming DDoS attacks, the 1857 same attributes defined for Section 7.1.4 are applicable for 1858 representing the attack per talker. 1860 +--:(telemetry) {dots-telemetry}? 1861 +--rw pre-or-ongoing-mitigation* [cuid tmid] 1862 +--rw cuid string 1863 +--rw cdid? string 1864 +--rw tmid uint32 1865 +--rw target 1866 | ... 1867 +--rw attack-detail* [attack-id] 1868 +--rw id? uint32 1869 +--rw attack-id string 1870 +--rw attack-name? string 1871 +--rw attack-severity? attack-severity 1872 +--rw start-time? uint64 1873 +--rw end-time? uint64 1874 +--rw top-talker 1875 +--rw talker* [source-prefix] 1876 +--rw spoofed-status? boolean 1877 +--rw source-prefix inet:ip-prefix 1878 +--rw source-port-range* [lower-port] 1879 | +--rw lower-port inet:port-number 1880 | +--rw upper-port? inet:port-number 1881 +--rw source-icmp-type-range* [lower-type] 1882 | +--rw lower-type uint8 1883 | +--rw upper-type? uint8 1884 +--rw total-attack-traffic* [unit] 1885 | +--rw unit unit 1886 | +--rw low-percentile-g? yang:gauge64 1887 | +--rw mid-percentile-g? yang:gauge64 1888 | +--rw high-percentile-g? yang:gauge64 1889 | +--rw peak-g? yang:gauge64 1890 +--rw total-attack-connection 1891 +--rw low-percentile-l* [protocol] 1892 | ... 1893 +--rw mid-percentile-l* [protocol] 1894 | ... 1895 +--rw high-percentile-l* [protocol] 1896 | ... 1897 +--rw peak-l* [protocol] 1898 ... 1900 Figure 29: Attack Detail Tree Structure 1902 7.2. From DOTS Clients to DOTS Servers 1904 DOTS clients uses PUT request to signal pre-or-ongoing-mitigation 1905 telemetry to DOTS servers. An example of such request is shown in 1906 Figure 30. 1908 Header: PUT (Code=0.03) 1909 Uri-Path: ".well-known" 1910 Uri-Path: "dots" 1911 Uri-Path: "tm" 1912 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1913 Uri-Path: "tmid=123" 1914 Content-Format: "application/dots+cbor" 1916 { 1917 "ietf-dots-telemetry:telemetry": { 1918 "pre-or-ongoing-mitigation": [ 1919 { 1920 "target": { 1921 "target-prefix": [ 1922 "2001:db8::1/128" 1923 ] 1924 }, 1925 "total-attack-traffic-protocol": [ 1926 { 1927 "protocol": 17, 1928 "unit": "megabit-ps", 1929 "mid-percentile-g": "900" 1930 } 1931 ], 1932 "attack-detail": [ 1933 { 1934 "attack-id": "an-id", 1935 "start-time": "1957811234", 1936 "attack-severity": "emergency" 1937 } 1938 ] 1939 } 1940 ] 1941 } 1942 } 1944 Figure 30: PUT to Send Pre-or-Ongoing-Mitigation Telemetry 1946 'cuid' is a mandatory Uri-Path parameter for PUT requests. 1948 The following additional Uri-Path parameter is defined: 1950 tmid: Telemetry Identifier is an identifier for the DOTS pre-or- 1951 ongoing-mitigation telemetry data represented as an integer. 1952 This identifier MUST be generated by DOTS clients. 'tmid' values 1953 MUST increase monotonically (when a new PUT is generated by a 1954 DOTS client to convey pre-or-ongoing-mitigation telemetry). 1956 This is a mandatory attribute. 1958 'cuid' and 'tmid' MUST NOT appear in the PUT request message body. 1960 At least 'target' attribute and another pre-or-ongoing-mitigation 1961 attributes (Section 7.1) MUST be present in the PUT request. If only 1962 the 'target' attribute is present, this request is handled as per 1963 Section 7.3. 1965 The relative order of two PUT requests carrying DOTS pre-or-ongoing- 1966 mitigation telemetry from a DOTS client is determined by comparing 1967 their respective 'tmid' values. If such two requests have 1968 overlapping 'target', the PUT request with higher numeric 'tmid' 1969 value will override the request with a lower numeric 'tmid' value. 1970 The overlapped lower numeric 'tmid' MUST be automatically deleted and 1971 no longer be available. 1973 The DOTS server indicates the result of processing a PUT request 1974 using CoAP response codes. The response code 2.04 (Changed) is 1975 returned if the DOTS server has accepted the pre-or-ongoing- 1976 mitigation telemetry. The error response code 5.03 (Service 1977 Unavailable) is returned if the DOTS server has erred. 5.03 uses Max- 1978 Age option to indicate the number of seconds after which to retry. 1980 How long a DOTS server maintains a 'tmid' as active or logs the 1981 enclosed telemetry information is implementation-specific. Note that 1982 if a 'tmid' is still active, then logging details are updated by the 1983 DOTS server as a function of the updates received from the peer DOTS 1984 client. 1986 A DOTS client that lost the state of its active 'tmids' or has to set 1987 'tmid' back to zero (e.g., crash or restart) MUST send a GET request 1988 to the DOTS server to retrieve the list of active 'tmid'. The DOTS 1989 client may then delete 'tmids' that should not be active anymore 1990 (Figure 31). Sending a DELETE with no 'tmid' indicates that all 1991 'tmids' must be deactivated (Figure 32). 1993 Header: DELETE (Code=0.04) 1994 Uri-Path: ".well-known" 1995 Uri-Path: "dots" 1996 Uri-Path: "tm" 1997 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 1998 Uri-Path: "tmid=123" 2000 Figure 31: Delete a Pre-or-Ongoing-Mitigation Telemetry 2002 Header: DELETE (Code=0.04) 2003 Uri-Path: ".well-known" 2004 Uri-Path: "dots" 2005 Uri-Path: "tm" 2006 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2008 Figure 32: Delete All Pre-or-Ongoing-Mitigation Telemetry 2010 7.3. From DOTS Servers to DOTS Clients 2012 The pre-or-ongoing-mitigation (attack details, in particular) can 2013 also be signaled from DOTS servers to DOTS clients. For example, the 2014 DOTS server co-located with a DDoS detector collects monitoring 2015 information from the target network, identifies DDoS attack using 2016 statistical analysis or deep learning techniques, and signals the 2017 attack details to the DOTS client. 2019 The DOTS client can use the attack details to decide whether to 2020 trigger a DOTS mitigation request or not. Furthermore, the security 2021 operation personnel at the DOTS client domain can use the attack 2022 details to determine the protection strategy and select the 2023 appropriate DOTS server for mitigating the attack. 2025 In order to receive pre-or-ongoing-mitigation telemetry notifications 2026 from a DOTS server, a DOTS client MUST send a PUT (followed by a GET) 2027 with the target filter. An example of such PUT request is shown in 2028 Figure 33. In order to avoid maintaining a long list of such 2029 requests, it is RECOMMENDED that DOTS clients include all targets in 2030 the same request. DOTS servers may be instructed to restrict the 2031 number of pre-or-ongoing-mitigation requests per DOTS client domain. 2032 This request MUST be maintained active by the DOTS server until a 2033 delete request is received from the same DOTS client to clear this 2034 pre-or-ongoing-mitigation telemetry. 2036 The relative order of two PUT requests carrying DOTS pre-or-ongoing- 2037 mitigation telemetry from a DOTS client is determined by comparing 2038 their respective 'tmid' values. If such two requests have 2039 overlapping 'target', the PUT request with higher numeric 'tmid' 2040 value will override the request with a lower numeric 'tmid' value. 2041 The overlapped lower numeric 'tmid' MUST be automatically deleted and 2042 no longer be available. 2044 Header: PUT (Code=0.03) 2045 Uri-Path: ".well-known" 2046 Uri-Path: "dots" 2047 Uri-Path: "tm" 2048 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2049 Uri-Path: "tmid=123" 2050 Content-Format: "application/dots+cbor" 2052 { 2053 "ietf-dots-telemetry:telemetry": { 2054 "pre-or-ongoing-mitigation": [ 2055 { 2056 "target": { 2057 "target-prefix": [ 2058 "2001:db8::/32" 2059 ] 2060 } 2061 } 2062 ] 2063 } 2064 } 2066 Figure 33: PUT to Request Pre-or-Ongoing-Mitigation Telemetry 2068 DOTS clients of the same domain can request to receive pre-or- 2069 ongoing-mitigation telemetry bound to the same target. 2071 The DOTS client conveys the Observe Option set to '0' in the GET 2072 request to receive asynchronous notifications carrying pre-or- 2073 ongoing-mitigation telemetry data from the DOTS server. The GET 2074 request specifies a 'tmid' (Figure 34) or not (Figure 35). 2076 Header: GET (Code=0.01) 2077 Uri-Path: ".well-known" 2078 Uri-Path: "dots" 2079 Uri-Path: "tm" 2080 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2081 Uri-Path: "tmid=123" 2082 Observe: 0 2084 Figure 34: GET to Subscribe to Telemetry Asynchronous Notifications 2085 for a Specific 'tmid' 2087 Header: GET (Code=0.01) 2088 Uri-Path: ".well-known" 2089 Uri-Path: "dots" 2090 Uri-Path: "tm" 2091 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2092 Observe: 0 2094 Figure 35: GET to Subscribe to Telemetry Asynchronous Notifications 2095 for All 'tmids' 2097 The DOTS client can filter out the asynchronous notifications from 2098 the DOTS server by indicating one or more Uri-Query options in its 2099 GET request. A Uri-Query option can include the following 2100 parameters: target-prefix, lower-port, upper-port, target-protocol, 2101 target-fqdn, target-uri, alias-name. An example of request to 2102 subscribe to asynchronous UDP telemetry notifications is shown in 2103 Figure 36. This filter will be applied for all 'tmids'. 2105 Header: GET (Code=0.01) 2106 Uri-Path: ".well-known" 2107 Uri-Path: "dots" 2108 Uri-Path: "tm" 2109 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2110 Uri-Query: "target-protocol=17" 2111 Observe: 0 2113 Figure 36: GET Request to Receive Telemetry Asynchronous 2114 Notifications Filtered using Uri-Query 2116 The DOTS server will send asynchronous notifications to the DOTS 2117 client when an attack event is detected following similar 2118 considerations as in Section 4.4.2.1 of 2119 [I-D.ietf-dots-signal-channel]. An example of a pre-or-ongoing- 2120 mitigation telemetry notification is shown in Figure 37. 2122 { 2123 "ietf-dots-telemetry:telemetry": { 2124 "pre-or-ongoing-mitigation": [ 2125 { 2126 "tmid": 123, 2127 "target": { 2128 "target-prefix": [ 2129 "2001:db8::1/128" 2130 ] 2131 }, 2132 "target-protocol": [ 2133 17 2134 ], 2135 "total-attack-traffic": [ 2136 { 2137 "unit": "megabit-ps", 2138 "mid-percentile-g": "900" 2139 } 2140 ], 2141 "attack-detail": [ 2142 { 2143 "attack-id": "an-id", 2144 "start-time": "1957818434", 2145 "attack-severity": "emergency" 2146 } 2147 ] 2148 } 2149 ] 2150 } 2151 } 2153 Figure 37: Message Body of a Pre-or-Ongoing-Mitigation Telemetry 2154 Notification from the DOTS Server 2156 A DOTS server sends the aggregate data for a target using 'total- 2157 attack-traffic' attribute. The aggregate assumes that Uri-Query 2158 filters are applied on the target. The DOTS server MAY include more 2159 granular data when needed (that is, 'total-attack-traffic-protocol' 2160 and 'total-attack-traffic-port'). If a port filter (or protocol 2161 filter) is included in a request, 'total-attack-traffic-protocol' (or 2162 'total-attack-traffic-port') conveys the data with the port (or 2163 protocol) filter applied. 2165 A DOTS server may aggregate pre-or-ongoing-mitigation data (e.g., 2166 'top-talkers') for all targets of a domain, or when justified, send 2167 specific information (e.g., 'top-talkers') per individual targets. 2169 The DOTS client may log pre-or-ongoing-mitigation telemetry data with 2170 an alert sent to an administrator or a network controller. The DOTS 2171 client may send a mitigation request if the attack cannot be handled 2172 locally. 2174 A DOTS client that is not interested to receive pre-or-ongoing- 2175 mitigation telemetry data for a target MUST send a delete request 2176 similar to the one depicted in Figure 31. 2178 8. DOTS Telemetry Mitigation Status Update 2180 8.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry 2181 Attributes 2183 The mitigation efficacy telemetry attributes can be signaled from 2184 DOTS clients to DOTS servers as part of the periodic mitigation 2185 efficacy updates to the server (Section 5.3.4 of 2186 [I-D.ietf-dots-signal-channel]). 2188 Total Attack Traffic: The overall attack traffic as observed from 2189 the DOTS client perspective during an active mitigation. See 2190 Figure 27. 2192 Attack Details: The overall attack details as observed from the 2193 DOTS client perspective during an active mitigation. See 2194 Section 7.1.5. 2196 The "ietf-dots-telemetry" YANG module augments the "mitigation-scope" 2197 type message defined in "ietf-dots-signal" so that these attributes 2198 can be signalled by a DOTS client in a mitigation efficacy update 2199 (Figure 38). 2201 augment /ietf-signal:dots-signal/ietf-signal:message-type 2202 /ietf-signal:mitigation-scope/ietf-signal:scope: 2203 +--rw total-attack-traffic* [unit] {dots-telemetry}? 2204 | ... 2205 +--rw attack-detail* [attack-id] {dots-telemetry}? 2206 +--rw id? uint32 2207 +--rw attack-id string 2208 +--rw attack-name? string 2209 +--rw attack-severity? attack-severity 2210 +--rw start-time? uint64 2211 +--rw end-time? uint64 2212 +--rw source-count 2213 | ... 2214 +--rw top-talker 2215 ... 2217 Figure 38: Telemetry Efficacy Update Tree Structure 2219 In order to signal telemetry data in a mitigation efficacy update, it 2220 is RECOMMENDED that the DOTS client has already established a DOTS 2221 telemetry setup session with the server in 'idle' time. 2223 Header: PUT (Code=0.03) 2224 Uri-Path: ".well-known" 2225 Uri-Path: "dots" 2226 Uri-Path: "mitigate" 2227 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2228 Uri-Path: "mid=123" 2229 If-Match: 2230 Content-Format: "application/dots+cbor" 2232 { 2233 "ietf-dots-signal-channel:mitigation-scope": { 2234 "scope": [ 2235 { 2236 "alias-name": [ 2237 "https1", 2238 "https2" 2239 ], 2240 "attack-status": "under-attack", 2241 "ietf-dots-telemetry:total-attack-traffic": [ 2242 { 2243 "ietf-dots-telemetry:unit": "megabit-ps", 2244 "ietf-dots-telemetry:mid-percentile-g": "900" 2245 } 2246 ] 2247 } 2248 ] 2249 } 2250 } 2252 Figure 39: An Example of Mitigation Efficacy Update with Telemetry 2253 Attributes 2255 8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry 2256 Attributes 2258 The mitigation status telemetry attributes can be signaled from the 2259 DOTS server to the DOTS client as part of the periodic mitigation 2260 status update (Section 5.3.3 of [I-D.ietf-dots-signal-channel]). In 2261 particular, DOTS clients can receive asynchronous notifications of 2262 the attack details from DOTS servers using the Observe option defined 2263 in [RFC7641]. 2265 In order to make use of this feature, DOTS clients MUST establish a 2266 telemetry setup session with the DOTS server in 'idle' time and MUST 2267 set the 'server-originated-telemetry' attribute to 'true'. 2269 DOTS servers MUST NOT include telemetry attributes in mitigation 2270 status updates sent to DOTS clients for which 'server-originated- 2271 telemetry' attribute is set to 'false'. 2273 As defined in [RFC8612], the actual mitigation activities can include 2274 several countermeasure mechanisms. The DOTS server signals the 2275 current operational status to each relevant countermeasure. A list 2276 of attacks detected by each countermeasure MAY also be included. The 2277 same attributes defined for Section 7.1.5 are applicable for 2278 describing the attacks detected and mitigated. 2280 The "ietf-dots-telemetry" YANG module (Section 9) augments the 2281 "mitigation-scope" type message defined in "ietf-dots-signal" with 2282 telemetry data as depicted in following tree structure: 2284 augment /ietf-signal:dots-signal/ietf-signal:message-type 2285 /ietf-signal:mitigation-scope/ietf-signal:scope: 2286 +--ro total-traffic* [unit] {dots-telemetry}? 2287 | +--ro unit unit 2288 | +--ro low-percentile-g? yang:gauge64 2289 | +--ro mid-percentile-g? yang:gauge64 2290 | +--ro high-percentile-g? yang:gauge64 2291 | +--ro peak-g? yang:gauge64 2292 +--rw total-attack-traffic* [unit] {dots-telemetry}? 2293 | +--rw unit unit 2294 | +--rw low-percentile-g? yang:gauge64 2295 | +--rw mid-percentile-g? yang:gauge64 2296 | +--rw high-percentile-g? yang:gauge64 2297 | +--rw peak-g? yang:gauge64 2298 +--ro total-attack-connection {dots-telemetry}? 2299 | +--ro low-percentile-c 2300 | | +--ro connection? yang:gauge64 2301 | | +--ro embryonic? yang:gauge64 2302 | | +--ro connection-ps? yang:gauge64 2303 | | +--ro request-ps? yang:gauge64 2304 | | +--ro partial-request-ps? yang:gauge64 2305 | +--ro mid-percentile-c 2306 | | ... 2307 | +--ro high-percentile-c 2308 | | ... 2309 | +--ro peak-c 2310 | ... 2311 +--rw attack-detail* [attack-id] {dots-telemetry}? 2312 +--rw id? uint32 2313 +--rw attack-id string 2314 +--rw attack-name? string 2315 +--rw attack-severity? attack-severity 2316 +--rw start-time? uint64 2317 +--rw end-time? uint64 2318 +--rw source-count 2319 | +--rw low-percentile-g? yang:gauge64 2320 | +--rw mid-percentile-g? yang:gauge64 2321 | +--rw high-percentile-g? yang:gauge64 2322 | +--rw peak-g? yang:gauge64 2323 +--rw top-talker 2324 +--rw talker* [source-prefix] 2325 +--rw spoofed-status? boolean 2326 +--rw source-prefix inet:ip-prefix 2327 +--rw source-port-range* [lower-port] 2328 | +--rw lower-port inet:port-number 2329 | +--rw upper-port? inet:port-number 2330 +--rw source-icmp-type-range* [lower-type] 2331 | +--rw lower-type uint8 2332 | +--rw upper-type? uint8 2333 +--rw total-attack-traffic* [unit] 2334 | +--rw unit unit 2335 | +--rw low-percentile-g? yang:gauge64 2336 | +--rw mid-percentile-g? yang:gauge64 2337 | +--rw high-percentile-g? yang:gauge64 2338 | +--rw peak-g? yang:gauge64 2339 +--rw total-attack-connection 2340 +--rw low-percentile-c 2341 | +--rw connection? yang:gauge64 2342 | +--rw embryonic? yang:gauge64 2343 | +--rw connection-ps? yang:gauge64 2344 | +--rw request-ps? yang:gauge64 2345 | +--rw partial-request-ps? yang:gauge64 2346 +--rw mid-percentile-c 2347 | ... 2348 +--rw high-percentile-c 2349 | ... 2350 +--rw peak-c 2351 ... 2353 Figure 40 shows an example of an asynchronous notification of attack 2354 mitigation status from the DOTS server. This notification signals 2355 both the mid-percentile value of processed attack traffic and the 2356 peak percentile value of unique sources involved in the attack. 2358 { 2359 "ietf-dots-signal-channel:mitigation-scope": { 2360 "scope": [ 2361 { 2362 "mid": 12332, 2363 "mitigation-start": "1507818434", 2364 "alias-name": [ 2365 "https1", 2366 "https2" 2367 ], 2368 "lifetime": 1600, 2369 "status": "attack-successfully-mitigated", 2370 "bytes-dropped": "134334555", 2371 "bps-dropped": "43344", 2372 "pkts-dropped": "333334444", 2373 "pps-dropped": "432432", 2374 "ietf-dots-telemetry:total-attack-traffic": [ 2375 { 2376 "ietf-dots-telemetry:unit": "megabit-ps", 2377 "ietf-dots-telemetry:mid-percentile-g": "900" 2378 } 2379 ], 2380 "ietf-dots-telemetry::attack-detail": [ 2381 { 2382 "ietf-dots-telemetry:attack-id": "another-id", 2383 "ietf-dots-telemetry:source-count": { 2384 "ietf-dots-telemetry:peak-g": "10000" 2385 } 2386 } 2387 ] 2388 } 2389 ] 2390 } 2391 } 2393 Figure 40: Response Body of a Mitigation Status With Telemetry 2394 Attributes 2396 DOTS clients can filter out the asynchronous notifications from the 2397 DOTS server by indicating one or more Uri-Query options in its GET 2398 request. A Uri-Query option can include the following parameters: 2399 target-prefix, lower-port, upper-port, target-protocol, target-fqdn, 2400 target-uri, alias-name. An example of request to subscribe to 2401 asynchronous notifications bound to the "http1" alias is shown in 2402 Figure 41. 2404 Header: GET (Code=0.01) 2405 Uri-Path: ".well-known" 2406 Uri-Path: "dots" 2407 Uri-Path: "mitigate" 2408 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 2409 Uri-Path: "mid=12332" 2410 Uri-Query: "target-alias=https1" 2411 Observe: 0 2413 Figure 41: GET Request to Receive Asynchronous Notifications Filtered 2414 using Uri-Query 2416 If the target query does not match the target of the enclosed 'mid' 2417 as maintained by the DOTS server, the latter MUST respond with a 4.04 2418 (Not Found) error response code. The DOTS server MUST NOT add a new 2419 observe entry if this query overlaps with an existing one. 2421 9. YANG Module 2423 This module uses types defined in [RFC6991] and [RFC8345]. 2425 file "ietf-dots-telemetry@2020-04-15.yang" 2426 module ietf-dots-telemetry { 2427 yang-version 1.1; 2428 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry"; 2429 prefix dots-telemetry; 2431 import ietf-dots-signal-channel { 2432 prefix ietf-signal; 2433 reference 2434 "RFC SSSS: Distributed Denial-of-Service Open Threat 2435 Signaling (DOTS) Signal Channel Specification"; 2436 } 2437 import ietf-dots-data-channel { 2438 prefix ietf-data; 2439 reference 2440 "RFC DDDD: Distributed Denial-of-Service Open Threat 2441 Signaling (DOTS) Data Channel Specification"; 2442 } 2443 import ietf-yang-types { 2444 prefix yang; 2445 reference 2446 "Section 3 of RFC 6991"; 2447 } 2448 import ietf-inet-types { 2449 prefix inet; 2450 reference 2451 "Section 4 of RFC 6991"; 2453 } 2454 import ietf-network-topology { 2455 prefix nt; 2456 reference 2457 "Section 6.2 of RFC 8345: A YANG Data Model for Network 2458 Topologies"; 2459 } 2461 organization 2462 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 2463 contact 2464 "WG Web: 2465 WG List: 2467 Author: Mohamed Boucadair 2468 2470 Author: Konda, Tirumaleswar Reddy 2471 "; 2472 description 2473 "This module contains YANG definitions for the signaling 2474 of DOTS telemetry exchanged between a DOTS client and 2475 a DOTS server, by means of the DOTS signal channel. 2477 Copyright (c) 2020 IETF Trust and the persons identified as 2478 authors of the code. All rights reserved. 2480 Redistribution and use in source and binary forms, with or 2481 without modification, is permitted pursuant to, and subject 2482 to the license terms contained in, the Simplified BSD License 2483 set forth in Section 4.c of the IETF Trust's Legal Provisions 2484 Relating to IETF Documents 2485 (http://trustee.ietf.org/license-info). 2487 This version of this YANG module is part of RFC XXXX; see 2488 the RFC itself for full legal notices."; 2490 revision 2020-04-15 { 2491 description 2492 "Initial revision."; 2493 reference 2494 "RFC XXXX: Distributed Denial-of-Service Open Threat 2495 Signaling (DOTS) Telemetry"; 2496 } 2498 feature dots-telemetry { 2499 description 2500 "This feature means that the DOTS signal channel is able 2501 to convey DOTS telemetry data between DOTS clients and 2502 servers."; 2503 } 2505 typedef attack-severity { 2506 type enumeration { 2507 enum emergency { 2508 value 1; 2509 description 2510 "The attack is severe: emergency."; 2511 } 2512 enum critical { 2513 value 2; 2514 description 2515 "The attack is critical."; 2516 } 2517 enum alert { 2518 value 3; 2519 description 2520 "This is an alert."; 2521 } 2522 } 2523 description 2524 "Enumeration for attack severity."; 2525 } 2527 typedef unit-type { 2528 type enumeration { 2529 enum packet-ps { 2530 value 1; 2531 description 2532 "Packets per second (pps)."; 2533 } 2534 enum bit-ps { 2535 value 2; 2536 description 2537 "Bits per Second (bit/s)."; 2538 } 2539 enum byte-ps { 2540 value 3; 2541 description 2542 "Bytes per second (Byte/s)."; 2543 } 2544 } 2545 description 2546 "Enumeration to indicate which unit type is used."; 2547 } 2548 typedef unit { 2549 type enumeration { 2550 enum packet-ps { 2551 value 1; 2552 description 2553 "Packets per second (pps)."; 2554 } 2555 enum bit-ps { 2556 value 2; 2557 description 2558 "Bits per Second (bps)."; 2559 } 2560 enum byte-ps { 2561 value 3; 2562 description 2563 "Bytes per second (Bps)."; 2564 } 2565 enum kilopacket-ps { 2566 value 4; 2567 description 2568 "Kilo packets per second (kpps)."; 2569 } 2570 enum kilobit-ps { 2571 value 5; 2572 description 2573 "Kilobits per second (kbps)."; 2574 } 2575 enum kilobyte-ps { 2576 value 6; 2577 description 2578 "Kilobytes per second (kBps)."; 2579 } 2580 enum megapacket-ps { 2581 value 7; 2582 description 2583 "Mega packets per second (Mpps)."; 2584 } 2585 enum megabit-ps { 2586 value 8; 2587 description 2588 "Megabits per second (Mbps)."; 2589 } 2590 enum megabyte-ps { 2591 value 9; 2592 description 2593 "Megabytes per second (MBps)."; 2594 } 2595 enum gigapacket-ps { 2596 value 10; 2597 description 2598 "Giga packets per second (Gpps)."; 2599 } 2600 enum gigabit-ps { 2601 value 11; 2602 description 2603 "Gigabits per second (Gbps)."; 2604 } 2605 enum gigabyte-ps { 2606 value 12; 2607 description 2608 "Gigabytes per second (GBps)."; 2609 } 2610 enum terapacket-ps { 2611 value 13; 2612 description 2613 "Tera packets per second (Tpps)."; 2614 } 2615 enum terabit-ps { 2616 value 14; 2617 description 2618 "Terabits per second (Tbps)."; 2619 } 2620 enum terabyte-ps { 2621 value 15; 2622 description 2623 "Terabytes per second (TBps)."; 2624 } 2625 } 2626 description 2627 "Enumeration to indicate which unit is used."; 2628 } 2630 typedef interval { 2631 type enumeration { 2632 enum hour { 2633 value 1; 2634 description 2635 "Hour."; 2636 } 2637 enum day { 2638 value 2; 2639 description 2640 "Day."; 2641 } 2642 enum week { 2643 value 3; 2644 description 2645 "Week."; 2646 } 2647 enum month { 2648 value 4; 2649 description 2650 "Month."; 2651 } 2652 } 2653 description 2654 "Enumeration to indicate the overall measurement period."; 2655 } 2657 typedef sample { 2658 type enumeration { 2659 enum second { 2660 value 1; 2661 description 2662 "Second."; 2663 } 2664 enum 5-seconds { 2665 value 2; 2666 description 2667 "5 seconds."; 2668 } 2669 enum 30-seconds { 2670 value 3; 2671 description 2672 "30 seconds."; 2673 } 2674 enum minute { 2675 value 4; 2676 description 2677 "One minute."; 2678 } 2679 enum 5-minutes { 2680 value 5; 2681 description 2682 "5 minutes."; 2683 } 2684 enum 10-minutes { 2685 value 6; 2686 description 2687 "10 minutes."; 2688 } 2689 enum 30-minutes { 2690 value 7; 2691 description 2692 "30 minutes."; 2693 } 2694 enum hour { 2695 value 8; 2696 description 2697 "One hour."; 2698 } 2699 } 2700 description 2701 "Enumeration to indicate the measurement perdiod."; 2702 } 2704 typedef percentile { 2705 type decimal64 { 2706 fraction-digits 2; 2707 } 2708 description 2709 "The nth percentile of a set of data is the 2710 value at which n percent of the data is below it."; 2711 } 2713 grouping percentile-config { 2714 description 2715 "Configuration of low, mid, and high percentile values."; 2716 leaf measurement-interval { 2717 type interval; 2718 description 2719 "Defines the period on which percentiles are computed."; 2720 } 2721 leaf measurement-sample { 2722 type sample; 2723 description 2724 "Defines the time distribution for measuring 2725 values that are used to compute percentiles."; 2726 } 2727 leaf low-percentile { 2728 type percentile; 2729 default "10.00"; 2730 description 2731 "Low percentile. If set to '0', this means low-percentiles 2732 are disabled."; 2733 } 2734 leaf mid-percentile { 2735 type percentile; 2736 must '. >= ../low-percentile' { 2737 error-message 2738 "The mid-percentile must be greater than 2739 or equal to the low-percentile."; 2741 } 2742 default "50.00"; 2743 description 2744 "Mid percentile. If set to the same value as low-percentiles, 2745 this means mid-percentiles are disabled."; 2746 } 2747 leaf high-percentile { 2748 type percentile; 2749 must '. >= ../mid-percentile' { 2750 error-message 2751 "The high-percentile must be greater than 2752 or equal to the mid-percentile."; 2753 } 2754 default "90.00"; 2755 description 2756 "High percentile. If set to the same value as mid-percentiles, 2757 this means high-percentiles are disabled."; 2758 } 2759 } 2761 grouping percentile { 2762 description 2763 "Generic grouping for percentile."; 2764 leaf low-percentile-g { 2765 type yang:gauge64; 2766 description 2767 "Low traffic."; 2768 } 2769 leaf mid-percentile-g { 2770 type yang:gauge64; 2771 description 2772 "Mid percentile."; 2773 } 2774 leaf high-percentile-g { 2775 type yang:gauge64; 2776 description 2777 "High percentile."; 2778 } 2779 leaf peak-g { 2780 type yang:gauge64; 2781 description 2782 "Peak"; 2783 } 2784 } 2786 grouping unit-config { 2787 description 2788 "Generic grouping for unit configuration."; 2790 list unit-config { 2791 key "unit"; 2792 description 2793 "Controls which units are allowed when sharing telemetry 2794 data."; 2795 leaf unit { 2796 type unit-type; 2797 description 2798 "Can be packet-ps, bit-ps, or byte-ps."; 2799 } 2800 leaf unit-status { 2801 type boolean; 2802 mandatory true; 2803 description 2804 "Enable/disable the use of the measurement unit."; 2805 } 2806 } 2807 } 2809 grouping traffic-unit { 2810 description 2811 "Grouping of traffic as a function of measurement unit."; 2812 leaf unit { 2813 type unit; 2814 description 2815 "The traffic can be measured using unit types: packets 2816 per second (PPS), Bits per Second (BPS), and/or 2817 bytes per second. DOTS agents auto-scale to the appropriate 2818 units (e.g., megabit-ps, kilobit-ps)."; 2819 } 2820 uses percentile; 2821 } 2823 grouping traffic-unit-protocol { 2824 description 2825 "Grouping of traffic of a given transport protocol as 2826 a function of measurement unit."; 2827 leaf protocol { 2828 type uint8; 2829 description 2830 "The transport protocol. 2831 Values are taken from the IANA Protocol Numbers registry: 2832 . 2834 For example, this field contains 6 for TCP, 2835 17 for UDP, 33 for DCCP, or 132 for SCTP."; 2836 } 2837 uses traffic-unit; 2839 } 2841 grouping traffic-unit-port { 2842 description 2843 "Grouping of traffic bound to port number as 2844 a function of measurement unit."; 2845 leaf port { 2846 type inet:port-number; 2847 description 2848 "Port number."; 2849 } 2850 uses traffic-unit; 2851 } 2853 grouping total-connection-capacity { 2854 description 2855 "Total Connections Capacity. If the target is subjected 2856 to resource consuming DDoS attack, these attributes are 2857 useful to detect resource consuming DDoS attacks"; 2858 leaf connection { 2859 type uint64; 2860 description 2861 "The maximum number of simultaneous connections that 2862 are allowed to the target server. The threshold is 2863 transport-protocol specific because the target server 2864 could support multiple protocols."; 2865 } 2866 leaf connection-client { 2867 type uint64; 2868 description 2869 "The maximum number of simultaneous connections that 2870 are allowed to the target server per client."; 2871 } 2872 leaf embryonic { 2873 type uint64; 2874 description 2875 "The maximum number of simultaneous embryonic connections 2876 that are allowed to the target server. The term 'embryonic 2877 connection' refers to a connection whose connection handshake 2878 is not finished and embryonic connection is only possible in 2879 connection-oriented transport protocols like TCP or SCTP."; 2880 } 2881 leaf embryonic-client { 2882 type uint64; 2883 description 2884 "The maximum number of simultaneous embryonic connections 2885 that are allowed to the target server per client."; 2886 } 2887 leaf connection-ps { 2888 type uint64; 2889 description 2890 "The maximum number of connections allowed per second 2891 to the target server."; 2892 } 2893 leaf connection-client-ps { 2894 type uint64; 2895 description 2896 "The maximum number of connections allowed per second 2897 to the target server per client."; 2898 } 2899 leaf request-ps { 2900 type uint64; 2901 description 2902 "The maximum number of requests allowed per second 2903 to the target server."; 2904 } 2905 leaf request-client-ps { 2906 type uint64; 2907 description 2908 "The maximum number of requests allowed per second 2909 to the target server per client."; 2910 } 2911 leaf partial-request-ps { 2912 type uint64; 2913 description 2914 "The maximum number of partial requests allowed per 2915 second to the target server."; 2916 } 2917 leaf partial-request-client-ps { 2918 type uint64; 2919 description 2920 "The maximum number of partial requests allowed per 2921 second to the target server per client."; 2922 } 2923 } 2925 grouping total-connection-capacity-protocol { 2926 description 2927 "Total Connections Capacity per protocol. If the target is subjected 2928 to resource consuming DDoS attack, these attributes are 2929 useful to detect resource consuming DDoS attacks"; 2930 leaf protocol { 2931 type uint8; 2932 description 2933 "The transport protocol. 2934 Values are taken from the IANA Protocol Numbers registry: 2936 ."; 2937 } 2938 uses total-connection-capacity; 2939 } 2941 grouping connection { 2942 description 2943 "A set of attributes which represent the attack 2944 characteristics"; 2945 leaf connection { 2946 type yang:gauge64; 2947 description 2948 "The number of simultaneous attack connections to 2949 the target server."; 2950 } 2951 leaf embryonic { 2952 type yang:gauge64; 2953 description 2954 "The number of simultaneous embryonic connections to 2955 the target server."; 2956 } 2957 leaf connection-ps { 2958 type yang:gauge64; 2959 description 2960 "The number of attack connections per second to 2961 the target server."; 2962 } 2963 leaf request-ps { 2964 type yang:gauge64; 2965 description 2966 "The number of attack requests per second to 2967 the target server."; 2968 } 2969 leaf partial-request-ps { 2970 type yang:gauge64; 2971 description 2972 "The number of attack partial requests to 2973 the target server."; 2974 } 2975 } 2977 grouping connection-percentile { 2978 description 2979 "Total attack connections."; 2980 container low-percentile-c { 2981 description 2982 "Low percentile of attack connections."; 2983 uses connection; 2985 } 2986 container mid-percentile-c { 2987 description 2988 "Mid percentile of attack connections."; 2989 uses connection; 2990 } 2991 container high-percentile-c { 2992 description 2993 "High percentile of attack connections."; 2994 uses connection; 2995 } 2996 container peak-c { 2997 description 2998 "Peak attack connections."; 2999 uses connection; 3000 } 3001 } 3003 grouping connection-protocol { 3004 description 3005 "Total attack connections."; 3006 leaf protocol { 3007 type uint8; 3008 description 3009 "The transport protocol. 3010 Values are taken from the IANA Protocol Numbers registry: 3011 ."; 3012 } 3013 uses connection; 3014 } 3016 grouping connection-port { 3017 description 3018 "Total attack connections per port number."; 3019 leaf port { 3020 type inet:port-number; 3021 description 3022 "Port number."; 3023 } 3024 uses connection-protocol; 3025 } 3027 grouping connection-protocol-percentile { 3028 description 3029 "Total attack connections."; 3030 list low-percentile-l { 3031 key "protocol"; 3032 description 3033 "Low percentile of attack connections."; 3034 uses connection-protocol; 3035 } 3036 list mid-percentile-l { 3037 key "protocol"; 3038 description 3039 "Mid percentile of attack connections."; 3040 uses connection-protocol; 3041 } 3042 list high-percentile-l { 3043 key "protocol"; 3044 description 3045 "High percentile of attack connections."; 3046 uses connection-protocol; 3047 } 3048 list peak-l { 3049 key "protocol"; 3050 description 3051 "Peak attack connections."; 3052 uses connection-protocol; 3053 } 3054 } 3056 grouping connection-protocol-port-percentile { 3057 description 3058 "Total attack connections."; 3059 list low-percentile-l { 3060 key "protocol port"; 3061 description 3062 "Low percentile of attack connections."; 3063 uses connection-port; 3064 } 3065 list mid-percentile-l { 3066 key "protocol port"; 3067 description 3068 "Mid percentile of attack connections."; 3069 uses connection-port; 3070 } 3071 list high-percentile-l { 3072 key "protocol port"; 3073 description 3074 "High percentile of attack connections."; 3075 uses connection-port; 3076 } 3077 list peak-l { 3078 key "protocol port"; 3079 description 3080 "Peak attack connections."; 3082 uses connection-port; 3083 } 3084 } 3086 grouping attack-detail { 3087 description 3088 "Various information and details that describe the on-going 3089 attacks that needs to be mitigated by the DOTS server. 3090 The attack details need to cover well-known and common attacks 3091 (such as a SYN Flood) along with new emerging or vendor-specific 3092 attacks."; 3093 leaf id { 3094 type uint32; 3095 description 3096 "Vendor ID is a security vendor's Enterprise Number."; 3097 } 3098 leaf attack-id { 3099 type string; 3100 description 3101 "Unique identifier assigned by the vendor for the attack."; 3102 } 3103 leaf attack-name { 3104 type string; 3105 description 3106 "Textual representation of attack description. Natural Language 3107 Processing techniques (e.g., word embedding) can possibly be used 3108 to map the attack description to an attack type."; 3109 } 3110 leaf attack-severity { 3111 type attack-severity; 3112 description 3113 "Severity level of an attack. How this level is determined 3114 is implementation-specific."; 3115 } 3116 leaf start-time { 3117 type uint64; 3118 description 3119 "The time the attack started. Start time is represented in seconds 3120 relative to 1970-01-01T00:00:00Z in UTC time."; 3121 } 3122 leaf end-time { 3123 type uint64; 3124 description 3125 "The time the attack ended. End time is represented in seconds 3126 relative to 1970-01-01T00:00:00Z in UTC time."; 3127 } 3128 container source-count { 3129 description 3130 "Indicates the count of unique sources involved 3131 in the attack."; 3132 uses percentile; 3133 } 3134 } 3136 grouping top-talker-aggregate { 3137 description 3138 "Top attack sources."; 3139 list talker { 3140 key "source-prefix"; 3141 description 3142 "IPv4 or IPv6 prefix identifying the attacker(s)."; 3143 leaf spoofed-status { 3144 type boolean; 3145 description 3146 "Indicates whether this address is spoofed."; 3147 } 3148 leaf source-prefix { 3149 type inet:ip-prefix; 3150 description 3151 "IPv4 or IPv6 prefix identifying the attacker(s)."; 3152 } 3153 list source-port-range { 3154 key "lower-port"; 3155 description 3156 "Port range. When only lower-port is 3157 present, it represents a single port number."; 3158 leaf lower-port { 3159 type inet:port-number; 3160 mandatory true; 3161 description 3162 "Lower port number of the port range."; 3163 } 3164 leaf upper-port { 3165 type inet:port-number; 3166 must '. >= ../lower-port' { 3167 error-message 3168 "The upper port number must be greater than 3169 or equal to lower port number."; 3170 } 3171 description 3172 "Upper port number of the port range."; 3173 } 3174 } 3175 list source-icmp-type-range { 3176 key "lower-type"; 3177 description 3178 "ICMP type range. When only lower-type is 3179 present, it represents a single ICMP type."; 3180 leaf lower-type { 3181 type uint8; 3182 mandatory true; 3183 description 3184 "Lower ICMP type of the ICMP type range."; 3185 } 3186 leaf upper-type { 3187 type uint8; 3188 must '. >= ../lower-type' { 3189 error-message 3190 "The upper ICMP type must be greater than 3191 or equal to lower ICMP type."; 3192 } 3193 description 3194 "Upper type of the ICMP type range."; 3195 } 3196 } 3197 list total-attack-traffic { 3198 key "unit"; 3199 description 3200 "Total attack traffic issued from this source."; 3201 uses traffic-unit; 3202 } 3203 container total-attack-connection { 3204 description 3205 "Total attack connections issued from this source."; 3206 uses connection-percentile; 3207 } 3208 } 3209 } 3211 grouping top-talker { 3212 description 3213 "Top attack sources."; 3214 list talker { 3215 key "source-prefix"; 3216 description 3217 "IPv4 or IPv6 prefix identifying the attacker(s)."; 3218 leaf spoofed-status { 3219 type boolean; 3220 description 3221 "Indicates whether this address is spoofed."; 3222 } 3223 leaf source-prefix { 3224 type inet:ip-prefix; 3225 description 3226 "IPv4 or IPv6 prefix identifying the attacker(s)."; 3227 } 3228 list source-port-range { 3229 key "lower-port"; 3230 description 3231 "Port range. When only lower-port is 3232 present, it represents a single port number."; 3233 leaf lower-port { 3234 type inet:port-number; 3235 mandatory true; 3236 description 3237 "Lower port number of the port range."; 3238 } 3239 leaf upper-port { 3240 type inet:port-number; 3241 must '. >= ../lower-port' { 3242 error-message 3243 "The upper port number must be greater than 3244 or equal to lower port number."; 3245 } 3246 description 3247 "Upper port number of the port range."; 3248 } 3249 } 3250 list source-icmp-type-range { 3251 key "lower-type"; 3252 description 3253 "ICMP type range. When only lower-type is 3254 present, it represents a single ICMP type."; 3255 leaf lower-type { 3256 type uint8; 3257 mandatory true; 3258 description 3259 "Lower ICMP type of the ICMP type range."; 3260 } 3261 leaf upper-type { 3262 type uint8; 3263 must '. >= ../lower-type' { 3264 error-message 3265 "The upper ICMP type must be greater than 3266 or equal to lower ICMP type."; 3267 } 3268 description 3269 "Upper type of the ICMP type range."; 3270 } 3271 } 3272 list total-attack-traffic { 3273 key "unit"; 3274 description 3275 "Total attack traffic issued from this source."; 3276 uses traffic-unit; 3277 } 3278 container total-attack-connection { 3279 description 3280 "Total attack connections issued from this source."; 3281 uses connection-protocol-percentile; 3282 } 3283 } 3284 } 3286 grouping baseline { 3287 description 3288 "Grouping for the telemetry baseline."; 3289 uses ietf-data:target; 3290 leaf-list alias-name { 3291 type string; 3292 description 3293 "An alias name that points to a resource."; 3294 } 3295 list total-traffic-normal { 3296 key "unit"; 3297 description 3298 "Total traffic normal baselines."; 3299 uses traffic-unit; 3300 } 3301 list total-traffic-normal-per-protocol { 3302 key "unit protocol"; 3303 description 3304 "Total traffic normal baselines per protocol."; 3305 uses traffic-unit-protocol; 3306 } 3307 list total-traffic-normal-per-port { 3308 key "unit port"; 3309 description 3310 "Total traffic normal baselines per port number."; 3311 uses traffic-unit-port; 3312 } 3313 list total-connection-capacity { 3314 key "protocol"; 3315 description 3316 "Total connection capacity."; 3317 uses total-connection-capacity-protocol; 3318 } 3319 list total-connection-capacity-per-port { 3320 key "protocol port"; 3321 description 3322 "Total connection capacity per port number."; 3323 leaf port { 3324 type inet:port-number; 3325 description 3326 "The target port number."; 3327 } 3328 uses total-connection-capacity-protocol; 3329 } 3330 } 3332 grouping pre-or-ongoing-mitigation { 3333 description 3334 "Grouping for the telemetry data."; 3335 list total-traffic { 3336 key "unit"; 3337 description 3338 "Total traffic."; 3339 uses traffic-unit; 3340 } 3341 list total-traffic-protocol { 3342 key "unit protocol"; 3343 description 3344 "Total traffic per protocol."; 3345 uses traffic-unit-protocol; 3346 } 3347 list total-traffic-port { 3348 key "unit port"; 3349 description 3350 "Total traffic per port."; 3351 uses traffic-unit-port; 3352 } 3353 list total-attack-traffic { 3354 key "unit"; 3355 description 3356 "Total attack traffic."; 3357 uses traffic-unit-protocol; 3358 } 3359 list total-attack-traffic-protocol { 3360 key "unit protocol"; 3361 description 3362 "Total attack traffic per protocol."; 3363 uses traffic-unit-protocol; 3364 } 3365 list total-attack-traffic-port { 3366 key "unit port"; 3367 description 3368 "Total attack traffic per port."; 3369 uses traffic-unit-port; 3371 } 3372 container total-attack-connection { 3373 description 3374 "Total attack connections."; 3375 uses connection-protocol-percentile; 3376 } 3377 container total-attack-connection-port { 3378 description 3379 "Total attack connections."; 3380 uses connection-protocol-port-percentile; 3381 } 3382 list attack-detail { 3383 key "attack-id"; 3384 description 3385 "Provides a set of attack details."; 3386 uses attack-detail; 3387 container top-talker { 3388 description 3389 "Lists the top attack sources."; 3390 uses top-talker; 3391 } 3392 } 3393 } 3395 augment "/ietf-signal:dots-signal/ietf-signal:message-type/" 3396 + "ietf-signal:mitigation-scope/ietf-signal:scope" { 3397 if-feature "dots-telemetry"; 3398 description 3399 "Extends mitigation scope with telemetry update data."; 3400 list total-traffic { 3401 key "unit"; 3402 config false; 3403 description 3404 "Total traffic."; 3405 uses traffic-unit; 3406 } 3407 list total-attack-traffic { 3408 key "unit"; 3409 description 3410 "Total attack traffic."; 3411 uses traffic-unit; 3412 } 3413 container total-attack-connection { 3414 config false; 3415 description 3416 "Total attack connections."; 3417 uses connection-percentile; 3418 } 3419 list attack-detail { 3420 key "attack-id"; 3421 description 3422 "Atatck details"; 3423 uses attack-detail; 3424 container top-talker { 3425 description 3426 "Top attack sources."; 3427 uses top-talker-aggregate; 3428 } 3429 } 3430 } 3432 augment "/ietf-signal:dots-signal/ietf-signal:message-type" { 3433 if-feature "dots-telemetry"; 3434 description 3435 "Add a new choice to enclose telemetry data in DOTS 3436 signal channel."; 3437 case telemetry-setup { 3438 description 3439 "Indicates the message is about telemetry."; 3440 container max-config-values { 3441 config false; 3442 description 3443 "Maximum acceptable configuration values."; 3444 uses percentile-config; 3445 leaf server-originated-telemetry { 3446 type boolean; 3447 description 3448 "Indicates whether the DOTS server can be instructed 3449 to send pre-or-ongoing-mitigation telemetry. If set to FALSE 3450 or the attribute is not present, this is an indication 3451 that the server does not support this capability."; 3452 } 3453 leaf telemetry-notify-interval { 3454 type uint32 { 3455 range "1 .. 3600"; 3456 } 3457 must '. >= ../../min-config-values/telemetry-notify-interval' { 3458 error-message 3459 "The value must be greater than or equal 3460 to the telemetry-notify-interval in the min-config-values"; 3461 } 3462 units "seconds"; 3463 description 3464 "Minimum number of seconds between successive 3465 telemetry notifications."; 3466 } 3468 } 3469 container min-config-values { 3470 config false; 3471 description 3472 "Minimum acceptable configuration values."; 3473 uses percentile-config; 3474 leaf telemetry-notify-interval { 3475 type uint32 { 3476 range "1 .. 3600"; 3477 } 3478 units "seconds"; 3479 description 3480 "Minimum number of seconds between successive 3481 telemetry notifications."; 3482 } 3483 } 3484 container supported-units { 3485 config false; 3486 description 3487 "Supported units and default activation status."; 3488 uses unit-config; 3489 } 3490 list telemetry { 3491 key "cuid tsid"; 3492 description 3493 "The telemetry data per DOTS client."; 3494 leaf cuid { 3495 type string; 3496 description 3497 "A unique identifier that is 3498 generated by a DOTS client to prevent 3499 request collisions. It is expected that the 3500 cuid will remain consistent throughout the 3501 lifetime of the DOTS client."; 3502 } 3503 leaf cdid { 3504 type string; 3505 description 3506 "The cdid should be included by a server-domain 3507 DOTS gateway to propagate the client domain 3508 identification information from the 3509 gateway's client-facing-side to the gateway's 3510 server-facing-side, and from the gateway's 3511 server-facing-side to the DOTS server. 3513 It may be used by the final DOTS server 3514 for policy enforcement purposes."; 3515 } 3516 leaf tsid { 3517 type uint32; 3518 description 3519 "An identifier for the DOTS telemetry setup 3520 data."; 3521 } 3522 choice setup-type { 3523 description 3524 "Can be a mitigation configuration, a pipe capacity, 3525 or baseline message."; 3526 case telemetry-config { 3527 description 3528 "Uses to set low, mid, and high percentile values."; 3529 container current-config { 3530 description 3531 "Current configuration values."; 3532 uses percentile-config; 3533 uses unit-config; 3534 leaf server-originated-telemetry { 3535 type boolean; 3536 description 3537 "Used by a DOTS client to enable/disable whether it 3538 accepts pre-or-ongoing-mitigation telemetry from 3539 the DOTS server."; 3540 } 3541 leaf telemetry-notify-interval { 3542 type uint32 { 3543 range "1 .. 3600"; 3544 } 3545 units "seconds"; 3546 description 3547 "Minimum number of seconds between successive 3548 telemetry notifications."; 3549 } 3550 } 3551 } 3552 case pipe { 3553 description 3554 "Total pipe capacity of a DOTS client domain"; 3555 list total-pipe-capacity { 3556 key "link-id unit"; 3557 description 3558 "Total pipe capacity of a DOTS client domain."; 3559 leaf link-id { 3560 type nt:link-id; 3561 description 3562 "Identifier of an interconnection link."; 3563 } 3564 leaf capacity { 3565 type uint64; 3566 mandatory true; 3567 description 3568 "Pipe capacity."; 3569 } 3570 leaf unit { 3571 type unit; 3572 description 3573 "The traffic can be measured using unit types: packets 3574 per second (PPS), Bits per Second (BPS), and/or 3575 bytes per second. DOTS agents auto-scale to the 3576 appropriate units (e.g., megabit-ps, kilobit-ps)."; 3577 } 3578 } 3579 } 3580 case baseline { 3581 description 3582 "Traffic baseline information"; 3583 list baseline { 3584 key "id"; 3585 description 3586 "Traffic baseline information"; 3587 leaf id { 3588 type uint32; 3589 must '. >= 1'; 3590 description 3591 "A baseline entry identifier."; 3592 } 3593 uses baseline; 3594 } 3595 } 3596 } 3597 } 3598 } 3599 case telemetry { 3600 description 3601 "Indicates the message is about telemetry."; 3602 list pre-or-ongoing-mitigation { 3603 key "cuid tmid"; 3604 description 3605 "Pre-or-ongoing-mitigation telemetry per DOTS client."; 3606 leaf cuid { 3607 type string; 3608 description 3609 "A unique identifier that is 3610 generated by a DOTS client to prevent 3611 request collisions. It is expected that the 3612 cuid will remain consistent throughout the 3613 lifetime of the DOTS client."; 3614 } 3615 leaf cdid { 3616 type string; 3617 description 3618 "The cdid should be included by a server-domain 3619 DOTS gateway to propagate the client domain 3620 identification information from the 3621 gateway's client-facing-side to the gateway's 3622 server-facing-side, and from the gateway's 3623 server-facing-side to the DOTS server. 3625 It may be used by the final DOTS server 3626 for policy enforcement purposes."; 3627 } 3628 leaf tmid { 3629 type uint32; 3630 description 3631 "An identifier to uniquely demux telemetry data sent 3632 using the same message."; 3633 } 3634 container target { 3635 description 3636 "Indicates the target."; 3637 uses ietf-data:target; 3638 leaf-list alias-name { 3639 type string; 3640 description 3641 "An alias name that points to a resource."; 3642 } 3643 leaf-list mid-list { 3644 type uint32; 3645 description 3646 "Reference a list of associated mitigation requests."; 3647 } 3648 } 3649 uses pre-or-ongoing-mitigation; 3650 } 3651 } 3652 } 3653 } 3654 3655 10. YANG/JSON Mapping Parameters to CBOR 3657 All DOTS telemetry parameters in the payload of the DOTS signal 3658 channel MUST be mapped to CBOR types as shown in the following table: 3660 o Implementers may use the values in: https://github.com/boucadair/ 3661 draft-dots-telemetry/blob/master/mapping-table.txt 3663 +----------------------+-------------+------+---------------+--------+ 3664 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 3665 | | Type | Key | Type & | Type | 3666 | | | | Information | | 3667 +----------------------+-------------+------+---------------+--------+ 3668 | tsid | uint32 |TBA1 | 0 unsigned | Number | 3669 | telemetry | container |TBA2 | 5 map | Object | 3670 | low-percentile | decimal64 |TBA3 | 6 tag 4 | | 3671 | | | | [-2, integer]| String | 3672 | mid-percentile | decimal64 |TBA4 | 6 tag 4 | | 3673 | | | | [-2, integer]| String | 3674 | high-percentile | decimal64 |TBA5 | 6 tag 4 | | 3675 | | | | [-2, integer]| String | 3676 | unit-config | list |TBA6 | 4 array | Array | 3677 | unit | enumeration |TBA7 | 0 unsigned | String | 3678 | unit-status | boolean |TBA8 | 7 bits 20 | False | 3679 | | | | 7 bits 21 | True | 3680 | total-pipe-capability| list |TBA9 | 4 array | Array | 3681 | link-id | string |TBA10 | 3 text string | String | 3682 | pre-or-ongoing- | list |TBA11 | 4 array | Array | 3683 | mitigation | | | | | 3684 | total-traffic-normal | list |TBA12 | 4 array | Array | 3685 | low-percentile-g | yang:gauge64|TBA13 | 0 unsigned | String | 3686 | mid-percentile-g | yang:gauge64|TBA14 | 0 unsigned | String | 3687 | high-percentile-g | yang:gauge64|TBA15 | 0 unsigned | String | 3688 | peak-g | yang:gauge64|TBA16 | 0 unsigned | String | 3689 | total-attack-traffic | list |TBA17 | 4 array | Array | 3690 | total-traffic | list |TBA18 | 4 array | Array | 3691 | total-connection- | | | | | 3692 | capacity | list |TBA19 | 4 array | Array | 3693 | connection | uint64 |TBA20 | 0 unsigned | String | 3694 | connection-client | uint64 |TBA21 | 0 unsigned | String | 3695 | embryonic | uint64 |TBA22 | 0 unsigned | String | 3696 | embryonic-client | uint64 |TBA23 | 0 unsigned | String | 3697 | connection-ps | uint64 |TBA24 | 0 unsigned | String | 3698 | connection-client-ps | uint64 |TBA25 | 0 unsigned | String | 3699 | request-ps | uint64 |TBA26 | 0 unsigned | String | 3700 | request-client-ps | uint64 |TBA27 | 0 unsigned | String | 3701 | partial-request-ps | uint64 |TBA28 | 0 unsigned | String | 3702 | partial-request- | | | | | 3703 | client-ps | uint64 |TBA29 | 0 unsigned | String | 3704 | total-attack- | | | | | 3705 | connection | container |TBA30 | 5 map | Object | 3706 | low-percentile-l | list |TBA31 | 4 array | Array | 3707 | mid-percentile-l | list |TBA32 | 4 array | Array | 3708 | high-percentile-l | list |TBA33 | 4 array | Array | 3709 | peak-l | list |TBA34 | 4 array | Array | 3710 | attack-detail | list |TBA35 | 4 array | Array | 3711 | id | uint32 |TBA36 | 0 unsigned | Number | 3712 | attack-id | string |TBA37 | 3 text string | String | 3713 | attack-name | string |TBA38 | 3 text string | String | 3714 | attack-severity | enumeration |TBA39 | 0 unsigned | String | 3715 | start-time | uint64 |TBA40 | 0 unsigned | String | 3716 | end-time | uint64 |TBA41 | 0 unsigned | String | 3717 | source-count | container |TBA42 | 5 map | Object | 3718 | top-talker | container |TBA43 | 5 map | Object | 3719 | spoofed-status | boolean |TBA44 | 7 bits 20 | False | 3720 | | | | 7 bits 21 | True | 3721 | low-percentile-c | container |TBA45 | 5 map | Object | 3722 | mid-percentile-c | container |TBA46 | 5 map | Object | 3723 | high-percentile-c | container |TBA47 | 5 map | Object | 3724 | peak-c | container |TBA48 | 5 map | Object | 3725 | baseline | container |TBA49 | 5 map | Object | 3726 | current-config | container |TBA50 | 5 map | Object | 3727 | max-config-values | container |TBA51 | 5 map | Object | 3728 | min-config-values | container |TBA52 | 5 map | Object | 3729 | supported-units | container |TBA53 | 5 map | Object | 3730 | server-originated- | boolean |TBA54 | 7 bits 20 | False | 3731 | telemetry | | | 7 bits 21 | True | 3732 | telemetry-notify- | uint32 |TBA55 | 0 unsigned | Number | 3733 | interval | | | | | 3734 | tmid | uint32 |TBA56 | 0 unsigned | Number | 3735 | measurement-interval | enumeration |TBA57 | 0 unsigned | String | 3736 | measurement-sample | enumeration |TBA58 | 0 unsigned | String | 3737 | talker | list |TBA59 | 4 array | Array | 3738 | source-prefix | inet: |TBA60 | 3 text string | String | 3739 | | ip-prefix | | | | 3740 | mid-list | leaf-list |TBA61 | 4 array | Array | 3741 | | uint32 | | 0 unsigned | Number | 3742 | source-port-range | list |TBA62 | 4 array | Array | 3743 | source-icmp-type- | list |TBA63 | 4 array | Array | 3744 | range | | | | | 3745 | lower-type | uint8 |TBA64 | 0 unsigned | Number | 3746 | upper-type | uint8 |TBA65 | 0 unsigned | Number | 3747 | target | container |TBA66 | 5 map | Object | 3748 | capacity | uint64 |TBA67 | 0 unsigned | String | 3749 | protocol | uint8 |TBA68 | 0 unsigned | Number | 3750 | total-traffic- | | | | | 3751 | normal-per-protocol | list |TBA69 | 4 array | Array | 3752 | total-traffic- | | | | | 3753 | normal-per-port | list |TBA70 | 4 array | Array | 3754 | total-connection- | | | | | 3755 | capacity-per-port | list |TBA71 | 4 array | Array | 3756 | total-traffic- | | | | | 3757 | -protocol | list |TBA72 | 4 array | Array | 3758 | total-traffic- port | list |TBA73 | 4 array | Array | 3759 | total-attack- | | | | | 3760 | traffic-protocol | list |TBA74 | 4 array | Array | 3761 | total-attack- | | | | | 3762 | traffic-port | list |TBA75 | 4 array | Array | 3763 | total-attack- | | | | | 3764 | connection-port | list |TBA76 | 4 array | Array | 3765 | port | inet: | | | | 3766 | | port-number|TBA77 | 0 unsigned | Number | 3767 | ietf-dots-telemetry: | | | | | 3768 | telemetry-setup | container |TBA80 | 5 map | Object | 3769 | ietf-dots-telemetry: | | | | | 3770 | total-traffic | list |TBA81 | 4 array | Array | 3771 | ietf-dots-telemetry: | | | | | 3772 | unit | enumeration |TBA82 | 0 unsigned | String | 3773 | ietf-dots-telemetry: | | | | | 3774 | low-percentile-g | yang:gauge64|TBA83 | 0 unsigned | String | 3775 | ietf-dots-telemetry: | | | | | 3776 | mid-percentile-g | yang:gauge64|TBA84 | 0 unsigned | String | 3777 | ietf-dots-telemetry: | | | | | 3778 | high-percentile-g | yang:gauge64|TBA85 | 0 unsigned | String | 3779 | ietf-dots-telemetry: | | | | | 3780 | peak-g | yang:gauge64|TBA86 | 0 unsigned | String | 3781 | ietf-dots-telemetry: | | | | | 3782 | total-attack-traffic | list |TBA87 | 4 array | Array | 3783 | ietf-dots-telemetry: | | | | | 3784 | total-attack- | | | | | 3785 | connection | container |TBA88 | 5 map | Object | 3786 | ietf-dots-telemetry: | | | | | 3787 | low-percentile-c | container |TBA89 | 5 map | Object | 3788 | ietf-dots-telemetry: | | | | | 3789 | mid-percentile-c | container |TBA90 | 5 map | Object | 3790 | ietf-dots-telemetry: | | | | | 3791 | high-percentile-c | container |TBA91 | 5 map | Object | 3792 | ietf-dots-telemetry: | | | | | 3793 | peak-c | container |TBA92 | 5 map | Object | 3794 | ietf-dots-telemetry: | | | | | 3795 | connection | uint64 |TBA93 | 0 unsigned | String | 3796 | ietf-dots-telemetry: | | | | | 3797 | embryonic | uint64 |TBA94 | 0 unsigned | String | 3798 | ietf-dots-telemetry: | | | | | 3799 | connection-ps | uint64 |TBA95 | 0 unsigned | String | 3800 | ietf-dots-telemetry: | | | | | 3801 | request-ps | uint64 |TBA96 | 0 unsigned | String | 3802 | ietf-dots-telemetry: | | | | | 3803 | partial-request-ps | uint64 |TBA97 | 0 unsigned | String | 3804 | ietf-dots-telemetry: | | | | | 3805 | attack-detail | list |TBA98 | 4 array | Array | 3806 | ietf-dots-telemetry: | | | | | 3807 | id | uint32 |TBA99 | 0 unsigned | Number | 3808 | ietf-dots-telemetry: | | | | | 3809 | attack-id | string |TBA100| 3 text string | String | 3810 | ietf-dots-telemetry: | | | | | 3811 | attack-name | string |TBA101| 3 text string | String | 3812 | ietf-dots-telemetry: | | | | | 3813 | attack-severity | enumeration |TBA102| 0 unsigned | String | 3814 | ietf-dots-telemetry: | | | | | 3815 | start-time | uint64 |TBA103| 0 unsigned | String | 3816 | ietf-dots-telemetry: | | | | | 3817 | end-time | uint64 |TBA104| 0 unsigned | String | 3818 | ietf-dots-telemetry: | | | | | 3819 | source-count | container |TBA105| 5 map | Object | 3820 | ietf-dots-telemetry: | | | | | 3821 | top-talker | container |TBA106| 5 map | Object | 3822 | ietf-dots-telemetry: | | | | | 3823 | spoofed-status | boolean |TBA107| 7 bits 20 | False | 3824 | | | | 7 bits 21 | True | 3825 | ietf-dots-telemetry: | | | | | 3826 | talker | list |TBA108| 4 array | Array | 3827 | ietf-dots-telemetry: | inet: |TBA109| 3 text string | String | 3828 | source-prefix | ip-prefix | | | | 3829 | ietf-dots-telemetry: | | | | | 3830 | source-port-range | list |TBA110| 4 array | Array | 3831 | ietf-dots-telemetry: | | | | | 3832 | lower-port | inet: | | | | 3833 | | port-number|TBA111| 0 unsigned | Number | 3834 | ietf-dots-telemetry: | | | | | 3835 | upper-port | inet: | | | | 3836 | | port-number|TBA112| 0 unsigned | Number | 3837 | ietf-dots-telemetry: | | | | | 3838 | source-icmp-type- | list |TBA113| 4 array | Array | 3839 | range | | | | | 3840 | ietf-dots-telemetry: | | | | | 3841 | lower-type | uint8 |TBA114| 0 unsigned | Number | 3842 | ietf-dots-telemetry: | | | | | 3843 | upper-type | uint8 |TBA115| 0 unsigned | Number | 3844 | ietf-dots-telemetry: | | | | | 3845 | telemetry | container |TBA116| 5 map | Object | 3846 +----------------------+-------------+------+---------------+--------+ 3848 11. IANA Considerationsr 3850 11.1. DOTS Signal Channel CBOR Key Values 3852 This specification registers the DOTS telemetry attributes in the 3853 IANA "DOTS Signal Channel CBOR Key Values" registry available at 3854 https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel- 3855 cbor-key-values. 3857 The DOTS telemetry attributes defined in this specification are 3858 comprehension-optional parameters. 3860 o Note to the RFC Editor: (1) CBOR keys are assigned from the 3861 32768-49151 range. (2) Please assign the following suggested 3862 values. 3864 +----------------------+-------+-------+------------+---------------+ 3865 | Parameter Name | CBOR | CBOR | Change | Specification | 3866 | | Key | Major | Controller | Document(s) | 3867 | | Value | Type | | | 3868 +----------------------+-------+-------+------------+---------------+ 3869 | tsid | TBA1 | 0 | IESG | [RFCXXXX] | 3870 | telemetry | TBA2 | 5 | IESG | [RFCXXXX] | 3871 | low-percentile | TBA3 | 6tag4 | IESG | [RFCXXXX] | 3872 | mid-percentile | TBA4 | 6tag4 | IESG | [RFCXXXX] | 3873 | high-percentile | TBA5 | 6tag4 | IESG | [RFCXXXX] | 3874 | unit-config | TBA6 | 4 | IESG | [RFCXXXX] | 3875 | unit | TBA7 | 0 | IESG | [RFCXXXX] | 3876 | unit-status | TBA8 | 7 | IESG | [RFCXXXX] | 3877 | total-pipe-capability| TBA9 | 4 | IESG | [RFCXXXX] | 3878 | link-id | TBA10 | 3 | IESG | [RFCXXXX] | 3879 | pre-or-ongoing- | TBA11 | 4 | IESG | [RFCXXXX] | 3880 | mitigation | | | | | 3881 | total-traffic-normal | TBA12 | 4 | IESG | [RFCXXXX] | 3882 | low-percentile-g | TBA13 | 0 | IESG | [RFCXXXX] | 3883 | mid-percentile-g | TBA14 | 0 | IESG | [RFCXXXX] | 3884 | high-percentile-g | TBA15 | 0 | IESG | [RFCXXXX] | 3885 | peak-g | TBA16 | 0 | IESG | [RFCXXXX] | 3886 | total-attack-traffic | TBA17 | 4 | IESG | [RFCXXXX] | 3887 | total-traffic | TBA18 | 4 | IESG | [RFCXXXX] | 3888 | total-connection- | TBA19 | 4 | IESG | [RFCXXXX] | 3889 | capacity | | | | | 3890 | connection | TBA20 | 0 | IESG | [RFCXXXX] | 3891 | connection-client | TBA21 | 0 | IESG | [RFCXXXX] | 3892 | embryonic | TBA22 | 0 | IESG | [RFCXXXX] | 3893 | embryonic-client | TBA23 | 0 | IESG | [RFCXXXX] | 3894 | connection-ps | TBA24 | 0 | IESG | [RFCXXXX] | 3895 | connection-client-ps | TBA25 | 0 | IESG | [RFCXXXX] | 3896 | request-ps | TBA26 | 0 | IESG | [RFCXXXX] | 3897 | request-client-ps | TBA27 | 0 | IESG | [RFCXXXX] | 3898 | partial-request-ps | TBA28 | 0 | IESG | [RFCXXXX] | 3899 | partial-request- | TBA29 | 0 | IESG | [RFCXXXX] | 3900 | client-ps | | | | | 3901 | total-attack- | TBA30 | 5 | IESG | [RFCXXXX] | 3902 | connection | | | | | 3903 | low-percentile-l | TBA31 | 4 | IESG | [RFCXXXX] | 3904 | mid-percentile-l | TBA32 | 4 | IESG | [RFCXXXX] | 3905 | high-percentile-l | TBA33 | 4 | IESG | [RFCXXXX] | 3906 | peak-l | TBA34 | 4 | IESG | [RFCXXXX] | 3907 | attack-detail | TBA35 | 4 | IESG | [RFCXXXX] | 3908 | id | TBA36 | 0 | IESG | [RFCXXXX] | 3909 | attack-id | TBA37 | 3 | IESG | [RFCXXXX] | 3910 | attack-name | TBA38 | 3 | IESG | [RFCXXXX] | 3911 | attack-severity | TBA39 | 0 | IESG | [RFCXXXX] | 3912 | start-time | TBA40 | 0 | IESG | [RFCXXXX] | 3913 | end-time | TBA41 | 0 | IESG | [RFCXXXX] | 3914 | source-count | TBA42 | 5 | IESG | [RFCXXXX] | 3915 | top-talker | TBA43 | 5 | IESG | [RFCXXXX] | 3916 | spoofed-status | TBA44 | 7 | IESG | [RFCXXXX] | 3917 | low-percentile-c | TBA45 | 5 | IESG | [RFCXXXX] | 3918 | mid-percentile-c | TBA46 | 5 | IESG | [RFCXXXX] | 3919 | high-percentile-c | TBA47 | 5 | IESG | [RFCXXXX] | 3920 | peak-c | TBA48 | 5 | IESG | [RFCXXXX] | 3921 | ietf-dots-signal-cha | TBA49 | 5 | IESG | [RFCXXXX] | 3922 | current-config | TBA50 | 5 | IESG | [RFCXXXX] | 3923 | max-config-value | TBA51 | 5 | IESG | [RFCXXXX] | 3924 | min-config-values | TBA52 | 5 | IESG | [RFCXXXX] | 3925 | supported-units | TBA55 | 5 | IESG | [RFCXXXX] | 3926 | server-originated- | TBA54 | 7 | IESG | [RFCXXXX] | 3927 | telemetry | | | | | 3928 | telemetry-notify- | TBA55 | 0 | IESG | [RFCXXXX] | 3929 | interval | | | | | 3930 | tmid | TBA56 | 0 | IESG | [RFCXXXX] | 3931 | measurement-interval | TBA57 | 0 | IESG | [RFCXXXX] | 3932 | measurement-sample | TBA58 | 0 | IESG | [RFCXXXX] | 3933 | talker | TBA59 | 0 | IESG | [RFCXXXX] | 3934 | source-prefix | TBA60 | 0 | IESG | [RFCXXXX] | 3935 | mid-list | TBA61 | 4 | IESG | [RFCXXXX] | 3936 | source-port-range | TBA62 | 4 | IESG | [RFCXXXX] | 3937 | source-icmp-type- | TBA63 | 4 | IESG | [RFCXXXX] | 3938 | range | | | | | 3939 | lower-type | TBA64 | 0 | IESG | [RFCXXXX] | 3940 | upper-type | TBA65 | 0 | IESG | [RFCXXXX] | 3941 | target | TBA66 | 5 | IESG | [RFCXXXX] | 3942 | capacity | TBA67 | 0 | IESG | [RFCXXXX] | 3943 | protocol | TBA68 | 0 | IESG | [RFCXXXX] | 3944 | total-traffic- | TBA69 | 4 | IESG | [RFCXXXX] | 3945 | normal-per-protocol | | | | | 3946 | total-traffic- | TBA70 | 4 | IESG | [RFCXXXX] | 3947 | normal-per-port | | | | | 3948 | total-connection- | TBA71 | 4 | IESG | [RFCXXXX] | 3949 | capacity-per-port | | | | | 3950 | total-traffic- | TBA72 | 4 | IESG | [RFCXXXX] | 3951 | -protocol | | | | | 3952 | total-traffic-port | TBA73 | 4 | IESG | [RFCXXXX] | 3953 | total-attack- | TBA74 | 4 | IESG | [RFCXXXX] | 3954 | traffic-protocol | | | | | 3955 | total-attack- | TBA75 | 4 | IESG | [RFCXXXX] | 3956 | traffic-port | | | | | 3957 | total-attack- | TBA76 | 4 | IESG | [RFCXXXX] | 3958 | connection-port | | | | | 3959 | port | TBA77 | 0 | IESG | [RFCXXXX] | 3960 | ietf-dots-telemetry: | TBA80 | 5 | IESG | [RFCXXXX] | 3961 | telemetry-setup | | | | | 3962 | ietf-dots-telemetry: | TBA81 | 0 | IESG | [RFCXXXX] | 3963 | total-traffic | | | | | 3964 | ietf-dots-telemetry: | TBA82 | 0 | IESG | [RFCXXXX] | 3965 | unit | | | | | 3966 | ietf-dots-telemetry: | TBA83 | 0 | IESG | [RFCXXXX] | 3967 | low-percentile-g | | | | | 3968 | ietf-dots-telemetry: | TBA84 | 0 | IESG | [RFCXXXX] | 3969 | mid-percentile-g | | | | | 3970 | ietf-dots-telemetry: | TBA85 | 0 | IESG | [RFCXXXX] | 3971 | high-percentile-g | | | | | 3972 | ietf-dots-telemetry: | TBA86 | 0 | IESG | [RFCXXXX] | 3973 | peak-g | | | | | 3974 | ietf-dots-telemetry: | TBA87 | 0 | IESG | [RFCXXXX] | 3975 | total-attack-traffic | | | | | 3976 | ietf-dots-telemetry: | TBA88 | 0 | IESG | [RFCXXXX] | 3977 | total-attack- | | | | | 3978 | connection | | | | | 3979 | ietf-dots-telemetry: | TBA89 | 0 | IESG | [RFCXXXX] | 3980 | low-percentile-c | | | | | 3981 | ietf-dots-telemetry: | TBA90 | 0 | IESG | [RFCXXXX] | 3982 | mid-percentile-c | | | | | 3983 | ietf-dots-telemetry: | TBA91 | 0 | IESG | [RFCXXXX] | 3984 | high-percentile-c | | | | | 3985 | ietf-dots-telemetry: | TBA92 | 0 | IESG | [RFCXXXX] | 3986 | peak-c | | | | | 3987 | ietf-dots-telemetry: | TBA93 | 0 | IESG | [RFCXXXX] | 3988 | connection | | | | | 3989 | ietf-dots-telemetry: | TBA94 | 0 | IESG | [RFCXXXX] | 3990 | embryonic | | | | | 3991 | ietf-dots-telemetry: | TBA95 | 0 | IESG | [RFCXXXX] | 3992 | connection-ps | | | | | 3993 | ietf-dots-telemetry: | TBA96 | 0 | IESG | [RFCXXXX] | 3994 | request-ps | | | | | 3995 | ietf-dots-telemetry: | TBA97 | 0 | IESG | [RFCXXXX] | 3996 | partial-request-ps | | | | | 3997 | ietf-dots-telemetry: | TBA98 | 4 | IESG | [RFCXXXX] | 3998 | attack-detail | | | | | 3999 | ietf-dots-telemetry: | TBA99 | 0 | IESG | [RFCXXXX] | 4000 | id | | | | | 4001 | ietf-dots-telemetry: | TBA100| 0 | IESG | [RFCXXXX] | 4002 | attack-id | | | | | 4003 | ietf-dots-telemetry: | TBA101| 0 | IESG | [RFCXXXX] | 4004 | attack-name | | | | | 4005 | ietf-dots-telemetry: | TBA102| 0 | IESG | [RFCXXXX] | 4006 | attack-severity | | | | | 4007 | ietf-dots-telemetry: | TBA103| 0 | IESG | [RFCXXXX] | 4008 | start-time | | | | | 4009 | ietf-dots-telemetry: | TBA104| 0 | IESG | [RFCXXXX] | 4010 | end-time | | | | | 4011 | ietf-dots-telemetry: | TBA105| 0 | IESG | [RFCXXXX] | 4012 | source-count | | | | | 4013 | ietf-dots-telemetry: | TBA106| 0 | IESG | [RFCXXXX] | 4014 | top-talker | | | | | 4015 | ietf-dots-telemetry: | TBA107| 0 | IESG | [RFCXXXX] | 4016 | spoofed-status | | | | | 4017 | ietf-dots-telemetry: | TBA108| 0 | IESG | [RFCXXXX] | 4018 | talker | | | | | 4019 | ietf-dots-telemetry: | TBA109| 0 | IESG | [RFCXXXX] | 4020 | source-prefix | | | | | 4021 | ietf-dots-telemetry: | | | | | 4022 | source-port-range | TBA110| 4 | IESG | [RFCXXXX] | 4023 | ietf-dots-telemetry: | | | | | 4024 | lower-port | TBA111| 0 | IESG | [RFCXXXX] | 4025 | ietf-dots-telemetry: | | | | | 4026 | upper-port | TBA112| 0 | IESG | [RFCXXXX] | 4027 | ietf-dots-telemetry: | | | | | 4028 | source-icmp-type- | TBA113| 4 | IESG | [RFCXXXX] | 4029 | range | | | | | 4030 | ietf-dots-telemetry: | | | | | 4031 | lower-type | TBA114| 0 | IESG | [RFCXXXX] | 4032 | ietf-dots-telemetry: | | | | | 4033 | upper-type | TBA115| 0 | IESG | [RFCXXXX] | 4034 | ietf-dots-telemetry: | TBA116| 5 | IESG | [RFCXXXX] | 4035 | telemetry | | | | | 4036 +----------------------+-------+-------+------------+---------------+ 4038 11.2. DOTS Signal Channel Conflict Cause Codes 4040 This specification requests IANA to assign a new code from the "DOTS 4041 Signal Channel Conflict Cause Codes" registry available at 4042 https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel- 4043 conflict-cause-codes. 4045 Code Label Description Reference 4046 TBA overlapping-pipes Overlapping pipe scope [RFCXXXX] 4048 11.3. DOTS Signal Telemetry YANG Module 4050 This document requests IANA to register the following URI in the "ns" 4051 subregistry within the "IETF XML Registry" [RFC3688]: 4053 URI: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry 4054 Registrant Contact: The IESG. 4055 XML: N/A; the requested URI is an XML namespace. 4057 This document requests IANA to register the following YANG module in 4058 the "YANG Module Names" subregistry [RFC7950] within the "YANG 4059 Parameters" registry. 4061 name: ietf-dots-telemetry 4062 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry 4063 maintained by IANA: N 4064 prefix: dots-telemetry 4065 reference: RFC XXXX 4067 12. Security Considerations 4069 Security considerations in [I-D.ietf-dots-signal-channel] need to be 4070 taken into consideration. 4072 13. Contributors 4074 The following individuals have contributed to this document: 4076 o Li Su, CMCC, Email: suli@chinamobile.com 4078 o Jin Peng, CMCC, Email: pengjin@chinamobile.com 4080 o Pan Wei, Huawei, Email: william.panwei@huawei.com 4082 14. Acknowledgements 4084 The authors would like to thank Flemming Andreasen, Liang Xia, and 4085 Kaname Nishizuka co-authors of https://tools.ietf.org/html/draft- 4086 doron-dots-telemetry-00 draft and everyone who had contributed to 4087 that document. 4089 The authors would like to thank Kaname Nishizuka, Jon Shallow, Wei 4090 Pan and Yuuhei Hayashi for comments and review. 4092 15. References 4094 15.1. Normative References 4096 [Enterprise-Numbers] 4097 "Private Enterprise Numbers", 2005, . 4100 [I-D.ietf-dots-data-channel] 4101 Boucadair, M. and T. Reddy.K, "Distributed Denial-of- 4102 Service Open Threat Signaling (DOTS) Data Channel 4103 Specification", draft-ietf-dots-data-channel-31 (work in 4104 progress), July 2019. 4106 [I-D.ietf-dots-signal-call-home] 4107 Reddy.K, T., Boucadair, M., and J. Shallow, "Distributed 4108 Denial-of-Service Open Threat Signaling (DOTS) Signal 4109 Channel Call Home", draft-ietf-dots-signal-call-home-08 4110 (work in progress), March 2020. 4112 [I-D.ietf-dots-signal-channel] 4113 Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and 4114 N. Teague, "Distributed Denial-of-Service Open Threat 4115 Signaling (DOTS) Signal Channel Specification", draft- 4116 ietf-dots-signal-channel-41 (work in progress), January 4117 2020. 4119 [I-D.ietf-dots-signal-filter-control] 4120 Nishizuka, K., Boucadair, M., Reddy.K, T., and T. Nagata, 4121 "Controlling Filtering Rules Using Distributed Denial-of- 4122 Service Open Threat Signaling (DOTS) Signal Channel", 4123 draft-ietf-dots-signal-filter-control-03 (work in 4124 progress), March 2020. 4126 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4127 Requirement Levels", BCP 14, RFC 2119, 4128 DOI 10.17487/RFC2119, March 1997, 4129 . 4131 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 4132 DOI 10.17487/RFC3688, January 2004, 4133 . 4135 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 4136 RFC 6991, DOI 10.17487/RFC6991, July 2013, 4137 . 4139 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 4140 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 4141 October 2013, . 4143 [RFC7641] Hartke, K., "Observing Resources in the Constrained 4144 Application Protocol (CoAP)", RFC 7641, 4145 DOI 10.17487/RFC7641, September 2015, 4146 . 4148 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 4149 RFC 7950, DOI 10.17487/RFC7950, August 2016, 4150 . 4152 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 4153 the Constrained Application Protocol (CoAP)", RFC 7959, 4154 DOI 10.17487/RFC7959, August 2016, 4155 . 4157 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4158 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4159 May 2017, . 4161 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 4162 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 4163 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 4164 2018, . 4166 15.2. Informative References 4168 [I-D.bosh-core-new-block] 4169 Boucadair, M. and J. Shallow, "New Constrained Application 4170 Protocol (CoAP) Block-Wise Transfer Options", draft-bosh- 4171 core-new-block-00 (work in progress), April 2020. 4173 [I-D.ietf-dots-multihoming] 4174 Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing 4175 Deployment Considerations for Distributed-Denial-of- 4176 Service Open Threat Signaling (DOTS)", draft-ietf-dots- 4177 multihoming-03 (work in progress), January 2020. 4179 [I-D.ietf-dots-use-cases] 4180 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 4181 L., and K. Nishizuka, "Use cases for DDoS Open Threat 4182 Signaling", draft-ietf-dots-use-cases-20 (work in 4183 progress), September 2019. 4185 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 4186 "Framework for IP Performance Metrics", RFC 2330, 4187 DOI 10.17487/RFC2330, May 1998, 4188 . 4190 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 4191 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 4192 . 4194 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 4195 Threat Signaling (DOTS) Requirements", RFC 8612, 4196 DOI 10.17487/RFC8612, May 2019, 4197 . 4199 Authors' Addresses 4201 Mohamed Boucadair (editor) 4202 Orange 4203 Rennes 35000 4204 France 4206 Email: mohamed.boucadair@orange.com 4208 Tirumaleswar Reddy (editor) 4209 McAfee, Inc. 4210 Embassy Golf Link Business Park 4211 Bangalore, Karnataka 560071 4212 India 4214 Email: kondtir@gmail.com 4216 Ehud Doron 4217 Radware Ltd. 4218 Raoul Wallenberg Street 4219 Tel-Aviv 69710 4220 Israel 4222 Email: ehudd@radware.com 4223 Meiling Chen 4224 CMCC 4225 32, Xuanwumen West 4226 BeiJing, BeiJing 100053 4227 China 4229 Email: chenmeiling@chinamobile.com