lkml.org 
[lkml]   [2002]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectTCP/IP connection setup using ECN: interaction with firewall problems
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/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.069 / U:1.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site