On Wed, Feb 07, 2007 at 02:34:53PM +0100, Daniel Hartmeier wrote: > I think SYN cookies[1] would be stateless, but I don't know > how they hold up against 130k pps.
Back in the mid-90s, I worked at a well-known search engine company. We used Pentium Pro servers and when we enabled SYN cookies, the web servers quickly became unresponsive. Apparently the cost of computing MD5 for each SYN, even under non-DoS conditions, was too much. Now, many things have changed since then, but I'm not convinced that CPU speeds versus network speeds are such that a typical server could keep up with a typical full-bandwidth DoS flood. > And they have their own > drawbacks (I think non-randomness of sequence numbers isn't > even mentioned). There is a 24-bit value s that is based on a cryptographic function, which in turn is based on (src ip, src port, dst ip, dst port, t) Assuming something suitable for the secret cryptographic function (i.e. indistinguishable from a random mapping), then someone attempting to do blind IP spoofing would have 24 bits of randomness to guess against instead of 32. Given the allowable window sizes, it's not that hard to spoof a bunch of packets with varying sequence numbers in order to terminate a TCP connection (or insert data), regardless of how many bits of the sequence number are random (2^32 just isn't that big any more). Given that botnets are increasing in size, and that network services are relatively secure against pre-authentication vulnerabilities, it seems that we should be worried about DoS, and that perhaps the best approach is to design something that operates on top of UDP or that is an alternative to TCP that involves: 1) anti-DoS (memory consumption) feature involving no state allocation on the part of the server until the client has proven it can send and receive data as a particular network address. This prevents spoofing network addresses in order to fill the server's memory, and once the client has been nailed down to a network address they can be limited on that basis. Note that botnets involve numerous network addresses, so this cannot address a DDoS involving botnets. To prevent spoofing, this must involve sending the client a value that he or she cannot easily predict. This implies that it must be cryptographically secure, which implies that it must involve some non-trivial amount of computation on the part of the server. Since CPU speed is increasing faster than memory capacity, and since most systems deal with maximized CPU usage better than maximized memory allocation, this seems a reasonable tradeoff to make. Note that the obvious CPU consumption countermeasure involves allocating memory, so there is no easy solution for dealing with both problems simultaneously. 2) Scalable proof-of-work by client before server allocates resources. Basically the server provides a challenge that the client must spend resources to solve, and then the server must be able to validate the client's answer efficiently. This deals with abuses like spamming or DoS by forcing the client to spend resources in proportion to the resources the server uses. Since most client machines are single-user machines asking for a single request to be satisfied, this will not lead to any major performance problems (in most cases). Since the resources available to the typical client will increase over time, the protocol should be able to scale up the amount of work required in reasonable increments without protocol/software changes. Resource-limited clients should be able to refuse to perform requests that require too much work, or requests from servers which may themselves be abusive in requiring too much work. One possible implementation would be to provide the client with the output of a cryptographic one-way function, and an indication of the input space in which to search for the preimage. The client then tries inputs until it discovers the preimage. Other possibilities include computation problems from the domain known as "NP", which have the property of being expensive to solve, but inexpensive to check the solution. -- Good code works. Great code can't fail. -><- <URL:http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED]
pgpbE6D9FuDP4.pgp
Description: PGP signature
