RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (1)

RFC 5961, "Improving TCP's Robustness to Blind In-Window Attacks", August 2010

Source of RFC: tcpm (tsv)

Errata ID: 4845

Status: Verified
Type: Technical

Reported By: Michael Tüxen
Date Reported: 2016-10-27
Verifier Name: Mirja Kühlewind
Date Verified: 2016-10-31

Section 3.2 says:

   1) If the RST bit is set and the sequence number is outside the
      current receive window (SEG.SEQ <= RCV.NXT || SEG.SEQ > RCV.NXT+
      RCV.WND), silently drop the segment.

It should say:

   1) If the RST bit is set and the sequence number is outside the
      current receive window (SEG.SEQ < RCV.NXT || SEG.SEQ >= RCV.NXT+
      RCV.WND), silently drop the segment.

Notes:

The condition should be the opposite of (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND), which is stated in the second item of the enumeration.

Status: Reported (1)

RFC 5961, "Improving TCP's Robustness to Blind In-Window Attacks", August 2010

Source of RFC: tcpm (tsv)

Errata ID: 5068

Status: Reported
Type: Technical

Reported By: Wesley Eddy
Date Reported: 2017-07-12

Section 3.2 says:

   [RFC0793] currently requires handling of a segment with the RST bit
   when in a synchronized state to be processed as follows:
...
   Instead, implementations SHOULD implement the following steps in
   place of those specified in [RFC0793] (as listed above).

It should say:

   [RFC0793] currently requires handling of a segment with the RST bit
   when in a synchronized state to be processed as follows:
...
   Instead, when in either a synchronized state or SYN-RECEIVED,
   implementations SHOULD implement the following steps in place of
   those specified in [RFC0793] (as listed above, for the synchronized
   states).  Note that transition from SYN-RECEIVED to either LISTEN or
   CLOSED and user signaling is still subject to whether the connection
   was originated by a passive OPEN (as described in RFC 793).

Notes:

The text in section 3.2 begins by stating a change from RFC 793 for RST bit handling "when in a synchronized state" (which means all states except for LISTEN, SYN-SENT, and SYN-RECEIVED). Later in the section, the same change is described more loosely and text states that it's applicable "In all states except SYN-SENT", and separate behavior is provided for SYN-SENT, but the earlier text leaves uncertainty if the former is supposed to apply to SYN-RECEIVED as well, since the earlier text in the section section begins by discussing only "synchronized" states.

Since the check is totally valid for SYN-RECEIVED, and the behavior in steps 1, 2, and 3 are valid for SYN-RECEIVED, it seems appropriate to make sure this is clarified in the earlier text.

Status: Held for Document Update (1)

RFC 5961, "Improving TCP's Robustness to Blind In-Window Attacks", August 2010

Source of RFC: tcpm (tsv)

Errata ID: 4772

Status: Held for Document Update
Type: Technical

Reported By: Stéphane Bortzmeyer
Date Reported: 2016-08-10
Held for Document Update by: Mirja Kühlewind
Date Held: 2016-09-12

Section 7 says:

[The entire section]

It should say:

No suggested text because it requires a much more serious analysis. 
May be adding that the rate-limit counter SHOULD be per-connection, 
in the spirit of RFC 6528?

Notes:

It appears the section does not specify that the counter for ACK throttling SHOULD be per-connection. In Linux, it is apparently global, which allowed its use as a side channel enabling nasty attacks (CVE-2016-5696 and the paper "Off-Path TCP Exploits: Global Rate Limit Considered Dangerous" <http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf>).
Also see discussion on tcpm list about this reported errata!

Report New Errata