On May 29, 2009, at 12:05 PM, Florian Weimer wrote:
* Douglas Otis:
Just using TCP would prevent most of the DNS poisoning attacks
that Amir's paper reports.
TCP is prone to DDoS attack.
Only when implemented naively. If the client does not split the
query into two packets or artificially lowers the window size, you
can answer it without creating any state.
Any modification to TCP that bypasses SYN/ACK handshakes for full-
duplex data is not TCP. Indeed, DNS could operate accepting any TCP
packet "as-if" SYN-ACK handshakes occurred. The stack could initially
ignore sequence numbers, and assume all DNS messages are fully
contained within the packet, and that all messages are always frame
aligned.
This approach omits source verification, and therefore is unable to
mitigate spoofed reflected attacks. The same effect could be achieved
using EDNS0 options that extend both transaction-ids as well as packet
size. Of course, discovering whether a DNS server violates TCP
protocols or implements a new EDNS0 option may also expend an
additional exchange. This initial exchange would determine whether
the DNS server uses a facocta TCP or chokes on a new EDNS0 option. Of
course, the originating DNS client will need to retain this result to
establish global state to avoid increased resource consumption. The
initial exchange would also determine whether MTU limitations or
packet inspection on the path may also cause non-compliant packets to
be dropped. Any attack hammering the client may therefore induce the
downgrading to less secure modes.
The argument against TCP is not the protocol. It's just that you
have to upgrade both authoritative servers and resolvers to make it
work well.
Huh? Why suggest radical changes to the TCP protocol, and then, in the
same breath, say the problem is not the protocol?
Defending against DDoS attack was never a major consideration during
early TCP or UDP development. Bot-nets weren't the problem they are
today. Bastardizing TCP, rather than adopting properly designed
protocols, is unlikely to provide a solutions, but instead likely to
create new vulnerabilities.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg