Make The Client Pay

Whenever you have a freely available resource, some people will abuse the resource, with the direct or indirect consequence that others will be unable to use it legitimately. The solution to this is to make the client sacrifice some nominal amount of something which is personally valuable to them. The idea isn't to make clients pay you back, just to make them pay.

So for example, in the case of freely available medical services, making clients pay in money is a poor method of sacrifice. That's because money is very unevenly distributed so that some small fraction of the population doesn't care about it at all, whereas a large fraction doesn't have enough to pay for legitimate uses.

Happily, computer networking power is not so unevenly distributed. Personal computers differ in power only by two or three orders of magnitude, and not 9 orders of magnitude as is the case for money. So in the case of all kinds of denial of service attacks, it is sensible to make the client pay for requested services in computing power. This also applies to the processing of requests for services which is itself a service.

But to make the client pay for a specific service, the client must first request that service. There's no way to send the money before some sort of request. As long as a client can send a request at some protocol level, a server is vulnerable to denial of service attacks.

Did you miss the point where it's not about sending payment, let alone money, but about proving it's been sacrificed? If you send someone a video showing you burning a million dollars, that's proof of sacrifice of a million dollars.

If a client spends as much or more computing power formulating and sending a request as a server spends receiving and examining it then this is an appropriate sacrifice for most applications. This is the most elemental request for service / sacrifice pair there is and it is indivisible; you can't make a request without sacrificing something.

How to convince a rogue client to abide by this rule is left as an exercise for the lowly programmer. Meanwhile the InteractionDesigner is busy trying to construct more circle quadratures type of designs.

Here, let me hold your hand while I do your thinking for you. Since someone obviously neglected to explain the facts of life to you, I will start off with those.

The reason you can't cite any law or produce any proof that thwarting denial of service using a 'make the client pay' tactic is impossible is because there isn't one. And the reason there isn't any such proof is because one can't be constructed. And the reason why one can't be constructed is because the opposite (that it does in fact work) has already been proved and accepted as true.

HashCash, which SJ was so good to point us towards, is a working 'make the client pay' solution to the problem of defending human attention from denial of service attacks (ie, spam). Given that the tactic is known to work, I need merely give the general shape of a solution in the case of TCP. And the only reason I need to do this at all is to show that 'make the client pay' can be applied much further than anyone has ever thought it applicable before.

Once TCP is re-engineered to prevent, or at least make much more difficult, DoS attacks, then IP-based attacks are a completely different thing. These are much more difficult to prevent and it would take re-engineering IP to prevent them, but maybe once people get tired of a single badly configured company router being able to hose half the internet then something will be done about the problem. Your whining about it accomplishes nothing and it's quite obvious that a Single Totally Integrated Solution that thwarts DoS all the way from the IP layer to the email layer, and provides cake and cookies too, is neither possible nor desirable.

Now be a good boy and if you manage to assimilate all these facts then you'll earn yourself a pat on the head.

Richard - I must be missing something.

A "Denial of Service Attack" is, by definition, a coherent set actions taken by someone, an attacker, A, that prevents a server, S from providing their service to a legitimate client, L.
Consider requiring a client, C, to prove that they have made a payment, P (standing both for proof and payment - there should be no confusion).
C must send their request for service, R, to S including P.
S must confirm that P is valid.
- This requires resources.
A can send an arbitrary number of Rs to S, whether valid or not.
A can thereby force S to expend an arbitrary amount of resources confirming that various Ps are valid.
A can thereby degrade the service provided by S to L.
In the extreme, A (which may be distributed and therefore not recognised as a single attacker) can prevent S from servicing L.
Therefore A has successfully executed a DoS attack on S.

This seems independent of the mechanism of P, and to prove that a DoS attack can succeed by definition.

Could you explain where I have gone wrong? Thanks.

First, if you really want to understand the issues then you might want to stick to the right language and context. That context is economic, so you speak about resources being spoiled until others starve. If you don't use this language then by now, Eric has assured this, you send a clear sign to me that you're unwilling and incapable of learning.

The whole point of the payment / verification scheme is that it is radically asymmetric. Paying requires a great deal of computation whereas verification of payment requires minimal computation at best. In the case of multiplying a row of numbers and checking whether they fall within a list of bounds, the cost of doing this is trivial. And it's obvious to see that it is not independent of the payment method.

Further, wasting CPU verifying payment isn't a problem in reality because CPU power is plentiful and networking bandwidth is scarce. That's why you use the thing which is plentiful (though not human-plentiful) to pay for the thing which is scarce, and not vice versa. If the situation were reversed then you would just reverse what resource pays for what other resource. Again, this is just economics. -- RK

Even before S confirms that P is valid, S still has to allocate network resources to receive R. Those resources can be exhausted by A just as they are today. You can keep pushing that problem to lower levels (that "aren't your problem"), but that doesn't make the problem go away. -- EH

Go away, go away, go away. You're uneducable Eric. The only thing you achieve by persistently asking your questions is to make me dismiss the possibility that anyone else has the same comprehension problems. And since your questions inhibit other people asking the same thing, your participation is actually a net negative contribution to this discussion. -- RK

This page should probably be renamed ProposedDefencesAgainstDos? because each DoS attack that targets a distinct resource may need to be defended against differently.

Let's try this again.

Most programmers think that DoS is just something that happens when you try to provide a service to the broad public, without any accountability or traceability. When asked to characterize DoS, they would say that "DoS attacks are based on exploiting the vulnerability of allowing access" or "simply overloading the server with more requests than it can handle", but this is not true.

It's not true because servers get overloaded all the time and usually what happens is that a few requests get delayed or dropped, so server overloads are not DoS. The typical programmer's way of thinking about DoS is very engineering and security-minded, and it happens to be incomplete. What that means is that you can't possibly engineer a security solution to the problem of DoS, and also that it's not a security problem in the first place so there might be other solutions.

Now let's think about DoS for a moment. Let's take it out of the computer networking arena and think about the essence of DoS. The essence of DoS is that there is some resource which is freely available to a group of people and which one or more members hoard until the rest of the group starves. In essence, DoS is a case of famine and not just any kind of famine but artificially induced famine. A famine where there's plenty of food, or other resource, to go around for all legitimate purposes, but hoarding and misallocation causes the majority to starve.

Now, what we see is that DoS is an economic problem so it's not any wonder then that there isn't any kind of security solution to that economic problem. What we also see is that DoS isn't just any kind of random economic problem but a very specific problem that's been extensively studied and is very well documented. AmartyaSen got a Nobel Prize in Economics for having pointed out the causes of famines, and Shlomo Reutlinger & Marcelo Selowsky verified it. So by now the thesis that famines are caused by unequal income distributions has widely become accepted.

Note that famines are not caused by lack of supply of food. Famines are not caused by demand "overloading" supply, they're not caused by overpopulation, they're not caused by having too little food to go around. In computer networking terms, this means that DoS is not caused by servers (supply) being overloaded by requests (too much demand). Famines are caused by a misallocation of the supply, such that some people have enough to throw away while others don't have enough to avoid starvation. What causes the misallocation isn't very relevant either so long as it isn't outright theft.

How do you rectify income distributions? Well, that's a problem with a known solution. The solution is ancient, in fact, and was first pointed out by JohnMaynardKeynes in his work on depressions. Keynes's solution to depression is for the government (primary resource holder) to distribute money (the resource) based on some large scale project involving massive amounts of manpower. If the project has some kind of ancillary benefit, then that's great but its purpose in pulling the economy out of depression is simply to function as a makework scheme with the characteristics that it prevents hoarding and is targeted at the needy.

Note that this level of indirection (famine of food -> famine of money -> solve famine of money -> solve the famine of food) is completely unnecessary. In ancient Egypt, people were paid directly with grain and the pharaohs engaged in massive construction projects as makework schemes. Egypt's economy functioned very well on this basis for eons until the Romans conquered it and "modernized" the economy.

So we have that DoS is an economic problem with a known economic solution. What, then, does this solution look like? The solution involves distributing, either directly or indirectly, the resource according to some makework scheme. This works because you don't care that your clients pay you back but you do care that they pay some purely nominal fee in some medium which is equally distributed (eg, labour) and valuable to the clients so that they avoid making spurious requests.

Whatever resource is attacked by DoS (whether storage, computation or network capacity) the solution is some kind of makework scheme. In the case of storage for connection state, which is what's attacked during SYN floods, the beginnings of a solution is detailed below. In the cases of network bandwidth and CPU, which are attacked during DDoS, it would take a very different solution since they are self-regenerating resources.

Unlike storage, it isn't possible to create so many forged requests that the server is incapable of handling any new requests at all. Which characteristic also makes it much more difficult to attack these resources since a DoS targeted at bandwidth or CPU can only succeed at that point in time and not for all time. Even if one limits storage allocation by expiring it, the number of storage*time blocks available in a given time period is more limited than CPU time slices.

Note also the problem of theft. Effective makework schemes in history rely on the impossibility of stealing another person's labour. In the case of DoS, problems arise when one computer may steal the computing power of thousands of others. This then turns into a mixed economic-security problem, the solution to which is to impose costs on the stolen computers so high that their rightful owners will be so inconvenienced as to motivate them to fix their security problems. IF this cannot be done then DoS has no solution in the current regime.

Finally note that HashCash uses precisely this tactic (Make The Client Pay). The hash cash scheme thwarts spurious requests for human attention by making clients pay in human-visible processing power.

What beautiful mischaracterization of a problem leading up to non-solutions, like the one proposed below. --CostinCozianu

Agreed. What works for a real-world example (famine) won't work for a virtual-world situation, because the constraints of physical presence don't exist. A food distribution system for a famine-stricken area will be accessible only by the locals, and so the travel time to the food centers is a factor, as is the pipeline between centers. The Internet makes nearly every computer equidistant, and so a sufficiently distributed botnet can DOS any server.

Are you some kind of idiot? This issue is addressed explicitly and it has nothing to do with "the constraints of physical presence". (And who the hell said anything about food centers??) It has everything with the ability of computers to steal each other's computing power. And even then, making the client(s) pay is a useful tactic because it increases by a few orders of magnitude the minimum size of a botnet to successfully perform an attack, and increases by a few orders of magnitude more the minimum size of a botnet to perform an attack unnoticed by the zombie computers' owners. If you successfully create a differential between the two, the greed / stupidity of the botnet controller will ensure that attacks are visible to the zombie computers' owners. And by visible is meant annoying, hence they'll tighten security and take their computers out of the botnet.

Your example is famine. If it's a bad one, withdraw it. And your proposal lacks the basic knowledge of how computers communicate, so I thought that a little explanation of why they differ from real-world things like people would be useful. If the resource is purely connectivity, and the client needs only to make the server take some time. and can ignore the server's request, sending another request immediately (if waiting that long). means that your plan is flawed. It's also not kosher to claim that your plan would be good "if IP was designed correctly" or some other dodge, since we have to deal with the initial constraints of the world as it is.

My example is famine and despite a lengthy exposition which it is obvious you haven't read a single word, you don't understand anything about famines. Distance measures are completely irrelevant in either case except perhaps in the case of food distribution which you're the only one concerned with in the first place.

Your example, I remind you. If you think that it is a bad one, refactor it

