Re: [Tsvwg] WGLC for Port Randomization starts now (April 1st)

Joe Touch <touch@ISI.EDU> Wed, 27 May 2009 16:22 UTC

Return-Path: <touch@ISI.EDU>
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 BFC083A6DCE for <tsvwg@core3.amsl.com>; Wed, 27 May 2009 09:22:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 x8001KQIWlSS for <tsvwg@core3.amsl.com>; Wed, 27 May 2009 09:22:55 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B3EAD3A6CBB for <tsvwg@ietf.org>; Wed, 27 May 2009 09:22:55 -0700 (PDT)
Received: from [75.212.193.38] (38.sub-75-212-193.myvzw.com [75.212.193.38]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n4RGO2FF001555; Wed, 27 May 2009 09:24:04 -0700 (PDT)
Message-ID: <4A1D6920.2090201@isi.edu>
Date: Wed, 27 May 2009 09:24:00 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
References: <20090415033307.F00C0CD585E@lawyers.icir.org> <4A037030.6040107@isi.edu> <0C53DCFB700D144284A584F54711EC58074EEED6@xmb-sjc-21c.amer.cisco.com> <4A1AB6EE.5080900@gont.com.ar> <0C53DCFB700D144284A584F54711EC58074EEF11@xmb-sjc-21c.amer.cisco.com> <4A1BF56D.3020709@isi.edu> <C240732A-D48D-4D96-85BD-2E3C090682C3@lakerest.net> <0C53DCFB700D144284A584F54711EC58074EF70A@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <0C53DCFB700D144284A584F54711EC58074EF70A@xmb-sjc-21c.amer.cisco.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "James Polk (jmpolk)" <jmpolk@cisco.com>, mallman@icir.org, Randall Stewart <rrs@lakerest.net>, Fernando Gont <fernando@gont.com.ar>, 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, 27 May 2009 16:22:56 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Anantha Ramaiah (ananth) wrote:
>  
> 
>>> It's worth noting that many implementations aren't RFC compliant in 
>>> this regard, though.
>>>
>>>> It is also well known that the side-effect of TIME-WAIT 
>> requirement 
>>>> leads for the 4-tuple (socket-pairs) to be locked for some time.
>>> That is not a "side effect", that is the *desired* effect.
>>>
>>>> It needs to be pointed out at that, other transport protocols like 
>>>> SCTP doesn't have the TIME-WAIT requirement since the protocol 
>>>> supports in-built mechanisms to deal with the need for the same.
>>> SCTP has a TIME WAIT state for its connection IDs (socket pair and 
>>> vtags), just as TCP has for its (socket pair). The 
>> difference is that 
>>> SCTP has a larger connection ID space, that's *all*.
>>
>> Joe:
>>
>> Technically you are correct... there is a timed-wait on 
>> vtags. The BSD implementation (the reference implementation) 
>> does properly implement this. However the space is so large 
>> most implementations do not do so.
>>
>> I guess other developers have felt its not worth the trouble 
>> with such a large space....
>>
>> R
> 
> Yes, exactly. To rephrase :
> 
> - SCTP protocol state machine doesn't have a TIME-WAIT state.

That's not what I got from the specs or Randall's note; there is a
TIME-WAIT state, but it's generally not implemented (which I find
amazing, given the extent to which SCTP went to avoid security issues).

> - SCTP doesn't suffer from the same problem like TCP where you cannot
> reuse the socket pair. You reuse the socket pair immediately and the
> connections would get accepted. The only thing mandated by the protocol
> is that the vtag (a billon spaced one) needs to be unique for every new
> connection request. 

STCP has exactly the same issue; SCTP defines the connection ID as
including the vtag, which increases the size of the space, which makes
it not an concern, though. TCP defines the connection ID as the socket
pair, which does not have enough entropy to avoid collisions.

> - Like you said *some* implementations have chosen to do time-wait on
> vtags (NOT the TIME-WAIT on the entire TCB (socket pair) which it
> TOTALLY different. (esp for the context the current discussion is
> happenning)

SCTP defines the "TIME-WAIT" on the connection identifier, not just the
vtags.

> So, actually I should have said that other transport protocols like SCTP
> have the in-built mechanism (vtags, similar to timestamps of TCP in some
> sense as far the current discussion goes) to deal with the port reuse
> issue.

vtags are constant over the life of the connection. the closest thing
they come to in TCP terms is the ISN pair, but it is inserted in the
header of every packet.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkodaSAACgkQE5f5cImnZrsTTwCgrWLZFkwC2JpA2Mj/GLv1GI4t
twYAoNTUzXaCw16K8ChyoZwK/5n5MLNc
=Mrty
-----END PGP SIGNATURE-----