Subject: ECN and ISOC: request for help...

From: Franck Martin <[email-masked]>
Date: Wed, 24 Jul 2002 12:39:36 +1200

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-masked] <mailto:[email-masked]> 
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.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Jul 2002 10:32:22 +0200

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

---

From: jamal <[email-masked]>
Date: Wed, 24 Jul 2002 09:11:40 -0400 (EDT)

> 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

---

From: "Theodore Ts'o" <[email-masked]>
Date: Thu, 25 Jul 2002 01:37:40 -0400

> 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

---

From: Franck Martin <[email-masked]>
Date: 25 Jul 2002 23:16:32 +1200

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.