Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review

[Florian Weimer <[e-mail]>]

* Douglas Otis:

> 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.

>From the point of view of a compliant connection initiator, it is
hardly distinguishable from a more traditional implementation.

> This approach omits source verification, and therefore is unable to
> mitigate spoofed reflected attacks.

The packet count would not even be higher than ordinary TCP.  If you
send a spoofed SYN to a compliant TCP server, it sends back three to
five SYN+ACKs, until it receives an ACK or an RST.  Bandwidth is a
different matter, but that could be addressed by CNAME cookies
(although Cisco's patent may apply to that).

> The same effect could be achieved using EDNS0 options that extend
> both transaction-ids as well as packet size.

Not really, EDNS0 is not suitable for communicating support of an
extended query ID.

>> 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?

A lot of this has already been tried and proven in the HTTP context.
Claims that "TCP doesn't scale" or that "TCP is vulnerable to DoS
attacks" always sound very hollow to me.  DNS handles a fraction of
the requests processed by HTTP and SMTP, and yet it can't be run on
TCP for protocol reasons?  Come on.

> 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.

It's already being done for HTTP, and maybe to a lesser extent, for
SMTP.

I'm not saying that it make sense to upgrade the DNS infrastructure so
that it can smoothly handle a TCP-centric load.  Such a massive
upgrade could be better used to roll out something different.  But TCP
itself is not the problem.  In fact, experience with DoS attacks
against TCP services means that you've got a portfolio of solutions to
deal with attacks, something that would have yet to be developed for a
hypothetical non-TCP transport.