An option-based implementation of SYN cookies?

[Mikael Olsson <mikael.olsson () enternet se>]

Yes, I know, I'm so-la-la three years late in adding to this
debate, but who knows, maybe something good will come out of
it.

I'm assuming that the reader understands today's implementation
of SYN cookies (and that I do aswell :-P )


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 we want echoed from the connection
  originator. The connection originator would 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.


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 people whose stacks don't NECHOREPLY things.
  If the server side of a connection is dropped due to RAM shortage,
  they'll probably have to retry the connection from scratch.


So what's the big idea then?
  My (futile?) hope would be that people start implementing the
  NECHO/NECHOREPLY mechanism; it's low cost, simple, and they
  don't have to have the first clue as to what it does.
  
  Connection originators having the NECHO/NECHOREPLY 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 NECHO/NECHOREPLY options 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".  

  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?
Spontaneous applause? :-)
A better place to discuss this?

/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.olsson () enternet se