[LEDE-DEV] [PATCH] firewall3: Enable TCP_ECN by default.

[Kevin Darbyshire-Bryant]

On 03/10/17 18:22, David Lang wrote:
> On Tue, 3 Oct 2017, Kevin Darbyshire-Bryant wrote:
> 
>> It's tempting to set it to 1 (like I have for the past year+) and be 
>> damned :-)
> 
> So what is the failure mode and how will people who experience failures 
> know what they need to change?
> 
> David Lang

I'd anticipate increased initial connection latency rather than complete 
failure, suggested by this extract from wiki:

Beginning with version 4.1 of the Linux kernel, released in June 2015, 
the tcp_ecn_fallback mechanism, as specified in RFC 3168 section 
6.1.1.1, is enabled by default when ECN is enabled (the value of 1). The 
fallback mechanism attempts ECN connectivity in the initial setup of 
outgoing connections, with a graceful fallback for transmissions without 
ECN capability, mitigating issues with ECN-intolerant hosts or firewalls.

https://tools.ietf.org/html/rfc3168


They'd need to add/change if absolutely necessary:

/etc/config/firewall

config defaults
	option tcp_ecn '2'  <--- from '1'


rfc extract:


6.1.1.1.  Middlebox Issues

    ECN introduces the use of the ECN-Echo and CWR flags in the TCP
    header (as shown in Figure 3) for initialization.  There exist some
    faulty firewalls, load balancers, and intrusion detection systems in
    the Internet that either drop an ECN-setup SYN packet or respond with
    a RST, in the belief that such a packet (with these bits set) is a
    signature for a port-scanning tool that could be used in a denial-
    of-service attack.  Some of the offending equipment has been
    identified, and a web page [FIXES] contains a list of non-compliant
    products and the fixes posted by the vendors, where these are
    available.  The TBIT web page [TBIT] lists some of the web servers
    affected by this faulty equipment.  We mention this in this document
    as a warning to the community of this problem.

    To provide robust connectivity even in the presence of such faulty
    equipment, a host that receives a RST in response to the transmission
    of an ECN-setup SYN packet MAY resend a SYN with CWR and ECE cleared.
    This could result in a TCP connection being established without using
    ECN.

    A host that receives no reply to an ECN-setup SYN within the normal
    SYN retransmission timeout interval MAY resend the SYN and any
    subsequent SYN retransmissions with CWR and ECE cleared.  To overcome
    normal packet loss that results in the original SYN being lost, the
    originating host may retransmit one or more ECN-setup SYN packets
    before giving up and retransmitting the SYN with the CWR and ECE bits
    cleared.

    We note that in this case, the following example scenario is
    possible:

    (1) Host A: Sends an ECN-setup SYN.
    (2) Host B: Sends an ECN-setup SYN/ACK, packet is dropped or delayed.
    (3) Host A: Sends a non-ECN-setup SYN.
    (4) Host B: Sends a non-ECN-setup SYN/ACK.

    We note that in this case, following the procedures above, neither
    Host A nor Host B may set the ECT bit on data packets.  Further, an
    important consequence of the rules for ECN setup and usage in Section
    6.1.1 is that a host is forbidden from using the reception of ECT
    data packets as an implicit signal that the other host is ECN-
    capable.