Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
Please listen carefully, as our opinions have changed.

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.

user:
pass:
register,


           

Please log in.
Before you can vote, you need to register. Please log in or create an account.

Stateless TCP/IP server

A limited document server which would be immune to most DOS attacks
  (+2, -1)
(+2, -1)
  [vote for,
against]

The proposal is for a simple document server which could be placed on an 'exposed network' without fear of compromise, because (1) it would not have to keep any state information about incoming connections, and (2) with one exception, outgoing packets would be no larger than incoming packets; even in that case, they'd not be much larger.

Because the server would use TCP/IP protocol, people behind firewalls would be able to access if if the required port was open, without any special handling by their firewall.

The server would respond to ARP packets in the usual fashion, and to TCP/IP packets destined for the proper port. All non-reset TCP packets would generate an identically-sized TCP packet in return, with one exception.

For every TCP packet, the reply should have the source and destination addresses and ports swapped from the original. Except as noted, the seq and ack numbers should be passed exactly as received.

A SYN packet should return a SYN+ACK packet with a sequence number equal to the received sequence number, and an ack number one above the received sequence number, and with MSS set to 512 bytes [this is the one packet that may be larger than the original, because of the need to include MSS].

A RES packet should be dropped on the floor.

Other packets would be sent back with seq and ack numbers as received, and with the same-sized data payload as received.

For the server to return useful information, the documents to be served should be encoded in such a way as to not contain any 'FF' characters. Assuming each file has a 32-bit ID, the entity requesting data would simply send out a stream of [file-id][counter], where 'counter' was a file offset counter which increased by eight each time it was sent.

The server, upon receipt of each data packet, would look through the data payload for two bytes, eight bytes aprt, that differed by eight. It would recognize this as the LSB of the counter, and could thus tell what portion of the file was being requested. It would then return a data packet, identical in size to the one received, with the appropriate portion of the requested file.

If, for some reason, the server could not make sense of the received packet's data payload, it would return FF's. The client would recognize this occurrence and request the missing data later.

Although the protocol would not be terribly efficient, the server would be able to handle as many connections as bandwidth permitted without difficulty. If someone wanted to open up 1,000 connections each from 1,000 computers and just leave them open, they could. All of the connections would remain open for as long as the clients wanted them, but the server wouldn't care one iota.

Anyone ever heard of anything like that?

supercat, Oct 12 2004

RFC 793: TCP http://www.ietf.org/rfc/rfc793.txt
[jutta, Oct 12 2004]

[link]






       I've written TCP implementations, Jutta. I'm aware that in some ways the stateless implementation is sub-optimal from a packet utilization standpoint, but I believe that if the client is RFC-compliant the server will generally behave in RFC-compliant fasion as well.   

       In normal operation, the client sends a server a packet, the server sends the client a packet, the client sends a server an ack, and the server sends the client an ack. If any packet gets lost along the way, the client will retransmit and everything will recover gracefully.   

       I've not tested the 'echo server' concept over a WAN, but I have tested it on a local ethernet and it does work. The server (which I coded on "bare metal") has no clue who's connected, but the clients all think they're connected to it.
supercat, Oct 12 2004
  

       I didn't intend the link to RFC 793 as a comment, just as something that might be useful in considering the idea.   

       [webchat], how about giving a source for the rumor you're amplifying? In any case, this idea isn't about DDOS attacks (which rely on many hosts), just about DOS attacks (which rely on a small effort in the client causing a large effort in the server.) Battling DDOS usually requires communication among nodes in a network.   

       Why the weird addressing in the requests? What if two file ids happen to be 8 apart?. For a proof of concept, I'd just make the requests 12 bytes, have the sender send -1 <fileid> <offset>, and outlaw -1 as fileid or offset.
jutta, Oct 12 2004
  

       Because TCP is a byte-oriented protocol, there is no application-level subdivision into packets. And because the server is completely stateless, it has no way of knowing what the client wants other than what happens to arrive in any TCP packet.   

       If the application always sent out its data in simply-formatted packets, and waited for each reply before sending the next packet, things would be nice and simple and beautiful. But that isn't realistically going to be the case.   

       The idea here is that the server can look at any portion of the data stream (unless it happens to fall in a packet of 15 bytes or less) and tell what the application wants it to do without needing any outside information. There would be some more 'interesting' approaches available than looking for an 'counting' byte to establish synchronization, but I thought the counting-byte method was the easiest to describe.
supercat, Oct 12 2004
  

       [webchat] the link on the left, called [link] is the place to put your links.   

       (Why do I feel like Dr. Seuss?)
reap, Oct 13 2004
  
      
[annotate]
  


 

back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle