idnits 2.17.1 draft-chen-dots-server-hierarchical-deployment-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 doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (March 9, 2020) is 1508 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-15 == Outdated reference: A later version (-13) exists of draft-ietf-dots-multihoming-03 == 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-07 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-20 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 M. Chen 3 Internet-Draft Li. Su 4 Intended status: Informational China Mobile 5 Expires: September 10, 2020 March 9, 2020 7 A method for dots server deployment 8 draft-chen-dots-server-hierarchical-deployment-02 10 Abstract 12 As DOTS is used for DDoS Mitigation signaling, in practice, there are 13 different deployment scenarios for DOTS agents deployment depending 14 on the network deployment mode. This document made an recommandation 15 for DOTS Server deployment, include ISP and enterprise deployment 16 scenarios. The goal is to provide some guidance for DOTS agents 17 deployment. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 10, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. DOTS server Considerations . . . . . . . . . . . . . . . . . 3 56 4. DOTS server deployment inside an ISP . . . . . . . . . . . . 4 57 4.1. DOTS Agents Deployment . . . . . . . . . . . . . . . . . 4 58 4.2. DOTS Agents interfaces . . . . . . . . . . . . . . . . . 6 59 4.2.1. Bandwidth consuming attack . . . . . . . . . . . . . 7 60 4.2.2. Host resource consuming attack . . . . . . . . . . . 7 61 5. DOTS server deployment between ISPs . . . . . . . . . . . . . 8 62 6. DOTS server deployment for Enterprise . . . . . . . . . . . . 9 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 68 10.2. Informative References . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction 73 DDoS Open Threat Signaling (DOTS) is a protocol to standardize real- 74 time signaling, threat-handling 75 requests[I-D.ietf-dots-signal-channel], when attack target is under 76 attack, dots client send mitigation request to dots server for help, 77 If the mitigation request contains enough messages of the attack, 78 then the mitigator can respond very effectively. 80 In the architecture draft[I-D.ietf-dots-architecture], when comes to 81 the deployment topic, it says this does not necessarily imply that 82 the attack target and the DOTS client have to be co-located in the 83 same administrative domain, but it is expected to be a common 84 scenario. Although co-location of DOTS server and mitigator within 85 the same domain is expected to be a common deployment model, it is 86 assumed that operators may require alternative models. 88 In the DOTS server discovery draft[I-D.ietf-dots-server-discovery], 89 it is says that a key point in the deployment of DOTS is the ability 90 of network operators to be able to configure DOTS clients with the 91 correct DOTS server(s) information consistently. 93 In the DOTS multihoming draft[I-D.ietf-dots-multihoming], it provides 94 deployment recommendations for DOTS client and DOTS gateway, it is 95 says when conveying a mitigation request to protect the attack 96 target, the DOTS client among the DOTS servers available Must select 97 a DOTS server whose network has assigned the prefixes from which 98 target prefixes and target IP addresses are derived. This implies 99 that id no appropriate DOTS server is found, the DOTS client must not 100 send the mitigation request to any DOTS server. So in this document, 101 we give some dots server deployment consideration as the title 102 suggests we prefer hierarchical deployment. 104 This is DOTS server deployment guidance for operators, We've written 105 about our experience as an ISP, and we hope that other scenarios will 106 contribute as well. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in 113 [RFC2119] 115 The readers should be familiar with the terms defined in 116 [I-D.ietf-dots-requirements] [I-D.ietf-dots-use-cases] 118 The terminology related to YANG data modules is defined in [RFC7950] 120 In addition, this document uses the terms defined below: 122 dots svr: abbreviation of dots server. 124 ISP: Internet service provider. 126 Orchestrator: With the function of DOTS server that can receive 127 messages from clients and made decisions for mitigators selection. 129 netflow/ipfix collector: Flow collector used for DDoS attack 130 detection. 132 3. DOTS server Considerations 134 When take dots server deployment into consideration, one thing must 135 be involved is mitigator. So far, how many network devices can play 136 the role of mitigator, we 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 Whether DOTS server can be deployed, the following conditions need to 148 be met: 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 divide into 167 backbone and metropolitan area networks logically. There are two 168 most important routers: backbone router, man(metropolitan area 169 network) router. It's worth noting that there are usually Internet 170 Data Centers(IDC), high bandwidth demand customers(such as online 171 game companies) and VIP customer centers(such as financial clients) 172 distributed in metropolitan area networks. When a ddos attack 173 occurs, it must be one of the three cases as follows, and the 174 corresponding mitigator will responsible for mitigation. 176 o DDoS attacks occur inside the LAN or the attack source inside 177 metropolitan area network launched an attack against the target in 178 local area network, the lan network detected the attack, dots 179 server3 will receive mitigation request, and mitigator3 will act 180 as the first responsible mitigator. 182 o DDoS attacks occur inside the MAN or the attack source inside 183 backbone network launched an attack against the target in 184 metropolitan area network, the man network detected the attack, 185 dots server2 will receive mitigation request, then mitigator2 will 186 act as the first responsible mitigator. 188 o DDoS attacks from other ISPs, the backbone network detected the 189 attack, dots server1 will receive mitigation request, then 190 mitigator1 will act as the first responsible mitigator. 192 If attacks on the same attack target are found both in adjacent 193 areas, there are two strategies for the mitigators' selection, then 194 found the best mitigation node for different scenes. 196 o Near Attack Source Mitigation(NASM), NASM means that the 197 mitigation is performed closest to the source of the attack, this 198 usually happens at the entrance to the edge of the network. This 199 approach can block attack flow at the source and protect network 200 bandwidth maximumly, but requires the ability to operate the 201 entire network. This principle is more suitable for large-traffic 202 attack mitigation. 204 o Near Attack Target Mitigation(NATM), NATM means that the 205 mitigation is performed closest to the attack target, This is the 206 easiest and most direct way, but it will cause the attack flow 207 long-distance transmission, occupy the bandwidth along the link, 208 more likely to cause link congestion. This principle is more 209 suitable for low-traffic attack mitigation. 211 According to the NATM, the lower network mitigator will act as the 212 first responsible mitigator. for example, dots server1 and dots 213 server2 both received the mitigation request from attack target by 214 dots client, mitigator2 will responsible for ddos 215 disposition(priority ranking: mitigator3, mitigator2, mitigator1), 216 but according to the NASM the priority will be reverse. 218 Normally, The lower network the target in, the easier it is to alert. 219 Because the higher network the attack target in, the greater the 220 bandwidth of the pipeline. As shown in the following figure, 221 Orchestrator take on the role for scheduling. Because the importance 222 of the orchestrator, it is suggested to consider bakeup mechanisms or 223 heartbeat technology to ensure continuity and security. 225 How does DOTS client can find DOTS servers, we can reference the DOTS 226 server discovery draft[I-D.ietf-dots-server-discovery], Static 227 configuration or dynamic discovery depends on the actual scenario and 228 the size of the network. 230 +----------+ 231 |other ISPs| 232 +----------+ 233 | 234 +-----------+ 235 |dots client| 236 ======|========================== 237 | Backbone Network 238 +---------------+ +----------+ 239 |backbone router|-----|mitigator1| 240 +---------------+ +----------+ 241 |dots svr1| 242 +---------+ 243 ........|........................ 244 | MAN 245 +----------+ +----------+ 246 |man router|-------|mitigator2| 247 +----------+ +----------+ 248 |dots svr2| 249 +---------+ 250 .......|........................ 251 | LAN 252 +----------+ +----------+ 253 |IDC router|------|mitigator3| 254 +----------+ +----------+ 255 |dots svr3| 256 +------------+ 257 |Orchestrator| 258 +------------+ 259 | 260 +-----------+ +--------------+ +-------------+ 261 |dots client|----|flow collector|---|attack target| 262 +-----------+ +--------------+ +-------------+ 264 *MAN is for metropolitan area network 265 *LAN is for local area network 266 *flow collector is for netflow/ipfix collector 268 Figure 1: hierarchical deployment for DOTS servers 270 4.2. DOTS Agents interfaces 272 In the dots use case draft[I-D.ietf-dots-use-cases], it is says the 273 orchestrator analyses the various information it receives from DDoS 274 telemetry system, and initiates one or multiple DDoS mitigation 275 strategies. In the telemetry draft, all the telemetry informations 276 are contained and some parameters can be used to make decisions. 278 This section made a discussion on which attributes could be used in 279 orchestrator for scheduling. 281 We suggest orchestrator has three capabilities and reuse the method 282 of registration and notification in signal channel to know all the 283 related mitigators capability and residue capability: 285 1.Can get the neflow/ipfix collector's telemetry informations. 287 2.Can get the capabilities of each mitigator, it means the initial 288 capacity, this means that with each addition of mitigator there needs 289 to be a protocol that can push this information to orchestrator, we 290 recommend using DOTS signal channel to transfer initial capacity. 292 3.When mitigation finished, mitigator can inform orchestrator that 293 mitigation is finished and capacity has been released, also we 294 recommend using DOTS signal channel to transfer. 296 4.2.1. Bandwidth consuming attack 298 The following parameters will be required by orchestrator: 300 o top-talker 302 o source-prefix 304 o total-traffic 306 o total-attack-traffic 308 o total-pipe-capability 310 The recommended approach here is to redirect traffic and flow 311 cleaning. 313 4.2.2. Host resource consuming attack 315 The following parameters will be required by orchestrator: 317 o top-talker 319 o source-prefix 321 The recommended approach here is to use router for disposition. 323 5. DOTS server deployment between ISPs 325 Because of global connectivity, the coexistence of different 326 operators is very common, coordination between operators across 327 networks is very important. Interdomain attacks occur frequently, We 328 recommend deploying the DOTS server at the access point. 330 o DDoS attack from one of other ISPs, for example, ISP A received 331 DDoS attack from ISP B or ISP C, then dots server C or dots server 332 B will receive the mitigation request. 334 o DDoS attacks from two or more of other ISPs,for example, ISP A and 335 ISP B both start ddos attack to ISP C, then dots server A and dots 336 server B will both receive mitigation request from dots client C. 338 +-------------+ +-------------+ 339 | ISP A | | ISP B | 340 | +---------+ | | +---------+ | 341 | |dots svrA| | | |dots svrB| | 342 +-------------+ +-------------+ 343 | | 344 +-------+===========+-------+ 345 |dots client| 346 +===========+ 347 | 348 | 349 +-------------+ 350 | |dots svrC| | 351 | +---------+ | 352 | ISP C | 353 +-------------+ 355 Figure 2: DOTS Server Deployment between different ISPs 357 It is obvious from the figure 2 that there is a super DOTS client in 358 the middle, this also means that there will be corresponding netflow/ 359 ipfix collector on the link between different ISPs, the final 360 location of the DOTS client according to the actual network topology. 361 When an DDoS attack occurs, depending on the direction of the attack, 362 the corresponding server is required for mitigation, DOTS server can 363 use call home to find the source of the DDoS 364 attacks[I-D.ietf-dots-signal-call-home] 366 6. DOTS server deployment for Enterprise 368 In addition to operators taking advantage of the pipeline to make a 369 contribution to DDoS attack mitigation, there are also enterprise- 370 level DDoS attack mitigation solutions. It's usually a cloud service 371 and a large number of distributed nodes are deployed to protect their 372 customers from DDoS attack, customers' websites can be hidden behind 373 the nodes, usually the internet game companies and the live streaming 374 company will choose this way. 376 +-------------+ 377 | ISP | 378 | +---------+ | 379 | |dots svr | | 380 +-------------+ 381 | 382 | 383 +-------------+ 384 | Anti-D Node | 385 +-------------+ 386 |dots client| 387 +-----------+ 388 | 389 | 390 +-------------+ 391 |attack target| 392 +-------------+ 394 *Anti-D is for Anti-DDoS 396 Figure 3: DOTS Server Deployment for Enterprise and ISP 398 When enterprise-level anti-DDos nodes are unable to mitigate the DDoS 399 attack, they can trigger DOTS client which integrated in the Anti-D 400 Node to send mitigation request to ISP's DOTS server. 402 7. Security Considerations 404 TBD 406 8. IANA Considerations 408 TBD 410 9. Acknowledgement 412 TBD 414 10. References 416 10.1. Normative References 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, 420 DOI 10.17487/RFC2119, March 1997, 421 . 423 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 424 RFC 7950, DOI 10.17487/RFC7950, August 2016, 425 . 427 10.2. Informative References 429 [I-D.ietf-dots-architecture] 430 Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and 431 R. Compton, "Distributed-Denial-of-Service Open Threat 432 Signaling (DOTS) Architecture", draft-ietf-dots- 433 architecture-15 (work in progress), March 2020. 435 [I-D.ietf-dots-multihoming] 436 Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing 437 Deployment Considerations for Distributed-Denial-of- 438 Service Open Threat Signaling (DOTS)", draft-ietf-dots- 439 multihoming-03 (work in progress), January 2020. 441 [I-D.ietf-dots-requirements] 442 Mortensen, A., K, R., and R. Moskowitz, "Distributed 443 Denial of Service (DDoS) Open Threat Signaling 444 Requirements", draft-ietf-dots-requirements-22 (work in 445 progress), March 2019. 447 [I-D.ietf-dots-server-discovery] 448 Boucadair, M. and T. Reddy.K, "Distributed-Denial-of- 449 Service Open Threat Signaling (DOTS) Agent Discovery", 450 draft-ietf-dots-server-discovery-10 (work in progress), 451 February 2020. 453 [I-D.ietf-dots-signal-call-home] 454 Reddy.K, T., Boucadair, M., and J. Shallow, "Distributed 455 Denial-of-Service Open Threat Signaling (DOTS) Signal 456 Channel Call Home", draft-ietf-dots-signal-call-home-07 457 (work in progress), November 2019. 459 [I-D.ietf-dots-signal-channel] 460 Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and 461 N. Teague, "Distributed Denial-of-Service Open Threat 462 Signaling (DOTS) Signal Channel Specification", draft- 463 ietf-dots-signal-channel-41 (work in progress), January 464 2020. 466 [I-D.ietf-dots-use-cases] 467 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 468 L., and K. Nishizuka, "Use cases for DDoS Open Threat 469 Signaling", draft-ietf-dots-use-cases-20 (work in 470 progress), September 2019. 472 Authors' Addresses 474 Meiling Chen 475 China Mobile 477 32, Xuanwumen West 479 BeiJing 480 , 481 BeiJing 483 100053 485 China 487 Email: 488 chenmeiling@chinamobile.com 490 Li Su 491 China Mobile 493 32, Xuanwumen West 495 BeiJing 497 100053 499 China 501 Email: 502 suli@chinamobile.com