Subject: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00

From: Fernando Gont <[email-masked]>
Date: Fri, 07 Jan 2011 20:24:07 -0300

Folks,

We have published the I-D "Defending Against Sequence Number Attacks"
(draft-gont-tcpm-rfc1948bis-00), which is a revision of Steven's RFC1948.

The Abstract of the I-D is:
---- cut here ----
This document specifies an algorithm for the generation of TCP
Initial Sequence Numbers (ISNs), such that the chances of an off-path
attacker of guessing the sequence numbers in use by a target
connection are reduced.  This document is a revision of RFC 1948, and
takes the ISN generation algorithm originally proposed in that
document to Standards Track.
---- cut here ----

Any comments will be more than welcome.

Thanks,
Fernando

-------- Original Message --------
Subject: New Version Notification for draft-gont-tcpm-rfc1948bis-00
Date: Mon,  3 Jan 2011 12:35:29 -0800 (PST)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
CC: [email-masked]

A new version of I-D, draft-gont-tcpm-rfc1948bis-00.txt has been
successfully submitted by Fernando Gont and posted to the IETF repository.

Filename:	 draft-gont-tcpm-rfc1948bis
Revision:	 00
Title:		 Defending Against Sequence Number Attacks
Creation_date:	 2011-01-03
WG ID:		 Independent Submission
Number_of_pages: 12

Abstract:
This document specifies an algorithm for the generation of TCP
Initial Sequence Numbers (ISNs), such that the chances of an off-path
attacker of guessing the sequence numbers in use by a target
connection are reduced.  This document is a revision of RFC 1948, and
takes the ISN generation algorithm originally proposed in that
document to Standards Track.

The IETF Secretariat.

---

From: Hal Wigoda <[email-masked]>
Date: Fri, 7 Jan 2011 22:50:56 -0600

Where can I get copy  of this as I 
am doing a paper on Covert Channels over TCP/IP using the sequence number field....

On Jan 7, 2011, at 5:24 PM, Fernando Gont wrote:

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Sat, 8 Jan 2011 14:36:02 -0000

Fernando, group,

On the basis of "eating our own dogfood", updating rfc1948 to make it to standards track and updating it with current findings is a supportable idea. 

