> From: Michael Richardson
>
>  I was going to implement this for a firewall I used to work on. It
>would be much nice for a user to see "Connection refused" than "No
>data" when the site they want to access isn't allowed. (e.g. in a
>transparent HTTP proxy).

my feeling exactly.  if i have a "secure" machine, this would make it
seem more secure from the attacker's pov.

>    Andrew> i've got my box at home to the point where accept()
>    Andrew> returns after the first syn (via a setsockopt() on the
>    Andrew> "master" socket), subsequent syns are simply "absorbed",
>
>  Yes, this is much better than a global parameter, I sort of feel
>that perhaps it should be a new system call: eager_accept()? 
>
>    Andrew> i haven't got the reset packet working yet (although my
>    Andrew> computer notices that that's what i'm trying to do) and
>    Andrew> then there would be some finishing work (like making it a
>    Andrew> config option, and adding a sysctl so that you can compile
>    Andrew> it in but turn it off for later), but other than that, i'm
>    Andrew> pretty much done.
>
>  Huh, so you would be global? Bad.

it would be global in the sense of yes-you-can-use-it/not-supported,
not in the sense of this-is-how-sockets-will-behave-here.

my theory was as follows:
1) add eager support to your kernel...
2) create, bind, listen, and all that other socket stuff for the
   server socket that you normally do...
3) issue a setsockopt() on the server socket...
4) accept on the server socket, which will return after the initial
   syn packet...
5) decide whether to keep the connection or not and using an ioctl on
   the "connected" socket, tell the tcp to send a syn-ack, or a
   reset...
6) use the slave socket as normal...

the extra steps are 1, 3, and 5.  other than that you would be using
completely normal sockets.  and for services that you don't want
serviced as "eager", simply don't do steps 3 or 5 (wouldn't have any
effect anyway).

>  I'm also worried that you would make SYN attacks worse. That was one
>reason for not implementing things. 

that is one concern that perry has voiced.  and i can see what he's
talking about, since each spurious syn will now result in a socket to
be serviced, not a socket to be eventually dropped from the pcb list.
in that case, eager sockets would lose...

-- 
|-----< "CODE WARRIOR" >-----|
andrew@echonyc.com (TheMan)        * "ah!  i see you have the internet
codewarrior@daemon.org                               that goes *ping*!"
warfare@graffiti.com      * "information is power -- share the wealth."