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

Murari Sridharan <muraris@microsoft.com> Thu, 26 July 2007 19:14 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 1IE8me-0002ci-T9; Thu, 26 Jul 2007 15:14:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8mc-0002by-JO; Thu, 26 Jul 2007 15:13:58 -0400
Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE8mb-0006kD-AZ; Thu, 26 Jul 2007 15:13:58 -0400
Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 26 Jul 2007 12:13:56 -0700
Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.150]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Thu, 26 Jul 2007 12:13:54 -0700
From: Murari Sridharan <muraris@microsoft.com>
To: Joe Touch <touch@ISI.EDU>
Date: Thu, 26 Jul 2007 12:13:54 -0700
Subject: RE: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization
Thread-Topic: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization
Thread-Index: AcfPtvQxDsL76unxSIOdk+kp1iUnigAAP8TQ
Message-ID: <FCA794787FDE0D4DBE9FFA11053ECEB60C26A163C0@NA-EXMSG-C110.redmond.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> <46A8EEB8.2000304@isi.edu>
In-Reply-To: <46A8EEB8.2000304@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: -8.0 (--------)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, tsvwg WG <tsvwg@ietf.org>, list <dccp@ietf.org>, Fernando Gont <fernando@gont.com.ar>, TSV Dir <tsv-dir@ietf.org>, DCCP
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

Agree on the NAT part.

However whether or not its negotiated during SYN exchange would depend on how it gets specified. For instance (again I really am thinking real-time and aloud here not fully thought thru) we could do something like the following. On the SYN packet, the sender picks a port (unscaled)and tries to negotiate a scaling option, (NATs that do packet inspection are free to strip this option out) and the destination picks a port and may respond to the scaling. If both sides agreed, then the scaled ports are used for the 4-tupe, if not the unscaled version is used. The only caveat is that while a connection attempt is in progress to a destination, we cannot be trying the same local port, since till the 3-way handshake completes you wont know whether the scaled or the unscaled version is going to be used.

I am not suggesting that scaling ports is a good option, just a thought. I will look at the portnames draft.

-----Original Message-----
From: Joe Touch [mailto:touch@ISI.EDU]
Sent: Thursday, July 26, 2007 11:58 AM
To: Murari Sridharan
Cc: tsvwg WG; tcpm@ietf.org; DCCP mailing list; Fernando Gont; TSV Dir
Subject: Re: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization



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.

Scale works for windows because of two things:

1) the scale increases the granularity of the window info

2) the scale factor can be negotiated during SYN exchange

Neither is true for ports.

1-p) ports are specific numbers; extended fields could be provided in options, but that's equivalent to having the port number itself in an option anyway

2-p) we can negotiate the use of these extended port ranges with endpoints, but it will break NATs

Portnames is a step in these directions, but is currently experimental at best. See http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt (to be updated shortly).

Joe

--
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI


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