| To: | Lennert Buytenhek <buytenh@xxxxxxx> |
|---|---|
| Subject: | Re: [PATCH,RFC] explicit connection confirmation |
| From: | bert hubert <ahu@xxxxxxx> |
| Date: | Thu, 7 Nov 2002 14:49:18 +0100 |
| Cc: | netdev@xxxxxxxxxxx |
| In-reply-to: | <20021107120956.GA10832@xxxxxxx> |
| Mail-followup-to: | bert hubert <ahu@xxxxxxx>, Lennert Buytenhek <buytenh@xxxxxxx>, netdev@xxxxxxxxxxx |
| References: | <20021107093207.GA30666@xxxxxxx> <20021107112733.GA24283@xxxxxxxxxxxxxxx> <20021107120956.GA10832@xxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.3.28i |
On Thu, Nov 07, 2002 at 07:09:56AM -0500, Lennert Buytenhek 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. > > 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. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | test, Jacky Hsiao |
|---|---|
| Next by Date: | Re: [PATCH,RFC] explicit connection confirmation, Lennert Buytenhek |
| Previous by Thread: | Re: [PATCH,RFC] explicit connection confirmation, Lennert Buytenhek |
| Next by Thread: | Re: [PATCH,RFC] explicit connection confirmation, Lennert Buytenhek |
| Indexes: | [Date] [Thread] [Top] [All Lists] |