However, the complete replacement of the references to MD5 with SHA256 may be discussable still - a partial list of acceptable hash algorithms may be advisable (ie. MD5 might be more readily available to an implementer, than SHA-256; thus he may want to skip proper ISN generation altogether, if SHA-256 has to be implemented first. Or only a poor substitute (such as PRN generator as MT64 (or even the compiler-default random()) may be used as hash....

Only found a typo (section B.1 s/Informaitonal/Informational/).

Regards,
   Richard

> -----Original Message-----
> From: Fernando Gont [mailto:[email-masked]]
> Sent: Samstag, 08. Jänner 2011 00:24
> To: [email-masked]
> Subject: [tcpm] Fwd: New Version Notification fordraft-gont-tcpm-
> rfc1948bis-00
> 
> Folks,
>

---

From: Fernando Gont <[email-masked]>
Date: Sat, 8 Jan 2011 15:22:07 -0300

Hi, Richard,

Thanks so much for your timely feedback! -- You'll find my response inline...

On Sat, Jan 8, 2011 at 11:36 AM, Scheffenegger, Richard <[email-masked]> wrote:
> However, the complete replacement of the references to MD5 with SHA256 may be discussable
> still - a partial list of acceptable hash algorithms may be advisable (ie. MD5 might be more readily
> available to an implementer, than SHA-256; thus he may want to skip proper ISN generation altogether,
> if SHA-256 has to be implemented first. Or only a poor substitute (such as PRN generator as MT64
> (or even the compiler-default random()) may be used as hash....

The recommendation of SHA-256 instead of MD5 was, for the most part,
in response of my recent experience with the IESG: While pursuing
draft-ietf-tsvwg-port-randomization, they suggested that MD5 be
replaced with SHA-256 (in one of the port randomization algorithms,
which uses the expression specified in RFC1948).

IIRC, both of the co-authors (Steven and me) and Alfred (CC'ed, who
reviewed this document before publication) agreed that MD5 would be
fine for *this* purpose... but went ahead with s/MD5(HMAC-SHA-256/
because of what I mentioned about the IESG.
I also recall that there's an I-D aiming at deprecate MD5 altogether?
-- not sure how it would affect us.

FWIW, I do agree with you that MD5 may be more readily available. --
actually, many systems already implement RFC1948, with MD5 rather than
HMAC-SHA-256.

All the above said, I'd be interested in hearing input from the WG
about this particular issue.

> Only found a typo (section B.1 s/Informaitonal/Informational/).

Will fix this.

Thanks!

Best regards,
Fernando

---

From: <[email-masked]>
Date: Sat, 8 Jan 2011 18:53:54 +0000

Much discussion of the ID to deprecate MD5 on the main ietf mailing list in last call. Consensus settled around 'MD5 is still useful if there are no security implications, but do a careful security evaluation first before using MD5' and this is reflected in the updated
http://tools.ietf.org/html/draft-turner-md5-seccon-update-08
   Where the MD5 checksum is used inline with the protocol
   solely to protect against errors an MD5 checksum is still an
   acceptable use.  Applications and protocols need to clearly state in
   their security considerations what security services, if any, are
   expected from the MD5 checksum.  In fact, any application and
   protocol that employs MD5 needs to clearly state the expected
   security services from their use of MD5.

My take is that all claimed 'secure' hashes will be found to have collisions eventually, which is the nature of most checksums (where probability of colliisions increases with filesize). And there's probably an underlying mathematical proof that there will always be collisions... I am surprised security people aren't spending their time recommending that we don't use CRC32c, or one's complement checksums, due to the high risk of collisions and easy falsifiability... OMG, TCP still uses one's complement checksums! On every packet! It's insecure! The HORROR! Deprecate TCP NOW!

And you should go ahead and use MD5, because hey, it's still better than the one's complement checksum endemic to TCP, and if TCP is still using one's complement for packets, securing any aspect of TCP is just ridiculous. Using either MD5 or SHA for seq no generation is a palliative measure, as your draft says, but using SHA is also a placebo; you think you're getting security because it's SHA, but you're not. Stick with MD5, where you know you're not really getting security, and you therefore don't claim that TCP is secure because SHA is involved.

The IESG response of  'must not use MD5' is the kind of kneejerk similar to that longstanding  'all protocols must implement congestion control'. Not suitable in all cases; more rational thought required.

Lloyd Wood
http://sat-net.com/L.Wood/
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Fernando Gont [[email-masked]]
Sent: 08 January 2011 18:22
To: Scheffenegger, Richard
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tcpm] Fwd: New Version Notification       fordraft-gont-tcpm-rfc1948bis-00

Hi, Richard,

Will fix this.

Thanks!

Best regards,
Fernando

---

From: Fernando Gont <[email-masked]>
Date: Sat, 08 Jan 2011 16:34:48 -0300

Hi, Lloyd,

On 08/01/2011 03:53 p.m., [email-masked] wrote:
> Much discussion of the ID to deprecate MD5 on the main ietf mailing
> list in last call. Consensus settled around 'MD5 is still useful if
> there are no security implications, but do a careful security
> evaluation first before using MD5' and this is reflected in the
> updated http://tools.ietf.org/html/draft-turner-md5-seccon-update-08 
> Where the MD5 checksum is used inline with the protocol solely to
> protect against errors an MD5 checksum is still an acceptable use.
> Applications and protocols need to clearly state in their security
> considerations what security services, if any, are expected from the
> MD5 checksum.  In fact, any application and protocol that employs MD5
> needs to clearly state the expected security services from their use
> of MD5.

Well, but in this case we'd be "assuming" that MD5 is secure (*), and
then the IESG would likely ask us to replace MD5 with SHA-256 during
IESG review -- they did this for port-randomization, which borrows the
scheme from RFC 1948.

(*) For this particular use, we believe that MD5 is still good enough.
-- after all RFC1948 aims at mitigating *blind* attacks (connection
spoofing, etc.). If you're really worried about MD5 collisions for the
ISNs, then you should be using IPsec or the like.

> And you should go ahead and use MD5, because hey, it's still better
> than the one's complement checksum endemic to TCP, and if TCP is
> still using one's complement for packets, securing any aspect of TCP
> is just ridiculous. Using either MD5 or SHA for seq no generation is
> a palliative measure, as your draft says, but using SHA is also a
> placebo; you think you're getting security because it's SHA, but
> you're not. Stick with MD5, where you know you're not really getting
> security, and you therefore don't claim that TCP is secure because
> SHA is involved.

MD5 or SHA buy you the same thing, because in our threat model an
attacker would not be exploiting the collisions properties of MD5.

> The IESG response of  'must not use MD5' is the kind of kneejerk
> similar to that longstanding  'all protocols must implement
> congestion control'. Not suitable in all cases; more rational thought
> required.

But you still need no DISCUSSes for a document to be published as an RFC...

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

---

From: Fernando Gont <[email-masked]>
Date: Sat, 08 Jan 2011 02:41:48 -0300

Hi, Hal,

http://www.ietf.org/id/draft-gont-tcpm-rfc1948bis-00.txt

Best regards,
Fernando

---

From: Lars Eggert <[email-masked]>
Date: Sun, 9 Jan 2011 10:59:26 +0200

Hi,

> which uses the expression specified in RFC1948).

the suggestion actually came from the sec-dir reviewer, and it wasn't a very strong suggestion:

On 2010-2-27, at 4:05, Charlie Kaufman wrote:
> p16 para 2: suggests use of MD5, which is fine from the point of view of documenting current practice, and in fact is cryptographically just fine in this context. Nevertheless, crypto weenies the world over will pounce on you if it looks like you're suggesting that people use it. It's probably better to just suggest "some cryptographic hash function", or if you have to suggest something specific, perhaps SHA-256. The appendix at the end should specify the hash algorithm used by existing implementations.

Cullen, who was AD at the time, also commented on this, but basically just wanted to make sure that a security person had reviewed this in depth:

On 2010-3-4, at 7:43, Cullen Jennings wrote:
> I'm fairly skeptical of the advice on choosing the key sizes. I'm not a crypto person but I'd love to see some analysis of this. 
...
> I suspect I would be much more conformable with something that had been looked at lots, like AES counter mode. Again, I'm not even qualified to suggest anything here but I'm looking for evidence the crypto stuff was seriously looked at. 

So we probably could have argued to retain MD5 for port-randomization (maybe as part of a list of crypto hash functions, as Charlie suggested). That should mean that it should be OK to retain it here as well, esp. if AES-256 creates implementation difficulties for some stacks.

Lars

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Jan 2011 11:09:12 -0800

My key questions are below.

IMO, this might be ready for experimental, but shouldn't go 
standards-track unless it uses an algorithm for which we have 
substantial experience. This doc introduces a new alg, which isn't 
appropriate for a simple "revise to standards track" process, IMO.

Joe

1) is this the most important change we want to make to TCP

	as a WG, we ought to be discussing this for
	every standards-track change to TCP; we don't seem
	to be doing this as a plan

2) the discussion of how this doc changes 1948 needs to be included in 
the core of the doc (Sec 2, IMO), and needs to be updated

	- this is a new algorithm, which, IMO, is experimental at best
	the alg proposed in Sec 2 is predictable for a given socket
	pair; that seems inconsistent with the security concerns that
	drive this doc

	- security concerns with MD5 need to be cited; the current
	note cites the definition of MD5 only; it's not clear
	they apply for unkeyed use as just a hash function

	- the impact of guessing a sequence number should be discussed
	better; as per 4953, increasing window sizes and link speeds
	means that knowing ISN value isn't as important as it once was

2) the impact of this doc on TIME_WAIT isn't sufficiently addressed

	most machines simply don't keep TW around as long as they
	are required; they also sometimes use a single pseudo-random
	generator across all connections; this needs to be considered
	in more detail

