idnits 2.17.1 draft-doron-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 : ---------------------------------------------------------------------------- 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 (October 30, 2016) is 2728 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-00 == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-02 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-01 == Outdated reference: A later version (-02) exists of draft-nishizuka-dots-inter-domain-mechanism-01 == Outdated reference: A later version (-05) exists of draft-reddy-dots-data-channel-00 == Outdated reference: A later version (-10) exists of draft-reddy-dots-signal-channel-01 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS E. Doron 3 Internet-Draft Radware Ltd. 4 Intended status: Informational T. Reddy 5 Expires: May 3, 2017 F. Andreasen 6 Cisco Systems, Inc. 7 L. Xia 8 Huawei 9 K. Nishizuka 10 NTT Communications 11 October 30, 2016 13 Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry 14 Specifications 15 draft-doron-dots-telemetry-00 17 Abstract 19 This document aims to enrich DOTS Signaling with various telemetry 20 attributes allowing optimal DDoS/DoS attack mitigation. The nature 21 of the DOTS architecture is to allow DOTS Agents to be integrated in 22 highly diverse environments. Therefore, the DOTS architecture 23 imposes a significant challenge in delivering optimal mitigation 24 services. The DOTS Telemetry covered in this document aims to 25 provide all needed attributes and feedback signaled from DOTS Agents 26 such that optimal mitigation services can be delivered based on DOTS 27 Signaling. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 3, 2017. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 66 2. Using the DOTS telemetry for a successful mitigation . . . . 4 67 3. DOTS Telemetry attributes . . . . . . . . . . . . . . . . . . 8 68 3.1. Pre-mitigation DOTS Telemetry attributes . . . . . . . . 9 69 3.1.1. "Normal Baselines" of legitimate traffic . . . . . . 9 70 3.1.2. "Total Attack Traffic volume" . . . . . . . . . . . . 9 71 3.1.3. "Attack Details" . . . . . . . . . . . . . . . . . . 9 72 3.1.4. "Total pipe capacity" . . . . . . . . . . . . . . . . 10 73 3.1.5. List of already "Authenticated source IPs" . . . . . 10 74 3.2. Client to Server Mitigation Status DOTS Telemetry 75 attributes . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.2.1. Current "Total traffic volumes" . . . . . . . . . . . 11 77 3.2.2. Current "Total Attack Traffic" . . . . . . . . . . . 11 78 3.2.3. "Mitigation Efficacy Factor" . . . . . . . . . . . . 11 79 3.2.4. "Attack Details" . . . . . . . . . . . . . . . . . . 11 80 3.3. Server to Client Mitigation Status DOTS Telemetry 81 attributes . . . . . . . . . . . . . . . . . . . . . . . 11 82 3.3.1. Current "Mitigation Countermeasure status" . . . . . 11 83 4. DOTS Telemetry Use-cases . . . . . . . . . . . . . . . . . . 12 84 4.1. Hybrid anti-DoS services use-case . . . . . . . . . . . . 12 85 4.2. MSP to MSP anti-DoS services use-case . . . . . . . . . . 13 86 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 91 8.2. Informative References . . . . . . . . . . . . . . . . . 13 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 94 1. Introduction 96 The DOTS signaling architecture (see [I-D.ietf-dots-architecture]) is 97 designed to allow anti-DoS services for a vast number of networking, 98 security and operational scenarios aimed to operate in diverse 99 environments. This is a multi-dimensional challenge DOTS needs to 100 meet in order to provide all the signaling requirements as derived 101 from each environment's unique characteristics. The DOTS Client can 102 be integrated within various elements with large diversity on their 103 security capabilities. In a simple use case, the DOTS Client can be 104 integrated in entities with a very basic understanding of the current 105 security conditions, for example a customer portal with a user that 106 is just realizing that something is "going wrong" with his service 107 but is not aware of the main cause of the service degradation. Here, 108 the DOTS Client can basically signal the need for mitigation along 109 with its identification attributes. In a more advanced use case, the 110 DOTS Client can be integrated within DDoS/DoS attack mitigators (and 111 their control and management environments) or network and security 112 elements that have been actively engaged with ongoing attacks. The 113 DOTS Client mitigation environment determines that it is no longer 114 possible or practical for it to handle these attacks. This can be 115 due to lack of resources or security capabilities, as derived from 116 the complexities and the intensity of these attacks. In this 117 circumstance the DOTS Client has invaluable knowledge about the 118 actual attacks that need to be handled by the DOTS Server. By 119 enabling the DOTS Client to share this comprehensive knowledge of an 120 ongoing attack, the DOTS Server can dramatically increase its 121 abilities to accomplish successful mitigation. While the attack is 122 being handled by the DOTS Server associated mitigation resources, the 123 DOTS Server has the knowledge about the ongoing attack mitigation. 124 The DOTS Server can share this information with the DOTS Client so 125 that the Client can better comprehend and evaluate the actual 126 mitigation realized. Both DOTS Client and DOTS Server can benefit 127 this information by presenting various information in relevant 128 management, reporting and portal systems. 130 "DOTS Telemetry" is defined as the collection of attributes 131 characterizing the actual attacks that have been detected and 132 mitigated. The DOTS Telemetry is an optional set of attributes that 133 can be signaled in the various DOTS protocol messages. The DOTS 134 Telemetry can be optionally sent from the DOTS Client to Server and 135 vice versa. 137 This document aims to define all the required DOTS Telemetry 138 attributes in order to use DOTS Signal and Data Channels for DOTS 139 Telemetry signaling. Due to the diversity of environments DOTS 140 Agents are designed to be integrated within, the DOTS Telemetry 141 attributes (all of them as a whole, or some of them) are not 142 mandatory fields in any type of DOTS protocol message. Nevertheless, 143 when DOTS Telemetry attributes are available to the DOTS Agent it MAY 144 signal the attributes in order to optimize the overall service 145 provisioned using DOTS. Other basic minimum set of DOTS mandatory 146 signaling attributes (like "targeted entity", Targeted IP address and 147 so on), that are covered in other DOTS documents, are not reiterated 148 in this document. No assumption is made regarding the DOTS 149 Telemetry's actual collection methodology. 151 The document is divided into three logical parts: The first outlines 152 the need for DOTS Telemetry. The second covers the actual telemetry 153 attributes needed for providing comprehensive mitigation services. 154 The third describes the telemetry attributes needed for each of the 155 DOTS Signaling stages. Several typical use cases are also discussed 156 in detail. 158 1.1. Requirements Language 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119 [RFC2119]. 164 1.2. Definition of Terms 166 This document uses the various terms defined in DOTS reuirements 167 document, see [I-D.ietf-dots-requirements]. 169 2. Using the DOTS telemetry for a successful mitigation 171 The cyber security battle between the adversary and security 172 countermeasures is an everlasting fight. The DoS/DDoS attacks have 173 become more vicious and sophisticated in almost all aspects of their 174 maneuvers and malevolent intentions. IT organizations and service 175 providers are facing DoS/DDoS attacks that fall into two broad 176 categories: Network/Transport layer attacks and Application layer 177 attacks. Network/Transport layer attacks target the victim's 178 infrastructure. These attacks are not necessarily aimed at taking 179 down the actual delivered services, but rather to eliminate various 180 network elements (routers, switches, FW, transit links, and so on) 181 from serving legitimate user traffic. Here the main method of the 182 attackers is to send a large volume or high PPS of traffic toward the 183 victim's infrastructure. Attack volumes may vary from a few 100 184 Mbps/PPS to 100s of Gbps or even Tbps. Attacks are commonly carried 185 out leveraging botnets and attack reflectors for amplification 186 attacks, such as NTP, DNS, SNMP, SSDP, and so on. Application layer 187 attacks target various applications. Typical examples include 188 attacks against HTTP/HTTPS, DNS, SIP, SMTP, and so on. However, all 189 valid applications with their ports open at network edges can be 190 attractive attack targets. Application layer attacks are considered 191 more complex and hard to categorize, therefore harder to detect and 192 mitigate efficiently. 194 To compound the problem, attackers also leverage multi-vectored 195 attacks. These merciless attacks are assembled from dynamic attack 196 vectors (Network/Application) and tactics. Here, multiple attack 197 vectors formed by multiple attack types and volumes are launched 198 simultaneously towards the victim. Multi-vector attacks are harder 199 to detect and defend. Multiple and simultaneous mitigation 200 techniques are needed to defeat such attack campaigns. It is also 201 common for attackers to change attack vectors only moments after a 202 successful mitigation, burdening their opponents with changing their 203 defense methods. 205 The ultimate conclusion derived from these real-life scenarios is 206 that modern attacks detection and mitigation are most certainly 207 complicated and highly convoluted tasks. They demand a comprehensive 208 knowledge of the attack attributes, the targeted normal behavior/ 209 traffic patterns, as well as the attacker's on-going and past 210 actions. Even more challenging, retrieving all the analytics needed 211 for detecting these attacks is not simple to obtain with the 212 industry's current capabilities. 214 With all this in mind, when signaling a mitigation request, it is 215 most certainly beneficial for the DOTS Client to signal to the DOTS 216 Server any knowledge regarding ongoing attacks. This can happen in 217 cases where DOTS Clients are asking the DOTS Server for support in 218 defending against attacks that they have already detected and/or 219 mitigated. These actions taken by DOTS Agent are referred to as 220 "signaling the DOTS Telemetry". If attacks are already detected and 221 categorized, the DOTS Server, and his associated mitigation services, 222 can proactively benefit this information and optimize the overall 223 service delivered. It is important to note that DOTS Client and 224 Server detection and mitigation approaches can be different, and can 225 potentially outcome different results and attack classifications. 226 Therefore, the DDOS mitigation service must treat the ongoing attack 227 details from the Client as hints, and cannot completely rely or trust 228 the attack details conveyed by the DOTS client. Nevertheless, the 229 DOTS Telemetry should support the identification of such misalignment 230 conditions. 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. They use the DOTS Telemetry to 236 be prepared for attack mitigation and to assign the correct resources 237 (operation staff, networking and mitigation) for the specific 238 service. Similarly, security operation personnel at the DOTS Client 239 side ask for feedback about their requests for protection. 240 Therefore, it is valuable for the DOTS Server to share DOTS Telemetry 241 with the DOTS Client. Thus mutual sharing of information is crucial 242 for "closing the mitigation loop" between the Client and Server. For 243 the Server side teams, it is important to realize that "the same 244 attacks that I am seeing are those that my client is asking me to 245 mitigate?." For the Client side, it is important to realize that the 246 Clients receive the required service. For example: understanding 247 that "I asked for mitigation of two attacks and my Server detects and 248 mitigates only one...". Cases of inconsistency in attack 249 classification between DOTS Client and Server can be high-lighted, 250 and maybe handled, using the DOTS Telemetry various attributes. 252 In addition, management and orchestration systems, at both Client and 253 Server side, can potentially use DOTS Telemetry as a feedback to 254 automate various control and management activities derived from 255 ongoing information signaled. 257 Should the DOTS Server's mitigation resources have the capabilities 258 to facilitate the DOTS Telemetry, the Server adopts its protection 259 strategy and activates the required countermeasures immediately. The 260 overall results of this adoption are optimized attack mitigation 261 decisions and actions. 263 The DOTS Telemetry can also be used to tune the mitigators with the 264 correct state of the attack. During the last few years, DDoS/DoS 265 attack detection technologies have evolved from threshold-based 266 detection (that is, cases when all or specific parts of traffic cross 267 a pre-defined threshold for a certain period of time is considered as 268 an attack) to an "anomaly detection" approach. In anomaly detection, 269 the main idea is to maintain rigorous learning of "normal" behavior 270 and where an "anomaly" (or an attack) is identified and categorized 271 based on the knowledge about the normal behavior and a deviation from 272 this normal behavior. Machine learning approaches are used such that 273 the actual "traffic thresholds" are "automatically calculated" by 274 learning the protected entity normal traffic behavior during peace 275 time. The normal traffic characterization learned is referred to as 276 the "normal traffic baseline". An attack is detected when the 277 victim's actual traffic is deviating from this normal baseline. 279 In addition, the subsequent activities toward mitigating the attack 280 are much more challenging. The ability to distinguish legitimate 281 traffic from attacker traffic on a per packet basis is complex. This 282 complexity originates in the fact that the packet itself may look 283 "legitimate" and no attack signature can be identified. The anomaly 284 can be identified only after detailed statistical analysis. DDoS/DoS 285 attack mitigators use the normal baseline during the actual 286 mitigation of an attack to identify and categorize the expected 287 appearance of a specific traffic pattern. Particularly the 288 mitigators use the normal baseline to recognize the "level of 289 normality" needs to be achieved during the various mitigation 290 process. 292 Normal baseline calculation is performed based on continuous learning 293 of the normal behavior of the protected entities. The minimum 294 learning period varies from hours to days and even weeks, depending 295 on the protected application behavior. The baseline cannot be 296 learned during active attacks because attack conditions do not 297 characterize the protected entities' normal behavior. 299 If the DOTS Client has calculated the normal baseline of its 300 protected entities, signaling this attribute to the DOTS Server along 301 with the attack traffic levels is significantly valuable. The DOTS 302 Server benefits from this telemetry by tuning its mitigation 303 resources with the DOTS Client's normal baseline. The mitigators use 304 the baseline to familiarize themselves with the attack victim's 305 normal behavior and target the baseline as the level of normality 306 they need to achieve. Consequently, the overall mitigation 307 performances obtained are dramatically improved in terms of time to 308 mitigate, accuracy, false-negative, false-positive, and other 309 measures. Mitigation of attacks without having certain knowledge of 310 normal traffic can be inaccurate at best. This is especially true 311 for DOTS environments where it is assumed that there is no universal 312 DDoS attack scale threshold triggering an attack across 313 administrative domains (see [I-D.ietf-dots-architecture]). In 314 addition, the highly diverse types of use-cases where DOTS Clients 315 are integrated also emphasize the need for knowledge of Client 316 behavior. Consequently, common global thresholds for attacks 317 detection practically cannot be realized. Each client can have his 318 own levels of traffic and normal behavior. Without facilitate 319 baseline signaling, it can be very difficult for Server to detect and 320 mitigate the attacks accurately. It is important to emphasize that 321 it is practically impossible for the Server's mitigators to calculate 322 the normal baseline, in cases they do not have any knowledge of the 323 traffic beforehand. In addition, baseline learning requires a period 324 of time that cannot be afforded during active attack. 326 As mentioned above, the task of isolating legitimate from attacker 327 traffic is extremely difficult to achieve. A common mechanism that 328 DDoS/DoS mitigators use to achieve such a distinction is to 329 authenticate source IP addresses that send traffic towards protected 330 entities. The source IP address can be authenticated as legitimate 331 or as a malicious BOT. Traffic from a BOT can be discarded or can be 332 rate-limited. Authentication can be performed using various 333 techniques; actively sending various challenges towards source IP 334 addresses is a common method. SYN Cookies, CAPTCHA, cryptographic 335 puzzle and others are examples of challenge-response tests used by 336 mitigators to determine whether the user is legitimate or a BOT. 337 Most certainly, building a list of authenticated source IP addresses 338 is a task that consumes resources and takes a long period of time to 339 construct. If the DOTS Client has already built a list of 340 authenticated IP addresses, the DOTS Server can use this list to 341 safely serve these IP addresses without any further need to re- 342 authenticate them. It is important to mention that "authenticated 343 IPs" are different from IP addresses in a "white list". This is 344 mainly because the authenticated IPs addresses are not predefined and 345 are not known upfront to the DOTS Agents. In addition, a source IP 346 address is treated as an authenticated IP address for a limited 347 period of time. 349 During a high volume attack, DOTS Client pipes can be totally 350 saturated. The Client asks the Server to handle the attack upstream 351 so that DOTS Client pipes return to a reasonable load level. At this 352 point, it is essential to ensure that the DOTS Server does not 353 overwhelm the DOTS Client pipes by sending back "clean traffic", or 354 what it believes is "clean". This can happen when the Server has not 355 managed to detect and mitigate all the attacks launched towards the 356 Client. In this case, it can be valuable to Clients to signal to 357 Server the "Total pipe capacity", which is the level of traffic the 358 Clients can absorb from the upstream Server. Dynamic updating of the 359 condition of pipes between DOTS Agents while they are under a DDoS 360 attack is essentially. For example, for cases of multiple DOTS 361 Clients share the same physical connectivity pipes. It is important 362 to note, that the term "pipe" noted here does not necessary represent 363 physical pipe, but rather represents the current level of traffic 364 Client can observe from Server. The Server should activate other 365 mechanisms to ensure it does not saturate the Client's pipes 366 unintentionally. The Rate Limiter can be a reasonable candidate to 367 achieve this objective; the Client can ask for the type of traffic 368 (such as ICMP, UDP, TCP port 80) it prefers to limit. 370 To summarize, timely and effective signaling of up-to-date DOTS 371 telemetry to all elements involved in the mitigation process is 372 essential and absolutely improves the overall service effectiveness. 373 Bi-directional feedback between DOTS elements is required for the 374 increased awareness of each party, supporting superior and highly 375 efficient attack mitigation service. 377 3. DOTS Telemetry attributes 379 This section outlines the set of DOTS Telemetry attributes. The 380 ultimate objective of these attributes is to allow for the complete 381 knowledge of attacks and the various particulars that can best 382 characterize attacks. This section presents the attributes required 383 for each stage of the DOTS Signaling protocol (see 384 [I-D.reddy-dots-signal-channel] and 385 [I-D.nishizuka-dots-inter-domain-mechanism]). Other way of using 386 telemetry attributes is allowing DOTS Server to receive relevant DOTS 387 Telemetry before the actual attacks are launched using the DOTS Data 388 Channel [I-D.reddy-dots-signal-channel]. 390 The description and motivation behind each attribute were presented 391 in previous sections in this document. The data model and the actual 392 integration within the DOTS Protocol are out of scope of this 393 document. It is expected that the following attributes will be 394 covered in any of the DOTS Protocol and DOTS Data Model standards. 395 As explained in previous sections, the DOTS Telemetry attributes are 396 optionally signaled and therefore SHOULD NOT be treated as mandatory 397 fields in any DOTS protocol messages. 399 3.1. Pre-mitigation DOTS Telemetry attributes 401 The Pre-mitigation telemetry attributes MAY be signaled from the DOTS 402 Client to the DOTS Server as part of the initiation of a DOTS service 403 request or during peace time using the DOTS Data Channel. Can be 404 signaled during a "Mitigation Request" (see also 405 [I-D.nishizuka-dots-inter-domain-mechanism]) session, or as part of 406 the "POST request" DOTS Signal (see also 407 [I-D.reddy-dots-signal-channel]). The following attributes are 408 required: 410 3.1.1. "Normal Baselines" of legitimate traffic 412 Average, x percentile and peak values of "Total traffic normal 413 baselines". PPS and BPS of the traffic are required. 415 [[EDITOR'S NOTE: We request feedback from the working group about 416 possible types of baselines to be signaled.]] 418 3.1.2. "Total Attack Traffic volume" 420 Current and peak values of "Total attack traffic". PPS and BPS of 421 attack traffic are required. 423 3.1.3. "Attack Details" 425 Various information and details that describe the on-going attacks 426 that need to be mitigated by the DOTS Server. The Attack Details 427 need to cover well-known and common attacks (such as a SYN Flood) 428 along with new emerging or vendor-specific attacks. The following is 429 a suggestion for the required fields in the Attack Details (this 430 definition follows the CEF Common Event Formula event definition, see 431 also [CEF] for more description): 433 Vendor |Version| Attack ID| Attack Name| Attack Severity| Extension 435 Where Extension is a placeholder for additional fields. Examples for 436 such fields are: Attack Classification, for example UDP port 80, 437 Layer 7 attack signature - Regex with Layer 7 attack signatures. 438 These can be defined as relevant key value pairs. Common and well- 439 known attack IDs SHOULD be standardized, and the vendor-specific IDs 440 SHOULD be specifically defined by each vendor. 442 The DOTS server should only treat the attack details as hints, and 443 not as a strict attribute to comply to. Please see requirement 444 OP-004 in [I-D.ietf-dots-requirements]. 446 [[EDITOR'S NOTE: We request feedback from the working group about 447 possible alternatives for presenting "Attack Details" and various 448 characteristics of attacks.]] 450 3.1.4. "Total pipe capacity" 452 The limit of traffic volume, in BPS and PPS. The DOTS Server SHALL 453 eliminate sending this back as clean traffic. This attribute 454 represents the DOTS Client's pipe limits. 456 3.1.5. List of already "Authenticated source IPs" 458 List of source IP addresses that the DOTS Client has already 459 identified as authenticated IP addresses. 461 [[EDITOR'S NOTE: We request feedback from the working group about the 462 way to support this kind of IP address list under various NAT 463 strategies deployed in the Client's network. The same support is 464 required for "white lists" and "black lists" referred to in several 465 DOTS drafts, see [I-D.reddy-dots-data-channel].]] 467 3.2. Client to Server Mitigation Status DOTS Telemetry attributes 469 The Mitigation Status telemetry attributes MAY be signaled from the 470 DOTS Client to the DOTS Server as part of the periodic mitigation 471 status update as realized by the Server. This can be signaled during 472 "Mitigation Efficacy Update" (see also 473 [I-D.nishizuka-dots-inter-domain-mechanism] session, or as part of 474 the - "PUT request" DOTS signal (see also 475 [I-D.reddy-dots-signal-channel]). 477 The following attributes are required: 479 3.2.1. Current "Total traffic volumes" 481 Current values of the total traffic, in BPS and PPS, that arrive at 482 the DOTS Client sites. In addition, the Peak and x percentile of 483 traffic, in BPS and PPS, MAY also be signaled. 485 3.2.2. Current "Total Attack Traffic" 487 The total attack traffic volume, bps and pps, that the DOTS Client 488 still sees during the active mitigation service. In addition, the 489 Peak and x percentile of traffic, in BPS and PPS, MAY also be 490 signaled. 492 3.2.3. "Mitigation Efficacy Factor" 494 A factor defining the overall Mitigation Efficacy from the Client 495 perspective. By way of suggestion, the Mitigation Efficacy Factor 496 can be defined as the current clean traffic ratio to the normal 497 baseline. Network and Application Performance Monitoring attributes 498 can also be considered here. 500 3.2.4. "Attack Details" 502 The overall attack details as observed from the DOTS Client 503 perspective. The same data models that will be defined for the Pre- 504 mitigation DOTS Telemetry can also be applicable here. 506 3.3. Server to Client Mitigation Status DOTS Telemetry attributes 508 The Mitigation Status telemetry attributes MAY be signaled from the 509 DOTS Server to the DOTS Client as part of the periodic mitigation 510 status update. This can be signaled during "Mitigation Status" (see 511 also [I-D.nishizuka-dots-inter-domain-mechanism] session, or as part 512 of the "GET request" DOTS Signal (see also 513 [I-D.reddy-dots-signal-channel]). 515 The following attributes are required: 517 3.3.1. Current "Mitigation Countermeasure status" 519 As defined in [I-D.ietf-dots-requirements], the actual mitigation 520 activities can include several countermeasure mechanisms. The DOTS 521 Server SHOULD signal the current operational status to each relevant 522 countermeasure. For example: Layer 4 mitigation active/inactive, 523 Layer 7 mitigation active/inactive, and so on. In addition to the 524 status of each countermeasure, the DOTS Server SHOULD also signal: A 525 list of attacks detected by each countermeasure, and the statistics 526 for each countermeasure: Number of bytes/packets for each attack 527 handled, clean traffic volumes, dropped traffic. 529 It is important to maintain the AttackID among all DOTS 530 communications. The DOTS Client can further use this information for 531 reporting and service fulfillment purposes. 533 4. DOTS Telemetry Use-cases 535 DOTS Telemetry can certainly improve numerous DOTS Signaling use 536 cases. Nevertheless, DOTS Telemetry can be most beneficial when 537 dealing with relatively complex use cases where the DOTS Client is 538 integrated into environments with advanced detection and mitigation 539 abilities. In this section, typical use-cases are presented. 540 However, this list of use cases does not eliminate many other 541 scenarios, where the DOTS Telemetry is the pivot in bringing in 542 valuable use cases. It is expected that the DOTS Telemetry notions 543 will be added to the DOTS use cases [I-D.ietf-dots-use-cases] 544 documant. 546 4.1. Hybrid anti-DoS services use-case 548 In this common use case, a large enterprise deploys DDoS/DoS 549 mitigators as "in-line" devices on all the enterprise Internet peers. 550 The enterprise's security and operations teams are aware that in 551 cases of a large volume of attacks their Internet links can get 552 saturated. Therefore, having "in-line" mitigation devices deployed 553 will not help them in maintaining the service level that their 554 organization must maintain. In addition, they understand that they 555 are not capable of operating all the required actions to mitigate 556 multi-vector attacks. For these solid reasons, the enterprise IT 557 decides to purchase MSP (Managed Security Services) for "on demand" 558 DDoS/DoS mitigation services from a MSP Cloud provider. As part of 559 the anti-DoS service delivery, the enterprise and the MSP Cloud 560 provider have agreed to the required SLA. Also, they deploy a DOTS 561 Client at the enterprise premises and the DOTS Server at the MSP 562 cloud. During peace time, the enterprise mitigators build the 563 enterprise protected service's normal baseline. In cases of attacks 564 that can be mitigated "on-prem", the enterprise is able to deal with 565 the attack with its own resources. Should the attack become a large 566 volume attack and or also become multi-vector, the Internet links of 567 the organization, or even the mitigator links, get saturated. The 568 DOTS Client signals the need for aid in mitigating the on-going 569 attacks from the MSP's DOTS Server. In order to fulfil his SLA, the 570 MSP uses the DOTS Telemetry it received from the Client to assign the 571 adequate mitigation resources, tune the mitigators with the normal 572 baseline, assign the appropriate personnel to handle the enterprise 573 attacks, and so forth. The enterprise's security and operations team 574 uses the DOTS Telemetry they received from their DOTS Client to get 575 visibility into the actual mitigation performed "on the cloud" and 576 makes sure the service is fulfilled as expected. 578 4.2. MSP to MSP anti-DoS services use-case 580 This use case can be treated as a continuation of the previous use 581 case. The MSP Cloud provider operation team realizes that they have 582 some serious difficulties at their data centers and they are no 583 longer capable of serving the enterprise attacks. A back-to-back 584 DOTS Gateway is implemented at the MSP Cloud to allow redirection of 585 the attack to another MSP Cloud provider for the purpose of attack 586 mitigation. The same processes for using DOTS Telemetry are taken 587 here to ensure continuous service delivery. The same is true for 588 visibility into the actual service provided to the enterprise and to 589 the primary MSP Cloud provider. 591 5. Acknowledgements 593 Thanks to Yotam Ben-Ezra and Dennis Usle from Radware for their 594 contribution, careful reading and feedback. 596 6. IANA Considerations 598 This memo includes no request to IANA. 600 7. Security Considerations 602 To Be Added. 604 8. References 606 8.1. Normative References 608 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 609 Requirement Levels", BCP 14, RFC 2119, 610 DOI 10.17487/RFC2119, March 1997, 611 . 613 8.2. Informative References 615 [CEF] ArcSight, Inc., "Common Event Format configuration 616 guide.", 2009, . 620 [I-D.ietf-dots-architecture] 621 Mortensen, A., Andreasen, F., Reddy, T., 622 christopher_gray3@cable.comcast.com, c., Compton, R., and 623 N. Teague, "Distributed-Denial-of-Service Open Threat 624 Signaling (DOTS) Architecture", draft-ietf-dots- 625 architecture-00 (work in progress), July 2016. 627 [I-D.ietf-dots-requirements] 628 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 629 Denial of Service (DDoS) Open Threat Signaling 630 Requirements", draft-ietf-dots-requirements-02 (work in 631 progress), July 2016. 633 [I-D.ietf-dots-use-cases] 634 Dobbins, R., Fouant, S., Migault, D., Moskowitz, R., 635 Teague, N., and L. Xia, "Use cases for DDoS Open Threat 636 Signaling", draft-ietf-dots-use-cases-01 (work in 637 progress), March 2016. 639 [I-D.nishizuka-dots-inter-domain-mechanism] 640 Nishizuka, K., Xia, L., Xia, J., Zhang, D., Fang, L., 641 christopher_gray3@cable.comcast.com, c., and R. Compton, 642 "Inter-domain cooperative DDoS protection mechanism", 643 draft-nishizuka-dots-inter-domain-mechanism-01 (work in 644 progress), July 2016. 646 [I-D.reddy-dots-data-channel] 647 Reddy, T., Wing, D., Boucadair, M., Nishizuka, K., and L. 648 Xia, "Distributed Denial-of-Service Open Threat Signaling 649 (DOTS) Data Channel", draft-reddy-dots-data-channel-00 650 (work in progress), August 2016. 652 [I-D.reddy-dots-signal-channel] 653 Reddy, T., Boucadair, M., Wing, D., and P. Patil, 654 "Distributed Denial-of-Service Open Threat Signaling 655 (DOTS) Signal Channel", draft-reddy-dots-signal-channel-01 656 (work in progress), September 2016. 658 Authors' Addresses 660 Ehud Doron 661 Radware Ltd. 662 Raoul Wallenberg Street 663 Tel-Aviv 69710 664 Israel 666 Email: ehudd@radware.com 667 Tirumaleswar Reddy 668 Cisco Systems, Inc. 669 Cessna Business Park, Varthur Hobli 670 Sarjapur Marathalli Outer Ring Road 671 Bangalore, Karnataka 560103 672 India 674 Email: tireddy@cisco.com 676 Flemming Andreasen 677 Cisco Systems, Inc. 678 USA 680 Email: fandreas@cisco.com 682 Liang Xia (Frank) 683 Huawei 684 101 Software Avenue, Yuhuatai District 685 Nanjing, Jiangsu 210012 686 China 688 Email: Frank.xialiang@huawei.com 690 Kaname Nishizuka 691 NTT Communications 692 GranPark 16F, 3-4-1 Shibaura, 693 Tokyo, Minato-ku 108-8118 694 Japan 696 Email: kaname@nttv6.jp