Date: Mon, 10 Nov 2003 01:11:20 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Andre Oppermann <oppermann@pipeline.ch> Cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review Message-ID: <20031110005543.C532@odysseus.silby.com> In-Reply-To: <3FAE68FB.64D262FF@pipeline.ch> References: <3FAE68FB.64D262FF@pipeline.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 9 Nov 2003, Andre Oppermann wrote:
> Hello all,
>
> this patch contains three things (to be separated for committing):
I don't have much time free in the next week, so I cannot do a complete
review. However, I just did a quick readthrough.
> tcp_hostcache
This looks good to me, I've been waiting for you to finish it for a long
time. You actually missed a point:
- Ensures that a cached entry isn't added until the 3WHS is completed.
This should help make synfloods with random source addresses less
damaging.
Would it be possible to provide a way for netstat to view the host cache
table? I think that it would be useful.
> ip_fastforward
No comment, I didn't read through this part, and I'm not familiar with
the forwarding code.
> tcp bug fixes and MSS DoS attack prevention
Generally good, but:
> - adds tcp_minmssoverload which disconnects a TCP session if
> it receives too many (1000) packets per second whose average
> segement size is lower than tcp_minmss
> - DoS attack 2: make MSS very low on local side of connection
> and send maaaany small packet to remote host. For every packet
> (eg. 2 bytes payload) a sowakeup is done to the listening
> process. Consumes a lot of CPU there.
I don't think that your patch for this really solves anything. Anyone who
would write such a program could just as easily make it use concurrent
connections, have it auto-reconnect, and/or have it only send 900 packets
per second. I think that you should remove this section of the patch, but
leave a comment about this problem existing so that it will be thought
more about in the future.
After the rest of the code is in, we can brainstorm on other possible
solutions... I think that Mini's idea of approaching it as an optimization
is the correct one.
Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031110005543.C532>