idnits 2.17.1 draft-chen-dots-server-hierarchical-deployment-01.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. 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 (October 31, 2019) is 1629 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-14 == Outdated reference: A later version (-13) exists of draft-ietf-dots-multihoming-02 == Outdated reference: A later version (-15) exists of draft-ietf-dots-server-discovery-05 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-38 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-20 Summary: 1 error (**), 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 Jin. Peng 5 Expires: May 3, 2020 CMCC 6 October 31, 2019 8 A method for dots server deployment 9 draft-chen-dots-server-hierarchical-deployment-01 11 Abstract 13 As DOTS is used for DDoS Mitigation signaling, in practice, there are 14 different deployment scenarios for DOTS agents deployment depending 15 on the network deployment mode. This document made an accommandation 16 for DOTS Server deployment which may be Suitable for ISP. The goal 17 is to provide some guidance for DOTS agents 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 May 3, 2020. 36 Copyright Notice 38 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . 5 59 4.2.1. Bandwidth consuming attack . . . . . . . . . . . . . 6 60 4.2.2. Host resource consuming attack . . . . . . . . . . . 6 61 5. DOTS server deployment between ISPs . . . . . . . . . . . . . 7 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 9.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 onfigure DOTS clients with the 90 correct DOTS server(s) nformation 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.so far, how many network devices can play 135 the role of mitigator, we make a summerized list as follows: 137 o Router. 139 o Special cleaning equipment, such as Flow clean device and clean 140 center. 142 o Network security equipment, such as firewall,IPS and WAF. 144 Whether DOTS server can be deployed, the following conditions need to 145 be met: 147 o DOTS server and mitigator are in the same administrative domain 149 o DOTS server can go directly to the mitigator which had best go 150 through without any other DOTS agents 152 o DOTS server has the permissions for scheduling and operations on 153 mitigator 155 o DOTS server has the ability to know the address of attack target 156 belong to which mitigator 158 4. DOTS server deployment inside an ISP 160 4.1. DOTS Agents Deployment 162 From the internal structure of ISP, the whole network can divide into 163 three parts logically. There are three most important routers: 164 backbone router, man(metropolitan area network) router, and IDC 165 router. When a ddos attack occurs, it must be one of the three cases 166 as follows, and the corresponding mitigator will responsible for 167 mitigation. 169 o only the lan network detected the attack, dots server3 will 170 receive mitigation request, and mitigator3 will act as the first 171 responsible mitigator. 173 o only the man network detected the attack, dots server2 will 174 receive mitigation request, then mitigator2 will act as the first 175 responsible mitigator. 177 o only the backbone network detected the attack, dots server1 will 178 receive mitigation request, then mitigator1 will act as the first 179 responsible mitigator. 181 o Attacks on the same attack target are found both in adjacent 182 areas, the lower network mitigator will act as the first 183 responsible mitigator. for example, dots server1 and dots server2 184 both received the mitigation request from attack target by dots 185 client, mitigator2 will responsible for ddos disposition(priority 186 ranking: mitigator3, mitigator2, mitigator1). 188 Normally, The lower network the target in, the easier it is to alert. 189 Because the higher network the attack target in, the greater the 190 bandwidth of the pipeline. As shown in the following figure, 191 Orchestrator take on the role for scheduling. Because the importance 192 of the orchestrator, it is suggested to consider bakeup mechanisms to 193 ensure continuity and security. 195 How does DOTS client can find DOTS servers, we can reference the DOTS 196 server discovery draft[I-D.ietf-dots-server-discovery], Static 197 configuration or dynamic discovery depends on the actual scenario and 198 the size of the network. 200 +---------+ 201 |other ISP| 202 +---------+ 203 .........|.......................... 204 | backbone network 205 +---------------+ +----------+ 206 |backbone router|-----|mitigator1| 207 +---------------+ +----------+ 208 |dots svr1| 209 +---------+ 210 ..........|................................. 211 | metropolitan area network 212 +----------+ +----------+ 213 |man router|-------|mitigator2| 214 +----------+ +----------+ 215 |dots svr2| 216 +---------+ 217 ..........|................................. 218 | local area network 219 +----------+ +----------+ 220 |IDC router|------|mitigator3| 221 +----------+ +----------+ 222 |dots svr3| 223 -------------- 224 |Orchestrator| 225 +------------+ 226 | 227 | 228 +-----------+ +-----------------------+ +-------------+ 229 |dots client|----|netflow/ipfix collector|---|attack target| 230 +-----------+ +-----------------------+ +-------------+ 232 Figure 1: DOTS Server Deployment 234 4.2. DOTS Agents interfaces 236 In the dots use case draft[I-D.ietf-dots-use-cases], it is says the 237 orchestrator analyses the various information it receives from DDoS 238 telemetry system, and initiates one or multiple DDoS mitigation 239 strategies. In the telemetry draft, all the telemetry informations 240 are contained and some parameters can be used to make decisions. 241 This section made a discussion on which attributes could be used in 242 orchestrator for scheduling and the orchestrator's ability. to know 243 all the related mitigators capability and residue capability. 245 We suggest orchestrator has three capabilities and reuse the method 246 of registration and notification in signal channel: 248 1.Can get the neflow/ipfix collector's telemetry informations. 250 2.Can get the capabilities of each mitigator, it means the initial 251 capacity, this means that with each addition of mitigator there needs 252 to be a protocol that can push this information to orchestrator, we 253 recommend using DOTS signal channel to transfer initial capacity. 255 3.When mitigation finished, mitigator can inform orchestrator that 256 mitigation is finished and capacity has been released, also we 257 recommend using DOTS signal channel to transfer. 259 4.2.1. Bandwidth consuming attack 261 The following parameters will be required by orchestrator: 263 o top-talker 265 o source-prefix 267 o total-traffic 269 o total-attack-traffic 271 o total-pipe-capability 273 The recommended approach here is to redirect traffic and flow 274 cleaning. 276 4.2.2. Host resource consuming attack 278 The following parameters will be required by orchestrator: 280 o top-talker 282 o source-prefix 284 The recommended approach here is to use router for disposition. 286 5. DOTS server deployment between ISPs 288 The coexistence of different operators is very common, coordination 289 between operators across networks is very important. Interdomain 290 attacks occur frequently, We recommend deploying the DOTS server at 291 the access point 293 o DDoS attack from one of other ISPs, for example, ISP A received 294 DDoS attack from ISP B or ISP C, then dots server C or dots server 295 B will receive the mitigation request. 297 o DDOS attack from two or more of other ISPs,for example, ISP A and 298 ISP B both start ddos attack to ISP C, then dots server A and dots 299 server B will both receive mitigation request from dots client C. 301 +-------------+ +-------------+ 302 | ISP A |--------| ISP B | 303 | +---------+ | | +---------+ | 304 | |dots svrA| | | |dots svrB| | 305 +-------------+ +-------------+ 306 | | 307 +-------------+-------------+ 308 | 309 +-------------+ 310 | ISP C | 311 | +---------+ | 312 | |dots svrC| | 313 +-------------+ 315 Figure 2: DOTS Server Deployment2 317 6. Security Considerations 319 TBD 321 7. IANA Considerations 323 TBD 325 8. Acknowledgement 327 TBD 329 9. References 331 9.1. Normative References 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, 335 DOI 10.17487/RFC2119, March 1997, 336 . 338 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 339 RFC 7950, DOI 10.17487/RFC7950, August 2016, 340 . 342 9.2. Informative References 344 [I-D.ietf-dots-architecture] 345 Mortensen, A., K, R., Andreasen, F., Teague, N., and R. 346 Compton, "Distributed-Denial-of-Service Open Threat 347 Signaling (DOTS) Architecture", draft-ietf-dots- 348 architecture-14 (work in progress), May 2019. 350 [I-D.ietf-dots-multihoming] 351 Boucadair, M., K, R., and W. Pan, "Multi-homing Deployment 352 Considerations for Distributed-Denial-of-Service Open 353 Threat Signaling (DOTS)", draft-ietf-dots-multihoming-02 354 (work in progress), July 2019. 356 [I-D.ietf-dots-requirements] 357 Mortensen, A., K, R., and R. Moskowitz, "Distributed 358 Denial of Service (DDoS) Open Threat Signaling 359 Requirements", draft-ietf-dots-requirements-22 (work in 360 progress), March 2019. 362 [I-D.ietf-dots-server-discovery] 363 Boucadair, M. and R. K, "Distributed-Denial-of-Service 364 Open Threat Signaling (DOTS) Agent Discovery", draft-ietf- 365 dots-server-discovery-05 (work in progress), August 2019. 367 [I-D.ietf-dots-signal-channel] 368 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 369 Teague, "Distributed Denial-of-Service Open Threat 370 Signaling (DOTS) Signal Channel Specification", draft- 371 ietf-dots-signal-channel-38 (work in progress), October 372 2019. 374 [I-D.ietf-dots-use-cases] 375 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 376 L., and K. Nishizuka, "Use cases for DDoS Open Threat 377 Signaling", draft-ietf-dots-use-cases-20 (work in 378 progress), September 2019. 380 Authors' Addresses 382 Meiling Chen 383 CMCC 384 32, Xuanwumen West 385 BeiJing , BeiJing 100053 386 China 388 Email: chenmeiling@chinamobile.com 390 Li Su 391 CMCC 392 32, Xuanwumen West 393 BeiJing 100053 394 China 396 Email: suli@chinamobile.com 398 Jin Peng 399 CMCC 400 32, Xuanwumen West 401 BeiJing 100053 402 China 404 Email: pengjin@chinamobile.com