TCP Sender Clarification for Persist Condition
RFC 6429
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2015-10-14
|
07 | (System) | Notify list changed from tcpm-chairs@ietf.org, draft-ietf-tcpm-persist@ietf.org, mjethanandani@gmail.com to (None) |
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Pete Resnick |
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
|
2011-12-08
|
07 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue. |
|
2011-12-08
|
07 | (System) | RFC published |
|
2011-09-19
|
07 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent. |
|
2011-09-16
|
07 | (System) | IANA Action state changed to No IC from In Progress |
|
2011-09-16
|
07 | (System) | IANA Action state changed to In Progress |
|
2011-09-16
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2011-09-16
|
07 | Amy Vezza | IESG has approved the document |
|
2011-09-16
|
07 | Amy Vezza | Closed "Approve" ballot |
|
2011-09-15
|
07 | Wesley Eddy | Approval announcement text changed |
|
2011-09-15
|
07 | Wesley Eddy | Approval announcement text regenerated |
|
2011-09-15
|
07 | Wesley Eddy | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup. |
|
2011-09-15
|
07 | Russ Housley | [Ballot discuss] The Gen-ART Review by Brian Carpenter on 5-Jun-2011 started quite a discussion. That discussion does not seem to have reached closure. … [Ballot discuss] The Gen-ART Review by Brian Carpenter on 5-Jun-2011 started quite a discussion. That discussion does not seem to have reached closure. I find myself siding with the argument presented by David Borman for publication of this document as an Informational RFC, but this discussion needs to come to closure for a reasonable consensus call on this point. |
|
2011-09-15
|
07 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss |
|
2011-09-15
|
07 | (System) | New version available: draft-ietf-tcpm-persist-07.txt |
|
2011-09-13
|
07 | Pete Resnick | [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss |
|
2011-09-09
|
06 | (System) | New version available: draft-ietf-tcpm-persist-06.txt |
|
2011-09-09
|
07 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss |
|
2011-08-22
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2011-08-22
|
05 | (System) | New version available: draft-ietf-tcpm-persist-05.txt |
|
2011-07-11
|
07 | Wesley Eddy | State Change Notice email list has been changed to tcpm-chairs@tools.ietf.org, draft-ietf-tcpm-persist@tools.ietf.org, mjethanandani@gmail.com from tcpm-chairs@tools.ietf.org, draft-ietf-tcpm-persist@tools.ietf.org |
|
2011-06-17
|
07 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Derek Atkins. |
|
2011-06-09
|
07 | Cindy Morgan | Removed from agenda for telechat |
|
2011-06-09
|
07 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation. |
|
2011-06-09
|
07 | Amy Vezza | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
|
2011-06-09
|
07 | Adrian Farrel | [Ballot comment] Support David and Pete's Discusses |
|
2011-06-09
|
07 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-06-09
|
07 | Sean Turner | [Ballot comment] I'm with Dave on this - shouldn't this draft include "Updates: 1122 (once approved)" in the header? If it is updating 1122 then … [Ballot comment] I'm with Dave on this - shouldn't this draft include "Updates: 1122 (once approved)" in the header? If it is updating 1122 then doesn't it have to go standards track? |
|
2011-06-09
|
07 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-06-09
|
07 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-06-08
|
07 | Russ Housley | [Ballot discuss] The Gen-ART Review by Brian Carpenter on 5-Jun-2011 started quite a discussion. That discussion does not seem to have reached closure. … [Ballot discuss] The Gen-ART Review by Brian Carpenter on 5-Jun-2011 started quite a discussion. That discussion does not seem to have reached closure. I find myself siding with the argument presented by David Borman for publication of this document as an Informational RFC, but this discussion needs to come to closure for a reasonable consensus call on this point. |
|
2011-06-08
|
07 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-06-08
|
07 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-06-08
|
07 | Amanda Baber | We understand that this document doesn't require any IANA actions. |
|
2011-06-07
|
07 | Peter Saint-Andre | [Ballot comment] Please expand "DoS" on first use and add an informative reference to RFC 4732. |
|
2011-06-07
|
07 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-06-07
|
07 | Ralph Droms | [Ballot comment] Are the phrases "Zero-Window Probe (ZWP)", 'persist condition', "ZWP state" and "ZWP or persist condition" all equivalent? If so, for consistency, choose one … [Ballot comment] Are the phrases "Zero-Window Probe (ZWP)", 'persist condition', "ZWP state" and "ZWP or persist condition" all equivalent? If so, for consistency, choose one and use it throughout. At the end of section 3, for clarity, I suggest changing: OLD: to persist legitimate connections NEW: to maintain legitimate connections in persist condition |
|
2011-06-07
|
07 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-06-05
|
07 | Pete Resnick | [Ballot discuss] In the introduction: This guidance is not intended to preclude resource management by the operating system or application, which may request … [Ballot discuss] In the introduction: This guidance is not intended to preclude resource management by the operating system or application, which may request connections to be aborted regardless of them being in the persist condition, and the TCP implementation should, of course, comply by aborting such connections. And in section 5: ...a TCP implementation MUST allow connections in the ZWP or persist condition to be closed or aborted by their applications or other resource management routines in the operating system. It's likely that these statements are either superfluous or incorrect. The 1122 instructions say that "TCP MUST allow the connection to stay open." It doesn't put any requirement on operating systems or applications which might purposefully abort connections for any purpose, including the DoS attack identified in this document, or because of user-cancel operations, or system shutdowns, or any number of other reasons, and I have no indication (at least it is nowhere cited in this document) that anybody has taken the guidance to TCP to mean that such aborts should not be honored. So in that sense, I think the statement doesn't add much to the interpretation of TCP. However, insofar as this statement intends that operating systems or applications ought to be allowed to *blindly* abort connections in persist condition, I think it is flat wrong. That is to say, if the operating system has some reason to believe that the connection is actually dead, or an attack, of course an abort is justified. As the document says in section 4: A clever application might detect such attacks with connections that are not making progress, and could close these connections. And indeed, this should be recommended behavior in the face of the attack. However, the next sentence reveals what is actually going on here: ...However, some applications might have transferred all the data to the TCP socket and subsequently closed the socket leaving the connection with no controlling process, hereby referred to as orphaned connections. It is socket implementations, not TCP, that are the real problem here. Many of these APIs that allow applications to exit without gracefully closing TCP connections are what is causing the problem, not the protocol design of TCP or the implementation requirements in 1122. If the WG (and the IETF) really think that this has something to do with the requirements of 1122, then this document needs to be standards track, not informational, and should explain why this is a protocol problem. If this is just a security consideration regarding persist condition connections, then it should state that applications and/or operating systems need to look out for this attack and only abort those connections that it has determined are in fact attacks and not all persist condition connections (and probably give some implementation advice about how to distinguish real persist condition from an attack). And if this document is about the socket API, it should stick to discussion about that and not implicate 1122 in this mess. In either of the latter two cases, as per David Harrington's discussion, it should remove the 2119 language since it is informational and no protocol change is being made. |
|
2011-06-05
|
07 | Pete Resnick | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-06-03
|
07 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-06-03
|
07 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
|
2011-06-01
|
07 | David Harrington | |
|
2011-06-01
|
07 | David Harrington | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-05-31
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Derek Atkins |
|
2011-05-31
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Derek Atkins |
|
2011-05-23
|
07 | Stewart Bryant | [Ballot comment] "Systems that adhere too strictly to the above verbiage of" Comment: In English English I would not consider "verbiage" to be polite to … [Ballot comment] "Systems that adhere too strictly to the above verbiage of" Comment: In English English I would not consider "verbiage" to be polite to the author of RFC1122. |
|
2011-05-23
|
07 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-05-20
|
07 | Amy Vezza | Last call sent |
|
2011-05-20
|
07 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <tcpm@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-tcpm-persist-04.txt> (Clarification of sender behavior in persist condition.) to Informational RFC The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Clarification of sender behavior in persist condition.' <draft-ietf-tcpm-persist-04.txt> as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document clarifies the Zero Window Probes (ZWP) described in Requirements for Internet Hosts [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-persist/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-persist/ No IPR declarations have been submitted directly on this I-D. |
|
2011-05-19
|
07 | Wesley Eddy | Telechat date has been changed to 2011-06-09 from 2011-05-26 |
|
2011-05-19
|
07 | Wesley Eddy | Last Call text changed |
|
2011-05-19
|
07 | Wesley Eddy | Last Call was requested |
|
2011-05-19
|
07 | Wesley Eddy | State changed to Last Call Requested from IESG Evaluation. |
|
2011-05-19
|
07 | Wesley Eddy | [Ballot Position Update] New position, Yes, has been recorded for Wesley Eddy |
|
2011-05-19
|
07 | Wesley Eddy | Ballot has been issued |
|
2011-05-19
|
07 | Wesley Eddy | Created "Approve" ballot |
|
2011-05-19
|
07 | (System) | Ballot writeup text was added |
|
2011-05-19
|
07 | (System) | Last call text was added |
|
2011-05-19
|
07 | (System) | Ballot approval text was added |
|
2011-05-09
|
07 | Wesley Eddy | Placed on agenda for telechat - 2011-05-26 |
|
2011-05-09
|
07 | Wesley Eddy | State changed to IESG Evaluation from AD Evaluation. |
|
2011-05-05
|
07 | Wesley Eddy | State changed to AD Evaluation from Publication Requested. |
|
2011-05-05
|
07 | Cindy Morgan | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the … (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Michael Scharf (michael.scharf@alcatel-lucent.com) is the document shepherd. He has personally reviewed this version and believes it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document is the outcome of lengthy discussions that have spanned over years. The WG chairs (Wes Eddy and David Borman) have had one on one discussions with the authors prior to it being adopted as a WG document, as well as discussions on the mailing list since it was adopted. The working group last call generated late feedback from key WG members that is addressed in the document. Since this is a short and informational document, the reviews are sufficient. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There was a significant amount of discussions on the scope of this document, and the WG consensus was to come up with a draft that clarifies the intentions of RFC 1122. There is a reasonable level of support for the document. During the working group last call, some late objections have been raised on the mailing list, and the requested changes have completely been incorporated in the document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? There are no significant formatting issues. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are properly split. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations are present and specify no actions for IANA. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not applicable. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. From abstract: This document clarifies the Zero Window Probes (ZWP) described in Requirements for Internet Hosts [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The biggest challenge with this document was getting the authors to limit its scope and simplify what needed to be in the document to make it acceptable as a WG document. The entire impetus for this document was that there were TCP implementations out there that treated connections in persist state as special, and had explicit code to keep them from being terminated in situations where the implementation would normally abort connections in other TCP states, which lead to a vulnerability for resource starvation. Earlier versions of the document contained a full API, i. e., a mechanism for applications to set timers to abort TCP connections in persist state, and the WG wanted the document to only identify and clarify the issue of how a TCP should treat connections in the persist state: the same as any other connection. All that has been removed from the document. Early on one of the largest issues was getting the authors to understand the distinction between the TCP protocol itself terminating a connection in persist state, and some other part of the operating system implementation terminating a TCP connection. If the OS is resource starved it can abort any TCP connections it wants to, including connections in persist state, and that does not make it the TCP protocol that is deciding to abort the connection. In its current format, the document reflects those changes to limit the scope of the document to just identify what has been mis-interpretted and clarify that a TCP connection in persist state is treated the same as any other TCP connection. And while this document doesn't explicitly state it, the reason that Section 4.2.2.17 of Requirements for Internet Hosts [RFC1122] exists is that at the time there were TCP implementations that were treating connections in persist state the same as connections that weren't receiving any return traffic and timing them out. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This is a short informational document that does not specify a protocol. It is published to clarify the intentions of RFC 1122. |
|
2011-05-05
|
07 | Cindy Morgan | Draft added in state Publication Requested |
|
2011-05-05
|
07 | Cindy Morgan | [Note]: 'Michael Scharf (michael.scharf@alcatel-lucent.com) is the document shepherd.' added |
|
2011-03-29
|
04 | (System) | New version available: draft-ietf-tcpm-persist-04.txt |
|
2011-02-16
|
03 | (System) | New version available: draft-ietf-tcpm-persist-03.txt |
|
2011-02-14
|
02 | (System) | New version available: draft-ietf-tcpm-persist-02.txt |
|
2010-11-10
|
01 | (System) | New version available: draft-ietf-tcpm-persist-01.txt |
|
2010-06-03
|
00 | (System) | New version available: draft-ietf-tcpm-persist-00.txt |