If the resource is bandwidth ("connectivity" doesn't have any well-defined meaning) then it's a whole different problem. It's then a DDoS problem and not a DoS problem. Your mendacious "we have to deal with the initial constraints of the world as it is" is particularly idiotic given that this proposal would see the reengineering of TCP. A different proposal using the same general tactic would see the reengineering of IP. Either way, your "things have to stay exactly like they are" position is ridiculous in the extreme.

I don't think they should stay the same, but that's not what you started this out as, before you moved the goalposts. Had you started with the premise that IP does not allow for the limitation of client-side to prevent server overload, you'd be fine. But you instead start with a flawed idea, and then spend the rest of the time trying to twist the initial conditions around until your idea might jsut work. And the distinction between DDos and Dos is trivial, and in the real world, irrelevant, because the use of a simgle client to DoS a server has passed into history - the BlackHats? have botnets of thousands of machines at their disposal

IP can be reengineered to prevent those overloads, using the exact same tactic. It's just not my problem to deal with.
- Re-engineering IP will not provide the infinite bandwidth assumed by this "tactic".
- Hi Eric, please go away until you learn the meaning of the word 'economics'. Which I expect to be never. -- RK
- Hi, Richard. I understand and agree entirely with the economic angle. Making the client pay acts as a noise filter. That noise filter can't be used to prevent DoS attacks, though, because DoS attacks can achieve their goal by simply overwhelming the filter. Spam has to reach an audience to succeed. DoS attacks only have to consume a finite resource to succeed. You should be able to grasp the economics of that, if you let yourself try. -- EH
The distinction between DDoS and DoS is utterly non-trivial in an economic sense since botnets are built using stolen property. Which is something that's extremely relevant in an economic sense and can be exploited to shut them down. I've dealt with this issue but you haven't bothered to read or understand it. Hardly any wonder since you don't understand the simple core economic argument, so why would you understand the complex extended one?

Handwaving away reality usually fails. In our world, the number of single-machine DoS attacks are vanishingly small, because it's vastly easier to overload a server from several machines, and because all of the machines are compromised machines. No one attacks from a machine they own, because the backtracking would reveal them to the authorities. All DoS attacks these days are a) distributed and b) launched from compromised machines. So you can ignore the single-machine attacks - they are too easily stopped with other measures.

Now for the case of many machines, if your proposal actually worked, and cause significant load on the client machines, it might have the beneficial effect of forcing the users to claen their machines. But as others have pointed out, your plan, in the current Internet, fails to force the client to perform anything, and it can blissfully send packet after packet, paced enough to prevent user-affecting load. The cumulative effect of 10,000, or 100,000, or 1,000,000 clients sending packets to the server will bring it to a halt, all without any noticeable load on the horde of clients. If you can't understand this simple fact, you are lost.

It's obvious you haven't read this page nor do you understand anything on it. Who are you anyways? Just so I can mentally plonk you. -- RK

Why should I give you that? If you can't aruge the logic away, you want to ignore it?

Just returning the favour. You're already ignoring everything I wrote, I just want to reciprocate. In any case, I think you're Eric since no one else so blatantly ignores what others wrote to repeat their position. -- RK

Nope, not part of the Eric Cabal.

A proposal to thwart SYN floods

A way to prevent SYN floods is to design the protocol so the client must spend some time on each request. For example, in the case of the three-handed handshake, when the client sends a connect request, the server sends back a moderately large number in the current range it services and dumps any state information. The client now has to factor this number into its component primes. This takes 1/10 second. The client then sends the results back to the server, the server verifies the result and verifies that the product lies within the current service range.

Making each request cost the client a little bit of CPU time ensures that clients can't take more than a small share of resources. Under the above scheme, a computer wouldn't be able to make more than 10 TCP requests each second. Note that this thwarts botnet attacks also since subverted computers would grind to a halt and cause their owners to intervene. Either that or it would multiply the minimum size for a successful botnet attack by several orders of magnitude.

Some problems with this idea

A malicious client can flood the server with numbers and factors without regard for correctness. Therefore the client doesn't spend much time generating them, and the server has to take up CPU time verifying them. In fact, because the server dumps any state information, a client can even use the same correct solution over and over, since the server can't recognize that it's the same client over and over.
Note that it doesn't matter how inexpensive the numbers are for the server to generate. What matters is that a client can cause the server to transmit them in response to each request. The server will have some limit to the volume of requests it can handle. Once that limit is exceeded service is denied. Hence this is no protection against denial of service.
- Indeed the proposal doesn't prevent all DoS attacks, it only makes them harder to do.
- Overwhelming a server with requests is no "harder" with this plan than it is now. This plan only places a burden on clients that need to establish a legitimate connection. DOS nodes are free to ignore that burden.
- And have you pulled this judgement out of your ass or do you have any arguments to back it up? I see someone has deleted my response to this so-called "criticism".
- I must have missed something here. Under this scheme, why can't a DoS client simply initiate an arbitrary number of requests, forcing the server to deal with them? In what way does making the client do work to complete the connection stop the client from swamping the server with initial requests?
- [Right. The most infamously successful DenialOfService attacks historically succeeded by sending exactly one packet per attack, e.g. the half open attack, Christmas tree packets, etc. The reply from the server of no interest, and is typically actively avoided altogether by IP spoofing. It is, on the other hand, possible to examine DoS issues at higher levels; there was a DoS attack on sendmail that caused it to fill up its own disk.]
- SYN floods work not by overwhelming CPU but by overwhelming the temporary storage dedicated to keeping track of half-open connections. The above proposal stops this particular vector by eliminating the need for temporary storage. The server sends the half-open state back to the client so that the client can later prove the connection is fully open. Now, if SYN floods worked by overwhelming CPU or network bandwidth then that would be a different problem.
Round-trip times across the 'net are frequently far in excess of 1/10 second. Adding 1/10 of a second, even 1/2 a second, doesn't matter.
This proposal does little about adverse parties opening, then dropping, connection - a common attack vector. Many real-world DoS attacks are aimed lower in the protocol stack than what the proposal addresses.
- Well, there's the evidence I needed that Ben's editing out the economics prologue to the proposal wasn't a good idea. If you can explain how DoS attacks can't go lower in the protocol stack than what the proposed solution addresses, please do so.
The proposal slows legitimate users down as well as adversaries. In many cases, network traffic involves lots of small, separate transactions rather than one connection maintained for a long time.
- If the delay is 1/10 or 1/2 a second, it really doesn't matter.

Works against spam, not DoS

The proposal is essentially HashCash. Basically, HashCash is a scheme whereby the sender of an email has to include the solution to a SemiHardProblem (partial hash collisions), where one of the parameters to the hard problem is the text of the message (or a digest thereof). Solving the SemiHardProblem requires a significant fraction of a second of CPU resources for the sender; but the solution is verified in microseconds by the receiver. Email filter can be programmed to discard emails without valid solutions as spam (along with other filters, such as accepting emails from known senders, discarding emails with V1AGRA in the header, etc.).

This prevents spam, but not Denial of Service. The email server has to remember which emails had which hard problem, or else a spammer can use any solved problem to get through the filter. So a DoS attacker (not a spammer), would overload the server with emails and the server would have to remember state, and remembering state is the weakness that most DoS attacks are based upon.

How in hell do you manage to read "keeps state" in "the server dumps state"? But I don't think Scott wrote that passage above, I think it's Ben deeply misunderstanding the situation.

The idea is ridiculously useless

It is completely and irremediably broken. Of course, RK wouldn't know because he has disdain for anything ComputerScience, and he cannot be bothered to write it down properly (meaning at least pseudo-code). So there's this discussion going at the level of handwaving vis-a-vis the "bottom of protocol stack" and "higher up the protocol stack". It's an example of how not to design (designing from the position of ignorance) coming from our chief InteractionDesigner. -- CostinCozianu

Note how all that "bottom of protocol stack" and "higher up the protocol stack" handwaving crap was introduced by nitwits who can't bother reading the proposal in the first place. If there's a problem with it, it would be more constructive to point out what it is rather than this grandstanding you're so fond of. -- RK

No, you write it down properly, and then you'll see that it's bloody obvious that if the server discards the state, it'll be flooded by easily forged packets regardless. By the way, if you write down what is the logical condition that you try to prove about the protocol, you may be able to get to a half decent design. That would be proof driven design, as recommended by EwDijkstra. -- Costin

No, it would be engineering. Don't think that what you happen to mean by the word is the same as what designers mean. And don't presume that your version of the word 'design' is more authoritative than the one used by a field that names itself after the word.

Yeah, HumptyDumpty and all that. It's a simple exercise: try to find out if you know what you are trying to design. And this can be done by writing it down. What is the condition for any design to be considered successful? When you "design" a UI, that would be subjective. When you design a protocol against DOS, it should be precise. And that's design. The engineering part is refining and implementing the solution. But don't think that if you present a so called "solution" in free form, fuzzy English, that's design. Because it ain't.
Except that "denial of service" isn't a problem characterizable in physical or mathematical terms. It's an economic problem characterizable only using economic language, what you might denigrate as free form, fuzzy English. And it's rather annoying that I started by using the precise economic language but first you objected because it wasn't mathematics, and then Ben deleted it.

So you'll get forged packets, so what? It's not like they'll overwhelm temporary storage because under the proposal there isn't any anymore. The only things they can overwhelm (resources they can exhaust till others starve) are CPU and network bandwidth. CPU isn't a problem since the network stack isn't CPU bound. And overwhelming network bandwidth lends itself to a completely different attack pattern than SYN floods. -- RK

The forged packets will make you have the socket open on the server. Cause you don't know which sockets are from legitimate clients and which are from flooders. And that's DOS for you. -- Costin

Under the proposal, the socket doesn't even open until the client has solved the SemiHardProblem the server requires. There are no open sockets with forged IPs. I don't understand why people persist in assigning the flaws of TCP/IP to a proposal that seeks to redesign it entirely.

Here's the key: "The socket doesn't even open until the client has solved the problem". That would be deriving by the way of "because I think so".

In order to prevent (or generate) a DoS attack, all layers and components of the system must be understood. As pointed out above, many attack vectors work by consuming system resources which a system must make available to outsiders in order to be useful. If I'm running a server, I've got to accept incoming connections so legitimate clients can use my service; until a connection is negotiated a server cannot distinguish between a connection request from a legitimate user, and from an attacker; making excessive connections (or irregular ones which stimulate incorrect behavior in a system) is a good way to attack a system. In order to prevent this sort of attack from occurring, a server would have to distinguish between hostile and friendly connections before the connection is made. At the low levels of the "protocol stack" (particularly at the IP layer and TCP layers, where many such attacks take place), there is little or no authentication performed - thus spoofing is easy to do and difficult to detect. Application-layer authentication schemes, such as HashCash, are of no use against attacks against the network, transport, or session layers. (Conversely, of course, SYN cookies other low-level defenses aren't of much use against spam email).

Under the proposal, you can't make a connection at all until after you've proved that you've invested some amount of computation into it. Authentication is a red herring.

Be careful of possible different meanings of "connection" in this context. One meaning would be the establishment of a session via a protocol such as TCP; a SemiHardProblem could be made a prerequisite to establishing such a connection at the transport/session layer.

But to negotiate such a thing, the host must be open to receiving "connect requests" (which the word "connection" may also refer to) from the outside. And for the protocol to work as describe, some state must be maintained between connect requests and the subsequent answer to the challenge; otherwise the server can't verify that the challenge is correct (or that a submitted answer to the challenge is indeed what was asked). If such state is maintained, an attacker could initiate numerous connect requests, and never answer the challenge.

One possible workaround to the state-maintenance would be for the challenge to be digitally signed by the host; that way a hostile attacker wouldn't be able to "manufacture" challenge answers and avoid the required investment of computation. OTOH, that opens up a new attack vector - just flood the server with bogus answers.

''Under the above proposal, there is a global window of challenges and no state is maintained per-request. So for example, the server could be sending challenges between 120 gagillion and 121 gagillion. And in the next minute, it's between 121 and 122, and a minute after that it's 122 and 123, and so on. You've got a minute to answer, after that your challenge is obsolete. As stated, the only state kept around is what window of numbers (challenges) you're servicing and this is global to all users and O(1).'

Wow ! The attacker solves it once (in .1 or .5 seconds as you like it) and sends 1000 responses. You don't keep state, so you don't know if you have seen the "solution" before. Next the attacker doesn't even have to solve it, he just sends a bunch of numbers hitting in the vicinity of your challenge, so as to probabilistically hit the interval. If you want to verify that it's a correct prime decomposition you have to spend CPU on the server. Because you maintain no state you have to spend the same CPU power 1000 times for the same attack. Oh, and by the way, a legitimate user will pick the challenge 1 second before it expires and sends back the response one second after, tough luck buddy. So now you really ought to keep a list of valid intervals to increase the window of opportunity for legitimate users. And you've just increased it for the attackers as well. That's a few of the many ways in which your "design" falls flat on its face.
You know Costin, you accuse me of not thinking rigorously and of proposing ideas that are obviously false, but you're doing that yourself. Worse because while you claim that my ideas can be disproved "if you think about it", I claim your objections can be disproved without having to think about it at all. And here follows my proof of that claim;
First, a window doesn't have to advance totally, it can advance piecemeal. So every 6 seconds the window advances 0.1 gajillion and after 60 seconds it's advanced from 120 gajillion to 121 gajillion without anyone being left out in the cold.
Second, no one said that you must advance through the space of challenges continuously, you could easily advance in a pseudo-random fashion. So at the beginning, the server might start with 120 gajillion to 121 gajillion. After 6 seconds, it could add 179.2-179.3 gajillion so you have 120.1-120.9+179.2-179.3e Then after another 6 seconds it adds 64.5-64.6. You get the picture?
I get the picture that you think too sloppily, you have not disproved anything and you do not even intend to, but you want to do more handwaving. In any case, it doesn't work this way - you throw a bunch of handwaving and you want others to find faults in a non-existent design, an ever-moving target. You'll move it until it resembles nothing of what you proposed initially. All my objections apply to your "modified" proposal, and undoubtedly you'll modify it once more, and so on and so forth, so I'm not playing that game. If you want to propose something seriously, good; if not, why would anyone waste his time with somebody ShiftingTheBurdenOfProof?
Okay, first of all I never proposed any specification or engineering blueprint. And actually, I never even proposed a design. What I intended was an approach justified using economic reasoning. It's not up to me to make it work since it's an engineering project. It's only up to me to justify that the approach is sound, by correctly characterizing the problem as an economic problem and given the general form of any economic solution to this problem. The implementation details are not my concern, they're your concern actually. Given that there must be a solution to the problem of DoS and given that the solution has this form, then it is now your job to construct an actual working solution. You're the software engineer, not I. So why don't you do your job instead of whining about the fact that I'm not doing yours? So your accusation that I'm shifting the burden of proof? Well, you get points for the pre-emptive attack, but you lose more points for even starting a war front you're on the losing side of.

Having to sign challenges is much more computationally intensive than just shoving them back out the door.

The "much more" part of that, as opposed to simply "more", is not at all clear to me, given my experience with the cost of the kinds of algorithms in question. -- Doug

No matter how you define "connection" or "socket" in this protocol, there is a limit to the number of initial requests a server can respond to in some time period. CPU and memory may not be the limiting factors, but network bandwidth is finite. All DoS nodes have to do to push the server to that limit is send initial requests. The protocol does nothing to restrict their ability to do that. Once the server's limit is reached, legitimate requests can't be handled. This should be obvious. -- EricHodges

And network bandwidth at that level is under the auspices of IP, not TCP. You'd have to re-engineer IP to thwart that.

But you haven't, so you haven't prevented DoS attacks. And IP doesn't matter. Any network will have a bandwidth limit regardless of protocol. -- EH

The only thing which prevents this sort of attack is a good firewall guarding the part of the network where the pipe gets skinny. For most organizations, unfortunately, that point is beyond their immediate control - instead it's at their provider's facility. Traffic analysis and other heuristic techniques can sometimes sniff out (or at least detect) a DoS attack.
Firewalls don't help when you need to allow access to a service. DoS attacks are based on exploiting the vulnerability of allowing access. -- EH

May I ask a question, that is not directly related to the aspects discussed so far? Yes, thanks. If this concept was abopted in general, wouldn't this immediately mean, that rich clients get better service, than poor ones? And with our society having at least 6 orders of magnitude in income, wouldn't that put the poor quickly below the ability to use the net for anything useful? Can this concern be addressed? -- GunnarZarncke

No, because you're not making clients pay in money, only in computing power. And computing power only has a spread of 2 or 3 orders of magnitude at best. And income has a spread of 9 orders of magnitude, not 6. You forgot to count the third world. -- RK

Discussion continued on LogarithmicWealth.

FebruaryZeroSix

CategorySecurity CategoryInternet CategoryDistributed