Re: [Tsvwg] WGLC for Port Randomization starts now (April 1st)
Lars Eggert <lars.eggert@nokia.com> Wed, 15 April 2009 14:54 UTC
Return-Path: <lars.eggert@nokia.com>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A0283A6E0B for <tsvwg@core3.amsl.com>; Wed, 15 Apr 2009 07:54:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e18PU51oEHBi for <tsvwg@core3.amsl.com>; Wed, 15 Apr 2009 07:54:26 -0700 (PDT)
Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id CAAAC3A697A for <tsvwg@ietf.org>; Wed, 15 Apr 2009 07:54:24 -0700 (PDT)
Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3FEtKKY045725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Apr 2009 17:55:20 +0300 (EEST) (envelope-from lars.eggert@nokia.com)
Message-Id: <40307809-6388-4F1C-8194-307E806EE642@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: "mallman@icir.org" <mallman@icir.org>
In-Reply-To: <20090415033307.F00C0CD585E@lawyers.icir.org>
Content-Type: multipart/signed; boundary="Apple-Mail-7--492884967"; micalg="sha1"; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Wed, 15 Apr 2009 17:55:19 +0300
References: <20090415033307.F00C0CD585E@lawyers.icir.org>
X-Mailer: Apple Mail (2.930.3)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Wed, 15 Apr 2009 17:55:20 +0300 (EEST)
Cc: "James M. Polk" <jmpolk@cisco.com>, tsvwg <tsvwg@ietf.org>
Subject: Re: [Tsvwg] WGLC for Port Randomization starts now (April 1st)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Apr 2009 14:54:27 -0000
Hi, thanks for the review, Mark. Authors, please discuss this review with Mark. The chairs think that eventually, a document revision will be needed to address the points that Mark has raised. Thanks, Lars On 2009-4-15, at 6:33, Mark Allman wrote: > >> This is the start of the WGLC for Port Randomization, which will >> last for 14 days - starting April 1st, going through April >> 15th. Please review this document and post comments to the TSVWG >> list and authors. > > I read the document today. Comments: > > - The title is bogus. The prose carefully says that the document is > not about port randomization, but about port obfuscation. The > title > should be corrected. > > - While the early part of the document does talk in terms of > obfuscation and not randomization the entire document needs > scrubbed > because there are plenty of places where the document discusses > "randomization" when it really means "obfuscation". I flagged a > bunch of these but am not including them in this email because > there > are just too many. I suggest searching for "random" and fixing all > the bogus instances. > > - Section 1: "tihs" --> "this" > > - Section 1: "produce a random" --> "produce a mathematically random" > > - Section 2.1: There is a claim that the ephemeral port space is > "traditionally" from 49152-65535. I think it is more traditional > for hosts to use monotonically increasing ports starting at 1024. > Even if hosts do use this upper range they also use this lower > range > a bunch. I'd nuke this statement as probably wrong, but at least > dubious. > > - Section 2.2: suggest tacking "at a given point in time" to the end > of the last sentence. > > - In 2.2 and several other places the notion of a 'blind' attacker is > stretched. I.e., the document discusses attackers that cannot see > some particular connection directly but can view some other, > perhaps > related, communication with the host. It might be nice to see this > developed when the concept of a 'blind attack' is developed because > it isn't quite blind and it feels a little funny being introduced > in > the middle after we have been told the document deals with blind > attacks. > > - In 2.3 you might note that an alternative approach is for both > hosts > to keep state about recent connections. I am not arguing it is a > good approach or a bad approach...just an alternate approach that > would work towards minimizing the collision rate. > > - In 3.1 collisions are discussed as "interoperability problems". I > don't think that is quite right. I think the real issue is that > there is added delay in getting things setup. > > - I found the notion of a bit array in 3.2 to be way too much detail. > Just note that a host could introduce a system to track which port > numbers are going to be used specifically by applications and leave > it at that. The bit array isn't the Clear Right Answer so just > leave the data structures out. > > - I think the notion: > > Although carefully chosen random sources and optimized five-tuple > lookup mechanisms (e.g., optimized through hashing) will mitigate > the cost of this verification, some systems may still not want to > incur this search time. > > I remain of the opinion that this is just used-car-salesman talk. > Hosts have to be able to associate incoming packets with connection > state on every packet arrival. That is the same kind of lookup > they > have to do to check whether a chosen connection-id is in use. The > above is simply FUD. Trying a couple of these connection-ids is in > no way an onerous task. I strongly suggest this sentence be > removed. > > - Further in 3.3.1 you note that web proxies and NATs are examples of > systems that "create many connections from a single local IP > address > to a single service". I think that's pretty dubious. You might > say > that they make more connections to popular services than end hosts > do (because of the aggregation) and thus increase the population of > used ephemeral ports and hence the chance of collision using Alg. 1 > or 2. But, I think it's sort of dubious to just leave it hanging > as > these things hit the problematic case as a matter of course, which > is not generally true, I bet. > > - Again, the paragraph under "figure 3" is dubious. First, it is > predicated on the notion that lookup time is somehow consequential, > which is pretty off-the-mark as I noted above. Second, the data we > have suggests that there are *less* port choices required to handle > remote collisions with Alg. 2 when compared to Alg. 1. While that > is not exactly what is being discussed in this section it seems > like > we can use remote collisions as a proxy here for what the local > collision rate likely looks like. (See table 3 in [Allman].) And, > in fact, going a step further nearly all the collisions are taken > care of by two port choices. So, it's hard to believe that this > playing up of the possibility of some arduous search through the > port space is really warrented. > > - Perhaps I missed it, but it would be nice to define the > "traditional > BSD algorithm" early in the document. > > - Section 3.3.4: "that even a" --> "that a" > > - Section 3.3.4: "systems recommend" --> "systems we recommend" > > - Section 3.3.4: It'd be nice to see some reasoning about why a table > size of 1024 is being recommended. It seems like this is > arbitrarily pulled out of the air. I think it'd be fine to leave > this to the implementer. I.e., note that [Allman] shows 10 entries > will work fine for collision avoidance and increasing the table > size > increases the obfuscation and leave it at that. If you pick a > number then at least motivate it somehow. > > - 3.3.5: "introduced yet another" --> "introduced another" > > - 3.3.5: The algorithm is wrong. This is my fault. The paper is not > clear. Alas. When a collision is found we do not increment by > one, > but choose a new random increment. This is just not discussed in > the paper, but should have been. However, I looked at the code for > my simulator and that is how I did it. > > - 3.3.5: I'd like to see more prose about algorithm 5 to mirror the > other sections. I.e., to give the intuition behind it, etc. > > - 3.5: You should likely add the caveat to our results that goes "in > the two environments assessed" or something like that. > > - I think it's slanted that you sort of report results for Algorithms > 1 and 2, but not for the remainder of the algorithms. The "sort > of" > being that you just say "they were the worst". We have numbers > here. Let the data do the talking. > > - And, if I had one request about data it would be to note that no > matter what algorithm is chosen the fraction of hosts we saw having > *any* collisions is exceedingly small. I.e., the collision problem > is really a non-problem for most cases. And, so it might be > reasonable to use something dumb and simple in the general case and > a little more expensive in a less general case. At least that's > how > I think the data really comes down. > > - [Allman] should be: > > Mark Allman. Comments On Selecting Ephemeral Ports. ACM > Computer > Communication Review, 39(2), April 2009. > > That's a pretty long list. But, I don't think there is really > anything > difficult in there. In general I think the document is in pretty > decent > shape, but I would like to see most of the above addressed before the > document moves forward. FWIW. > > allman > > >
- [Tsvwg] WGLC for Port Randomization starts now (A… James M. Polk
- Re: [Tsvwg] WGLC for Port Randomization starts no… Mark Allman
- Re: [Tsvwg] WGLC for Port Randomization starts no… Lars Eggert
- Re: [Tsvwg] WGLC for Port Randomization starts no… Lars Eggert
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- [Tsvwg] Fwd: WGLC for Port Randomization starts n… Lars Eggert
- Re: [Tsvwg] Fwd: WGLC for Port Randomization star… Anantha Ramaiah (ananth)
- Re: [Tsvwg] Fwd: WGLC for Port Randomization star… Fernando Gont
- Re: [Tsvwg] WGLC for Port Randomization starts no… Fernando Gont
- Re: [Tsvwg] Fwd: WGLC for Port Randomization star… Mark Allman
- Re: [Tsvwg] WGLC for Port Randomization starts no… Anantha Ramaiah (ananth)
- Re: [Tsvwg] WGLC for Port Randomization starts no… Fernando Gont
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- Re: [Tsvwg] WGLC for Port Randomization starts no… Anantha Ramaiah (ananth)
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- Re: [Tsvwg] WGLC for Port Randomization starts no… Mark Allman
- Re: [Tsvwg] WGLC for Port Randomization starts no… Fernando Gont
- Re: [Tsvwg] WGLC for Port Randomization starts no… Mark Allman
- [Tsvwg] title (was Re: WGLC for Port Randomizatio… Mark Allman
- [Tsvwg] table size (was Re: WGLC for Port Randomi… Mark Allman
- [Tsvwg] NATs (etc.) (was Re: WGLC for Port Random… Mark Allman
- [Tsvwg] interoperability (was Re: WGLC for Port R… Mark Allman
- [Tsvwg] algorithm 5 (was Re: WGLC for Port Random… Mark Allman
- [Tsvwg] lookup time (was Re: WGLC for Port Random… Mark Allman
- Re: [Tsvwg] WGLC for Port Randomization starts no… Randall Stewart
- Re: [Tsvwg] WGLC for Port Randomization starts no… Anantha Ramaiah (ananth)
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- Re: [Tsvwg] WGLC for Port Randomization starts no… Anantha Ramaiah (ananth)
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- Re: [Tsvwg] title (was Re: WGLC for Port Randomiz… Fernando Gont
- Re: [Tsvwg] NATs (etc.) (was Re: WGLC for Port Ra… Fernando Gont
- Re: [Tsvwg] NATs (etc.) (was Re: WGLC for Port Ra… Mark Allman
- Re: [Tsvwg] interoperability (was Re: WGLC for Po… Fernando Gont
- Re: [Tsvwg] interoperability (was Re: WGLC for Po… Mark Allman
- Re: [Tsvwg] table size (was Re: WGLC for Port Ran… Fernando Gont
- Re: [Tsvwg] NATs (etc.) (was Re: WGLC for Port Ra… Fernando Gont
- Re: [Tsvwg] table size (was Re: WGLC for Port Ran… Mark Allman
- Re: [Tsvwg] interoperability (was Re: WGLC for Po… Fernando Gont
- Re: [Tsvwg] table size (was Re: WGLC for Port Ran… Fernando Gont
- Re: [Tsvwg] algorithm 5 (was Re: WGLC for Port Ra… Fernando Gont
- Re: [Tsvwg] lookup time (was Re: WGLC for Port Ra… Fernando Gont
- Re: [Tsvwg] WGLC for Port Randomization starts no… Brian F. G. Bidulock
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- Re: [Tsvwg] WGLC for Port Randomization starts no… Fernando Gont
- Re: [Tsvwg] WGLC for Port Randomization starts no… Anantha Ramaiah (ananth)
- Re: [Tsvwg] WGLC for Port Randomization starts no… Randy Stewart
- Re: [Tsvwg] WGLC for Port Randomization starts no… Randy Stewart
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- Re: [Tsvwg] WGLC for Port Randomization starts no… Anantha Ramaiah (ananth)
- Re: [Tsvwg] WGLC for Port Randomization starts no… Anantha Ramaiah (ananth)
- Re: [Tsvwg] WGLC for Port Randomization starts no… Anantha Ramaiah (ananth)
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- [Tsvwg] Port Randomization issues summary Joe Touch
- Re: [Tsvwg] WGLC for Port Randomization starts no… Randy Stewart
- Re: [Tsvwg] WGLC for Port Randomization starts no… Brian F. G. Bidulock
- Re: [Tsvwg] WGLC for Port Randomization starts no… Brian F. G. Bidulock
- Re: [Tsvwg] algorithm 5 (was Re: WGLC for Port Ra… Mark Allman
- Re: [Tsvwg] WGLC for Port Randomization starts no… Randy Stewart
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- Re: [Tsvwg] WGLC for Port Randomization starts no… Randy Stewart
- Re: [Tsvwg] WGLC for Port Randomization starts no… Randy Stewart
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- Re: [Tsvwg] WGLC for Port Randomization starts no… Randy Stewart
- Re: [Tsvwg] WGLC for Port Randomization starts no… Randy Stewart
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- Re: [Tsvwg] WGLC for Port Randomization starts no… Randy Stewart
- Re: [Tsvwg] WGLC for Port Randomization starts no… Randy Stewart
- Re: [Tsvwg] WGLC for Port Randomization starts no… Michael Tüxen
- Re: [Tsvwg] WGLC for Port Randomization starts no… Anantha Ramaiah (ananth)
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- Re: [Tsvwg] WGLC for Port Randomization starts no… Michael Tüxen
- Re: [Tsvwg] WGLC for Port Randomization starts no… Brian F. G. Bidulock
- Re: [Tsvwg] Port Randomization issues summary Fernando Gont
- Re: [Tsvwg] WGLC for Port Randomization starts no… Joe Touch
- Re: [Tsvwg] Port Randomization issues summary Joe Touch
- Re: [Tsvwg] WGLC for Port Randomization starts no… Randy Stewart
- Re: [Tsvwg] algorithm 5 (was Re: WGLC for Port Ra… Fernando Gont
- Re: [Tsvwg] Port Randomization issues summary Fernando Gont
- Re: [Tsvwg] Port Randomization issues summary Joe Touch
- Re: [Tsvwg] algorithm 5 (was Re: WGLC for Port Ra… Mark Allman
- Re: [tsvwg] [Tsvwg] lookup time (was Re: WGLC for… Mark Allman
- Re: [tsvwg] [Tsvwg] lookup time (was Re: WGLC for… Fernando Gont