Subject: Re: Re[2]: www.isoc.org unreachable when ECN is used

From: Sally Floyd <[email-masked]>
Date: Thu, 11 Dec 2003 13:05:15 -0800

>Yes, but if you're a firewall that stepped into a temporal stasis box
>before 3168 was published, you're still thinking that the bits are
>reserved, and that the Japanese haven't surrendered, and you should
>fight on, discarding evil packets that have the reserved bits set....

Actually, it has nothing to do with a firewall that still thinks
that the ECN bits in the IP or TCP header are reserved.  As RFC
3360 on "Inappropriate TCP Resets Considered Harmful" explains (in
Section 11), it has to do with a port-scanning tool that used testing
for ECN-capability as one of its many tests, back in the days when
ECN was Experimental instead of Proposed Standard.  Such testing
for ECN-capability uses the two ECN bits in the TCP header, which
used to be reserved.  This was followed by a security article that
said that anying using these two bits in the TCP header in a TCP
SYN packet could be assumed to have malicious intentions.  This was
shortly followed by commercial products that blocked any TCP SYN
packets using these two bits in the TCP header (but that did not
block packets using the other four "Reserved" bits in the TCP
header).  That is, this is not about firewalls blocking TCP connections
that use any of the previously-reserved bits in the TCP header,
this is about firewalls that block only the two specific bits used
for ECN.

From Section 11 of RFC 3360:

   Unfortunately, misconceived security concerns are one of the reasons
   for the problems described in this document in the first place.  An
   August, 2000, article on "Intrusion Detection Level Analysis of Nmap
   and Queso" described the port-scanning tool Queso as sending SYN
   packets with the last two Reserved bits in the TCP header set, and
   said the following:  "[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."  As is documented on the TBIT Web Page, the middleboxes
   that block SYNs using the two ECN-related Reserved flags in the TCP
   header do not block SYNs using other Reserved flags in the TCP
   header. 
 
   One lesson appears to be that anyone can effectively "attack" a new
   TCP function simply by using that function in their publicly-
   available port-scanning tool, thus causing middleboxes of all kinds
   to block the use of that function. 

Section 3.1 of RFC 3360 is about those TCP implementations (i.e.,
Linux) that choose not to implement the fixes to TCP's ECN negotiation
procedures that allow TCP to work even in the presence of these
broken firewalls.  The work-around is exactly what one might think,
that is, if the first SYN is Reset or ignored, then one gets to try
again without trying to negotiate ECN this time.  This has been
around as the suggested fix since 2000:

   A work-around for maintaining connectivity in the face of the broken
   equipment was described in [Floyd00], and has been specified in RFC
   3168 as a procedure that may be included in TCP implementations.
   ...
   Some TCP implementors have so far decided not to deploy these
   workarounds...

One might hope that Linux implementors would make a better decision
next time around.  And that firewall designers would not be so quick
to block some new functionality just because it is used in the
latest port-scanning tool.  But I wouldn't count on it...

- Sally
http://www.icir.org/floyd/

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 12 Dec 2003 13:12:43 -0500

> latest port-scanning tool.  But I wouldn't count on it...

To continue quoting from RFC 3360, there were some good reasons stated
in that document for why reasonable implementors might not choose to
implement the workaround:

   * The work-arounds would result in ECN-capable hosts not responding
     properly to the first valid reset received in response to a SYN
     packet.

   * The work-arounds would limit ECN functionality in environments
     without broken equipment, by disabling ECN where the first SYN or
     SYN-ACK packet was dropped in the network.

   * The work-arounds in many cases would involve a delay of six seconds
     or more before connectivity is established with the remote server,
     in the case of broken equipment that drops ECN-setup SYN packets.
     By accommodating this broken equipment, the work-arounds have been
     judged as implicitly accepting both this delay and the broken
     equipment that would be causing this delay.

It should also be noted that RFC 3168 did not require the workaround
as a MUST.  If RFC 3168 had required the use of the workaround (which
presumably would have required the working group to come to a
consensus that the tradeoffs listed above were less important than
coddling trashy firewall implementations), then I'm sure the Linux
implementors would have respected such a MUST requirement in RFC 3168.

						- Ted

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 12 Dec 2003 21:01:09 +0100

>      equipment that would be causing this delay.

It sounds like ECN is pretty badly designed; I'm glad it wasn't my idea.
But since it is out there now, it still seems better to provide a
workaround that provides _some_ connectivity (even with a six-second
delay) than an implementation that provides none at all.

Better still, just turn ECN off.

> implementors would have respected such a MUST requirement in RFC 3168.

The problem is that RFC 3168 postdates all the RFCs that came before it,
and when something needs to be compatible with real-world systems that
are not all instantly and simultaneously upgraded, it needs to behave in
a way that works acceptably with systems that haven't guite reached RFC
3168.

This problem will only get worse, you know.  More and more systems on
the Net, with more and more variable maintenance, mean ever greater
difficulty in making any non-backwards-compatible change at all to
anything.  For better or for worse, the earliest design decisions of the
Internet will be haunting us for decades to come, and it will be
imperative to design anything new in a way that accommodates them.
Obviously this wasn't done for ECN, and I daresay it isn't being done
for lots of new specifications.

I guess this would be second on the list of most common mistakes made by
engineers, after the woeful misjudgement of necessary or available
capacity (in addressing schemes, for example).

---

From: John Kristoff <[email-masked]>
Date: Fri, 12 Dec 2003 14:37:56 -0600

On Fri, 12 Dec 2003 21:01:09 +0100

> It sounds like ECN is pretty badly designed; I'm glad it wasn't my

Those are pretty bold statements.

  <http://www.icir.org/floyd/ecn.html>

The above page seems to indicate that there was a lot of thought that
went into ECN and other related protocols.  Some of links to ECN papers
and related congestion issues from Sally's pages make good reading. Some
of the work actually goes back quite a ways and not all of it based on
TCP/IP.  In my opinion, much of what has Sally Floyd's name on it,
including ECN, is exceptional.

John

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 12 Dec 2003 22:19:49 +0100

> Those are pretty bold statements.

Well, when something pops up in software I use that adds functionality
that I never wanted and breaks things that used to work, bold statements
are in order.  If Microsoft had done this, someone would be calling for
a Constitutional amendment to forbid it.

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 12 Dec 2003 16:24:09 -0500

> for lots of new specifications.

There are a lot of broken firewalls out there.  Some of them stop any
new TCP/UDP port that wasn't known about at the time they were
constructed.  Should we therefore stop inventing new protocols.

Some of them stop various VOIP stacks.  Are they "broken"?  Should we
give up on VOIP just because some stupidly designed boxes?

Some middleware boxes reach into TCP packets, and modify them while
they are in flight, either to adjust the Max Segment Size option (to
deal with other breakages caused by things like PPP over ethernet
combined with firewalls that drop ICMP fragmentation needed packets,
which therefore breaks Path MTU discovery), or to adjust the TCP
window size, becuause they are going over satellite links --- and
encryption and integrity protection prevents such hacks from working.

Does that mean that Path MTU was badly designed, because it failed to
take into account stupid firewalls?  Does it mean that backwards
compatibility is **SO** important that we cannot add security, lest we
break some badly designed, but yet deployed infrastructure boxes?  

Of course, we do need to be pragmatic, which in some cases means
rewarding bad behaviour.  But in the case of ECN, most of the major
sites on the net have fixed their broken firewalls.  It's unfortunate
that ISOC happens to be one that hasn't, but if we accomodate every
single stupidly designed box out there, we might as well not bother
having IETF meetings, and just pack up and go home.  After all, no
matter what we we do, even if it is to design a new protocol that uses
a newly assigned TCP or UDP port, I guarantee *somewhere* out there,
there will be a stupidly designed firewall will not do the right thing
when we deploy that new protocol.

Ultimately, given that market pressure often got us into this kind of
mess, sometimes using market pressure is the only way to get us out of
the mess.  It's amazing how quickly most commercial storefront sites
fixed their ECN-buggy firewalls when they realized that they might be
losing potential customers as result of their bogus firewalls....

					- Ted

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 12 Dec 2003 22:28:30 +0100