3) the doc should discuss how it can be implemented on a machine that 
doesn't know absolute time
	even TCP's timestamps don't need to be absolute, but if a
	machine always boots the same way with the same info, it
	will reuse sequence numbers unless it has a persistent clock,
	coordinates time with another party, or has persistent state;
	none of these are necessarily true, e.g., for small devices

4) where true authentication is noted as an alternative, TCP-AO should 
be included, IMO

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Jan 2011 11:15:02 -0800

As a broader question, do we really need to say "do this" (where "this" 
is a new algorithm)?

Or would it be sufficient to say (as, e.g., a BCP), "doing something is 
a good thing".

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Jan 2011 16:38:22 -0300

Hi, Joe,

On 10/01/2011 04:09 p.m., Joe Touch wrote:
> substantial experience. 

Yes, I'll be backing out SHA-256 and will go back to recommending MD5.
-- As already noted on this list, this change was political rather than
technical.

So I assume that this would address your concern and you'd be game for
std track, right?

>     to be doing this as a plan

huh? Why should this be "the most important change to TCP" for us to
work on it?

> the core of the doc (Sec 2, IMO), and needs to be updated

No problem with this -- what do others think?

>     pair; that seems inconsistent with the security concerns that

Joe, this document is about mitigating blind attacks. If you know the
socket pair, you can predict the ISN, unless you were able to see the
ISN of a previous connection for that socket pair -- which is a
completely different threat-model, that this document does not (and
doesn't aim to) address.

>     they apply for unkeyed use as just a hash function

The I-D cited by Lloyd will be referenced in the next revision.

>     means that knowing ISN value isn't as important as it once was

Guessing the ISN is still as important as it was when it comes to
connection spoofing (note that most of the discussion is about
connection spoofing and trust relationship exploitation).

We could possibly add an informative reference to RFC 4953 for other
sequence number issues.

>     generator across all connections; this needs to be considered

So now you care about running code? -- It's surprising that you're
raising this, instead of declaring them as bugs and be done with it.

Anyway, this document is not about the TIME-WAIT state. And proper
references are included where appropriate (e.g., the reference to the
CPNI TCP security document)

>     none of these are necessarily true, e.g., for small devices

C'mon, Joe: initialize that timer to a random value, and be done with it.

> 4) where true authentication is noted as an alternative, TCP-AO should

No problem with this. Will do.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Jan 2011 11:49:35 -0800

> So I assume that this would address your concern and you'd be game for

The specification of the PRF needs to be more detailed. I.e., state how 
the hash is padded, byte order, and what portion of the output you're 
using (since MD5 hashes are too long).

> huh? Why should this be "the most important change to TCP" for us to

This is a general question; we don't want to be spending cycles around 
the edges if we have bigger fish to fry.

> completely different threat-model, that this document does not (and

If knowing the socket pair means you can predict the ISN, then this doc 
shouldn't be discussing the need for a random component or the time value.

I.e., your response above is inconsistent with a LOT of the discussion 
in this doc.

> raising this, instead of declaring them as bugs and be done with it.

I'm concerned about the performance impact of declaring this a SHOULD.

> CPNI TCP security document)

If the result of this SHOULD impacts TW performance, then yes, it is 
about TW state.

> C'mon, Joe: initialize that timer to a random value, and be done with it.

Stand-alone boxes don't necessarily understand 'random' - if they reboot 
and execute the same code in the same order, their 'random' is 
deterministic. You need to address that. This relates to the other 
concerns about some TCP mods that require state in home routers - it's a 
valid concern. You're declaring a SHOULD; you need to explain what you 
assume is available.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Jan 2011 17:11:12 -0300

Hi, Joe,

> using (since MD5 hashes are too long).

How come that you don't deem this one as an implementation detail that
should not concern us?

> shouldn't be discussing the need for a random component or the time value.

Sorry, let me rephrase: With the proposed algorithm, you can only
predict an ISN if you know the socket pair *and* you know the ISN of a
previous connection between the source host and the destination
endpoint. -- But this is *intentional*.

-- We do want the ISNs to be monotonically increasing across connections
-- hence the predictability to an *on* *path* attacker.

> I'm concerned about the performance impact of declaring this a SHOULD.

It's a SHOULD not a MUST. So, if anything "what are the reasons for not
implementing this? -- Performance"?

> If the result of this SHOULD impacts TW performance, then yes, it is

Can you clearly state what your concern is? -- I just don't follow.

And... What does RFC 1948 have to do with TIME-WAIT performance?

> valid concern. You're declaring a SHOULD; you need to explain what you

Ok, my proposed text would be:
"This specification assumes the host supports a random() function that
provides random numbers as in, e.g. ISO C random() function."

If you have anything better, please post it.

