Subject: [tcpm] Please read

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 31 Jul 2008 10:49:56 -0700

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
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 Jul 2008 11:41:46 -0700

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
| [email-masked]
| https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 31 Jul 2008 15:13:06 -0400

Is an RFC really needed?

I've always assumed that the application layer MAY
do pretty much whatever it wants. Further application
layer servers SHOULD protect their own resources against
abusive clients. Those protection mechanisms MAY include
terminating connections.

All of that is true independent of any specific method
of abusing server resources.