Theodore Ts'o writes:

> But in the case of ECN, most of the major sites on the
> net have fixed their broken firewalls.

Why is ECN being deployed by default?  Does it fix some problem that is
worse than rendering thousands of hosts inaccessible?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 12 Dec 2003 23:22:14 +0100

On 12-dec-03, at 22:24, Theodore Ts'o wrote:

> take into account stupid firewalls?

Path MTU disovery was implemented very poorly because implementations 
tend expect certain functionality in routers, and usually don't recover 
when this functionality is absent. (For whatever reason.)

> Does it mean that backwards

The way things are today (and will probably stay for a long time), 
there is no course of action that is completely problem-free.

In the mean time, can anyone explain to me which real-world problem ECN 
solves?

---

From: Mark Smith <[email-masked]>
Date: Sat, 13 Dec 2003 09:38:19 +1030

On Fri, 12 Dec 2003 22:19:49 +0100

> a Constitutional amendment to forbid it.

I think you might be missing the point. ECN only breaks when used with previous *bad* implementations of the relevant RFCs.

At a guess, I find, that it is only 1% or less of web sites that I visit that I have trouble with ECN. That indicates that the other 99% of web sites firewalls got it right. Following your logic, the 99% should be penelised for the mistakes of the 1%.

In the long term, accommodating developer naivety, rather than penalising it, can only lead everybody down a dead end path. At the end of that path, no improvements can ever be made, because everthing is so fragile, and completely depends on assumptions or existing behaviours, rather than documented standards. Improvement stops, at which point everybody suffers.

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 13 Dec 2003 09:31:03 +0900

Iljitsch;

>> take into account stupid firewalls?

Yes, PMTUD was badly designed.

> when this functionality is absent. (For whatever reason.)

No, it is not an implementation issue.

It is not a good design to periodically send a large packet
expecting it is larger than the current path MTU and dropped.

It should have been designed into TCP over IPv4 and should have
never set don't fragment bit. TCP should be able to know that
packets are reassembled at the IP layer.

IPv6 was badly designed. IPv6 should never use PMTUD and TCP over
IPv6 should work with PMTU of 1280, unless it gets OOB information
that all the pathes have larger MTU. An alternative was to let routers
record MTU, say, in flow label field.

						Masataka Ohta

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Sat, 13 Dec 2003 01:41:07 +0100

Mark Smith writes:

> I think you might be missing the point. ECN only breaks when used
> with previous *bad* implementations of the relevant RFCs.

Perhaps my point isn't clear: ECN implementations prevent communication,
rather than enhance it. I don't see what advantage ECN provides, but it
has become obvious from this discussion what it removes.  A protocol and
implementation that leave you worse off than you would be without them
are a waste of time.

And what, exactly, is a "bad" implementation of relevant RFCs?  One that
does not presciently foresee every good and not-so-good implementation
of every conceivably functionality that someone might dream up in a
spare moment for the eternal future?

I don't like solutions looking for problems.  They tend to cause
problems themselves.

Apparently, FreeBSD and Windows don't implement ECN, since they both seem
to work for me with any site.  This is how things should be.

> At a guess, I find, that it is only 1% or less of web sites that I
> visit that I have trouble with ECN.

How many Web sites do you have trouble accessing _without_ ECN?

> That indicates that the other 99% of web sites firewalls got
> it right. Following your logic, the 99% should be penelised
> for the mistakes of the 1%.

No.  Following my logic, if I can access 100% of sites without ECN,
there is no point in implementing ECN so that I can access only 99% of
them.  I lose something with ECN, and I gain nothing.  Therefore ECN is
a bad idea--feature bloat.

> In the long term, accommodating developer naivety, rather than
> penalising it, can only lead everybody down a dead end path.

Yes.  That's why I'm not interested in ECN.  Why encourage mistakes?

> Improvement stops, at which point everybody suffers.

You assume that improvement is required.

