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

From: Lars Eggert <[email-masked]>
Date: Wed, 6 May 2009 16:37:02 +0300

Hi, authors,

On 2009-4-15, at 17:55, Eggert Lars (Nokia-NRC/Espoo) wrote:
> Authors, please discuss this review with Mark. The chairs think that  
> eventually, a document revision will be needed to address the points  
> that Mark has raised.

please begin the discussion of the WG last call comments, so that a  
final revision can be produced that we can move forward to IETF last  
call.

Thanks,
Lars

> On 2009-4-15, at 6:33, Mark Allman wrote:
>>
>>> This is the start of the WGLC for Port Randomization, which will
>>> last for 14 days - starting April 1st, going through April
>>> 15th. Please review this document and post comments to the TSVWG
>>> list and authors.
>>
>> I read the document today.  Comments:
>>
>> - The title is bogus.  The prose carefully says that the document is
>>   not about port randomization, but about port obfuscation.  The  
>> title
>>   should be corrected.
>>
>> - While the early part of the document does talk in terms of
>>   obfuscation and not randomization the entire document needs  
>> scrubbed
>>   because there are plenty of places where the document discusses
>>   "randomization" when it really means "obfuscation".  I flagged a
>>   bunch of these but am not including them in this email because  
>> there
>>   are just too many.  I suggest searching for "random" and fixing all
>>   the bogus instances.
>>
>> - Section 1: "tihs" --> "this"
>>
>> - Section 1: "produce a random" --> "produce a mathematically random"
>>
>> - Section 2.1: There is a claim that the ephemeral port space is
>>   "traditionally" from 49152-65535.  I think it is more traditional
>>   for hosts to use monotonically increasing ports starting at 1024.
>>   Even if hosts do use this upper range they also use this lower  
>> range
>>   a bunch.  I'd nuke this statement as probably wrong, but at least
>>   dubious.
>>
>> - Section 2.2: suggest tacking "at a given point in time" to the end
>>   of the last sentence.
>>
>> - In 2.2 and several other places the notion of a 'blind' attacker is
>>   stretched.  I.e., the document discusses attackers that cannot see
>>   some particular connection directly but can view some other,  
>> perhaps
>>   related, communication with the host.  It might be nice to see this
>>   developed when the concept of a 'blind attack' is developed because
>>   it isn't quite blind and it feels a little funny being introduced  
>> in
>>   the middle after we have been told the document deals with blind
>>   attacks.
>>
>> - In 2.3 you might note that an alternative approach is for both  
>> hosts
>>   to keep state about recent connections.  I am not arguing it is a
>>   good approach or a bad approach...just an alternate approach that
>>   would work towards minimizing the collision rate.
>>
>> - In 3.1 collisions are discussed as "interoperability problems".  I
>>   don't think that is quite right.  I think the real issue is that
>>   there is added delay in getting things setup.
>>
>> - I found the notion of a bit array in 3.2 to be way too much detail.
>>   Just note that a host could introduce a system to track which port
>>   numbers are going to be used specifically by applications and leave
>>   it at that.  The bit array isn't the Clear Right Answer so just
>>   leave the data structures out.
>>
>> - I think the notion:
>>
>>     Although carefully chosen random sources and optimized five-tuple
>>     lookup mechanisms (e.g., optimized through hashing) will mitigate
>>     the cost of this verification, some systems may still not want to
>>     incur this search time.
>>
>>   I remain of the opinion that this is just used-car-salesman talk.
>>   Hosts have to be able to associate incoming packets with connection
>>   state on every packet arrival.  That is the same kind of lookup  
>> they
>>   have to do to check whether a chosen connection-id is in use.  The
>>   above is simply FUD.  Trying a couple of these connection-ids is in
>>   no way an onerous task.  I strongly suggest this sentence be
>>   removed.
>>
>> - Further in 3.3.1 you note that web proxies and NATs are examples of
>>   systems that "create many connections from a single local IP  
>> address
>>   to a single service".  I think that's pretty dubious.  You might  
>> say
>>   that they make more connections to popular services than end hosts
>>   do (because of the aggregation) and thus increase the population of
>>   used ephemeral ports and hence the chance of collision using Alg. 1
>>   or 2.  But, I think it's sort of dubious to just leave it hanging  
>> as
>>   these things hit the problematic case as a matter of course, which
>>   is not generally true, I bet.
>>
>> - Again, the paragraph under "figure 3" is dubious.  First, it is
>>   predicated on the notion that lookup time is somehow consequential,
>>   which is pretty off-the-mark as I noted above.  Second, the data we
>>   have suggests that there are *less* port choices required to handle
>>   remote collisions with Alg. 2 when compared to Alg. 1.  While that
>>   is not exactly what is being discussed in this section it seems  
>> like
>>   we can use remote collisions as a proxy here for what the local
>>   collision rate likely looks like.  (See table 3 in [Allman].)  And,
>>   in fact, going a step further nearly all the collisions are taken
>>   care of by two port choices.  So, it's hard to believe that this
>>   playing up of the possibility of some arduous search through the
>>   port space is really warrented.
>>
>> - Perhaps I missed it, but it would be nice to define the  
>> "traditional
>>   BSD algorithm" early in the document.
>>
>> - Section 3.3.4: "that even a" --> "that a"
>>
>> - Section 3.3.4: "systems recommend" --> "systems we recommend"
>>
>> - Section 3.3.4: It'd be nice to see some reasoning about why a table
>>   size of 1024 is being recommended.  It seems like this is
>>   arbitrarily pulled out of the air.  I think it'd be fine to leave
>>   this to the implementer.  I.e., note that [Allman] shows 10 entries
>>   will work fine for collision avoidance and increasing the table  
>> size
>>   increases the obfuscation and leave it at that.  If you pick a
>>   number then at least motivate it somehow.
>>
>> - 3.3.5: "introduced yet another" --> "introduced another"
>>
>> - 3.3.5: The algorithm is wrong.  This is my fault.  The paper is not
>>   clear.  Alas.  When a collision is found we do not increment by  
>> one,
>>   but choose a new random increment.  This is just not discussed in
>>   the paper, but should have been.  However, I looked at the code for
>>   my simulator and that is how I did it.
>>
>> - 3.3.5: I'd like to see more prose about algorithm 5 to mirror the
>>   other sections.  I.e., to give the intuition behind it, etc.
>>
>> - 3.5: You should likely add the caveat to our results that goes "in
>>   the two environments assessed" or something like that.
>>
>> - I think it's slanted that you sort of report results for Algorithms
>>   1 and 2, but not for the remainder of the algorithms.  The "sort  
>> of"
>>   being that you just say "they were the worst".  We have numbers
>>   here.  Let the data do the talking.
>>
>> - And, if I had one request about data it would be to note that no
>>   matter what algorithm is chosen the fraction of hosts we saw having
>>   *any* collisions is exceedingly small.  I.e., the collision problem
>>   is really a non-problem for most cases.  And, so it might be
>>   reasonable to use something dumb and simple in the general case and
>>   a little more expensive in a less general case.  At least that's  
>> how
>>   I think the data really comes down.
>>
>> - [Allman] should be:
>>
>>     Mark Allman.  Comments On Selecting Ephemeral Ports.  ACM  
>> Computer
>>     Communication Review, 39(2), April 2009.
>>
>> That's a pretty long list.  But, I don't think there is really  
>> anything
>> difficult in there.  In general I think the document is in pretty  
>> decent
>> shape, but I would like to see most of the above addressed before the
>> document moves forward.  FWIW.
>>
>> allman
>>
>>
>>
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 07 May 2009 16:35:12 -0700

Some comments on Mark's comments...

> I read the document today.  Comments:
...
>     Even if hosts do use this upper range they also use this lower range

"traditionally" is incorrect; it's *defined* as that range by IANA.

Source ports can use any port they want, though - as Mark points out -
they tend to avoid the "system" ports.

>   - In 2.3 you might note that an alternative approach is for both hosts

And, FWIW, some of that state is already being kept, e.g., in TIME-WAIT
on the side that initiates connection close. It's only for connections
on the other side that keeping such state is even needed.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 13 May 2009 17:27:13 -0300

> "traditionally" is incorrect; it's *defined* as that range by IANA.

Agreed. Will apply this change.

Kind regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 25 May 2009 00:55:20 -0700

> And, FWIW, some of that state is already being kept, e.g., in 
> TIME-WAIT on the side that initiates connection close. It's 
> only for connections on the other side that keeping such 
> state is even needed.

Hmm.. I missed this one.. The draft which we had put out more than an
year ago DOES talk about keeping state at the peer to minimize
collisions. It lists a few algorithms to that effect as well.

http://ietfreport.isoc.org/all-ids/draft-ananth-tsvwg-timewait-00.txt 

-Anantha
> 
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkoDcDAACgkQE5f5cImnZrsHYQCdHojYyD53iVk2o+ZORHzUuzJR
> QVcAnjNWQWH2Rh0On3jCTD5SPXoCrKUo
> =VxEn
> -----END PGP SIGNATURE-----
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 May 2009 12:19:10 -0300

> collisions. It lists a few algorithms to that effect as well.

They probably mean that additional work is required only on the side
that performed the passive close. (i.e., half of the work is already done).

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Mon, 25 May 2009 09:15:00 -0700

> that performed the passive close. (i.e., half of the work is already done).

I made the observation, and yes, that's what I meant.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 25 May 2009 09:22:36 -0700

> -----Original Message-----
> From: Fernando Gont 
> [mailto:[email-masked]] On Behalf Of 
> Fernando Gont
> Sent: Monday, May 25, 2009 8:19 AM
> To: Anantha Ramaiah (ananth)
> Cc: Joe Touch; [email-masked]; James Polk (jmpolk); tsvwg
> Subject: Re: [Tsvwg] WGLC for Port Randomization starts now 
> (April 1st)
> 
> They probably mean that additional work is required only on 
> the side that performed the passive close. (i.e., half of the 
> work is already done).

Any RFC compliant TCP implementation will honor TIME-WAIT requirement
and that involves keeping state at the side which initiated the
connection close. 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. 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. So, the point of interest is keeping micro-state at the end which
performed the passive close and that aspect is covered in detail in our
draft. That was my observation.

-Anantha
> 
> Kind regards,
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked] PGP 
> Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> 
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 26 May 2009 06:58:05 -0700

Anantha Ramaiah (ananth) wrote:
> connection close.

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
> for some time. 

That is not a "side effect", that is the *desired* effect.

> It needs to be pointed out at that, other transport
> 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

---

From: Mark Allman <[email-masked]>
Date: Tue, 26 May 2009 10:09:58 -0400

My observation was merely meant to be quite high level.  I.e., an
end-point can prevent collisions by keeping state.  In TCP, half of this
is well-covered by the usual TIME-WAIT state.  Half of it would have to
be some new, local state a host decided to keep so that it avoided these
collisions.  All I was suggesting was that the port obfuscation I-D
could briefly note that keeping state is one way to avoid collisions if
the collision rate of the chosen port obfuscation technique is thought
to be problematic in some situation.  My intention was not to suggest
some big change here.  A sentence or two is what I was thinking.

(And, this should not be construed as support for
draft-ananth-tsvwg-timewait.) 

allman

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 May 2009 19:28:20 -0300

Mark Allman wrote:

>     not about port randomization, but about port obfuscation.  The title
>     should be corrected.

I have no problem with applying this change. However, other wg
participants (Alfred Honenes, at least) made arguments against this
change (i.e., "port randomization" is how this is stuff is known
everywhere. Also, IIRC Eric Rescorla had argued that the hash function
was actually a PRNG). So I'm not sure how to proceed here...

>   - Section 1: "tihs" --> "this"

Will do. Thanks!

>   - Section 1: "produce a random" --> "produce a mathematically random"

Will do.

>     a bunch.  I'd nuke this statement as probably wrong, but at least

I will go with "IANA defines..."

>   - Section 2.2: suggest tacking "at a given point in time" to the end

I wasn't able to find the aforementioned sentence. :-(

>     some particular connection directly but can view some other, perhaps
>     it isn't quite blind and it feels a little funny being introduced in

Agreed. Will do.

>     would work towards minimizing the collision rate.

Agreed. Will do.

>     there is added delay in getting things setup.

If the remaining TIME-WAIT period is larger than the
connection-establishment timer, the connection-establishment attempt
will fail. (In any case, I consider long delays in
connection-establishment attempts as an interoperability problem. e.g.,
racall the studies on interactive applications referenced in the tcp
soft errors I-D/RFC).

OTOH, if the TIME-WAIT state is assassinated, packets from a previous
incarnation of he connection could result in undetected data stream
corruption.

>     leave the data structures out.

IIRC, I had included this note as that how this has already been
implemented on some OSes (e.g., OpenBSD). Please let me know if you feel
strongly about removing this text.

>     state on every packet arrival.  That is the same kind of lookup they

I have no problem with removing this text. Michael?

That aside, this might be more of a concern in the case of Algorithm 3.
Thoughts?

>     systems that "create many connections from a single local IP address
>     to a single service".  I think that's pretty dubious.  You might say
>     or 2.  But, I think it's sort of dubious to just leave it hanging as

This is the scenario that lead to users of FreeBSD and OpenBSD to hit
the aforementioned problem. And what led FreeBSD to disable port
randomization when the connection-establishment rate is "high".

That said, if you feel that something along the lines of "You might say
that they make more connections to popular services than end hosts do
(because of the aggregation) and thus increase the population of used
ephemeral ports and hence the chance of collision using Alg. 1 or 2."
would address the point you've raised, I have no problem with
incorporating this text. That aside, I think that this network scenario
(e.g., nat or proxy) would also affect Algorithm 5.

>     which is pretty off-the-mark as I noted above.  

I'm not sure what you mean...

>     Second, the data we
>     is not exactly what is being discussed in this section it seems like

One might argue that this may be the case for scenarios in which the
number of collisions/port utilization is nevertheless small. What if
local port utilization was, say, 50%-70%?

>   - Perhaps I missed it, but it would be nice to define the "traditional

It's the "incremental selection" of port numbers (the one in Figure 1).
Will add a pointer.

>   - Section 3.3.4: "that even a" --> "that a"

I was meaning "even a table of a few entries (10) can result..."

>   - Section 3.3.4: "systems recommend" --> "systems we recommend"

Will do.

>     will work fine for collision avoidance and increasing the table size

I agree with you. The 1024 value is pulled out of the air. The point is
that for a general purpose system, because of memory availability and
cost, you probably won't choose a table size in such a fine-grained way.
But... this is me being pragmatic and non-academic. Also, a value of 10
was enough for that *specific* network scenario/traffic (this is
something that should be clarified, btw)... that's why I'd personally
pick a larger number.

>   - 3.3.5: "introduced yet another" --> "introduced another"