That aside: What would be your concern about the node re-using the same
ISNs? (even assuming connections are established at the same time since
the node was bootstrapped... because you're assuming this, right?) --
Would an off-path attacker be able to predict them? And, if not, why are
you still concerned about it?

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Jan 2011 13:11:19 -0800

> How come that you don't deem this one as an implementation detail that

The question is really "what is this document requiring".

Is your intent to say "use MD5", and figure the rest our yourself?

If so, why bother using the "+" operator, or putting the time value 
outside the hash?

Either such details matter or they don't; if they don't, you need to 
explain why they don't. You don't *need* to spec it out to the bit level 
if that doesn't matter, but you do need to explain why you spec out some 
parts and not others.

> -- We do want the ISNs to be monotonically increasing across connections

The alg you gave is monotonically increasing across connections within a 
socket pair. Presumably that's what you mean, right?

> implementing this? -- Performance"?

1) per-connection computational overhead

2) the need to retain per-socketpair state for TW (vs., e.g., some 
*known* implementations that do otherwise to reduce the state needed to 
avoid TW reuse).

> And... What does RFC 1948 have to do with TIME-WAIT performance?

If you generate ISNs that are monotonic within a socket pair, but are 
otherwise arbitrary across different socket pairs, you NEED to keep the 
TWs per socket pair. If you want to keep less TW state, you can use a 
different mechanism.

> If you have anything better, please post it.

The point is that some boxes that use that function will generate the 
same value upon reboot. The fact that neither you nor I have a solution 
to this is the point - your requirement is making an assumption which is 
not true.

> you still concerned about it?

You need to address what your algorithm requires and what it does not. 
If you can demonstrate that there's no ill effect, then you can explain 
that, e.g., you DON'T really need the random call.

Joe

---

From: William Allen Simpson <[email-masked]>
Date: Mon, 10 Jan 2011 16:17:45 -0500

On 1/10/11 2:49 PM, Joe Touch wrote:
> The specification of the PRF needs to be more detailed. I.e., state how the hash is padded, byte order, and what portion of the output you're using (since MD5 hashes are too long).
>
Strongly disagree!

The standard should only be that a PRF is used.  There are no interoperability
requirements.  Moreover, we'd endlessly spin our wheels needlessly arguing about
these insignificant details.

In code I was writing not that long ago, I used part of the hash for the ISN,
and part for the timestamp, and part for the cookie.  There were plenty of
bits to go around.

