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 | TrackBackoriginal post mentioned two RFCs, the other was
http://www.garlic.com/~lynn/aadsm26.htm#16 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)
http://www.garlic.com/~lynn/subtopic.html#hacmp
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
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
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:
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/99.html#48 Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
http://www.garlic.com/~lynn/2005c.html#51 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2006e.html#11 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006i.html#6 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
http://www.garlic.com/~lynn/2006x.html#3 Why so little parallelism?
and other references mentioning distributed operation
http://www.garlic.com/~lynn/2006y.html#5 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006y.html#6 The Future of CPUs: What's After Multi-Core?