Re: ECN & cisco firewall
Dave, et. al., At 05:56 08/09/00, David S. Miller wrote: .. >in the Cisco PIX case does the firewall send a reset .. a bug ticket has been opened for the cisco pix firewall and [lack-of] TCP ECN inter operability. the developers know about the issue, and i'm sure that a fix will be forthcoming in a future interim release. back to linux kernel issues, cheers, lincoln. -- Lincoln Dale Content Services Business Unit [EMAIL PROTECTED] cisco Systems, Inc. | | |||| +1 (408) 525-1274 bldg G, 170 West Tasman +61 (3) 9659-4294 << San Jose CA 95134..:||:..:||:.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN & cisco firewall
On Sat, Sep 09, 2000 at 03:38:26AM -0700, David S. Miller wrote: >Date: Sat, 9 Sep 2000 12:32:34 +0200 >From: Jamie Lokier <[EMAIL PROTECTED]> > >So our TCP stack can observe this and say "ah, that route doesn't >do ECN; let's retry without ECN and see if we get a better >response". > > This might work. Although, a tougher case to handle are the > firewalls which just silently drop the packet if ECN bits are > set. The timeout is just too long to make a "backdown and try > withough ECN" scheme worthwhile in that case. It is just the same thing as pmtu blackhole detection, and very hard to get right. I tried to implement a good scheme for pmtu blackhole detection for linux, but failed. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN & cisco firewall
Date:Sat, 9 Sep 2000 12:32:34 +0200 From: Jamie Lokier <[EMAIL PROTECTED]> So our TCP stack can observe this and say "ah, that route doesn't do ECN; let's retry without ECN and see if we get a better response". This might work. Although, a tougher case to handle are the firewalls which just silently drop the packet if ECN bits are set. The timeout is just too long to make a "backdown and try withough ECN" scheme worthwhile in that case. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN & cisco firewall
Jamie Lokier <[EMAIL PROTECTED]> writes: > Now, for how to deal with firewalls that block ECN. Perhaps it's a > _good_ thing that they send RSTs. Not all of them do. For example, attempting to access www.tesco.com with ECN enabled produces no response at all to the SYN packets, it looks as though they are being silently discarded. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN & cisco firewall
Graham Murray wrote: > "David S. Miller" <[EMAIL PROTECTED]> writes: > > > The authors of rfc793 probably, in all honesty, really meant > > "must be set to zero by current implementations". > > I agree, to me it seems obvious that the reason is so that these bits > could be used at some time in the future for some, then unknown, > purpose. Now that RFC 2481 has defined the bits, only implementations > which grok and support ECN should be setting these bits, older > implementations will (following RFC793) set them to zero and thus old > and new implementations should correctly interwork. The RFC 793 authors really should have stated that non-zero bits on incoming packets are reserved for future protocol extensions, and should be silently accepted and ignored. RFC 793 predates modern firewalls AFAIK. There just wasn't a need for protection from things like DDOS's, teardrop etc. Now, for how to deal with firewalls that block ECN. Perhaps it's a _good_ thing that they send RSTs. Presumably the RSTs don't have ECN bits set. So our TCP stack can observe this and say "ah, that route doesn't do ECN; let's retry without ECN and see if we get a better response". -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN & cisco firewall
"David S. Miller" <[EMAIL PROTECTED]> writes: > The authors of rfc793 probably, in all honesty, really meant > "must be set to zero by current implementations". I agree, to me it seems obvious that the reason is so that these bits could be used at some time in the future for some, then unknown, purpose. Now that RFC 2481 has defined the bits, only implementations which grok and support ECN should be setting these bits, older implementations will (following RFC793) set them to zero and thus old and new implementations should correctly interwork. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN & cisco firewall
> > sites which RST these ECN carrying packets are the ones which disturb > > me the most, in the Cisco PIX case does the firewall send a reset > > So, how would properly written pre-ECN software indicate > rejection of packets with the unknown ECN flag? By leaving the bits as zero - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN & cisco firewall
David S. Miller writes: >From: Ulrich Kiermayr <[EMAIL PROTECTED]> > > Reserved: 6 bits > > Reserved for future use. Must be zero. > > >The point is: 'must be zero' is redefined by rfc2481 (ECN). > > The authors of rfc793 probably, in all honesty, really meant > "must be set to zero by current implementations". > > Even though they did not say this, several pages later they bestow > upon us the concept of being liberal in what one accepts. Perhaps To be "liberal in what one accepts" you get rid of firewalls. The whole point of a firewall is to be conservative. > sites which RST these ECN carrying packets are the ones which disturb > me the most, in the Cisco PIX case does the firewall send a reset So, how would properly written pre-ECN software indicate rejection of packets with the unknown ECN flag? > That's a really anal, zero purpose, check to put into a firewall. > I don't know of even any embedded printer stacks that puke when > the reserved flag bits are non-zero. The only things this protects > anyone from are extensions such as ECN :-) Who knows what attacks might be done with future extensions? Your firewall is buggy if it passes strange packets. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN & cisco firewall
> > the reserved flag bits are non-zero. The only things this protects > > anyone from are extensions such as ECN :-) > > To be fair even older netfilter had the same problem (ipt_unclean would > complain about the reserved bits). It is probably a common bug. The current British Standard kitemark for a firewall appears to require the bug 8) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN & cisco firewall
On Fri, Sep 08, 2000 at 02:56:59AM -0700, David S. Miller wrote: > That's a really anal, zero purpose, check to put into a firewall. > I don't know of even any embedded printer stacks that puke when > the reserved flag bits are non-zero. The only things this protects > anyone from are extensions such as ECN :-) To be fair even older netfilter had the same problem (ipt_unclean would complain about the reserved bits). It is probably a common bug. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN & cisco firewall
On Fri, 8 Sep 2000, David S. Miller wrote: > The authors of rfc793 probably, in all honesty, really meant > "must be set to zero by current implementations". Thats often the problem when interpretations are possible: Different people see the meaning differently. > Even though they did not say this, several pages later they bestow > upon us the concept of being liberal in what one accepts. Perhaps > Cisco PIX firewall engineers missed this paragraph. :-) Also, there > is not one part of the packet parsing steps they describe which says > "if any reserved flag bits are non-zero, drop packet" or "reset" (the > sites which RST these ECN carrying packets are the ones which disturb > me the most, in the Cisco PIX case does the firewall send a reset > back?). In case i havent sayed this clearly enough: It seems after several tests: the PIX itself sent the RST (blocking the connection) instead of letting the SYN pass to the actual host (behind the firewall) > That's a really anal, zero purpose, check to put into a firewall. > I don't know of even any embedded printer stacks that puke when > the reserved flag bits are non-zero. The only things this protects > anyone from are extensions such as ECN :-) Yeah, but we will see what cisco has to say about that LL&P Ulrich -- ,-, .-.,,--- | | / / |,---' Ulrich KiermayrInst. for Theoret. Physics, Univ. of Vienna | |/ /| ||_ eMail: [EMAIL PROTECTED]PGP Key ID: 0xA8D764D8 | ( | | _:ICQ: 17858333 Web: http://www.thp.univie.ac.at/~kie | |\ \| || @Home: Dampierrestr. 4/5, A-1140 Vienna; +43(699)19671909 | | \ \ |`---, @Work: Boltzmanngasse 5, A-1090 Vienna; +43(1)4277/51555 `-' `-'''--- System going down at 5 this afternoon to install scheduler bug. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN & cisco firewall
Date: Fri, 8 Sep 2000 11:42:54 +0200 (CEST) From: Ulrich Kiermayr <[EMAIL PROTECTED]> Reserved: 6 bits Reserved for future use. Must be zero. The point is: 'must be zero' is redefined by rfc2481 (ECN). The authors of rfc793 probably, in all honesty, really meant "must be set to zero by current implementations". Even though they did not say this, several pages later they bestow upon us the concept of being liberal in what one accepts. Perhaps Cisco PIX firewall engineers missed this paragraph. :-) Also, there is not one part of the packet parsing steps they describe which says "if any reserved flag bits are non-zero, drop packet" or "reset" (the sites which RST these ECN carrying packets are the ones which disturb me the most, in the Cisco PIX case does the firewall send a reset back?). That's a really anal, zero purpose, check to put into a firewall. I don't know of even any embedded printer stacks that puke when the reserved flag bits are non-zero. The only things this protects anyone from are extensions such as ECN :-) Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ECN & cisco firewall
Hello! Following a discussion about ECN and firewalls some days ago: We have the same problem here with several Cisco PIX Firewalls not handling ECN correctly. After a little research we think we know what is going wrong: The firewall checks the TCP-Header against rfc793. There it is stated for the Reserved Bits: Reserved: 6 bits Reserved for future use. Must be zero. The point is: 'must be zero' is redefined by rfc2481 (ECN). (The firewall-people at cisco do not seem to be fully aware of that yet.) The firewall sees a header violating rfc793 and considers it a bogous TCP packet. So it sends a RST instead of letting the connection pass. The problem is that this is not caused by misadministration of the firewall. It seems to be built into the Software. We already sent this issue to cisco (along with our sniffer logs) and are now waiting for a reply. :-) (Hopefully they will find a solution before kernels enabling ECN start do be widely distributed - in Mandrake 7.2beta it is already tha case.) LL&P Ulrich -- ,-, .-.,,--- | | / / |,---' Ulrich KiermayrInst. for Theoret. Physics, Univ. of Vienna | |/ /| ||_ eMail: [EMAIL PROTECTED]PGP Key ID: 0xA8D764D8 | ( | | _:ICQ: 17858333 Web: http://www.thp.univie.ac.at/~kie | |\ \| || @Home: Dampierrestr. 4/5, A-1140 Vienna; +43(699)19671909 | | \ \ |`---, @Work: Boltzmanngasse 5, A-1090 Vienna; +43(1)4277/51555 `-' `-'''--- They are relatively good but absolutely terrible. -- Alan Kay, commenting on Apollos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
