One document matched: draft-ananth-tcpm-persist-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc category="info" docName="draft-ananth-tcpm-persist-01.txt" ipr="trust200902">
<front>
<title abbrev="TCP persist anomaly">Clarification of sender behaviour in
persist condition.</title>
<author fullname="Murali Bashyam" initials="M." surname="Bashyam">
<organization>Ocarina Networks, Inc</organization>
<address>
<postal>
<street>42 Airport parkway</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country>
</postal>
<phone>+1 (408) 512-2966</phone>
<email>mbashyam@ocarinanetworks.com</email>
</address>
</author>
<author fullname="Mahesh Jethanandani" initials="M."
surname="Jethanandani">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 (408) 527-8230</phone>
<email>mahesh@cisco.com</email>
</address>
</author>
<author fullname="Anantha Ramaiah" initials="A." surname="Ramaiah">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 (408) 525-6486</phone>
<email>ananth@cisco.com</email>
</address>
</author>
<date day="10" month="July" year="2009" />
<area>Transport</area>
<workgroup>TCP Maintenance and Minor Extensions Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document attempts to clarify the notion of the Zero Window
Probes (ZWP) described in RFC 1122 <xref target="RFC1122"></xref>. In
particular, it clarifies the actions that can be taken on connections
which are experiencing the ZWP condition. The motivation for this
document stems from the belief that TCP implementations strictly
adhering to the current RFC language have the potential to become
vulnerable to Denial of Service (DoS) scenarios.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>According to RFC 1122 <xref target="RFC1122"></xref> Section
4.2.2.17: 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. It is important to remember that ACK
(acknowledgement) 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.</t>
</section>
<section title="Discussion on RFC 1122 Requirement">
<t>It needs to be emphasised that TCP MUST NOT take any action of its
own when a particular connection is in persist state for a long time. As
per RFC 1122 as long as the ACK's are being received for window probes,
it can continue to stay in persist mode. This is important because
typically applications would want the TCP connection to stay open unless
it explicitly closes the connection. For example take the case of user
running a print job and the printer ran out of paper waiting for the
user intervention. It would be premature for TCP to take action on its
own. Hence TCP cannot act as a resource manager and it is the system or
application's responsibility to take appropriate action.</t>
<t>At the same time, many existing TCP implementations that adhere
strictly to the above verbiage of RFC 1122, may fall victim to DOS
attacks, if appropriate measures are not followed. For example, if we
take the case of a busy server where multiple clients can advertise a
zero forever (by reliably acknowledging the ZWP's), it could eventually
lead to the resource exhaustion in the system. In such cases the system
would need to take appropriate action on the TCP connection to reclaim
the resources. The document is not intended to provide any advice on any
particular resource management scheme that can be implemented to
circumvent DOS issues arising due to the connections stuck in the
persist state. The problem is applicable to TCP and TCP derived
transport protocols like SCTP.</t>
</section>
<section title="Description of Attack">
<t>If TCP implementations strictly follow RFC 1122 and there is no
instruction on what to do in persist condition, connections will
encounter an indefinite wait. To illustrate this, consider the case
where the client application opens a TCP connection with a HTTP <xref
target="RFC2616"></xref> 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.</t>
<t>Applications on the sender can transfer all the data to the TCP
socket and subsequently close the socket leaving the connection in
orphaned state. If the application on the receiver refuses to read the
data, the orphaned connection will be left holding the data indefinitely
in its send queue.</t>
<t>If the above scenario persists for an extended period of time, it
will lead to TCP buffers and connection blocks starvation causing
legitimate existing connections and new connection attempts to fail.</t>
<t>CERT is putting a advisory in this regard<xref
target="VU723308"></xref> and is making vendors aware of this DoS
scenario.</t>
</section>
<section title="Clarification Regarding RFC 1122 Requirements">
<t>A consequence of adhering to the above requirement mandated by RFC
1122 is that multiple TCP receivers advertising a zero window to a
server could exhaust the connection and buffer resources of the sender.
In such cases, and specially when the receiver is reliably acknowledging
zero window probe, to achieve robustness, the system should be able to
take appropriate action on those TCP connections and reclaim resources.
A possible action could be to terminate the connection and such an
action is in the spirit of RFC 1122.</t>
<t>In order to accomplish this action, TCP MAY provide a feedback
regarding the persist condition to the application if requested to do so
or the application or the resource manager can query the health of the
TCP connection which would allow it to take the desired action. All such
actions are in complete compliance of RFC 793 and RFC 1122.</t>
</section>
<section title="Conclusion">
<t>The document addresses the fact that terminating TCP connections
stuck in the persist condition does not violate RFC 1122 or RFC 793. It
also suggests that TCP MUST not abort any connection until either
explicitly requested by the application to do so. The implementation
guidelines of the request and the action are documented in Section 7,
and the details of mitigating the DoS attack are left to the
implementer.</t>
</section>
<section title="Acknowledgments">
<t>This document was inspired by the recent discussions that took place
regarding the TCP persist condition issue in the TCPM WG mailing list
<xref target="TCPM"></xref>. The outcome of those discussions was to
come up with a draft that would clarify the intentions of the ZWP
referred by RFC 1122. We would like to thank Mark Allman and David
Borman for clarifying the objective behind this draft.</t>
</section>
<section title="Programming Considerations">
<t>To enable a server to clear connections in persist condition and
reclaim resources, a socket interface needs to be defined. Note, this
condition is mutually exclusive from a persist condition where we are
not getting zero windows acknowledgement for the probes.</t>
<t>PERSIST_TIMEOUT</t>
<t>Format: setsockopt(fd, SOL_TCP, PERSIST_TIMEOUT,
persist_timeout_value)</t>
<t>The interface allows applications to inform TCP that when the local
connection stays in persist condition it can be cleared after a set
time. Note that the default value of this option is indefinite.</t>
<t>TCP sender will save the current time in the connection block when it
receives a zero window ACK. This time is referred to as the persist
entry time. Thereafter every time the probe timer expires and before it
sends another probe or an ACK carrying zero window is received a check
will be done to see how long the connection has been in persist
condition by comparing the current time to the persist entry time. If
the timeout has been exceeded, the connection will be aborted.</t>
<t>Any time a ACK is received that advertises a non-zero window, the
persist entry time is cleared to take the connection out of persist
condition.</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.RFC.1122" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2616" ?>
<reference anchor="TCPM">
<front>
<title>IETF TCPM Working Group and mailing list
http://www.ietf.org/html.charters/tcpm-charter.html</title>
<author fullname="TCPM" initials="" surname="TCPM" />
</front>
<format target="http://www.ietf.org/html.charters/tcpm-charter.html"
type="HTML" />
</reference>
<reference anchor="VU723308">
<front>
<title>Vulnerability is Web Servers
http://www.kb.cert.org/vuls/id/723308</title>
<author fullname="Art Manion" surname="Manion">
<organization>CERT</organization>
<address>
<uri>http://www.cert.org</uri>
</address>
</author>
<date day="10" month="July" year="2009" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 12:45:51 |