Re: [PATCH,RFC] explicit connection confirmation

[Lennert Buytenhek <buytenh@gnu.org>]

On Thu, Nov 07, 2002 at 02:49:18PM +0100, bert hubert wrote:

> > > I think this approach smells, btw - doesn't this mean that processes
> > > will now be woken up on receiving a SYN instead of after completion
> > > of the handshake?
> > 
> > Yes, it does mean this.  You are free to suggest alternatives.
> 
> I like having this ability - I dislike offering it to an unsuspecting
> userspace.

Userspace needs to turn on the option first, so your 'unsuspecting'
does not apply.


> > > Would make a synflood all the more interesting..
> > 
> > In case of a synflood, the TCP stack will fall back to sending
> > syncookies as it normally does.
> 
> Yes, but in your setup, a spoofable SYN packet will spawn a process for many
> daemons, unless they are modified to first try to read/write to the socket
> (which might block!) before forking/pthread_create()ing.

Again, if the app decides to turn on TCP_CONFIRM_CONNECT, then it's
up to the app to deal with it properly.  There are very good reasons
for not turning on TCP_CONFIRM_CONNECT by default, which is why it
is not on by default, and why grafting a setsockopt onto every daemon
there is out there is definitely not a good idea.


cheers,
Lennert