idnits 2.17.1 draft-reddy-dots-telemetry-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 12, 2019) is 1681 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-06 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-37 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-20 Summary: 0 errors (**), 0 flaws (~~), 4 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: March 15, 2020 Orange 6 E. Doron 7 Radware Ltd. 8 September 12, 2019 10 Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry 11 draft-reddy-dots-telemetry-02 13 Abstract 15 This document aims to enrich DOTS signal channel protocol with 16 various telemetry attributes allowing optimal DDoS attack mitigation. 17 This document specifies the normal traffic baseline and attack 18 traffic telemetry attributes a DOTS client can convey to its DOTS 19 server in the mitigation request, the mitigation status telemetry 20 attributes a DOTS server can communicate to a DOTS client, and the 21 mitigation efficacy telemetry attributes a DOTS client can 22 communicate to a DOTS server. The telemetry attributes can assist 23 the mitigator to choose the DDoS mitigation techniques and perform 24 optimal DDoS attack mitigation. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 15, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. DOTS Telemetry: Overview & Purpose . . . . . . . . . . . . . 5 63 4. DOTS Telemetry Attributes . . . . . . . . . . . . . . . . . . 8 64 4.1. Pre-mitigation DOTS Telemetry Attributes . . . . . . . . 8 65 4.1.1. Total Traffic Normal Baseline . . . . . . . . . . . . 8 66 4.1.2. Total Pipe Capability . . . . . . . . . . . . . . . . 9 67 4.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 9 68 4.1.4. Total Traffic . . . . . . . . . . . . . . . . . . . . 9 69 4.1.5. Total Connections Characteristics . . . . . . . . . . 9 70 4.1.6. Attack Details . . . . . . . . . . . . . . . . . . . 10 71 4.2. DOTS Client to Server Mitigation Efficacy DOTS Telemetry 72 Attributes . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.2.1. Total Attack Traffic . . . . . . . . . . . . . . . . 12 74 4.2.2. Attack Details . . . . . . . . . . . . . . . . . . . 12 75 4.3. DOTS Server to Client Mitigation Status DOTS Telemetry 76 Attributes . . . . . . . . . . . . . . . . . . . . . . . 13 77 4.3.1. Mitigation Status . . . . . . . . . . . . . . . . . . 13 78 5. DOTS Telemetry YANG Module . . . . . . . . . . . . . . . . . 13 79 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 13 80 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 13 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 6.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 13 83 6.2. DOTS Signal Telemetry YANG Module . . . . . . . . . . . . 14 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 88 9.2. Informative References . . . . . . . . . . . . . . . . . 15 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 The Internet security 'battle' between the adversary and security 94 countermeasures is an everlasting one. DDoS attacks have become more 95 vicious and sophisticated in almost all aspects of their maneuvers 96 and malevolent intentions. IT organizations and service providers 97 are facing DDoS attacks that fall into two broad categories: Network/ 98 Transport layer attacks and Application layer attacks. Network/ 99 Transport layer attacks target the victim's infrastructure. These 100 attacks are not necessarily aimed at taking down the actual delivered 101 services, but rather to eliminate various network elements (routers, 102 switches, firewalls, transit links, and so on) from serving 103 legitimate user traffic. The main method of such attacks is to send 104 a large volume or high PPS of traffic toward the victim's 105 infrastructure. Typically, attack volumes may vary from a few 100 106 Mbps/PPS to 100s of Gbps or even Tbps. Attacks are commonly carried 107 out leveraging botnets and attack reflectors for amplification 108 attacks, such as NTP, DNS, SNMP, SSDP, and so on. Application layer 109 attacks target various applications. Typical examples include 110 attacks against HTTP/HTTPS, DNS, SIP, SMTP, and so on. However, all 111 valid applications with their port numbers open at network edges can 112 be attractive attack targets. Application layer attacks are 113 considered more complex and hard to categorize, therefore harder to 114 detect and mitigate efficiently. 116 To compound the problem, attackers also leverage multi-vectored 117 attacks. These merciless attacks are assembled from dynamic attack 118 vectors (Network/Application) and tactics. As such, multiple attack 119 vectors formed by multiple attack types and volumes are launched 120 simultaneously towards a victim. Multi-vector attacks are harder to 121 detect and defend. Multiple and simultaneous mitigation techniques 122 are needed to defeat such attack campaigns. It is also common for 123 attackers to change attack vectors right after a successful 124 mitigation, burdening their opponents with changing their defense 125 methods. 127 The ultimate conclusion derived from these real scenarios is that 128 modern attacks detection and mitigation are most certainly 129 complicated and highly convoluted tasks. They demand a comprehensive 130 knowledge of the attack attributes, the targeted normal behavior/ 131 traffic patterns, as well as the attacker's on-going and past 132 actions. Even more challenging, retrieving all the analytics needed 133 for detecting these attacks is not simple to obtain with the 134 industry's current capabilities. 136 The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is 137 used to carry information about a network resource or a network (or a 138 part thereof) that is under a Distributed Denial of Service (DDoS) 139 attack. Such information is sent by a DOTS client to one or multiple 140 DOTS servers so that appropriate mitigation actions are undertaken on 141 traffic deemed suspicious. Various use cases are discussed in 142 [I-D.ietf-dots-use-cases]. 144 Typically, DOTS clients can be integrated within a DDoS attack 145 detector, or network and security elements that have been actively 146 engaged with ongoing attacks. The DOTS client mitigation environment 147 determines that it is no longer possible or practical for it to 148 handle these attacks. This can be due to lack of resources or 149 security capabilities, as derived from the complexities and the 150 intensity of these attacks. In this circumstance, the DOTS client 151 has invaluable knowledge about the actual attacks that need to be 152 handled by the DOTS server. By enabling the DOTS client to share 153 this comprehensive knowledge of an ongoing attack under specific 154 circumstances, the DOTS server can drastically increase its abilities 155 to accomplish successful mitigation. While the attack is being 156 handled by the DOTS server associated mitigation resources, the DOTS 157 server has the knowledge about the ongoing attack mitigation. The 158 DOTS server can share this information with the DOTS client so that 159 the client can better assess and evaluate the actual mitigation 160 realized. 162 In some deployments, DOTS clients can send mitigation hints derived 163 from attack details to DOTS servers, with the full understanding that 164 the DOTS server may ignore mitigation hints, as described in 165 [RFC8612] (Gen-004). Mitigation hints will be transmitted across the 166 DOTS signal channel, as the data channel may not be functional during 167 an attack. How a DOTS server is handling normal and attack traffic 168 attributes, and mitigation hints is implementation-specific. 170 Both DOTS client and server can benefit this information by 171 presenting various information in relevant management, reporting, and 172 portal systems. 174 This document defines DOTS telemetry attributes the DOTS client can 175 convey to the DOTS server, and vice versa. The DOTS telemetry 176 attributes are not mandatory fields. Nevertheless, when DOTS 177 telemetry attributes are available to a DOTS agent, and absent any 178 policy, it can signal the attributes in order to optimize the overall 179 mitigation service provisioned using DOTS. Some of the DOTS 180 telemetry data are not shared during an attack time. 182 2. Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 186 "OPTIONAL" in this document are to be interpreted as described in BCP 187 14 [RFC2119][RFC8174] when, and only when, they appear in all 188 capitals, as shown here. 190 The reader should be familiar with the terms defined in [RFC8612]. 192 "DOTS Telemetry" is defined as the collection of attributes that are 193 used to characterize normal traffic baseline, attacks and their 194 mitigation measures, and any related information that may help in 195 enforcing countermeasures. The DOTS Telemetry is an optional set of 196 attributes that can be signaled in the DOTS signal channel protocol. 198 The meaning of the symbols in YANG tree diagrams is defined in 199 [RFC8340]. 201 3. DOTS Telemetry: Overview & Purpose 203 When signaling a mitigation request, it is most certainly beneficial 204 for the DOTS client to signal to the DOTS server any knowledge 205 regarding ongoing attacks. This can happen in cases where DOTS 206 clients are asking the DOTS server for support in defending against 207 attacks that they have already detected and/or mitigated. These 208 actions taken by DOTS clients are referred to as "signaling the DOTS 209 Telemetry". 211 If attacks are already detected and categorized by the DOTS client 212 domain, the DOTS server, and its associated mitigation services, can 213 proactively benefit this information and optimize the overall service 214 delivered. It is important to note that DOTS client and server 215 detection and mitigation approaches can be different, and can 216 potentially outcome different results and attack classifications. 217 The DDoS mitigation service treats the ongoing attack details from 218 the client as hints and cannot completely rely or trust the attack 219 details conveyed by the DOTS client. 221 A basic requirement of security operation teams is to be aware and 222 get visibility into the attacks they need to handle. The DOTS server 223 security operation teams benefit from the DOTS telemetry, especially 224 from the reports of ongoing attacks. Even if some mitigation can be 225 automated, operational teams can use the DOTS telemetry to be 226 prepared for attack mitigation and to assign the correct resources 227 (operation staff, networking and mitigation) for the specific 228 service. Similarly, security operation personnel at the DOTS client 229 side ask for feedback about their requests for protection. 230 Therefore, it is valuable for the DOTS server to share DOTS telemetry 231 with the DOTS client. Thus mutual sharing of information is crucial 232 for "closing the mitigation loop" between the DOTS client and server. 233 For the server side team, it is important to realize that the same 234 attacks that the DOTS server's mitigation resources are seeing are 235 those that the DOTS client is asking to mitigate. For the DOTS 236 client side team, it is important to realize that the DOTS clients 237 receive the required service. For example: understanding that "I 238 asked for mitigation of two attacks and my DOTS server detects and 239 mitigates only one...". Cases of inconsistency in attack 240 classification between DOTS client and server can be high-lighted, 241 and maybe handled, using the DOTS telemetry attributes. 243 In addition, management and orchestration systems, at both DOTS 244 client and server sides, can potentially use DOTS telemetry as a 245 feedback to automate various control and management activities 246 derived from ongoing information signaled. 248 If the DOTS server's mitigation resources have the capabilities to 249 facilitate the DOTS telemetry, the DOTS server adopts its protection 250 strategy and activates the required countermeasures immediately 251 (automation enabled). The overall results of this adoption are 252 optimized attack mitigation decisions and actions. 254 The DOTS telemetry can also be used to tune the DDoS mitigators with 255 the correct state of the attack. During the last few years, DDoS 256 attack detection technologies have evolved from threshold-based 257 detection (that is, cases when all or specific parts of traffic cross 258 a pre-defined threshold for a certain period of time is considered as 259 an attack) to an "anomaly detection" approach. In anomaly detection, 260 the main idea is to maintain rigorous learning of "normal" behavior 261 and where an "anomaly" (or an attack) is identified and categorized 262 based on the knowledge about the normal behavior and a deviation from 263 this normal behavior. Machine learning approaches are used such that 264 the actual "traffic thresholds" are "automatically calculated" by 265 learning the protected entity normal traffic behavior during peace 266 time. The normal traffic characterization learned is referred to as 267 the "normal traffic baseline". An attack is detected when the 268 victim's actual traffic is deviating from this normal baseline. 270 In addition, subsequent activities toward mitigating an attack are 271 much more challenging. The ability to distinguish legitimate traffic 272 from attacker traffic on a per packet basis is complex. This 273 complexity originates from the fact that the packet itself may look 274 "legitimate" and no attack signature can be identified. The anomaly 275 can be identified only after detailed statistical analysis. DDoS 276 attack mitigators use the normal baseline during the mitigation of an 277 attack to identify and categorize the expected appearance of a 278 specific traffic pattern. Particularly the mitigators use the normal 279 baseline to recognize the "level of normality" needs to be achieved 280 during the various mitigation process. 282 Normal baseline calculation is performed based on continuous learning 283 of the normal behavior of the protected entities. The minimum 284 learning period varies from hours to days and even weeks, depending 285 on the protected application behavior. The baseline cannot be 286 learned during active attacks because attack conditions do not 287 characterize the protected entities' normal behavior. 289 If the DOTS client has calculated the normal baseline of its 290 protected entities, signaling this attribute to the DOTS server along 291 with the attack traffic levels is significantly valuable. The DOTS 292 server benefits from this telemetry by tuning its mitigation 293 resources with the DOTS client's normal baseline. The DOTS server 294 mitigators use the baseline to familiarize themselves with the attack 295 victim's normal behavior and target the baseline as the level of 296 normality they need to achieve. Consequently, the overall mitigation 297 performances obtained are dramatically improved in terms of time to 298 mitigate, accuracy, false-negative, false-positive, and other 299 measures. 301 Mitigation of attacks without having certain knowledge of normal 302 traffic can be inaccurate at best. This is especially true for 303 recursive signaling (see Section 3.2.3 in [I-D.ietf-dots-use-cases]). 304 In addition, the highly diverse types of use-cases where DOTS clients 305 are integrated also emphasize the need for knowledge of client 306 behavior. Consequently, common global thresholds for attack 307 detection practically cannot be realized. Each DOTS client can have 308 its own levels of traffic and normal behavior. Without facilitating 309 normal baseline signaling, it may be very difficult for DOTS servers 310 in some cases to detect and mitigate the attacks accurately. It is 311 important to emphasize that it is practically impossible for the 312 server's mitigators to calculate the normal baseline, in cases they 313 do not have any knowledge of the traffic beforehand. In addition, 314 baseline learning requires a period of time that cannot be afforded 315 during active attack. Of course, this information can provided using 316 out-of-band mechanisms or manual configuration at the risk to 317 maintain inaccurate information as the network evolves and "normal" 318 patterns change. The use of a dynamic and collaborative means 319 between the DOTS client and server to identify and share key 320 parameters for the sake of efficient DDoS protect is valuable. 322 During a high volume attack, DOTS client pipes can be totally 323 saturated. The DOTS client asks the DOTS server to handle the attack 324 upstream so that DOTS client pipes return to a reasonable load level 325 (normal pattern, ideally). At this point, it is essential to ensure 326 that the DOTS server does not overwhelm the DOTS client pipes by 327 sending back "clean traffic", or what it believes is "clean". This 328 can happen when the server has not managed to detect and mitigate all 329 the attacks launched towards the client. In this case, it can be 330 valuable to clients to signal to server the "Total pipe capacity", 331 which is the level of traffic the clients can absorb from the 332 upstream server. Dynamic updating of the condition of pipes between 333 DOTS agents while they are under a DDoS attack is essential. For 334 example, for cases of multiple DOTS clients share the same physical 335 connectivity pipes. It is important to note, that the term "pipe" 336 noted here does not necessary represent physical pipe, but rather 337 represents the current level of traffic client can observe from 338 server. The server should activate other mechanisms to ensure it 339 does not saturate the client's pipes unintentionally. The rate-limit 340 action defined in [I-D.ietf-dots-data-channel] can be a reasonable 341 candidate to achieve this objective; the client can ask for the type 342 of traffic (such as ICMP, UDP, TCP port 80) it prefers to limit. 344 To summarize, timely and effective signaling of up-to-date DOTS 345 telemetry to all elements involved in the mitigation process is 346 essential and absolutely improves the overall service effectiveness. 347 Bi-directional feedback between DOTS agents is required for the 348 increased awareness of each party, supporting superior and highly 349 efficient attack mitigation service. 351 4. DOTS Telemetry Attributes 353 This section outlines the set of DOTS telemetry attributes. The 354 ultimate objective of these attributes is to allow for the complete 355 knowledge of attacks and the various particulars that can best 356 characterize attacks. 358 The description and motivation behind each attribute were presented 359 in Section 3. DOTS telemetry attributes are optionally signaled and 360 therefore MUST NOT be treated as mandatory fields in the DOTS signal 361 channel protocol. 363 4.1. Pre-mitigation DOTS Telemetry Attributes 365 The pre-mitigation telemetry attributes are indiciated by the path- 366 suffix '/telemetry'. The '/telemetry' is appended to the path-prefix 367 to form the URI used with a CoAP request to signal the DOTS 368 telemetry. The following pre-mitigation telemetry attributes can be 369 signaled from the DOTS client to the DOTS server. 371 o DISCUSSION NOTES: (1) Some telemetry can be communicated using 372 DOTS data channel. (2) Evaluate the risk of fragmentation, or (3) 373 check if we can define a dedicated URI for telemetry (e.g.: use 374 ./telemetry). Some of the information is not specific to each 375 mitigation request. 377 4.1.1. Total Traffic Normal Baseline 379 The low percentile (10th percentile), mid percentile (50th 380 percentile), high percentile (90th percentile) and peak values (100th 381 percentile) of "Total traffic normal baselines" measured in packets 382 per second (PPS) or kilo packets per second (Kpps) and Bits per 383 Second (BPS), and kilobytes per second or megabytes per second or 384 gigabytes per second. For example, 90th percentile says that 90% of 385 the time, the total normal traffic is below the limit specified. 387 4.1.2. Total Pipe Capability 389 The limit of traffic volume, in packets per second (PPS) or kilo 390 packets per second (Kpps) and Bits per Second (BPS), and in kilobytes 391 per second or megabytes per second or gigabytes per second. These 392 attributes represents the DOTS client domain pipe limit. 394 o NOTE: Multi-homing case to be considered. 396 4.1.3. Total Attack Traffic 398 The total attack traffic can be identified by the DOTS client 399 domain's DDoS Mitigation System (DMS) or DDoS Detector. The low 400 percentile (10th percentile), mid percentile (50th percentile), high 401 percentile (90th percentile) and peak values of total attack traffic 402 measured in packets per second (PPS) or kilo packets per second 403 (Kpps) and Bits per Second (BPS), and kilobytes per second or 404 megabytes per second or gigabytes per second. 406 4.1.4. Total Traffic 408 The low percentile (10th percentile), mid percentile (50th 409 percentile), high percentile (90th percentile) and peak values of 410 total traffic during a DDoS attack measured in packets per second 411 (PPS) or kilo packets per second (Kpps) and Bits per Second (BPS), 412 and kilobytes per second or megabytes per second gigabytes per 413 second. 415 4.1.5. Total Connections Characteristics 417 The following attributes are useful to detect resource-based DDoS 418 attacks: 420 o The maximum number of simultaneous connections that are allowed to 421 the target server and the threshold is transport-protocol 422 specific. For example, the target server could support both 423 HTTP/2 and HTTP/3. 425 o The maximum number of simultaneous connections that are allowed to 426 the target server per client. 428 o The maximum number of simultaneous embryonic connections that are 429 allowed to the target server and the threshold is transport- 430 protocol specific. The term "embryonic connection" refers to a 431 connection whose connection handshake is not finished and 432 embryonic connection is only possible in connection-oriented 433 transport protocols like TCP or SCTP. 435 o The maximum number of simultaneous embryonic connections that are 436 allowed to the target server per client. 438 o The maximum number of connections allowed per second to the target 439 server and the threshold is transport-protocol specific. 441 o The maximum number of connections allowed per second to the target 442 server per client. 444 o The maximum number of requests allowed per second to the target 445 server and the threshold is protocol specific. 447 o The maximum number of requests allowed per second to the target 448 server per client. 450 o The maximum number of partial requests allowed per second to the 451 target server and the threshold is protocol specific. 453 o The maximum number of partial requests allowed per second to the 454 target server per client. 456 4.1.6. Attack Details 458 Various information and details that describe the on-going attacks 459 that needs to be mitigated by the DOTS server. The attack details 460 need to cover well-known and common attacks (such as a SYN Flood) 461 along with new emerging or vendor-specific attacks. The attack 462 details can also be signaled from the DOTS server to the DOTS client. 463 For example, the DOTS server co-located with a DDoS detector collects 464 monitoring information from the target network, identifies DDoS 465 attack using statistical analysis or deep learning techniques, and 466 signals the attack details to the DOTS client. The client can use 467 the attack details to decide whether to trigger the mitigation 468 request or not. Further, the security operation personnel at the 469 DOTS client domain can use the attack details to determine the 470 protection strategy and select the appropriate DOTS server for 471 mitigating the attack. The DOTS client can receive asynchronous 472 notifications of the attack details from the DOTS server using the 473 Observe option defined in [RFC7641]. 475 The following new fields describing the on-going attack are 476 discussed: 478 vendor-id: Vendor ID is a security vendor's Enterprise Number as 479 registered with IANA [Enterprise-Numbers]. It is a four-byte 480 integer value. 482 This is a mandatory sub-attribute. 484 attack-id: Unique identifier assigned by the vendor for the attack. 486 This is a mandatory sub-attribute. 488 attack-name: Textual representation of attack description. Natural 489 Language Processing techniques (e.g., word embedding) can possibly 490 be used to map the attack description to an attack type. Textual 491 representation of attack solves two problems (a) avoids the need 492 to create mapping tables manually between vendors (2) Avoids the 493 need to standardize attack types which keep evolving. 495 This is a mandatory sub-attribute 497 attack-severity: Attack severity. Emergency (0), critical (1) and 498 alert (2). 500 This is an optional sub-attribute 502 start-time: The time the attack started. 64-bit unsigned integer 503 field containing a timestamp. The value indicates the time since 504 January 1, 1970, 00:00 UTC using a fixed point format. In this 505 format, the integer number of seconds is contained in the first 48 506 bits of the field, and the remaining 16 bits indicate the number 507 of 1/64K fractions of a second (Native format - Unix). 509 This is a mandatory sub-attribute 511 end-time: The time the attack-id attack ended. 64-bit 512 unsigned integer field containing a timestamp. The value 513 indicates the time since January 1, 1970, 00:00 UTC using a fixed 514 point format. In this format, the integer number of seconds is 515 contained in the first 48 bits of the field, and the remaining 16 516 bits indicate the number of 1/64K fractions of a second (Native 517 format - Unix). 519 This is a optional sub-attribute 521 The following existing fields are re-defined describing the on-going 522 attack are discussed: 524 o List of top talkers targeting the victim and the attack traffic 525 from each of the top talkers measured in packets per second (PPS) 526 or kilo packets per second (Kpps) and Bits per Second (BPS), and 527 kilobytes per second or megabytes per second or gigabytes per 528 second. If the top talkers are spoofed IP addresses (e.g., 529 reflection attacks) or not. The average number of simultaneous 530 connections from each of the top talkers. The top talkers are 531 represented using the 'source-prefix', 'soure-port-range', and 532 source-imcp-type-range' attributes defined in 533 [I-D.ietf-dots-signal-call-home]. These are optional attributes 534 in the attack details. 536 o The target resource is identified using the attributes 'target- 537 prefix', 'target-port-range', 'target-protocol', 'target- 538 fqdn','target-uri', or 'alias-name' defined in the base DOTS 539 signal channel protocol and at least one of the attributes 540 'target-prefix', 'target-fqdn','target-uri', or 'alias-name' MUST 541 be present in the attack details. The low percentile (10th 542 percentile), mid percentile (50th percentile), high percentile 543 (90th percentile) and peak values of the attack-id attack traffic 544 measured in packets per second (PPS) or kilo packets per second 545 (Kpps) and Bits per Second (BPS), and kilobytes per second or 546 megabytes per second or gigabytes per second. 548 4.2. DOTS Client to Server Mitigation Efficacy DOTS Telemetry 549 Attributes 551 The mitigation efficacy telemetry attributes can be signaled from the 552 DOTS client to the DOTS server as part of the periodic mitigation 553 efficacy updates to the server. 555 4.2.1. Total Attack Traffic 557 The low percentile (10th percentile), mid percentile (50th 558 percentile), high percentile (90th percentile) and peak values of 559 total attack traffic the DOTS client still sees during the active 560 mitigation service measured in packets per second (PPS) or kilo 561 packets per second (Kpps) and Bits per Second (BPS), and kilobytes 562 per second or megabytes per second or gigabytes per second. 564 4.2.2. Attack Details 566 The overall attack details as observed from the DOTS client 567 perspective during the active mitigation service. The same 568 attributes defined in Section 4.1.6 are applicable here. 570 4.3. DOTS Server to Client Mitigation Status DOTS Telemetry Attributes 572 The mitigation status telemetry attributes can be signaled from the 573 DOTS server to the DOTS client as part of the periodic mitigation 574 status update. 576 4.3.1. Mitigation Status 578 As defined in [RFC8612], the actual mitigation activities can include 579 several countermeasure mechanisms. The DOTS server SHOULD signal the 580 current operational status to each relevant countermeasure. A list 581 of attacks detected by each countermeasure. The same attributes 582 defined for Section 4.1.6 are applicable here for describing the 583 attacks detected and mitigated. 585 5. DOTS Telemetry YANG Module 587 5.1. Tree Structure 589 TODO 591 5.2. YANG Module 593 TODO 595 6. IANA Considerations 597 6.1. DOTS Signal Channel CBOR Mappings Registry 599 This specification registers the DOTS telemetry attributes in the 600 IANA "DOTS Signal Channel CBOR Mappings" registry established by 601 [I-D.ietf-dots-signal-channel]. 603 The DOTS telemetry attributes defined in this specification are 604 comprehension-optional parameters. 606 o Note to the RFC Editor: Please delete (TBD1)-(TBD5) once CBOR keys 607 are assigned from the 0x8000 - 0xBFFF range. 609 +-------------------+------------+--------+---------------+--------+ 610 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 611 | | Type | Key | Type & | Type | 612 | | | | Information | | 613 +-------------------+------------+--------+---------------+--------+ 614 | TODO | | | | | 615 +-------------------+------------+--------+---------------+--------+ 617 6.2. DOTS Signal Telemetry YANG Module 619 This document requests IANA to register the following URI in the "ns" 620 subregistry within the "IETF XML Registry" [RFC3688]: 622 URI: urn:ietf:params:xml:ns:yang:TODO 623 Registrant Contact: The IESG. 624 XML: N/A; the requested URI is an XML namespace. 626 This document requests IANA to register the following YANG module in 627 the "YANG Module Names" subregistry [RFC7950] within the "YANG 628 Parameters" registry. 630 name: ietf-dots-telemetry 631 namespace: urn:ietf:params:xml:ns:yang:TODO 632 maintained by IANA: N 633 prefix: dots-telemetry 634 reference: RFC XXXX 636 7. Security Considerations 638 Security considerations in [I-D.ietf-dots-signal-channel] need to be 639 taken into consideration. 641 8. Acknowledgements 643 The authors would like to thank Flemming Andreasen, Liang Xia, and 644 Kaname Nishizuka co-authors of https://tools.ietf.org/html/draft- 645 doron-dots-telemetry-00 draft and everyone who had contributed to 646 that document. 648 Authors would like to thank Kaname Nishizuka, Jon Shallow, Wei Pan 649 and Yuuhei Hayashi for comments and review. 651 9. References 653 9.1. Normative References 655 [Enterprise-Numbers] 656 "Private Enterprise Numbers", 2005, . 659 [I-D.ietf-dots-data-channel] 660 Boucadair, M. and R. K, "Distributed Denial-of-Service 661 Open Threat Signaling (DOTS) Data Channel Specification", 662 draft-ietf-dots-data-channel-31 (work in progress), July 663 2019. 665 [I-D.ietf-dots-signal-call-home] 666 K, R., Boucadair, M., and J. Shallow, "Distributed Denial- 667 of-Service Open Threat Signaling (DOTS) Signal Channel 668 Call Home", draft-ietf-dots-signal-call-home-06 (work in 669 progress), September 2019. 671 [I-D.ietf-dots-signal-channel] 672 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 673 Teague, "Distributed Denial-of-Service Open Threat 674 Signaling (DOTS) Signal Channel Specification", draft- 675 ietf-dots-signal-channel-37 (work in progress), July 2019. 677 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 678 Requirement Levels", BCP 14, RFC 2119, 679 DOI 10.17487/RFC2119, March 1997, 680 . 682 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 683 DOI 10.17487/RFC3688, January 2004, 684 . 686 [RFC7641] Hartke, K., "Observing Resources in the Constrained 687 Application Protocol (CoAP)", RFC 7641, 688 DOI 10.17487/RFC7641, September 2015, 689 . 691 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 692 RFC 7950, DOI 10.17487/RFC7950, August 2016, 693 . 695 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 696 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 697 May 2017, . 699 9.2. Informative References 701 [I-D.ietf-dots-use-cases] 702 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 703 L., and K. Nishizuka, "Use cases for DDoS Open Threat 704 Signaling", draft-ietf-dots-use-cases-20 (work in 705 progress), September 2019. 707 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 708 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 709 . 711 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 712 Threat Signaling (DOTS) Requirements", RFC 8612, 713 DOI 10.17487/RFC8612, May 2019, 714 . 716 Authors' Addresses 718 Tirumaleswar Reddy 719 McAfee, Inc. 720 Embassy Golf Link Business Park 721 Bangalore, Karnataka 560071 722 India 724 Email: kondtir@gmail.com 726 Mohamed Boucadair 727 Orange 728 Rennes 35000 729 France 731 Email: mohamed.boucadair@orange.com 733 Ehud Doron 734 Radware Ltd. 735 Raoul Wallenberg Street 736 Tel-Aviv 69710 737 Israel 739 Email: ehudd@radware.com