Date: Thu, 8 Jan 2004 11:16:07 -0800 (PST) From: Nate Lawson <nate@root.org> To: Andre Oppermann <andre@freebsd.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet ip_icmp.c tcp.h tcp_input.c tcp_subr.ctcp_usrreq.c tcp_var.h Message-ID: <20040108110434.R36017@root.org> In-Reply-To: <3FFD9B72.C3BD7F3C@freebsd.org> References: <200401081740.i08He8J9063202@repoman.freebsd.org> <3FFD9B72.C3BD7F3C@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 8 Jan 2004, Andre Oppermann wrote: > Andre Oppermann wrote: > > > > andre 2004/01/08 09:40:07 PST > > > > FreeBSD src repository > > > > Modified files: > > sys/netinet ip_icmp.c tcp.h tcp_input.c tcp_subr.c > > tcp_usrreq.c tcp_var.h > > Log: > > Limiters and sanity checks for TCP MSS (maximum segement size) > > resource exhaustion attacks. > > The fix for 4-STABLE is here: > > http://www.nrg4u.com/freebsd/tcpminmss-4stable-20040107.diff > > As usual if there are any problems contact me immediatly. Especially > when you see any disconnects during nomal activity. It might be that > I've missed a scenario or case where an application is legitimatly > sending more than 1,000 small tcp segements per second. However I've > looked and tried hard to find one. Is this disabled for lo0? There are plenty of apps that read/write small segments as part of a control protocol. Of course, they can't change the MTU and the default is 16k. I think the SLIP MTU was 256 so perhaps a high-speed SLIP application might be hampered. But I see a comment in your code about that case. So in actuality, we're probably ok. The magic numbers just make me uncomfortable though. -Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040108110434.R36017>