[tcpm] Comments on draft-blanton-tcpm-3517bis-01

[Ethan Blanton <[e-mail]>]

Hi all,

The 3517bis -01 is out, and available here:

    http://www.ietf.org/id/draft-blanton-tcpm-3517bis-01.txt

We believe that we have addressed all of the concerns with -00 in this
document, and that it is ready for last call.  A quick rundown of the
concerns which came up in -00 and their related changes (or the
reasoning behind not changing anything) follows.

* Matt Mathis brought up a concern with the quoted requirement from
  RFC 2018 that SACK information MUST be discarded following an RTO.
  There is an Errata on 2018 (also by Matt) addressing this.  We were
  not comfortable updating 2018 "on the side" as it were, so rather
  than change the quoted recommendation, we added some text explaining
  that this issue has been reconsidered, that there is an Errata on
  the subject, and that implementors should find out what the state of
  affair is when implementing.  Section 5.1 paragraph 1 now reads:

   In order to avoid memory deadlocks, the TCP receiver is allowed to
   discard data that has already been selectively acknowledged.  As a
   result, [RFC2018] suggests that a TCP sender SHOULD expunge the SACK
   information gathered from a receiver upon a retransmission timeout
   "since the timeout might indicate that the data receiver has
   reneged."  Additionally, a TCP sender MUST "ignore prior SACK
   information in determining which data to retransmit."  However, since
   the publication of [RFC2018] this has come to be viewed by some as
   too strong.  It has been suggested that, as long as robust tests for
   reneging are present, an implementation can retain and use SACK
   information across a timeout event [Errata1610].  While this document
   does not change the specification in [RFC2018], we note that
   implementers should consult any updates to [RFC2018] on this subject.
   Further, a SACK TCP sender SHOULD utilize all SACK information made
   available during the slow start phase of loss recovery following an
   RTO.

* Richard Scheffenegger brought up an end-of-window loss corner case
  which RFC 3517 loss recovery does not handle as aggressively as
  NewReno, potentially leading to RTO.  While the problem itself is
  well-understood, our read of the consensus is that the suggestions
  put forth to mitigate it are not.  Since 3517 is standards track and
  mature, no changes were made to the document regarding end-of-window
  losses.

* There has been ongoing discussion regarding TCP security in relation
  to Fernando's draft.  One of the bullets in that draft involves a
  blind out-of-window attack which can cause a sender to mistakenly
  infer loss in the absence of SACK.  A note was added to security
  considerations to hilight this robustness when DupACKs are properly
  accounted:

   Similarly, [CPNI309] sketches a variant of a blind attack [RFC5961]
   whereby an attacker can spoof out-of-window data to a TCP endpoint,
   causing it to respond to the legitimate peer with a duplicate
   cumulative ACK, per [RFC793].  Adding a SACK-based requirement to
   trigger loss recovery effectively mitigates this attack, as the
   duplicate ACKs caused by out-of-window segments will not contain SACK
   information indicating reception of previously un-SACKED in-window
   data.

* The "Changes Relative to RFC 3517" section has been clarified
  editorially.

* Despite the IETF/IESG joint commitment to making submission of I-Ds
  as painful as possible, we negotiated the boilerplate minefield and
  updated the text and formatting of the draft *just so* to convince
  the automated tools to accept it.

Thanks,
Ethan