Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]

Joe Touch <touch@ISI.EDU> Wed, 28 November 2007 13:22 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMrZ-0007HM-AV; Wed, 28 Nov 2007 08:22:01 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IxMrY-0007H7-0q for tcpm-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 08:22:00 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMrW-0007Gs-SE for tcpm@ietf.org; Wed, 28 Nov 2007 08:21:58 -0500
Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxMrW-0004Xc-CH for tcpm@ietf.org; Wed, 28 Nov 2007 08:21:58 -0500
Received: from [75.197.89.138] (138.sub-75-197-89.myvzw.com [75.197.89.138]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lASDLKoZ011228; Wed, 28 Nov 2007 05:21:22 -0800 (PST)
Message-ID: <474D6B3C.7050402@isi.edu>
Date: Wed, 28 Nov 2007 05:21:00 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Mahesh Jethanandani <mahesh@cisco.com>
Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]
References: <20071126193803.585E12FC5BE@lawyers.icir.org> <61806008-0CBC-417D-B5EB-46A7EE18446F@windriver.com> <474CA683.2030600@cisco.com> <3EE5954A-5E50-4B1E-82BC-7A5FD55AEF1F@windriver.com> <474D1004.9030100@cisco.com>
In-Reply-To: <474D1004.9030100@cisco.com>
X-Enigmail-Version: 0.95.5
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: tcpm@ietf.org, David Borman <david.borman@windriver.com>, Mark Allman <mallman@icir.org>
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1544669682=="
Errors-To: tcpm-bounces@ietf.org


Mahesh Jethanandani wrote:
...
> What I should have said is that the fact that the above statement in RFC
> 1122 that "TCP MUST allow the connection to stay open" in response to
> probes has caused a lot of confusion. We have opinions all the way from
> it is ok for TCP to terminate the connection "in times of trouble" to it
> is not for TCP to terminate any connection. We have had mails that have
> said that it is ok for application/OS/socket layer to terminate the
> connection but it is not ok for TCP to terminate the connection. Does it
> mean that if socket interface makes a call to tcp_abort() to abort a
> connection, that it is not TCP that is aborting the connection, but it
> is socket interface that is, and therefore it is fine?
> 
> Would it not help to clarify the statement in the rfc?

It would be useful to clarify that in the Unix man pages for
tcp_abort(), if there is in fact any real confusion in the Unix
community on this issue.

As Dave noted, RFC1122 is clear on the context of not aborting
connections within TCP due to zero windows with active probes.

The rest of this discussion has been addressing a moving target based on
falsified claims of a vulnerability, which, as others have noted, is not
more advantageous than many others in TCP, e.g., slowly draining
buffers. It makes no sense to single out "victims" of this "attack" by
"cleaning up" TCP state to save resources vs. any other mechanism to
limit resource overuse (e.g., prohibiting new connections, deleting
those with the largest socket buffers, etc.).

The key issue is that a zero receive window with active probes is a
valid, active TCP connection - as valid as any other in its use of
resources. If we need a document to describe what to do in the event of
resource overuse (and I don't think we do), the current document - and
motivating threat - are notable only in how NOT to single out
connections for resource recovery.

Joe





_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm