idnits 2.17.1 draft-chen-dots-server-hierarchical-deployment-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 doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (July 06, 2019) is 1754 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-01 == Outdated reference: A later version (-15) exists of draft-ietf-dots-server-discovery-04 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-34 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-17 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 Jin. Peng 5 Expires: January 7, 2020 CMCC 6 July 06, 2019 8 A method for dots server deployment 9 draft-chen-dots-server-hierarchical-deployment-00 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 January 7, 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 5. DOTS server deployment between ISPs . . . . . . . . . . . . . 5 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 9.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 DDoS Open Threat Signaling (DOTS) is a protocol to standardize real- 69 time signaling, threat-handling 70 requests[I-D.ietf-dots-signal-channel], when attack target is under 71 attack, dots client send mitigation request to dots server for help, 72 If the mitigation request contains enough messages of the attack, 73 then the mitigator can respond very effectively. 75 In the architecture draft[I-D.ietf-dots-architecture], it is says 76 that this does not necessarily imply that the attack target and the 77 DOTS client have to be co-located in the same administrative domain, 78 but it is expected to be a common scenario. Although co-location of 79 DOTS server and mitigator within the same domain is expected to be a 80 common deployment model, it is assumed that operators may require 81 alternative models. 83 In the DOTS server discovery draft[I-D.ietf-dots-server-discovery], 84 it is says that a key point in the deployment of DOTS is the ability 85 of network operators to be able to onfigure DOTS clients with the 86 correct DOTS server(s) nformation consistently. 88 In the DOTS multihoming draft[I-D.ietf-dots-multihoming], it provides 89 deployment recommendations for DOTS client and DOTS gateway, it is 90 says when conveying a mitigation request to protect the attack 91 target, the DOTS client among the DOTS servers available Must select 92 a DOTS server whose network has assigned the prefixes from which 93 target prefixes and target IP addresses are derived. This implies 94 that id no appropriate DOTS server is found, the DOTS client must not 95 send the mitigation request to any DOTS server. So in this document, 96 we give some dots server deployment consideration as the title 97 suggests we prefer hierarchical deployment. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in 104 [RFC2119] 106 The readers should be familiar with the terms defined in 107 [I-D.ietf-dots-requirements] [I-D.ietf-dots-use-cases] 109 The terminology related to YANG data modules is defined in [RFC7950] 111 In addition, this document uses the terms defined below: 113 dots svr: abbreviation of dots server. 115 ISP: Internet service provider. 117 3. DOTS server Considerations 119 When take dots server deployment into consideration, one thing must 120 be involved is mitigator.so far, how many network devices can play 121 the role of mitigator, we make a summerized list as follows: 123 o Router. 125 o Special cleaning equipment, such as Flow clean device and clean 126 center. 128 o Network security equipment, such as firewall,IPS and WAF 130 Whether DOTS server can be deployed, the following conditions need to 131 be met: 133 o DOTS server has to interconnected with mitigator 135 o DOTS server can go directly to the mitigator which had best go 136 through without any other DOTS agents 138 o DOTS server has the permissions for scheduling and operations on 139 mitigator 141 o DOTS server has the ability to know the address of attack target 142 belong to which mitigator 144 4. DOTS server deployment inside an ISP 146 From the internal structure of ISP, the whole network can divide into 147 three parts logically. There are three most important routers: 148 backbone router, man(metropolitan area network) router, and IDC 149 router. When a ddos attack occurs, it must be one of the three cases 150 as follows, and the corresponding mitigator will responsible for 151 mitigation. 153 o only the lan network detected the attack, dots server3 will 154 receive mitigation request, and mitigator3 will act as the first 155 responsible mitigator. 157 o only the man network detected the attack, dots server2 will 158 receive mitigation request, then mitigator2 will act as the first 159 responsible mitigator. 161 o only the backbone network detected the attack, dots server1 will 162 receive mitigation request, then mitigator1 will act as the first 163 responsible mitigator. 165 o Attacks on the same attack target are found both in adjacent 166 areas, the upper network mitigator will act as the first 167 responsible mitigator. for example, dots server1 and dots server2 168 both received the mitigation request from attack target by dots 169 client, mitigator1 will responsible for ddos disposition(priority 170 ranking: mitigator1 > mitigator2 > mitigator3). 172 +---------+ 173 |other ISP| 174 +---------+ 175 .........|.......................... 176 | backbone network 177 +---------------+ +----------+ 178 |backbone router|-----|mitigator1| 179 +---------------+ +----------+ 180 |dots svr1| 181 +---------+ 182 ..........|................................. 183 | metropolitan area network 184 +----------+ +----------+ 185 |man router|-------|mitigator2| 186 +----------+ +----------+ 187 |dots svr2| 188 +---------+ 189 ..........|......................... 190 | local area network 191 +----------+ +----------+ 192 |IDC router|------|mitigator3| 193 +----------+ +----------+ 194 |dots svr3| 195 +---------+ 196 | 197 | 198 +-----------+ +-------------+ 199 |dots client|-------|attack target| 200 +-----------+ +-------------+ 202 Figure 1: DOTS Server Deployment 204 5. DOTS server deployment between ISPs 206 The coexistence of different operators is very common, coordination 207 between operators across networks is very important. Interdomain 208 attacks occur frequently, We recommend deploying the DOTS server at 209 the access point 211 o DDoS attack from one of other ISPs, for example, ISP A received 212 DDoS attack from ISP B or ISP C, then dots server C or dots server 213 B will receive the mitigation request. 215 o DDOS attack from two or more of other ISPs,for example, ISP A and 216 ISP B both start ddos attack to ISP C, then dots server A and dots 217 server B will both receive mitigation request from dots client C. 219 +-------------+ +-------------+ 220 | ISP A |--------| ISP B | 221 | +---------+ | | +---------+ | 222 | |dots svrA| | | |dots svrB| | 223 +-------------+ +-------------+ 224 | | 225 +-------------+-------------+ 226 | 227 +-------------+ 228 | ISP C | 229 | +---------+ | 230 | |dots svrC| | 231 +-------------+ 233 Figure 2: DOTS Server Deployment2 235 6. Security Considerations 237 TBD 239 7. IANA Considerations 241 TBD 243 8. Acknowledgement 245 TBD 247 9. References 249 9.1. Normative References 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, 253 DOI 10.17487/RFC2119, March 1997, 254 . 256 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 257 RFC 7950, DOI 10.17487/RFC7950, August 2016, 258 . 260 9.2. Informative References 262 [I-D.ietf-dots-architecture] 263 Mortensen, A., K, R., Andreasen, F., Teague, N., and R. 264 Compton, "Distributed-Denial-of-Service Open Threat 265 Signaling (DOTS) Architecture", draft-ietf-dots- 266 architecture-14 (work in progress), May 2019. 268 [I-D.ietf-dots-multihoming] 269 Boucadair, M. and R. K, "Multi-homing Deployment 270 Considerations for Distributed-Denial-of-Service Open 271 Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01 272 (work in progress), January 2019. 274 [I-D.ietf-dots-requirements] 275 Mortensen, A., K, R., and R. Moskowitz, "Distributed 276 Denial of Service (DDoS) Open Threat Signaling 277 Requirements", draft-ietf-dots-requirements-22 (work in 278 progress), March 2019. 280 [I-D.ietf-dots-server-discovery] 281 Boucadair, M. and R. K, "Distributed-Denial-of-Service 282 Open Threat Signaling (DOTS) Server Discovery", draft- 283 ietf-dots-server-discovery-04 (work in progress), June 284 2019. 286 [I-D.ietf-dots-signal-channel] 287 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 288 Teague, "Distributed Denial-of-Service Open Threat 289 Signaling (DOTS) Signal Channel Specification", draft- 290 ietf-dots-signal-channel-34 (work in progress), May 2019. 292 [I-D.ietf-dots-use-cases] 293 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 294 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 295 Open Threat Signaling", draft-ietf-dots-use-cases-17 (work 296 in progress), January 2019. 298 Authors' Addresses 300 Meiling Chen 301 CMCC 302 32, Xuanwumen West 303 BeiJing , BeiJing 100053 304 China 306 Email: chenmeiling@chinamobile.com 307 Li Su 308 CMCC 309 32, Xuanwumen West 310 BeiJing 100053 311 China 313 Email: suli@chinamobile.com 315 Jin Peng 316 CMCC 317 32, Xuanwumen West 318 BeiJing 100053 319 China 321 Email: pengjin@chinamobile.com