Skip to main content

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
[Ballot discuss]
1) persist is Informational, but you are using RFC2119 language.

2) does this document update rfc1122? the header doesn't say so, nor …
[Ballot discuss]
1) persist is Informational, but you are using RFC2119 language.

2) does this document update rfc1122? the header doesn't say so, nor does the abstract or intro sections.
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