draft-ietf-tcpm-persist-03.txt   draft-ietf-tcpm-persist-04.txt 
TCP Maintenance and Minor M. Bashyam TCP Maintenance and Minor Extensions M. Bashyam
Extensions Working Group Ocarina Networks, Inc 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: September 30, 2011 Cisco
February 14, 2011 March 29, 2011
Clarification of sender behavior in persist condition. Clarification of sender behavior in persist condition.
draft-ietf-tcpm-persist-03.txt draft-ietf-tcpm-persist-04.txt
Abstract Abstract
This document clarifies the Zero Window Probes (ZWP) described in This document clarifies the Zero Window Probes (ZWP) described in
Requirements for Internet Hosts [RFC1122]. In particular, it Requirements for Internet Hosts [RFC1122]. In particular, it
clarifies the actions that can be taken on connections which are clarifies the actions that can be taken on connections which are
experiencing the ZWP condition. experiencing the ZWP condition.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2011. This Internet-Draft will expire on September 30, 2011.
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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Discussion on RFC 1122 Requirement . . . . . . . . . . . . . . 5 3. Discussion on RFC 1122 Requirement . . . . . . . . . . . . . . 5
4. Description of one Simple Attack . . . . . . . . . . . . . . . 6 4. Description of one Simple Attack . . . . . . . . . . . . . . . 6
5. Clarification Regarding RFC 1122 Requirements . . . . . . . . 7 5. Clarification Regarding RFC 1122 Requirements . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
9. Appendix A, Programming Considerations . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
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 [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."
skipping to change at page 3, line 37 skipping to change at page 3, line 37
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 Requirements for Internet Hosts [RFC1122] have the 4.2.2.17 of Requirements for Internet Hosts [RFC1122] have the
potential to make systems vulnerable to Denial of Service (DoS) potential to make systems vulnerable to Denial of Service (DoS)
scenarios where attackers tie up resources by keeping connections in scenarios where attackers tie up resources by keeping connections in
the persist condition, if such resource management is not performed the persist condition, if such resource management is not performed
external to the protocol implementation. external to the protocol implementation.
Section 2 of this document describes why implementations must not Section 3 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 4 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 5 concludes
with a requirements-language clarification to the RFC 1122 with a requirements-language clarification to the RFC 1122
requirement. requirement.
2. Requirements 2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
When used in lowercase, these words convey their typical use in When used in lowercase, these words convey their typical use in
skipping to change at page 5, line 41 skipping to change at page 5, line 41
could eventually lead to the resource exhaustion in the server could eventually lead to the resource exhaustion in the server
system. In such cases the application or operating system would need system. In such cases the application or operating system would need
to take appropriate action on the TCP connection to reclaim their to take appropriate action on the TCP connection to reclaim their
resources and continue to 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 5 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
4. 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
skipping to change at page 6, line 35 skipping to change at page 7, line 5
are not making progress, and could close these connections. However, are not making progress, and could close these connections. However,
some applications might have transferred all the data to the TCP some applications might have transferred all the data to the TCP
socket and subsequently closed the socket leaving the connection with socket and subsequently closed the socket leaving the connection with
no controlling process, hereby referred to as orphaned connections. no controlling process, hereby referred to as orphaned connections.
Such orphaned connections might be left holding the data indefinitely Such orphaned connections might be left holding the data indefinitely
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
attacks. More sophisticated attacks are possible which can build on
this vulnerability and may remain effective even when mitigated with
the mechanism prescribed in Appendix A of this document.
5. Clarification Regarding RFC 1122 Requirements 5. Clarification Regarding RFC 1122 Requirements
As stated in Requirements for Internet Hosts [RFC1122], a TCP As stated in Requirements for Internet Hosts [RFC1122], a TCP
implementation MUST NOT close a connection merely because it seems to implementation MUST NOT close a connection merely because it seems to
be stuck in the ZWP or persist condition. Unstated in RFC 1122, but be stuck in the ZWP or persist condition. Unstated in RFC 1122, but
implicit for system robustness, a TCP implementation MUST allow implicit for system robustness, a TCP implementation MUST allow
connections in the ZWP or persist condition to be closed or aborted connections in the ZWP or persist condition to be closed or aborted
by their applications or other resource management routines in the by their applications or other resource management routines in the
operating system. operating system.
In order to provide some level of robustness to DoS attacks, a TCP An interface that allows an application to inform TCP on what to do
implementation MAY provide a feedback regarding the persist condition when the connection stays in persist condition, or for application or
to the application if requested to do so or an application or other other resource manager to query the health of the TCP connection is
resource manager can query the health of the TCP connection allowing considered outside the scope of this document. All such techniques
it to take the desired action. All such techniques are in complete however are in complete compliance of TCP [RFC0793] and Requirements
compliance of TCP [RFC0793] and Requirements for Internet Hosts for Internet Hosts [RFC1122].
[RFC1122].
6. IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
7. Security Considerations 7. Security Considerations
This document discusses one system security consideration as This document discusses one system security consideration as
described in Security Considerations Guidelines [RFC3552]. In described in Security Considerations Guidelines [RFC3552]. In
particular it describes a inappropriate use of a system that is particular it describes a inappropriate use of a system that is
skipping to change at page 11, line 5 skipping to change at page 11, line 5
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.
9. Appendix A, Programming Considerations 9. References
As a potential implementation guideline, the authors are documenting
some of the programming considerations. This should not be in any
way construed as the only way that the mitigation against the DoS
condition can be achieved. Applications can choose their own
implementations on how to deal with this DoS scenario, and should be
aware that this mitigation is only effective at combating the simple
attack scenario described in this document, and does not handle even
slightly more sophisticated attacks based on the same or similar
concepts.
Note, this persist condition is mutually exclusive from a persist
condition where we are not getting zero windows acknowledgement for
the probes.
The technique described here allows an application to specify to the
operating system that it consents to aborting such connections.
Implementers can choose to in addition provide an asynchronous
notification interface to inform the application of the connection in
the persist condition, if they want the application to abort the
connection. In the case where the application has terminated or
orphaned the connection, the TCP or kernel code will go ahead and
clear the connection and reclaim its resources.
The key consideration in putting a solution together is to be able to
detect a connection that is in persist condition. The application
through the socket interface will be able to inform TCP
implementation or kernel of how long they are willing to have
connections wait in the persist condition.
PERSIST_TIMEOUT
Format:
int setsockopt (sockfd, SOL_TCP, SO_PERSISTTIMEO,
persist_timeout_value, length)
int getsockopt (sockfd, SOL_TCP, SO_PERSISTTIMEO,
persist_timeout_value, length)
where persist_timeout_value recorded in seconds is of type int, the
length is set to four.
The above interface allows applications to inform TCP what to do when
the local connection stays in the persist condition. Note that the
default value of persist_timeout_value is -1 which implies it is
infinite.
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.
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 condition.
10. References
10.1. Normative References 9.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 9.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.
[TCPM] TCPM, "IETF TCPM Working Group and mailing list [TCPM] TCPM, "IETF TCPM Working Group and mailing list
 End of changes. 13 change blocks. 
91 lines changed or deleted 23 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/