If I have a system that does everything I require, I don't need
improvements.  "Improvements" will destabilize my system uselessly,
while providing no benefit that I need.  The assumption that information
systems must be perpetually "upgraded" and "improved" even in the
absence of clear need, and the axiomatic character that this assumption
seems to have among so many people in IT, is an affliction largely
peculiar to the information-technology industry, and to a lesser extent
to all high-tech industries.

---

From: Mark Smith <[email-masked]>
Date: Sat, 13 Dec 2003 11:29:04 +1030

> improvements. 

So your currently requirements are exactly the same as all the other users of the Internet ? I find it hard to believe that your requirements are exactly the same as mine, and I'm only one of the other approximately 500 million people currently accessing the Internet.

Do you know what ECN does ? Can you explain why you don't need it ? If you can't, I don't think you should be making statements about whether it is good or bad, or whether it has been designed well or not.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Sat, 13 Dec 2003 02:22:05 +0100

Mark Smith writes:

> So your currently requirements are exactly the same as all the
> other users of the Internet?

No, but my situation is similar to theirs.  They don't require
improvements if their systems do all they require, either.

> I find it hard to believe that your requirements are exactly
> the same as mine, and I'm only one of the other approximately
> 500 million people currently accessing the Internet.

They need not be the same as yours.  Your requirements, or the
requirements of other users of the Internet, may be even more modest
than mine.  Indeed, for the majority of Internet users, this is probably
actually the case.

> Do you know what ECN does?

Yes.  I've read the RFC.

> Can you explain why you don't need it?

The burden of proof is not upon me.  It's up to the person recommending
ECN to prove to me that I need it.

I don't experience network congestion with any significant frequency. I
don't need ECN. Packets in my connections are not being dropped, or at
least not to any extent that I've perceived, and this has always been
the case. ECN is an "improvement" that I don't require, and having it
actually makes the Net more inaccessible than it was without ECN,
because not every part of the Net is compatible with ECN.

If there are specific applications so intolerant to congestion-related
packet loss that they justify ECN, then those applications--and only
those--should use ECN.  Personally, though, I'd prefer that it always be
turned off by default.  The Internet worked before ECN, it will continue
to work today without ECN.

---

From: Fred Templin <[email-masked]>
Date: Fri, 12 Dec 2003 18:01:49 -0800

> Yes, PMTUD was badly designed.

No disagreement here.

>> tend expect certain functionality in routers, and usually don't 
>> recover when this functionality is absent. (For whatever reason.)
>
>

Again, no disagreement. The packet loss is inefficient.

> packets are reassembled at the IP layer.

Yes - it would have been great if this was designed into the
architecture way back when. But it wasn't, so it would be up
to receiving implementations to add hooks into the IPv4
reassembly cache if they want to inform the TCP of
fragmentation.

> record MTU, say, in flow label field. 

Huh? First, the flow label field is needed for other purposes.
Second, untrusted routers can't be counted on to record
accurate MTU values. Finally, not all forwarding nodes
can be counted on to understand IPv6.

The only reliable PMTU information is that which comes
from a trusted end node.

