On Sun, 5 Nov 2000, Michael Richardson wrote:
>
> It would be good if any experiences with this, in particular, sites
> involved could be summarized. Is this a bug in the ECN, or is this due to
> buggy remote implementations. The ECN WG, and I think Jamal who implemented
> this (?) would want to know about deployment problems.
>
Sorry for the lengthy reply.
Dax Kelson <dax@xxxxxxxxxxxx> did extensive tests with Linux on the net to
try and isolate which sites were anti-ECN. Those tests were repeated by
J Padhye<jitu@xxxxxxxx>. You can look at the results at:
http://www.aciri.org/tbit/ecn.daxlist.txt.gz
There actually has been a lot of activity happening ....
And infact, we (Linux), have greatly influenced the way the RFC is
evolving. If the (old) IETF moto of "we believe in running code .."
is alive then you just need to look at ECN and Linux (to appreciate Dave
Clark's wisdom).
ECN is going to move from Experimental to Standard soon.
* The problem are so far pointing to firewalls, content switches/ load
balancers, and intrusion detection systems which block the two ECN bits
in the TCP header.
The old RFCs defined the two ECN bits as "reserved".
English, as any other natural language, is ambigous. However translating
that to mean "not allowed" beats me.
Summary: these boxes which block ECN are broken.
Summary 2: we know that these broken boxes exist. What do you do about it?
Certainly, Linux users opening problem reports to the vendors helps a
lot. The vendors listen to their customers. There is going to be 'noise'
at the IETF on this as well.
There are several behaviors we have seen so far from these boxes:
1) send a RST to SYN with ECN enabled bits
Some of the positively Id-ed boxes which do this:
- CISCOs PIX firewall and CISCOs local director
--- CISCO has acted very positively and fixed this problem.
>From a posting by Dax:
http://marc.theaimsgroup.com/?l=linux-kernel&m=97154562227096&w=1
Not sure how many sites have deployed the fix.
2) They just swallow the SYN ;-<
Positively Id-ed in this category are Raptor firewalls.
- I am pursuing this since my workplace uses Raptor firewalls.
3) some smart-ass intrusion detection systems eg article at:
http://www.securityfocus.com/frames/?focus=ids&content=/focus/ids/articles/portscan.html
titled "Intrusion Detection Level Analysis of Nmap and Queso"
claims:
"[QUESO] is easy to identify, if you see [these two Reserved bits and the
SYN bit] set in the 13th byte of the TCP header, you know that someone has
malicious intentions for your network."
Now imagine how many intrusion detection systems are lsitening to that
opinion and infact using it to block ECN packets.
4) According to Sally's web page:
AIX 4.3.2.0-4.3.3.0, IRIX 6.2- 6.5, Solaris 2.6 - 2.7,
or Linux 2.1.122 - 2.2.14 of possible systems (as id-ed by nmap) that
might be causing this.
I know that old netfilter/ipchains has these problems. I doubt if it was
anywhere around Linux 2.1.122 - 2.2.14; maybe someone could clarify.
I doubt very much if these systems were running as servers; they were
probably configured as firewalls.
Summary3: We have to do something about this if ECN is to be deployed.
So far there is a proposal by Sally Floyd and company which neither Alexey
nor Davem are thrilled about. I know i am not.
Hopefully, this clears some air.
cheers,
jamal
|