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

Message ID 20171003071648.5539-1-rosenp@gmail.com
State New
Headers show
Series
  • [LEDE-DEV] firewall3: Enable TCP_ECN by default.
Related show

Commit Message

Rosen Penev Oct. 3, 2017, 7:16 a.m.
ECN is used by fq_codel and other AQMs. Kernel 4.2 added a fallback in case of failure, so adjust to kernel default.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 defaults.c | 1 +
 1 file changed, 1 insertion(+)

Comments

Kevin Darbyshire-Bryant Oct. 3, 2017, 8:03 a.m. | #1
On 03/10/17 08:16, Rosen Penev wrote:
> ECN is used by fq_codel and other AQMs. Kernel 4.2 added a fallback in case of failure, so adjust to kernel default.

The kernel default is 2, which is what you've set the firewall3 default 
to be now as well.  2 accepts ECN on incoming connections but does NOT 
request it on outbound connections.  Therefore the fallback mechanism 
you mention doesn't actually come in to play at all.

Setting the value to '1' permits linux to attempt ECN on both incoming 
and outgoing connections to/from the router itself (and uses the 
fallback mechanism)

It's tempting to set it to 1 (like I have for the past year+) and be 
damned :-)




> 
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
>   defaults.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/defaults.c b/defaults.c
> index 85a3750..68e40f5 100644
> --- a/defaults.c
> +++ b/defaults.c
> @@ -90,6 +90,7 @@ fw3_load_defaults(struct fw3_state *state, struct uci_package *p)
>   
>   	defs->syn_flood_rate.rate  = 25;
>   	defs->syn_flood_rate.burst = 50;
> +	defs->tcp_ecn		   = 2;
>   	defs->tcp_syncookies       = true;
>   	defs->tcp_window_scaling   = true;
>   	defs->custom_chains        = true;
>
David Lang Oct. 3, 2017, 5:22 p.m. | #2
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
Kevin Darbyshire-Bryant Oct. 5, 2017, 2:26 p.m. | #3
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.

Patch

diff --git a/defaults.c b/defaults.c
index 85a3750..68e40f5 100644
--- a/defaults.c
+++ b/defaults.c
@@ -90,6 +90,7 @@  fw3_load_defaults(struct fw3_state *state, struct uci_package *p)
 
 	defs->syn_flood_rate.rate  = 25;
 	defs->syn_flood_rate.burst = 50;
+	defs->tcp_ecn		   = 2;
 	defs->tcp_syncookies       = true;
 	defs->tcp_window_scaling   = true;
 	defs->custom_chains        = true;