TCP/IP connection setup using ECN: interaction with firewall problems

From: Olaf Dabrunz (Olaf.Dabrunz@gmx.de)
Date: Mon Aug 12 2002 - 19:19:44 EST


Hello all,

I am using the explicit congestion notification feature by switching it on
with "echo 1 >/proc/sys/net/ipv4/tcp_ecn". Usually this works fine. But
there are certain hosts whose firewalls consider the ECN flags to be an
indicator for a scan or attack. This (mis-)behaviour has also been
described in the standards track protocol definition for ECN, RFC 3168.

Though the firewalls are the faulty components (see RFC 3168), my
experience with similar problems (server-side firewalls that drop all ICMP
packets, causing a loss of service to clients with a smaller MTU than the
server) has shown that these kinds of firewall problems are difficult to
overcome on the firewall configuration side (it seems this is due to lack
of time and/or problem-awareness of the administrators).

In order to still work together with such hosts, RFC 3168 section 6.1.1.1
suggests a change in behaviour of the ECN-capable clients. It states that

   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.

Also, in case the firewall responds to an ECN-setup SYN by sending a
packet with the RST flag set, it states that

   [...] 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.

I actually experience the first problem stated above. The tpcdump trace
below shows what happens when I try to connect to www.nvidia.com.

19:10:37.192791 123.45.67.89.34342 > 209.213.198.80.http: S [ECN-Echo,CWR] 2222688860:2222688860(0) win 5808 <mss 1452,sackOK,timestamp 15670700,nop,wscale 0> (DF)
19:10:40.183059 123.45.67.89.34342 > 209.213.198.80.http: S [ECN-Echo,CWR] 2222688860:2222688860(0) win 5808 <mss 1452,sackOK,timestamp 15673700,nop,wscale 0> (DF)
19:10:46.183270 123.45.67.89.34342 > 209.213.198.80.http: S [ECN-Echo,CWR] 2222688860:2222688860(0) win 5808 <mss 1452,sackOK,timestamp 15679700,nop,wscale 0> (DF)
19:10:58.183715 123.45.67.89.34342 > 209.213.198.80.http: S [ECN-Echo,CWR] 2222688860:2222688860(0) win 5808 <mss 1452,sackOK,timestamp 15691700,nop,wscale 0> (DF)

AFAICS from the kernel ChangeLogs Linux versions 2.4.* and 2.5.* do not
implement the interoperability features described above. Is that correct?
Is someone working on a patch that implements these features?

Thanks, Olaf.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Aug 15 2002 - 22:00:30 EST