Fred
[email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 13 Dec 2003 12:13:27 +0900

Fred Templin;

> reassembly cache if they want to inform the TCP of

As IP and TCP are implemented with a lot of interference,
which is a good thing, it was OK to modify both IP and TCP
to introduce properly designed PMTUD.

> Huh?

First, this is an alternative for those who insits on having
PMTUD. I prefer to just send 1280B.

> First, the flow label field is needed for other purposes.

Because of the interaction between fragmentation and QoS assurance,
PMTU of QoS assured flow must also be assured that only best effort
packets need to reuse the unused 16 bit of the field.

> accurate MTU values.

It was possible to specify all the IPv6 routers behave so without
having backward compatibility problem.

> Finally, not all forwarding nodes

What is the problem?

When you receives an IPv6 packet, all the routers on the path
of the packet is IPv6 capable.

> The only reliable PMTU information is that which comes

As P of PMTU means PATH, the end node does not have PMTU
information, unless the information is collected by routers
on the path.

						Masataka Ohta

---

From: Franck Martin <[email-masked]>
Date: 15 Dec 2003 10:51:55 +1200

> to work today without ECN.

I think I do need ECN because of the poor bandwidth I have for my
organisation, however I cannot use it because 2 important sites to us/me
are ECN broken (www.ausaid.org.au/Australia Foreign Affairs, I told them
about it and I have not check if they have fixed it and www.isoc.org)

I asked them both to fix their implementation, you know the story about
isoc....

Unless, I would not care about reaching only 99% of the sites..

Cheers

----
Franck Martin
[email-masked]
SOPAC, Fiji
GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9  D9C6 BE79 9E60 81D9 1320
"Toute connaissance est une reponse a une question" G.Bachelard

---

From: jamal <[email-masked]>
Date: 14 Dec 2003 21:21:22 -0500

On Thu, 2003-12-11 at 16:05, Sally Floyd wrote:

> next time around. 

The linux implementation actually helped have a _lot_ of broken
devices fixed. I have ECN turned on always (for the last few years);
i find broken devices once every few months as opposed to once every 2-3
hours when we first deployed. The last one was when i was
a few weeks ago - the admin told me he will be upgrading the PIX
firewall in the next week. 
So the Linux decision was infact a very good one. An award of some form
is in order.

Philosophically:
One could argue that at the end a better network is one with less broken
devices; and that a better interop really means conformance as opposed
to adaptation to broken implementations. 

The main contention it seems is the definition of "reserved". Does it
mean "reserved forever?" Or does it mean "reserved for future use?" and
who defines what "future" means?
Someone needs to write a draft on this topic.

cheers,
jamal

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Mon, 15 Dec 2003 05:34:53 +0100

> So the Linux decision was infact a very good one. An award of some form

Maybe Microsoft will be inspired to do things the same way: it can
change its implementations in order to break 10% of all sites around the
world, and when anyone complains, it can say that it was forcing those
sites to move to more modern software, and that it really deserves an
award in consequence.

> to adaptation to broken implementations.

This conflicts with Linux having a broken implementation (and yes, it is
broken, because it is not interoperatively better).

> The main contention it seems is the definition of "reserved".

The main contention seems to be the system with the problem.  If it's
Linux, it's not a bug, it's feature.  If it's Microsoft, it's not a
feature, it's a bug.

---

From: [email-masked]
Date: Mon, 15 Dec 2003 01:06:13 -0500

> Linux, it's not a bug, it's feature.  If it's Microsoft, it's not a

Linux could at least stand on the claim that it was implementing the RFCs as
written, and that the interoperability problem was due to the other end failing
to implement the RFCs.

Feel free to point at examples of Microsoft saying "We're MS, and we're going
to implement the RFC because if everybody did it the RFC way, the world would
be a better place, even if there's breakage along the way".

Be prepared to find a LOT of examples - you'll need them to outweigh the damage
that has been done by active content in e-mail, even when the very first set of
MIME RFCs cautioned against it due to security concerns.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Mon, 15 Dec 2003 07:37:23 +0100

[email-masked] writes:

> Linux could at least stand on the claim that it was implementing
> the RFCs as written, and that the interoperability problem was
> due to the other end failing to implement the RFCs.

The RFCs are not specific enough to support such a claim.

> Feel free to point at examples of Microsoft saying "We're MS,
> and we're going to implement the RFC because if everybody did
> it the RFC way, the world would be a better place, even if
> there's breakage along the way".

Microsoft knows better; apparently Linux developers and/or supporters do
not.

---

From: Mark Smith <[email-masked]>
Date: Mon, 15 Dec 2003 17:28:17 +1030

On Mon, 15 Dec 2003 07:37:23 +0100

> The RFCs are not specific enough to support such a claim.

So what purpose do RFCs serve if they aren't specific enough to be complied with ? I'm intrigued to find out what you think they are for.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Mon, 15 Dec 2003 08:19:15 +0100

Mark Smith writes:

> So what purpose do RFCs serve if they aren't specific enough to be
> complied with ?

They can easily be complied with and yet still be general.  It's just
that there may be argument as to what constitutes perfect compliance or
lack thereof, and it isn't generally possible to prove either way, given
the vagueness of the original text.

In other words, the argument in the context of this discussion, that
Linux is somehow magically following RFCs with greater accuracy than
usual or in comparison to others, is virtually impossible to substantiate.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Mon, 15 Dec 2003 08:20:01 +0100

[email-masked] writes:

> Microsoft knows better than the RFC?

No.

> Microsoft knows better than to implement RFCs so everybody can benefit?

No.

> I'm not sure that either parsing is what you want to be claiming.

Good.

I was saying that Microsoft knows better than to make claims such as you
described.

---

From: Mark Smith <[email-masked]>
Date: Mon, 15 Dec 2003 18:10:13 +1030

On Mon, 15 Dec 2003 08:19:15 +0100

> the vagueness of the original text.

Are you aware of the reason why certain words are capitalised in RFCs ?

I suggest you spend a few minutes reading this RFC if you aren't 

http://www.faqs.org/rfcs/rfc2119.html

> usual or in comparison to others, is virtually impossible to substantiate.

Implementations can be measured against the capitalised words in RFCs.

As friendly piece of advice, the more you argue these points, the more you are showing what you don't know, and are embarressing yourself.

---

From: [email-masked]
Date: Mon, 15 Dec 2003 02:15:20 -0500

or

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Mon, 15 Dec 2003 10:22:24 +0100

> Are you aware of the reason why certain words are capitalised in RFCs ?

Yes.  I don't see the relevance of that here.

> Implementations can be measured against the capitalised words in RFCs.

But there are many many ambiguous directives in RFCs, both with and
without uppercased terms.  For example:

  "If a host has received an ECN-setup SYN packet, then it MAY send
  an ECN-setup SYN-ACK packet.  Otherwise, it MUST NOT send an
  ECN-setup SYN-ACK packet."

What does "otherwise" mean here? What this appears to say is that a host
may AND must not send the packet, because the meaning of "otherwise" is
ambiguous.

It should have been written this way:

  "If a host has received an ECN-setup SYN packet, then it MAY send
  an ECN-setup SYN-ACK packet.  If a host has not received an ECN-setup
  SYN packet, then it MUST NOT send an ECN-setup SYN-ACK packet."

Because of the ambiguity in the original text, multiple interpretations
are possible, some more robust and compatible than others.  The
repetition in the second example may irritate some people, but it
removes ambiguity.

While the inattentive or unreflective reader may incorrectly assert that
ambiguity is absent from the first example, implementors may reach
contradictory conclusions about the meaning and create conflicting
implementations while all of them claim that their own respective
implementations are correct.  And because of the way the text is
written, there is no way to determine who did it correctly, and who did
not.

While I'm at it (in RFC 3168), here's another example of oddness:

  "There exists at least one faulty TCP implementation in which TCP
  receivers set the Reserved field of the TCP header in ACK packets (and
  hence the SYN-ACK) simply to reflect the Reserved field of the TCP
  header in the received data packet."

If reserved is not synonymous with must-be-zero, then why is reflection
of the reserved field "faulty"?  And if reserved _is_ synonymous with
must-be-zero, then why are transports that send RST whenever they see
non-zero reserved bits "faulty"?  In the former case, the state of the
bits doesn't matter, so reflecting them shouldn't cause a problem.  In
the latter case, non-zero values in the bits are not allowed, so
treating this as an indication of an error is entirely logical.

> As friendly piece of advice, the more you argue these points, the
> more you are showing what you don't know, and are embarressing
> yourself.

As long as you depend on personal attacks to support your position,
while I depend on facts and reasoning to support mine, I'm not worried
about embarrassing myself or seeming ignorant.  See above.

---

From: jamal <[email-masked]>
Date: 15 Dec 2003 07:12:41 -0500

> sites to move to more modern software, and that it really deserves an

The issue is a standard that defines ECN in the RFC; Linux implemented
that standard to the spec. All MUSTs are met.
Other older devices made assumptions about what the future would be
and hard-coded certain behavior. Its clear that the older devices are
the one that are broken. Now if Linux had done what the older devices
did (like MS did with kerberos) then you would be correct.

I claim that ECN would have been a failure in deployment i.e not as
transparent as it is today if Linux had implemented the workaround.
Thats where the award is deserved. 

> broken, because it is not interoperatively better).

Your definition of broken is a little off. I would think the broken
implementation is the one that misunderstood the definition.  "reserved"
as i have been enlightened privately has been clearly defined at IETF
as:
a) Must be set to zero on transmission
b) Should be ignored upon reception.

Some systems dont follow b). I believe those are "broken". Linux does
follow b).

It is true that an implementation would be considered robust if it was
able to recover from interacting with problematic non-conformant devices
i.e those that break b). But robustness does not equate to conformance.
It is also true that some systems may break b) _by design_ for paranoia
reasons.
You make none of the above points. 

> Linux, it's not a bug, it's feature.  If it's Microsoft, it's not a

You are working hard to turn this into a Linux vs MS debate? 
Heres some help for you: MS sucks! ;-> In case you didnt hear that, here
goes again MS sucks! ;-> 
Now go and look for your sword and meet me at the fountain by the town
square for a duel for i have dishonored your family. Oh, i forgot to
mention the time, make it at sunset because i have other things i have
to go to after (like work for example).

cheers,
jamal

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 15 Dec 2003 07:03:00 -0600

----- Original Message ----- 
From: "jamal" <[email-masked]>
To: "Anthony G. Atkielski" <[email-masked]>
Cc: "IETF Discussion" <[email-masked]>
Sent: Monday, December 15, 2003 6:12 AM
Subject: Re: Re[4]: www.isoc.org unreachable when ECN is used

