Reducing the TIME-WAIT State Using TCP Timestamps
draft-ietf-tcpm-tcp-timestamps-04

[Ballot comment]
[Revised 2 February]

Nice document, very clear presentation.

I have one relatively minor issue with the Security Considerations section: the
first sentence doesn't have any connection with security considerations.
I suggest dropping the text entirely, retaining the pointer in the second sentence.

I think it would be better to point to draft-ietf-tcpm-tcp-security, rather than [CPNI-TCP],
since it will represent community consensus with respect to security issues for tcp.

[Ballot comment]
I think it would be better to point to draft-ietf-tcpm-tcp-security, rather than [CPNI-TCP],
since it will represent community consensus with respect to security issues for tcp.

[Ballot discuss]
[Revised 2 February]

Nice document, very clear presentation.

I have one relatively minor issue with the Security Considerations section: the
first sentence doesn't have any connection with security considerations.
I suggest dropping the text entirely, retaining the pointer in the second sentence.

[Ballot discuss]
This is a DISCUSS-DISCUSS (i.e., there is nothing for the author to do at this time).

Should this draft be a BCP or a standard track draft?

[Ballot discuss]
Nice document, very clear presentation.

I have some relatively minor issues with the Security Considerations section, plus a discuss-discuss issue.

(1)
The first paragraph doesn't really seem to describe a security issue.  I wonder if the
the text should be focused on the (lack of) security implications when only one of the
communicating peers implements the specification.  (As I understand it, this algorithm
never does any worse than the current state.)

(2)
It seems there is a very minor attack that is enabled by this enhancement -
certainly nothing that would preclude using this technique, but still there:
an attacker could spoof a SYN that met the requirements and prevent a
host from releasing unneeded resources (after the normal TIME_WAIT passed).

This attack could already be performed using the ISNs; this document
just expands the range of messages that could be used.

Now to the discuss-discuss:  is this really a BCP?  I personally would lean
to standards track, but want to hear what others think.

[Ballot discuss]
Nice document, very clear presentation.

I have some relatively minor issues with the Security Considerations section:

(1)
The first paragraph doesn't really seem to describe a security issue.  I wonder if the
the text should be focused on the (lack of) security implications when only one of the
communicating peers implements the specification.  (As I understand it, this algorithm
never does any worse than the current state.)

(2)
It seems there is a very minor attack that is enabled by this enhancement -
certainly nothing that would preclude using this technique, but still there:
an attacker could spoof a SYN that met the requirements and prevent a
host from releasing unneeded resources (after the normal TIME_WAIT passed).

This attack could already be performed using the ISNs; this document
just expands the range of messages that could be used.

[Ballot comment]
Nice document, very clear presentation.

I have some relatively minor issues with the Security Considerations section:

(1)
The first paragraph doesn't really seem to describe a security issue.  I wonder if the
the text should be focused on the (lack of) security implications when only one of the
communicating peers implements the specification.  (As I understand it, this algorithm
never does any worse than the current state.)

(2)
It seems there is a very minor attack that is enabled by this enhancement -
certainly nothing that would preclude using this technique, but still there:
an attacker could spoof a SYN that met the requirements and prevent a
host from releasing unneeded resources (after the normal TIME_WAIT passed).

This attack could already be performed using the ISNs; this document
just expands the range of messages that could be used.

[Ballot comment]
Stylistic suggestion: in the bullets in section 2, either include
  the parenthetical "(creating a connection in the SYN-RECEIVED
  state)" in every sub-bullet or only the first.

  Where ISN comparisons are performed in the rules in section 2, is
  the comparison strictly "less than", or is the (rather unlikely
  event of) wraparound considered?

[Ballot comment]
section 3:
s/are important for TCPs that/are important for TCP connections that/

s/break prevent/prevent/

appendix A: "the workaround in RFC 1337" - can you be more specific?

[Ballot comment]
The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP
  to include a timestamp value in its segments, that can be used to

s/TCP/TCP implementation/?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Reducing the TIME-WAIT state using TCP timestamps) to BCP


The IESG has received a request from the TCP Maintenance and Minor
Extensions WG (tcpm) to consider the following document:
- 'Reducing the TIME-WAIT state using TCP timestamps'
  as a BCP

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 2010-12-07. 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.

*** Note: *** This document has a downward reference to RFC 1337.
Please comment during the last call on the appropriateness of
this downref.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-timestamps/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-timestamps/

draft-ietf-tcpm-tcp-timestamps
 


  (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?


Wesley Eddy (Wesley.M.Eddy@nasa.gov) 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 has had review in the TCPM working group, and underwent
several revisions based on mailing list discussion prior to becoming
a working group draft.  Some comments were received during working
group last call which were sufficiently addressed.  The depth and
breadth of reviews has been appropriate for the scope of the draft.


  (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 has been a reasonable amount of support from several individuals for
this document.  There has not been recent resistance to any of the document's
current content, which was reduced when it was clear that some additional
content (when it was still an individual submission) did not have consensus.



  (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 a few IDNITS errors which appear to be a mix of spurious and
non-worrisome.  One such case is the reported down-ref to RFC 1337,
which is used as Normative here because it should be read and understood
in understanding this BCP, even though 1337 it is marked Informational
in the RFC Editor database.  This shepherd thinks this is consistent
with the spirit of RFC 3967 which allows downrefs in BCPs to
Informational documents.


  (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 describes an algorithm for processing incoming SYN
  segments that allows higher connection-establishment rates between
  any two TCP endpoints when a TCP timestamps option is present in the
  incoming SYN segment.  This document only modifies processing of SYN
  segments received for connections in the TIME-WAIT state; processing
  in all other states is unchanged.


    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?

Nothing exceptional occurred during the working group process for this
document.


    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?

Implementations of the technique described in this document have been
implemented for some time.  The document specifically cites the Linux
kernel's TCP implementation, though there are others as well.  One
reason for completing this document is to bring this practice to the
RFC series so that it can be captured for other implementations.