will do. (probably some "english as second language" going on here :-( )

>     clear.  Alas.  When a collision is found we do not increment by one,

Any specific reason for this approach instead of the one described ni
the port randomization I-D?

My take is that the one in our I-D could be better in terms of
collisions of connection-id's.

>     other sections.  I.e., to give the intuition behind it, etc.

Any proposed text?

>     the two environments assessed" or something like that.

You mean in the context of "The larger the
   value of "N", the more similar this algorithm is to the algorithm
   described in Section 3.3.1 of this document.", or where?

>     1 and 2, but not for the remainder of the algorithms.  The "sort of"

In which section?  e.g., Section 3.3.2 (Algorithm #2) does not report
any results, either.

Side note: I do believe myself that Algorithm #4 is the one that has the
best properties. But I didn't mean the text to reflect this fact. SO if
there's any specific text that could be interpreted in such a way,
please let me know and I'll be happy to change it.

>     a little more expensive in a less general case.  At least that's how

Isn't this already noted in Section 3.5?

>   - [Allman] should be:
> 
>       Mark Allman.  Comments On Selecting Ephemeral Ports.  ACM Computer

Will do. Thanks.

Thanks, for the feedback, by the way!
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Mark Allman <[email-masked]>
Date: Tue, 26 May 2009 23:22:55 -0400

[Replying in a series of notes ... this one is just for clarifications.]

> I wasn't able to find the aforementioned sentence. :-(

I am referring to the last sentence in section 2.2.  This could also be
viewed as the sentence immediately before the start of section 2.3.

> strongly about removing this text.

Perhaps relegate it to an appendix and note more specifically this is
what OpenBSD does.  Ultimately, I don't think the document turns on this
point, but I found it out-of-place.

> >     other sections.  I.e., to give the intuition behind it, etc.

Well, no.  I suppose I could generate some if pressed.  But, it'll take
me some time to get to it.

>    described in Section 3.3.1 of this document.", or where?

No.  In section 3.5.

> In which section?  e.g., Section 3.3.2 (Algorithm #2) does not report

Section 3.5.

> Isn't this already noted in Section 3.5?

Without going back to re-read right now... No, I don't think so.  It
would be nice, I think, to say that in the general case collisions are
way, way rare using any of these algorithms according to the data that
has been analyzed.

allman

---

From: Mark Allman <[email-masked]>
Date: Tue, 26 May 2009 23:23:03 -0400

> was actually a PRNG). So I'm not sure how to proceed here...

I didn't remember these, sorry.

I actually don't buy either of these arguments.  But, perhaps something
like "Port Obfuscation Through Randomization and Hashing" would capture
all the keywords.  

I think the title is off-the-mark, but it wouldn't be the first title
and ultimately it isn't a show-stopper.

allman

---

From: Mark Allman <[email-masked]>
Date: Tue, 26 May 2009 23:23:12 -0400

> I agree with you. The 1024 value is pulled out of the air. The point
> is that for a general purpose system, because of memory availability
> and cost, you probably won't choose a table size in such a
> fine-grained way.  But... this is me being pragmatic and
> non-academic. Also, a value of 10 was enough for that *specific*
> network scenario/traffic (this is something that should be clarified,
> btw)... that's why I'd personally pick a larger number.

I think my formulation is better:

   I.e., note that [Allman] shows 10 entries will work fine for
   collision avoidance [to the extent that the data in [Allman] has legs
   outside those environments, of course] and increasing the table size
   increases the obfuscation and leave it at that.

That doesn't say "don't increase the number".  That just says what we
know.  You, Fernando, then choosing 1024 is perfectly fine if that is
where your comfort level is.  I am not quibbling with your particular
gut feeling here.  I just don't see why we should encode that in the
document. 

allman

---

From: Mark Allman <[email-masked]>
Date: Tue, 26 May 2009 23:23:16 -0400

> That said, if you feel that something along the lines of "You might
> say that they make more connections to popular services than end hosts
> used ephemeral ports and hence the chance of collision using Alg. 1 or
> 2."  would address the point you've raised, I have no problem with
> incorporating this text. That aside, I think that this network
> scenario (e.g., nat or proxy) would also affect Algorithm 5.

I am not familiar enough with the FreeBSD/OpenBSD experience.  But,
you're formulation is pretty tightly scoped.  If there is some box
making a bajillion connections to some service then sure... the port
space is going to be used and it is going to be more difficult to choose
additional ports.  But, I don't see that as the norm.  I think the
formulation I sketch that NATs (proxies, etc.) create more contention by
aggregating multiple peers into one port space is a reasonable point to
make.  And, in fact, is shown in the data.  But, the data also shows
that even in this case the collision rate is very low.

allman

---

From: Mark Allman <[email-masked]>
Date: Tue, 26 May 2009 23:23:21 -0400

> connection-establishment attempts as an interoperability
> problem. e.g., racall the studies on interactive applications
> referenced in the tcp soft errors I-D/RFC).
> 

Well, I still don't buy that you're using the most precise language
here.  I wouldn't refer to this problem in that way.  But, I see where
you're going.

allman

---

From: Mark Allman <[email-masked]>
Date: Tue, 26 May 2009 23:23:08 -0400

> the port randomization I-D?

Let's backup and make sure we make something clear... I didn't somehow
mis-implement A5 in my tests.  The I-D is wrong.  (It is my fault the
I-D is wrong.  The paper is not clear enough.)  So, I'd prefer if these
were synced up just to avoid confusion.  If you want to do a riff, call
it something else.

> collisions of connection-id's.

I actually don't think it matters.  Look at the difference between A1
and A2.  Basically, there isn't any difference in the collision rate.
Sometimes A1 is better, sometimes A2 is better.  I'd expect the same
thing in the case of A5 and some inc-by-one riff.

allman

---

From: Mark Allman <[email-masked]>
Date: Tue, 26 May 2009 23:23:19 -0400

> That aside, this might be more of a concern in the case of Algorithm 3.

Why is this more of a concern with algorithm 3?  I think if you are
going to persist in making these claims about lookup time being some
sort of problem then you should illustrate it for us.  Otherwise, I
think the ability of stacks to do this lookup on every packet arrival
indicates that this is a non-problem.  If there is a problem, show us.
If not, let's not imagine a problem.

> I'm not sure what you mean...

This paragraph (under figure 3):

   We will refer to this algorithm as 'Algorithm 2'.  The difference
   between this algorithm and Algorithm 1 is that the search time for
   this variant may be longer than for the latter, particularly when
   there is a large number of port numbers already in use.  Also, this
   algorithm may be unable to select an ephemeral port (i.e., return
   "ERROR") even if there are port numbers that would result in unique
   five-tuples, particularly when there are a large number of port
   numbers already in use.

It's all dubious conjecture.

> local port utilization was, say, 50%-70%?

Oh, come on .... we can all construct scenarios that cause fits for all
these algorithms.  Even if you're right, does it matter?  To more than 3
people in the entire world?  I mean, come on, ... there is some *actual
data* that has been reviewed and published on the subject.  We should
use it to guide our work here.  Why discount reality?  I am saying that
[Allman] represents all of reality.  It surely does not.  But, it's the
best we've got right now.  Why are we still waving our hands over wild
out-of-the-blue scenarios that could, possibly, in some case happen?  If
we want to do that then why don't we just say all the algorithms suck
when there are 63K-1 ports the peer's TIME-WAIT for some connection ID
and we need that last port?  There.  They all suck.  Let's just throw
the document away.  OK?  I think the clear path here is to try to be
even-handed and use the information at hand to drive progress and not
our wild fantasies.

allman

---

From: Randall Stewart <[email-masked]>
Date: Wed, 27 May 2009 05:12:19 -0400

On May 26, 2009, at 9:58 AM, Joe Touch wrote:

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

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

> iEYEARECAAYFAkob9W0ACgkQE5f5cImnZrseiQCfZEJ3sWltiyvMmSnTkwyyWooy
> J5IAoMhmJQBfK5rsxmJeOnUXgsXpGOR8
> =OWYf

------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 27 May 2009 08:45:58 -0700

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

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.

Thanks,
-Anantha

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 May 2009 09:24:00 -0700

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

> is that the vtag (a billon spaced one) needs to be unique for every new

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.

> TOTALLY different. (esp for the context the current discussion is

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

> sense as far the current discussion goes) to deal with the port reuse

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

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 27 May 2009 09:26:41 -0700

> It's worth noting that many implementations aren't RFC 
> compliant in this regard, though.

Which TCP implementation is not honoring TIME-WAIT state (BSD, Linux,
our implementations etc., all honor TIME-WAIT requirement)? The only
thing is that the "ancient" 2MSL value can be configurable. 2MSL is
getting adapted to modern networks and in some intranet cases this value
is configured to be very small, FWIW. 

> 
> > It is also well known that the side-effect of TIME-WAIT requirement 

The reason I use the term "side effect" is beause if the TIME-WAIT state
deosn't exist, your port reuse factor aka connection acceptance rate
(for the same socket pair) gets increased. YMMV.

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

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 May 2009 09:50:22 -0700

> is configured to be very small, FWIW. 

RFC793 specifies MSL as 2 minutes, and it is not "configurable". In
terms of following the specification, that's where most implementations
fail.

Many modern networks actually take advantage of this MSL when they do
not flush their buffers during short-term outages. In networks with such
paths - e.g., users on cellphones that go through tunnels, etc. - RTT is
not a reasonable estimate of MSL.

> (for the same socket pair) gets increased. YMMV.

If TIME-WAIT doesn't exist, your potential to have data from an old
connection corrupt a new connection also increases, and you no longer
have a reliable protocol. If you call that "mileage", sure; I call that
a crash ;-)

