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
|