> From: Haya Shulman <haya.shul...@gmail.com> > > This is essentially an IP packet modification vulnerability and in order > > to do these, you don't even need fragmentation. This might happen even > > due to malfunctioning network adapter or other network device, not > > necessarily an "attack". One of the reasons for DNSSEC existence is to > > prevent processing of "damaged" DNS data, with malicious origin or not. > > If you are concerned with improperly assembled IP packets, the DNS > > community is the wrong place to ask for a fix. The DNS community can > > only make sure "their" protocol takes care of such issues, and issues > > like this are totally addressed by technologies such as DNSSEC, TSIG > > etc. But the fundamental "fix" for this issue has to happen in the > > TCP/IP stack.
I do not understand why that paragraph was quoted, because Haya Shulman's following paragraph is almost unrelated to it. The main point of the preceding paragraph seems to be DNSSEC protects DNS data intentional and accidential data change or corruption in the lower layers. Fixes for other application protocols vulnerable to fragmentation attacks are off topic here. > IP does not, and was not designed to, guarantee security - only best effort > end-to-end delivery. The discussion was if Eastlake cookies can prevent the > attacks: the example I showed was a legitimate way to apply IP > fragmentation (which is a feature of IP - it is not a bug) to foil the > protection offered by Eastlate cookies and to inject spoofed content into > the DNS response (despite the use of Eastlake cookies for protection). That claim against having "[injected] spoofed content into the DNS response (despite the use of Eastlake cookies for protection)" is false unless that attack was against DNS clients and servers using DNS cookies, and not merely the cookies described in https://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03 but cookies in an as-yet unpublished proposal with a payload checksum. Note that I thought that there are no available implementations even of original flavor cookies. I do not understand how a blind attack against DNS cookies checksums would work. That makes me wonder whether these fragmentation attacks are blind. IP fragementation or TCP segment assembly attacks in which the attacker can see all of the traffic are, to understate the case, much less interesting. If these attacks are blind, how do they fix the UDP checksum? This is somewhat relevant, because there are far easier attacks than IP fragmentation for an attacker who can see DNS traffic. It is only somewhat relevant, because the answer is still DNSSEC. > This > should be of interest to DNS community, unless you argue that the DNS > community should rely on IP layer for security of DNS. No one said anything like "[relying] on IP layer for security of DNS." As Paul Vixie repeatedly wrote, cookies is need to protect against reflection attacks. On the other hand, DNSSEC is the source of DNS data security. Maybe that's why it's called DNSSEC. ..... } From: Haya Shulman <haya.shul...@gmail.com> } There are these measurments that studied loss due to traffic volume, and } they found that Kernel loss occurs at above 100-150 Kpps (packets per } second), with 64 byte packets. One of these works, in addition to measuring } loss in kernel, also measured performance of snort under heavy load, and } found loss could occur above 100KB. } http://www.sciencedirect.com/science/article/pii/S143484110600063X I see little relevant to current PC hardware or software in that abstract of a 7 year old paper. It does tend to contradict Haya Shulman's apparently unsupported guesses about the causes of the packet losses she observed. } http://www.sciencedirect.com/science/article/pii/S1084804509001040 That paper is not as ancient, but it is even more irrelevant. } Two significant differences between our and their setting is that they used } only a single host that generated the traffic, and the traffic consisted of } 64 Byte packets (we used 500Byte packets). } In any case, I am curious as to wether the loss occured in DNS software and } if increasing the buffers in DNS software can mitigate the problem (I'll } run it again to confirm). I do not understand why spend that effort is worthwhile. If as I suspect, increasing DNS forwarder socket buffer size tends to mitigate the attack, we'll know something we already knew, that the attack is less likely to work everywhere. However, no DNS server software maintainer would consider changing socket buffer sizes based this issue. The fix for DNS insecurity is DNSSEC. This paper of Haya Shulman reports that by DNS request flooding of a recursive, an attacker might determine the DNS client port numbers used by the server. That might be interesting by contradicting claims DNS forwarding is secure because no one can know those port numbers. (Never mind that the first I've heard of such very weak security claims are in Haya Shulman's papers.) The reasonable conclusion to this report is "Deploy DNSSEC because DNS without DNSSEC is insecure." The paper also contained an explanation of the effect that is unsupported by measurements, tests, or code reading and simply wrong. That explanation is also irrelevant to the point and reasonable conclusion of the paper. The right way to fix the paper is to remove the relevant, unsupported explanation. Vernon Schryver v...@rhyolite.com _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs