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

["Anantha Ramaiah (ananth)" <[e-mail]>]

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Wednesday, May 27, 2009 9:15 PM
> To: Randy Stewart
> Cc: Anantha Ramaiah (ananth); tsvwg; James Polk (jmpolk); 
> Fernando Gont; [e-mail]
> Subject: Re: [Tsvwg] WGLC for Port Randomization starts now 
> (April 1st)
> 
> -----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.

What do you mean by "all socket pairs", at any given time there is only
*one* association with a given socket pair S. Also *every* vtag that is
generated is put into time-wait (of course only in some implementations)
What you say would have made sense if the connection qualifier for SCTP
happens to include vtag, but that is not the case. See below.

> 
> 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.

Why are you simply adding these bits? We are talking about port reuse
and not IP addr reuse, the src port is the one generated under the
jurisdiction of transport protocol code. 

> 
> > 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.

The vtag is like a 32 bit signature (hash), which would detect old
duplicates sine the vtag wouldn't match (yes we assuming wraparound of
vtag takes a lot of time) Ok, let me ask you this question : lets assume
that timestamps option is mandated for every TCP connection, the
timestamp is monotonically increasing number acts like a verification
mechanism to detect old segments (PAWS), so question is : do you still
think 2MSL (which is an overkill for modern networks) wait is better
than having timestamps, the answer is if the wraparound of a 32 bit
number happens slower than 2MSL, which is typically the case, then
timestamps definetely helps in preventing old segments getting injected
into the data stream. Now in case of SCTP the "timestamp" (vtag) is
generated once per association and it is an identifer which is used to
uniquely identify a particular association, hence vtags help in
rejecting old duplicates, TCP doesn't have anything to reject anything
extra to make this decision ( obviously I am talking about the case
where the seq# falls in the window, else TCP input processing rules
would drop the segment)

-Anantha
> 
> 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
> > [e-mail]
> > 
> > 
> > 
> -----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-----
>