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

Joe Touch <touch@ISI.EDU> Thu, 28 May 2009 04:13 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 730AE3A6882 for <tsvwg@core3.amsl.com>; Wed, 27 May 2009 21:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.967
X-Spam-Level:
X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6]
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 m3asP3J+oNdc for <tsvwg@core3.amsl.com>; Wed, 27 May 2009 21:13:39 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 66C1F3A6781 for <tsvwg@ietf.org>; Wed, 27 May 2009 21:13:39 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-106-86-44.lsanca.dsl-w.verizon.net [71.106.86.44]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n4S4Er73025044; Wed, 27 May 2009 21:14:55 -0700 (PDT)
Message-ID: <4A1E0FBD.8080308@isi.edu>
Date: Wed, 27 May 2009 21:14:53 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Randy Stewart <randall@lakerest.net>
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> <0C53DCFB700D144284A584F54711EC58074EF74C@xmb-sjc-21c.amer.cisco.com> <4A1D6F4E.2080005@isi.edu> <0C53DCFB700D144284A584F54711EC58075636B3@xmb-sjc-21c.amer.cisco.com> <D3F996EE-AF45-4E38-8DA8-5C43E98A3112@lakerest.net>
In-Reply-To: <D3F996EE-AF45-4E38-8DA8-5C43E98A3112@lakerest.net>
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>, "Anantha Ramaiah (ananth)" <ananth@cisco.com>, tsvwg <tsvwg@ietf.org>, mallman@icir.org, Fernando Gont <fernando@gont.com.ar>
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: Thu, 28 May 2009 04:13:40 -0000

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

Randy Stewart wrote:
> Not getting into the details of vtags.. I think you hit
> upon the key point. If you are doing time-wait.. you are
> doing time-wait on vtags... aka: 32 bit numbers.
> 
> An IP address/Port is NEVER blocked from re-use right away
> like it can be in TCP due to time-wait. This was always
> one of the most irritating things I did not like in TCP. 

Sorry, maybe I'm missing this.

Let A=srcIP, X=srcport, B=dstIP, Y=dstport.

In TCP, if I use A,X->B,Y, then close the connection, I cannot use it
for another 2 minutes.

In SCTP, if I use A,X->B,Y with Vtag Q, then close the connection,
clearly I cannot use A,X->B,Y with Vtag Q again for some (unspecified,
AFAICT, in the specs) period of time.

You appear to be claiming that what SCTP does is block Vtag Q for that
period of time _for all_ socket pairs. That's strictly worse than TCP
was doing.

E.g., TCP has 32 + 16 + 32 + 16 bits to play with for connections as a
whole, i.e., 96 bits. SCTP would have only 32. A large server with a lot
of short connections could easily have vtag collisions in that situation.

> I
> understand the need for it.. but I have been known (in past
> lives) while testing things (in a lab) to reboot a machine to
> get out of time-wait (due to frustration ;-D)

Sure - and what I'm claiming is that not having (or not holding) true
time-wait in SCTP puts you in the same boat as you were in TCP when you
spin the MSL timer down. In both cases you're betting that old packets
won't come into the new connection - and, as I noted, with routers
stalling to handle interruptions - things are getting worse along those
lines, not better.

Joe

> On May 27, 2009, at 9:20 PM, Anantha Ramaiah (ananth) wrote:
> 
>> Joe,
>>
>>>
>>>>>> 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
>>>>
>>>> TCB is gone, only the vtag can be in time-wait (some
>>> implementations
>>>> do it). TIME-WAIT state doesn't exist in the SCTP protocol. Pl see
>>>> Randy's and my responses.
>>>
>>> While I agree that the term "TIME-WAIT" does not appear in
>>
>> Term, huh? TIME-WAIT is a state in TCP state machine, SCTP doesn't have
>> it. Period. As far as SCTP goes the 4 tuple (socket-pair) is never held
>> in TIME-WAIT unlike TCP, i.e, you don't have to hold the TCB hanging in
>> there for about 2MSL. Now, as Randy explained the vtag alone CAN be held
>> in some timewait(again not mandated by the protocol). This is not
>> specified in SCTP RFC, nor is the timewait value. SCTP is robust against
>> time-wait hazards because of the vtag facility and that is what I meant
>> when I said the protocol has "inbuilt mechanisms" for dealing with data
>> corruption from an old incarnation (your crash ;-)
>>
>>> RFC 2690, there is a note:
>>
>> FWIW, RFC 2690 is obselete. Pl refer RFC 4960.
>>
>>>
>>> " A new Verification Tag value MUST be used each time the
>>>   endpoint tears-down and then re-establishes an association to the
>>>   same peer."
>>>
>>> Can you explain how you know that the tag is new unless you
>>> hold it for some period of time?
>>
>> Well, this is purely implementation specific, some imp. can simply be ok
>> having a sequential allocation for vtags. Agreed everything isn't
>> infinite and there is a wrap up coming into play which can happen if a
>> host is trying to make bajillions of connections (open/close), yes you
>> can dream up such similar scenarios. The SCTP RFC doesn't say that vtag
>> generation needs to be sequential/random (rightfully so, since it is all
>> implementation details). The Key point is TCP mandates keeping state
>> (active closer) needs to wait for 2MSL whereas SCTP the TCB can be
>> freed, and vtag time-wait is optional, and SCTP does not suffer from
>> time-wait hazards since vtag protects it.
>>
>> -Anantha
>>
> 
> -----
> Randall Stewart
> randall@lakerest.net
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoeD70ACgkQE5f5cImnZruySACfdm9p30W0GcuKaBUJ6rKoXxBL
lm4AoNrFpWuRY8BCMw6R8/5wtyPfztOv
=5uhf
-----END PGP SIGNATURE-----