> it). TIME-WAIT state doesn't exist in the SCTP protocol. Pl see Randy's

While I agree that the term "TIME-WAIT" does not appear in RFC 2690,
there is a note:

" 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?

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 May 2009 13:49:21 -0300

Hello, Mark,

> I didn't remember these, sorry.

Alfred (CC'ed) made this comment on the tsvwg mailing-list a while ago.

Eric made this comment in the context of my timestamps I-D (which uses
essnetially the same algorithm), on the tcpm wg mailing-list.

> and ultimately it isn't a show-stopper.

I honestly don't care about the title either way (i.e., keep the current
one or change it). I guess the chairs could provide advice on how to
proceed?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 May 2009 14:07:48 -0300

>> randomization when the connection-establishment rate is "high".
[....]
> make.  And, in fact, is shown in the data.  

I agree with this.

> But, the data also shows

This is the one I'm not sure about. Yes, I believe in the result of your
research. However, can we really assume that the network scenario in
which you measure connections really represents most network scenarios,
and that therefore we can broadly claim that "collision rates resulting
from NATs are very low"?

I'm not saying that is not the case. I'm just wondering whether it would
be appropriate that the data we have represent mosts network scenarios.

e.g., it is not unusual to have a large number of clients behind a NAT
connecting every few seconds to a mailserver on the public side of the
NAT.This may be a dumb thing to do... but it does happen.

Thoughts?

Thanks,

---

From: Mark Allman <[email-masked]>
Date: Wed, 27 May 2009 13:42:49 -0400

> > space is going to be used and it is going to be more difficult to
> > choose additional ports.  But, I don't see that as the norm.  I
> > think the formulation I sketch that NATs (proxies, etc.) create more
> > contention by aggregating multiple peers into one port space is a
> > reasonable point to make.  And, in fact, is shown in the data.
> 
> I agree with this.
> 
> > But, the data also shows that even in this case the collision rate
> > is very low.
> 
> This is the one I'm not sure about. Yes, I believe in the result of
> your research. However, can we really assume that the network scenario
> in which you measure connections really represents most network
> scenarios, and that therefore we can broadly claim that "collision
> rates resulting from NATs are very low"?
> 
> I'm not saying that is not the case. I'm just wondering whether it
> would be appropriate that the data we have represent mosts network
> scenarios.
> 

I'm not asking you to say that the data in my paper is representative.
I have repeatedly said that in fact it is two data points and we know
that the Internet is a widely variable place.  The formulation I give
above notes that NATs and proxies cause aggregation that the causes
*more* contention for the port space.  That is reasonable to say.  And,
in fact, the data in my paper does show slightly more collisions when a
NAT is assumed because of this aggregation and contention.  What I am
responding to is this wild notion that somehow NATs and proxies are
going to *dramatically* effect things.  Certainly they *can*.  And,
certainly any one of us could *dream* the scenario where it might
happen.  But, to repeat, I don't think we should be basing our decisions
here on dreams or handwaves.

(And, also note that as I noted in [Allman] one could view a quite busy
NAT or proxy as not being all that vulnerable to these sorts of attacks
anyway just because their normal port allocation---say using the
traditional BSD scheme---moves fast enough and involves enough remote
IPs that blind attacks are naturally mitigated.)

allman

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 May 2009 14:47:24 -0300

> here.  I wouldn't refer to this problem in that way.  But, I see where

Please let me know if you expect a change in the text, or whether it
would be okay to leave the text "as is".

FWIW, I could expand "interoperability problems" to "delays in the
establishment of connections or data corruption" if necessary. -- I just
thought that that was too much detail.

Thanks,

---

From: Mark Allman <[email-masked]>
Date: Wed, 27 May 2009 13:52:41 -0400

> establishment of connections or data corruption" if necessary. -- I
> just thought that that was too much detail.

I prefer this.  It's what you mean.

allman

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 May 2009 13:58:13 -0300

>    increases the obfuscation and leave it at that.

Increasing the table might possibly decrease the collision rate, too.
(i.e., it prevents the system from skipping port numbers unnecessarily).
I do not recall what were results of your research in this area,
though... but will look at your paper again.

Agreed. Will do.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 May 2009 14:52:34 -0300

Mark Allman wrote:

[....]
> *more* contention for the port space.  That is reasonable to say.  

Agreed. Will do.

> And,

I wil review the text. What I meant is that they *can*.. not that they
"will".

> IPs that blind attacks are naturally mitigated.)

Agreed.

Thanks,

---

From: Mark Allman <[email-masked]>
Date: Wed, 27 May 2009 13:51:31 -0400

> (i.e., it prevents the system from skipping port numbers
> unnecessarily).  I do not recall what were results of your research in
> this area, though... but will look at your paper again.

As I **said above**, I found that a table of 10 entries works fine for
collision **avoidance**.

You can likely dream up some scenario whereby a bigger table size does
in fact reduce the collision rate.  Or, perhaps whereby you can reduce
the collision rate to less than zero.  I prefer just looking at the
data, but realize YMMV.

Again, I am not asking you to say a table size of 10 is somehow ideal.
I am just saying that we have some data that suggests it is OK in some
environments and that plus a note that increasing the size increases the
obfuscation seems perfectly reasonable to me.  I don't see how pulling
some number out thin air is better.  I don't see how your number is
justified.  If you want to use it, great, I don't care.  But, I don't
see why we need to be recommending or suggesting this completely made up
value.

allman

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 May 2009 16:43:10 -0300

> I prefer this.  It's what you mean.

Ok. Will do.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 May 2009 16:49:11 -0300

Mark Allman wrote:

> obfuscation seems perfectly reasonable to me.  

I agree with this. In particular, when the sentence includes the phrase
"in some environments". That's the only thing I was arguing.

> I don't see how pulling

I had already agreed that I would be removing the value 1024. I was only
arguing that "a table of 10 is enough" is misleading. Something along
the lines of "[Allman] has found that in some environments a table size
of 10....". That's all.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 May 2009 17:25:50 -0300

Mark Allman wrote:

> mis-implement A5 in my tests.  

Who said that? How could you mis-implement it, if you introduced the
algorithm yourself? -- That's not what I meant.

> The I-D is wrong.  

Yes, it is wrong, in the sense that it does not reflect the algorithm
you introduced, etc.

What I meant, is (just me being curious): Was there any reason for which
you retry random ports instead of retrying the ports in an incremental way?

That said, should we include both variants? (we *did* do this for Alg #1
& Alg #2). As far as I am concerned, I don't care either way (i.e., just
sync'inc the I-D with your paper, or sync'ing *and* also adding a second
variant of the random-increments approach).

> (It is my fault the
> were synced up just to avoid confusion.  

Yes, that's what I was meaning to do.

> thing in the case of A5 and some inc-by-one riff.

I'd would expect this to change the the number of port numbers in use is
much higher. But this is just me guessing, and probably doesn't matter -
at least as far as this doc is concerned.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 May 2009 18:33:55 -0300

Mark Allman wrote:

>    there is a large number of port numbers already in use. 

This one might be dubious. (although it says "may", not "will").

>     Also, this

If you retry random port, chances are that you may retry the same port
more than once, instead of trying a different port that might be
available. The larger the number of ports in uses, the more likely this
would be. (see the pseudo-code).

Does this actually happen in practice? - Well, the only data that we
have shows a very small number of collisions, so this won't be evident
(as only a couple of retries are enough).

That's my reasoning.

That said, I have no problem with tweaking the text. If you have a
specific proposal, please let me know.

Thanks,

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 27 May 2009 16:05:17 -0600

Joe,

You can hold the old tag long enough to get a new one: a few
nanoseconds or so...

--brian

Joe Touch wrote:                                (Wed, 27 May 2009 09:50:22)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 May 2009 15:11:08 -0700

> You can hold the old tag long enough to get a new one: a few

Sure. Do that a few times, then have packets with the old tag show up
and tell me what happens ;-)

Yes, the space is big, but it's not infinite. Systems are well known to
seed 'random' generators with the same values on reboot. Overall, this
sounds like "security by faith".

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 May 2009 20:07:12 -0300

Hello, Mark,

Comments in-line....

> viewed as the sentence immediately before the start of section 2.3.

Sorry, I wasn't able to do it (probably "english as a second language"
going on here).

The current sentence is:

"  Additionally, if an
   attacker could force a client to periodically establish a new TCP
   connection to an attacker controlled machine (or through an attacker
   observable routing path), the attacker could subtract consecutive
   source port values to obtain the number of outoing TCP connections
   established globally by the target host within that time period (up
   to wrap-around issues and 5-tuple collisions, of course)."

> point, but I found it out-of-place.

You are arguing against the inclusion of "array of bits" as an
implementation approach, rather than against that of "keeping a list of
the reserved ports in the range 1024-65535, right? - If so, I will tweak
the text.

> me some time to get to it.

Ok. Will craft some text and post it on the list for review.

>>    described in Section 3.3.1 of this document.", or where?

Will do. (Sorry, it seems I had misread your comment).

Will do.

P.S.: Please let me know if there are any issues open, so that I start
working on a rev of the port randomization I-D.

Thanks,

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 27 May 2009 18:20:17 -0700

Joe,
    
> protocols like 
> > 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.

> 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

---

From: Randy Stewart <[email-masked]>
Date: Wed, 27 May 2009 21:31:35 -0400

Joe:

Just a few comments ;)

>>> While I agree that the term "TIME-WAIT" does not appear in RFC 2690,

Its actually 2960 ... but of course thats obsolete anyway and the
new document is 4960.

Now it too does not mention time-wait.. but I agree with you 100%... its
implicit in the fact its the only way you will be able to assure that
its not used... Thats exactly why we put this in the BSD  
implementation. Its
probably one of the things we should have added to 4960.. I know we
had discussed it on this list previously... but it never made it
into the errata document. It most likely would have been a SHOULD
so I guess implementations could still not do it and claim to
be fully compliant... but IMO you really need to time-wait the
vtag's.

R

> iEYEARECAAYFAkodunwACgkQE5f5cImnZrsjEACfTl4Auix1CYhX1KgLNQh7S1R8
> 6xEAnA3BGTnf8KhQjylHAsRZXtkCUkrE
> =KBIL

-----
Randall Stewart
[email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Wed, 27 May 2009 21:39:38 -0400

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

R

-----
Randall Stewart
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 May 2009 21:14:53 -0700

Randy Stewart wrote:
> 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

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

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 May 2009 21:19:05 -0700

Ananth,

Please see Randy's post.

> corruption from an old incarnation (your crash ;-)

SCTP is *not* robust unless you hold at least the socket pair + vtag
tuple* in some wait state. Holding just the vtag is perhaps less work,
but inhibits more connections than holding the true connection ID (the
socket pair + vtag tuple).

* (that's not the TCB, FWIW - TCBs have all sorts of other stuff (time
since last packet sent, RTT estimates, etc.)

Without holding some sort of wait state, there is NO inbuilt mechanism
that avoids corruption from an old connection. The *assumption* is that
the vtags are not reused in sequence.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 May 2009 21:28:19 -0700

Oh, and a point about vtags being random:

> having a sequential allocation for vtags.

...
> The SCTP RFC doesn't say that vtag
> implementation details).

Yes, it does:

- From 4960:

    Verification Tag: A 32-bit unsigned integer that is randomly
                                                        ^^^^^^^^
      generated...
      ^^^^^^^^^

Then later:

 A) "A" first sends an INIT chunk to "Z".  In the INIT, "A" must
      provide its Verification Tag (Tag_A) in the Initiate Tag field.
      Tag_A SHOULD be a random number in the range of 1 to 4294967295
                        ^^^^^^^^^^^^^
      (see Section 5.3.1 for Tag value selection).  After sending the
      INIT, "A" starts the T1-init timer and enters the COOKIE-WAIT
      state.

The verification tag is copied from the initiate tag on connection
establishment, which is defined as being random as follows:

5.3.1.  Selection of Tag Value

   Initiate Tag values should be selected from the range of 1 to 2**32 -
   1.  It is very important that the Initiate Tag value be randomized to
   help protect against "man in the middle" and "sequence number"
   attacks.  The methods described in [RFC4086] can be used for the
   Initiate Tag randomization.  Careful selection of Initiate Tags is
   also necessary to prevent old duplicate packets from previous
   associations being mistakenly processed as belonging to the current
   association.

That's pretty random, and AFAICT cannot be sequential and be OK. The
trouble with randomness, however, as I noted is that it often is
(incorrectly) tied to parameters that repeat on reboot.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 27 May 2009 23:30:09 -0700

> From: Joe Touch [mailto:[email-masked]] 
> Sent: Wednesday, May 27, 2009 9:15 PM
> To: Randy Stewart
> Cc: Anantha Ramaiah (ananth); tsvwg; James Polk (jmpolk); 
> Fernando Gont; [email-masked]
> upon the key 
> > point. If you are doing time-wait.. you are doing time-wait on 
> > vtags... aka: 32 bit numbers.
> > 
> 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.
> 
> 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. 

> > 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
> >> 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 ;-)
> >>
> >>> 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
> > [email-masked]
> > 
> > 
> > 
> iEYEARECAAYFAkoeD70ACgkQE5f5cImnZruySACfdm9p30W0GcuKaBUJ6rKoXxBL
> lm4AoNrFpWuRY8BCMw6R8/5wtyPfztOv
> =5uhf

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 27 May 2009 23:38:07 -0700

Yep, I stand corrected on that point (Randy did point to me the same),
agreed,  the chances of collision are more compared to sequential. As
far as port reuse is concerned, the key point is that in case of TCP it
is a 16 bit number (since TCP doesn't have any extra mechanism to
discard duplicates) whereas in SCTP it is 32 bit number (vtag). Pl see
my other post.

-Anantha 

> Sent: Wednesday, May 27, 2009 9:28 PM
> Cc: Fernando Gont; [email-masked]; James Polk (jmpolk); tsvwg
> > Well, this is purely implementation specific, some imp. can 
> simply be 
> > ok having a sequential allocation for vtags.
> 
> ...
> > generation needs to be sequential/random (rightfully so, 
> since it is 
> > all implementation details).
> 
> Yes, it does:
> 
> - From 4960:
> 
> The verification tag is copied from the initiate tag on 
> connection establishment, which is defined as being random as follows:
> 
> That's pretty random, and AFAICT cannot be sequential and be 
> OK. The trouble with randomness, however, as I noted is that 
> it often is
> iEYEARECAAYFAkoeEuMACgkQE5f5cImnZrt4ygCg49IUXOHhqDaYln5UdlbhU1Eu
> mRsAn12Ugysx32gLlVUqb93nGSFvRNGJ
> =qMOl

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Thu, 28 May 2009 00:01:06 -0700

