Re: [Tsvwg] WGLC for Port Randomization starts now (April 1st)
Mark Allman <mallman@icir.org> Wed, 15 April 2009 03:32 UTC
Return-Path: <mallman@icir.org>
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 DF41B3A685C for <tsvwg@core3.amsl.com>;
Tue, 14 Apr 2009 20:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.506
X-Spam-Level:
X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093,
BAYES_00=-2.599]
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 b7rqN4eItgYC for
<tsvwg@core3.amsl.com>; Tue, 14 Apr 2009 20:32:06 -0700 (PDT)
Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU
[192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id C0A243A681A for
<tsvwg@ietf.org>; Tue, 14 Apr 2009 20:32:06 -0700 (PDT)
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net
[69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with
ESMTP id n3F3XF0b007978; Tue, 14 Apr 2009 20:33:17 -0700
Received: from lawyers.icir.org (unknown [69.222.35.58]) by guns.icir.org
(Postfix) with ESMTP id 14CA9394DDA3; Tue, 14 Apr 2009 23:33:10 -0400 (EDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org
(Postfix) with ESMTP id F00C0CD585E; Tue, 14 Apr 2009 23:33:07 -0400 (EDT)
To: "James M. Polk" <jmpolk@cisco.com>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <XFE-RTP-201eWYXI4Ht000037b9@xfe-rtp-201.amer.cisco.com>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Given to Fly
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma21872-1"; micalg=pgp-sha1;
protocol="application/pgp-signature"
Date: Tue, 14 Apr 2009 23:33:07 -0400
Sender: mallman@icir.org
Message-Id: <20090415033307.F00C0CD585E@lawyers.icir.org>
Cc: 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
Reply-To: mallman@icir.org
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 03:32:08 -0000
> 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