December 26, 2006

Changing the Mantra -- RFC 4732 on rethinking DOS

A couple of years ago I wrote that we should stop thinking about DOS -- denial of service attacks -- as something we don't do anything about in design phases simply because we can't stop it. The net community had adopted a sort of "institutional defeatism" which was causing problems because we weren't properly thinking through the ramifications of some of our choices.

I proposed that for a security protocol, it should make DOS no worse than it was without the security protocol, which at least theoretically removes the temptation for the user to turn off the security. That eliminates the easy attack against the user's security. Further, we help the popularity of the security protocol, and hopefully just thinking about this objective gets the designer looking for ways to reduce DOS.

Lynn now points to a new RFC on DOS, which primarily aims at the same thing: getting people to think about DOS when they build their systems:

4732 I Internet Denial-of-Service Considerations, Handley M., IAB, Rescorla E., 2006/12/22 (38pp)

This document provides an overview of possible avenues for denial-of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities.

A quick skim through indicates that it includes a good list of the many classical DOS techniques, and also a useful list of defences.

Posted by iang at December 26, 2006 10:43 AM | TrackBack

original post mentioned two RFCs, the other was Security Implications of Using the Data Encryption Standard (DES)

we had done detailed vulnerability study when we were doing our high availability product (ha/cmp) ... including tcp/ip (both RFCs and code)

i.e. availability might be considered part of integrity and from the security acronym PAIN

P - privacy (or sometimes CAIN and confidentiality)
A - authentication
I - integrity
N - non-repudiation

later when we had been called in to consult on payments transactions ... for something that has since come to be called e-commerce

there was also an incident where the largest online service provider was starting to have internet server crash ... storage exhaustion with a lot of half-open sessions. this started the middle of june and continued thru the middle of august (during that period they had wide variety of different people to come in and look at the problem).

Finally one of the people flew out to the west coast and bought me a hamburger after work. He described the problem while I ate the hamburger. Then i gave him a quick&dirty fix which he applied later that night.

Almost exactly a year later ... there was a whole lot of press with similar kind of system failures at an ISP in manhatten (i.e. I talked to most of the major product providers the previous year about addressing the problem ... but none were interested until the problem got a whole lot of press).

misc. past references to the incident: AADS related information Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?) [Lit.] Buffer overruns Caller ID "spoofing" The Pankian Metaphor

for some topic drift ... recent post having to do with ha/cmp scale-up and distributed lock manager (DLM) being able to meet database ACID properties Why so little parallelism?

and other references mentioning distributed operation The Future of CPUs: What's After Multi-Core? The Future of CPUs: What's After Multi-Core?

Posted by: Lynn Wheeler at December 26, 2006 02:49 PM
Post a comment

Remember personal info?

Hit preview to see your comment as it would be displayed.