> 
> * (that's not the TCB, FWIW - TCBs have all sorts of other 
> stuff (time since last packet sent, RTT estimates, etc.)

Cmon, Joe, the connection block is a superset of everything, every TCP
implementer knows that. Now, *some* implementations would save memory by
freeing the TCB before entering the TIME-WAIT and hold a micro-TCB (or
whatever you call it as) to identify the "connection" and the connection
identifier is the socket-pair (4 tuple)

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2009 06:56:59 -0700

...
> What do you mean by "all socket pairs",

All values of A, X, B Y - i.e., *every* service from *every* source port
on *every* remote host to *every* IP address on the local host.

> at any given time there is only
> *one* association with a given socket pair S.

That's true for TCP too.

> Also *every* vtag that is

You're missing the point. By putting the vtag - by itself - into a
"time-wait", you are effectively saying that the vtag - by itself - is
the unique connection ID. That's not what 4960 says.

> jurisdiction of transport protocol code. 

I am adding the bits because in TCP I can support multiple connections
from different ports and different IP source addresses to different IP
destinations on the same machine. If you hold onto vtag 0xffff in a
time-wait, you're saying that 0xffff is prohibited on *all* new
connections, regardless of address or port (to that host).

> vtag takes a lot of time) 

Random selection does not ensure uniqueness within some given time. In
fact, if it did, it would be easy to show it was *not* random.

> Ok, let me ask you this question : lets assume
> mechanism to detect old segments (PAWS), 

This is a red herring - RFC 4960 prohibits monotonic increasing vtags.
They need to be random - they even say how that randomness is defined.

> so question is : do you still
> into the data stream. 

So let's presume (incorrectly) that vtags are monotonic. Even then, I
agree that this *helps*, but you're treating this as a form of
"prevention". It doesn't *prevent* anything.

For a *single* service, we agree that vtags increase the space of
identifiers to detect overlapping connections, but the extent of this
protection depends on how fast the connections happen, and the extent to
which it repeats undetected - which "random" does ***not*** prohibit.
The only safe way to prevent repetition is to hold state, just as TCP does.

Now, if you're going to start holding vtags across all ports and IP
addresses, i.e., treating just the vtag as a unique ID, you may have
made things better for a single socket pair, but you make things
**worse** for arbitrary socket pairs coming into a machine, which had a
lot more entropy than 32 bits.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2009 06:58:44 -0700

> discard duplicates) whereas in SCTP it is 32 bit number (vtag). Pl see

In TCP, for a single socket pair, it is a 0-bit number.

In TCP, for arbitrary source IP addresses and services, over arbitrary
ports, it is at least 64 bits (plus more bits if the local host has
multiple IP addresses).

In SCTP, if you hold *just* the vtag, it's 32 bits, which is *lower*
than TCP in the second case above.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2009 07:01:06 -0700

> identifier is the socket-pair (4 tuple)

Well, you wanted to be specific about terminology.

The term for a connection ID in TCP is a socket pair, not a micro-TCB.
It is the socket pair that is held in time-wait; whether an
implementation also holds onto any memory associated with the connection
(the TCB) is its choice.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2009 07:34:15 -0700

Taking a step back, I thought it would be useful to summarize the key
issues of this discussion (IMO):

1) randomizing connection IDs helps protect against blind attacks

	- but ultimately the only way to avoid old segments
	from interfering with new connections is to keep state

	- randomness requires keeping more state at the endpoints
	than sequential use of the ID space

2) keeping state at the endpoints is costly

	- large ID space helps with #1, but can end up
	amplifying storage costs when IDs have no
	lifetime of "no reuse"

3) randomness is costly

	as SCTP demonstrated, asserting randomness may be better
	done by referring to existing separate definitions

Joe

---

From: Randy Stewart <[email-masked]>
Date: Thu, 28 May 2009 10:39:37 -0400

Joe:

In-line..

On May 27, 2009, at 12:50 PM, Joe Touch wrote:

>> implementations do

Basically for BSD we take a v-tag used in a connection.. call it 'X',  
and
we place just the tag 'X' into a "timed-wait" cache for 2MSL. There is  
no
restriction on the socket here.. just the tag 'X' will not be used again
with this socket.

So say the socket did the following:

sd = socket(..., ONE-2-MANY)

/* setup events .. not shown */

sd = sctp_connectx(ip-z, &assoc-id);

<---At transport layer Vtag=X --->

sctp_sendmsg(some-mesg, size,... assoc-id);

... some time later
sctp_sendmsg(SCTP_EOF, assoc-id);

<---SHUTDOWN is sent, and at conclusion
     the V-tag'X' is placed in timed-wait.

<-- event returned telling you the association is gone.

Then right away (less than 2MSL).. app does

sd = sctp_connectx(ip-z, &assoc-id);

<- Transport layer randomly picks a new vtag but CANNOT use 'X'
    (its in the time-wait cache).. so it uses 'Y'.

sctp_sendmsg(hello-again, size, ..., assoc-id);

Note that In theory I did not even need to have the "connectx calls"  
since
SCTP will setup the association implicitly ... I added these for clarity
in this email ;-)

So basically the socket/port and peer socket/port is re-used right  
away with
the restriction being that the vtag 'X' cannot be used.

Hope that clears up the issue  :-)

R

> iEYEARECAAYFAkodb04ACgkQE5f5cImnZruWNwCfUx8QgBSsjEo2zKsRuFtykbpp
> 4DQAmwaWCj0UjpRscD8aOwx4Xznkq2xa
> =WP09

-----
Randall Stewart
[email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 28 May 2009 08:45:40 -0600

Randall,

Note for the next interop: could I run you low on memory
by just forming and aborting assocations rapidly?  That
is, put all of your 2^32 vtag into this undocumented vtag
timed-wait state?

Do you do this per-port? Per transport-address pair and
port?  Could I put 2^32 into wait state for more than one
transport address port combination?  I could really run
you out of (instead of low on) memory then...

--brian

Randall Stewart wrote:                      (Wed, 27 May 2009 05:12:19)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 28 May 2009 08:51:14 -0600

Randy,

So, by forming and releasing 2^32 associations within 2MSL I can
rum you out of vtags?  That might be a lot of memory depending on
how much memory you use for each vtag in this wait state.  What
do you do when all of the vtags are in wait state?  Can a new
association form?

--brian

Randy Stewart wrote:                          (Thu, 28 May 2009 10:39:37)
> 
> Basically for BSD we take a v-tag used in a connection.. call it 'X',  and
> we place just the tag 'X' into a "timed-wait" cache for 2MSL. There is  no

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Mark Allman <[email-masked]>
Date: Thu, 28 May 2009 11:02:23 -0400

> Yes, that's what I was meaning to do.

To me you sync them and call it a day.  I.e., I see no reason for
describing another riff.

allman

---

From: Randy Stewart <[email-masked]>
Date: Thu, 28 May 2009 11:07:27 -0400

> of short connections could easily have vtag collisions in that  

No actually Q is blocked ONLY for the socket pair
A,X -> B,Y for 2MSL.

> stalling to handle interruptions - things are getting worse along  

And that is why Vtags are time waited in SCTP... I understand
the issue.. but often times in lab conditions its an annoying
pain to deal with ;-)

R

>>> have

-----
Randall Stewart
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2009 08:11:42 -0700

...
>> So basically the socket/port and peer socket/port is re-used right away
>> with

Yes, but it also underscores my concern. What you did was basically:

	- increase the space available to a single service from
	a single IP address
		going from TCP's 16 bits (max) of source port to
		48 bits of source port + vtag

	- *decrease* the space available for different
	services from different IP addresses
		going from TCP's 32 bits of address +
		16 bits of source port + 16 bits of
		dest port (64 bits) down to only 32

Joe

---

From: Randy Stewart <[email-masked]>
Date: Thu, 28 May 2009 11:15:27 -0400

For a particular port X you have a limit of 2^32
vtags.. yep..

But the BSD implementation would not support that many simultaneous
connections anyway.. I think we have a sysctl limit of about 40,000
associations... it can be raised... but the default is 40k..

So you might have a hard time rolling over that many associations
in the period of time your talking about.

If you don't keep a timed wait, then you could get old packets
injected on a new association.. for example an ABORT could
be tossed at you from an old association where you re-used
the vtag...

R

