draft-ietf-tcpm-persist-07.txt   rfc6429.txt 
TCP Maintenance and Minor Extensions M. Bashyam Internet Engineering Task Force (IETF) M. Bashyam
Working Group Ocarina Networks, Inc Request for Comments: 6429 Ocarina Networks, Inc.
Internet-Draft M. Jethanandani Category: Informational M. Jethanandani
Intended status: Informational A. Ramaiah ISSN: 2070-1721 A. Ramaiah
Expires: March 18, 2012 Cisco Cisco
September 15, 2011 December 2011
TCP sender clarification for Persist Condition. TCP Sender Clarification for Persist Condition
draft-ietf-tcpm-persist-07.txt
Abstract Abstract
This document clarifies the Zero Window Probes (ZWP) described in This document clarifies the Zero Window Probes (ZWPs) described in
Requirements for Internet Hosts [RFC1122]. In particular, it RFC 1122 ("Requirements for Internet Hosts -- Communication Layers").
clarifies the actions that can be taken on connections which are In particular, it clarifies the actions that can be taken on
experiencing the ZWP condition. This draft clarifies what has been connections that are experiencing the ZWP condition. Rather than
till now a misinterpretation of the standard as specified in RFC 1122 making a change to the standard, this document clarifies what has
[RFC1122] rather than making a change to the standard. been until now a misinterpretation of the standard as specified in
RFC 1122.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on March 18, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6429.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Discussion on RFC 1122 Requirement . . . . . . . . . . . . . . 4 1.1. Requirements Language ......................................3
3. Description of one Simple Attack . . . . . . . . . . . . . . . 5 2. Discussion of RFC 1122 Requirement ..............................3
4. Clarification Regarding RFC 1122 Requirements . . . . . . . . 6 3. Description of One Simple Attack ................................4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. Clarification Regarding RFC 1122 Requirements ...................5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations .........................................5
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments .................................................5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References ......................................................6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References .......................................6
8.2. Informative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References .....................................6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Section 4.2.2.17 of Requirements for Internet Hosts [RFC1122] says: Section 4.2.2.17 of "Requirements for Internet Hosts -- Communication
Layers" [RFC1122] says:
"A TCP MAY keep its offered receive window closed indefinitely. "A TCP MAY keep its offered receive window closed indefinitely.
As long as the receiving TCP continues to send acknowledgments in As long as the receiving TCP continues to send acknowledgments in
response to the probe segments, the sending TCP MUST allow the response to the probe segments, the sending TCP MUST allow the
connection to stay open. connection to stay open.
DISCUSSION: DISCUSSION:
It is extremely important to remember that ACK (acknowledgment) It is extremely important to remember that ACK (acknowledgment)
segments that contain no data are not reliably transmitted by segments that contain no data are not reliably transmitted by
TCP." TCP".
Therefore zero window probing needs to be supported to prevent a Therefore, zero window probing needs to be supported to prevent a
connection from hanging forever if ACK segments that re-opens the connection from hanging forever if ACK segments that re-open the
window is lost. The condition where the sender goes into the Zero window are lost. The condition where the sender goes into the Zero
Window Probe (ZWP) mode is typically known as the 'persist Window Probe (ZWP) mode is typically known as the 'persist
condition'. condition'.
This guidance is not intended to preclude resource management by the This guidance is not intended to preclude resource management by the
operating system or application, which may request connections to be operating system or application, which may request that connections
aborted regardless of them being in the persist condition, and the be aborted regardless of whether or not they are in the persist
TCP implementation needs to, of course, comply by aborting such condition. The TCP implementation needs to, of course, comply by
connections. TCP implementations that misinterpret Section 4.2.2.17 aborting such connections. If such resource management is not
of Requirements for Internet Hosts [RFC1122] have the potential to performed external to the protocol implementation, TCP
make systems vulnerable to Denial of Service (DoS) [RFC4732] implementations that misinterpret Section 4.2.2.17 of [RFC1122] have
scenarios where attackers tie up resources by keeping connections in the potential to make systems vulnerable to denial-of-service (DoS)
the persist condition, if such resource management is not performed [RFC4732] scenarios where attackers tie up resources by keeping
external to the protocol implementation. connections in the persist condition.
This draft clarifies what has been till now a misinterpretation of Rather than making a change to the standard, this document clarifies
the standard as specified in RFC 1122 [RFC1122], rather than making a what has been until now a misinterpretation of the standard as
change to the standard. specified in RFC 1122 [RFC1122].
Section 2 of this document describes why implementations might not Section 2 of this document describes why implementations might not
close connections merely because they are in the persist condition, close connections merely because they are in the persist condition,
yet need to still allow such connections to be closed on command. yet need to still allow such connections to be closed on command.
Section 3 outlines a simple attack on systems that do not Section 3 outlines a simple attack on systems that do not
sufficiently manage connections in this state. Section 4 concludes sufficiently manage connections in this state. Section 4 concludes
with a requirements-language clarification to the RFC 1122 with a requirements-language clarification to the RFC 1122
requirement. requirement.
2. Discussion on RFC 1122 Requirement 1.1. Requirements Language
Per Requirements for Internet Hosts [RFC1122] as long as the ACK's The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
are being received for window probes, a connection can continue to "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
stay in the persist condition. This is an important feature because "OPTIONAL" in this document are to be interpreted as described in
typically applications would want the TCP connection to stay open [RFC2119].
unless an application explicitly closes the connection.
2. Discussion of RFC 1122 Requirement
Per [RFC1122], as long as the ACKs are being received for window
probes, a connection can continue to stay in the persist condition.
This is an important feature, because applications typically would
want the TCP connection to stay open unless an application explicitly
closes the connection.
For example, take the case of a user running a network print job
during which the printer runs out of paper and is waiting for the
user to reload the paper tray (user intervention). The printer may
not be reading data from the printing application during this time.
For example take the case of user running a network print job during
which the printer runs out of paper and is waiting for the user
intervention to reload the paper tray. The printer may not be
reading data from the printing application during this time.
Although this may result in a prolonged ZWP state, it would be Although this may result in a prolonged ZWP state, it would be
premature for TCP to take action on its own and close the printer premature for TCP to take action on its own and close the printer
connecting merely due to its lack of progress. Once the printer's connection merely due to its lack of progress. Once the printer's
paper tray is reloaded (which may be minutes, hours, or days later), paper tray is reloaded (which may be minutes, hours, or days later),
the print job needs to be able to continue uninterrupted over the the print job needs to be able to continue uninterrupted over the
same TCP connection. same TCP connection.
However, systems that misinterpret the above section of Requirements However, systems that misinterpret Section 4.2.2.17 of [RFC1122] may
for Internet Hosts [RFC1122] may fall victim to DoS attacks, by not fall victim to DoS attacks by not supporting sufficient mechanisms to
supporting sufficient mechanisms to allow release of system resources allow release of system resources tied up by connections in the
tied up by connections in the persist condition during times of persist condition during times of resource exhaustion. For example,
resource exhaustion. For example, if we take the case of a busy take the case of a busy server where multiple (attacker) clients can
server where multiple (attacker) clients can advertise a zero window advertise a zero window forever (by reliably acknowledging the ZWPs).
forever (by reliably acknowledging the ZWPs). This could eventually This could eventually lead to resource exhaustion in the server
lead to the resource exhaustion in the server system. In such cases system. In such cases, the application or operating system would
the application or operating system would need to take appropriate need to take appropriate action on the TCP connection to reclaim
action on the TCP connection to reclaim their resources and continue their resources and continue to maintain legitimate connections.
to maintain legitimate connections.
The problem is applicable to TCP and TCP derived flow-controlled The problem is applicable to TCP and TCP-derived flow-controlled
transport protocols like SCTP. transport protocols such as the Stream Control Transmission Protocol
(SCTP).
Clearly, a system needs to be robust to such attacks and allow Clearly, a system needs to be robust to such attacks and allow
connections in the persist condition to be aborted in the same way as connections in the persist condition to be aborted in the same way as
any other connection. Section 4 of this document provides the any other connection. Section 4 of this document provides the
requisite clarification, to permit such resource management requisite clarification to permit such resource management.
3. Description of one Simple Attack 3. Description of One Simple Attack
To illustrate a potential DoS scenario, consider the case where many To illustrate a potential DoS scenario, consider the case where many
client applications open TCP connection with a HTTP [RFC2616] server, client applications open TCP connections with an HTTP [RFC2616]
and each sends a GET request for a large page and stops reading the server, and each sends a GET request for a large page and stops
response partway through. This causes the client's TCP reading the response partway through. This causes the client's TCP
implementation to advertise a zero window to the server. For every implementation to advertise a zero window to the server. For every
large HTTP response, the server is left holding on to the response large HTTP response, the server is left holding on to the response
data in its sending queue. The amount of response data held will data in its sending queue. The amount of response data held will
depend on the size of the send buffer and the advertised window. If depend on the size of the send buffer and the advertised window. If
the clients never read the data in their receive queues in order to the clients never read the data in their receive queues and therefore
clear the persist condition, the server will continue to hold that do not clear the persist condition, the server will continue to hold
data indefinitely. Since there may be a limit to the operating that data indefinitely. Since there may be a limit to the operating
system kernel memory available for TCP buffers, this may result in system kernel memory available for TCP buffers, this may result in
DoS to legitimate connections by locking up the necessary resources. DoS to legitimate connections by locking up the necessary resources.
If the above scenario persists for an extended period of time, it If the above scenario persists for an extended period of time, it
will lead to TCP buffers and connection blocks starvation causing will lead to starvation of TCP buffers and connection blocks, causing
legitimate existing connections and new connection attempts to fail. legitimate existing connections and new connection attempts to fail.
A clever application needs to detect such attacks with connections A clever application needs to detect such attacks with connections
that are not making progress, and could close these connections. that are not making progress, and could close these connections.
However, some applications might have transferred all the data to the However, some applications might have transferred all the data to the
TCP socket and subsequently closed the socket leaving the connection TCP socket and subsequently closed the socket, leaving the
with no controlling process, hereby referred to as orphaned connections with no controlling process; such connections are
connections. Such orphaned connections might be left holding the referred to as orphaned connections. These orphaned connections
data indefinitely in their sending queue. might be left holding the data indefinitely in their sending queue.
CERT has released an advisory in this regard[VU723308] and is making The US Computer Emergency Readiness Team (CERT) has released an
vendors aware of this DoS scenario. advisory in this regard [VU723308] and is making vendors aware of
this DoS scenario.
4. Clarification Regarding RFC 1122 Requirements 4. Clarification Regarding RFC 1122 Requirements
As stated in Requirements for Internet Hosts [RFC1122], a TCP As stated in [RFC1122], a TCP implementation MUST NOT close a
implementation MUST NOT close a connection merely because it seems to connection merely because it seems to be stuck in the ZWP or persist
be stuck in the ZWP or persist condition. Unstated in RFC 1122, but condition. Though unstated in RFC 1122, but implicit for system
implicit for system robustness, a TCP implementation needs to allow robustness, a TCP implementation needs to allow connections in the
connections in the ZWP or persist condition to be closed or aborted ZWP or persist condition to be closed or aborted by their
by their applications or other resource management routines in the applications or other resource management routines in the operating
operating system. system.
An interface that allows an application to inform TCP on what to do An interface that allows an application to inform TCP on what to do
when the connection stays in persist condition, or for application or when the connection stays in the persist condition, or that allows an
other resource manager to query the health of the TCP connection is application or other resource manager to query the health of the TCP
considered outside the scope of this document. All such techniques connection, is considered outside the scope of this document. All
however are in complete compliance of TCP [RFC0793] and Requirements such techniques, however, are in complete compliance with TCP
for Internet Hosts [RFC1122]. [RFC0793] and [RFC1122].
5. IANA Considerations
This document has no actions for IANA.
6. Security Considerations 5. Security Considerations
This document discusses one system security consideration as This document discusses one system security consideration that is
described in Security Considerations Guidelines [RFC3552]. In listed in "Guidelines for Writing RFC Text on Security
particular it describes a inappropriate use of a system that is Considerations" [RFC3552]. In particular, it describes an
acting as a server for many users. That and a possible DoS attack is inappropriate use of a system that is acting as a server for many
discussed in Section 3. users. That use and a possible DoS attack are discussed in
Section 3.
The document limits itself to clarifying RFC 1122. It does not This document limits itself to clarifying RFC 1122. It does not
discuss what can happen with orphaned connections and other possible discuss what can happen with orphaned connections and other possible
mitigation techniques, as these are considered outside the scope of mitigation techniques, as these are considered outside the scope of
this document. this document.
7. Acknowledgments 6. Acknowledgments
This document was inspired by the recent discussions that took place This document was inspired by the recent discussions that took place
regarding the TCP persist condition issue in the TCPM WG mailing list regarding the TCP persist condition issue in the TCP Maintenance and
[TCPM]. The outcome of those discussions was to come up with a draft Minor Extensions (TCPM) Working Group mailing list [TCPM]. The
that would clarify the intentions of the ZWP referred by RFC 1122. outcome of those discussions was to come up with a document that
We would like to thank Mark Allman, Ted Faber and David Borman for would clarify the intentions of the ZWP as discussed in RFC 1122. We
clarifying the objective behind this draft. To Wesley Eddy for his would like to thank Mark Allman, Ted Faber, and David Borman for
extensive editorial comments and to Dan Wing, Mark Allman and clarifying the objective behind this document. Thanks also go to
Fernando Gont on providing feedback on the document. Wesley Eddy for his extensive editorial comments and to Dan Wing,
Mark Allman, and Fernando Gont for providing feedback on this
document.
8. References 7. References
8.1. Normative References 7.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 7.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
July 2003. July 2003.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
Service Considerations", RFC 4732, December 2006. Denial-of-Service Considerations", RFC 4732,
December 2006.
[TCPM] TCPM, "IETF TCPM Working Group and mailing list [TCPM] IETF, "TCP Maintenance and Minor Extensions (tcpm) -
http://www.ietf.org/html.charters/tcpm.charter.html". Charter", <http://datatracker.ietf.org/wg/tcpm/charter/>.
[VU723308] [VU723308] Manion, A. and D. Warren, "TCP may keep its offered
Manion, "Vulnerability in Web Servers receive window closed indefinitely (RFC 1122)",
http://www.kb.cert.org/vuls/id/723308", July 2009. November 2009, <http://www.kb.cert.org/vuls/id/723308>.
Authors' Addresses Authors' Addresses
Murali Bashyam Murali Bashyam
Ocarina Networks, Inc Ocarina Networks, Inc.
42 Airport Parkway 42 Airport Parkway
San Jose, CA 95110 San Jose, CA 95110
USA USA
Phone: +1 (408) 512-2966 Phone: +1 (408) 512-2966
Email: mbashyam@ocarinanetworks.com EMail: mbashyam@ocarinanetworks.com
Mahesh Jethanandani Mahesh Jethanandani
Cisco Cisco
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 (408) 527-8230 Phone: +1 (408) 527-8230
Email: mjethanandani@gmail.com EMail: mjethanandani@gmail.com
Anantha Ramaiah Anantha Ramaiah
Cisco Cisco
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 (408) 525-6486 Phone: +1 (408) 525-6486
Email: ananth@cisco.com EMail: ananth@cisco.com
 End of changes. 49 change blocks. 
150 lines changed or deleted 159 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/