RE: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization

Fernando Gont <fernando@gont.com.ar> Mon, 30 July 2007 21:27 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFcmH-0003k1-9v; Mon, 30 Jul 2007 17:27:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFcmB-0003VA-Pc; Mon, 30 Jul 2007 17:27:39 -0400
Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFcm9-0001kK-FQ; Mon, 30 Jul 2007 17:27:39 -0400
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 27D7CF0C46E; Mon, 30 Jul 2007 18:27:07 -0300 (ART)
Received: from fgont.gont.com.ar (200.61.43.18.static.telmex.net.ar [200.61.43.18] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l6ULQopg029773; Mon, 30 Jul 2007 18:27:00 -0300
Message-Id: <7.0.1.0.0.20070730030538.076fd2a8@gont.com.ar>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Mon, 30 Jul 2007 03:14:54 -0300
To: Murari Sridharan <muraris@microsoft.com>, tsvwg WG <tsvwg@ietf.org>
From: Fernando Gont <fernando@gont.com.ar>
Subject: RE: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization
In-Reply-To: <FCA794787FDE0D4DBE9FFA11053ECEB60C26A1618E@NA-EXMSG-C110.r edmond.corp.microsoft.com>
References: <200702111621.l1BGL6mw029875@venus.xmundo.net> <0E46EBE9-1C13-44B6-9C04-476D418F5A6D@nokia.com> <A6CE6259-646E-4C35-9DA3-8911A8CB2B54@nokia.com> <FCA794787FDE0D4DBE9FFA11053ECEB60C26A1618E@NA-EXMSG-C110.redmond.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Mon, 30 Jul 2007 18:27:06 -0300 (ART)
X-Spam-Score: 1.8 (+)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, DCCP mailing list <dccp@ietf.org>, TSV Dir <tsv-dir@ietf.org>
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

At 11:42 26/07/2007, Murari Sridharan wrote:

>In this context I wanted to bring up a related issue that might also 
>strengthen this sort of a port randomization proposal.
>
>Today the 64k port limitation is starting to become a huge problem 
>and most often admins add ip addresses to increase the scalability. 
>Given that most often the destination port (and sometimes the 
>destination address) is well known, the only scalability left is the 
>source address. Increasing ip addresses to improve scalability seems 
>a fairly round about approach and frankly doesn't scale well. Given 
>that the 64k limit is not fundamental why not provide a scaling 
>factor similar to the receive window to scale the number of usable 
>ports. This also makes randomization much more meaningful because in 
>certain proxy scenarios the number of connections quickly exhausts 
>the available ports and at that point the attacker can simply use 
>any port assuming he can guess the source address.

While I may agree with increasing the range of port numbers, I think 
this is out of the scope of the port randomization draft we have authored.

There are a few things that may be worth noting:

* The port randomization approaches discussed in the port 
randomization draft are independent of the range of ephemeral ports. 
That is, even if at some point we decide to scale the port numbers 
(or whatever), the approaches discussed in the port randomization 
draft would still apply.

* Most TCP implementations use for the ephemeral ports a very small 
subspace eg, ports 1024-4999) of the available port number space. 
That is, you may be using 1/10th of the range you have available. In 
this respect, our port randomization draft advises to increase the 
port number range used for ephemeral ports. This may help a bit in 
the scenarios you are describing.

Kind regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1






_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm