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.
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
