hotmail not dealing with ECN

hotmail not dealing with ECN

[Jeremy Hansen]

Just curious if others have noticed that hotmail is unable to deal with
ECN and wondering if this is a standard that should be encouraged, as in
should I tell hotmail that perhaps they should look into supporting it, or
should I not waste my breath and echo 0 > /proc/sys/net/ipv4/tcp_ecn?

thanks
-jeremy


--
this is my sig.

-
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/

Re: hotmail not dealing with ECN

[Juri Haberland]

Jeremy Hansen wrote:
> 
> Just curious if others have noticed that hotmail is unable to deal with
> ECN and wondering if this is a standard that should be encouraged, as in
> should I tell hotmail that perhaps they should look into supporting it, or
> should I not waste my breath and echo 0 > /proc/sys/net/ipv4/tcp_ecn?

Forget it. I mailed them and this is the answer:

"As ECN is not a widely used internet standard, and as Cisco does not
have a stable OS for their routers that accepts ECN, anyone attempting
to access our site through a gateway or from a computer that uses ECN
will be unable to do so."

Juri

-- 
juri.haberland@innominate.com
system engineer                                         innominate AG
clustering & security                            the linux architects
tel: +49-30-308806-45   fax: -77            http://www.innominate.com
-
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/

Re: hotmail not dealing with ECN

[David S. Miller]

Juri Haberland writes:
 > Forget it. I mailed them and this is the answer:
 > 
 > "As ECN is not a widely used internet standard, and as Cisco does not
 > have a stable OS for their routers that accepts ECN, anyone attempting
 > to access our site through a gateway or from a computer that uses ECN
 > will be unable to do so."

The interesting bit is the "Cisco does not have a stable OS..." part.

I've been told repeatedly by the Cisco folks that a stable supported
patch is available from them for their firewall products which were
rejecting ECN packets.

I'd really like Cisco to reaffirm this and furthermore, and
furthermore get in contact with and correct the hotmail folks
if necessary.

I have in fact noticed that some sites that did have the problem have
installed the fix and are now accessible with ECN enabled.

Later,
David S. Miller
davem@redhat.com

-
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/

Re: hotmail not dealing with ECN

[Lincoln Dale]

Hi,

At 01:06 AM 25/01/2001 -0800, David S. Miller wrote:
>Juri Haberland writes:
>  > Forget it. I mailed them and this is the answer:
>  >
>  > "As ECN is not a widely used internet standard, and as Cisco does not
>  > have a stable OS for their routers that accepts ECN, anyone attempting
>  > to access our site through a gateway or from a computer that uses ECN
>  > will be unable to do so."
>
>The interesting bit is the "Cisco does not have a stable OS..." part.

Cisco _routers_ don't care whether packets have ECN set or not.

>I've been told repeatedly by the Cisco folks that a stable supported
>patch is available from them for their firewall products which were
>rejecting ECN packets.

nothing has changed since before --
both the cisco PIX and cisco LocalDirector didn't used to function 
correctly with ECN bits set.

both were fixed less than a week after a bug was opened and both have 
updates available for download ...
that was many many months ago ..

i wonder if some folk are being too quick to point the finger at just one 
vendor.  did some versions of solaris have problems with ECN too?

>I'd really like Cisco to reaffirm this and furthermore, and
>furthermore get in contact with and correct the hotmail folks
>if necessary.

if Juri can forward me (privately) the details of the hotmail person that 
said the above, i'd be happy to ensure that it is resolved ..

>I have in fact noticed that some sites that did have the problem have
>installed the fix and are now accessible with ECN enabled.

good to hear.


cheers,

lincoln.
NB. some cisco routers may start adding the ability to set ECN to indicate 
congestion too  ...

-
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/

Re: hotmail not dealing with ECN

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.21.0101250041440.1498-100000@srv2.ecropolis.com>
By author:    Jeremy Hansen <jeremy@xxedgexx.com>
In newsgroup: linux.dev.kernel
>
> Just curious if others have noticed that hotmail is unable to deal with
> ECN and wondering if this is a standard that should be encouraged, as in
> should I tell hotmail that perhaps they should look into supporting it, or
> should I not waste my breath and echo 0 > /proc/sys/net/ipv4/tcp_ecn?
> 

They are.  I do think they have a point, though; ECN is listed as an
experimental standard at IETF, and I do think that it's not exactly
fair to *require* everyone to use it until it is standards-track.  It
would be another thing if Linux could turn it off on a per-connection
basis if these packets get dropped.

In general, I have found the Hotmail people to be quite responsive to
problems as long as they gets pointed out that they violate
established standards.  In this case, though, they feel that they
don't want to potentially destabilize their network over something
that is labelled an experimental standard.  I can certainly understand
their point.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

Re: hotmail not dealing with ECN

[David S. Miller]

H. Peter Anvin writes:
 > I do think they have a point, though; ECN is listed as an
 > experimental standard at IETF, and I do think that it's not exactly
 > fair to *require* everyone to use it until it is standards-track.
 > It would be another thing if Linux could turn it off on a
 > per-connection basis if these packets get dropped.

Firstly, how do these things make standards status if everybody
twiddles their fingers and ignores the issues at the high volume sites
so the thing can't be effectively beta tested by researchers?

Secondly, the RFCs are pretty clear that the bits in question used for
ECN are _reserved_ and to be ignored by implementations.  That means
to not be interpreted, and more importantly not used to discard
packets.

It is specifically described in this way so that things like ECN _can_
be deployed without worrying about existing implementations being
confused.

These sites ignoring this issue, and the fix existing from the vendors
of products with the problem, are only exacerbating the situation.  A
better internet will take longer because they are doing this.  This
better internet with full blown ECN is in their best interest, it will
allow them to serve more connections, more customers, and make more
money.

Thirdly, it was widely discussed by the ECN reserachers on how to
"detect ECN blackholes" sort to speak.  All such schemes suggested
we unusable, it is not doable without impacting performance _and_
violating existing RFCs.  Basically, you have to ignore a valid TCP
reset to deal with some of the ECN holes out there, that is where such
workaround attempts become full crap and are unsatisfactory for
inclusion in any implementation much less an RFC.  Happily, we got the
ECN folks to agree with Alexey and myself on these points.

So turning it off on a per-connection basis is not really an option.

 > In this case, though, they feel that they don't want to potentially
 > destabilize their network over something that is labelled an
 > experimental standard.  I can certainly understand their point.

That's respectible.

However, to my knowledge the fix in question is available from Cisco
as a fully supported "safe" patch, rather than some haphazard beta
patch.

I think it's just a "fud to avoid a small burdon issue" on the hotmail
folks part.  Well, if this is the case they can just let me know how
many support mails at which the burdon of verifying installation of
the fix from Cisco will not see so bad in comparison :-)

Finally, regardless of whether ECN is a standard or not, making
any interpretation of the reserved bits is at best a violation
of the "be liberal of what you receive" mantra of the internet
standards committee which the hotmail person quoted seemed so
keen on mentioning :-)

Later,
David S. Miller
davem@redhat.com
-
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/

Re: hotmail not dealing with ECN

[H. Peter Anvin]

"David S. Miller" wrote:
> 
> Secondly, the RFCs are pretty clear that the bits in question used for
> ECN are _reserved_ and to be ignored by implementations.  That means
> to not be interpreted, and more importantly not used to discard
> packets.
> 

Last I communicated with them, I looked for a reference like that in the
standards RFCs so I could quote chapter and verse at the Hotmail people,
but I couldn't find it.  If there is such a reference, someone should
point it out to them, as well as the Cisco patch you point out.  As I
said before, I have had good experience with getting them to fix things
if someone actually points the exact violation they're committing.

>  > In this case, though, they feel that they don't want to potentially
>  > destabilize their network over something that is labelled an
>  > experimental standard.  I can certainly understand their point.
> 
> That's respectible.
> 
> However, to my knowledge the fix in question is available from Cisco
> as a fully supported "safe" patch, rather than some haphazard beta
> patch.

Right, but there is a whole mythos around which version of IOS does what
without breaking something.  I can certainly understand that people are
reluctant to upgrade if they don't have to.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

Re: hotmail not dealing with ECN

[David S. Miller]

H. Peter Anvin writes:
 > Last I communicated with them, I looked for a reference like that in the
 > standards RFCs so I could quote chapter and verse at the Hotmail people,
 > but I couldn't find it.

RFC793, where is lists the unused flag bits as "reserved".
That is pretty clear to me.  It just has to say that
they are reserved, and that is what it does.

 > Right, but there is a whole mythos around which version of IOS does what
 > without breaking something.  I can certainly understand that people are
 > reluctant to upgrade if they don't have to.

As far as I understand it, the PIIX stuff doesn't run IOS but rather
some other system created for these firewall products.

