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

Joe Touch <touch@ISI.EDU> Thu, 26 July 2007 19:18 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 1IE8rC-00088a-Sp; Thu, 26 Jul 2007 15:18:42 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8rA-000879-HY; Thu, 26 Jul 2007 15:18:40 -0400
Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE8rA-0005gV-2r; Thu, 26 Jul 2007 15:18:40 -0400
Received: from [130.129.37.253] (dhcp-25fd.ietf69.org [130.129.37.253]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l6QJIQYF008992; Thu, 26 Jul 2007 12:18:26 -0700 (PDT)
Message-ID: <46A8F37A.8070508@isi.edu>
Date: Thu, 26 Jul 2007 12:18:18 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.5 (Windows/20070716)
MIME-Version: 1.0
To: Murari Sridharan <muraris@microsoft.com>
Subject: Re: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization
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> <FCA794787FDE0D4DBE9FFA11053ECEB60C26A163C0@NA-EXMSG-C110.redmond.corp.microsoft.com>
In-Reply-To: <FCA794787FDE0D4DBE9FFA11053ECEB60C26A163C0@NA-EXMSG-C110.redmond.corp.microsoft.com>
X-Enigmail-Version: 0.95.2
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: TSV Dir <tsv-dir@ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>, DCCP mailing list <dccp@ietf.org>, tsvwg WG <tsvwg@ietf.org>, Fernando Gont <fernando@gont.com.ar>
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>
Content-Type: multipart/mixed; boundary="===============1785978800=="
Errors-To: tcpm-bounces@ietf.org


Murari Sridharan wrote:
> 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.

It can't get negotiated during the SYN; NATs wouldn't track that, and
will break the connection if it 'moves' to another port.

Even if it is in the SYN, it won't allow two hosts to share a port
through a NAT.

It's worth looking at the alternatives which are discussed in Mark's ID
and mine, too.

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