-----
Randall Stewart
[email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Thu, 28 May 2009 11:18:55 -0400

On May 28, 2009, at 11:11 AM, Joe Touch wrote:

>>> away

Joe:

I don't follow your meaning here..

I can have

IP-A Port-X Vtag-Y <---->
and
IP-A Port-Y Vtag=Y <---->

existing simultaneously... so I don't see how this decreased the
space for services from different IP addresses...

R

> iEYEARECAAYFAkoeqa4ACgkQE5f5cImnZrsNGgCg8Kjm1IoDOf7zN40ChPUt6NOj
> m9EAoKb+AEJRebbaPLyhPNvKGI3ckPZv
> =YNfE

-----
Randall Stewart
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2009 08:12:53 -0700

Brian F. G. Bidulock wrote:
> rum you out of vtags? 

SCTP doesn't indicate that vtags can be reused within 2MSL; it doesn't
say how long to hold them.

I.e., you might have more than 2MSL of time to play with for this attack.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2009 08:15:31 -0700

See below; now I'm really confused:

>> No actually Q is blocked ONLY for the socket pair

I don't see 2MSL anywhere in the SCTP spec.

Your earlier note said you blocked Q for all sockets; this says you
block only within the socket pair -- which is basically what I've been
saying all along - you block on the full connection ID, i.e., [A,X,B,Y,Q].

Joe

---

From: Randy Stewart <[email-masked]>
Date: Thu, 28 May 2009 11:23:17 -0400

> saying all along - you block on the full connection ID, i.e.,  

I did not describe where the time wait is kept... I just said
I keep it ;-)

Vtag Q is blocked for the socket.. its not the full connection id.
So A/X/Q is blocked (assuming A is the IP and X is the port). We
can establish a new association with B/Y as long as we have
a different vtag i.e. Q'.

At the same time, some other socket on machine A ... lets say A/X'
can have a association to the same peer with vtag Q as well.
i.e.

A+X+Q <------assoc ---> B+Y+T

and

A+Y+Q <----- asoc ---> B+Y+U

The key is that when A+X+Q stops and starts a new association, for 2MSL
it can't use vtag Q...  i.e. it must use Q'

R

> iEYEARECAAYFAkoeqpMACgkQE5f5cImnZrufNQCgi/9fCaS/wk4Yhc9oo3quwBEq
> DzoAoOgTAdS7b5jkYIFbgT2jp9sQrgc6
> =dlHs

-----
Randall Stewart
[email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Thu, 28 May 2009 11:24:55 -0400

True, its not specified... in BSD we set it at
2MSL but I believe its a configurable option as well. i.e. a sysctl

R
On May 28, 2009, at 11:12 AM, Joe Touch wrote:

> iEYEARECAAYFAkoeqfUACgkQE5f5cImnZrscpwCg3f5HUMZamswcpjoL94klfxgb
> 5ZoAnAjNIRIculeYHHMf1AnmIVCTZkIe
> =XsuZ

-----
Randall Stewart
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2009 08:31:19 -0700

>> space for services from different IP addresses...

OK so there's two cases:

	1) the vtag is the unique thing held (NO OTHER STATE)
	2) the vtag is held in the context of the socket pair

In 1), the vtag effectively is the connection ID.

In 2), the connection ID is the 5-tuple of
[srcIP,srcport,dstIP,dstport,vtag]

In the case of 1), you decrease the space available for connections vs.
TCP when you include connections from different machines and for
different services.

In the case of 2), you increase the space available, and I don't have
the concern raised above.

I am still a bit confused as to which case is true; you appeared to give
two different responses.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2009 08:36:24 -0700

Randy Stewart wrote:
...
>> Vtag Q is blocked for the socket.. its not the full connection id.

which socket? [A,X] or [B,Y]?

>> it can't use vtag Q...  i.e. it must use Q'

(again, I don't see 2MSL in the SCTP doc on vtag reuse times)

What are T and U (isn't the tag bidirectional?)?

Joe

---

From: Randy Stewart <[email-masked]>
Date: Thu, 28 May 2009 11:45:41 -0400

On May 28, 2009, at 11:31 AM, Joe Touch wrote:

>>>>>> we place just the tag 'X' into a "timed-wait" cache for 2MSL.  
>>>>>> There
>>>>>> is no
>>>>>> restriction on the socket here.. just the tag 'X' will not be  
>>>>>> used
>>>>>> again
>>>>>> with this socket.
>>
>> ...

Ok, I just went out and looked at the code (sometimes its good to  
refresh your memory ;-D)

Basically the vtag cache holds:

1) Vtag
2) Source port
3) Destination port
4) A timestamp when the entry expires.

This is all hashed on SrcPrt+DstPrt+Vtag-in-time-wait.

So when I go to create a new association, I

1) Randomly generate a vtag e.g. R
2) Hash R+local-port+Peer-port
3) Use hash to look in vtag time wait block.
4) If found goto 1
    else use vtag-R

The IP addresses themselves are not saved in this. Could they be,  
sure, we just
decided not to... since one would then have to have a "set" of IP  
addresses
and a port on each side... and that seemed unneeded. Of course, as I  
said, most
implementations have no timed-wait on anything.. which we in theory  
could do
by setting the Time = 0... so they expire right away... But I don't  
think
that is wise.

It might even be wise to go back and expand the hash to include the IP  
addresses of the peer...
since this simpler approach does limit the vtags somewhat... i.e. a  
peer connecting to
a server from a same port could not use a vtag thats in time-wait...  
which is not
strictly correct...

R

> iEYEARECAAYFAkoerkcACgkQE5f5cImnZrvVlQCgoNoQPGril0N687ocbOD1n0ex
> cUoAn35PgtR+ogd0NGkkPZBD74H39MzN
> =uJLP

-----
Randall Stewart
[email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Thu, 28 May 2009 11:47:08 -0400

> What are T and U (isn't the tag bidirectional?)?

The tags the peer picked... not that the local endpoint
cares as far as this discussion is concerned.

Note that your right, we do NOT list 2MSL in the document.. in fact
we don't mention timed wait per se... and maybe it should
be in the document...

R
> iEYEARECAAYFAkoer3cACgkQE5f5cImnZrvsogCg5cM7lakepecFJqoHQid06B38
> J+kAn0qyUXrOajdK0qQrIM+rSbpGPsA7
> =moQg

-----
Randall Stewart
[email-masked]

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 28 May 2009 19:55:00 +0200

Hi Joe,

just a clarification:

* timewait for vtags is currently no described in
   any SCTP specification.
* the need for this kind of feature came up
   several times.
* Randall describes what is used implemented in
   FreeBSD and it does take the port number pair
   into account.
* Since an SCTP endpoint can have multiple addresses
   and these addresses can change over time, addresses
   are not considered in the FreeBSD implementation.

Looking at the discussion, I think we need to write
up an ID describing this stuff. This would also clarify
things for other implementations which do not have
this kind of stuff at all.

Best regards
Michael

On May 28, 2009, at 5:45 PM, Randy Stewart wrote:

> It might even be wise to go back and expand the hash to include the  
> IP addresses of the peer...

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Thu, 28 May 2009 11:19:42 -0700

Randy/Michael :
 My suggestion here would be :

Suppose you are going to specify the timewait of vtags in the spec etc., I would like the following point to be considered (debated in the list):
- Just not repeat the same thing done for TCP i.e, 2MSL (4 minutes!). 2MSL time was considered the "safe and conservative time" for the old segments to be drained out of the network in 1981. Now this timewait value is, needless to say, is ultra-conservative for modern networks and SCTP being a modern transport protocol, should consider more thought while choosing the empirical value. Almost every implementation out there provides a knob and nobody waits for 4 minutes as far as TCP is concerned. FWIW.

I also agree with the other point which Randy made, ie., to include IP addresses in the vtag hash. This is what we do today for TCP (I am not talking about active close, which anyway maintains the complete 4 tuple) for passively closed connections as well. (the expired timewait ID which we had posted).
Thanks,
-Anantha

> From: Michael Tüxen [mailto:[email-masked]] 
> Sent: Thursday, May 28, 2009 10:55 AM
> To: Joe Touch
> Cc: James Polk (jmpolk); Randy Stewart; Anantha Ramaiah 
> (ananth); tsvwg; [email-masked]; Fernando Gont
> Looking at the discussion, I think we need to write up an ID 
> describing this stuff. This would also clarify things for 
> other implementations which do not have this kind of stuff at all.
> 
> Best regards
> Michael
> 
> >>>>>>> Basically for BSD we take a v-tag used in a 
> connection.. call it 
> >>>>>>> 'X', and we place just the tag 'X' into a 
> "timed-wait" cache for 
> >>>>>>> 2MSL.
> >>>>>>> There
> >>>>>>> is no
> >>>>>>> used again with this socket.
> >>>
> >>> ...
> >>>>>>> So basically the socket/port and peer socket/port is re-used 
> >>>>>>> right away with the restriction being that the vtag 
> 'X' cannot 
> >>>>>>> be used.
> >>>>>>
> >> In the case of 1), you decrease the space available for 
> connections 
> >> vs.
> > sure, we just decided not to... since one would then have to have a 
> > "set" of IP addresses and a port on each side... and that seemed 
> > unneeded. Of course, as I said, most implementations have no 
> > timed-wait on anything.. which we in theory could do by setting the 
> > Time = 0... so they expire right away... But I don't think that is 
> > wise.
> >
> > peer connecting to a server from a same port could not use a vtag 
> > thats in time-wait...
> > which is not
> > strictly correct...
> >
> >
> >
> > R
> >
> >>
> >>
> >> I am still a bit confused as to which case is true; you 
> appeared to 
> >> give two different responses.
> >>
> >> Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2009 11:18:13 -0700

> this kind of stuff at all.

Sure - I'd be glad to assist...(NB to the chairs/ADs: yes, only after
TCP-AO is revised, which is coming shortly).

