Seeing that most people take a look at the "client puzzle protocol" and say "but this doesn't solve anything?!" I thought I'd take the opportunity to (re)introduce an idea of mine. I mentioned this three months ago, but noone seemed interested. This time around, I took the time of explaining WHY this is a good idea, so read on... Why do we need a better SYN flood protection than the current SYN cookies? -------------------------------------------- Current SYN cookies are carried in the sequence number field, which makes for great compitability with all implementations of TCP. However, this small field is unable to carry all desired information, which either makes for loss of functionality, or RAM usage on the server side, the latter being exactly what we wanted to avoid by using SYN cookies. Also, using the sequence number field to carry extra information makes for a smaller random space of the TCP ISNs, which in turn makes TCP blind spoofing easier. In this document, I propose a new standard for implementing SYN cookies using a TCP option. This enhancement does not break any existing TCP functionality, but acts as a helper during SYN flooding attacks. It enables the connection terminator (server / firewall) to remember ANY data from half-open connections while still consuming NO RAM whatsoever. Why am I mailing this here rather than to the IETF? --------------------------------------------------- 1) Because I think this may be hard to introduce without some backup. 2) Because this is more of a firewall issue than a host issue. SYN flood prevention in a firewall protecting a large network is VERY expensive in terms of RAM usage if one is to do it right. The Issue --------- Upon receipt of a SYN packet, we don't want to use local resources to remember it; there is no way of knowing whether it is legit or part of a SYN flood The ideal situation would be to be able to respond with a SYN+ACK packet, and completely forget about original SYN packet. This is not possible today, since there are a number of things that we'll need later on in the connection, such as the proposed MSS, SACKPERMIT, WSOPT information, etc ... The SYN cookie schemes of today utilize the sequence number field to send information to the connection originator; this works since we know that that information is passed back to us unchanged later on. The problem is that the MSS/SACK/WSOPT info must be remembered locally, still consuming local resources, albeit not as much as before. New proposed solution --------------------- Enter, stage right, two new TCP options: TCPOPT_NECHO and TCPOPT_NECHOREPLY. *clap* *clap* *clap* I'd propose that TCPOPT_NECHO could be used in the SYN+ACK packet to transmit all the data that the connection terminator would want echoed from the connection originator; this is the same data that we otherwise would have to store in RAM for the half-opened connection. The connection originator would then respond with a TCPOPT_NECHOREPLY containing all the data received in the NECHO, unaltered, in its ACK packet. The data in these options, or its length, is NOT defined by any specification, and their use is NOT regulated by any means. All that is required is that a TCP receiving NECHO will take all its data and send out an NECHOREPLY with the same data in its next packet. In the option data, we would be able to place all the information that our hearts could desire, along with a hash for authentication. This data could include MSS information, window scaling, a boolean saying whether SACK is in use, etc ... As I said earlier, the format of the option data is not specified. It does not have to be. Its contents are only meaningful to the host sending the NECHO option, and need not be understood by anyone else. This also leaves an open opportunity to use this option type somewhere else in the future. RST cookies, anyone? The effects ----------- In situations where we're short of memory, we can actually drop all information related to SYN_RECVD connections, and still have everything work when the ACK packet arrives later on, with all the information needed to setup the connection contained in the NECHOREPLY option. How much does one need to implement ----------------------------------- Connection originators (ie all TCP stack implementors) only need to be able to REPLY to NECHO options. They do not need to be able to send out NECHOs with SYN cookie information of their own. Connection terminators (firewalls, servers) need to implement the generation of NECHO options and consequent parsing of the incoming NECHOREPLY options. Pros ---- We achieve everything that SYN cookies were initially intended to do, including zero RAM usage for half-open connections. Cons ---- This won't help connection originators whose stacks don't reply to NECHOs. It also means a bit of work on the TCP stacks around the world. NOTE: My proposed solution does ***NOT*** break today's TCP functionality! It is designed as an optional "helper" during SYN flooding situations! So what's the big idea then? ---------------------------- My (futile?) hope would be that client side developers start implementing the mechanism to REPLY to NECHO requests; it's low cost, simple, and they don't have to have the first clue as to what it does. Connection originators having the REPLY mechanism would benifit by always succeeding in connecting to a server that sends out its SYN cookies inside an NECHO option, even if it is under heavy SYN flooding. Connection originators NOT supporting this option would have a hard time getting to such hosts. I would hope that this is incentive enough to get TCP stack implementors to incorporate the reply functionality in their code. Living alongside today's SYN cookies ------------------------------------ It is completely possible to utilize BOTH types of SYN cookies on the same server. Hence, when the server runs out of resources to handle sequence-number-carried SYN cookies (which work regardless of the originator TCP implementation), the new option-based SYN cookies would let people with "new" TCPs connect anyway. Why "NECHO"? ------------ There is already an option called "ECHO", see RFC 1072, but its length is assumed to be 6 bytes (4 bytes data). We need more than that to be able to relay all information - for future needs. The "N" in "NECHO" is simply "New". We could also call it "VECHO", for "Variable (length)" One COULD quite conceivably utilize the ECHO option; maybe a lot of stacks support it today? I don't know. However, I don't know if it is legal to use in the SYN+ACK packet. 4 bytes could carry 2 bytes of MSS, 1 byte of window scale, 1 bit of SACKPERMIT, and have 7 bits to spare. (What about timestamps? I have to go read RFC 1323 again...) The whole concept seems kind of .... cramped. Maybe one could use ECHO and violate the specification by sending more than 4 bytes of data? Welpz. Enough rambling and unfounded speculation for one day. Ideas? Flames? Comments? Some backup that I can hand over to Bellovin et Co? :-) Spontaneous applause? :-) /Mike -- Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 ÖRNSKÖLDSVIK Phone: +46 (0)660 105 50 Fax: +46 (0)660 122 50 Mobile: +46 (0)70 248 00 33 WWW: http://www.enternet.se E-mail: mikael.olssonat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:08:19 PDT