Re: ECN and ISOC: request for help...
I found the problem when coming back from Inet2002 and alerted Lynn and Anne. It was the first time they heard about it, they told me... (between us I don care who found it first... does it really matter?) Now, if someone alerted them before, and they forgot about it. I worried that they (or anybody) will ever get arround to fix this problem at least in ISOC. Imagine other places, how hard it will be, if even ISOC with the full backing of IETF cannot do it? And the band played on Cheers Franck On Thu, 2002-07-25 at 20:09, Brian E Carpenter wrote: P.S. Credit where credit is due: it was Ted who first detected and reported this problem with ISOC's mail service provider, during the NomCom process.
RE: ECN and ISOC: request for help...
I don't see why this is embarrasing. I have no problems with people setting up filtering rules that say DENY-ALL accept packets that I EXPLICITLY know what every bit does, and I want to allow it... That said, ECN is a relatively recent addition to the suite and I wouldn't expect all firewalling rules to be setup to use it (I believe that some of the bits involved have been used by other experimental protocols for other things). For this reason I don't think this behavior is as bad or embarrassing as you think it is. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Franck Martin Sent: Tuesday, July 23, 2002 10:17 PM To: 'Gary E. Miller'; Christian Huitema Cc: ietf Subject: RE: ECN and ISOC: request for help... I'm not in a campaign to promote ECN, or anything... I'm saying that ISOC web site is not reachable if you enable ECN, which RFC793(standard) or RFC3168(proposed Standard) talk about. I don't want to talk about what is a standard or what is not... What is compliant or not... Will there be anybody to volunteer and fix the routers leading to ISOC web site, mailing lists, e-mail addresses and so on? This is what my message is all about. Please IETF members in Washington DC, Area, please give a call to ISOC and offer some help... This is embarrassing, that's all Cheers. Franck Martin Network and Database Development Officer SOPAC South Pacific Applied Geoscience Commission Fiji E-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Web site: http://www.sopac.org/ http://www.sopac.org/ Support FMaps: http://fmaps.sourceforge.net/ http://fmaps.sourceforge.net/ Certificate: https://www.sopac.org/ssl/ This e-mail is intended for its addresses only. Do not forward this e-mail without approval. The views expressed in this e-mail may not be necessarily the views of SOPAC. -Original Message- From: Gary E. Miller [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 24 July 2002 3:02 To: Christian Huitema Cc: ietf Subject: RE: ECN and ISOC: request for help... Yo Christian! Actually, RFC 3168 has nothing to do with it. The issue is RFC 793. RFC 793 is a Standard, not a Proposed Standard RFC 793 lists the bits later used by ECN as Reserved. Computer programs are supposed to ignore Reserved bits unless they really know what they are doing. If a router treats bits in the header as required by the STANDARD RFC 793 then RFC 3168 will cause no harm.I do not have a copy of Baker handy, but I bet it agrees. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 On Tue, 23 Jul 2002, Christian Huitema wrote: So, if you are on a campaign to promote ECN, then maybe you should first try to promote this specification to the next standard level... You may also want to take a stab at revising the Requirements for IP Version 4 Routers; the last edition, RFC 1812 by Fred Baker, dates from June 1995.
RE: ECN and ISOC: request for help...
At 01:16 AM 7/24/2002, Franck Martin wrote: I'm not in a campaign to promote ECN, or anything... I'm saying that ISOC web site is not reachable if you enable ECN, which RFC793(standard) or RFC3168(proposed Standard) talk about. I don't want to talk about what is a standard or what is not... What is compliant or not... Will there be anybody to volunteer and fix the routers leading to ISOC web site, mailing lists, e-mail addresses and so on? RFC3168 is dated September 2001. That's pretty recent. It is likely many routers have not even been rebooted since then, let alone been updated to new software revisions. Assuming a new software revision is available that supports ECN, that new revision would have to be tested and qualified before being deployed. Sites which insist on ECN will be disappointed for a long time to come. That said, such routers really shouldn't choke on the packets. I would guess it's dropping the packets due to explicit configuration, though. - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com
Re: ECN and ISOC: request for help...
Franck, ISOC knows about this, but you actually need to contact ISOC's ISP. But frankly it's a quixotic mission; SMTP mailers that break when they find a non-ECN-tolerant SMTP peer are likely to encounter trouble for some years to come. The issue here is that there is a MAY in RFC 3168 that IMHO should be a SHOULD. That's the first MAY in section 6.1.1.1. If your ECN code implemented that MAY, you would not have seen a problem. Brian Franck Martin wrote: In its great wisdom, the IETF has divised a system to control congestion over the Internet called ECN [RFC3168], unfortunately there are still some routers out there which are Explicit Congestion Notification (ECN) broken: http://urchin.earth.li/cgi-bin/ecn.pl One of this router leads to the ISOC web site. what is funny is to see the above RFC is copyright ISOC. Could someone located in the Washington DC area please contact the ISOC people and help them to be RFC compliant... I have highlighted to ISOC the problem, they are aware, but understaffed and this is a little bit tricky, but it should be a piece of cake for the IETF members. More info on ECN: http://urchin.earth.li/ecn/ http://www.icir.org/floyd/ecn.html http://www.rfc-editor.org/rfc/rfc3168.txt Franck Martin Network and Database Development Officer SOPAC South Pacific Applied Geoscience Commission Fiji E-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Web site: http://www.sopac.org/ http://www.sopac.org/ Support FMaps: http://fmaps.sourceforge.net/ http://fmaps.sourceforge.net/ Certificate: https://www.sopac.org/ssl/ This e-mail is intended for its addresses only. Do not forward this e-mail without approval. The views expressed in this e-mail may not be necessarily the views of SOPAC.
Re: ECN and ISOC: request for help...
On Wed, 24 Jul 2002, Brian E Carpenter wrote: Franck, ISOC knows about this, but you actually need to contact ISOC's ISP. But frankly it's a quixotic mission; SMTP mailers that break when they find a non-ECN-tolerant SMTP peer are likely to encounter trouble for some years to come. The issue here is that there is a MAY in RFC 3168 that IMHO should be a SHOULD. That's the first MAY in section 6.1.1.1. If your ECN code implemented that MAY, you would not have seen a problem. That hack was never added to the Linux implementation (dont think you will *ever* see it as part of the Linux TCP code). I am glad we did that: almost all the net sites that had anything to do with fixing their broken boxes to date have had admins who got emails from someone using Linux who told them their site was broken. I dont know what Franck uses but i am willing to bet it is Linux. On the issue of I should be allowed to block whatever bits i want, i would say if you block ECN you will hear from some rabid Linux user ;- On a serious note, you can block whatever you want but you should be able to do so on a policy basis: Most of the broken boxen dont provide the admin the option to allow ECN bits (instead hard-coded to drop). And if you had the option and choose and still decide to drop, its almost as helpful as blocking all ICMP packets. cheers, jamal
RE: ECN and ISOC: request for help...
Yo Daniel! On Wed, 24 Jul 2002, Daniel Senie wrote: RFC3168 is dated September 2001. That's pretty recent. RFC 793 is dated September 1981. If the routers/firewalls handled packets per RFC 793 there would be no problem. Just set them to zero and pass them along. The reserved bits were first used for ECN in RFC 2481 dated January 1999. If the firewalls handled packets per RFC 2481 there would be no problem. RFC 3168 refined the handling of ECN in September 2001. If the firewalls handled packets per RFC 3168 there would be no problem. It is only those router/firewalls that IGNORED all advice on what to do with those bits since 1981 that have a problem. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676
RE: ECN and ISOC: request for help...
In regards to all comments. Yes I'm using linux 2.4.x, and I'm disabling linux to handle ECN, because there is too much trouble with important organisations we are working with. I gave early an URL that lists some of these organisations like some important departments of the US government Please stop arguing on how a router should handle bits. There is a problem here ISOC or ISOC's ISP has some broken routers (we all agree on that?) and they need to be fixed. Who will help to fix it? I have highlighted the problem to ISOC, Lynn and Anne, but it is a little bit technical for ISOC (hmm???) and I'm too far away to be of any help (I'm in Fiji), so someone has to do the next bit: find out which router is broken and call the manager of the router and propose him a solution... During this time the band played on. Franck Martin Network and Database Development Officer SOPAC South Pacific Applied Geoscience Commission Fiji E-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Web site: http://www.sopac.org/ http://www.sopac.org/ Support FMaps: http://fmaps.sourceforge.net/ http://fmaps.sourceforge.net/ Certificate: https://www.sopac.org/ssl/ This e-mail is intended for its addresses only. Do not forward this e-mail without approval. The views expressed in this e-mail may not be necessarily the views of SOPAC.
RE: ECN and ISOC: request for help...
Please stop arguing on how a router should handle bits. There is a problem here ISOC or ISOC's ISP has some broken routers (we all agree on that?) and they need to be fixed. best to call the net police immediately randy
Re: ECN and ISOC: request for help...
On Wed, Jul 24, 2002 at 10:32:22AM +0200, Brian E Carpenter wrote: The issue here is that there is a MAY in RFC 3168 that IMHO should be a SHOULD. That's the first MAY in section 6.1.1.1. If your ECN code implemented that MAY, you would not have seen a problem. Nope, not true. The problem is most of the problematic firewalls silently drop SYN packets without sending an RST. So simply implementing the first MAY does little good. The second MAY addresses that concern, but it adds a large amount of complexity, because you have to deal with situations where one of the packets are lost, and what happens if one side retransmits while the otherside retries the SYN without the ECN bits. The discussion in RFC 3168 is incomplete about whether the SYN packet which is retransmitted without the ECN bit needs to be done with a new set of sequence numbers, and how to make sure both sides don't end up with a conflicting idea of whether or not ECN is enabled. It certainly increases the complexity of the TCP state transition diagram to implement the second MAY, and the rules of how it should work are not fully specified --- there is a lot of hand-waving going on there. There is also the question of whether this kind of complexity should be added, when arguably the firewalls involved are broken. At the very least, they violate the internet dictum of being liberal in what you accept --- with no security benefit whatsoever. Furthermore, it should be noted that as far as I know, all of these broken firewalls have updated firmware which fix the problem. The issue is getting the firmware updated. (And not surprisingly, all of the commercial e-comerce sites have this bug fixed for a very long time. It's the non-profit sites which have been lame.) - Ted
RE: ECN and ISOC: request for help...
Yo Christian! Actually, RFC 3168 has nothing to do with it. The issue is RFC 793. RFC 793 is a Standard, not a Proposed Standard RFC 793 lists the bits later used by ECN as Reserved. Computer programs are supposed to ignore Reserved bits unless they really know what they are doing. If a router treats bits in the header as required by the STANDARD RFC 793 then RFC 3168 will cause no harm.I do not have a copy of Baker handy, but I bet it agrees. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 On Tue, 23 Jul 2002, Christian Huitema wrote: So, if you are on a campaign to promote ECN, then maybe you should first try to promote this specification to the next standard level... You may also want to take a stab at revising the Requirements for IP Version 4 Routers; the last edition, RFC 1812 by Fred Baker, dates from June 1995.
RE: ECN and ISOC: request for help...
One of this router leads to the ISOC web site. what is funny is to see the above RFC is copyright ISOC. Could someone located in the Washington DC area please contact the ISOC people and help them to be RFC compliant... Your reference to RFC compliance is somewhat mistaken. First, it misrepresents what RFC compliance means: the FOO explains how to do FOO; a system is compliant if it chooses to do FOO in a manner compatible with the RFC, and non compliant if it chooses an incompatible variant; however, a system that does not do FOO is neither compliant nor non-compliant, it just does not do it. There is absolutely no IETF mandate that all systems implement all RFC. Second, RFC 3168 is a Proposed Standard. To quote RFC 2026: Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. So, if you are on a campaign to promote ECN, then maybe you should first try to promote this specification to the next standard level... You may also want to take a stab at revising the Requirements for IP Version 4 Routers; the last edition, RFC 1812 by Fred Baker, dates from June 1995. -- Christian Huitema
RE: ECN and ISOC: request for help...
I'm not in a campaign to promote ECN, or anything... I'm saying that ISOC web site is not reachable if you enable ECN, which RFC793(standard) or RFC3168(proposed Standard) talk about. I don't want to talk about what is a standard or what is not... What is compliant or not... Will there be anybody to volunteer and fix the routers leading to ISOC web site, mailing lists, e-mail addresses and so on? This is what my message is all about. Please IETF members in Washington DC, Area, please give a call to ISOC and offer some help... This is embarrassing, that's all Cheers. Franck Martin Network and Database Development Officer SOPAC South Pacific Applied Geoscience Commission Fiji E-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Web site: http://www.sopac.org/ http://www.sopac.org/ Support FMaps: http://fmaps.sourceforge.net/ http://fmaps.sourceforge.net/ Certificate: https://www.sopac.org/ssl/ This e-mail is intended for its addresses only. Do not forward this e-mail without approval. The views expressed in this e-mail may not be necessarily the views of SOPAC. -Original Message- From: Gary E. Miller [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 24 July 2002 3:02 To: Christian Huitema Cc: ietf Subject: RE: ECN and ISOC: request for help... Yo Christian! Actually, RFC 3168 has nothing to do with it. The issue is RFC 793. RFC 793 is a Standard, not a Proposed Standard RFC 793 lists the bits later used by ECN as Reserved. Computer programs are supposed to ignore Reserved bits unless they really know what they are doing. If a router treats bits in the header as required by the STANDARD RFC 793 then RFC 3168 will cause no harm.I do not have a copy of Baker handy, but I bet it agrees. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 On Tue, 23 Jul 2002, Christian Huitema wrote: So, if you are on a campaign to promote ECN, then maybe you should first try to promote this specification to the next standard level... You may also want to take a stab at revising the Requirements for IP Version 4 Routers; the last edition, RFC 1812 by Fred Baker, dates from June 1995.
