draft-ietf-tcpm-persist-00.txt   draft-ietf-tcpm-persist-01.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: December 4, 2010 Cisco Systems Expires: May 14, 2011 Cisco Systems
June 02, 2010 November 10, 2010
Clarification of sender behaviour in persist condition. Clarification of sender behaviour in persist condition.
draft-ietf-tcpm-persist-00.txt draft-ietf-tcpm-persist-01.txt
Abstract Abstract
This document attempts to clarify the notion of the Zero Window This document attempts to clarify the notion of the Zero Window
Probes (ZWP) described in RFC 1122 [RFC1122]. In particular, it Probes (ZWP) described in RFC 1122 [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. The motivation for this document experiencing the ZWP condition. The motivation for this document
stems from the belief that TCP implementations strictly adhering to stems from the belief that TCP implementations strictly adhering to
the current RFC language have the potential to become vulnerable to the current RFC language have the potential to become vulnerable to
Denial of Service (DoS) scenarios. Denial of Service (DoS) scenarios.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 December 4, 2010. This Internet-Draft will expire on May 14, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 7, line 11 skipping to change at page 7, line 11
so or the application or the resource manager can query the health of 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. 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. All such actions are in complete compliance of RFC 793 and RFC 1122.
5. Conclusion 5. Conclusion
The document addresses the fact that terminating TCP connections The document addresses the fact that terminating TCP connections
stuck in the persist condition does not violate RFC 1122 or RFC 793. stuck in the persist condition does not violate RFC 1122 or RFC 793.
It also suggests that TCP must not abort any connection until It also suggests that TCP must not abort any connection until
explicitly requested by the application or the operating system to do explicitly requested by the application or the operating system to do
so. The implementation guidelines of the request and the action are so. The potential implementation guidelines of the request and the
documented in Section 7, and the details of mitigating the DoS attack action are documented in Section 7, and the details of mitigating the
are left to the implementer. DoS attack are left to the implementer.
6. 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 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 and David Borman for clarifying We would like to thank Mark Allman and David Borman for clarifying
the objective behind this draft. To Dan Wing, Mark Allman and the objective behind this draft. To Dan Wing, Mark Allman and
Fernando Gont on providing feedback on the document. Fernando Gont on providing feedback on the document.
7. Programming Considerations 7. Programming Considerations
To enable a server to clear connections in persist condition and As a potential implementation guideline, the authors are documenting
reclaim resources, a socket interface needs to be defined. Note, some of the programming considerations. This should not be in any
this condition is mutually exclusive from a persist condition where way construed as the only way that the mitigation against the DoS
we are not getting zero windows acknowledgement for the probes. condition can be achieved. Applications can choose their own
implementations on how to deal with this DoS sceanrio.
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 can inform TCP or kernel of how long
they are willing to wait in persist condition. When the connection
reaches that particular timeout value a EPERSISTTIMEOUT notification
will be sent to the application. The application on receiving the
notification can turn around and issue a close. In the case, the
application has terminated, TCP or kernel will go ahead and clear the
connection and reclaim the resoruces. Note, this persist condition
is mutually exclusive from a persist condition where we are not
getting zero windows acknowledgement for the probes.
PERSIST_TIMEOUT PERSIST_TIMEOUT
Format: Format:
int setsockopt (sockfd, SOL_TCP, SO_PERSISTTIMEO, int setsockopt (sockfd, SOL_TCP, SO_PERSISTTIMEO,
persist_timeout_value, length) persist_timeout_value, length)
int getsockopt (sockfd, SOL_TCP, SO_PERSISTTIMEO, int getsockopt (sockfd, SOL_TCP, SO_PERSISTTIMEO,
persist_timeout_value, length) persist_timeout_value, length)
where persist_timeout_value recorded in seconds is of type int and where persist_timeout_value recorded in seconds is of type int and
the length is four. the length is four.
The interface allows applications to inform TCP that when the local The above interface allows applications to inform TCP that when the
connection stays in persist condition it can be aborted after a set local connection stays in persist condition it can be aborted after a
time. Note that the default value of this option is infinite. set time. Note that the default value of this option is infinite.
TCP sender will save the current time in the connection block when it 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 receives a zero window ACK. This time is referred to as the persist
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
 End of changes. 6 change blocks. 
14 lines changed or deleted 27 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/