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
