idnits 2.17.1 draft-fujiwara-dnsop-fragment-attack-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 283: '... Section 3 of [RFC4035] defines that A security-aware name server MUST...' RFC 2119 keyword, line 333: '... [I-D.ietf-acme-acme] recommends that servers SHOULD perform DNS...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 388 has weird spacing: '... or iptables ...' == Line 497 has weird spacing: '...ication any ...' == Line 512 has weird spacing: '...ication any ...' -- The document date (March 01, 2019) is 1882 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Fujiwara 3 Internet-Draft JPRS 4 Intended status: Informational March 01, 2019 5 Expires: September 2, 2019 7 Measures against cache poisoning attacks using IP fragmentation in DNS 8 draft-fujiwara-dnsop-fragment-attack-01 10 Abstract 12 Researchers proposed practical DNS cache poisoning attacks using IP 13 fragmentation. This document shows feasible and adequate measures at 14 full-service resolvers and authoritative servers against these 15 attacks. To protect resolvers from these attacks, avoid 16 fragmentation (limit requestor's UDP payload size to 1220/1232), drop 17 fragmented UDP DNS responses and use TCP at resolver side. To make a 18 domain name robust against these attacks, limit EDNS0 Responder's 19 maximum payload size to 1220, set DONTFRAG option to DNS response 20 packets and use good random fragmentation ID at authoritative server 21 side. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 2, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Methodology of the attack . . . . . . . . . . . . . . . . . . 3 59 3. Current status . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Possible measures . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Use DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.2. Limit requestor's UDP payload size to 1220/1232 on IPv6 . 6 63 4.3. Limit requestor's UDP payload size to 512 . . . . . . . . 6 64 4.4. Set IP_DONTFRAG / IPv6 DONTFRAG at authoritative servers 7 65 4.5. Drop path MTU discovery or filter ICMP related to path 66 MTU discovery . . . . . . . . . . . . . . . . . . . . . . 7 67 4.6. Drop all fragmented packets . . . . . . . . . . . . . . . 7 68 4.7. Drop fragmented UDP DNS responses at full-service 69 resolvers . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.8. Use TCP only . . . . . . . . . . . . . . . . . . . . . . 7 71 4.9. Use good randomness for Fragmentation Identification 72 field . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 5. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 6. Example firewall configuration . . . . . . . . . . . . . . . 8 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 78 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 9 79 10.1. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 10.2. 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 83 11.2. Informative References . . . . . . . . . . . . . . . . . 10 84 Appendix A. How to know path MTU size . . . . . . . . . . . . . 11 85 Appendix B. How to generate crafted ICMP packets . . . . . . . . 11 86 B.1. Example of crafted ICMP Need Fragmentation and DF set 87 packet . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 B.2. Example of crafted ICMPv6 Packet Too Big . . . . . . . . 12 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 "Fragmentation Considered Poisonous" [Herzberg2013] proposed 94 effective off-path DNS cache poisoning attacks using IP 95 fragmentation. The attacks mainly depend on the use of UDP to 96 retrieve long DNS responses, resulting in packet fragmentation. 98 Recent full-service resolvers use good randomness for query source 99 port numbers and ID field in DNS header to prevent cache poisoning 100 attacks by off-path attackers. However, IP fragmentation is 101 performed by OS kernel or routers that operators of DNS servers 102 cannot control, and the query source port number and ID field in DNS 103 header exist only in first fragment. The attack depends on poor 104 randomness of "Identification" field generated by IP fragmentation 105 and some bugs in IP reassembly code. Attackers can know path MTU 106 size between authoritative servers and victim full-service resolvers, 107 and responses from the authoritative servers. If attackers know 108 generation algorithm of the "Identification" field, they can generate 109 crafted second fragment packets that will be accepted by victim full- 110 service resolvers. 112 [Hlavacek2013] also discussed the attacks and pointed that attackers 113 can control path MTU size between some authoritative servers and 114 victim full-service resolvers by sending crafted ICMP packets 115 (Fragmentation needed and DF set, or ICMPv6 Packet Too Big). 116 [Hlavacek2013] proposed a defense and two workarounds. The defence 117 is DNSSEC and workarounds are ignoring ICMP type=3 code=4 118 (fragmentation needed and DF set), and limiting response size / EDNS0 119 buffer size fit to MTU size. 121 And more, "Domain Validation++ For MitM-Resilient PKI" [Brandt2018] 122 proved that off-path attackers can intervene in path MTU discovery 123 [RFC1191] to perform intentionally fragment responses from 124 authoritative servers. They also proved that they poisoned 125 Certificate Authorities (CAs)' full-service resolvers and 126 successfully issued some fraudulent certificates. 128 As a result, we cannot trust all fragmented UDP packets and path MTU 129 discovery. 131 By the way, TCP is considered strong against fragmentation attacks 132 because TCP has sequence number and acknowledgement number in each 133 sequence. 135 This document describes possible measures of cache poisoning attacks 136 using IP fragmentation. 138 2. Methodology of the attack 140 DNS cache poisoning attacks using IP fragmentation are performed by 141 combining the path MTU attack and cache poisoning attack. Path MTU 142 attack targets are authoritative DNS servers. Cache poisoning attack 143 targets are full-service resolvers. 145 Cache poisoning attacks using IP fragmentation are performed as 146 follows steps. Path MTU attack is performed by step 3. Cache 147 poisoning attack is performed by step 4 to 6. 149 1. Choose victim full-service resolver and target domain name. 151 2. Get the correct response from authoritative servers of the target 152 domain name. 154 3. Send crafted ICMP/ICMPv6 packet to authoritative servers of the 155 target domain name. The crafted ICMP packet indicates small path 156 MTU size from the authoritative server to the victim full- 157 resolver. If control of the path MTU succeed, proceed to the 158 next step. 160 4. Generate second fragments from the correct response retrieved at 161 step 2 with specified path MTU size, and calculate partial 162 checksum value of the second fragment. Generate crafted second 163 fragment that has the same partial checksum value. (If the 164 partial checksum value of the correct second fragment and the 165 partial checksum value of the crafted second fragment are the 166 same, the UDP checksum value are the same.) 168 5. Send trigger query (target domain name / type) to the victim 169 full-service resolver. 171 6. Send the crafted second fragment to victim full-service resolver 172 with assumed fragment ID (or all possible IDs, at most 65536 on 173 IPv4). 175 7. If victim full-service resolver accepts the crafted second 176 fragment, the attack is successful. 178 The keys of the attack are: 180 o The attacker can control the fragmentation. 182 o The attacker can generate second fragment that generates the same 183 UDP checksum value as the original response. 185 o The query source port and DNS ID field exist in the first 186 fragment. 188 o the reassembly process holds received second fragment until 189 arrival of the first fragment (timing is not strict), 191 o IPv4 fragmentation ID field has only 16 bits. 193 o Some IPv6 implementations use predictable fragment Identification 194 values [RFC7739]. 196 The probability of spoofing a resolver is described in Section 7.2 of 197 [RFC5452]. The DNS cache poisoning attack using IP fragmentation 198 changes to P=1 and I=1 (source port and ID are in the first fragment 199 and need not predict), and adds number of fragment IDs as a 200 denominator. 202 On IPv6, the attack does not change the probability because IPv6 203 fragment ID field has 32 bits. On IPv4, the attack changes the 204 probability from 1/2^32 to 1/2^16 because IPv4 fragment ID field has 205 only 16 bits. 207 3. Current status 209 [Brandt2018] showed that Linux version 3.13 and older versions are 210 vulnerable to crafted ICMP fragmentation needed and DF set packet and 211 off-path attackers can set some of authoritative servers' path MTU 212 size to 296. 214 The author tested Linux version 2.6.32, 4.18.20 and FreeBSD 12.0. 215 Linux 2.6.32 accepts crafted "ICMP Need Fragmentation and DF set" 216 packet and path MTU decreased to 552. Linux 2.6.32, Linux 4.18.20 217 and FreeBSD 12.0 accept crafted "ICMPv6 Packet Too Big" packet and 218 path MTU decreased to 1280. 220 Linux version 4.18.20 may ignore crafted ICMP packet. 222 FreeBSD and NetBSD accept "ICMP Need Fragmentation and DF set" packet 223 related to established TCP and ignore "ICMP Need Fragmentation and DF 224 set" packet related to UDP. 226 Then, off-path attackers can decrease path MTU size from some IPv4 227 authoritative servers to 552 (or 296), and can decrease path MTU size 228 from IPv6 authoritative servers to 1280 (minimal IPv6 MTU size). 230 As described before, some old operating systems use predictable 231 (incremental) fragmentation ID. 233 Furthermore, off-path attackers can know path MTU size related to 234 authoritative servers and they can generate crafted fragmented DNS 235 responses to victim full-service resolvers. 237 Then, measures against these attacks at full-service resolvers is 238 important. 240 +---------------+---------+----------+---------+----------+ 241 | OS / | crafted | minimal | crafted | minimal | 242 | source | ICMPv4 | IPv4 MTU | ICMPv6 | IPv6 MTU | 243 +---------------+---------+----------+---------+----------+ 244 | [Brandt2018] | accept | 552/296 | unknown | unknown | 245 +---------------+---------+----------+---------+----------+ 246 | Linux 2.6.32 | accept | 552 | accept | 1280 | 247 | Linux 4.18.20 | ignore? | | accept | 1280 | 248 | FreeBSD 12 | ignore | | accept | 1280 | 249 +---------------+---------+----------+---------+----------+ 251 4. Possible measures 253 4.1. Use DNSSEC 255 DNSSEC is a measure against cache poisoning attacks. However, there 256 are many unsigned zones and full-service resolver operator need to 257 consider these zones. 259 "Use DNSSEC" requires both authoritative side and resolver side 260 support. 262 4.2. Limit requestor's UDP payload size to 1220/1232 on IPv6 264 Limiting EDNS0 requestor's UDP payload size [RFC6891] to 1220/1232 on 265 IPv6 is a measure of path MTU attacks on IPv6 because minimal MTU 266 size of IPv6 is 1280 and most of implementations ignore ICMPv6 packet 267 too big packets whose MTU size is smaller than 1280. 269 4.3. Limit requestor's UDP payload size to 512 271 Limiting EDNS0 requestor's UDP payload size [RFC6891] to 512 may be a 272 measure of path MTU attacks. 274 However, since most of DNSSEC responses exceed 512 octets, limiting 275 EDNS0 requestor's UDP payload size to 512 results truncated responses 276 and resolvers need to retry queries by TCP. It always decreases name 277 resolution performance. 279 And more, [Brandt2018] showed that off-path attackers can set some of 280 authoritative servers' path MTU cache to 296. In this case, limiting 281 EDNS0 payload size is not a measure. 283 Section 3 of [RFC4035] defines that A security-aware name server MUST 284 support a message size of at least 1220 octets. 286 4.4. Set IP_DONTFRAG / IPv6 DONTFRAG at authoritative servers 288 It is a measure of authoritative server side. 290 4.5. Drop path MTU discovery or filter ICMP related to path MTU 291 discovery 293 It is not a measure of resolver side. All authoritative servers need 294 to be changed. Changing all authoritative servers is impossible. 295 TCP requires path MTU discovery. 297 4.6. Drop all fragmented packets 299 To avoid the fragmentation attacks, "drop all fragmented packets" is 300 one of the ideas. However, under path MTU discovery attacks, TCP 301 packets may be fragmented and dropped. Then, "drop all fragmented 302 UDP packets related to DNS" is the solution. 304 4.7. Drop fragmented UDP DNS responses at full-service resolvers 306 Drop fragmented UDP DNS responses at full-service resolvers may be a 307 measure of cache poisoning attacks using IP fragmentation. 309 To avoid fragmentation in normal condition, use EDNS0 requestor's and 310 responder's UDP payload size as 1220 to avoid fragmentation. 1220 is 311 the minimal value defined by [RFC4035]. 313 Under path MTU discovery attacks and cache poisoning attacks using IP 314 fragmentation, UDP DNS response packets are fragmented and dropped 315 and name resolution fails. 317 If resolver software retries by TCP, TCP is strong for fragmentation 318 attacks and name resolution by TCP will success. 320 4.8. Use TCP only 322 It is believed that TCP is not vulnerable to fragmentation attacks. 323 Unbound has "tcp-upstream" option that changes the upstream queries 324 use TCP only for transport. 326 Some operators that support [RFC8078] said that they use TCP only for 327 transport to avoid cache poisoning attacks. 329 The full-service resolvers of multiple CAs issuing domain validation 330 (DV) certificates are required to withstand cache poisoning attacks, 331 it is better to implement their full-service resolvers use TCP 332 upstream queries only. Section 11.2 "DNS security" of 333 [I-D.ietf-acme-acme] recommends that servers SHOULD perform DNS 334 queries over TCP, which provides better resistance to some forgery 335 attacks than DNS over UDP. 337 4.9. Use good randomness for Fragmentation Identification field 339 See [RFC7739]. 341 5. Proposal 343 To avoid cache poisoning attacks using IP fragmentation by full- 344 service resolvers, 346 o Full-service resolvers set EDNS0 requestor's UDP payload size to 347 1220. (minimal size defined by [RFC4035]) 349 o Full-service resolvers drop fragmented UDP responses related to 350 DNS. 352 o Full-service resolvers may retry name resolution by TCP. 354 o (Full-service resolvers support DNSSEC validation.) 356 To make a domain name robust for cache poisoning attacks using IP 357 fragmentation, 359 o Authoritative servers choose EDNS0 responder's maximum payload 360 size limit to 1220 (to avoid IP fragmentation). 362 o Authoritative servers send DNS responses with IP_DONTFRAG / 363 IPV6_DONTFRAG options. 365 o (Authoritative servers support DNSSEC and sign the domain name.) 367 o Authoritative servers and network devices use good randomness for 368 fragmentation Identification field. 370 Exception: If authoritative servers and full-service resolvers are 371 located beyond the link with the MTU value less than 1280, choose 372 EDNS0 requestor's and responder's maximum payload size limit to the 373 smallest link MTU value. 375 6. Example firewall configuration 377 Linux iptables support dropping first fragment with UDP source port 378 53 by using m32 module. Other first fragments that is not UDP, not 379 source port 53 are not dropped. Second and following fragments 380 should not be dropped because they may relate to other protocols. 382 Second fragments related to DNS will be dropped because their first 383 fragments dropped. 385 iptables -t raw -A PREROUTING -m u32 --u32 \\ 386 "6&0xFFFF00FF=0x20000011&&18&0xffff=53" -j DROP 388 or iptables -t raw -A PREROUTING -p udp -f -j DROP 390 ip6tables -A INPUT -p udp -m frag --fragfirst -m udp --sport 53 -j DROP 392 Other OSs may not handle first fragments. Then, drop all fragmented 393 UDP packets. 395 On FreeBSD, 'ipfw' can drop all fragmented UDP packets (second 396 fragments). 398 ipfw deny log udp from any to me in frag 400 7. IANA Considerations 402 This document has no IANA actions. 404 8. Security Considerations 406 Under path MTU discovery and fragmentation attacks, most full-service 407 resolver software do not retry name resolution by TCP, name 408 resolution related to attacks fails. 410 9. Acknowledgments 412 The author would like to specifically thank Mark Andrews and Daisuke 413 HIGASHI. 415 10. Change History 417 10.1. 00 419 Initial version 421 10.2. 01 423 o Added Attack methodology 425 o Added measures at authoritative servers 427 11. References 429 11.1. Normative References 431 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 432 DOI 10.17487/RFC1191, November 1990, 433 . 435 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 436 Rose, "Protocol Modifications for the DNS Security 437 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 438 . 440 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 441 Resilient against Forged Answers", RFC 5452, 442 DOI 10.17487/RFC5452, January 2009, 443 . 445 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 446 for DNS (EDNS(0))", STD 75, RFC 6891, 447 DOI 10.17487/RFC6891, April 2013, 448 . 450 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 451 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 452 February 2016, . 454 11.2. Informative References 456 [Brandt2018] 457 Brandt, M., Dai, T., Klein, A., Shulman, H., and M. 458 Waidner, "Domain Validation++ For MitM-Resilient PKI", 459 Proceedings of the 2018 ACM SIGSAC Conference on Computer 460 and Communications Security , 2018. 462 [Herzberg2013] 463 Herzberg, A. and H. Shulman, "Fragmentation Considered 464 Poisonous", IEEE Conference on Communications and Network 465 Security , 2013. 467 [Hlavacek2013] 468 Hlavacek, T., "IP fragmentation attack on DNS", RIPE 67 469 Meeting , 2013, . 472 [I-D.ietf-acme-acme] 473 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 474 Kasten, "Automatic Certificate Management Environment 475 (ACME)", draft-ietf-acme-acme-18 (work in progress), 476 December 2018. 478 [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from 479 the Parent via CDS/CDNSKEY", RFC 8078, 480 DOI 10.17487/RFC8078, March 2017, 481 . 483 Appendix A. How to know path MTU size 485 o Linux: ip route get 487 o FreeBSD: sysctl -o net.inet.tcp.hostcache.list 489 Appendix B. How to generate crafted ICMP packets 491 Let the crafted path MTU size be cMTU. 493 B.1. Example of crafted ICMP Need Fragmentation and DF set packet 494 IP header: 495 +-----------------------------------------------+ 496 | V/HL 0x45 / TOS any / Total Length 20+8+20+8 | 497 | Identification any / Flags/Offset 0 | 498 | TTL any / Protocol 1 / Header checksum: calc | 499 | Source Address: attack tool address or any | 500 | Destination: target auth server address | 501 +-----------------------------------------------+ 503 ICMP header: 504 +-----------------------------------------------+ 505 | Type 3 / Code 4 / Checksum: calculate | 506 | unused 0 / Next-Hop MTU: cMTU | 507 +-----------------------------------------------+ 509 Internet Header + 64 bits of Original Datagram: 510 IP header: +-----------------------------------------------+ 511 | V/HL 0x45 / TOS any / Total Length 1420 | 512 | Identification any / Flags/Offset 0x4000(DF)| 513 | TTL any / Protocol 17/ Header checksum: calc | 514 | Source Address: target auth server address | 515 | Destination: victim full-resolver address | 516 +-----------------------------------------------+ 517 UDP header: 518 +-----------------------------------------------+ 519 | Source Port 53 / Destination Port: any | 520 | Length 1400 / Checksum: any | 521 +-----------------------------------------------+ 523 B.2. Example of crafted ICMPv6 Packet Too Big 524 IPv6 header: 525 +----------------------------------------------------+ 526 | Version/Traffic Class/Flow Label: 0x60000000 | 527 |Payload Len: cMTU-40 / NextHeader 58 / HopLimit any | 528 | Source Address: attack tool address or any | 529 | Destination Address: target auth server address | 530 +----------------------------------------------------+ 531 ICMPv6 header: 532 +----------------------------------------------------+ 533 | Type 2 / Code 0 / Checksum: calculate | 534 | MTU: (64bit) cMTU | 535 +----------------------------------------------------+ 536 Fake invoking packet 537 IPv6 header: 538 +----------------------------------------------------+ 539 | Version/Traffic Class/Flow Label: 0x60000000 | 540 |Payload Len: 1400 / NextHeader 17 / HopLimit any | 541 | Source Address: target auth server address | 542 | Destination Address: victim full-resolver address | 543 +----------------------------------------------------+ 544 UDP header: 545 +----------------------------------------------------+ 546 | Source Port 53 / Destination Port: any | 547 | Length 1400 / Checksum: any | 548 +----------------------------------------------------+ 549 Rest: Fill zero to end of packet 551 Author's Address 553 Kazunori Fujiwara 554 Japan Registry Services Co., Ltd. 555 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 556 Chiyoda-ku, Tokyo 101-0065 557 Japan 559 Phone: +81 3 5215 8451 560 Email: fujiwara@jprs.co.jp