2018-01-23 17:53 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0014316CentOS-7kernelpublic2017-12-31 20:12
ReporterNonSecwitter 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
Product Version7.4.1708 
Target VersionFixed in Version 
Summary0014316: TCP_ECN not functioning
DescriptionFrom what I understand, ECN (Explicit Congestion Notification) should be functional from kernel version 2.4.20 forward. To be functional, the client and server must set specific TCP header flags during session establishment as follows:

1) The initiator sets [ECE] and [CWR] in the initiating [SYN] packet as an indication of being ECN capable.

2) If the remote end is ECN capable, it sets _ONLY_ the [ECE] flag in the [SYN]/[ACK] response.

ECN settings are in /proc/sys/net/ipv4/tcp_ecn according to the following options:

tcp_ecn - INTEGER
    Control use of Explicit Congestion Notification (ECN) by TCP.
    ECN is used only when both ends of the TCP connection indicate
    support for it. This feature is useful in avoiding losses due
    to congestion by allowing supporting routers to signal
    congestion before having to drop packets.
    Possible values are:
        0 Disable ECN. Neither initiate nor accept ECN.
        1 Enable ECN when requested by incoming connections and
          also request ECN on outgoing connection attempts.
        2 Enable ECN when requested by incoming connections
          but do not request ECN on outgoing connections.
    Default: 2

I have confirmed one fresh install across the public Internet, one fresh install on the LAN and an active webserver known to run CentOS 7. Whether set to (1) or (2) the remote system is not responding with [ECE] set in the [SYN]/[ACK] packet.
Steps To ReproduceTo verify tcp_ecn configuration state:
sudo cat /proc/sys/net/ipv4/tcp_ecn

Can be set by:
sudo sysctl -w net.ipv4.tcp_ecn=2

Once verified/set packet captures show that remote CentOS 7 host does not respond with [ECE] set when initiating client sets [ECE] and [CWR]
Additional InformationRFC 3168 Section 6.1.1 detailing connection establishment with ECN
https://tools.ietf.org/html/rfc3168#page-14

TCP kernel documentation where tcp_ecn options can be found
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

Tagsnetwork, tcp, tcp_ecn
abrt_hash
URL
Attached Files

-Relationships
+Relationships

-Notes

~0030838

NonSecwitter (reporter)

Example of proper session initialization (unknown server OS):
1254 14.215287 x.x.x.x 192.225.158.30 TCP 66 57682 → 443 [SYN, ECN, CWR]
1257 14.290859 192.225.158.30 x.x.x.x TCP 74 443 → 57680 [SYN, ACK, ECN]

Example of workstation to CentOS server session initialization:
13 0.706130 x.x.x.x 50.201.169.2 TCP 66 57711 → 443 [SYN, ECN, CWR]
16 0.725670 50.201.169.2 x.x.x.x TCP 66 443 → 57711 [SYN, ACK]

~0030839

NonSecwitter (reporter)

The "ECN Capable Transport" field in the IP header is also set to 0.

(Same CentOS server from the previous note)

Internet Protocol Version 4, Src: 50.201.169.2, Dst: x.x.x.x
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
+Notes

-Issue History
Date Modified Username Field Change
2017-12-31 19:40 NonSecwitter New Issue
2017-12-31 19:40 NonSecwitter Tag Attached: network
2017-12-31 19:40 NonSecwitter Tag Attached: tcp
2017-12-31 19:40 NonSecwitter Tag Attached: tcp_ecn
2017-12-31 19:50 NonSecwitter Note Added: 0030838
2017-12-31 20:12 NonSecwitter Note Added: 0030839
+Issue History