From owner-freebsd-net@FreeBSD.ORG Thu Dec 30 10:42:18 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8508C16A4CE for ; Thu, 30 Dec 2004 10:42:18 +0000 (GMT) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 067CF43D4C for ; Thu, 30 Dec 2004 10:42:18 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 23465 invoked from network); 30 Dec 2004 10:42:16 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 30 Dec 2004 10:42:16 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 30 Dec 2004 04:42:15 -0600 (CST) From: Mike Silbersack To: Maxim Konovalov In-Reply-To: <20041229155419.I74642@mp2.macomnet.net> Message-ID: <20041230042939.L35911@odysseus.silby.com> References: <20041218033226.L28788@odysseus.silby.com> <20041229155419.I74642@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: net@FreeBSD.org Subject: Re: Update: Alternate port randomization approaches X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 10:42:18 -0000 On Wed, 29 Dec 2004, Maxim Konovalov wrote: > On Wed, 29 Dec 2004, 03:02-0600, Mike Silbersack wrote: >> This appears to work for Igor, and it seems safe enough to commit before >> 4.11-RC2. But, if possible, I'd like a few more sets of eyes to doublecheck >> the concept and code; please take a look at it if you have a chance. > > Again, it's not clear for me why we don't follow our usual > deveplopment cycle here: commit & test in HEAD and then MFC to STABLE? > > -- > Maxim Konovalov The problems random port allocation exposes only occur in situations where machine A is making repeated connections to machine B, so it's limited to situations like front-end web proxies, connections to database servers, and a few other things. General web servers, ftp servers, SMTP servers, etc, aren't affected. So, committing to -current won't cause us to learn anything; specific testers are needed. I should have worked on this issue months ago, but I didn't, so I'm trying to come up with something safe as quickly as possible. This is necessitated because 4.11 is going to be the last in the 4.11 series, so this can't be pushed off until after 4.11 is published - there'd be little point in bothering at that time. Igor has been generous enough to test the various iterations of this patch as I've developed them and tested on a production system to see if they work for him. Based on his results, I think we're pretty close to an acceptable compromised between security (full randomization) and proper operation (no randomization.) We're now looking at settings more along the lines of a 10 connections per second ceiling and a 45 second threshold before randomization is reenabled, FWIW. I'm not too concerned about general testing because these patches are quite simple; they're modifications of the previous behavior, so they won't create any new problems. As far as bugs in the implementaton go, well, anyone is welcome to do a quick review. :) Mike "Silby" Silbersack