Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt
* Daisuke HIGASHI: > draft-fujiwara-dnsop-fragment-attack-01: > >> 3. Current status >> >> [Brandt2018] showed that Linux version 3.13 and older versions are >> vulnerable to crafted ICMP fragmentation needed and DF set packet and >> off-path attackers can set some of authoritative servers' path MTU >> size to 296. >> >> The author tested Linux version 2.6.32, 4.18.20 and FreeBSD 12.0. >> Linux 2.6.32 accepts crafted "ICMP Need Fragmentation and DF set" >> packet and path MTU decreased to 552. Linux 2.6.32, Linux 4.18.20 >> and FreeBSD 12.0 accept crafted "ICMPv6 Packet Too Big" packet and >> path MTU decreased to 1280. >> >> Linux version 4.18.20 may ignore crafted ICMP packet. > >I confirmed that Linux 4.18 (Ubuntu 18.10) accepts crafted ICMP > on "plain" UDP socket. And if sockopt IP_PMTUDISC_DONT is set to sockets > (many DNS implements do this) sender host generates fragmented packets > caused by crafted ICMP. > >Determining whether a DNS implementation on Linux accepts > crafted ICMPv4 or not is somewhat confusing and need to investigate > with caution: > > - Latest Linux seems to still accept crafted ICMPv4 by default. >Linux 3.15 introduced a new socket option IP_PMTUDISC_OMIT >which makes sockets ignore PMTU information and send packet with DF=0. >With this option sending socket never honor PMTU information and > fragmentation >is done if and only if the packet size exceeds outgoing interface MTU. > > - Some DNS implementation (BIND 9.9.10 / Unbound 1.5.0 and later) utilize > IP_PMTUDISC_OMIT option if available. So these DNS implementation on > Linux 3.15 (or later) > won't accept crafted ICMP. > (I submitted a patch to NSD for enabling this feature. > https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4235 ) Correct, this was the intent. There is another essential Linux kernel change: not using the path MTU when forwarding packets. Otherwise, a Linux hypervisor (or router), after receiving an ICMP packet directed to itself, would reassemble the packet and re-fragment it to the cached (spoofed) path MTU. I believe it's this commit: commit 69647ce46a236a355a7a3096d793819a9bd7c1d3 Author: Hannes Frederic Sowa Date: Wed Feb 26 01:20:41 2014 +0100 ipv4: use ip_skb_dst_mtu to determine mtu in ip_fragment ip_skb_dst_mtu mostly falls back to ip_dst_mtu_maybe_forward if no socket is attached to the skb (in case of forwarding) or determines the mtu like we do in ip_finish_output, which actually checks if we should branch to ip_fragment. Thus use the same function to determine the mtu here, too. This is important for the introduction of IP_PMTUDISC_OMIT, where we want the packets getting cut in pieces of the size of the outgoing interface mtu. IPv6 already does this correctly. > - Some Linux distribution is based on older version (like Linux 3.10) > but has IP_PMTUDISC_OMIT feature by backporting. > > I found that IP_PMTUDISC_OMIT feature is backported to Red Hat > Enterprise Linux 7 > (it's Linux 3.10 based) but they didn't backport corresponding macro > definition to glibc header. > So BIND9's / Unbound's IP_PMTUDISC_OMIT feature on current RHEL7 > won't be enabled > regardless of kernel feature. > (Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1684874 ) Yes, this is about to be fixed. But applications can use the constant directly if necessary (it's not architecture-specific and will never change). All in all, I do not think it is necessary or desirable to send DF=1 responses. The backwards compatibility impact would be too large. Thanks, Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt
draft-fujiwara-dnsop-fragment-attack-01: > 3. Current status > > [Brandt2018] showed that Linux version 3.13 and older versions are > vulnerable to crafted ICMP fragmentation needed and DF set packet and > off-path attackers can set some of authoritative servers' path MTU > size to 296. > > The author tested Linux version 2.6.32, 4.18.20 and FreeBSD 12.0. > Linux 2.6.32 accepts crafted "ICMP Need Fragmentation and DF set" > packet and path MTU decreased to 552. Linux 2.6.32, Linux 4.18.20 > and FreeBSD 12.0 accept crafted "ICMPv6 Packet Too Big" packet and > path MTU decreased to 1280. > > Linux version 4.18.20 may ignore crafted ICMP packet. I confirmed that Linux 4.18 (Ubuntu 18.10) accepts crafted ICMP on "plain" UDP socket. And if sockopt IP_PMTUDISC_DONT is set to sockets (many DNS implements do this) sender host generates fragmented packets caused by crafted ICMP. Determining whether a DNS implementation on Linux accepts crafted ICMPv4 or not is somewhat confusing and need to investigate with caution: - Latest Linux seems to still accept crafted ICMPv4 by default. Linux 3.15 introduced a new socket option IP_PMTUDISC_OMIT which makes sockets ignore PMTU information and send packet with DF=0. With this option sending socket never honor PMTU information and fragmentation is done if and only if the packet size exceeds outgoing interface MTU. - Some DNS implementation (BIND 9.9.10 / Unbound 1.5.0 and later) utilize IP_PMTUDISC_OMIT option if available. So these DNS implementation on Linux 3.15 (or later) won't accept crafted ICMP. (I submitted a patch to NSD for enabling this feature. https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4235 ) - Some Linux distribution is based on older version (like Linux 3.10) but has IP_PMTUDISC_OMIT feature by backporting. I found that IP_PMTUDISC_OMIT feature is backported to Red Hat Enterprise Linux 7 (it's Linux 3.10 based) but they didn't backport corresponding macro definition to glibc header. So BIND9's / Unbound's IP_PMTUDISC_OMIT feature on current RHEL7 won't be enabled regardless of kernel feature. (Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1684874 ) Regards, -- Daisuke Higashi ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt
You specify a well known TSIG key (e.g. name=“.”, algorithm=hmac-sha256, key=<32-zero-bytes>) then you use it when you don’t have a more specific key. If the server support the WKK you will get back a TSIG signed response that can’t have been forged by a off path attacker if it matched the response. There should be enough entropy in a TSIG query without add more but one can add more by putting random data in the other field prior to generating the request’s hmac. Otherwise you should get back a BADKEY error if the server supports TSIG and FORMERR, NOTIMP (without a TSIG record) or a non-TSIG response if the server does not implement TSIG. Clients can remember of they get a TSIG response and reject non-TSIG responses in the future or treat each transaction as independent. I would expect public DNS resolvers to formally state when they support this. The pairwise table I generated was to show what current servers do when presented with a unknown, unexpected TSIG key. There are a number of mis-implementation of TSIG shown. A few underspecified parts of the TSIG specification which I raise earlier. There are firewalls that unnecessarily block requests with TSIG present and there are mis-implementations of STD 13 shown. If we proceed down this path we will need to get CVE’s issues against all the firewalls and nameserver implementation that block/drop requests with TSIG presents they should be issued for firewalls anyway as it they break the ability to use TSIG. Servers that mis-implement TSIG or STD 13 need to be identified and fixed. A date for removal of workarounds for the mis-implementations needs to be set (+5 years from publishing should be enough time) along with a campaign to find at inform the server operators of broken servers. Tests for WKK behaviour should be added to delegated server tests and if we don’t go down this path vendors that implement TSIG at least should be add BADKEY tests to their QA procedures, similarly vendors that don’t implement TSIG need to add TSIG queries to their QA procedures. The raw data for the table is available at https://ednscomp.isc.org and is regenerated towards the end of the month. Mark > On 4 Mar 2019, at 10:52 pm, fujiw...@jprs.co.jp wrote: > >> From: Mark Andrews >> Or one can use TSIG with a well known key to get a cryptograph hash of the >> response. Below is how >> how the servers for the Alexa to 1 Million handle unexpected TSIG. It’s >> well under a day to add >> this to a recursive server that supports TSIG already. It’s a couple of >> minutes of configuration >> time to add it to a authoritative server that supports TSIG already. > > Do you mean adding new method like DNS Cookies ? > > I have a question. > > If a resolver want to take measures, > does the resolver configure TSIG to communicate all authoritative servers ? > > -- > Kazunori Fujiwara, JPRS > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt
At Mon, 04 Mar 2019 20:43:14 +0900 (JST), fujiw...@jprs.co.jp wrote: > > - Section 3 > > > >Linux 2.6.32, Linux 4.18.20 > >and FreeBSD 12.0 accept crafted "ICMPv6 Packet Too Big" packet and > >path MTU decreased to 1280. > > > > I suspect this often doesn't matter much in practice. Since IPv6 > > doesn't allow fragmentation and PMTU discovery isn't very effective for > ^ > on-path fragmentation ? Oops, sorry for the confusing text. I meant "IPv6 doesn't allow fragmentation at intermediate nodes" (or, yes, I meant "on-path fragmentation"). > > DNS responders, the server implementation should set > > IPV6_USE_MIN_MTU and expect that MTU anyway (several implementations > > actually set this option; some others don't, but they are just lucky > > to not encounter the problem or receive complaints about it). > > If setting IPV6_USE_MIN_MTU, does the server use 1280 as all path MTU value ? Yes. Or more accurately, if IPV6_USE_MIN_MTU is set the path MTU value (if known) is just ignored. > Without IPV6_DONTFRAG option, are responses larger than 1280 fragmented ? Yes (if IPV6_USE_MIN_MTU is specified). > I observed many fragmented IPv6 DNS responses whose packet size are > 1496 or 1500. Those should be sent from a server that doesn't set IPV6_USE_MIN_MTU or from a system that doesn't support the option (sadly a very widely deployed OS doesn't support it: Linux). > # What I was interested in was that many implementations accept > # crafted "ICMPv6 Packet Too Big". Sure, but unless it matters in the larger context of the draft, it's just a distraction. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt
> From: Mark Andrews > Or one can use TSIG with a well known key to get a cryptograph hash of the > response. Below is how > how the servers for the Alexa to 1 Million handle unexpected TSIG. It’s well > under a day to add > this to a recursive server that supports TSIG already. It’s a couple of > minutes of configuration > time to add it to a authoritative server that supports TSIG already. Do you mean adding new method like DNS Cookies ? I have a question. If a resolver want to take measures, does the resolver configure TSIG to communicate all authoritative servers ? -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt
> From: 神明達哉 >>https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-01 >> >> It summarized DNS cache poisoning attack using IP fragmentation >> and countermeasures. >> >> If the draft is interested, I will request timeslot at IETF 104. > > I've read the draft. I think it's generally well written and contains > useful information. Thanks very much. > Some specific comments follow: > > - general: I wonder whether the effect of this problem can be > substantially different between IPv6 and IPv4. As the draft itself > discusses, IPv6 has a much larger ID space for fragmentation (the > existence of implementations that generate predictable IDs is an > implementation issue; in the case of IPv4 it's a protocol issue). > IPv6 also has a much larger minimum MTU. In practice, I suspect > most (unsigned) important responses can fit in the minimum MTU, > substantially affecting the practical severity of the attack. I'm > not saying that we don't have to take any measure for the IPv6 case, > but I think this difference is worth noting in the draft explicitly. I agree and need to consider how to update. > - general: the draft the term "full-service resolver" in Abstract and > throughout the document. It may be only me, but I always feel this > term is confusing and misleading, even after the publication of > RFC8499. It's not very clear to me whether "full-service" excludes > "forwarding only" resolvers. RFC8499 refers to RFC1123, and its > definition is also unclear to me in this sense. If this confusion > is not only mine, I think the use of the term is rather harmful, > since the issue discussed in this draft shouldn't exclude forwarding > only resolvers. What matters here is a resolver with a cache, and > in that sense I'd rather suggest just saying "(recursive) resolver"; > it should be obvious that it's about a resolver with the cache from > the context. I will consider the comment. > - general: on a related point, I suspect the discussion about > authoritative servers is not actually specific to authoritative > servers; consider the case of a recursive server that takes queries > from forwarding only resolvers. It should be generally applicable > to any DNS "responder", and I'd suggest revising the draft > accordingly. DNS forwarders and stub resolvers may be target of cache poisoning attacks. Then, path MTU attack targets are DNS responders (auth/resolver servers). > - general: since this is about off-path cache poisoning attacks, you > may also want to refer to DNS cookies (RFC7873) as a possible measure. I agree. > - Section 3 > >Linux 2.6.32, Linux 4.18.20 >and FreeBSD 12.0 accept crafted "ICMPv6 Packet Too Big" packet and >path MTU decreased to 1280. > > I suspect this often doesn't matter much in practice. Since IPv6 > doesn't allow fragmentation and PMTU discovery isn't very effective for ^ on-path fragmentation ? > DNS responders, the server implementation should set > IPV6_USE_MIN_MTU and expect that MTU anyway (several implementations > actually set this option; some others don't, but they are just lucky > to not encounter the problem or receive complaints about it). If setting IPV6_USE_MIN_MTU, does the server use 1280 as all path MTU value ? Without IPV6_DONTFRAG option, are responses larger than 1280 fragmented ? I observed many fragmented IPv6 DNS responses whose packet size are 1496 or 1500. # What I was interested in was that many implementations accept # crafted "ICMPv6 Packet Too Big". > - Section 4.2 > >Limiting EDNS0 requestor's UDP payload size [RFC6891] to 1220/1232 on >IPv6 is a measure of path MTU attacks on IPv6 because minimal MTU >size of IPv6 is 1280 and most of implementations ignore ICMPv6 packet >too big packets whose MTU size is smaller than 1280. > > I suggest removing "and most of implementations..." since even if an > implementation accepts ICMPv6 PMTU with MTU < 1280, it doesn't mean > they fragment packets at that size. > > - Section 4.8 > >Some operators that support [RFC8078] said that they use TCP only for >transport to avoid cache poisoning attacks. > > It's not clear (to me at least) how RFC8078 is related to a TCP-only > operation. Some more explanation may help. > > - Section 5 > >o Full-service resolvers may retry name resolution by TCP. > > I don't get exactly what this means...in which case does it suggest > the retry with TCP? I will add texts. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt
Mark Andrews wrote on 2019-03-01 12:00: Or one can use TSIG with a well known key to get a cryptograph hash of the response. ... i prefer this approach. no matter how bad fragmentation was in V4 and no matter how much worse it is in V6, we must not lock ourselves into packets whose size is computed from the analog properties of 10Mbit ethernet (1500) minus a whole bunch of witch-craft fudge factors. i expect to live until around 2050, and by that time i'd like to use a LAN max packet size that's only 1/15000th of capacity (as 10Mbit ethernet had), and to either use smaller packets when forwarding through a WAN gateway, or make fragmentation possible, which V6 has unintentionally made presently impossible. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt
At Fri, 01 Mar 2019 21:14:48 +0900 (JST), fujiw...@jprs.co.jp wrote: > Dear DNSOP, > > I submitted draft-fujiwara-dnsop-fragment-attack-01. > >https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-01 > > It summarized DNS cache poisoning attack using IP fragmentation > and countermeasures. > > If the draft is interested, I will request timeslot at IETF 104. I've read the draft. I think it's generally well written and contains useful information. Some specific comments follow: - general: I wonder whether the effect of this problem can be substantially different between IPv6 and IPv4. As the draft itself discusses, IPv6 has a much larger ID space for fragmentation (the existence of implementations that generate predictable IDs is an implementation issue; in the case of IPv4 it's a protocol issue). IPv6 also has a much larger minimum MTU. In practice, I suspect most (unsigned) important responses can fit in the minimum MTU, substantially affecting the practical severity of the attack. I'm not saying that we don't have to take any measure for the IPv6 case, but I think this difference is worth noting in the draft explicitly. - general: the draft the term "full-service resolver" in Abstract and throughout the document. It may be only me, but I always feel this term is confusing and misleading, even after the publication of RFC8499. It's not very clear to me whether "full-service" excludes "forwarding only" resolvers. RFC8499 refers to RFC1123, and its definition is also unclear to me in this sense. If this confusion is not only mine, I think the use of the term is rather harmful, since the issue discussed in this draft shouldn't exclude forwarding only resolvers. What matters here is a resolver with a cache, and in that sense I'd rather suggest just saying "(recursive) resolver"; it should be obvious that it's about a resolver with the cache from the context. - general: on a related point, I suspect the discussion about authoritative servers is not actually specific to authoritative servers; consider the case of a recursive server that takes queries from forwarding only resolvers. It should be generally applicable to any DNS "responder", and I'd suggest revising the draft accordingly. - general: since this is about off-path cache poisoning attacks, you may also want to refer to DNS cookies (RFC7873) as a possible measure. - Section 3 Linux 2.6.32, Linux 4.18.20 and FreeBSD 12.0 accept crafted "ICMPv6 Packet Too Big" packet and path MTU decreased to 1280. I suspect this often doesn't matter much in practice. Since IPv6 doesn't allow fragmentation and PMTU discovery isn't very effective for DNS responders, the server implementation should set IPV6_USE_MIN_MTU and expect that MTU anyway (several implementations actually set this option; some others don't, but they are just lucky to not encounter the problem or receive complaints about it). - Section 4.2 Limiting EDNS0 requestor's UDP payload size [RFC6891] to 1220/1232 on IPv6 is a measure of path MTU attacks on IPv6 because minimal MTU size of IPv6 is 1280 and most of implementations ignore ICMPv6 packet too big packets whose MTU size is smaller than 1280. I suggest removing "and most of implementations..." since even if an implementation accepts ICMPv6 PMTU with MTU < 1280, it doesn't mean they fragment packets at that size. - Section 4.8 Some operators that support [RFC8078] said that they use TCP only for transport to avoid cache poisoning attacks. It's not clear (to me at least) how RFC8078 is related to a TCP-only operation. Some more explanation may help. - Section 5 o Full-service resolvers may retry name resolution by TCP. I don't get exactly what this means...in which case does it suggest the retry with TCP? -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt
Or one can use TSIG with a well known key to get a cryptograph hash of the response. Below is how how the servers for the Alexa to 1 Million handle unexpected TSIG. It’s well under a day to add this to a recursive server that supports TSIG already. It’s a couple of minutes of configuration time to add it to a authoritative server that supports TSIG already. Count, without WKK, with WWK. https://ednscomp.isc.org/compliance/alexa1m-tsig-wkk.txt 2019-02-24T00:00:05Z 2 dns=ok dnswkk=eof 39 dns=failed dnswkk=failed 348 dns=ok dnswkk=formerr,notsig 65 dns=timeoutdnswkk=formerr,notsig 10 dns=nosoa,noaa dnswkk=formerr,notsig 7 dns=servfail dnswkk=formerr,notsig 3 dns=formerrdnswkk=formerr,notsig 3 dns=nosoa,noaa,rd dnswkk=formerr,notsig 3 dns=refuseddnswkk=formerr,notsig 2 dns=noaa dnswkk=formerr,notsig 1 dns=nxdomain dnswkk=formerr,notsig 9 dns=ok dnswkk=formerr,notsig,opt (non RFC compliant: OPT record in response) 2 dns=refuseddnswkk=formerr,notsig,opt (non RFC compliant: OPT record in response) 786 dns=ok dnswkk=formerr,tsig-bad-sig (non RFC compliant: TSIG record in response) 33 dns=refuseddnswkk=formerr,tsig-bad-sig (non RFC compliant: TSIG record in response) 6 dns=servfail dnswkk=formerr,tsig-bad-sig (non RFC compliant: TSIG record in response) 3 dns=noaa dnswkk=formerr,tsig-bad-sig (non RFC compliant: TSIG record in response) 3 dns=timeoutdnswkk=formerr,tsig-bad-sig (non RFC compliant: TSIG record in response) 1 dns=ok dnswkk=formerr,tsig-bad-sig,proxy (non RFC compliant: TSIG record in response) 9 dns=rd dnswkk=formerr,tsig-bad-sig,rd (non RFC compliant: TSIG record in response) 156 dns=refuseddnswkk=malformed (non RFC compliant: malformed) 135 dns=ok dnswkk=malformed (non RFC compliant: malformed) 38 dns=servfail dnswkk=malformed (non RFC compliant: malformed) 13 dns=malformed dnswkk=malformed (non RFC compliant: malformed) 13 dns=timeoutdnswkk=malformed (non RFC compliant: malformed) 10 dns=nosoa dnswkk=malformed (non RFC compliant: malformed) 8 dns=nxdomain,addnswkk=malformed (non RFC compliant: malformed) 3 dns=nosoa,noaa dnswkk=malformed (non RFC compliant: malformed) 4 dns=ok dnswkk=noerror,badkey,nosoa,noaa (non RFC compliant: rcode != NOTAUTH) 4 dns=ok dnswkk=noerror,badkey,tsig-wrong-alg,nosoa,noaa (non RFC compliant: rcode != NOTAUTH) 3 dns=ok dnswkk=noerror,badkey,tsig-wrong-alg,tsig-bad-time,nosoa,noaa (non RFC compliant: rcode != NOTAUTH) 142252 dns=ok dnswkk=notauth,badkey 2483 dns=refuseddnswkk=notauth,badkey 694 dns=servfail dnswkk=notauth,badkey 369 dns=timeoutdnswkk=notauth,badkey 295 dns=nosoa,noaa dnswkk=notauth,badkey 176 dns=rd dnswkk=notauth,badkey 43 dns=nosoa dnswkk=notauth,badkey 9 dns=noaa dnswkk=notauth,badkey 2 dns=nxdomain dnswkk=notauth,badkey 2 dns=optdnswkk=notauth,badkey 2 dns=refused,rd dnswkk=notauth,badkey 5 dns=optdnswkk=notauth,badkey,opt (non RFC compliant: OPT record in response) 318 dns=ok dnswkk=notauth,badkey,proxy 6 dns=refuseddnswkk=notauth,badkey,proxy 3 dns=servfail dnswkk=notauth,badkey,proxy 2 dns=nosoa,noaa dnswkk=notauth,badkey,proxy 2 dns=timeoutdnswkk=notauth,badkey,proxy 1 dns=rd dnswkk=notauth,badkey,rd,proxy (non RFC compliant: RD=1 in response) 8238 dns=ok dnswkk=notauth,badkey,tsig-bad-time 159 dns=refuseddnswkk=notauth,badkey,tsig-bad-time 118 dns=servfail dnswkk=notauth,badkey,tsig-bad-time 37 dns=nosoa,noaa dnswkk=notauth,badkey,tsig-bad-time 30 dns=rd dnswkk=notauth,badkey,tsig-bad-time 17 dns=timeoutdnswkk=notauth,badkey,tsig-bad-time 3 dns=noaa dnswkk=notauth,badkey,tsig-bad-time 2 dns=nosoa dnswkk=notauth,badkey,tsig-bad-time 31 dns=ok dnswkk=notauth,badkey,tsig-bad-time,proxy 2 dns=nosoa,noaa dnswkk=notauth,badkey,tsig-bad-time,proxy 1 dns=refuseddnswkk=notauth,badkey,tsig-bad-time,proxy 27 dns=ok dnswkk=notauth,badkey,tsig-bad-time,tsig-bad-fudge 105 dns=ok dnswkk=notauth,badkey,tsig-wrong-alg 5 dns=nosoa,noaa dnswk
[DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt
Dear DNSOP, I submitted draft-fujiwara-dnsop-fragment-attack-01. https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-01 It summarized DNS cache poisoning attack using IP fragmentation and countermeasures. If the draft is interested, I will request timeslot at IETF 104. I think it is time to consider to avoid IP Fragmentation in DNS. It is possible to avoid IP fragmentation as much as possible. It is not good that DNS is the biggest user of IP fragmentation. Regards, -- Kazunori Fujiwara, JPRS A new version of I-D, draft-fujiwara-dnsop-fragment-attack-01.txt has been successfully submitted by Kazunori Fujiwara and posted to the IETF repository. Name: draft-fujiwara-dnsop-fragment-attack Revision: 01 Title: Measures against cache poisoning attacks using IP fragmentation in DNS Document date: 2019-03-01 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-fragment-attack-01.txt Status: https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-fragment-attack/ Htmlized: https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-fragment-attack Diff: https://www.ietf.org/rfcdiff?url2=draft-fujiwara-dnsop-fragment-attack-01 Abstract: Researchers proposed practical DNS cache poisoning attacks using IP fragmentation. This document shows feasible and adequate measures at full-service resolvers and authoritative servers against these attacks. To protect resolvers from these attacks, avoid fragmentation (limit requestor's UDP payload size to 1220/1232), drop fragmented UDP DNS responses and use TCP at resolver side. To make a domain name robust against these attacks, limit EDNS0 Responder's maximum payload size to 1220, set DONTFRAG option to DNS response packets and use good random fragmentation ID at authoritative server side. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