> This is a general question; we don't want to be spending cycles around the edges if we have bigger fish to fry.
>
Oh humbug.  These are all drafts concerning things we've known need to be
updated for TCP for 15+ years.  Heck, a draft by a WG co-chair is 4 years
old, and still not finished (and I'd place that one at the top).

Kudos to Gont for being willing to do the work -- and dodge the bullets.

>> No problem with this -- what do others think?
Change discussions should be nearest the end of the document, not the core.

> I'm concerned about the performance impact of declaring this a SHOULD.
I'm not.  We've been using high performance MD5 for such things since the
days of 186s in a cell phone.  I think it should be a MUST!

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Jan 2011 13:28:06 -0800

> days of 186s in a cell phone.  I think it should be a MUST!

The performance impact isn't just computational, FWIW. It's also state.

We had been discussing before on this list that some implementations 
don't keep TWs around; they just keep the first/last in a list, assuming 
that TWs are monotonic. If that's now monotonic within only a single 
socket pair, it increases the state needed to avoid socket reuse during 
TW. That's the non-computational performance impact...

Also, when we talk about performance, we consider not just how fast a 
cellphone can compute the sum, but how many connections/sec a CPU can 
support; putting MD5 in the path will cut that down quite a bit.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Jan 2011 20:24:04 -0300

Joe,

> Is your intent to say "use MD5", and figure the rest our yourself?

MD5 would be a good choice. But if you want to use something else,
that's still fine.

> If so, why bother using the "+" operator, or putting the time value

Joe, please read the I-D. The time value is put outside the hash such
that the ISNs increase over time.

> socket pair. Presumably that's what you mean, right?

Yes.

> *known* implementations that do otherwise to reduce the state needed to

I don't know what you're talking about. What's the increased state that
you'd need to retain if you implement this algorithm.

The algorithm is *stateless*! (apart from the global counter).

> TWs per socket pair. If you want to keep less TW state, you can use a

Isn't keeping the socket in the TIME-WAIT state a requirement?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Jan 2011 20:29:10 -0300

Joe,

On 10/01/2011 06:28 p.m., Joe Touch wrote:
> that TWs are monotonic. 

Cane you clearly state:

* How the aforementioned mechanism operates
* What specific implementations you're referring to
* What are the assumptions they make
* Whether such assumptions are based on current requirements (IETF-wise)
* Whether such assumptions are based on widely-deployed implementations
(and if so, which ones)

?

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Jan 2011 15:39:59 -0800

> MD5 would be a good choice. But if you want to use something else,

It'd be useful to say that.

> that the ISNs increase over time.

I was being a bit sarcastic - sorry. My point was that there's a certain 
amount of specificity, and a certain amount of handwaving. It'd be 
useful to explain why the distinction more clearly (i.e., which parts 
can be varied, which don't matter).

> you'd need to retain if you implement this algorithm.

If you implement ISN as a counter, you don't really need to keep TW. If 
you implement this, you do need to keep TW for each socket pair.

> The algorithm is *stateless*! (apart from the global counter).

It's the implication on how TW is kept that matters.

> Isn't keeping the socket in the TIME-WAIT state a requirement?

Making sure the values are not repeated for 2MSL is the requirement; how 
they are kept is up to the implementation.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Jan 2011 20:51:05 -0300

On 10/01/2011 08:39 p.m., Joe Touch wrote:

> If you implement ISN as a counter, you don't really need to keep TW. 

Sorry Joe: Is it me, or there is an explicit requirement in RFC 793 to
keep the TCP in the TIME-WAIT state?

> If

I think you're arguing about violating RFC 793.

That aside, please respond to my questions (now on a separate thread) on
the implementations you're referring to.

> they are kept is up to the implementation.

I see... So actual implementation of the TIME-WAIT state is up to the
implementation?

Which other states of TCP do you think we could get rid off?

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Jan 2011 16:20:21 -0800

> keep the TCP in the TIME-WAIT state?

An implementation must act as if there is such a state. There is no 
requirement to how to achieve that behavior (or any other in 793).

> I think you're arguing about violating RFC 793.

No; I'm arguing there are several ways to support it. Some prohibit some 
new TCP connections that could have otherwise happened, at the benefit 
of keeping less state. That's an endpoints perogative.

...
> I see... So actual implementation of the TIME-WAIT state is up to the

That is a tautology. Yes, to be explicit, it is.

> Which other states of TCP do you think we could get rid off?

Well, let's see - TCP cookies get rid of SYN-RECEIVED (there is no such 
internal state kept), but they end up acting as if it's kept. So are you 
now arguing that any implementation that uses cookies isn't implementing 
793 at all?

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Jan 2011 16:25:50 -0800

> * How the aforementioned mechanism operates

As a simple example consider outgoing source port numbers for 
connections you initiate, and don't reuse them for 2MSL. Generate the 
ISNs using a single global counter. Sure, it's not going to give you 
lots of connections, but you no longer need to keep TW for any outgoing 
connections.

> * What specific implementations you're referring to

They have been discussed on this list in the past when discussing other 
ways in which TW behaves. I don't recall which OS they are implemented 
in (likely things like home routers).

> * What are the assumptions they make

See above; most assume the overall connection rate is the limit, not 
per-socket pair.

> * Whether such assumptions are based on widely-deployed implementations

I don't know how widely; the point is that the assumptions are 
consistent with current IETF requirements. I believe they were deployed, 
but have only the reports of others when discussing TW to go on for that.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Jan 2011 23:14:52 -0300

> lots of connections, but you no longer need to keep TW for any outgoing

This is so broken that it probably does not even deserve discussion. So
a server that needs to go into TIME-WAIT relies on a *client* for
that???? How does your hypothetical server TCP implementation know how
the client is going to behave?

> in (likely things like home routers).

This is hand-waving.

And, FWIW, many (most?) home routers these days are based on Linux.

> See above; most assume the overall connection rate is the limit, not

This is flawed and broken. -- And IMO, unless you prove me wrong, not real.

> consistent with current IETF requirements. 

Consistent with what?

A server implements TIME-WAIT state by relying on a *client* not issuing
connections at a high rate?

And this also relies on global (and predictable) ISNs? (which are widely
known to be insane)

I'm done with this discussion, Joe. I have no more time to waste (nor do
I want to waste the time of other participants).

P.S.: If you get wg consensus on your view and proposed changes, I'll be
happy to trash our I-D as indicated.

Thanks,