idnits 2.17.1 draft-zhang-dots-dns-considerations-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC8612]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 seems to have RFC 2119 boilerplate text. -- The document date (July 26, 2020) is 1370 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 72, but not defined == Missing Reference: 'RFC8174' is mentioned on line 72, but not defined == Missing Reference: 'RFC 7858' is mentioned on line 85, but not defined == Unused Reference: 'I-D.ietf-dots-use-cases' is defined on line 236, but no explicit reference was found in the text == Unused Reference: 'RFC7858' is defined on line 241, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Zhang 3 Internet-Draft P. Zuo 4 Intended status: Informational Y. Sun 5 Expires: January 27, 2021 M. Yuan 6 CNNIC 7 July 26, 2020 9 DNS DOTS considerations 10 draft-zhang-dots-dns-considerations-00 12 Abstract 14 DDoS Open Threat Signaling(DOTS) described in [RFC8612] is a 15 standardized method to coordinate a real-time response among involved 16 operators. This document focus on the considerations regard to the 17 use of DOTS to mitigate DNS-Related DDoS attacks. 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 27, 2021. 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 1. Introduction 53 Domain Name System(DNS) is one of the most foundational and essential 54 services on the Internet, the security and robustness of DNS are of 55 great significance. However, the stable operation of DNS has been 56 threatened by Distributate Denial of Service(DDoS) for quiet a long 57 time. In addition, DNS is often used to implement amplification 58 attacks, reflection attacks, etc. 60 DDoS Open Threat Signaling(DOTS) described in [RFC8612] is a 61 standardized method to coordinate a real-time response among involved 62 operators. This document focus on the considerations regard to the 63 use of DOTS to mitigate DNS-Related DDoS attacks. 65 2. Terminology 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 69 "OPTIONAL" in this document are to be interpreted as described in BCP 70 14 [RFC2119] [RFC8174] when, and only when, they appear in all 71 capitals, as shown here. 73 This document uses the terminologies defined in [RFC8612] and [I- 74 D.ietf-dots-use-cases]. 76 3. DNS DOTS considerations 78 3.1. DOTS Server 80 DOTS Server described in RFC 8612 is responsible for handling 81 messages from DOTS client. In order to provide more effective and 82 comprehensive mitigation, the DOTS server should have the ability to 83 filter DNS messages based on different transfer protocols. At the 84 time of this writing, the majority of DNS traffic is transmitted in 85 plain text via UDP. As some new DNS protocols like DoT[RFC 7858], 86 DoH[RFC8484] are introduced, encrypted DNS traffic transmitted via 87 TLS and HTTPS is growing. As the normal deep packet inspection 88 method is not easy to detect encrypted traffic, port filtering or 89 deep learning methods can be considered to identify abnormal traffic 90 in the case of DoT or DoH. 92 3.2. Filter 94 Filters described in RFC 8612 should be extended to filter DNS 95 traffic based on DNS message characteristics. For example, DNS 96 packets can be filtered by domain name queried. Based on the 97 telemetry of the attack, filter can drop or transmit DNS packages 98 according to specific domain names or other DNS characteristics. In 99 addition, filter should support bidirectional filtering of DNS 100 traffic. For example, for the use of DNS to implement amplification 101 attacks, the filter can drop the DNS response from the DNS server 102 side. 104 3.3. Data channel 106 Data channel described in RFC 8612 should support the transmission of 107 blacklists and whitelists used in DNS traffic filtering and DNS 108 service status between DOTS client and DOTS server. The list should 109 include the DNS packet characteristics such as IP, port, domain name, 110 query type, etc. For scenarios where the blacklist and whitelist 111 have huge size and may cost long time to transfer, regular and 112 incremental update should be considered to ensure timely delivery of 113 information. 115 3.4. Traffic Management 117 DNS server should deploy DNS traffic management module to detect DDoS 118 traffic. When DDoS attack happens, traffic management module will 119 notify DOTS client to request attack coordination with DOTS server. 121 3.4.1. threshold setting 123 DOTS Client should set dynamic thresholds for different attacks. For 124 example, Bit-and-piece attack is a new pattern of attach which 125 spreading small and fine-targeted traffic attacks across hundreds of 126 IP-addresses to evade detection. This new pattern is often leveraged 127 on open DNS resolvers to launch what is commonly known as DNS 128 amplification. In this case, a relatively low threshold should be 129 set to detect such attacks. 131 3.4.2. DNS traffic monitoring 133 The DNS server directly processes DNS traffic, thus it can obtain the 134 status of DNS nodes most accurately and timely. A suitable attack 135 detection system should be applied on the DNS server side to 136 implement attack detection, feature baseline learning, protection 137 strategy recommendations, etc. For example, the DOTS client deployed 138 in the DNS server side can comprehensively calculate the probability 139 of false alarm and the probability of missed reports to trigger the 140 security mechanism reasonably. Attack detection system can consider 141 the classification of attack types, so that Filter can choose more 142 reasonable strategies in the early stage of a DDoS mitigation. 144 The DNS server should learn the characteristics of both the normal 145 DNS traffic and DDoS traffic in real time. The normal traffic 146 characteristics can be used as the normal flow profile. These 147 characteristics include but are not limited to: query rate of 148 specific domains, characteristics of domains, amplification ratio of 149 query size to response size, anomaly detection parameters and models 150 based on machine learning, etc. 152 Generally ordinary attacks have relatively obvious characteristics, 153 for example sending a large number of requests for random subdomains 154 to a DNS resolver. These type of attacks can be detected based on 155 the characteristics relatively simply. If the attack randomness is 156 strong and it is difficult to extract clear attack characteristics, 157 the characteristics aggregation can be performed by machine learning. 159 4. Example 161 Random subdomain attack is a type of DDOS against DNS service that 162 happens frequently. Attackers send a lot of DNS queries against a 163 valid and existing domain name. However, the queries will not target 164 the main domain name, but a lot of non-existing subdomains. The goal 165 of this attack is to create a DoS that will saturate the DNS server, 166 and cause the faliure of DNS service. Here is the mitigation process 167 of such Random subdomain attack. 169 1. A large number of requests for XXX.example.cn are mixed into the 170 normal DNS request, XXX represents a random domain name label. The 171 request traffic exceeds the service capabilities of DNS server. 173 2. The Traffic Moinitor located in DNS server detects the anomaly 174 traffic and sends attackrelated features and mitigation requests to 175 the Filter in the ISP through the DOTS interface. The information 176 contains the following: (1)The QNAME field of the attack packet is 177 random label + example.cn; (2)news.example.cn should be kept and 178 transmitted; (3)The normal QPS of domain name news.example.cn is M; 179 (4)The maximum response capacity of the server is N. 181 3: Filter implements mitigation process according to the signal it 182 receives and re-injects the cleaned data to the DNS server. After 183 filtering, the traffic contains normal request traffic and 184 news.example.cn requests. The total request traffic does not exceed 185 the DNS server service capacity. 187 +---------DOTS signal/data channel-------+ 188 |S C| 189 V | 190 +---------------------+ +------------+ 191 | | | | | DDOS ATTACK | | 192 | | |Filter| |========================>|----------+ | 193 | | | | |========================>| DNS | | 194 | | +------+ |====|XXX.example.cn|====>| Traffic | | 195 | +-----------> |========================>| Detection| | 196 |------------------> |========================>|----------+ | 197 | +------------> | normal DNS traffic | | 198 | | +----------> |------------------------>| DNS | 199 | ISP | | | | Server | 200 +---------------------+ +------------+ 201 *C is for DOTS client functionality 202 *S is for DOTS server functionality 204 Figure1: Random subdomain attack traffic 206 +--------DOTS signal/data channel--------+ 207 |S C| 208 V | 209 +---------------------+ +------------+ 210 | | |---+| |----------+ | 211 | |Filter|-+ || | DNS | | 212 | +------+ | || | Traffic | | 213 | ^ ^ | || news.example.cn | Detection| | 214 |----------- | | | +------------------------->|----------+ | 215 |------------+ | | | normal DNS REQ | | 216 | +--------+ +--------------------------->| | 217 | | +------ | | DNS | 218 | ISP | | | | Server | 219 +---------------------+ +------------+ 220 *C is for DOTS client functionality 221 *S is for DOTS server functionality 223 Figure2: normal DNS traffic after filtering 225 In the above example, the Filter uses the characteristics of anomaly 226 traffic provided by the DNS serve. This process not only filters the 227 attack traffic, but also keeps normal DNS packets within the service 228 capabilities of the DNS server to the maximum extent. 230 5. IANA Considerations 232 TBD. 234 6. References 236 [I-D.ietf-dots-use-cases] 237 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 238 L., and K. Nishizuka, ""Use cases for DDoS Open Threat 239 Signaling(work in progress)"", July 2019. 241 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 242 and P. Hoffman, ""Specification for DNS over Transport 243 Layer Security (TLS)"", May 2016, 244 . 246 [RFC8484] Hoffman, P. and P. McManus, ""DNS Queries over HTTPS 247 (DoH)"", October 2018, 248 . 250 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, ""DDoS Open 251 Threat Signaling (DOTS) Requirements"", May 2019, 252 . 254 Authors' Addresses 256 Haikuo Zhang 257 CNNIC 258 4 South 4th Street,Zhongguancun,Haidian District 259 Beijing, Beijing 100190 260 China 262 Phone: +86 10 5881 3163 263 Email: zhanghaikuo@cnnic.cn 265 Peng Zuo 266 CNNIC 267 4 South 4th Street,Zhongguancun,Haidian District 268 Beijing, Beijing 100190 269 China 271 Phone: +86 10 5881 2629 272 Email: zuopeng@cnnic.cn 273 Yungang Sun 274 CNNIC 275 4 South 4th Street,Zhongguancun,Haidian District 276 Beijing, Beijing 100190 277 China 279 Phone: +86 10 5881 2669 280 Email: sunyungang@cnnic.cn 282 Meng Yuan 283 CNNIC 284 4 South 4th Street,Zhongguancun,Haidian District 285 Beijing, Beijing 100190 286 China 288 Phone: +86 10 5881 2669 289 Email: yuanmeng@cnnic.cn