Joe

>>>>>>>>> right away
>>> by setting the Time = 0... so they expire right away... But I don't think
>>> that is wise.
>>>

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2009 13:25:19 -0700

Anantha Ramaiah (ananth) wrote:
> Suppose you are going to specify the timewait of vtags in the spec
> etc., I would like the following point to be considered (debated in the
> list):
> - Just not repeat the same thing done for TCP i.e, 2MSL (4 minutes!).
> 
> 2MSL time was considered the "safe and conservative time" for the old
> segments to be drained out of the network in 1981. Now this timewait
> value is, needless to say, is ultra-conservative for modern networks and
> SCTP being a modern transport protocol, should consider more thought
> while choosing the empirical value. Almost every implementation out
> there provides a knob and nobody waits for 4 minutes as far as TCP is
> concerned. FWIW.

Right. 2MSL might be way too short, given how new systems 'stall' for
longer periods of time -- e.g., as I noted how routers don't flush
queues when on trains going through tunnels.

While I agree that 2MSL might be incorrect as a value, there might be
good reason to *increase* the "do not repeat" period as well, as a
result of such "modern" environments.

Joe

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 28 May 2009 22:32:37 +0200

On May 28, 2009, at 8:19 PM, Anantha Ramaiah (ananth) wrote:

> etc., I would like the following point to be considered (debated in  
> the list):
> - Just not repeat the same thing done for TCP i.e, 2MSL (4  
> minutes!). 2MSL time was considered the "safe and conservative time"  
> for the old segments to be drained out of the network in 1981. Now  
> this timewait value is, needless to say, is ultra-conservative for  
> modern networks and SCTP being a modern transport protocol, should  
> consider more thought while choosing the empirical value. Almost  
> every implementation out there provides a knob and nobody waits for  
> 4 minutes as far as TCP is concerned. FWIW.
Currently we have made this sysctl'able. So operators could change  
that...
>
>
> I also agree with the other point which Randy made, ie., to include  
> IP addresses in the vtag hash. This is what we do today for TCP (I  
> am not talking about active close, which anyway maintains the  
> complete 4 tuple) for passively closed connections as well. (the  
> expired timewait ID which we had posted).
I would not include the IP address in the timewait, since we have  
multiple addresses
in SCTP which can even change over the lifetime of an SCTP endpoint...

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 28 May 2009 14:38:44 -0600

Randy,

Randy Stewart wrote:                          (Thu, 28 May 2009 11:15:27)
> be tossed at you from an old association where you re-used

I'm not sure that a time-wait will do that either: that is: When
all the vtags are in timed-wait what will you do?  If you refuse
the connection there is a DoS attack waiting to be exploited. If
you go with a vtag in timed-wait then you have a risk, just as
other approaches.  Just putting a vtag into timed-wait risks a
DoS attack.

For example, using a cryptographically generated vtag (which they
need to be anyway) the chances of reusing a vtag within a window
are very slim.  The chances get better when there are more
associations formed and dropped within a time window, just as with
your approach.  However, a cryptographical approach does not consume
memory per vtag and is therefore not vulnerable to these expoits.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 May 2009 17:42:31 -0300

Hello, Joe,

> 	from interfering with new connections is to keep state

Yes. But... what does this have to do with port randomization?

> 	than sequential use of the ID space

Why?

> 	done by referring to existing separate definitions

I didn't follow the recent discussion of TIME-WAIT state in SCTP, etc.
Could you clarify this one?

Thanks!

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2009 13:46:40 -0700

Brian F. G. Bidulock wrote:
> the connection there is a DoS attack waiting to be exploited. 

That should only happen for established (opened) connections that then
close (non-established wouldn't generate a time-wait). An endpoint that
wants to exhaust your resources can do worse with an open connection
than to run through connections and close them just to pile on the
time-waits, so it seems like this should be moot.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2009 13:49:28 -0700

> Yes. But... what does this have to do with port randomization?

It underscores the need to keep state in the endpoints, rather than just
trust that randomization will provide safety.

>> 	than sequential use of the ID space

If IDs are used in sequence, and endpoint can keep track of "do not use"
ones using two IDs (representing the range to be avoided). If IDs are
used randomly, then the endpoint needs a copy of each value to avoid.

> Could you clarify this one?

See RFC4960, sec 5.3.1., which refers off to RFC4086 to define
randomness, rather than defining it within the SCTP spec.

Joe

---

From: Randy Stewart <[email-masked]>
Date: Thu, 28 May 2009 16:52:09 -0400

> other approaches.  Just putting a vtag into timed-wait risks a

If someone wants to turn timed wait off in the BSD implementation
all it takes is a sysctl to set the wait interval to 0 and
then its just like all the other systems that Don't do time-wait.
You just shift the problem ;-)

R

-----
Randall Stewart
[email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 May 2009 18:38:34 -0300

> To me you sync them and call it a day.  I.e., I see no reason for

The only reason is that we did describe both riffs for Alg #1 vs. Alg #2
(i.e., incremental retry v.s random retry).

But I'm fine either way. Thoughts?

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 May 2009 18:54:58 -0300

> trust that randomization will provide safety.

Are you talking about the vtag randomization thing you were discussiing
with Anantha?

> used randomly, then the endpoint needs a copy of each value to avoid.

Again, I guess you msut be referring to some vtag-thing here, right?

> randomness, rather than defining it within the SCTP spec.

Ok.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2009 15:01:57 -0700

> Are you talking about the vtag randomization thing you were discussiing

Yes. I think you already have this in your draft, though. It differs
from what SCTP describes, but as you saw there's already a suggestion to
address that separately.

> Again, I guess you msut be referring to some vtag-thing here, right?

Well, yes and no. This also refers to your solution; if you select
source ports in sequence, it may be simpler/faster/less state to avoid
reuse during the required period than to do randomization. The point is
that randomization may increase protection against blind attacks, but it
comes at a cost of additional state at the endpoints. I don't know if
you say that explicitly, but it seems worth noting.

Joe

---

From: Mark Allman <[email-masked]>
Date: Thu, 28 May 2009 21:08:33 -0400

allman