Moot point.  I understand that upgrading can be a pain, but I think
it is in their best interest to do so (see better internet and "make
money" arguments).

Later,
David S. Miller
davem@redhat.com
-
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/

Re: hotmail not dealing with ECN

[H. Peter Anvin]

"David S. Miller" wrote:
> 
> H. Peter Anvin writes:
>  > Last I communicated with them, I looked for a reference like that in the
>  > standards RFCs so I could quote chapter and verse at the Hotmail people,
>  > but I couldn't find it.
> 
> RFC793, where is lists the unused flag bits as "reserved".
> That is pretty clear to me.  It just has to say that
> they are reserved, and that is what it does.
> 

Is the definition of "reserved" defined anywhere?  In a lot of specs,
"reserved" means MBZ.

Note, that I'm not arguing with you.  I'm trying to pick this apart.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

Re: hotmail not dealing with ECN

[David S. Miller]

H. Peter Anvin writes:
 > > RFC793, where is lists the unused flag bits as "reserved".
 > > That is pretty clear to me.  It just has to say that
 > > they are reserved, and that is what it does.
 > > 
 > 
 > Is the definition of "reserved" defined anywhere?  In a lot of specs,
 > "reserved" means MBZ.
 > 
 > Note, that I'm not arguing with you.  I'm trying to pick this apart.

It says "reserved for future use, must be zero".

I think the descrepency (and thus what the firewalls are doing) comes
from the ambiguous "must be zero".  I cannot fathom the RFC authors
meaning this to be anything other than "must be set to zero by current
implementations" or else what is the purpose of the "reserved for
future use part" right?

Honestly, is there anyone here who can tell me honestly that when they
see the words "reserved" in the description of a bit field description
(in a hardware programmers manual of some device, for example) that
they think it's ok the read the value and interpret it in any way?

To me it's always meant "we want to do cool things in the future,
things we haven't thought of now, so don't interpret these bits so we
can do that and you will still work".

Later,
David S. Miller
davem@redhat.com
-
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/

Re: hotmail not dealing with ECN

[H. Peter Anvin]

"David S. Miller" wrote:
> 
> It says "reserved for future use, must be zero".
> 
> I think the descrepency (and thus what the firewalls are doing) comes
> from the ambiguous "must be zero".  I cannot fathom the RFC authors
> meaning this to be anything other than "must be set to zero by current
> implementations" or else what is the purpose of the "reserved for
> future use part" right?
> 
> Honestly, is there anyone here who can tell me honestly that when they
> see the words "reserved" in the description of a bit field description
> (in a hardware programmers manual of some device, for example) that
> they think it's ok the read the value and interpret it in any way?
> 
> To me it's always meant "we want to do cool things in the future,
> things we haven't thought of now, so don't interpret these bits so we
> can do that and you will still work".
> 

Think of yourself as a firewall author now.  You come across this, and
go, "these bits aren't used now; this means noone should be setting
them.  I have no guarantee that anything in the future isn't going to use
these bits for something that isn't going to override the security of my
system."

MBZ to me indicate that it is legitimate for the recipient to drop them
as invalid if they are not.  This is probably unfortunate; they really
need specific definition about what the sender should do (set the bits to
zero) and the recipient should do (ignore the bits.)

Unfortunately, it's hard to be "liberal in what you accept" when you're
trying to enforce a security policy.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

Re: hotmail not dealing with ECN

[Helge Hafting]

"H. Peter Anvin" wrote:
> 
> "David S. Miller" wrote:
> >
> > It says "reserved for future use, must be zero".
> >
> > I think the descrepency (and thus what the firewalls are doing) comes
> > from the ambiguous "must be zero".  I cannot fathom the RFC authors
> > meaning this to be anything other than "must be set to zero by current
> > implementations" or else what is the purpose of the "reserved for
> > future use part" right?
> >
> > Honestly, is there anyone here who can tell me honestly that when they
> > see the words "reserved" in the description of a bit field description
> > (in a hardware programmers manual of some device, for example) that
> > they think it's ok the read the value and interpret it in any way?
> >
> > To me it's always meant "we want to do cool things in the future,
> > things we haven't thought of now, so don't interpret these bits so we
> > can do that and you will still work".
> >
> 
> Think of yourself as a firewall author now.  You come across this, and
> go, "these bits aren't used now; this means noone should be setting
> them.  I have no guarantee that anything in the future isn't going to use
> these bits for something that isn't going to override the security of my
> system."
> 
> MBZ to me indicate that it is legitimate for the recipient to drop them
> as invalid if they are not.  This is probably unfortunate; they really
> need specific definition about what the sender should do (set the bits to
> zero) and the recipient should do (ignore the bits.)
> 
> Unfortunately, it's hard to be "liberal in what you accept" when you're
> trying to enforce a security policy.

As David pointed out, it is "reserved for future use - you must set
these bits to zero and not use it _for your own purposes_.   For non-rfc
use of these bits _will_ break something the day we start using them
for something useful.

So, no reason for a firewall author to check these bits.

Helge Hafting
-
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/

Re: hotmail not dealing with ECN

[Rick Jones]

> As David pointed out, it is "reserved for future use - you must set
> these bits to zero and not use it _for your own purposes_.   For non-rfc
> use of these bits _will_ break something the day we start using them
> for something useful.
> 
> So, no reason for a firewall author to check these bits.

I thought that most firewalls were supposed to be insanely paranoid.
Perhaps it would be considered a possible covert data channel, as
farfecthed as that may sound.

rick jones
-- 
ftp://ftp.cup.hp.com/dist/networking/misc/rachel/
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to email, OR post, but please do NOT do BOTH...
my email address is raj in the cup.hp.com domain...
-
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/

Re: hotmail not dealing with ECN

[Rusty Russell]

In message <3A71BC34.F8024103@cup.hp.com> you write:
> I thought that most firewalls were supposed to be insanely paranoid.
> Perhaps it would be considered a possible covert data channel, as
> farfecthed as that may sound.

If they were `insanely paranoid' they wouldn't just be doing packet
filtering.  The firewall designers can't have it both ways.

1) Dropping these packets is wrong, but it won't get fixed if noone
   pressures them to.  Fixing this now also makes future standards
   enhancements easier, by bringing the 'net closer to compliance.

2) Sending RSTs is completely fucked up.  Those firewalls are too
   braindamaged to live.

Distros will probably turn ECN off, but maybe if we fix enough of the
net, later versions may not.

Rusty.
--
Premature optmztion is rt of all evl. --DK
-
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/

Re: hotmail not dealing with ECN

[Alan Cox]

> > So, no reason for a firewall author to check these bits.
> 
> I thought that most firewalls were supposed to be insanely paranoid.
> Perhaps it would be considered a possible covert data channel, as
> farfecthed as that may sound.

If you care about such things you run pure proxy. A packet filter is a simple
access barrier it isnt designed to stop information leakage

-
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/

Re: hotmail not dealing with ECN

[David Wagner]

Helge Hafting  wrote:
>So, no reason for a firewall author to check these bits.

You don't think like a firewall designer! :-)

Practice being really, really paranoid.  Think: You're designing a
firewall; you've got some reserved bits, currently unused; any future code
that uses them could behave in completely arbitrary and insecure ways,
for all you know.  Now recall that anything not known to be safe should
be denied (in a good firewall) -- see Cheswick and Bellovin for why.
When you take this point of view, it is completely understandable why
firewalls designed before ECN was introduced might block it.
-
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/

Re: hotmail not dealing with ECN

[Brian May]

>>>>> "David" == David Wagner <daw@mozart.cs.berkeley.edu> writes:

    David> Practice being really, really paranoid.  Think: You're
    David> designing a firewall; you've got some reserved bits,
    David> currently unused; any future code that uses them could
    David> behave in completely arbitrary and insecure ways, for all
    David> you know.  Now recall that anything not known to be safe
    David> should be denied (in a good firewall) -- see Cheswick and
    David> Bellovin for why.  When you take this point of view, it is
    David> completely understandable why firewalls designed before ECN
    David> was introduced might block it.

In which case, people who use these firewall products need to realize
that future developments may break these assumptions, and that the
firewall software needs to be updated/reconfigured as a result.
-- 
Brian May <bam@snoopy.apana.org.au>
-
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/

Re: hotmail not dealing with ECN

[Frank v Waveren]

On Sat, Jan 27, 2001 at 04:10:48AM +0000, David Wagner wrote:
> Practice being really, really paranoid.  Think: You're designing a
> firewall; you've got some reserved bits, currently unused; any future code
> that uses them could behave in completely arbitrary and insecure ways,
> for all you know.  Now recall that anything not known to be safe should
> be denied (in a good firewall) -- see Cheswick and Bellovin for why.
> When you take this point of view, it is completely understandable why
> firewalls designed before ECN was introduced might block it.

Why? Why not just zero them, and get both security and compatibility...

-- 
Frank v Waveren                                      Fingerprint: 0EDB 8787
fvw@[var.cx|dse.nl|stack.nl|chello.nl] ICQ#10074100     09B9 6EF5 6425 B855
Public key: http://www.var.cx/pubkey/fvw@var.cx-gpg     7179 3036 E136 B85D

-
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/

Re: hotmail not dealing with ECN

[Gregory Maxwell]

On Sat, Jan 27, 2001 at 07:18:09PM +0100, Frank v Waveren wrote:
> On Sat, Jan 27, 2001 at 04:10:48AM +0000, David Wagner wrote:
> > Practice being really, really paranoid.  Think: You're designing a
> > firewall; you've got some reserved bits, currently unused; any future code
> > that uses them could behave in completely arbitrary and insecure ways,
> > for all you know.  Now recall that anything not known to be safe should
> > be denied (in a good firewall) -- see Cheswick and Bellovin for why.
> > When you take this point of view, it is completely understandable why
> > firewalls designed before ECN was introduced might block it.
> 
> Why? Why not just zero them, and get both security and compatibility...

Eeek! NO!!!! NO NO NO NO NO NO NO!
For ECN that would have worked, but that doesn't mean that something
couldn't have been implimented there that wouldn't have worked that way..

I think that older Checkpoint firewalls (perhaps current?) zeroed out SACK
on 'hide nat'ed connections. This causes unreasonable stalls for users on
SACK enabled clients. Not cool.


-
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/

Re: hotmail not dealing with ECN

[Frank v Waveren]

On Sat, Jan 27, 2001 at 02:20:32PM -0500, Gregory Maxwell wrote:
> > Why? Why not just zero them, and get both security and compatibility...
> Eeek! NO!!!! NO NO NO NO NO NO NO!
> For ECN that would have worked, but that doesn't mean that something
> couldn't have been implimented there that wouldn't have worked that way..
> I think that older Checkpoint firewalls (perhaps current?) zeroed out SACK
> on 'hide nat'ed connections. This causes unreasonable stalls for users on
> SACK enabled clients. Not cool.

Point taken. So much for thinking simple... :-} 

-- 
Frank v Waveren                                      Fingerprint: 0EDB 8787
fvw@[var.cx|dse.nl|stack.nl|chello.nl] ICQ#10074100     09B9 6EF5 6425 B855
Public key: http://www.var.cx/pubkey/fvw@var.cx-gpg     7179 3036 E136 B85D

-
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/

Re: hotmail not dealing with ECN

[Jamie Lokier]

Gregory Maxwell wrote:
> > Why? Why not just zero them, and get both security and compatibility...
> 
> Eeek! NO!!!! NO NO NO NO NO NO NO!
> For ECN that would have worked, but that doesn't mean that something
> couldn't have been implimented there that wouldn't have worked that way..
> 
> I think that older Checkpoint firewalls (perhaps current?) zeroed out SACK
> on 'hide nat'ed connections. This causes unreasonable stalls for users on
> SACK enabled clients. Not cool.

If both SACK and SACK_PERMITTED were zeroed out, the clients would
negotiate non-SACK connections and everythings ok.  A performance
disadvantage relative to allowing SACK, but that's true of ECN as well.

-- Jamie
-
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/

Re: hotmail not dealing with ECN

[Gregory Maxwell]

On Sat, Jan 27, 2001 at 08:58:51PM +0100, Jamie Lokier wrote:
[snip]
> > I think that older Checkpoint firewalls (perhaps current?) zeroed out SACK
> > on 'hide nat'ed connections. This causes unreasonable stalls for users on
> > SACK enabled clients. Not cool.
> 
> If both SACK and SACK_PERMITTED were zeroed out, the clients would
> negotiate non-SACK connections and everythings ok.  A performance
> disadvantage relative to allowing SACK, but that's true of ECN as well.

Some checkpoint firewalls have caused stalls on SACK enabled clients. I
don't recall the exact configuration or method of action, but it does
happen. I suspect that it didn't kill the SackOK but only the actual SACKs
data. 

Breaking end-to-end is the path to maddness. Trusting practically any
network that leaves a room is insane.

Firewalling should be implemented on the hosts, perhaps with centralized
policy management. In such a situation, there would be no reason to filter
on funny IP options.

-
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/

RE: hotmail not dealing with ECN

[David Schwartz]

> Firewalling should be implemented on the hosts, perhaps with centralized
> policy management. In such a situation, there would be no reason to filter
> on funny IP options.

	That's madness. If you have to implement your firewalling on every host,
what do you do when someone wants to run a new OS? Forbid it?

	DS

-
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/

RE: hotmail not dealing with ECN

[James Sutherland]

On Sat, 27 Jan 2001, David Schwartz wrote:

> 
> > Firewalling should be implemented on the hosts, perhaps with centralized
> > policy management. In such a situation, there would be no reason to filter
> > on funny IP options.
> 
> 	That's madness. If you have to implement your firewalling on every host,
> what do you do when someone wants to run a new OS? Forbid it?

Of course. Then you find out about some new problem you want to block, so
you spend the next week reconfiguring a dozen different OS firewalling
systems. Hrm... I'll stick with a proper firewall, TYVM!


James.

-
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/

Re: hotmail not dealing with ECN

[Gregory Maxwell]

On Sat, Jan 27, 2001 at 11:09:27PM +0000, James Sutherland wrote:
> On Sat, 27 Jan 2001, David Schwartz wrote:
> 
> > 
> > > Firewalling should be implemented on the hosts, perhaps with centralized
> > > policy management. In such a situation, there would be no reason to filter
> > > on funny IP options.
> > 
> > 	That's madness. If you have to implement your firewalling on every host,
> > what do you do when someone wants to run a new OS? Forbid it?
> 
> Of course. Then you find out about some new problem you want to block, so
> you spend the next week reconfiguring a dozen different OS firewalling
> systems. Hrm... I'll stick with a proper firewall, TYVM!

It's this kind of ignorance that makes the internet a less secure and stable
place.

The network should not be a stateful device. If you need stateful
firewalling the only place it should be implimented is on the end node. If
management of that is a problem, then make an interface solve that problem
insted of breaking the damn network.
-
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/

Re: hotmail not dealing with ECN

[Dominik Kubla]

On Sat, Jan 27, 2001 at 07:11:59PM -0500, Gregory Maxwell wrote:

> It's this kind of ignorance that makes the internet a less secure and stable
> place.

You have obviously absolutely no idea what you are talking about. Period.

> The network should not be a stateful device. If you need stateful
> firewalling the only place it should be implimented is on the end node. If
> management of that is a problem, then make an interface solve that problem
> insted of breaking the damn network.

So how do you propose to secure devices like MRT's or X-Ray scanners or
life-support in a hospital? Nowadays this equipment  is hooked to the
internal network of the hospital and protected by really paranoid
firewalls. Do you really want unneeded software on those devices?

Or what about the computer systems in nuclear powerplants? In air defense
systems?  Power grids? Water supply?

Oh come on! Just reread some of the newspapers back from Dec 31 1999!

Yours,
  Dominik Kubla
-- 
          A lovely thing to see:                   Kobayashi Issa
     through the paper window's holes               (1763-1828)
                the galaxy.               [taken from: David Brin - Sundiver]
-
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/

[OT] Re: hotmail not dealing with ECN

[Gregory Maxwell]

On Sun, Jan 28, 2001 at 02:10:25AM +0100, Dominik Kubla wrote:
> On Sat, Jan 27, 2001 at 07:11:59PM -0500, Gregory Maxwell wrote:
> > It's this kind of ignorance that makes the internet a less secure and stable
> > place.
> 
> You have obviously absolutely no idea what you are talking about. Period.

Your following comments show exactly who is has no idea of what he is
talking about. Period.
 
> > The network should not be a stateful device. If you need stateful
> > firewalling the only place it should be implimented is on the end node. If
> > management of that is a problem, then make an interface solve that problem
> > insted of breaking the damn network.
> 
> So how do you propose to secure devices like MRT's or X-Ray scanners or
> life-support in a hospital? Nowadays this equipment  is hooked to the
> internal network of the hospital and protected by really paranoid
> firewalls. Do you really want unneeded software on those devices?

Oh yes! This provides you with virtually zero extra security.
Now someone in the next room, perhaps the lobby, is free to attack the
system... Which probably has very little extra security and trusts the
network (after all, it's firewall protected).

An attack against an Xray system is much more likely to come from inside the
companies network.

The only way to have firewall protection against even a simple majority of
attacks is to implement a firewall per system. That would be expensive, and
wasteful, so it makes a lot more sense to implement a firewall IN every
system. Such a thing can be done at zero expense with practically no
performance loss and not break the end-to-end model of the Internet.

But such a simple solution would totally invalidate the use for most
security 'experts' and their products. 

Firewalling is commodity. Cope. It's much more useful to push it to the
end-node where it belongs. But look where security companies make their
money.... The most common business affecting security violations are
internal. Yes, many security companies are making most of their money
selling expensive and pointless network profalatics. Why? For firewalling to
be affordable on every system, it has to be free. Thats not profitable for
security companies which is why you never hear it suggested, even though it
actually can defend against the most common threats.

The very fact that you bring up medical systems and suggest that I purposed
leaving them unsecured shows that your only avenue for discussion was
hysteria.
 
> Or what about the computer systems in nuclear powerplants? In air defense
> systems?  Power grids? Water supply?
> Oh come on! Just reread some of the newspapers back from Dec 31 1999!

Mythology and hysteria. The same things that promotes the propagation of
network degrading central firewalls.


-
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/

Re: [OT] Re: hotmail not dealing with ECN

[Dominik Kubla]

On Sat, Jan 27, 2001 at 11:35:43PM -0500, Gregory Maxwell wrote:
...
> An attack against an Xray system is much more likely to come from inside the
> companies network.
...

We are not talking about attacks here, we are talking about undefined
behaviour when (perhaps poorly designed) systems encounter network
packages that use new or experimental features: I have seen MRI scanners
panic when they received SNMP queries and SNMP has been around for ages!

Yours,
  Dominik Kubla
-- 
          A lovely thing to see:                   Kobayashi Issa
     through the paper window's holes               (1763-1828)
                the galaxy.               [taken from: David Brin - Sundiver]
-
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/

Re: [OT] Re: hotmail not dealing with ECN

[Michael H. Warfield]

On Sun, Jan 28, 2001 at 01:57:53PM +0100, Dominik Kubla wrote:
> On Sat, Jan 27, 2001 at 11:35:43PM -0500, Gregory Maxwell wrote:
> ...
> > An attack against an Xray system is much more likely to come from inside the
> > companies network.
> ...

> We are not talking about attacks here, we are talking about undefined
> behaviour when (perhaps poorly designed) systems encounter network
> packages that use new or experimental features: I have seen MRI scanners
> panic when they received SNMP queries and SNMP has been around for ages!

	Couple of years ago I did a security advisory on OS/9 (the
Microware OS that was originally designed for 6809 processors).  It
had become quite popular for embedded controllers.  I think at the time
it was ranked one of the top three embedded controller operating systems
and was used in a large number of Allen Bradley controllers.  Read that
last statement as saying that it was in a GOD AWFULL number of HVAC
controllers and factory automation controllers around the entire world.

	We stumbled onto a flaw in the protocol stacks in OS/9 and it
couldn't handle being hit with an ICMP redirect.  The incoming stack
didn't properly recognize it and created some weird state in the outgoing
stack.  The next time the controller tried to transmit something, the
controller hung leaving whatever it was controlling in what ever position
it was in, no matter what the consequences.  This was "discovered" the
hard way at a site where the network people had not even realized that
all of these controllers were connected to the main corporate network.
Envision hundreds of controllers suddenly freezing and an entire plant
rapidly grinding to a complete halt.

	My contact at Microware told me that they never anticipated having
those controllers hooked up to a general purpose network and OS/9 was
designed for such a small footprint (Hey, I had a multitasking, multiuser,
dial-in system running on a RadioShack CoCo with 64K of memory running OS/9)
that they had no room for handling ICMP redirects so they hadn't coded
it into the stack.  Multiple mistakes and assumptions resulted in a
security advisory warning about potential threats to human health and
safety.  They were having a bad day...  Especially when CNN called them.  :-/
(They had been notified over 6 months prior to the publication of the
advisory, BTW...)

	That advisory concluded to isolate all embedded controllers to
insulated subnets and configure all routers to refuse to pass ICMP
redirect packets.  Anyone want to take bets if it's been done to
any great extent?  It will take some factory being knocked on it's
ass and making CNN, and even then most people won't take action because
most of the admins don't know what's on their networks in those
environments.

	Upgrading a lot of these old controllers also meant physically
removing and replacing EPROMS. (One claim to fame for OS/9 is that it
was totally PIC and could be copied straight into EPROM and run
equally well from EPROM or RAM at arbitrary addresses.)  That's even
assuming you knew where all your controllers were and how to get to them!

	So...  Yeah...  I can understand what can happen when unknown
packets reach devices that were not designed to handle them.  Bad Juju...
And embedded controllers are a hell of a lot more plentyful than X-Ray
machines.

> Yours,
>   Dominik Kubla
> -- 
>           A lovely thing to see:                   Kobayashi Issa
>      through the paper window's holes               (1763-1828)
>                 the galaxy.               [taken from: David Brin - Sundiver]

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

-
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/

Re: [OT] Re: hotmail not dealing with ECN

[Gregory Maxwell]

On Sun, Jan 28, 2001 at 01:57:53PM +0100, Dominik Kubla wrote:
> On Sat, Jan 27, 2001 at 11:35:43PM -0500, Gregory Maxwell wrote:
> ...
> > An attack against an Xray system is much more likely to come from inside the
> > companies network.
> ...
> 
> We are not talking about attacks here, we are talking about undefined
> behaviour when (perhaps poorly designed) systems encounter network
> packages that use new or experimental features: I have seen MRI scanners
> panic when they received SNMP queries and SNMP has been around for ages!

The discussion was over centralized firewalls. Putting a firewall right on
top of a system is the same as putting it on the system. Putting a firewall
on your Internet connection would be insufficient to protect such a system.

It's not a question of how long something has been around. You should be
able to send line noise into the Ethernet port of any IP host and not have
it behave adversly. Anything less and you *WILL* have problems.

I would hope that you have enough sense to NOT connect any such broken
systems in any way to a public network. 

Yet, another point against firewalls: Apparently they encourage computer
professionals to behave criminally negligent by making it acceptable to
implement broken life critical services. 

Firewalling your hospital's Internet connection to prevent your tomographic
equipment from producing bad results due to a port scan rather then
correctly repairing the system is computer equivalent of placing the fuel tank
on the outside of the frame on a car (Pinto): Since it's protected by it's
own wall and the outer body, casual impacts won't make the defect noticeable.

Less people would have died in the pinto if the fuel tank was made of
sugar-glass and placed prominently on the hood. Not because it's safer that
way, but because out of both of the defective configurations the
tank-on-the-hood is obviously broken and would get fixed or not used.

Firewalls only actually improve security when there is only a single domain
of trust behind them. Often we have multiple domains of trust even within a
single system. Internet filtering firewalls provide nothing more then a
false sense of security, and some opportunistic script kiddie protection.

The continued profiteering by security 'experts' and acceptance of
magic-boxes by systems administrators ensures that better solutions are not
implemented.


-
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/

Re: [OT] Re: hotmail not dealing with ECN

[Dominik Kubla]

[... rant deleted ...]
> The continued profiteering by security 'experts' and acceptance of
> magic-boxes by systems administrators ensures that better solutions are not
> implemented.

You'd better get a reality check once in while.

Dominik
-- 
          A lovely thing to see:                   Kobayashi Issa
     through the paper window's holes               (1763-1828)
                the galaxy.               [taken from: David Brin - Sundiver]
-
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/

Re: hotmail not dealing with ECN

[James Sutherland]

On Sat, 27 Jan 2001, Gregory Maxwell wrote:
> On Sat, Jan 27, 2001 at 11:09:27PM +0000, James Sutherland wrote:
> > On Sat, 27 Jan 2001, David Schwartz wrote:
> > 
> > > 
> > > > Firewalling should be implemented on the hosts, perhaps with centralized
> > > > policy management. In such a situation, there would be no reason to filter
> > > > on funny IP options.
> > > 
> > > 	That's madness. If you have to implement your firewalling on every host,
> > > what do you do when someone wants to run a new OS? Forbid it?
> > 
> > Of course. Then you find out about some new problem you want to block, so
> > you spend the next week reconfiguring a dozen different OS firewalling
> > systems. Hrm... I'll stick with a proper firewall, TYVM!
> 
> It's this kind of ignorance that makes the internet a less secure and stable
> place.
> 
> The network should not be a stateful device. If you need stateful
> firewalling the only place it should be implimented is on the end node. If
> management of that is a problem, then make an interface solve that problem
> insted of breaking the damn network.

I'm not suggesting making the network a stateful device. I'm suggesting
having a firewall. That should NOT be implemented on the end node. Apart
from anything else, the firewall shouldn't run any services: this is a bit
difficult on a server...

The network isn't broken. It works very nicely, TYVM. The firewall will
occasionally need reconfiguring (block out new types of attack, allow new
services, etc.) It's just much easier (and more secure) on a dedicated
firewall than running a load of filtering on every single server.


James.

-
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/

Re: hotmail not dealing with ECN

[Gregory Maxwell]

On Sat, Jan 27, 2001 at 02:18:31PM -0800, David Schwartz wrote:
> > Firewalling should be implemented on the hosts, perhaps with centralized
> > policy management. In such a situation, there would be no reason to filter
> > on funny IP options.
> 
> 	That's madness. If you have to implement your firewalling on every host,
> what do you do when someone wants to run a new OS? Forbid it?

No a standard management interface would be followed by every host. Not
unlike configuring your ipaddress with DHCP.

-
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/

RE: hotmail not dealing with ECN

[David Schwartz]

> On Sat, Jan 27, 2001 at 02:18:31PM -0800, David Schwartz wrote:

> > > Firewalling should be implemented on the hosts, perhaps with
> > > centralized
> > > policy management. In such a situation, there would be no
> > > reason to filter
> > > on funny IP options.

> > That's madness. If you have to implement your firewalling
> > on every host,
> > what do you do when someone wants to run a new OS? Forbid it?

> No a standard management interface would be followed by every host. Not
> unlike configuring your ipaddress with DHCP.

	How does a standard interface help?

	Perhaps you don't understand the problem -- someone wants to use a new
operating system that you no information about. You are willing to let it
run on your network if and only if you can be assured it won't violate your
firewall policy.

	So how does an interface guarantee that an unknown implementation of that
interface will correctly implement it? And what about printers? Embedded
systems? Legacy equipment? What about systems that have to run software that
isn't as trusted as the implementation of the firewalls has to be?

	The net effect of having to trust every host to enforce your security
policy is that you can't give anyone not trusted to enforce your security
policy root access on any machine on your network. Or, to put it another
way, you have to trust every machine on your network and every person who
controls them as much as you trust your firewall. That's simply unacceptable
in many applications.

	DS

-
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/

Re: hotmail not dealing with ECN

[David Lang]

On Sat, 27 Jan 2001, Frank v Waveren wrote:

> Why? Why not just zero them, and get both security and compatibility...
>

the problem is that you don't know what they mean, just zeroing them may
break things (how will the sender know that you zeroed them).

David Lang

-
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/

Re: hotmail not dealing with ECN

[Johannes Erdfelt]

On Thu, Jan 25, 2001, David S. Miller <davem@redhat.com> wrote:
> 
> H. Peter Anvin writes:
>  > > RFC793, where is lists the unused flag bits as "reserved".
>  > > That is pretty clear to me.  It just has to say that
>  > > they are reserved, and that is what it does.
>  > > 
>  > 
>  > Is the definition of "reserved" defined anywhere?  In a lot of specs,
>  > "reserved" means MBZ.
>  > 
>  > Note, that I'm not arguing with you.  I'm trying to pick this apart.
> 
> It says "reserved for future use, must be zero".
> 
> I think the descrepency (and thus what the firewalls are doing) comes
> from the ambiguous "must be zero".  I cannot fathom the RFC authors
> meaning this to be anything other than "must be set to zero by current
> implementations" or else what is the purpose of the "reserved for
> future use part" right?
> 
> Honestly, is there anyone here who can tell me honestly that when they
> see the words "reserved" in the description of a bit field description
> (in a hardware programmers manual of some device, for example) that
> they think it's ok the read the value and interpret it in any way?
> 
> To me it's always meant "we want to do cool things in the future,
> things we haven't thought of now, so don't interpret these bits so we
> can do that and you will still work".

Generally it's to ensure that all implementations set those bit by
default to 0 as well.

Then in the future, 0 means "I don't support this feature either by
choice or by not implementing it yet".

JE

-
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/

Re: hotmail not dealing with ECN

[Brian May]

>>>>> "David" == David S Miller <davem@redhat.com> writes:

    David> It says "reserved for future use, must be zero".

Poor choice of wording.

If I was implementing this, I would assume that any packet with a
non-zero value is illegal by this RFC, and act accordingly.

I would assume that this "future use" may require handling of the
packet in a non-standard way, and packets with a non-zero value cannot
be used until the "future use" is better defined.

Also, the above statement should really clarify how routers should
cope if they receive a non-zero value. Drop it, pass it through
unchanged, or set it to zero?
-- 
Brian May <bam@snoopy.apana.org.au>
-
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/

Re: hotmail not dealing with ECN

[Jeremy M. Dolan]

On Thu, 25 Jan 2001 18:10:21 +0000, David S. Miller wrote:
> It says "reserved for future use, must be zero".

While I've not checked the context yet, this seems to be terrible
wording. The context doesn't direct this towards hosts constructing
packets? What is the 'It' you refer to, the TCP RFC? Do any of the
following override this awful wording job?

RFC1122 / STD0003    Requirements for Internet hosts (comm. layers)
RFC1123 / STD0003    Requirements for Internet hosts (apps)
RFC1009 / STD0004    Requirements for Internet gateways 
RFC1812              Requirements for IP Version 4 Routers 
RFC2979              Behavior of and Requirements for Internet Firewalls 

The last one seems it would have the most potential to clear up this
mess, unfortunatly it's only an informational RFC, and at a quick
glance, doesn't look like it addresses this issue. Regardless, the
intent of the author was clear... it'd just be nice to be able to
quote chapter and verse.

Besides, I'm MUCH more worried about all of .uk being behind an ECN
eating router then not being about to talk to some Microsoft webmail
service.

I fear this problem is doomed to repeat itself as well, as more of
IP's features become unreserved (Class E IP Address, anyone?)

/jmd

-- 
Jeremy M. Dolan <jmd@turbogeek.org>
OpenPGP key = http://turbogeek.org/openpgp-key
OpenPGP fingerprint = 494C 7A6E 19FB 026A 1F52  E0D5 5C5D 6228 DC43 3DEE
-
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/

Re: hotmail not dealing with ECN

[Florian Weimer]

"Jeremy M. Dolan" <jmd@foozle.turbogeek.org> writes:

> RFC1812              Requirements for IP Version 4 Routers 

RFC 1812 mandates routing of IP packets with reserved flags, but not
for TCP packets.

> RFC2979              Behavior of and Requirements for Internet Firewalls 
> 
> The last one seems it would have the most potential to clear up this
> mess, unfortunatly it's only an informational RFC, and at a quick
> glance, doesn't look like it addresses this issue. 

In fact, it does, but not in the way you want: ;-)

|   When a firewall acts a protocol end point it may
|
|    (1)   implement a "safe" subset of the protocol,
|
|    (2)   perform extensive protocol validity checks,

|   Good security may occasionally result in interoperability failures
|   between components.  This is understood.  However, this doesn't mean
|   that gratuitous interoperability failures caused by security
|   components are acceptable.

It is completely acceptable to deploy a firewall which drops packets
in which reserved flags are not zero.  Obviously, the implementer
doesn't know the effect of this flag (because they aren't defined
yet), so he's facing the choice whether to create a system which is
safe or a system which maximizes interoperability at the cost of
potential risks.  IMHO, the first choice is much more appropriate than
the second one.

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
-
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/

Re: hotmail not dealing with ECN

[Rogier Wolff]

H. Peter Anvin wrote:
> "David S. Miller" wrote:
> > 
> > H. Peter Anvin writes:
> >  > Last I communicated with them, I looked for a reference like that in the
> >  > standards RFCs so I could quote chapter and verse at the Hotmail people,
> >  > but I couldn't find it.
> > 
> > RFC793, where is lists the unused flag bits as "reserved".
> > That is pretty clear to me.  It just has to say that
> > they are reserved, and that is what it does.
> > 
> 
> Is the definition of "reserved" defined anywhere?  In a lot of specs,
> "reserved" means MBZ.

MBZ? Must Be Zero? 

Reserved means MBZ on things you generate, to guarantee you'll get
expected behaviour from the other side. But in no circumstance should
a reserved bit being non-zero confuse you. They should be
ignored. That leads to the "new" implementations knowing what the old
implementations will do.

			Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
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/

Re: hotmail not dealing with ECN

[Alan Cox]

> > RFC793, where is lists the unused flag bits as "reserved".
> > That is pretty clear to me.  It just has to say that
> > they are reserved, and that is what it does.
> > 
> 
> Is the definition of "reserved" defined anywhere?  In a lot of specs,
> "reserved" means MBZ.
> 
> Note, that I'm not arguing with you.  I'm trying to pick this apart.

Reserved values are normally (as in 793) listed as reserved, must be zero.
The meaning of that in RFC literature is absolutely clear. That in the absence
of you supporting a newer feature using these bits the value must be set to
zero. You may not rely on it being zero from another host however.

-
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/

Re: hotmail not dealing with ECN

[Matti Aarnio]

On Thu, Jan 25, 2001 at 05:30:29PM -0800, David S. Miller wrote:
...
> Thirdly, it was widely discussed by the ECN reserachers on how to
> "detect ECN blackholes" sort to speak.  All such schemes suggested
> we unusable, it is not doable without impacting performance _and_
> violating existing RFCs.  Basically, you have to ignore a valid TCP
> reset to deal with some of the ECN holes out there, that is where such
> workaround attempts become full crap and are unsatisfactory for
> inclusion in any implementation much less an RFC.  Happily, we got the
> ECN folks to agree with Alexey and myself on these points.
> 
> So turning it off on a per-connection basis is not really an option.

  But could you nevertheless consider supplying a socket option for it ?
  By all means default it per sysctl, but allow clearing/setting by
  program too.

... 
> Later,
> David S. Miller
> davem@redhat.com

/Matti Aarnio
-
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/

Re: hotmail not dealing with ECN

[David S. Miller]

Matti Aarnio writes:
 >   But could you nevertheless consider supplying a socket option for it ?
 >   By all means default it per sysctl, but allow clearing/setting by
 >   program too.

No, because then people will do the wrong thing.

They will create intricate "ECN black lists" and make
their apps set the socket option based upon whether
a site is in the black list or not.

This is wrong, and allows the problematic sites to continue to be
delinquent.

If these sites gradually become more and more disconnected from
the rest of the internet, they will fix their kit.  Other schemes
so far have been met with reluctance on the part of these sites.

I do not want to condone mechanisms which allow people to make
crutches for these broken sites ad infinitum.

Later,
David S. Miller
davem@redhat.com

-
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/

Re: hotmail not dealing with ECN

[James Sutherland]

On Fri, 26 Jan 2001, David S. Miller wrote:

> 
> Matti Aarnio writes:
>  >   But could you nevertheless consider supplying a socket option for it ?
>  >   By all means default it per sysctl, but allow clearing/setting by
>  >   program too.
> 
> No, because then people will do the wrong thing.
> 
> They will create intricate "ECN black lists" and make
> their apps set the socket option based upon whether
> a site is in the black list or not.
> 
> This is wrong, and allows the problematic sites to continue to be
> delinquent.
> 
> If these sites gradually become more and more disconnected from
> the rest of the internet, they will fix their kit.  Other schemes
> so far have been met with reluctance on the part of these sites.
> 
> I do not want to condone mechanisms which allow people to make
> crutches for these broken sites ad infinitum.

A delayed retry without ECN might be a good compromise...

Every single connection to ECN-broken sites would work as normal - it
would just take an extra few seconds. Instead of "Hotmail doesn't
work!" it becomes "Hrm... Hotmail is fscking slow, but Yahoo is fine. I'll
use Yahoo". A few million of those, and suddenly Hotmail isn't so hot...

James.

-
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/

Re: hotmail not dealing with ECN

[Lars Marowsky-Bree]

On 2001-01-26T11:40:36,
   James Sutherland <jas88@cam.ac.uk> said:

> A delayed retry without ECN might be a good compromise...

_NO!!!!!_

Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
Perfection is our goal, excellence will be tolerated. -- J. Yahl

-
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/

Re: hotmail not dealing with ECN

[James Sutherland]

On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote:

> On 2001-01-26T11:40:36,
>    James Sutherland <jas88@cam.ac.uk> said:
> 
> > A delayed retry without ECN might be a good compromise...
> 
> _NO!!!!!_

Why? As it stands, I have ECN disabled. It's staying disabled until I know
it won't degrade my Net access.


James.

-
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/

Re: hotmail not dealing with ECN

[Lars Marowsky-Bree]

On 2001-01-26T13:44:53,
   James Sutherland <jas88@cam.ac.uk> said:

> > > A delayed retry without ECN might be a good compromise...
> > _NO!!!!!_
> Why? As it stands, I have ECN disabled. It's staying disabled until I know
> it won't degrade my Net access.

First, you are ignoring a TCP_RST, which means "stop trying". 

You would have to retry a connection with a new source port. How do you handle
cases where the application explicitly bound the socket to a specific source
port / source IP ?

Caching whether the site is able to speak ECN or not is also suboptimal if the
local site is opening lots of outgoing connections, like a proxy server. (Of
course, memory has gotten cheap)

_And_ it is solving the problem on the wrong end.

Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
Perfection is our goal, excellence will be tolerated. -- J. Yahl

-
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/

Re: hotmail not dealing with ECN

[Jamie Lokier]

Lars Marowsky-Bree wrote:
> First, you are ignoring a TCP_RST, which means "stop trying". 

That's why we stop when we receive the second TCP RST.
It's just like dropping due to congestion, which is of course perfectly
safe in moderation.

> You would have to retry a connection with a new source port. How do
> you handle cases where the application explicitly bound the socket to
> a specific source port / source IP ?

Applications tend not to.  Do we care about those that do?

> Caching whether the site is able to speak ECN or not is also
> suboptimal if the local site is opening lots of outgoing connections,
> like a proxy server. (Of course, memory has gotten cheap)
> 
> _And_ it is solving the problem on the wrong end.

It would not solve the problem at all, if there's no incentive to switch
to ECN.  But then, why force people to use ECN if there's no advantage
to it anyway?

Does ECN provide perceived benefits to the node using it?

-- Jamie
-
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/

Re: hotmail not dealing with ECN

[David S. Miller]

Jamie Lokier writes:
 > Does ECN provide perceived benefits to the node using it?

Yes, endpoints and intermediate routers can tell the TCP sender about
congestion instead of TCP having to guess about it based upon observed
packet drop.

It is a major enhancement to performance over any WAN.

The endpoint based congestion notification happens _now_ if both
sides speak ECN.  The router based notification will be happening
in the near future as Cisco and others deploy ECN speaking versions of
their router software.

Later,
David S. Miller
davem@redhat.com
-
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/

Re: hotmail not dealing with ECN

[Jamie Lokier]

David S. Miller wrote:
>  > Does ECN provide perceived benefits to the node using it?
> 
> Yes, endpoints and intermediate routers can tell the TCP sender about
> congestion instead of TCP having to guess about it based upon observed
> packet drop.
> 
> It is a major enhancement to performance over any WAN.
> 
> The endpoint based congestion notification happens _now_ if both
> sides speak ECN.  The router based notification will be happening
> in the near future as Cisco and others deploy ECN speaking versions of
> their router software.

So there is no need to force everyone to upgrade to ECN right away.
They will eventually do so for the performance increase.

Presumably ISPs also benefit from ECN because they need less bandwidth
for the same traffic -- fix your firewall and SAVE MONEY on pipes!!!

-- Jamie
-
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/

ECN

[Simon Kirby]

On Fri, Jan 26, 2001 at 07:14:42AM -0800, David S. Miller wrote:

> Jamie Lokier writes:
>  > Does ECN provide perceived benefits to the node using it?
> 
> Yes, endpoints and intermediate routers can tell the TCP sender about
> congestion instead of TCP having to guess about it based upon observed
> packet drop.
> 
> It is a major enhancement to performance over any WAN.
> 
> The endpoint based congestion notification happens _now_ if both
> sides speak ECN.  The router based notification will be happening
> in the near future as Cisco and others deploy ECN speaking versions of
> their router software.

Hmm... Just wondering: what does TCP then do when it receives this ECN
notification?  Try harder, try less?  Or does it get a specific packet
saying "I dropped your packet", and then the sender retransmits?

I suppose I could go find the RFC...

Simon-

[  Stormix Technologies Inc.  ][  NetNation Communications Inc. ]
[       sim@stormix.com       ][       sim@netnation.com        ]
[ Opinions expressed are not necessarily those of my employers. ]
-
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/

Re: ECN

[Andrea Arcangeli]

On Fri, Jan 26, 2001 at 12:05:56PM -0500, Simon Kirby wrote:
> Hmm... Just wondering: what does TCP then do when it receives this ECN
> notification?  Try harder, try less?  Or does it get a specific packet

It will act in the same way if it the packet was dropped (but the packet wasn't
dropped). That is quite obviously correct behaviour. The RFC also mentions that
different congestion control treatment would be unfair with the non-ECN capable
TCP connections (but obviously non-ECN TCP connections are just penalized with
the current algorithm so such argument doesn't make much sense to me, said that
the standard congestion control looks sane choice and it also avoids a mess in
the TCP code internals).

Andrea
-
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/

Re: hotmail not dealing with ECN

[Dominik Kubla]

On Fri, Jan 26, 2001 at 04:03:42PM +0100, Jamie Lokier wrote:
...
> Applications tend not to.  Do we care about those that do?

Apache? ... Sendmail? ... Samba? ... The class? ... Bueller? Bueller? ...

Don't be ridiculous!
  Dominik Kubla
-- 
http://petition.eurolinux.org/index_html - No Software Patents In Europe!
http://petition.lugs.ch/ (in Switzerland)
-
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/

Re: hotmail not dealing with ECN

[Jamie Lokier]

Dominik Kubla wrote:
> On Fri, Jan 26, 2001 at 04:03:42PM +0100, Jamie Lokier wrote:
> ...
> > Applications tend not to.  Do we care about those that do?
> 
> Apache? ... Sendmail? ... Samba? ... The class? ... Bueller? Bueller? ...

Yeah, Apache and Samba establish _outgoing_ connections with fixed
source ports.... Not!

Or do these broken firewalls let ECN flags out but not in?

-- Jamie
-
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/

Re: hotmail not dealing with ECN

[Dominik Kubla]

On Fri, Jan 26, 2001 at 04:27:07PM +0100, Jamie Lokier wrote:
...
> Yeah, Apache and Samba establish _outgoing_ connections with fixed
> source ports.... Not!

Oops! Of course. Brain-damage on my part.  Now where is that dammned
brown paper bag...

Dominik
-- 
          A lovely thing to see:                   Kobayashi Issa
     through the paper window's holes               (1763-1828)
                the galaxy.               [taken from: David Brin - Sundiver]
-
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/

Re: hotmail not dealing with ECN

[H. Peter Anvin]

Dominik Kubla wrote:
> 
> On Fri, Jan 26, 2001 at 04:27:07PM +0100, Jamie Lokier wrote:
> ...
> > Yeah, Apache and Samba establish _outgoing_ connections with fixed
> > source ports.... Not!
> 
> Oops! Of course. Brain-damage on my part.  Now where is that dammned
> brown paper bag...
> 

ftpd and sshd do, however.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

Re: hotmail not dealing with ECN

[Marian Jancar]

Dominik Kubla wrote:
> 
> > Applications tend not to.  Do we care about those that do?
> 
> Apache? ... Sendmail? ... Samba? ... The class? ... Bueller? Bueller? ...

They dont connect but listen on these specified ports.
-
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/

Re: hotmail not dealing with ECN

[H. Peter Anvin]

Jamie Lokier wrote:
> 
> Lars Marowsky-Bree wrote:
> > First, you are ignoring a TCP_RST, which means "stop trying".
> 
> That's why we stop when we receive the second TCP RST.
> It's just like dropping due to congestion, which is of course perfectly
> safe in moderation.
> 

No, you can't issue multiple connects in response to a single socket
option.  One can argue that it would have been OK for these firewalls to
drop ECN packets, but replying with RST is just too broken to live.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

Re: hotmail not dealing with ECN

[Dax Kelson]

Jamie Lokier said once upon a time (Fri, 26 Jan 2001):

> Does ECN provide perceived benefits to the node using it?

Why are you even making suggestions when you haven't even read the RFC?

It seems that knowing what ECN is would be prerequisite to engaging in
discussion about it.

Dax

-
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/

Re: hotmail not dealing with ECN

[Jamie Lokier]

Dax Kelson wrote:
> Jamie Lokier said once upon a time (Fri, 26 Jan 2001):
> 
> > Does ECN provide perceived benefits to the node using it?
> 
> Why are you even making suggestions when you haven't even read the RFC?
> 
> It seems that knowing what ECN is would be prerequisite to engaging in
> discussion about it.

I do know what ECN is thanks.  Whether it provides _actual_ perceived
benefits depends on how widely deployed ECN routers and servers are.

-- Jamie

-
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/

Re: ECN -? Anything _I_ need to do to allow it?

[List User]

I run a small ISP for my local community and have read some reports about
hotmail not supporting it et al.  I don't want to be in a position where MY
site doesn't support this if it's the correct thing to do.

Is there anything special that needs to be done (cisco router config,
firewall (ie, checkpoint)) to allow this information to pass?

Steve

-
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/

Re: ECN -? Anything _I_ need to do to allow it?

[Matti Aarnio]

On Fri, Jan 26, 2001 at 05:47:14PM -0600, List User wrote:
> I run a small ISP for my local community and have read some reports about
> hotmail not supporting it et al.  I don't want to be in a position where MY
> site doesn't support this if it's the correct thing to do.
> 
> Is there anything special that needs to be done (cisco router config,
> firewall (ie, checkpoint)) to allow this information to pass?

	Cisco IOSes (at routers) ignore the ECN presently.
	Somewhen along 12.2 (or a bit latter) those routers
	will start supporting ECN markup.

	On Cisco product lines, the PIX firewalls have had problems,
	but they weren't cisco product originally...

	Checkpoint seems to pass the ECN bit successfully, at least
	the one at my office passes.

> Steve

/Matti Aarnio
-
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/

Re: hotmail not dealing with ECN

[David S. Miller]

James Sutherland writes:
 > A delayed retry without ECN might be a good compromise...
 > 
 > Every single connection to ECN-broken sites would work as normal - it
 > would just take an extra few seconds. Instead of "Hotmail doesn't
 > work!" it becomes "Hrm... Hotmail is fscking slow, but Yahoo is fine. I'll
 > use Yahoo". A few million of those, and suddenly Hotmail isn't so hot...

No, as explained in previous emails, no retry scheme can work.

Hotmails failing machines, for example, send RST packets back when
they see ECN.  Ignoring valid TCP RST frames is unacceptable and
Linux will not do that as long as I am maintaining it.

Later,
David S. Miller
davem@redhat.com

-
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/

Re: hotmail not dealing with ECN

[James Sutherland]

On Fri, 26 Jan 2001, David S. Miller wrote:

> 
> James Sutherland writes:
>  > A delayed retry without ECN might be a good compromise...
>  > 
>  > Every single connection to ECN-broken sites would work as normal - it
>  > would just take an extra few seconds. Instead of "Hotmail doesn't
>  > work!" it becomes "Hrm... Hotmail is fscking slow, but Yahoo is fine. I'll
>  > use Yahoo". A few million of those, and suddenly Hotmail isn't so hot...
> 
> No, as explained in previous emails, no retry scheme can work.
> 
> Hotmails failing machines, for example, send RST packets back when
> they see ECN.  Ignoring valid TCP RST frames is unacceptable and
> Linux will not do that as long as I am maintaining it.

I was not suggesting ignoring these. OTOH, there is no reason to treat an
RST packet as "go away and never ever send traffic to this host again" -
i.e. trying another TCP connection, this time with ECN disabled, would be
acceptable.


James.

-
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/

Re: hotmail not dealing with ECN

[David S. Miller]

James Sutherland writes:
 > I was not suggesting ignoring these. OTOH, there is no reason to treat an
 > RST packet as "go away and never ever send traffic to this host again" -
 > i.e. trying another TCP connection, this time with ECN disabled, would be
 > acceptable.

The connection failed, RST means connection reset.  RST means all
state is corrupt and this connection must die.  It cannot be
interpreted in any other way.

Using it as a metric for ECN enabling is thus unacceptable.

Later,
David S. Miller
davem@redhat.com
-
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/

Re: hotmail not dealing with ECN

[Jamie Lokier]

David S. Miller wrote:
> The connection failed, RST means connection reset.  RST means all
> state is corrupt and this connection must die.  It cannot be
> interpreted in any other way.

Therefore build a new connection, using a new source port if necessary.

-- Jamie
-
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/

Re: hotmail not dealing with ECN

[James Sutherland]

On Fri, 26 Jan 2001, David S. Miller wrote:
> James Sutherland writes:
>  > I was not suggesting ignoring these. OTOH, there is no reason to treat an
>  > RST packet as "go away and never ever send traffic to this host again" -
>  > i.e. trying another TCP connection, this time with ECN disabled, would be
>  > acceptable.
> 
> The connection failed, RST means connection reset.  RST means all
> state is corrupt and this connection must die.  It cannot be
> interpreted in any other way.

Obviously. The connection is now dead. However, trying to make a new
connection with different settings is perfectly reasonable.

> Using it as a metric for ECN enabling is thus unacceptable.

Why? The connection is dead, but there is nothing to prevent attempting
another connection.


James.

-
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/

Re: hotmail not dealing with ECN

[Lars Marowsky-Bree]

On 2001-01-26T15:08:21,
   James Sutherland <jas88@cam.ac.uk> said:

> Obviously. The connection is now dead. However, trying to make a new
> connection with different settings is perfectly reasonable.

No.

If connect() suddenly did two connection attempts instead of one, just how
many timeouts might that break?

> Why? The connection is dead, but there is nothing to prevent attempting
> another connection.

Right. And thats why connect() returns an error and retries are handled in
userspace.

Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
Perfection is our goal, excellence will be tolerated. -- J. Yahl

-
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/

Re: hotmail not dealing with ECN

[James Sutherland]

On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote:

> On 2001-01-26T15:08:21,
>    James Sutherland <jas88@cam.ac.uk> said:
> 
> > Obviously. The connection is now dead. However, trying to make a new
> > connection with different settings is perfectly reasonable.
> 
> No.
> 
> If connect() suddenly did two connection attempts instead of one, just how
> many timeouts might that break?

None. You time the request out as normal, if it does time out.

> > Why? The connection is dead, but there is nothing to prevent attempting
> > another connection.
> 
> Right. And thats why connect() returns an error and retries are handled in
> userspace.

Except you can't retry without ECN, because DaveM wants to do a Microsoft
and force ECN on everyone, whether they like it or not. If ECN is so
wonderful, why doesn't anybody actually WANT to use it anyway?


James.

-
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/

Re: hotmail not dealing with ECN

[Chris Ricker]

On Fri, 26 Jan 2001, James Sutherland wrote:

> Except you can't retry without ECN, because DaveM wants to do a Microsoft
> and force ECN on everyone, whether they like it or not.

Don't be absurd.  It's a compile-time option that nobody, not even Dave
Miller, is forcing you to compile into your kernel.

> If ECN is so wonderful, why doesn't anybody actually WANT to use it
> anyway?

Lots of people do.  Lots of other people (such as, in this case, hotmail)
will never upgrade their software until the groundswell of complaints is
more expensive than their perception of the cost of upgrading....

later,
chris

-- 
Chris Ricker                                               kaboom@gatech.edu
                                              chris.ricker@genetics.utah.edu

-
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/

Re: hotmail not dealing with ECN

[Henning P. Schmiedehausen]

kaboom@gatech.edu (Chris Ricker) writes:

>> If ECN is so wonderful, why doesn't anybody actually WANT to use it
>> anyway?

>Lots of people do.  Lots of other people (such as, in this case, hotmail)
>will never upgrade their software until the groundswell of complaints is
>more expensive than their perception of the cost of upgrading....

Well, I guess, this is the price we must pay for having a monoculture
(a Cisco-powered) internet. If the single source of routers, switches
and network components (speak: Cisco) makes a single mistake in a
release version of their software (speak: drop ECN frames), everyone
suffers.

Cisco: If I buy a _new_ PIIX oder LDIR today, do I get an ECN capable
IOS or not? If not, will my CCNA know about this and upgrade my Box
before deploying?

Everyone I know and their brothers, that use Cisco Equipment, have a
support contract with Cisco. Why not push an "mandatory upgrade" along
this path once the ECN leaves "experimental" status.

But I definitely agree with HPA, that forcing ECN in its current state
on all users is unacceptable.

Solution that I see: 

DaveM at RedHat ships Kernels with ECN enabled per default.
RedHat ships Distributions with net.ipv4.ip_ecn = 0 in /etc/sysctl.conf

Ah, the small bliss of diversity... ;-) (And this means not, running
both flavors of Linux, Debian _and_ RedHat... ;-) )

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   
-
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/

Re: hotmail not dealing with ECN

[Matti Aarnio]

On Fri, Jan 26, 2001 at 06:37:12PM +0000, Henning P. Schmiedehausen wrote:
... 
> Cisco: If I buy a _new_ PIIX oder LDIR today, do I get an ECN capable
> IOS or not? If not, will my CCNA know about this and upgrade my Box
> before deploying?

  That cisco box is called  PIX -- PIIX sounds like some intel thing..
  Current baseline binary contains ECN, and CCNA may or may not know it.

  Oh yes, PIX code is not IOS, it is something else -- because it wasn't
  Cisco product originally, but something what Cisco bought...

  I haven't followed up on what Local Directory product it, probably same
  PC hardware (+ disk) as PIX, but a bit different software suite.

> Everyone I know and their brothers, that use Cisco Equipment, have a
> support contract with Cisco. Why not push an "mandatory upgrade" along
> this path once the ECN leaves "experimental" status.

  Bruhaha...  PIX has MailGuard feature, which fucks up SMTP protocol
  royally in some old versions.  I see that buggy version still running
  deployed even though fixes were done back in May 1998 ...
  (http://www.zmailer.org/cisco-pix.html)

  Why do I see it ?  VGER's ZMailer uses extensively that "rare" extended
  SMTP feature which is where it happens, and my employer runs that same
  software in couple large ISP SMTP relays..

> 	Regards
> 		Henning

/Matti Aarnio
-
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/

Re: hotmail not dealing with ECN

[Jeremy M. Dolan]

On Fri, 26 Jan 2001 15:29:51 +0000, James Sutherland wrote:
> Except you can't retry without ECN, because DaveM wants to do a Microsoft
> and force ECN on everyone, whether they like it or not.

Who's forcing? You have to *SPECIFICALLY* enable it in the config,
ignoring the notice in the help text that there are "many" sites that
will be unaccessible to you with this feature turned on.

In a (barely) related note, I'm reminded of SYN cookies. Are there
certain firewalls/hosts out there that choke on these as well? If not,
why are they still disabled by default, not only required to be
config'd in, but to set a sysctl each run. (Even more work then ECN!)

Also, is there any way to force SYN cookies for all connections, not
just have them sent out when the queue is full?

/jmd (Who is waiting for the ZDNet story, "Linux 2.4 baned from .uk")
-
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/

Re: hotmail not dealing with ECN

[Jamie Lokier]

Lars Marowsky-Bree wrote:
> If connect() suddenly did two connection attempts instead of one, just how
> many timeouts might that break?

Timeouts are already broken by applications that repeatedly call
connect().  You'd get better timeout behaviour by letting the kernel
enforce backoff.

> > Why? The connection is dead, but there is nothing to prevent attempting
> > another connection.
> 
> Right. And thats why connect() returns an error and retries are handled in
> userspace.

And this is fine.  Can we be permitted to handle a retry in userspace
without fancy options (ECN, SACK, large windows etc.)?

-- Jamie
-
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/

Re: hotmail not dealing with ECN

[Drago Goricanec]

At Fri, 26 Jan 2001 15:08:21 +0000 (GMT),
James Sutherland <jas88@cam.ac.uk> wrote:
> 
> On Fri, 26 Jan 2001, David S. Miller wrote:
> > James Sutherland writes:
> >  > I was not suggesting ignoring these. OTOH, there is no reason to treat an
> >  > RST packet as "go away and never ever send traffic to this host again" -
> >  > i.e. trying another TCP connection, this time with ECN disabled, would be
> >  > acceptable.
> > 
> > The connection failed, RST means connection reset.  RST means all
> > state is corrupt and this connection must die.  It cannot be
> > interpreted in any other way.
> 
> Obviously. The connection is now dead. However, trying to make a new
> connection with different settings is perfectly reasonable.

Yes for the application, but not for the kernel.  The kernel should
not make any assumptions about the reason for a RST.

Can you just picture if we implement what you are suggesting?  Now
every single outgoing connection to a non-existant port or for any
other reason that returns a RST will have two complete connect cycles.
That's bad behavior and will not be tolerated.

On top of that, we would have to maintain extra state to decide
whether the previous request was a SYN with ECN or some other scenario
to avoid reacting to every RST we get.  Unnecessary bloat!

> > Using it as a metric for ECN enabling is thus unacceptable.
> 
> Why? The connection is dead, but there is nothing to prevent attempting
> another connection.

I fully support David Miller on this issue.  Let Linux lead the path
to full adoption of ECN, and we'll all be better for it in the long
run.

Drago
-
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/

Re: hotmail not dealing with ECN

[Jamie Lokier]

James Sutherland wrote:
> I was not suggesting ignoring these. OTOH, there is no reason to treat an
> RST packet as "go away and never ever send traffic to this host again" -
> i.e. trying another TCP connection, this time with ECN disabled, would be
> acceptable.

Using a different source port number, even.

-- Jamie
-
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/

Re: hotmail not dealing with ECN

[Olaf Titz]

> > I was not suggesting ignoring these. OTOH, there is no reason to treat an
> > RST packet as "go away and never ever send traffic to this host again" -
> > i.e. trying another TCP connection, this time with ECN disabled, would be
> > acceptable.
> 
> Using a different source port number, even.

But that has to be done on the application level, which means we need a
socket option to not use ECN. It is not acceptable that the kernel changes
the port number of a socket which already has one, or any application which
uses getsockname() on the connecting socket will horribly break.[1]

Olaf

[1] and this means any application using libsocks5, so nobody tell me "no
sane application does need this".
-
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/

Re: hotmail not dealing with ECN

[Jamie Lokier]

David S. Miller wrote:
>  > Every single connection to ECN-broken sites would work as normal - it
>  > would just take an extra few seconds. Instead of "Hotmail doesn't
>  > work!" it becomes "Hrm... Hotmail is fscking slow, but Yahoo is fine. I'll
>  > use Yahoo". A few million of those, and suddenly Hotmail isn't so hot...
> 
> No, as explained in previous emails, no retry scheme can work.
> 
> Hotmails failing machines, for example, send RST packets back when
> they see ECN.  Ignoring valid TCP RST frames is unacceptable and
> Linux will not do that as long as I am maintaining it.

How about this for a deployment plan:

Ignore only _one_ RST frame (the first one), either per destination IP
address or per connection.  It's equivalent to a little "controlled"
network loss :-)

First SYN includes ECN.  Second and subsequent SYNs do not.

This won't provide the benefits of ECN on a heavily congested network,
but it is a start on a lightly congested one.  In a few months you can
flip the switch to stop ignoring RST frames and enable ECN on all SYNs.

-- Jamie
-
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/

Re: hotmail not dealing with ECN

[David S. Miller]

Jamie Lokier writes:
 > Ignore only _one_ RST frame (the first one)

Hmmm... let me say it for the hundreth time.

Valid RST frames cannot be ignored under any circumstances.
It is a full failure, period.

The RST frame does not indicate why it happened, so you may not intuit
the reason, "retry" the connection, or anything else like that.  It
means connection failed, and we must return error from connect().

Nothing else is acceptable.

Later,
David S. Miller
davem@redhat.com
-
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/

Re: hotmail not dealing with ECN

[Lars Marowsky-Bree]

On 2001-01-26T06:39:36,
   "David S. Miller" <davem@redhat.com> said:

> The RST frame does not indicate why it happened, so you may not intuit
> the reason, "retry" the connection, or anything else like that.  It
> means connection failed, and we must return error from connect().
> 
> Nothing else is acceptable.

That would mean that the people worried about this should write a
wrapper-library for the connect() call, and maybe add a no_ecn flag to a
socket, and leave the kernel alone.

Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
Perfection is our goal, excellence will be tolerated. -- J. Yahl

-
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/

Re: hotmail not dealing with ECN

[David S. Miller]

Lars Marowsky-Bree writes:
 > That would mean that the people worried about this should write a
 > wrapper-library for the connect() call, and maybe add a no_ecn flag to a
 > socket, and leave the kernel alone.

I'm not adding a no_ecn option for sockets.  See my response
to Matti Aarnio earlier today on this list for the
reasons why.

People must fix their firewalls, there is no other way to
fix the problem and get ECN properly deployed.  I'm ceasing
conversation on this thread from this point forward.

Later,
David S. Miller
davem@redhat.com
-
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/

Re: hotmail not dealing with ECN

[Jamie Lokier]

David S. Miller wrote:
> People must fix their firewalls, there is no other way to
> fix the problem and get ECN properly deployed.  I'm ceasing
> conversation on this thread from this point forward.

I suggest the ISPs fix their firewalls to strip ECN coming from their
Linux clients, providing a neat and effective solution. :-)

-- Jamie
-
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/

Re: hotmail not dealing with ECN

[Thunder from the hill]

> Hotmails failing machines, for example, send RST packets back when
> they see ECN.  Ignoring valid TCP RST frames is unacceptable and
> Linux will not do that as long as I am maintaining it.
Whadda word!
---
Woah... I did a "cat /boot/vmlinuz >> /dev/audio" - and I think I heard
god...

-
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/

Re: hotmail not dealing with ECN

[Thunder from the hill]

> Every single connection to ECN-broken sites would work as normal - it
> would just take an extra few seconds. Instead of "Hotmail doesn't
> work!" it becomes "Hrm... Hotmail is fscking slow, but Yahoo is fine. I'll
> use Yahoo". A few million of those, and suddenly Hotmail isn't so hot...
I think Yahoo's cables will become hot then instead. And hot cables mean
slower connections.
So what?

Thunder
---
Woah... I did a "cat /boot/vmlinuz >> /dev/audio" - and I think I heard
god...


-
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/