> On Sun, 28 Jan 2001, jamal wrote:
> > There were people who made the suggestion that TCP should retry after a
> > RST because it "might be an anti-ECN path"
>
> That depends what you mean by "retry"; I wanted the ability to attempt a
> non-ECN connection. i.e. if I'm a mailserver, and try connecting to one of
> Hotmail's MX hosts with ECN, I'll get RST every time. I would like to be
> able to retry with ECN disabled for that connection.
>
We are allowing two rules to be broken, one is RFC 793 which
clearly and unambigously defines what a RST means. the second is
the firewall or IDS box which clearly is in violation.
The simplest thing in this chaos is to fix the firewall because it is in
violation to begin with.
I think it is silly to try to be "robust against RSTs" because of ECN.
What if the RST was genuine?
I see that we mostly have philosphical differences. You'd rather adapt
to the criminal and most people would rather have the criminal adjust to
society.
I think CISCO have been very good in responding fast. I blame the site
owners who dont want to go beyond their 9-5 job and upgrade their boxes.
In the old internet where only hackers were qualified for such jobs, the
upgrade would have happened by now at hotmail. I suppose it's part of
growing pains.
If you think the CISCOs were bad sending RSTs, i am sure you havent heard
about the Raptor firewalls. They dont even bother to send you anything if
you have ECN enabled ;-> Simply swallow your SYNs.
So tell me, what do you propose we deal with these? Do we further
disambiguate or assume the packet was lost?
I actually bothered calling Raptor, they chose to ignore me.
You should never ASSume anything about something that is "reserved".
I posted the definition from the collegiate dictionary, but i am sure most
dictionaries would give the same definition.
It's too bad we end up defining protocols using English. We should use
mathematical equations to remove any ambiguity ;->
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/