From owner-freebsd-net@FreeBSD.ORG Tue Feb 8 18:47:21 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 155A5106564A for ; Tue, 8 Feb 2011 18:47:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id AE7CE8FC21 for ; Tue, 8 Feb 2011 18:47:20 +0000 (UTC) Received: (qmail 19275 invoked by uid 399); 8 Feb 2011 18:47:17 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 8 Feb 2011 18:47:17 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D518FB3.3040503@FreeBSD.org> Date: Tue, 08 Feb 2011 10:47:15 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ivo Vachkov References: <4D411CC6.1090202@gont.com.ar> <4D431258.8040704@FreeBSD.org> <4D437B13.1070405@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , bz@freebsd.org Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:47:21 -0000 I've been up and running on this patch vs. r218391 for over 24 hours now, using algorithm 4 (as someone said is now the default in Linux) without any problems. I think Bjoern is better qualified than I to comment on the style of the patch, but it applies cleanly, and seems to run fine on both v4 and v6. hth, Doug On 01/31/2011 04:52, Ivo Vachkov wrote: > Hello, > > I attach the latest version of the port randomization code as a patch > against RELENG_8. > > Changelog: > 1) sysctl variable names are changed to: > - 'net.inet.ip.portrange.randomalg.version' - representing the > algorithm of choice. > - 'net.inet.ip.portrange.randomalg.alg5_tradeoff' - representing the > Algorithm 5 computational tradeoff value (the 'N' value in the > Algorithm 5 description in the RFC 6056). > 2) Code comments are synchronized with the current variable names. > > Ivo Vachkov > > On Sat, Jan 29, 2011 at 4:27 AM, Doug Barton wrote: >> On 01/28/2011 11:57, Ivo Vachkov wrote: >>> >>> On Fri, Jan 28, 2011 at 9:00 PM, Doug Barton wrote: >> >>>> How does net.inet.ip.portrange.randomalg sound? I would also suggest that >>>> the second sysctl be named net.inet.ip.portrange.randomalg.alg5_tradeoff >>>> so >>>> that one could do 'sysctl net.inet.ip.portrange.randomalg' and see both >>>> values. But I won't quibble on that. :) >>>> >>> >>> I have no objections with this. Since this is my first attempt to >>> contribute something back to the community I decided to see how it's >>> done before. So I found: >>> net.inet.tcp.rfc1323 >>> net.inet.tcp.rfc3465 >>> net.inet.tcp.rfc3390 >>> net.inet.tcp.rfc3042 >>> which probably led me in a wrong direction :) >> >> Yeah, I had actually intended to say something to the effect of "there are >> plenty of unfortunate examples in the tree already so your doing it that way >> is totally understandable" but I trimmed it. >> >>> I understand your point and agree with it. However, my somewhat >>> limited understanding of the sysctl internal organization is telling >>> me that tree node does not support values. Am I wrong? >> >> You are likely correct. :) It's an inconvenient fact that often forget >> because that's not the sandbox that I usually play in. >> >>> If my reasoning >>> is correct, maybe I can create the sysctl variables with the following >>> names: >>> - net.inet.ip.portrange.randomalg (Tree Node) >>> - net.inet.ip.portrange.randomalg.alg[orithm] (Leaf Node, to store the >>> selected algorithm) >> >> I would go with "version" to increase the visual distinctiveness. I searched >> the current tree and there doesn't seem to be a clear winner for how to >> portray "this is the current N/M that is in use" but "version" seems to have >> the most representatives. >> >>> - net.inet.ip.portrange.randomalg.alg5_tradeoff (Leaf Node, to store >>> the Algorithm 5 trade-off value) >> >> I'm assuming this is the "N" value mentioned in the RFC. If so, I commend >> you on your choice of "tradeoff" to represent it. :)