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