lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Mon, 27 Jan 2020 05:48:30 -0800
From:   Stephen Hemminger <>
Subject: Fw: [Bug 206319] New: ECN header flag processing overly restrictive
 in TCP

Begin forwarded message:

Date: Mon, 27 Jan 2020 08:15:36 +0000
Subject: [Bug 206319] New: ECN header flag processing overly restrictive in TCP

            Bug ID: 206319
           Summary: ECN header flag processing overly restrictive in TCP
           Product: Networking
           Version: 2.5
    Kernel Version: HEAD
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Other
        Regression: No

RFC3168 states, that a CWR flag "SHOULD" be *sent* together with a new data

However, linux is processing the CWR flag as data receiver ONLY when it arrives
together with some data (but apparently does accept it on retransmissions).

This has been found to be an interoperability issue with *BSD, where the CWR is
sent as quickly as possible, including on pure ACKs (or retransmissions) so
far. That deviation from RFC3168 there is reported at

Nevertheless, CWR processing as receiver should be less restrictive, to meet
the sprit of Postels Law: "Be liberal in what you accept, and conservative in
what you send."

This has been demonstrated to be a dramatic performance impediment, as the data
receiver (linux) keeps the ECE latched, while *BSD interprets the additional
ECE flags as another round of congestion. To which the data sender reacts by
continous reductions of the congestion window until extremely low packet
transmission rates (1 packet per delayed ACK timeout, or even persist timeout
(5s) are hit, and kept at that level for extensive periods of time.

Discussed this issue with Neal and Yuchung already, this bug report is to track
the issue in the field (impacted environments).

You are receiving this mail because:
You are the assignee for the bug.

Powered by blists - more mailing lists