idnits 2.17.1 draft-ietf-dots-telemetry-00.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 72 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 905 has weird spacing: '...rw unit uni...' == Line 912 has weird spacing: '...er-port ine...' -- The document date (December 17, 2019) is 1591 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'Enterprise-Numbers' == Outdated reference: A later version (-14) exists of draft-ietf-dots-signal-call-home-07 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-39 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-07) exists of draft-ietf-dots-signal-filter-control-02 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-20 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS T. Reddy 3 Internet-Draft McAfee 4 Intended status: Standards Track M. Boucadair 5 Expires: June 19, 2020 Orange 6 E. Doron 7 Radware Ltd. 8 M. Chen 9 CMCC 10 December 17, 2019 12 Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry 13 draft-ietf-dots-telemetry-00 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 June 19, 2020. 45 Copyright Notice 47 Copyright (c) 2019 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 & Purpose . . . . . . . . . . . . . 5 65 4. Generic Considerations . . . . . . . . . . . . . . . . . . . 8 66 4.1. DOTS Client Identification . . . . . . . . . . . . . . . 8 67 4.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . . . 8 68 5. DOTS Telemetry Attributes . . . . . . . . . . . . . . . . . . 9 69 5.1. Pre-mitigation DOTS Telemetry Attributes . . . . . . . . 9 70 5.1.1. Total Traffic Normal Baseline . . . . . . . . . . . . 9 71 5.1.2. Total Pipe Capability . . . . . . . . . . . . . . . . 9 72 5.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 10 73 5.1.4. Total Traffic . . . . . . . . . . . . . . . . . . . . 10 74 5.1.5. Total Connections Capacity . . . . . . . . . . . . . 10 75 5.1.6. Total Attack Connections . . . . . . . . . . . . . . 11 76 5.1.7. Attack Details . . . . . . . . . . . . . . . . . . . 11 77 5.2. DOTS Client to Server Mitigation Efficacy DOTS Telemetry 78 Attributes . . . . . . . . . . . . . . . . . . . . . . . 13 79 5.2.1. Total Attack Traffic . . . . . . . . . . . . . . . . 14 80 5.2.2. Attack Details . . . . . . . . . . . . . . . . . . . 14 81 5.3. DOTS Server to Client Mitigation Status DOTS Telemetry 82 Attributes . . . . . . . . . . . . . . . . . . . . . . . 14 83 5.3.1. Mitigation Status . . . . . . . . . . . . . . . . . . 14 84 6. DOTS Telemetry Configuration . . . . . . . . . . . . . . . . 14 85 6.1. Convey DOTS Telemetry Configuration . . . . . . . . . . . 14 86 6.2. Delete DOTS Telemetry Configuration . . . . . . . . . . . 17 87 7. DOTS Telemetry YANG Module . . . . . . . . . . . . . . . . . 17 88 7.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 17 89 7.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 23 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 91 8.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 38 92 8.2. DOTS Signal Telemetry YANG Module . . . . . . . . . . . . 39 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 95 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 40 96 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 98 12.1. Normative References . . . . . . . . . . . . . . . . . . 40 99 12.2. Informative References . . . . . . . . . . . . . . . . . 42 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 102 1. Introduction 104 The Internet security 'battle' between the adversary and security 105 countermeasures is an everlasting one. DDoS attacks have become more 106 vicious and sophisticated in almost all aspects of their maneuvers 107 and malevolent intentions. IT organizations and service providers 108 are facing DDoS attacks that fall into two broad categories: Network/ 109 Transport layer attacks and Application layer attacks. Network/ 110 Transport layer attacks target the victim's infrastructure. These 111 attacks are not necessarily aimed at taking down the actual delivered 112 services, but rather to eliminate various network elements (routers, 113 switches, firewalls, transit links, and so on) from serving 114 legitimate user traffic. The main method of such attacks is to send 115 a large volume or high PPS of traffic toward the victim's 116 infrastructure. Typically, attack volumes may vary from a few 100 117 Mbps/PPS to 100s of Gbps or even Tbps. Attacks are commonly carried 118 out leveraging botnets and attack reflectors for amplification 119 attacks, such as NTP, DNS, SNMP, SSDP, and so on. Application layer 120 attacks target various applications. Typical examples include 121 attacks against HTTP/HTTPS, DNS, SIP, SMTP, and so on. However, all 122 valid applications with their port numbers open at network edges can 123 be attractive attack targets. Application layer attacks are 124 considered more complex and hard to categorize, therefore harder to 125 detect and mitigate efficiently. 127 To compound the problem, attackers also leverage multi-vectored 128 attacks. These merciless attacks are assembled from dynamic attack 129 vectors (Network/Application) and tactics. As such, multiple attack 130 vectors formed by multiple attack types and volumes are launched 131 simultaneously towards a victim. Multi-vector attacks are harder to 132 detect and defend. Multiple and simultaneous mitigation techniques 133 are needed to defeat such attack campaigns. It is also common for 134 attackers to change attack vectors right after a successful 135 mitigation, burdening their opponents with changing their defense 136 methods. 138 The ultimate conclusion derived from these real scenarios is that 139 modern attacks detection and mitigation are most certainly 140 complicated and highly convoluted tasks. They demand a comprehensive 141 knowledge of the attack attributes, the targeted normal behavior/ 142 traffic patterns, as well as the attacker's on-going and past 143 actions. Even more challenging, retrieving all the analytics needed 144 for detecting these attacks is not simple to obtain with the 145 industry's current capabilities. 147 The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is 148 used to carry information about a network resource or a network (or a 149 part thereof) that is under a Distributed Denial of Service (DDoS) 150 attack. Such information is sent by a DOTS client to one or multiple 151 DOTS servers so that appropriate mitigation actions are undertaken on 152 traffic deemed suspicious. Various use cases are discussed in 153 [I-D.ietf-dots-use-cases]. 155 Typically, DOTS clients can be integrated within a DDoS attack 156 detector, or network and security elements that have been actively 157 engaged with ongoing attacks. The DOTS client mitigation environment 158 determines that it is no longer possible or practical for it to 159 handle these attacks. This can be due to lack of resources or 160 security capabilities, as derived from the complexities and the 161 intensity of these attacks. In this circumstance, the DOTS client 162 has invaluable knowledge about the actual attacks that need to be 163 handled by the DOTS server. By enabling the DOTS client to share 164 this comprehensive knowledge of an ongoing attack under specific 165 circumstances, the DOTS server can drastically increase its abilities 166 to accomplish successful mitigation. While the attack is being 167 handled by the DOTS server associated mitigation resources, the DOTS 168 server has the knowledge about the ongoing attack mitigation. The 169 DOTS server can share this information with the DOTS client so that 170 the client can better assess and evaluate the actual mitigation 171 realized. 173 In some deployments, DOTS clients can send mitigation hints derived 174 from attack details to DOTS servers, with the full understanding that 175 the DOTS server may ignore mitigation hints, as described in 176 [RFC8612] (Gen-004). Mitigation hints will be transmitted across the 177 DOTS signal channel, as the data channel may not be functional during 178 an attack. How a DOTS server is handling normal and attack traffic 179 attributes, and mitigation hints is implementation-specific. 181 Both DOTS client and server can benefit this information by 182 presenting various information in relevant management, reporting, and 183 portal systems. 185 This document defines DOTS telemetry attributes the DOTS client can 186 convey to the DOTS server, and vice versa. The DOTS telemetry 187 attributes are not mandatory fields. Nevertheless, when DOTS 188 telemetry attributes are available to a DOTS agent, and absent any 189 policy, it can signal the attributes in order to optimize the overall 190 mitigation service provisioned using DOTS. Some of the DOTS 191 telemetry data is not shared during an attack time. 193 2. Terminology 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 197 "OPTIONAL" in this document are to be interpreted as described in BCP 198 14 [RFC2119][RFC8174] when, and only when, they appear in all 199 capitals, as shown here. 201 The reader should be familiar with the terms defined in [RFC8612]. 203 "DOTS Telemetry" is defined as the collection of attributes that are 204 used to characterize normal traffic baseline, attacks and their 205 mitigation measures, and any related information that may help in 206 enforcing countermeasures. The DOTS Telemetry is an optional set of 207 attributes that can be signaled in the DOTS signal channel protocol. 209 The meaning of the symbols in YANG tree diagrams is defined in 210 [RFC8340]. 212 3. DOTS Telemetry: Overview & Purpose 214 When signaling a mitigation request, it is most certainly beneficial 215 for the DOTS client to signal to the DOTS server any knowledge 216 regarding ongoing attacks. This can happen in cases where DOTS 217 clients are asking the DOTS server for support in defending against 218 attacks that they have already detected and/or mitigated. These 219 actions taken by DOTS clients are referred to as "signaling the DOTS 220 Telemetry". 222 If attacks are already detected and categorized by the DOTS client 223 domain, the DOTS server, and its associated mitigation services, can 224 proactively benefit this information and optimize the overall service 225 delivered. It is important to note that DOTS client and server 226 detection and mitigation approaches can be different, and can 227 potentially outcome different results and attack classifications. 228 The DDoS mitigation service treats the ongoing attack details from 229 the client as hints and cannot completely rely or trust the attack 230 details conveyed by the DOTS client. 232 A basic requirement of security operation teams is to be aware and 233 get visibility into the attacks they need to handle. The DOTS server 234 security operation teams benefit from the DOTS telemetry, especially 235 from the reports of ongoing attacks. Even if some mitigation can be 236 automated, operational teams can use the DOTS telemetry to be 237 prepared for attack mitigation and to assign the correct resources 238 (operation staff, networking and mitigation) for the specific 239 service. Similarly, security operation personnel at the DOTS client 240 side ask for feedback about their requests for protection. 241 Therefore, it is valuable for the DOTS server to share DOTS telemetry 242 with the DOTS client. Thus mutual sharing of information is crucial 243 for "closing the mitigation loop" between the DOTS client and server. 244 For the server side team, it is important to realize that the same 245 attacks that the DOTS server's mitigation resources are seeing are 246 those that the DOTS client is asking to mitigate. For the DOTS 247 client side team, it is important to realize that the DOTS clients 248 receive the required service. For example: understanding that "I 249 asked for mitigation of two attacks and my DOTS server detects and 250 mitigates only one...". Cases of inconsistency in attack 251 classification between DOTS client and server can be high-lighted, 252 and maybe handled, using the DOTS telemetry attributes. 254 In addition, management and orchestration systems, at both DOTS 255 client and server sides, can potentially use DOTS telemetry as a 256 feedback to automate various control and management activities 257 derived from ongoing information signaled. 259 If the DOTS server's mitigation resources have the capabilities to 260 facilitate the DOTS telemetry, the DOTS server adopts its protection 261 strategy and activates the required countermeasures immediately 262 (automation enabled). The overall results of this adoption are 263 optimized attack mitigation decisions and actions. 265 The DOTS telemetry can also be used to tune the DDoS mitigators with 266 the correct state of the attack. During the last few years, DDoS 267 attack detection technologies have evolved from threshold-based 268 detection (that is, cases when all or specific parts of traffic cross 269 a pre-defined threshold for a certain period of time is considered as 270 an attack) to an "anomaly detection" approach. In anomaly detection, 271 the main idea is to maintain rigorous learning of "normal" behavior 272 and where an "anomaly" (or an attack) is identified and categorized 273 based on the knowledge about the normal behavior and a deviation from 274 this normal behavior. Machine learning approaches are used such that 275 the actual "traffic thresholds" are "automatically calculated" by 276 learning the protected entity normal traffic behavior during peace 277 time. The normal traffic characterization learned is referred to as 278 the "normal traffic baseline". An attack is detected when the 279 victim's actual traffic is deviating from this normal baseline. 281 In addition, subsequent activities toward mitigating an attack are 282 much more challenging. The ability to distinguish legitimate traffic 283 from attacker traffic on a per packet basis is complex. This 284 complexity originates from the fact that the packet itself may look 285 "legitimate" and no attack signature can be identified. The anomaly 286 can be identified only after detailed statistical analysis. DDoS 287 attack mitigators use the normal baseline during the mitigation of an 288 attack to identify and categorize the expected appearance of a 289 specific traffic pattern. Particularly the mitigators use the normal 290 baseline to recognize the "level of normality" needs to be achieved 291 during the various mitigation process. 293 Normal baseline calculation is performed based on continuous learning 294 of the normal behavior of the protected entities. The minimum 295 learning period varies from hours to days and even weeks, depending 296 on the protected application behavior. The baseline cannot be 297 learned during active attacks because attack conditions do not 298 characterize the protected entities' normal behavior. 300 If the DOTS client has calculated the normal baseline of its 301 protected entities, signaling this attribute to the DOTS server along 302 with the attack traffic levels is significantly valuable. The DOTS 303 server benefits from this telemetry by tuning its mitigation 304 resources with the DOTS client's normal baseline. The DOTS server 305 mitigators use the baseline to familiarize themselves with the attack 306 victim's normal behavior and target the baseline as the level of 307 normality they need to achieve. Consequently, the overall mitigation 308 performances obtained are dramatically improved in terms of time to 309 mitigate, accuracy, false-negative, false-positive, and other 310 measures. 312 Mitigation of attacks without having certain knowledge of normal 313 traffic can be inaccurate at best. This is especially true for 314 recursive signaling (see Section 3.2.3 in [I-D.ietf-dots-use-cases]). 315 In addition, the highly diverse types of use-cases where DOTS clients 316 are integrated also emphasize the need for knowledge of client 317 behavior. Consequently, common global thresholds for attack 318 detection practically cannot be realized. Each DOTS client can have 319 its own levels of traffic and normal behavior. Without facilitating 320 normal baseline signaling, it may be very difficult for DOTS servers 321 in some cases to detect and mitigate the attacks accurately. It is 322 important to emphasize that it is practically impossible for the 323 server's mitigators to calculate the normal baseline, in cases they 324 do not have any knowledge of the traffic beforehand. In addition, 325 baseline learning requires a period of time that cannot be afforded 326 during active attack. Of course, this information can provided using 327 out-of-band mechanisms or manual configuration at the risk to 328 maintain inaccurate information as the network evolves and "normal" 329 patterns change. The use of a dynamic and collaborative means 330 between the DOTS client and server to identify and share key 331 parameters for the sake of efficient DDoS protect is valuable. 333 During a high volume attack, DOTS client pipes can be totally 334 saturated. The DOTS client asks the DOTS server to handle the attack 335 upstream so that DOTS client pipes return to a reasonable load level 336 (normal pattern, ideally). At this point, it is essential to ensure 337 that the mitigator does not overwhelm the DOTS client pipes by 338 sending back "clean traffic", or what it believes is "clean". This 339 can happen when the mitigator has not managed to detect and mitigate 340 all the attacks launched towards the client. In this case, it can be 341 valuable to clients to signal to server the "Total pipe capacity", 342 which is the level of traffic the DOTS client domain can absorb from 343 the upstream network. Dynamic updating of the condition of pipes 344 between DOTS agents while they are under a DDoS attack is essential. 345 For example, for cases of multiple DOTS clients share the same 346 physical connectivity pipes. It is important to note, that the term 347 "pipe" noted here does not necessary represent physical pipe, but 348 rather represents the current level of traffic client can observe 349 from server. The server should activate other mechanisms to ensure 350 it does not saturate the client's pipes unintentionally. The rate- 351 limit action defined in [I-D.ietf-dots-data-channel] is a reasonable 352 candidate to achieve this objective; the client can ask for the type 353 of traffic (such as ICMP, UDP, TCP port number 80) it prefers to 354 limit. The rate-limit action can be controlled via the signal- 355 channel [I-D.ietf-dots-signal-filter-control] even when the pipe is 356 overwhelmed. 358 To summarize, timely and effective signaling of up-to-date DOTS 359 telemetry to all elements involved in the mitigation process is 360 essential and absolutely improves the overall service effectiveness. 361 Bi-directional feedback between DOTS agents is required for the 362 increased awareness of each party, supporting superior and highly 363 efficient attack mitigation service. 365 4. Generic Considerations 367 4.1. DOTS Client Identification 369 Following the rules in [I-D.ietf-dots-signal-channel], a unique 370 identifier is generated by a DOTS client to prevent request 371 collisions. 373 4.2. DOTS Gateways 375 DOTS gateways may be located between DOTS clients and servers. The 376 considerations elaborated in [I-D.ietf-dots-signal-channel] must be 377 followed. In particular, 'cdid' attribute is used to unambiguously 378 identify a DOTS client domain. 380 5. DOTS Telemetry Attributes 382 There are two broad types of DDoS attacks, one is bandwidth consuming 383 attack, the other is target resource consuming attack. This section 384 outlines the set of DOTS telemetry attributes that covers both the 385 types of attacks. The ultimate objective of these attributes is to 386 allow for the complete knowledge of attacks and the various 387 particulars that can best characterize attacks. 389 The description and motivation behind each attribute were presented 390 in Section 3. DOTS telemetry attributes are optionally signaled and 391 therefore MUST NOT be treated as mandatory fields in the DOTS signal 392 channel protocol. 394 5.1. Pre-mitigation DOTS Telemetry Attributes 396 The pre-mitigation telemetry attributes are indicated by the path- 397 suffix '/telemetry'. The '/telemetry' is appended to the path-prefix 398 to form the URI used with a CoAP request to signal the DOTS 399 telemetry. The following pre-mitigation telemetry attributes can be 400 signaled from the DOTS client to the DOTS server. 402 o DISCUSSION NOTES: (1) Some telemetry can be communicated using 403 DOTS data channel. (2) Evaluate the risk of fragmentation,. Some 404 of the information is not specific to each mitigation request. (3) 405 Should we define other configuration parameters to be controlled 406 by a DOTS client, e.g., Indicate a favorite measurement unit? 407 Indicate a minimum notification interval? 409 5.1.1. Total Traffic Normal Baseline 411 The low percentile (10th percentile), mid percentile (50th 412 percentile), high percentile (90th percentile) and peak values (100th 413 percentile) of "Total traffic normal baselines" measured in packets 414 per second (PPS) or kilo packets per second (Kpps) and Bits per 415 Second (BPS), and kilobytes per second or megabytes per second or 416 gigabytes per second. For example, 90th percentile says that 90% of 417 the time, the total normal traffic is below the limit specified. The 418 traffic normal baseline is represented for a target and is transport- 419 protocol specific. 421 5.1.2. Total Pipe Capability 423 The limit of traffic volume, in packets per second (PPS) or kilo 424 packets per second (Kpps) and Bits per Second (BPS), and in kilobytes 425 per second or megabytes per second or gigabytes per second. These 426 attributes represents the DOTS client domain pipe limit. 428 o NOTE: Multi-homing case to be considered. 430 5.1.3. Total Attack Traffic 432 The total attack traffic can be identified by the DOTS client 433 domain's DDoS Mitigation System (DMS) or DDoS Detector. The low 434 percentile (10th percentile), mid percentile (50th percentile), high 435 percentile (90th percentile) and peak values of total attack traffic 436 measured in packets per second (PPS) or kilo packets per second 437 (Kpps) and Bits per Second (BPS), and kilobytes per second or 438 megabytes per second or gigabytes per second. The total attack 439 traffic is represented for a target and is transport-protocol 440 specific. 442 5.1.4. Total Traffic 444 The low percentile (10th percentile), mid percentile (50th 445 percentile), high percentile (90th percentile) and peak values of 446 total traffic during a DDoS attack measured in packets per second 447 (PPS) or kilo packets per second (Kpps) and Bits per Second (BPS), 448 and kilobytes per second or megabytes per second gigabytes per 449 second. The total traffic is represented for a target and is 450 transport-protocol specific. 452 5.1.5. Total Connections Capacity 454 If the target is subjected to resource consuming DDoS attack, the 455 following optional attributes for the target per transport-protocol 456 are useful to detect resource consuming DDoS attacks: 458 o The maximum number of simultaneous connections that are allowed to 459 the target server. The threshold is transport-protocol specific 460 because the target server could support multiple protocols. 462 o The maximum number of simultaneous connections that are allowed to 463 the target server per client. 465 o The maximum number of simultaneous embryonic connections that are 466 allowed to the target server. The term "embryonic connection" 467 refers to a connection whose connection handshake is not finished 468 and embryonic connection is only possible in connection-oriented 469 transport protocols like TCP or SCTP. 471 o The maximum number of simultaneous embryonic connections that are 472 allowed to the target server per client. 474 o The maximum number of connections allowed per second to the target 475 server. 477 o The maximum number of connections allowed per second to the target 478 server per client. 480 o The maximum number of requests allowed per second to the target 481 server. 483 o The maximum number of requests allowed per second to the target 484 server per client. 486 o The maximum number of partial requests allowed per second to the 487 target server. 489 o The maximum number of partial requests allowed per second to the 490 target server per client. 492 5.1.6. Total Attack Connections 494 If the target is subjected to resource consuming DDoS attack, the low 495 percentile (10th percentile), mid percentile (50th percentile), high 496 percentile (90th percentile) and peak values of following optional 497 attributes for the target per transport-protocol are included to 498 represent the attack characteristics: 500 o The number of simultaneous attack connections to the target 501 server. 503 o The number of simultaneous embryonic connections to the target 504 server. 506 o The number of attack connections per second to the target server. 508 o The number of attack requests to the target server. 510 5.1.7. Attack Details 512 Various information and details that describe the on-going attacks 513 that needs to be mitigated by the DOTS server. The attack details 514 need to cover well-known and common attacks (such as a SYN Flood) 515 along with new emerging or vendor-specific attacks. The attack 516 details can also be signaled from the DOTS server to the DOTS client. 517 For example, the DOTS server co-located with a DDoS detector collects 518 monitoring information from the target network, identifies DDoS 519 attack using statistical analysis or deep learning techniques, and 520 signals the attack details to the DOTS client. The client can use 521 the attack details to decide whether to trigger the mitigation 522 request or not. Further, the security operation personnel at the 523 DOTS client domain can use the attack details to determine the 524 protection strategy and select the appropriate DOTS server for 525 mitigating the attack. The DOTS client can receive asynchronous 526 notifications of the attack details from the DOTS server using the 527 Observe option defined in [RFC7641]. 529 The following new fields describing the on-going attack are 530 discussed: 532 vendor-id: Vendor ID is a security vendor's Enterprise Number as 533 registered with IANA [Enterprise-Numbers]. It is a four-byte 534 integer value. 536 This is a mandatory sub-attribute. 538 attack-id: Unique identifier assigned by the vendor for the attack. 540 This is a mandatory sub-attribute. 542 attack-name: Textual representation of attack description. Natural 543 Language Processing techniques (e.g., word embedding) can possibly 544 be used to map the attack description to an attack type. Textual 545 representation of attack solves two problems (a) avoids the need 546 to create mapping tables manually between vendors (2) Avoids the 547 need to standardize attack types which keep evolving. 549 This is a mandatory sub-attribute 551 attack-severity: Attack severity. Emergency (0), critical (1) and 552 alert (2). 554 This is an optional sub-attribute 556 start-time: The time the attack started. The attack start time is 557 expressed in seconds relative to 1970-01-01T00:00Z in UTC time 558 (Section 2.4.1 of [RFC7049]). The CBOR encoding is modified so 559 that the leading tag 1 (epoch-based date/time) MUST be omitted. 561 This is a mandatory sub-attribute 563 end-time: The time the attack-id attack ended. The attack 564 end time is expressed in seconds relative to 1970-01-01T00:00Z in 565 UTC time (Section 2.4.1 of [RFC7049]). The CBOR encoding is 566 modified so that the leading tag 1 (epoch-based date/time) MUST be 567 omitted. 569 This is an optional sub-attribute 571 The following existing fields are re-defined describing the on-going 572 attack are discussed: 574 o The target resource is identified using the attributes 'target- 575 prefix', 'target-port-range', 'target-protocol', 'target- 576 fqdn','target-uri', or 'alias-name' defined in the base DOTS 577 signal channel protocol and at least one of the attributes 578 'target-prefix', 'target-fqdn','target-uri', or 'alias-name' MUST 579 be present in the attack details. 581 A. If the target is subjected to bandwidth consuming attack, the 582 attributes representing the low percentile (10th percentile), 583 mid percentile (50th percentile), high percentile (90th 584 percentile) and peak values of the attack-id attack traffic 585 measured in packets per second (PPS) or kilo packets per 586 second (Kpps) and Bits per Second (BPS), and kilobytes per 587 second or megabytes per second or gigabytes per second are 588 included. 590 B. If the target is subjected to resource consuming DDoS attacks, 591 the same attributes defined for Section 5.1.6 are applicable 592 for representing the attack. 594 This is an optional sub-attribute. 596 o A count of sources involved in the attack targeting the victim and 597 a list of top talkers among those sources. The top talkers are 598 represented using the 'source-prefix' defined in 599 [I-D.ietf-dots-signal-call-home]. If the top talkers are spoofed 600 IP addresses (e.g., reflection attacks) or not. If the target is 601 subjected to bandwidth consuming attack, the attack traffic from 602 each of the top talkers represented in the low percentile (10th 603 percentile), mid percentile (50th percentile), high percentile 604 (90th percentile) and peak values of traffic measured in packets 605 per second (PPS) or kilo packets per second (Kpps) and Bits per 606 Second (BPS), and kilobytes per second or megabytes per second 607 gigabytes per second. If the target is subjected to resource 608 consuming DDoS attacks, the same attributes defined for 609 Section 5.1.6 are applicable here for representing the attack per 610 talker. This is an optional sub-attribute. 612 5.2. DOTS Client to Server Mitigation Efficacy DOTS Telemetry 613 Attributes 615 The mitigation efficacy telemetry attributes can be signaled from the 616 DOTS client to the DOTS server as part of the periodic mitigation 617 efficacy updates to the server. 619 5.2.1. Total Attack Traffic 621 The low percentile (10th percentile), mid percentile (50th 622 percentile), high percentile (90th percentile), and peak values of 623 total attack traffic the DOTS client still sees during the active 624 mitigation service measured in packets per second (PPS) or kilo 625 packets per second (Kpps) and Bits per Second (BPS), and kilobytes 626 per second or megabytes per second or gigabytes per second. 628 5.2.2. Attack Details 630 The overall attack details as observed from the DOTS client 631 perspective during the active mitigation service. The same 632 attributes defined in Section 5.1.7 are applicable here. 634 5.3. DOTS Server to Client Mitigation Status DOTS Telemetry Attributes 636 The mitigation status telemetry attributes can be signaled from the 637 DOTS server to the DOTS client as part of the periodic mitigation 638 status update. 640 5.3.1. Mitigation Status 642 As defined in [RFC8612], the actual mitigation activities can include 643 several countermeasure mechanisms. The DOTS server SHOULD signal the 644 current operational status to each relevant countermeasure. A list 645 of attacks detected by each countermeasure. The same attributes 646 defined for Section 5.1.7 are applicable here for describing the 647 attacks detected and mitigated. 649 6. DOTS Telemetry Configuration 651 6.1. Convey DOTS Telemetry Configuration 653 PUT request is used to convey the configuration parameters for the 654 telemetry data (e.g., low, mid, or high percentile values). For 655 example, a DOTS client may contact its DOTS server to change the 656 default percentiles values used as baseline for telemetry data. In 657 reference to the example shown in Figure 1, the DOTS client modifies 658 all percentile reference values. 660 Header: PUT (Code=0.03) 661 Uri-Path: ".well-known" 662 Uri-Path: "dots" 663 Uri-Path: "telemetry" 664 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 665 Uri-Path: "tcid=123" 666 Content-Format: "application/dots+cbor" 668 { 669 "ietf-dots-telemetry:telemetry-config": { 670 "low-percentile": 5.00, 671 "mid-percentile": 65.00, 672 "high-percentile": 95.00 673 } 674 } 676 Figure 1: PUT to Convey the DOTS Telemetry Configuration 678 'cuid' is a mandatory Uri-Path parameter for PUT requests. 680 The following additional Uri-Path parameter is defined: 682 tcid: Telemetry Configuration Identifier is an identifier for the 683 DOTS telemetry configuration data represented as an integer. 684 This identifier MUST be generated by DOTS clients. 'tcid' 685 values MUST increase monotonically (when a new PUT is generated 686 by a DOTS client to convey the configuration parameters for the 687 telemetry). 689 This is a mandatory attribute. 691 At least one configurable attribute MUST be present in the PUT 692 request. 694 Attributes and Uri-Path parameters with empty values MUST NOT be 695 present in a request and render the entire request invalid. 697 The PUT request with a higher numeric 'tcid' value overrides the DOTS 698 telemetry configuration data installed by a PUT request with a lower 699 numeric 'tcid' value. To avoid maintaining a long list of 'tcid' 700 requests from a DOTS client, the lower numeric 'tcid' MUST be 701 automatically deleted and no longer available at the DOTS server. 703 The DOTS server indicates the result of processing the PUT request 704 using CoAP response codes: 706 o If the request is missing a mandatory attribute, does not include 707 'cuid' or 'tcid' Uri-Path parameters, or contains one or more 708 invalid or unknown parameters, 4.00 (Bad Request) MUST be returned 709 in the response. 711 o If the DOTS server does not find the 'tcid' parameter value 712 conveyed in the PUT request in its configuration data and if the 713 DOTS server has accepted the configuration parameters, then a 714 response code 2.01 (Created) MUST be returned in the response. 716 o If the DOTS server finds the 'tcid' parameter value conveyed in 717 the PUT request in its configuration data and if the DOTS server 718 has accepted the updated configuration parameters, 2.04 (Changed) 719 MUST be returned in the response. 721 o If any of the enclosed configurable attribute values are not 722 acceptable to the DOTS server, 4.22 (Unprocessable Entity) MUST be 723 returned in the response. 725 The DOTS client may re-try and send the PUT request with updated 726 attribute values acceptable to the DOTS server. 728 A DOTS client may issue a GET message with 'tcid' Uri-Path parameter 729 to retrieve the negotiated configuration. The response does not need 730 to include 'tcid' in its message body. 732 Setting 'low-percentile' to '0.00' indicates that the DOTS client is 733 not interested in receiving low-percentiles. Likewise, setting 'mid- 734 percentile' (or 'high-percentile') to the same value as 'low- 735 percentile' (or 'mid-percentile') indicates that the DOTS client is 736 not interested in receiving mid-percentiles (or high-percentiles). 737 For example, a DOTS client can send the request depicted in Figure 2 738 to inform the server that it is interested in receiving only high- 739 percentiles. 741 Notes: Should the server be able to indicate its preference too? 742 If the DOTS server and client cannot agree on a common telemetry 743 config, the client does not have to send the telemetry (it will 744 anyway be ignored by the server). 746 Header: PUT (Code=0.03) 747 Uri-Path: ".well-known" 748 Uri-Path: "dots" 749 Uri-Path: "telemetry" 750 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 751 Uri-Path: "tcid=569" 752 Content-Format: "application/dots+cbor" 754 { 755 "ietf-dots-telemetry:telemetry-config": { 756 "low-percentile": 0.00, 757 "mid-percentile": 0.00, 758 "high-percentile": 95.00 759 } 760 } 762 Figure 2: PUT to Disable Low- and Mid-Percentiles 764 6.2. Delete DOTS Telemetry Configuration 766 A DELETE request is used to delete the installed DOTS telemetry 767 configuration data (Figure 3). 769 Header: DELETE (Code=0.04) 770 Uri-Path: ".well-known" 771 Uri-Path: "dots" 772 Uri-Path: "telemetry" 773 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 774 Uri-Path: "tcid=123" 776 Figure 3: Delete Telemetry Configuration 778 The DOTS server resets the DOTS telemetry configuration back to the 779 default values and acknowledges a DOTS client's request to remove the 780 DOTS telemetry configuration using 2.02 (Deleted) response code. 782 Upon bootstrapping or reboot, a DOTS client MAY send a DELETE request 783 to set the telemetry parameters to default values. Such a request 784 does not include any 'tcid'. 786 7. DOTS Telemetry YANG Module 788 7.1. Tree Structure 790 This document defines the YANG module "ietf-dots-telemetry". 792 Notes: (1) Check naming conflict to ease CBOR mapping (e.g, low- 793 percentile is defined as yang:gauge64, list, or container). 795 Distinct names may be considered. (2) "protocol" is not indicated 796 in the telemetry data of "mitigation-scope" message type because 797 the mitigation request may include a "protocol". Similarly, 798 "target-*" attributes are not included in the in the telemetry 799 data of "mitigation-scope" message type because the mitigation 800 request must include at least one of the "target-*" attribute. 802 The "ietf-dots-telemetry" YANG module augments the "mitigation-scope" 803 type message defined in "ietf-dots-signal" with telemetry data as 804 depicted in following tree structure: 806 augment /ietf-signal:dots-signal/ietf-signal:message-type 807 /ietf-signal:mitigation-scope/ietf-signal:scope: 808 +--rw total-attack-traffic* [unit] {dots-telemetry}? 809 | +--rw unit unit 810 | +--rw low-percentile-g? yang:gauge64 811 | +--rw mid-percentile-g? yang:gauge64 812 | +--rw high-percentile-g? yang:gauge64 813 | +--rw peak-g? yang:gauge64 814 +--rw total-attack-connection {dots-telemetry}? 815 | +--rw low-percentile-c 816 | | +--rw connection? yang:gauge64 817 | | +--rw embryonic? yang:gauge64 818 | | +--rw connection-ps? yang:gauge64 819 | | +--rw request-ps? yang:gauge64 820 | | +--rw partial-request-ps? yang:gauge64 821 | +--rw mid-percentile-c 822 | | +--rw connection? yang:gauge64 823 | | +--rw embryonic? yang:gauge64 824 | | +--rw connection-ps? yang:gauge64 825 | | +--rw request-ps? yang:gauge64 826 | | +--rw partial-request-ps? yang:gauge64 827 | +--rw high-percentile-c 828 | | +--rw connection? yang:gauge64 829 | | +--rw embryonic? yang:gauge64 830 | | +--rw connection-ps? yang:gauge64 831 | | +--rw request-ps? yang:gauge64 832 | | +--rw partial-request-ps? yang:gauge64 833 | +--rw peak-c 834 | +--rw connection? yang:gauge64 835 | +--rw embryonic? yang:gauge64 836 | +--rw connection-ps? yang:gauge64 837 | +--rw request-ps? yang:gauge64 838 | +--rw partial-request-ps? yang:gauge64 839 +--rw attack-detail {dots-telemetry}? 840 +--rw vendor-id? uint32 841 +--rw attack-id? string 842 +--rw attack-name? string 843 +--rw attack-severity? attack-severity 844 +--rw start-time? uint64 845 +--rw end-time? uint64 846 +--rw source-count 847 | +--rw low-percentile-g? yang:gauge64 848 | +--rw mid-percentile-g? yang:gauge64 849 | +--rw high-percentile-g? yang:gauge64 850 | +--rw peak-g? yang:gauge64 851 +--rw top-talker 852 +--rw source-prefix* [source-prefix] 853 +--rw spoofed-status? boolean 854 +--rw source-prefix inet:ip-prefix 855 +--rw total-attack-traffic* [unit] 856 | +--rw unit unit 857 | +--rw low-percentile-g? yang:gauge64 858 | +--rw mid-percentile-g? yang:gauge64 859 | +--rw high-percentile-g? yang:gauge64 860 | +--rw peak-g? yang:gauge64 861 +--rw total-attack-connection 862 +--rw low-percentile-c 863 | +--rw connection? yang:gauge64 864 | +--rw embryonic? yang:gauge64 865 | +--rw connection-ps? yang:gauge64 866 | +--rw request-ps? yang:gauge64 867 | +--rw partial-request-ps? yang:gauge64 868 +--rw mid-percentile-c 869 | +--rw connection? yang:gauge64 870 | +--rw embryonic? yang:gauge64 871 | +--rw connection-ps? yang:gauge64 872 | +--rw request-ps? yang:gauge64 873 | +--rw partial-request-ps? yang:gauge64 874 +--rw high-percentile-c 875 | +--rw connection? yang:gauge64 876 | +--rw embryonic? yang:gauge64 877 | +--rw connection-ps? yang:gauge64 878 | +--rw request-ps? yang:gauge64 879 | +--rw partial-request-ps? yang:gauge64 880 +--rw peak-c 881 +--rw connection? yang:gauge64 882 +--rw embryonic? yang:gauge64 883 +--rw connection-ps? yang:gauge64 884 +--rw request-ps? yang:gauge64 885 +--rw partial-request-ps? yang:gauge64 887 Also, the "ietf-dots-telemetry" YANG module augments the "ietf-dots- 888 signal" with a new message type called "telemetry". The tree 889 structure of the "telemetry" message type is shown below: 891 augment /ietf-signal:dots-signal/ietf-signal:message-type: 892 +--:(telemetry) {dots-telemetry}? 893 +--rw telemetry* [cuid tcid] 894 +--rw cuid string 895 +--rw cdid? string 896 +--rw tcid uint32 897 +--rw telemetry-config 898 | +--rw low-percentile? percentile 899 | +--rw mid-percentile? percentile 900 | +--rw high-percentile? percentile 901 | +--rw unit-config* [unit] 902 | +--rw unit unit 903 | +--rw unit-status? boolean 904 +--rw total-pipe-capability* [unit] 905 | +--rw unit unit 906 | +--rw pipe? uint64 907 +--rw pre-mitigation* [telemetry-id] 908 +--rw telemetry-id uint32 909 +--rw target 910 | +--rw target-prefix* inet:ip-prefix 911 | +--rw target-port-range* [lower-port] 912 | | +--rw lower-port inet:port-number 913 | | +--rw upper-port? inet:port-number 914 | +--rw target-protocol* uint8 915 | +--rw target-fqdn* inet:domain-name 916 | +--rw target-uri* inet:uri 917 +--rw total-traffic-normal-baseline* [unit protocol] 918 | +--rw unit unit 919 | +--rw protocol uint8 920 | +--rw low-percentile-g? yang:gauge64 921 | +--rw mid-percentile-g? yang:gauge64 922 | +--rw high-percentile-g? yang:gauge64 923 | +--rw peak-g? yang:gauge64 924 +--ro total-attack-traffic* [unit protocol] 925 | +--ro unit unit 926 | +--ro protocol uint8 927 | +--ro low-percentile-g? yang:gauge64 928 | +--ro mid-percentile-g? yang:gauge64 929 | +--ro high-percentile-g? yang:gauge64 930 | +--ro peak-g? yang:gauge64 931 +--ro total-traffic* [unit protocol] 932 | +--ro unit unit 933 | +--ro protocol uint8 934 | +--ro low-percentile-g? yang:gauge64 935 | +--ro mid-percentile-g? yang:gauge64 936 | +--ro high-percentile-g? yang:gauge64 937 | +--ro peak-g? yang:gauge64 938 +--rw total-connection-capacity* [protocol] 939 | +--rw protocol uint8 940 | +--rw connection? uint64 941 | +--rw connection-client? uint64 942 | +--rw embryonic? uint64 943 | +--rw embryonic-client? uint64 944 | +--rw connection-ps? uint64 945 | +--rw connection-client-ps? uint64 946 | +--rw request-ps? uint64 947 | +--rw request-client-ps? uint64 948 | +--rw partial-request-ps? uint64 949 | +--rw partial-request-client-ps? uint64 950 +--ro total-attack-connection 951 | +--ro low-percentile-l* [protocol] 952 | | +--ro protocol uint8 953 | | +--ro connection? yang:gauge64 954 | | +--ro embryonic? yang:gauge64 955 | | +--ro connection-ps? yang:gauge64 956 | | +--ro request-ps? yang:gauge64 957 | | +--ro partial-request-ps? yang:gauge64 958 | +--ro mid-percentile-l* [protocol] 959 | | +--ro protocol uint8 960 | | +--ro connection? yang:gauge64 961 | | +--ro embryonic? yang:gauge64 962 | | +--ro connection-ps? yang:gauge64 963 | | +--ro request-ps? yang:gauge64 964 | | +--ro partial-request-ps? yang:gauge64 965 | +--ro high-percentile-l* [protocol] 966 | | +--ro protocol uint8 967 | | +--ro connection? yang:gauge64 968 | | +--ro embryonic? yang:gauge64 969 | | +--ro connection-ps? yang:gauge64 970 | | +--ro request-ps? yang:gauge64 971 | | +--ro partial-request-ps? yang:gauge64 972 | +--ro peak-l* [protocol] 973 | +--ro protocol uint8 974 | +--ro connection? yang:gauge64 975 | +--ro embryonic? yang:gauge64 976 | +--ro connection-ps? yang:gauge64 977 | +--ro request-ps? yang:gauge64 978 | +--ro partial-request-ps? yang:gauge64 979 +--ro attack-detail 980 +--ro vendor-id? uint32 981 +--ro attack-id? string 982 +--ro attack-name? string 983 +--ro attack-severity? attack-severity 984 +--ro start-time? uint64 985 +--ro end-time? uint64 986 +--ro source-count 987 | +--ro low-percentile-g? yang:gauge64 988 | +--ro mid-percentile-g? yang:gauge64 989 | +--ro high-percentile-g? yang:gauge64 990 | +--ro peak-g? yang:gauge64 991 +--ro top-talker 992 +--ro source-prefix* [source-prefix] 993 +--ro spoofed-status? boolean 994 +--ro source-prefix inet:ip-prefix 995 +--ro total-attack-traffic* [unit] 996 | +--ro unit unit 997 | +--ro low-percentile-g? yang:gauge64 998 | +--ro mid-percentile-g? yang:gauge64 999 | +--ro high-percentile-g? yang:gauge64 1000 | +--ro peak-g? yang:gauge64 1001 +--ro total-attack-connection 1002 +--ro low-percentile-l* [protocol] 1003 | +--ro protocol uint8 1004 | +--ro connection? yang:gauge64 1005 | +--ro embryonic? yang:gauge64 1006 | +--ro connection-ps? yang:gauge64 1007 | +--ro request-ps? yang:gauge64 1008 | +--ro partial-request-ps? yang:gauge64 1009 +--ro mid-percentile-l* [protocol] 1010 | +--ro protocol uint8 1011 | +--ro connection? yang:gauge64 1012 | +--ro embryonic? yang:gauge64 1013 | +--ro connection-ps? yang:gauge64 1014 | +--ro request-ps? yang:gauge64 1015 | +--ro partial-request-ps? yang:gauge64 1016 +--ro high-percentile-l* [protocol] 1017 | +--ro protocol uint8 1018 | +--ro connection? yang:gauge64 1019 | +--ro embryonic? yang:gauge64 1020 | +--ro connection-ps? yang:gauge64 1021 | +--ro request-ps? yang:gauge64 1022 | +--ro partial-request-ps? yang:gauge64 1023 +--ro peak-l* [protocol] 1024 +--ro protocol uint8 1025 +--ro connection? yang:gauge64 1026 +--ro embryonic? yang:gauge64 1027 +--ro connection-ps? yang:gauge64 1028 +--ro request-ps? yang:gauge64 1029 +--ro partial-request-ps? yang:gauge64 1031 7.2. YANG Module 1033 This module uses types defined in [RFC6991]. 1035 file "ietf-dots-telemetry@2019-11-08.yang" 1036 module ietf-dots-telemetry { 1037 yang-version 1.1; 1038 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry"; 1039 prefix dots-telemetry; 1041 import ietf-dots-signal-channel { 1042 prefix ietf-signal; 1043 reference 1044 "RFC SSSS: Distributed Denial-of-Service Open Threat 1045 Signaling (DOTS) Signal Channel Specification"; 1046 } 1047 import ietf-dots-data-channel { 1048 prefix ietf-data; 1049 reference 1050 "RFC DDDD: Distributed Denial-of-Service Open Threat 1051 Signaling (DOTS) Data Channel Specification"; 1052 } 1053 import ietf-yang-types { 1054 prefix yang; 1055 reference "Section 3 of RFC 6991"; 1056 } 1057 import ietf-inet-types { 1058 prefix inet; 1059 reference "Section 4 of RFC 6991"; 1060 } 1062 organization 1063 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 1064 contact 1065 "WG Web: 1066 WG List: 1068 Author: Mohamed Boucadair 1069 1071 Author: Konda, Tirumaleswar Reddy 1072 "; 1073 description 1074 "This module contains YANG definitions for the signaling 1075 of DOTS telemetry exchanged between a DOTS client and 1076 a DOTS server, by means of the DOTS signal channel. 1078 Copyright (c) 2019 IETF Trust and the persons identified as 1079 authors of the code. All rights reserved. 1081 Redistribution and use in source and binary forms, with or 1082 without modification, is permitted pursuant to, and subject 1083 to the license terms contained in, the Simplified BSD License 1084 set forth in Section 4.c of the IETF Trust's Legal Provisions 1085 Relating to IETF Documents 1086 (http://trustee.ietf.org/license-info). 1088 This version of this YANG module is part of RFC XXXX; see 1089 the RFC itself for full legal notices."; 1091 revision 2019-11-08 { 1092 description 1093 "Initial revision."; 1094 reference 1095 "RFC XXXX: Distributed Denial-of-Service Open Threat 1096 Signaling (DOTS) Telemetry"; 1097 } 1099 feature dots-telemetry { 1100 description 1101 "This feature means that the DOTS signal channel is able 1102 to convey DOTS telemetry data between DOTS clients and 1103 servers."; 1104 } 1106 typedef attack-severity { 1107 type enumeration { 1108 enum "emergency" { 1109 value 1; 1110 description 1111 "The attack is severe: emergency."; 1112 } 1113 enum "critical" { 1114 value 2; 1115 description 1116 "The attack is critical."; 1117 } 1118 enum "alert" { 1119 value 3; 1120 description 1121 "This is an alert."; 1122 } 1123 } 1124 description 1125 "Enumeration for attack severity."; 1126 } 1127 typedef unit { 1128 type enumeration { 1129 enum "pps" { 1130 value 1; 1131 description 1132 "Packets per second (PPS)."; 1133 } 1134 enum "kilo-pps" { 1135 value 2; 1136 description 1137 "Kilo packets per second (Kpps)."; 1138 } 1139 enum "bps" { 1140 value 3; 1141 description 1142 "Bits per Second (BPS)."; 1143 } 1144 enum "kilobytes-ps" { 1145 value 4; 1146 description 1147 "Kilobytes per second."; 1148 } 1149 enum "megabytes-ps" { 1150 value 5; 1151 description 1152 "Megabytes per second."; 1153 } 1154 enum "gigabytes-ps" { 1155 value 6; 1156 description 1157 "Gigabytes per second."; 1158 } 1159 } 1160 description 1161 "Enumeration to indicate which unit is used."; 1162 } 1164 typedef percentile { 1165 type decimal64 { 1166 fraction-digits 2; 1167 } 1168 description 1169 "The nth percentile of a set of data is the 1170 value at which n percent of the data is below it."; 1171 } 1173 grouping percentile-config { 1174 description 1175 "Configuration of low, mid, and high percentile values."; 1176 leaf low-percentile { 1177 type percentile; 1178 default "10.00"; 1179 description 1180 "Low percentile. If set to '0', this means low-percentiles 1181 are disabled."; 1182 } 1183 leaf mid-percentile { 1184 type percentile; 1185 must '. >= ../low-percentile' { 1186 error-message 1187 "The mid-percentile must be greater than 1188 or equal to the low-percentile."; 1189 } 1190 default "50.00"; 1191 description 1192 "Mid percentile. If set to the same value as low-percentiles, 1193 this means mid-percentiles are disabled."; 1194 } 1195 leaf high-percentile { 1196 type percentile; 1197 must '. >= ../mid-percentile' { 1198 error-message 1199 "The high-percentile must be greater than 1200 or equal to the mid-percentile."; 1201 } 1202 default "90.00"; 1203 description 1204 "High percentile. If set to the same value as mid-percentiles, 1205 this means high-percentiles are disabled."; 1206 } 1207 } 1209 grouping percentile { 1210 description 1211 "Generic grouping for percentile."; 1212 leaf low-percentile-g { 1213 type yang:gauge64; 1214 description 1215 "Low traffic."; 1216 } 1217 leaf mid-percentile-g { 1218 type yang:gauge64; 1219 description 1220 "Mid percentile."; 1221 } 1222 leaf high-percentile-g { 1223 type yang:gauge64; 1224 description 1225 "High percentile."; 1226 } 1227 leaf peak-g { 1228 type yang:gauge64; 1229 description 1230 "Peak"; 1231 } 1232 } 1234 grouping traffic-unit { 1235 description 1236 "Grouping of traffic as a function of measurement unit."; 1237 leaf unit { 1238 type unit; 1239 description 1240 "The traffic can be measured in packets per 1241 second (PPS) or kilo packets per second (Kpps) and Bits per 1242 Second (BPS), and kilobytes per second or megabytes per second 1243 or gigabytes per second."; 1244 } 1245 uses percentile; 1246 } 1248 grouping traffic-unit-protocol { 1249 description 1250 "Grouping of traffic of a given transport protocol as 1251 a function of measurement unit."; 1252 leaf unit { 1253 type unit; 1254 description 1255 "The traffic can be measured in packets per 1256 second (PPS) or kilo packets per second (Kpps) and Bits per 1257 Second (BPS), and kilobytes per second or megabytes per second 1258 or gigabytes per second."; 1259 } 1260 leaf protocol { 1261 type uint8; 1262 description 1263 "The transport protocol. 1264 Values are taken from the IANA Protocol Numbers registry: 1265 . 1267 For example, this field contains 6 for TCP, 1268 17 for UDP, 33 for DCCP, or 132 for SCTP."; 1269 } 1270 uses percentile; 1272 } 1274 grouping total-connection-capacity { 1275 description 1276 "Total Connections Capacity. If the target is subjected 1277 to resource consuming DDoS attack, these attributes are 1278 useful to detect resource consuming DDoS attacks"; 1279 leaf connection { 1280 type uint64; 1281 description 1282 "The maximum number of simultaneous connections that 1283 are allowed to the target server. The threshold is 1284 transport-protocol specific because the target server 1285 could support multiple protocols."; 1286 } 1287 leaf connection-client { 1288 type uint64; 1289 description 1290 "The maximum number of simultaneous connections that 1291 are allowed to the target server per client."; 1292 } 1293 leaf embryonic { 1294 type uint64; 1295 description 1296 "The maximum number of simultaneous embryonic connections 1297 that are allowed to the target server. The term 'embryonic 1298 connection' refers to a connection whose connection handshake 1299 is not finished and embryonic connection is only possible in 1300 connection-oriented transport protocols like TCP or SCTP."; 1301 } 1302 leaf embryonic-client { 1303 type uint64; 1304 description 1305 "The maximum number of simultaneous embryonic connections 1306 that are allowed to the target server per client."; 1307 } 1308 leaf connection-ps { 1309 type uint64; 1310 description 1311 "The maximum number of connections allowed per second 1312 to the target server."; 1313 } 1314 leaf connection-client-ps { 1315 type uint64; 1316 description 1317 "The maximum number of connections allowed per second 1318 to the target server per client."; 1319 } 1320 leaf request-ps { 1321 type uint64; 1322 description 1323 "The maximum number of requests allowed per second 1324 to the target server."; 1325 } 1326 leaf request-client-ps { 1327 type uint64; 1328 description 1329 "The maximum number of requests allowed per second 1330 to the target server per client."; 1331 } 1332 leaf partial-request-ps { 1333 type uint64; 1334 description 1335 "The maximum number of partial requests allowed per 1336 second to the target server."; 1337 } 1338 leaf partial-request-client-ps { 1339 type uint64; 1340 description 1341 "The maximum number of partial requests allowed per 1342 second to the target server per client."; 1343 } 1344 } 1346 grouping connection { 1347 description 1348 "A set of attributes which represent the attack 1349 characteristics"; 1350 leaf connection { 1351 type yang:gauge64; 1352 description 1353 "The number of simultaneous attack connections to 1354 the target server."; 1355 } 1356 leaf embryonic { 1357 type yang:gauge64; 1358 description 1359 "The number of simultaneous embryonic connections to 1360 the target server."; 1361 } 1362 leaf connection-ps { 1363 type yang:gauge64; 1364 description 1365 "The number of attack connections per second to 1366 the target server."; 1367 } 1368 leaf request-ps { 1369 type yang:gauge64; 1370 description 1371 "The number of attack requests per second to 1372 the target server."; 1373 } 1374 leaf partial-request-ps { 1375 type yang:gauge64; 1376 description 1377 "The number of attack partial requests to 1378 the target server."; 1379 } 1380 } 1382 grouping connection-percentile { 1383 description 1384 "Total attack connections."; 1385 container low-percentile-c { 1386 description 1387 "Low percentile of attack connections."; 1388 uses connection; 1389 } 1390 container mid-percentile-c { 1391 description 1392 "Mid percentile of attack connections."; 1393 uses connection; 1394 } 1395 container high-percentile-c { 1396 description 1397 "High percentile of attack connections."; 1398 uses connection; 1399 } 1400 container peak-c { 1401 description 1402 "Peak attack connections."; 1403 uses connection; 1404 } 1405 } 1407 grouping connection-protocol-percentile { 1408 description 1409 "Total attack connections."; 1410 list low-percentile-l { 1411 key "protocol"; 1412 description 1413 "Low percentile of attack connections."; 1414 leaf protocol { 1415 type uint8; 1416 description 1417 "The transport protocol. 1418 Values are taken from the IANA Protocol Numbers registry: 1419 ."; 1420 } 1421 uses connection; 1422 } 1423 list mid-percentile-l { 1424 key "protocol"; 1425 description 1426 "Mid percentile of attack connections."; 1427 leaf protocol { 1428 type uint8; 1429 description 1430 "The transport protocol. 1431 Values are taken from the IANA Protocol Numbers registry: 1432 ."; 1433 } 1434 uses connection; 1435 } 1436 list high-percentile-l { 1437 key "protocol"; 1438 description 1439 "Highg percentile of attack connections."; 1440 leaf protocol { 1441 type uint8; 1442 description 1443 "The transport protocol. 1444 Values are taken from the IANA Protocol Numbers registry: 1445 ."; 1446 } 1447 uses connection; 1448 } 1449 list peak-l { 1450 key "protocol"; 1451 description 1452 "Peak attack connections."; 1453 leaf protocol { 1454 type uint8; 1455 description 1456 "The transport protocol. 1457 Values are taken from the IANA Protocol Numbers registry: 1458 ."; 1459 } 1460 uses connection; 1461 } 1462 } 1463 grouping attack-detail { 1464 description 1465 "Various information and details that describe the on-going 1466 attacks that needs to be mitigated by the DOTS server. 1467 The attack details need to cover well-known and common attacks 1468 (such as a SYN Flood) along with new emerging or vendor-specific 1469 attacks."; 1470 leaf vendor-id { 1471 type uint32; 1472 description 1473 "Vendor ID is a security vendor's Enterprise Number."; 1474 } 1475 leaf attack-id { 1476 type string; 1477 description 1478 "Unique identifier assigned by the vendor for the attack."; 1479 } 1480 leaf attack-name { 1481 type string; 1482 description 1483 "Textual representation of attack description. Natural Language 1484 Processing techniques (e.g., word embedding) can possibly be used 1485 to map the attack description to an attack type."; 1486 } 1487 leaf attack-severity { 1488 type attack-severity; 1489 description 1490 "Severity level of an attack"; 1491 } 1492 leaf start-time { 1493 type uint64; 1494 description 1495 "The time the attack started. Start time is represented in seconds 1496 relative to 1970-01-01T00:00:00Z in UTC time."; 1497 } 1498 leaf end-time { 1499 type uint64; 1500 description 1501 "The time the attack ended. End time is represented in seconds 1502 relative to 1970-01-01T00:00:00Z in UTC time."; 1503 } 1504 container source-count { 1505 description 1506 "Indicates the count of unique sources involved 1507 in the attack."; 1508 uses percentile; 1509 } 1510 } 1511 grouping top-talker-aggregate { 1512 description 1513 "Top attack sources."; 1514 list source-prefix { 1515 key "source-prefix"; 1516 description 1517 "IPv4 or IPv6 prefix identifying the attacker(s)."; 1518 leaf spoofed-status { 1519 type boolean; 1520 description 1521 "Indicates whether this address is spoofed."; 1522 } 1523 leaf source-prefix { 1524 type inet:ip-prefix; 1525 description 1526 "IPv4 or IPv6 prefix identifying the attacker(s)."; 1527 } 1528 list total-attack-traffic { 1529 key "unit"; 1530 description 1531 "Total attack traffic issued from this source."; 1532 uses traffic-unit; 1533 } 1534 container total-attack-connection { 1535 description 1536 "Total attack connections issued from this source."; 1537 uses connection-percentile; 1538 } 1539 } 1540 } 1542 grouping top-talker { 1543 description 1544 "Top attack sources."; 1545 list source-prefix { 1546 key "source-prefix"; 1547 description 1548 "IPv4 or IPv6 prefix identifying the attacker(s)."; 1549 leaf spoofed-status { 1550 type boolean; 1551 description 1552 "Indicates whether this address is spoofed."; 1553 } 1554 leaf source-prefix { 1555 type inet:ip-prefix; 1556 description 1557 "IPv4 or IPv6 prefix identifying the attacker(s)."; 1558 } 1559 list total-attack-traffic { 1560 key "unit"; 1561 description 1562 "Total attack traffic issued from this source."; 1563 uses traffic-unit; 1564 } 1565 container total-attack-connection { 1566 description 1567 "Total attack connections issued from this source."; 1568 uses connection-protocol-percentile; 1569 } 1570 } 1571 } 1573 grouping pre-mitigation { 1574 description 1575 "Grouping for the telemetry data."; 1576 list total-traffic-normal-baseline { 1577 key "unit protocol"; 1578 description 1579 "Total traffic normal baselines."; 1580 uses traffic-unit-protocol; 1581 } 1582 list total-attack-traffic { 1583 key "unit protocol"; 1584 config false; 1585 description 1586 "Total attack traffic per protocol."; 1587 uses traffic-unit-protocol; 1588 } 1589 list total-traffic { 1590 key "unit protocol"; 1591 config false; 1592 description 1593 "Total traffic."; 1594 uses traffic-unit-protocol; 1595 } 1596 list total-connection-capacity { 1597 key "protocol"; 1598 description 1599 "Total connection capacity."; 1600 leaf protocol { 1601 type uint8; 1602 description 1603 "The transport protocol. 1604 Values are taken from the IANA Protocol Numbers registry: 1605 ."; 1606 } 1607 uses total-connection-capacity; 1608 } 1609 container total-attack-connection { 1610 config false; 1611 description 1612 "Total attack connections."; 1613 uses connection-protocol-percentile; 1614 } 1615 container attack-detail { 1616 config false; 1617 description 1618 "Attack details."; 1619 uses attack-detail; 1620 container top-talker { 1621 description 1622 "Top attack sources."; 1623 uses top-talker; 1624 } 1625 } 1626 } 1628 augment "/ietf-signal:dots-signal/ietf-signal:message-type/" 1629 + "ietf-signal:mitigation-scope/ietf-signal:scope" { 1630 if-feature "dots-telemetry"; 1631 description 1632 "Extends mitigation scope with telemetry update data."; 1633 list total-attack-traffic { 1634 key "unit"; 1635 description 1636 "Total attack traffic."; 1637 uses traffic-unit; 1638 } 1639 container total-attack-connection { 1640 description 1641 "Total attack connections."; 1642 uses connection-percentile; 1643 } 1644 container attack-detail { 1645 description 1646 "Atatck details"; 1647 uses attack-detail; 1648 container top-talker { 1649 description 1650 "Top attack sources."; 1651 uses top-talker-aggregate; 1652 } 1653 } 1654 } 1655 augment "/ietf-signal:dots-signal/ietf-signal:message-type" { 1656 if-feature "dots-telemetry"; 1657 description 1658 "Add a new choice to enclose telemetry data in DOTS 1659 signal channel."; 1660 case telemetry { 1661 description 1662 "Indicates the message is about telemetry."; 1663 list telemetry { 1664 key "cuid tcid"; 1665 description 1666 "The telemetry data per DOTS client."; 1667 leaf cuid { 1668 type string; 1669 description 1670 "A unique identifier that is 1671 generated by a DOTS client to prevent 1672 request collisions. It is expected that the 1673 cuid will remain consistent throughout the 1674 lifetime of the DOTS client."; 1675 } 1676 leaf cdid { 1677 type string; 1678 description 1679 "The cdid should be included by a server-domain 1680 DOTS gateway to propagate the client domain 1681 identification information from the 1682 gateway's client-facing-side to the gateway's 1683 server-facing-side, and from the gateway's 1684 server-facing-side to the DOTS server. 1686 It may be used by the final DOTS server 1687 for policy enforcement purposes."; 1688 } 1689 leaf tcid { 1690 type uint32; 1691 description 1692 "An identifier for the DOTS telemetry configuration 1693 data."; 1694 } 1695 container telemetry-config { 1696 description 1697 "Uses to set low, mid, and high percentile values."; 1698 uses percentile-config; 1699 list unit-config { 1700 key "unit"; 1701 description 1702 "Controls which units are allowed when sharing telemetry 1703 data."; 1704 leaf unit { 1705 type unit; 1706 description 1707 "The traffic can be measured in packets per 1708 second (PPS) or kilo packets per second (Kpps) and Bits per 1709 Second (BPS), and kilobytes per second or megabytes per second 1710 or gigabytes per second."; 1711 } 1712 leaf unit-status { 1713 type boolean; 1714 description 1715 "Enable/disable the use of the measurement unit."; 1716 } 1717 } 1718 } 1719 list total-pipe-capability { 1720 key "unit"; 1721 description 1722 "Total pipe capacity of a DOTS client domain."; 1723 leaf unit { 1724 type unit; 1725 description 1726 "The traffic can be measured in packets per 1727 second (PPS) or kilo packets per second (Kpps) and Bits per 1728 Second (BPS), and kilobytes per second or megabytes per second 1729 or gigabytes per second."; 1730 } 1731 leaf pipe { 1732 type uint64; 1733 description 1734 "Mid traffic percentile."; 1735 } 1736 } 1737 list pre-mitigation { 1738 key "telemetry-id"; 1739 description 1740 "Pre-mitigation telemetry."; 1741 leaf telemetry-id { 1742 type uint32; 1743 description 1744 "An identifier to uniquely demux telemetry data send using 1745 the same message."; 1746 } 1747 container target { 1748 description 1749 "Indicates the target."; 1750 uses ietf-data:target; 1752 } 1753 uses pre-mitigation; 1754 } 1755 } 1756 } 1757 } 1758 } 1760 1762 8. IANA Considerations 1764 8.1. DOTS Signal Channel CBOR Mappings Registry 1766 This specification registers the DOTS telemetry attributes in the 1767 IANA "DOTS Signal Channel CBOR Mappings" registry established by 1768 [I-D.ietf-dots-signal-channel]. 1770 The DOTS telemetry attributes defined in this specification are 1771 comprehension-optional parameters. 1773 o Note to the RFC Editor: Please delete (TBD1)-(TBD5) once CBOR keys 1774 are assigned from the 0x8000 - 0xBFFF range. 1776 +----------------------+-------------+------+---------------+--------+ 1777 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 1778 | | Type | Key | Type & | Type | 1779 | | | | Information | | 1780 +----------------------+-------------+------+---------------+--------+ 1781 | ietf-dots-signal-cha | | | | | 1782 | nnel:telemetry | container |0x8008| 5 map | Object | 1783 | tcid | uint32 |0x8009| 0 unsigned | Number | 1784 | telemetry-config | container |0x800A| 5 map | Object | 1785 | low-percentile | decimal64 |0x800B| 6 tag 4 | | 1786 | | | | [-2, integer]| String | 1787 | mid-percentile | decimal64 |0x800C| 6 tag 4 | | 1788 | | | | [-2, integer]| String | 1789 | high-percentile | decimal64 |0x800D| 6 tag 4 | | 1790 | | | | [-2, integer]| String | 1791 | unit-config | list |0x800E| 4 array | Array | 1792 | unit | enumeration |0x800F| 0 unsigned | String | 1793 | unit-status | boolean |0x8010| 7 bits 20 | False | 1794 | | | | 7 bits 21 | True | 1795 | total-pipe-capability| list |0x8011| 4 array | Array | 1796 | pipe | uint64 |0x8012| 0 unsigned | String | 1797 | pre-mitigation | list |0x8013| 4 array | Array | 1798 | telemetry-id | uint32 |0x8014| 0 unsigned | Number | 1799 | total-traffic- | | | | | 1800 | normal-baseline | list |0x8015| 4 array | Array | 1801 | low-percentile-g | yang:gauge64|0x8016| 0 unsigned | String | 1802 | mid-percentile-g | yang:gauge64|0x8017| 0 unsigned | String | 1803 | high-percentile-g | yang:gauge64|0x8018| 0 unsigned | String | 1804 | peak-g | yang:gauge64|0x8019| 0 unsigned | String | 1805 | total-attack-traffic | list |0x801A| 4 array | Array | 1806 | total-traffic | list |0x801B| 4 array | Array | 1807 | total-connection- | | | | | 1808 | capacity | list |0x801C| 4 array | Array | 1809 | connection | uint64 |0x801D| 0 unsigned | String | 1810 | connection-client | uint64 |0x801E| 0 unsigned | String | 1811 | embryonic | uint64 |0x801F| 0 unsigned | String | 1812 | embryonic-client | uint64 |0x8020| 0 unsigned | String | 1813 | connection-ps | uint64 |0x8021| 0 unsigned | String | 1814 | connection-client-ps | uint64 |0x8022| 0 unsigned | String | 1815 | request-ps | uint64 |0x8023| 0 unsigned | String | 1816 | request-client-ps | uint64 |0x8024| 0 unsigned | String | 1817 | partial-request-ps | uint64 |0x8025| 0 unsigned | String | 1818 | partial-request- | | | | | 1819 | client-ps | uint64 |0x8026| 0 unsigned | String | 1820 | total-attack- | | | | | 1821 | connection | container |0x8027| 5 map | Object | 1822 | low-percentile-l | list |0x8028| 4 array | Array | 1823 | mid-percentile-l | list |0x8029| 4 array | Array | 1824 | high-percentile-l | list |0x802A| 4 array | Array | 1825 | peak-l | list |0x802B| 4 array | Array | 1826 | attack-detail | container |0x802C| 5 map | Object | 1827 | vendor-id | uint32 |0x802D| 0 unsigned | Number | 1828 | attack-id | string |0x802E| 3 text string | String | 1829 | attack-name | string |0x802F| 3 text string | String | 1830 | attack-severity | enumeration |0x8030| 0 unsigned | String | 1831 | start-time | uint64 |0x8031| 0 unsigned | String | 1832 | end-time | uint64 |0x8032| 0 unsigned | String | 1833 | source-count | container |0x8033| 5 map | Object | 1834 | top-talker | container |0x8034| 5 map | Object | 1835 | spoofed-status | boolean |0x8035| 7 bits 20 | False | 1836 | | | | 7 bits 21 | True | 1837 | low-percentile-c | container |0x8036| 5 map | Object | 1838 | mid-percentile-c | container |0x8037| 5 map | Object | 1839 | high-percentile-c | container |0x8038| 5 map | Object | 1840 | peak-c | container |0x8039| 5 map | Object | 1841 +----------------------+-------------+------+---------------+--------+ 1843 8.2. DOTS Signal Telemetry YANG Module 1845 This document requests IANA to register the following URI in the "ns" 1846 subregistry within the "IETF XML Registry" [RFC3688]: 1848 URI: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry 1849 Registrant Contact: The IESG. 1850 XML: N/A; the requested URI is an XML namespace. 1852 This document requests IANA to register the following YANG module in 1853 the "YANG Module Names" subregistry [RFC7950] within the "YANG 1854 Parameters" registry. 1856 name: ietf-dots-telemetry 1857 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry 1858 maintained by IANA: N 1859 prefix: dots-telemetry 1860 reference: RFC XXXX 1862 9. Security Considerations 1864 Security considerations in [I-D.ietf-dots-signal-channel] need to be 1865 taken into consideration. 1867 10. Contributors 1869 The following individuals have contributed to this document: 1871 o Li Su, CMCC, Email: suli@chinamobile.com 1873 o Jin Peng, CMCC, Email: pengjin@chinamobile.com 1875 11. Acknowledgements 1877 The authors would like to thank Flemming Andreasen, Liang Xia, and 1878 Kaname Nishizuka co-authors of https://tools.ietf.org/html/draft- 1879 doron-dots-telemetry-00 draft and everyone who had contributed to 1880 that document. 1882 Authors would like to thank Kaname Nishizuka, Jon Shallow, Wei Pan 1883 and Yuuhei Hayashi for comments and review. 1885 12. References 1887 12.1. Normative References 1889 [Enterprise-Numbers] 1890 "Private Enterprise Numbers", 2005, . 1893 [I-D.ietf-dots-data-channel] 1894 Boucadair, M. and T. Reddy.K, "Distributed Denial-of- 1895 Service Open Threat Signaling (DOTS) Data Channel 1896 Specification", draft-ietf-dots-data-channel-31 (work in 1897 progress), July 2019. 1899 [I-D.ietf-dots-signal-call-home] 1900 Reddy.K, T., Boucadair, M., and J. Shallow, "Distributed 1901 Denial-of-Service Open Threat Signaling (DOTS) Signal 1902 Channel Call Home", draft-ietf-dots-signal-call-home-07 1903 (work in progress), November 2019. 1905 [I-D.ietf-dots-signal-channel] 1906 Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and 1907 N. Teague, "Distributed Denial-of-Service Open Threat 1908 Signaling (DOTS) Signal Channel Specification", draft- 1909 ietf-dots-signal-channel-39 (work in progress), November 1910 2019. 1912 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1913 Requirement Levels", BCP 14, RFC 2119, 1914 DOI 10.17487/RFC2119, March 1997, 1915 . 1917 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1918 DOI 10.17487/RFC3688, January 2004, 1919 . 1921 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1922 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1923 . 1925 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1926 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1927 October 2013, . 1929 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1930 Application Protocol (CoAP)", RFC 7641, 1931 DOI 10.17487/RFC7641, September 2015, 1932 . 1934 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1935 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1936 . 1938 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1939 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1940 May 2017, . 1942 12.2. Informative References 1944 [I-D.ietf-dots-signal-filter-control] 1945 Nishizuka, K., Boucadair, M., Reddy.K, T., and T. Nagata, 1946 "Controlling Filtering Rules Using Distributed Denial-of- 1947 Service Open Threat Signaling (DOTS) Signal Channel", 1948 draft-ietf-dots-signal-filter-control-02 (work in 1949 progress), September 2019. 1951 [I-D.ietf-dots-use-cases] 1952 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 1953 L., and K. Nishizuka, "Use cases for DDoS Open Threat 1954 Signaling", draft-ietf-dots-use-cases-20 (work in 1955 progress), September 2019. 1957 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1958 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1959 . 1961 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 1962 Threat Signaling (DOTS) Requirements", RFC 8612, 1963 DOI 10.17487/RFC8612, May 2019, 1964 . 1966 Authors' Addresses 1968 Tirumaleswar Reddy 1969 McAfee, Inc. 1970 Embassy Golf Link Business Park 1971 Bangalore, Karnataka 560071 1972 India 1974 Email: kondtir@gmail.com 1976 Mohamed Boucadair 1977 Orange 1978 Rennes 35000 1979 France 1981 Email: mohamed.boucadair@orange.com 1982 Ehud Doron 1983 Radware Ltd. 1984 Raoul Wallenberg Street 1985 Tel-Aviv 69710 1986 Israel 1988 Email: ehudd@radware.com 1990 Meiling Chen 1991 CMCC 1992 32, Xuanwumen West 1993 BeiJing, BeiJing 100053 1994 China 1996 Email: chenmeiling@chinamobile.com