netdev - Fw: [Bug 206319] New: ECN header flag processing overly restrictive in TCP

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <20200127054830.53973d51@hermes.lan>
Date:   Mon, 27 Jan 2020 05:48:30 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     netdev@...r.kernel.org
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
From: bugzilla-daemon@...zilla.kernel.org
To: stephen@...workplumber.org
Subject: [Bug 206319] New: ECN header flag processing overly restrictive in TCP

https://bugzilla.kernel.org/show_bug.cgi?id=206319

            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
          Assignee: stephen@...workplumber.org
          Reporter: rscheff@....at
        Regression: No

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

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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243231

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.