From owner-cvs-all@FreeBSD.ORG Thu Jan 8 11:16:11 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC51616A4CE for ; Thu, 8 Jan 2004 11:16:11 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 825D143D53 for ; Thu, 8 Jan 2004 11:16:06 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 36092 invoked by uid 1000); 8 Jan 2004 19:16:07 -0000 Date: Thu, 8 Jan 2004 11:16:07 -0800 (PST) From: Nate Lawson To: Andre Oppermann In-Reply-To: <3FFD9B72.C3BD7F3C@freebsd.org> Message-ID: <20040108110434.R36017@root.org> References: <200401081740.i08He8J9063202@repoman.freebsd.org> <3FFD9B72.C3BD7F3C@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 19:16:11 -0000 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