idnits 2.17.1 draft-hayashi-dots-dms-offload-usecase-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 (March 8, 2019) is 1875 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.nishizuka-dots-signal-control-filtering' is defined on line 313, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 331, but no explicit reference was found in the text == Unused Reference: 'RFC7049' is defined on line 341, but no explicit reference was found in the text == Outdated reference: A later version (-31) exists of draft-ietf-dots-data-channel-27 == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-20 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-30 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-17 == Outdated reference: A later version (-06) exists of draft-nishizuka-dots-signal-control-filtering-04 == Outdated reference: A later version (-04) exists of draft-reddy-dots-home-network-03 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS Y. Hayashi, Ed. 3 Internet-Draft NTT 4 Intended status: Informational K. Nishizuka, Ed. 5 Expires: September 9, 2019 NTT Communications 6 M. Boucadair, Ed. 7 Orange 8 March 8, 2019 10 DDoS Mitigation Offload: A DOTS Applicability Use Case 11 draft-hayashi-dots-dms-offload-usecase-00 13 Abstract 15 This document describes the applicability of DOTS to a DDoS 16 mitigation offload use case. This use case assumes that a DMS (DDoS 17 Mitigation System) whose utilization rate is high sends its blocked 18 traffic information to an orchestrator using DOTS protocols, then the 19 orchestrator requests forwarding nodes such as routers to filter the 20 traffic. Doing so enables service providers to mitigate DDoS attack 21 traffic automatically while ensuring interoperability and distributed 22 filter enforcement. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 9, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. DOTS Applicability to DDoS Mitigation Offload Use Case . . . 3 62 4.1. Component and Sequence Diagram . . . . . . . . . . . . . 3 63 4.2. Case: DOTS Request via Out-of-band Link . . . . . . . . . 5 64 4.3. Case: Mitigation Request via In-band Link . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 8.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 Volume-based distributed denial-of-service (DDoS) attacks such as DNS 76 amplification attacks are critical threats to be handled by service 77 providers. When such attacks occur, service providers have to 78 mitigate them immediately to protect or recover their services. 80 Therefore, for the service providers to immediately protect their 81 network services from DDoS attacks, DDoS mitigation needs to be 82 automated. To automate DDoS attack mitigation, it is desirable that 83 multi-vendor elements involved in DDoS attack detection and 84 mitigation collaborate and support standard interfaces to 85 communicate. 87 DDoS Open Threat Signaling (DOTS) is a set of protocols for real-time 88 signaling, threat-handling requests, and data between the multi- 89 vendor elements [I-D.ietf-dots-signal-channel] 90 [I-D.ietf-dots-data-channel]. This document describes an automated 91 DDoS Mitigation offload use case inherited from the DDoS 92 orchestration use case [I-D.ietf-dots-use-cases], which ambitions to 93 enable cost-effective DDoS Mitigation. 95 2. Terminology 97 The readers should be familiar with the terms defined in 98 [I-D.ietf-dots-requirements] [I-D.ietf-dots-use-cases] 100 In addition, this document uses the terms defined below: 102 Mitigation offload: Getting rid of a DMS's mitigation action and 103 assigning the action to another entity when the utilization rate 104 of the DMS reaches a given threshold. How such threshold is set 105 is deployment-specific. 107 Utilization rate: A scale to measure load of an entity such as link 108 utilization rate or CPU utilization rate. 110 3. The Problem 112 In general, DDoS countermeasures are divided into detection and 113 filtering, and detection is technically difficult. DDoS Mitigation 114 System (DMS) can detect attack traffic based on the technology of 115 their vendors, so service providers can increase DDoS countermeasure 116 level by deploying the DMS in their network. 118 However, the number/capacity of DMS instances that can be deployed in 119 a service providers network is limited due to equipment cost and 120 dimensioning matters. Thus, DMS's utilization rate can reach its 121 maximum capacity faster when the volume of DDoS attacks is enormous. 122 When the rate reaches maximum capacity, the mitigation strategy needs 123 to offload mitigation actions from the DMS to cost-effective 124 forwarding nodes such as routers. 126 4. DOTS Applicability to DDoS Mitigation Offload Use Case 128 This section does not consider deployments where the network 129 orchestrator and DMS are co-located. 131 4.1. Component and Sequence Diagram 133 Figures 1 and 2 show a component diagram and a sequence diagram of 134 the use case, respectively. 136 +--------------+ +-----------+ 137 | | | DDoS |+ 138 | Orchestrator |<-------| mitigation|| 139 | |S DOTS C| systems || 140 +--------------+ +-----------+| 141 | +----------+ 142 | e.g., BGP, BGP Flowspec 143 | 144 | +------------------+ 145 +->| Forwarding nodes |+ 146 +------------------+| 147 +-----------------+ 148 * C is for DOTS Client function 149 * S is for DOTS Server function 151 Figure 1: Component Diagram of DDoS Mitigation Offload Use Case 153 The component diagram shown in Figure 1 differs from that of DDoS 154 Orchestration usecase in [I-D.ietf-dots-use-cases] in some respects. 155 First, the DMS embeds a DOTS client to send DOTS requests to the 156 orchestrator. Second, the orchestrator sends a request to underlying 157 forwarding nodes to filter the attack traffic. 159 +------------+ +----------+ +------------+ 160 | | |DDoS |+ | Forwarding |+ 161 |Orchestrator| |Mitigation|| | Nodes || 162 | | |Systems || | || 163 +------------+ +----------+| +------------+| 164 | +----------+ +------------+ 165 | | | 166 | DOTS Request | | 167 |S<----------------------C| | 168 | | | 169 | e.g., BGP, BGP Flowspec | | 170 | Filter Attack Traffic | | 171 |-------------------------|------------->| 172 | | | 173 * C is for DOTS Client function 174 * S is for DOTS Server function 176 Figure 2: Sequence Diagram of DDoS Mitigation Offload Use Case 178 In this use case, it is assumed that volume based attack already hits 179 a network and attack traffic is detected and blocked by a DMS in the 180 network. When the volume-based attack becomes intense, DMS's 181 utilization rate can reach a certain threshold (e.g., maximum 182 capacity). Then, the DMS sends a DOTS request as offload request to 183 the orchestrator with the actions to enforce on the traffic. After 184 that, the orchestrator requests the forwarding nodes to filter attack 185 traffic by dissemination of flow specification rules protocols such 186 as BGP Flowspec [RFC5575] on the basis of the blocked traffic 187 information. 189 This use case is divided into two cases as discussed below. One is 190 that the DMS sends DOTS requests to the orchestrator via out-of-band 191 link, and the other one is that the DMS sends it via in-band link. 193 4.2. Case: DOTS Request via Out-of-band Link 195 In this case, the DMS sends a DOTS request to the orchestrator with 196 information of blocked traffic information by the DMS via out-of-band 197 link. The link is not congested when it is under volume attack-time, 198 so DOTS data channel [I-D.ietf-dots-data-channel] is suitable because 199 DOTS data channel has capability of conveying the drop-listed 200 filtering rules (and other actions such as 'rate-limit'). The 201 applicability of DOTS in such case is as follows: 203 o The DMS generates a list of flow tuples (e.g., 5-tuples) which the 204 DMS is blocking/rate-limiting and wants to offload. 206 o The DMS creates ACEs for each elements of the list, setting 207 "matches" as the flow tuple and "forwarding" in "actions" as 208 "drop" (or other actions). 210 o The DMS aggregates the ACEs under an ACL set, and the DMS sends 211 the ACL to the orchestrator setting "activation-type" as 212 "immediate". 214 Figure 3 shows a JSON example of ACL conveyed by DOTS data channel. 216 { 217 "ietf-dots-data-channel:acls": { 218 "acl": [ 219 { 220 "name": "DMS_Offload_Usecase_ACL", 221 "type": "ipv4-acl-type", 222 "activation-type": "immediate", 223 "aces": { 224 "ace": [ 225 { 226 "name": "DMS_Offload_Usecase_ACE_00", 227 "matches": { 228 "ipv4": { 229 "destination-ipv4-network": "192.0.2.2/32", 230 "source-ipv4-network": "203.0.113.2/32", 231 "protocol":17 232 }, 233 "udp": { 234 "source-port": { 235 "operator": "eq", 236 "port": 53 237 } 238 } 239 }, 240 "actions": { 241 "forwarding": "drop" 242 } 243 } 244 ] 245 } 246 } 247 ] 248 } 249 } 251 Figure 3: JSON Example of ACL conveyed by DOTS data channel 253 4.3. Case: Mitigation Request via In-band Link 255 In this case, the DMS sends a mitigation request to the orchestrator 256 with information of blocked traffic by the DMS via in-band channel. 257 The link can be congested when it is under volume attack-time, so 258 DOTS data channel can't be used to convey the drop-listed filtering 259 rules as blocked traffic information [Interop]. 261 The DOTS signal channel and [I-D.ietf-dots-signal-channel] and the 262 source-* clauses defined in [I-D.reddy-dots-home-network] are used to 263 communicate the policies to the orchestrator. 265 <<>>> 267 5. Security Considerations 269 Security considerations discussed in [I-D.ietf-dots-data-channel] and 270 [I-D.ietf-dots-signal-channel] are to be taken into account. 272 6. IANA Considerations 274 This document does not require any action from IANA. 276 7. Acknowledgement 278 Thanks to Tirumaleswar Reddy, Shunsuke Homma for the comments. 279 Thanks to Koichi Sakurada for demonstrating proof of concepts of this 280 use case. 282 8. References 284 8.1. Normative References 286 [I-D.ietf-dots-data-channel] 287 Boucadair, M. and R. K, "Distributed Denial-of-Service 288 Open Threat Signaling (DOTS) Data Channel Specification", 289 draft-ietf-dots-data-channel-27 (work in progress), 290 February 2019. 292 [I-D.ietf-dots-requirements] 293 Mortensen, A., K, R., and R. Moskowitz, "Distributed 294 Denial of Service (DDoS) Open Threat Signaling 295 Requirements", draft-ietf-dots-requirements-20 (work in 296 progress), February 2019. 298 [I-D.ietf-dots-signal-channel] 299 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 300 Teague, "Distributed Denial-of-Service Open Threat 301 Signaling (DOTS) Signal Channel Specification", draft- 302 ietf-dots-signal-channel-30 (work in progress), March 303 2019. 305 [I-D.ietf-dots-use-cases] 306 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 307 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 308 Open Threat Signaling", draft-ietf-dots-use-cases-17 (work 309 in progress), January 2019. 311 8.2. Informative References 313 [I-D.nishizuka-dots-signal-control-filtering] 314 Nishizuka, K., Boucadair, M., K, R., and T. Nagata, 315 "Controlling Filtering Rules Using DOTS Signal Channel", 316 draft-nishizuka-dots-signal-control-filtering-04 (work in 317 progress), February 2019. 319 [I-D.reddy-dots-home-network] 320 K, R., Harsha, J., Boucadair, M., and J. Shallow, "Denial- 321 of-Service Open Threat Signaling (DOTS) Signal Channel 322 Call Home", draft-reddy-dots-home-network-03 (work in 323 progress), December 2018. 325 [Interop] Nishizuka, K., Shallow, J., and L. Xia , "DOTS Interop 326 test report, IETF 103 Hackathon", November 2018, 327 . 331 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 332 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 333 DOI 10.17487/RFC4271, January 2006, 334 . 336 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 337 and D. McPherson, "Dissemination of Flow Specification 338 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 339 . 341 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 342 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 343 October 2013, . 345 Authors' Addresses 347 Yuhei Hayashi (editor) 348 NTT 349 3-9-11, Midori-cho 350 Musashino-shi, Tokyo 180-8585 351 Japan 353 Email: yuuhei.hayashi@gmail.com, yuuhei.hayashi.mr@hco.ntt.co.jp 354 Kaname Nishizuka (editor) 355 NTT Communications 356 GranPark 16F 3-4-1 Shibaura, Minato-ku 357 Tokyo 108-8118 358 Japan 360 Email: kaname@nttv6.jp 362 Mohamed Boucadair (editor) 363 Orange 364 Rennes 35000 365 France 367 Email: mohamed.boucadair@orange.com