Re: [tcpm] Please read

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

FWIW, I agree with this.

In addition, "unless otherwise instructed to do so" should be extended
to address the resource limit issue: "unless otherwise instructed to do
so, e.g., in the case where the OS is running out of resources, or a
user timeout occurs"

Regarding that last point, I understood it to be related - i.e., that
current implementations won't allow a user timeout to kill a connection
in persist. Is that the case? If so, that's worth noting under
motivation for the document as well.

Joe

Mahesh Jethanandani wrote:
| During the TCPM meeting in Dublin, Wes wanted to encourage readers on
| this mailing list to read the short (2 pages if you remove the boiler
| plate part) draft on "Clarification of Sender Behavior Under Persist
| Condition" draft.
|
| To enable a quick read, I have cut and pasted the relevant sections
| here. As noted in the meeting, this draft  tries to clarify the sender
| behavior without getting into the details of the DoS scenario and the
| possible solutions. Just to reiterate, it is this draft and not the
| original persist draft that we are trying to table for adoption as a WG
| item.
|
| 1.  Introduction
|
|   RFC 1122 [RFC1122] Section 4.2.2.17, page 92 says that: A TCP MAY
|   keep it's offered receive window closed indefinitely.  As long as the
|   receiving TCP continues to send acknowledgments in response to the
|   probe segments, the sending TCP MUST allow the connection to stay
|   open.  The RFC goes on to say that it is important to remember that
|   ACK (acknowledgment) segments that contain no data are not reliably
|   transmitted by TCP.  Therefore zero window probing SHOULD be
|   supported to prevent a connection from hanging forever if ACK
|   segments that re-opens the window is lost.  The condition where the
|   sender goes into the ZWP mode is typically known as the persist
|   condition.  The problem is applicable to TCP and TCP derived
|   transport protocols like SCTP.
|
|   A consequence of adhering to the above requirement mandated by RFC
|   1122 is that multiple TCP receivers (clients) advertising a zero
|   window to a busy server indefinitely (by reliably acknowledging the
|   ZWP), could exhaust the connection and buffer resources of the sender
|   (server).  In such cases, to achieve robustness, the system should be
|   able to take appropriate action on those TCP connections and reclaim
|   resources.  The purpose of this document is to clarify that such
|   actions are in the spirit of RFC 1122 and they don't violate RFC
|   1122.  The remainder of the document briefly describes the DoS
|   scenario, analyzes the current verbiage surrounding the ZWP in RFC
|   1122 and attempts to disambiguate the notion presented by RFC 1122.
|
| 2.  Discussion
|
|   Having the sender accumulate buffers and connection table entries
|   when the receiver has deliberately and maliciously closed the window
|   ultimately leads to resource exhaustion on the sender.  This
|   particular dependence on the receiver to open its zero window can be
|   easily exploited by a malicious receiver TCP application to launch a
|   DoS attack against the sender.  In this scenario the sender's
|   legitimate connections do not get established and already established
|   well behaved TCP connections are unable to transmit any data.  The
|   sender enters the persist condition and is stuck waiting indefinitely
|   for the receiver to open up its window.
|
|   To illustrate this, consider the case where the client application
|   opens a TCP connection with a HTTP [RFC2616] server, sends a GET
|   request for a large page and stops reading the response.  This would
|   cause the client TCP to advertise a zero window to the server.  For
|   every large HTTP response, the server is left holding on to all the
|   response data in it's send queue.  If the client never clears the
|   persist condition, the server will continue to hold that data
|   indefinitely.  Multiple such TCP connections stuck in the same
|   scenario on the server would cause resource depletion resulting in a
|   DoS situation on the server.
|
|   In such scenarios it should be possible for the application or the
|   system or a resource management entity to instruct TCP to terminate
|   connections stalled in the persist condition.  These actions are
|   necessary to prevent resource exhaustion on the server.
|
|   An extensive discussion took place recently about this issue on the
|   TCPM WG mailing list [TCPM].  The general opinion seemed to be that
|   terminating a TCP connection in persist condition does not violate
|   RFC 1122.  In particular the operating system, a resource manager, or
|   an application can instruct TCP to abort a connection in the persist
|   condition.  TCP itself SHOULD not take any action and continue to
|   keep the connection open as mandated by RFC 1122 unless otherwise
|   instructed to do so.  The exact mechanism by which the instruction to
|   abort the connection is conveyed to TCP is an implementation decision
|   and falls beyond the scope of the current memo.  To determine which
|   TCP connection to abort the entity can use the connection attributes
|   obtained from some interface similar to STATUS call mentioned in RFC
|   793.
|
|
|
|
|
|
|
|
| -- mahesh
| _______________________________________________
| tcpm mailing list
| tcpm@ietf.org
| https://www.ietf.org/mailman/listinfo/tcpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiSB2oACgkQE5f5cImnZru31wCgs59aQgSgQFZGr5yZzmQO8s4d
b2oAni+HjYblCng5DKD1FaoSZQIFYWT2
=MsGH
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm