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

From: Douglas Otis <[email-masked]>
Date: Mon, 1 Jun 2009 15:02:47 -0700

On May 31, 2009, at 2:34 AM, Florian Weimer wrote:
>
>> On May 29, 2009, at 12:05 PM, Florian Weimer wrote:
>>
>>> * Douglas Otis:
>>
>>> 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.

When "State-Free" TCP becomes indistinguishable, this similarity  
creates both security and compatibility issues.

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

TCP TTL first need to expire, freeing up server or firewall  
resources.  Unless normal TCP is disabled, resources will be still  
stranded by SYN flood attacks, either at the firewall or server.

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

EDNS0 can change both the query and the answer.  Transforming the  
structure of the query allows enhanced transactional IDs.   However,  
until such an option is widely supported, this will only increase DNS  
latency and overhead.  The same would be true when attempting to use  
otherwise bogus "State-Free" TCP transaction to support DNS.

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

Don't underestimate DNS.  Often TCP scales by using load-balancers and/ 
or a significant distribution of servers.

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

Defensive solutions for TCP can not cope with the attack levels that  
might be created by a small bot-net.  TCP quickly suffers from  
resource exhaustion.  DNS over UDP avoids this propensity.   However,  
the brute strength of DNS over UDP can be leveraged to attack other  
network infrastructure, and perhaps overwhelm resource capacity.  This  
is especially a concern when an MTA authorization protocol ignores UDP  
exponential back-off and then prematurely initiates additional  
transactions.  This is made even more destructive when message  
recipients generate an order of magnitude more transactions  
transformed by message local-parts directed toward any victim from  
fully cached DNS records.  This provides for free DDoS attacks while  
spamming.  These attacks might also be used to instigate DNS cache  
poisoning.

The ability to poison DNS caches can be dramatically reduced by  
running DNS over SCTP.   SCTP's ability to properly detect abusive  
sources allows mitigation efforts without causing an unfair loss of  
service.  Neither UDP nor TCP employ the features needed to mitigate  
these types of attacks.  The cost to mitigate TCP attacks quickly run  
into the millions, whereas DNS remains more robust and is more cost  
effective.  Unfortunately, when adequately deployed, the brute  
strength of DNS creates its own risks.  SCTP can be made robust and  
can mitigate most cache poisoning exploits ( but using 32 bit SCTP  
transaction-ID, 16 bit DNS transaction-ID, 16 bit port number, 16 bit  
stream number, SCTP-AUTH 32 bytes).  SCTP can also be secured using  
TLS over SCTP, S-SCTP, AUTH-SCTP, as well as containing DNSSEC messages.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Mon, 1 Jun 2009 15:02:47 -0700

-Doug

---

From: Amir Herzberg <[email-masked]>
Date: Tue, 2 Jun 2009 09:46:02 +0300

On Tue, Jun 2, 2009 at 1:02 AM, Douglas Otis <[email-masked]> wrote:
...

> Defensive solutions for TCP can not cope with the attack levels that might
> be created by a small bot-net.  TCP quickly suffers from resource
> exhaustion.  DNS over UDP avoids this propensity.   However, the brute
> strength of DNS over UDP can be leveraged to attack other network
> infrastructure, and perhaps overwhelm resource capacity.  This is especially
> a concern when an MTA authorization protocol ignores UDP exponential
> back-off and then prematurely initiates additional transactions.  This is
> made even more destructive when message recipients generate an order of
> magnitude more transactions transformed by message local-parts directed
> toward any victim from fully cached DNS records.  This provides for free
> DDoS attacks while spamming.  These attacks might also be used to instigate
> DNS cache poisoning.

Right. Furthermore... I think the discussion began, when Doug mentioned the
concerns with abuse of SPF validation by receiving MTA/MDA/MUAs (in fact,
suggesting I'll expand on this risk, which I mentioned in my review article,
but I agree, not in sufficient detail). These abuses involved DDoS as well
as DNS poisoning (a la Kaminski).

I think it is important to remember that all these solutions discussed later
in this thread (DNS-sec, DNS over TCP, DNS over SCTP, etc.), are long-term
solutions; i.e., as long as most of the Net continues using DNS over UDP (at
least as one or even default option), and not yet adopting DNS-sec, these
risks remain- I refer to the risks due to fully RFC compliant SPF validation
by MTA/MDAs (and MUAs, although I'm not sure this qualifies as RFC
compliant).
-- 
Amir Herzberg
Associate Professor, Dept. of Computer Science
Bar Ilan University
http://AmirHerzberg.com