idnits 2.17.1 draft-chen-dots-server-hierarchical-deployment-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (June 24, 2020) is 1402 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-dots-multihoming-04 == Outdated reference: A later version (-15) exists of draft-ietf-dots-server-discovery-10 == Outdated reference: A later version (-14) exists of draft-ietf-dots-signal-call-home-08 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-23 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS M. Chen 3 Internet-Draft Li. Su 4 Intended status: Informational China Mobile 5 Expires: December 26, 2020 June 24, 2020 7 A method for dots server deployment 8 draft-chen-dots-server-hierarchical-deployment-03 10 Abstract 12 As DOTS is used for DDoS Mitigation signaling, there are different 13 deployment scenarios for DOTS agents deployment depending on the 14 network topology. This document made recommandations for DOTS Server 15 deployment, include ISP and enterprise deployment scenarios. The 16 goal is to provide some guidance for DOTS agents deployment. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 26, 2020. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. DOTS server Considerations . . . . . . . . . . . . . . . . . 3 55 4. DOTS server deployment inside an ISP . . . . . . . . . . . . 4 56 4.1. DOTS Agents Deployment . . . . . . . . . . . . . . . . . 4 57 4.2. DOTS Agents interfaces . . . . . . . . . . . . . . . . . 7 58 4.2.1. Bandwidth consuming attack . . . . . . . . . . . . . 8 59 4.2.2. Host resource consuming attack . . . . . . . . . . . 8 60 5. DOTS server deployment between ISPs . . . . . . . . . . . . . 8 61 6. DOTS server deployment for Enterprise . . . . . . . . . . . . 9 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 67 10.2. Informative References . . . . . . . . . . . . . . . . . 11 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 70 1. Introduction 72 DDoS Open Threat Signaling (DOTS) is a protocol to standardize real- 73 time signaling, threat-handling 74 requests[I-D.ietf-dots-signal-channel], when attack target is under 75 attack, dots client send mitigation request to dots server for help, 76 If the mitigation request contains enough messages of the attack, 77 then the mitigator can respond very effectively. 79 In the architecture draft[I-D.ietf-dots-architecture], when comes to 80 the deployment topic, it says this does not necessarily imply that 81 the attack target and the DOTS client have to be co-located in the 82 same administrative domain, but it is expected to be a common 83 scenario. Although co-location of DOTS server and mitigator within 84 the same domain is expected to be a common deployment model, it is 85 assumed that operators may require alternative models. 87 In the DOTS server discovery draft[I-D.ietf-dots-server-discovery], 88 it is says that a key point in the deployment of DOTS is the ability 89 of network operators to be able to configure DOTS clients with the 90 correct DOTS server(s) information consistently. 92 In the DOTS multihoming draft[I-D.ietf-dots-multihoming], it provides 93 deployment recommendations for DOTS client and DOTS gateway, it is 94 says when conveying a mitigation request to protect the attack 95 target, the DOTS client among the DOTS servers available Must select 96 a DOTS server whose network has assigned the prefixes from which 97 target prefixes and target IP addresses are derived. This implies 98 that id no appropriate DOTS server is found, the DOTS client must not 99 send the mitigation request to any DOTS server. So in this document, 100 we give some dots server deployment consideration as the title 101 suggests we prefer hierarchical deployment. 103 This is DOTS server deployment guidance for operators, We've written 104 about our experience as an ISP, and we hope that other scenarios will 105 contribute as well. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in 112 [RFC2119] 114 The readers should be familiar with the terms defined in 115 [I-D.ietf-dots-requirements] [I-D.ietf-dots-use-cases] 117 The terminology related to YANG data modules is defined in [RFC7950] 119 In addition, this document uses the terms defined below: 121 dots svr: abbreviation of dots server. 123 ISP: Internet service provider. 125 Orchestrator: With the function of DOTS server that can receive 126 messages from clients and made decisions for mitigators selection. 128 netflow/ipfix collector: Flow collector used for DDoS attack 129 detection. 131 3. DOTS server Considerations 133 When take dots server deployment into consideration, one thing must 134 be involved is mitigator that can provide DDoS mitigation service. 135 So far, how many network devices can play the role of mitigator, we 136 make a summerized list as follows: 138 o Router. 140 o Special cleaning equipment, such as flow clean device and clean 141 center. 143 o Network security equipment, such as firewall, IPS and WAF. 145 o Servers that websites can hidden behind them. 147 There are several requirements for DOTS server deployment that may be 148 , and is consistent with other drafts: 150 o DOTS server and mitigator are in the same administrative domain. 152 o DOTS server can go directly to the mitigator which had best go 153 through without any other DOTS agents. 155 o DOTS server has the permissions for scheduling on mitigators. 157 o DOTS server has the ability to know the address of attack target 158 belong to which mitigator, if DOTS server hasn't matched attack 159 target to mitigators, DOTS server need to configure default 160 mitigators. 162 4. DOTS server deployment inside an ISP 164 4.1. DOTS Agents Deployment 166 From the internal structure of ISP, the whole network can abstract as 167 a three-level network logically. The hierarchy of the network can be 168 adjusted according to the size of the network. In addition to having 169 its own business, the upper network is responsible for connectivity 170 between the lower networks. It's worth noting that there are usually 171 Internet Data Centers(IDC), high bandwidth demand customers(such as 172 online game companies) and VIP customer centers(such as financial 173 clients) distributed in each level network, but most of these 174 services are typically placed on a secondary network. 176 /<===>Mitigator 177 __(RT)___ 178 / \ 179 / primary \ 180 ---------------- 181 | 182 / \ 183 / \ /<===>Mitigator 184 _______ _(RT)_ 185 / \ / \ 186 / Second \ / Second \ 187 ----------- ---------- 188 / / \ 189 /<==>Mitigator / \ 190 _(RT) ___ _(RT) 191 / \ / \ / \ 192 / Third \ /Third\ /Third \ 193 --------- ------- -------- 194 Figure 1: ISP multilevel network 196 There are mitigators such as cleaning centers in each regional 197 network. Select the second level network for detailed description, 198 the cleaning equipment is attached to the exit router, and Detector 199 is concatenated on the link, usually detector could be one type of 200 netflow/ipfix collector, sometimes could be firewall or IDS(Intrusion 201 Detection System), they could able to find some types of DDoS 202 attacks. Attacks from two different sources occur inside the Second 203 network as follows: 205 (Router)<=====>Flow Clean Device 206 ^^ 207 ||(Detector) 208 ________||__________ 209 ( || ) 210 ( #IDC# ++<<<<<>>>>>>++ 218 Figure 2:Two DDoS attack paths 220 There are only two attack source paths under this structure: One is 221 an attack launched within the network, flowing to the upper level of 222 the network. The other is that low-level networks launch attacks and 223 flow to the upper level of networks, and pass through the 224 intermediate level network. Internal DDoS attacks is out of scope in 225 this draft. 227 In this case, DOTS clients might consider to be deployed internally. 228 When DDoS attack occurs, attack target inside the Second network may 229 sense being attacked, such as customer complaints and the processing 230 speed is slower than before. attack target then inform Detector(DOTS 231 client) making mitigation request to DOTS server(Router), and the 232 traffic mitigation is then triggered. DOTS server and Mitigator are 233 in the same administrative domain. 235 (The Secondary network) 237 ^ 238 || 239 (Router)<=====>Flow Clean Device 240 (DOTS Server) (Mitigator) 241 ^ 242 || 243 |/ 244 (DOTS Client) 245 Detector 246 ________||__________ 247 ( || 1 ) 248 ( #IDC# ++<<<<<>>>>>>++ 257 Figure 3: DOTS Agents Deployment 259 When DDoS Attack path case 1 occurs, the DOTS client in the same 260 network will send mitigation requests to DOTS server which installed 261 in the same area within export router. 263 When DDoS Attack path case 2 occurs, the Dots server in the Third 264 network export router will receive mitigation request. If the first 265 level of protection is not effective enough, the DOTS server in the 266 upper network will also receive mitigation requests. 268 If attacks on the same attack target are found both in adjacent 269 areas, there are two strategies for the mitigators' selection, then 270 found the best mitigation node for different scenes. 272 o Near Attack Source Mitigation(NASM), NASM means that the 273 mitigation is performed closest to the source of the attack, this 274 usually happens at the entrance to the edge of the network. This 275 approach can block attack flow at the source and protect network 276 bandwidth maximumly, but requires the ability to operate the 277 entire network. This principle is more suitable for large-traffic 278 attack mitigation. 280 o Near Attack Target Mitigation(NATM), NATM means that the 281 mitigation is performed closest to the attack target, This is the 282 easiest and most direct way, but it will cause the attack flow 283 long-distance transmission, occupy the bandwidth along the link, 284 more likely to cause link congestion. This principle is more 285 suitable for low-traffic attack mitigation. 287 Normally, The lower network the target in, the easier it is to alert. 288 Because the higher network the attack target in, the greater the 289 bandwidth of the pipeline. When multiple mitigators need to work 290 together, then need orchestrator to take on the role for scheduling. 291 Because the importance of the orchestrator, it is suggested to 292 consider bakeup mechanisms or heartbeat technology to ensure 293 continuity and security. 295 How does DOTS client can find DOTS servers, we can reference the DOTS 296 server discovery draft[I-D.ietf-dots-server-discovery], Static 297 configuration or dynamic discovery depends on the actual scenario and 298 the size of the network. 300 4.2. DOTS Agents interfaces 302 In the dots use case draft[I-D.ietf-dots-use-cases], it is says the 303 orchestrator analyses the various information it receives from DDoS 304 telemetry system, and initiates one or multiple DDoS mitigation 305 strategies. In the telemetry draft, all the telemetry informations 306 are contained and some parameters can be used to make decisions. 307 This section made a discussion on which attributes could be used in 308 orchestrator for scheduling. 310 We suggest orchestrator has three capabilities and reuse the method 311 of registration and notification in signal channel to know all the 312 related mitigators capability and residue capability: 314 1.Can get the neflow/ipfix collector's telemetry informations. 316 2.Can get the capabilities of each mitigator, it means the initial 317 capacity, this means that with each addition of mitigator there needs 318 to be a protocol that can push this information to orchestrator, we 319 recommend using DOTS signal channel to transfer initial capacity. 321 3.When mitigation finished, mitigator can inform orchestrator that 322 mitigation is finished and capacity has been released, also we 323 recommend using DOTS signal channel to transfer. 325 4.2.1. Bandwidth consuming attack 327 The following parameters will be required by orchestrator: 329 o top-talker 331 o source-prefix 333 o total-traffic 335 o total-attack-traffic 337 o total-pipe-capability 339 The recommended approach here is to redirect traffic and flow 340 cleaning. 342 4.2.2. Host resource consuming attack 344 The following parameters will be required by orchestrator: 346 o top-talker 348 o source-prefix 350 The recommended approach here is to use router for disposition. 352 5. DOTS server deployment between ISPs 354 Because of global connectivity, the coexistence of different 355 operators is very common, coordination between operators across 356 networks is very important. Interdomain attacks occur frequently, We 357 recommend deploying the DOTS server at the access point. 359 o DDoS attack from one of other ISPs, for example, ISP A received 360 DDoS attack from ISP B or ISP C, then dots server inside ISP B or 361 ISP C will receive the mitigation requests. 363 o DDoS attacks from two or more of other ISPs,for example, ISP A and 364 ISP B both start ddos attack to ISP C, then dots server A and dots 365 server B will both receive mitigation request from dots client C. 367 +-------------+ +-------------+ 368 | ISP A | | ISP B | 369 | +---------+ | | +---------+ | 370 | C/S | | C/S | 371 +-------------+ +-------------+ 372 | | 373 +---------------------------+ 374 | 375 | 376 +-------------+ 377 | C/S | 378 | +---------+ | 379 | ISP C | 380 +-------------+ 381 Figure 4: DOTS Agents Deployment between ISPs 383 When an DDoS attack occurs, depending on the direction of the attack, 384 the corresponding server is required for mitigation, DOTS server can 385 use call home to find the source of the DDoS 386 attacks[I-D.ietf-dots-signal-call-home] 388 6. DOTS server deployment for Enterprise 390 In addition to operators taking advantage of the pipeline to make a 391 contribution to DDoS attack mitigation, there are also enterprise- 392 level DDoS attack mitigation solutions. It's usually a cloud service 393 and a large number of distributed nodes are deployed to protect their 394 customers from DDoS attack, customers' websites can be hidden behind 395 the nodes, usually the internet game companies and the live streaming 396 company will choose this way. 398 +-------------+ 399 | ISP | 400 | +---------+ | 401 | |dots svr | | 402 +-------------+ 403 | 404 | 405 +-------------+ 406 | Anti-D Node | 407 +-------------+ 408 |dots client| 409 +-----------+ 410 | 411 | 412 +-------------+ 413 |attack target| 414 +-------------+ 416 *Anti-D is for Anti-DDoS 418 Figure 5: Deployment for Enterprise and ISP 420 When enterprise-level anti-DDos nodes are unable to mitigate the DDoS 421 attack, they can trigger DOTS client which integrated in the Anti-D 422 Node to send mitigation request to ISP's DOTS server. 424 7. Security Considerations 426 TBD 428 8. IANA Considerations 430 TBD 432 9. Acknowledgement 434 TBD 436 10. References 438 10.1. Normative References 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, 442 DOI 10.17487/RFC2119, March 1997, 443 . 445 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 446 RFC 7950, DOI 10.17487/RFC7950, August 2016, 447 . 449 10.2. Informative References 451 [I-D.ietf-dots-architecture] 452 Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and 453 R. Compton, "Distributed-Denial-of-Service Open Threat 454 Signaling (DOTS) Architecture", draft-ietf-dots- 455 architecture-18 (work in progress), March 2020. 457 [I-D.ietf-dots-multihoming] 458 Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing 459 Deployment Considerations for Distributed-Denial-of- 460 Service Open Threat Signaling (DOTS)", draft-ietf-dots- 461 multihoming-04 (work in progress), May 2020. 463 [I-D.ietf-dots-requirements] 464 Mortensen, A., K, R., and R. Moskowitz, "Distributed 465 Denial of Service (DDoS) Open Threat Signaling 466 Requirements", draft-ietf-dots-requirements-22 (work in 467 progress), March 2019. 469 [I-D.ietf-dots-server-discovery] 470 Boucadair, M. and T. Reddy.K, "Distributed-Denial-of- 471 Service Open Threat Signaling (DOTS) Agent Discovery", 472 draft-ietf-dots-server-discovery-10 (work in progress), 473 February 2020. 475 [I-D.ietf-dots-signal-call-home] 476 Reddy.K, T., Boucadair, M., and J. Shallow, "Distributed 477 Denial-of-Service Open Threat Signaling (DOTS) Signal 478 Channel Call Home", draft-ietf-dots-signal-call-home-08 479 (work in progress), March 2020. 481 [I-D.ietf-dots-signal-channel] 482 Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and 483 N. Teague, "Distributed Denial-of-Service Open Threat 484 Signaling (DOTS) Signal Channel Specification", draft- 485 ietf-dots-signal-channel-41 (work in progress), January 486 2020. 488 [I-D.ietf-dots-use-cases] 489 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 490 L., and K. Nishizuka, "Use cases for DDoS Open Threat 491 Signaling", draft-ietf-dots-use-cases-23 (work in 492 progress), May 2020. 494 Authors' Addresses 496 Meiling Chen 497 China Mobile 499 32, Xuanwumen West 501 BeiJing 502 , 503 BeiJing 505 100053 507 China 509 Email: 510 chenmeiling@chinamobile.com 512 Li Su 513 China Mobile 515 32, Xuanwumen West 517 BeiJing 519 100053 521 China 523 Email: 524 suli@chinamobile.com