draft-ietf-tcpm-persist-02.txt   draft-ietf-tcpm-persist-03.txt 
TCP Maintenance and Minor M. Bashyam TCP Maintenance and Minor M. Bashyam
Extensions Working Group Ocarina Networks, Inc Extensions Working Group Ocarina Networks, Inc
Internet-Draft M. Jethanandani Internet-Draft M. Jethanandani
Intended status: Informational A. Ramaiah Intended status: Informational A. Ramaiah
Expires: August 18, 2011 Cisco Expires: August 18, 2011 Cisco
February 14, 2011 February 14, 2011
Clarification of sender behavior in persist condition. Clarification of sender behavior in persist condition.
draft-ietf-tcpm-persist-02.txt draft-ietf-tcpm-persist-03.txt
Abstract Abstract
This document clarifies the Zero Window Probes (ZWP) described in This document clarifies the Zero Window Probes (ZWP) described in
[RFC1122]. In particular, it clarifies the actions that can be taken Requirements for Internet Hosts [RFC1122]. In particular, it
on connections which are experiencing the ZWP condition. clarifies the actions that can be taken on connections which are
experiencing the ZWP condition.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
skipping to change at page 2, line 8 skipping to change at page 2, line 9
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Discussion on RFC 1122 Requirement . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Description of one Simple Attack . . . . . . . . . . . . . . . 5 3. Discussion on RFC 1122 Requirement . . . . . . . . . . . . . . 5
4. Clarification Regarding RFC 1122 Requirements . . . . . . . . 6 4. Description of one Simple Attack . . . . . . . . . . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 5. Clarification Regarding RFC 1122 Requirements . . . . . . . . 7
6. Appendix A, Programming Considerations . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Informative References . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
9. Appendix A, Programming Considerations . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Section 4.2.2.17 of [RFC1122] says: Section 4.2.2.17 of Requirements for Internet Hosts [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
skipping to change at page 3, line 31 skipping to change at page 3, line 31
connection from hanging forever if ACK segments that re-opens the connection from hanging forever if ACK segments that re-opens the
window is lost. The condition where the sender goes into the Zero- window is 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 connections to be
aborted regardless of them being in the persist condition, and the aborted regardless of them being in the persist condition, and the
TCP implementation should, of course, comply by aborting such TCP implementation should, of course, comply by aborting such
connections. TCP implementations strictly adhering to Section connections. TCP implementations strictly adhering to Section
4.2.2.17 of [RFC1122] have the potential to make systems vulnerable 4.2.2.17 of Requirements for Internet Hosts [RFC1122] have the
to Denial of Service (DoS) scenarios where attackers tie up resources potential to make systems vulnerable to Denial of Service (DoS)
by keeping connections in the persist condition, if such resource scenarios where attackers tie up resources by keeping connections in
management is not performed external to the protocol implementation. the persist condition, if such resource management is not performed
external to the protocol implementation.
Section 2 of this document describes why implementations must not Section 2 of this document describes why implementations must not
close connections merely because they are in the persist condition, close connections merely because they are in the persist condition,
yet must still allow such connections to be closed on command. yet must 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 2. Requirements
Per [RFC1122] as long as the ACK's are being received for window The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
probes, a connection can continue to stay in the persist condition. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
This is an important feature because typically applications would document are to be interpreted as described in RFC 2119.
want the TCP connection to stay open unless an application explicitly
closes the connection. When used in lowercase, these words convey their typical use in
common language, and they are not to be interpreted as described in
Key words for use in RFCs [RFC2119].
3. Discussion on RFC 1122 Requirement
Per Requirements for Internet Hosts [RFC1122] as long as the ACK's
are being received for window probes, a connection can continue to
stay in the persist condition. This is an important feature because
typically applications would want the TCP connection to stay open
unless an application explicitly closes the connection.
For example take the case of user running a network print job during 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 which the printer runs out of paper and is waiting for the user
intervention to reload the paper tray. The printer may not be intervention to reload the paper tray. The printer may not be
reading data from the printing application during this time. 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 connecting 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 should be able to continue uninterrupted over the same the print job should be able to continue uninterrupted over the same
TCP connection. TCP connection.
Systems that adhere too strictly to the above verbiage of [RFC1122] Systems that adhere too strictly to the above verbiage of
may fall victim to DoS attacks, by not supporting sufficient Requirements for Internet Hosts [RFC1122] may fall victim to DoS
mechanisms to allow release of system resources tied up by attacks, by not supporting sufficient mechanisms to allow release of
connections in the persist condition during times of resource system resources tied up by connections in the persist condition
exhaustion. For example, if we take the case of a busy server where during times of resource exhaustion. For example, if we take the
multiple (attacker) clients can advertise a zero window forever (by case of a busy server where multiple (attacker) clients can advertise
reliably acknowledging the ZWPs). This could eventually lead to the a zero window forever (by reliably acknowledging the ZWPs). This
resource exhaustion in the server system. In such cases the could eventually lead to the resource exhaustion in the server
application or operating system would need to take appropriate action system. In such cases the application or operating system would need
on the TCP connection to reclaim their resources and continue to to take appropriate action on the TCP connection to reclaim their
persist legitimate connections. resources and continue to persist 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 like SCTP.
Clearly, a system should be robust to such attacks and allow Clearly, a system should 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, in standards language, to permit such requisite clarification, in standards language, to permit such
resource management resource management
3. Description of one Simple Attack 4. 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 connection with a HTTP [RFC2616] server,
and each sends a GET request for a large page and stops reading the and each sends a GET request for a large page and stops reading the
response partway through. This causes the client's TCP 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 in order to
skipping to change at page 6, line 5 skipping to change at page 7, line 5
in their sending queue. in their sending queue.
CERT has released an advisory in this regard[VU723308] and is making CERT has released an advisory in this regard[VU723308] and is making
vendors aware of this DoS scenario. vendors aware of this DoS scenario.
Appendix A of this document provides a simple mitigation to such Appendix A of this document provides a simple mitigation to such
attacks. More sophisticated attacks are possible which can build on attacks. More sophisticated attacks are possible which can build on
this vulnerability and may remain effective even when mitigated with this vulnerability and may remain effective even when mitigated with
the mechanism prescribed in Appendix A of this document. the mechanism prescribed in Appendix A of this document.
4. Clarification Regarding RFC 1122 Requirements 5. Clarification Regarding RFC 1122 Requirements
As stated in [RFC1122], a TCP implementation MUST NOT close a As stated in Requirements for Internet Hosts [RFC1122], a TCP
connection merely because it seems to be stuck in the ZWP or persist implementation MUST NOT close a connection merely because it seems to
condition. Unstated in RFC 1122, but implicit for system robustness, be stuck in the ZWP or persist condition. Unstated in RFC 1122, but
a TCP implementation MUST allow connections in the ZWP or persist implicit for system robustness, a TCP implementation MUST allow
condition to be closed or aborted by their applications or other connections in the ZWP or persist condition to be closed or aborted
resource management routines in the operating system. by their applications or other resource management routines in the
operating system.
In order to provide some level of robustness to DoS attacks, a TCP In order to provide some level of robustness to DoS attacks, a TCP
implementation MAY provide a feedback regarding the persist condition implementation MAY provide a feedback regarding the persist condition
to the application if requested to do so or an application or other to the application if requested to do so or an application or other
resource manager can query the health of the TCP connection allowing resource manager can query the health of the TCP connection allowing
it to take the desired action. All such techniques are in complete it to take the desired action. All such techniques are in complete
compliance of [RFC0793] and [RFC1122]. compliance of TCP [RFC0793] and Requirements for Internet Hosts
[RFC1122].
5. Acknowledgments 6. IANA Considerations
This document has no actions for IANA.
7. Security Considerations
This document discusses one system security consideration as
described in Security Considerations Guidelines [RFC3552]. In
particular it describes a inappropriate use of a system that is
acting as a server for many users. That and a possible DoS attack is
discussed in Section 3.
8. 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 TCPM WG mailing list
[TCPM]. The outcome of those discussions was to come up with a draft [TCPM]. The outcome of those discussions was to come up with a draft
that would clarify the intentions of the ZWP referred by RFC 1122. that would clarify the intentions of the ZWP referred by RFC 1122.
We would like to thank Mark Allman, Ted Faber and David Borman for We would like to thank Mark Allman, Ted Faber and David Borman for
clarifying the objective behind this draft. To Wesley Eddy for his clarifying the objective behind this draft. To Wesley Eddy for his
extensive editorial comments and to Dan Wing, Mark Allman and extensive editorial comments and to Dan Wing, Mark Allman and
Fernando Gont on providing feedback on the document. Fernando Gont on providing feedback on the document.
6. Appendix A, Programming Considerations 9. Appendix A, Programming Considerations
As a potential implementation guideline, the authors are documenting As a potential implementation guideline, the authors are documenting
some of the programming considerations. This should not be in any some of the programming considerations. This should not be in any
way construed as the only way that the mitigation against the DoS way construed as the only way that the mitigation against the DoS
condition can be achieved. Applications can choose their own condition can be achieved. Applications can choose their own
implementations on how to deal with this DoS scenario, and should be implementations on how to deal with this DoS scenario, and should be
aware that this mitigation is only effective at combating the simple aware that this mitigation is only effective at combating the simple
attack scenario described in this document, and does not handle even attack scenario described in this document, and does not handle even
slightly more sophisticated attacks based on the same or similar slightly more sophisticated attacks based on the same or similar
concepts. concepts.
skipping to change at page 10, line 5 skipping to change at page 13, line 5
entry time. Thereafter every time the probe timer expires and before entry time. Thereafter every time the probe timer expires and before
it sends another probe or an ACK carrying zero window is received a 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 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. condition by comparing the current time to the persist entry time.
If the timeout has been exceeded, the connection will be aborted. If the timeout has been exceeded, the connection will be aborted.
Any time a ACK is received that advertises a non-zero window, the Any time a ACK is received that advertises a non-zero window, the
persist entry time is cleared to take the connection out of the persist entry time is cleared to take the connection out of the
persist condition. persist condition.
7. Informative References 10. References
10.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., "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.
10.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
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[TCPM] TCPM, "IETF TCPM Working Group and mailing list [TCPM] TCPM, "IETF TCPM Working Group and mailing list
http://www.ietf.org/html.charters/tcpm.charter.html". http://www.ietf.org/html.charters/tcpm.charter.html".
[VU723308] [VU723308]
Manion, "Vulnerability in Web Servers Manion, "Vulnerability in Web Servers
http://www.kb.cert.org/vuls/id/723308", July 2009. http://www.kb.cert.org/vuls/id/723308", July 2009.
Authors' Addresses Authors' Addresses
Murali Bashyam Murali Bashyam
 End of changes. 17 change blocks. 
44 lines changed or deleted 83 lines changed or added

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