> as i have been enlightened privately has been clearly defined at
IETF

A citation here (from anyone) would be really helpful. This is also my
understanding, but I have no idea why I think so, and would prefer to
continue the discussion knowing whether we've actually written this
down, or whether this is a commonly held belief resulting from being
conservative in what you send and liberal in what you accept.

---

From: [email-masked]
Date: Mon, 15 Dec 2003 09:20:12 -0500

>   SYN packet, then it MUST NOT send an ECN-setup SYN-ACK packet."

See? You parsed it.  Couldn't have been TOO ambiguous.

> of the reserved field "faulty"?

Because simply parroting back bits that you don't understand is broken.

Read the next sentence or two of the RFC you're citing:

   Because the TCP SYN packet sets the ECN-Echo and CWR flags to
   indicate ECN-capability, while the SYN-ACK packet sets only the ECN-
   Echo flag, the sending TCP correctly interprets a receiver's
   reflection of its own flags in the Reserved field as an indication
   that the receiver is not ECN-capable.  The sending TCP is not mislead
   by a faulty TCP implementation sending a SYN-ACK packet that simply
   reflects the Reserved field of the incoming SYN packet.

Now consider the breakage if ECN had defined the bits such that seeing
both ECN-Echo and CWR on a SYN+ACK was interpreted as "the other
end is ECN-aware", when in fact the other end was clueless.

That's why echoing back the bits is faulty - if anybody ever allocates the
bits for something, you may be agreeing to do something you didn't intend to.

It's the packet-level equivalent of mumbling "Yeah sure, whatever." in response
to a question.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 15 Dec 2003 15:27:13 +0100

On 15-dec-03, at 14:03, Spencer Dawkins wrote:

>> implementation is the one that misunderstood the definition. 
>> "reserved" as i have been enlightened privately has been clearly 
>> defined at IETF as:

> conservative in what you send and liberal in what you accept.

If we set our time machine for the year 1981 and look at the text in 
RFC 791 describing the bits in the TOS byte, the picture shows bits 6 
and 7 holding the value 0, while the text says "Bit  6-7:  Reserved for 
Future Use" without further discussion.

So this doesn't help.

However, I don't see any way to reserve fields for future backward 
compatible use without requiring them to be set to a predictable value 
(i.e., zero) upon transmission and ignoring their contents upon 
reception. Obviously setting the field to a random value precludes 
adding new values with new meanings, since non-zero values could then 
be set by implementations that aren't aware of the new functionality. 
Requiring the fields to have a certain value upon reception makes 
"future use" of the field impossible, as implementations would then 
have to be upgraded across the board first, which is hard to do with a 
few hundred million systems deployed.