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

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






_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg