On Wed, Jan 31, 2001 at 06:02:17PM +, Alan Cox wrote:
> > No. ECN is essential to the continued stability of the Internet. Without
> > probabilistic queuing (i.e. RED) and ECN the Internet will continue to have
> > retransmit synchronization and once congested stay congested until people get
On Wed, Jan 31, 2001 at 06:02:17PM +, Alan Cox wrote:
No. ECN is essential to the continued stability of the Internet. Without
probabilistic queuing (i.e. RED) and ECN the Internet will continue to have
retransmit synchronization and once congested stay congested until people get
> No. ECN is essential to the continued stability of the Internet. Without
> probabilistic queuing (i.e. RED) and ECN the Internet will continue to have
> retransmit synchronization and once congested stay congested until people get
> frustrated and give it up for a little bit.
Arguably so. In
No. ECN is essential to the continued stability of the Internet. Without
probabilistic queuing (i.e. RED) and ECN the Internet will continue to have
retransmit synchronization and once congested stay congested until people get
frustrated and give it up for a little bit.
Arguably so. In
On Sun, 28 Jan 2001, Pavel Machek wrote:
>
> Does not that mean that Linux 2.0.10 mistakenly announces it is ECN
> capable when offered ECN connection?
In fact it does. But as someone mentioned, ECN is resilient to this.
i.e this will be trapped and no ECN connection will happen.
For
At 14:55 -0800 29-01-2001, Pete Zaitcev wrote:
>So far I fail to see how a repainted NAK, kludged into a NAKless protocol,
>would improve stability of the Internet. If anything, it is going to
>exaggerate traffic oscillations.
If anything RED will *reduce* oscillations by alleviating retransmit
> From: Gregory Maxwell ([EMAIL PROTECTED])
> Date: Sun Jan 28 2001 - 14:42:04 EST
>
> On Sun, Jan 28, 2001 at 01:29:52PM +, James Sutherland wrote:
> > > There is nothing silly with the decision, davem is simply a modern day
> > > internet hero.
> >
> > No. If it were something
> "Albert" == Albert D Cahalan <[EMAIL PROTECTED]> writes:
>> /* NOTE. draft-ietf-tcpimpl-pmtud-01.txt requires pmtu black hole
>> detection. :-( It is place to make it. It is not made. I do not
>> want
Albert> So the Linux code is broken. ("requires")
Since when is code broken for failing
On Sun, 28 Jan 2001, Pavel Machek wrote:
> Does not that mean that Linux 2.0.10 mistakenly announces it is ECN
> capable when offered ECN connection?
No, the RFC deals with this.
Walter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Hi!
> > suggested blocking ECN. Article at:
> >
> >
>http://www.securityfocus.com/frames/?focus=ids=/focus/ids/articles/portscan.html
> >
> > the site is now ATM -- can someone briefly explain the logic in
> > blocking it?
>
> It is Queso they quoted not nmap, sorry -- same thing.
>
[James Sutherland]
> That depends what you mean by "retry"; I wanted the ability to
> attempt a non-ECN connection. i.e. if I'm a mailserver, and try
> connecting to one of Hotmail's MX hosts with ECN, I'll get RST every
> time. I would like to be able to retry with ECN disabled for that
>
[James Sutherland]
That depends what you mean by "retry"; I wanted the ability to
attempt a non-ECN connection. i.e. if I'm a mailserver, and try
connecting to one of Hotmail's MX hosts with ECN, I'll get RST every
time. I would like to be able to retry with ECN disabled for that
Hi!
suggested blocking ECN. Article at:
http://www.securityfocus.com/frames/?focus=idscontent=/focus/ids/articles/portscan.html
the site is now ATM -- can someone briefly explain the logic in
blocking it?
It is Queso they quoted not nmap, sorry -- same thing.
The idea is
On Sun, 28 Jan 2001, Pavel Machek wrote:
Does not that mean that Linux 2.0.10 mistakenly announces it is ECN
capable when offered ECN connection?
No, the RFC deals with this.
Walter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
"Albert" == Albert D Cahalan [EMAIL PROTECTED] writes:
/* NOTE. draft-ietf-tcpimpl-pmtud-01.txt requires pmtu black hole
detection. :-( It is place to make it. It is not made. I do not
want
Albert So the Linux code is broken. ("requires")
Since when is code broken for failing to abide by
From: Gregory Maxwell ([EMAIL PROTECTED])
Date: Sun Jan 28 2001 - 14:42:04 EST
On Sun, Jan 28, 2001 at 01:29:52PM +, James Sutherland wrote:
There is nothing silly with the decision, davem is simply a modern day
internet hero.
No. If it were something essential, perhaps,
At 14:55 -0800 29-01-2001, Pete Zaitcev wrote:
So far I fail to see how a repainted NAK, kludged into a NAKless protocol,
would improve stability of the Internet. If anything, it is going to
exaggerate traffic oscillations.
If anything RED will *reduce* oscillations by alleviating retransmit
James Sutherland writes:
> Except you can detect and deal with these "PMTU black holes". Just as you
> should detect and deal with ECN black holes. Maybe an ideal Internet
> wouldn't have them, but this one does. If you can find an ideal Internet,
> go code for it: until then, stick with the
David Lang writes:
> I am behind a raptor firewall and ran the test that David M posted a
> couple days ago and was able to sucessfully connect to his test machine.
>
> so either raptor tolorates ECN (at least in the verion I am running) or
> the test was not valid.
Did you actually list
ate: Sun, 28 Jan 2001 11:15:24 -0500 (EST)
> From: jamal <[EMAIL PROTECTED]>
> To: James Sutherland <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: ECN: Clearing the air (fwd)
>
>
>
> On Sun, 28 Jan 2001, James Sutherland wrote:
>
> > On Sun, 28 Ja
Gregory Maxwell wrote:
> > > There is nothing silly with the decision, davem is simply a modern day
> > > internet hero.
> >
> > No. If it were something essential, perhaps, but it's just a minor
> > performance tweak to cut packet loss over congested links. It's not
> > IPv6. It's not PMTU.
On Sun, Jan 28, 2001 at 01:08:40PM -0500, jamal wrote:
> On Sun, 28 Jan 2001, Rogier Wolff wrote:
>
> > A sufficiently paranoid firewall should block requests that he doesn't
> > fully understand. ECN was in this category, so old firewalls are
> > "right" to block these. (Sending an 'RST' is not
On Sun, Jan 28, 2001 at 05:11:20PM +, James Sutherland wrote:
[snip]
> > The simplest thing in this chaos is to fix the firewall because it is in
> > violation to begin with.
>
> It is not in violation, and you can't fix it: it's not yours.
[snip]
> > It's too bad we end up defining
On Sun, Jan 28, 2001 at 02:09:19PM +, James Sutherland wrote:
> On Sun, 28 Jan 2001, Ben Ford wrote:
> > Do keep in mind, we aren't breaking connectivity, they are.
>
> Let me guess: you're a lawyer? :-)
>
> This is a very strange definition: if someone makes a change such that
> their
On Sun, Jan 28, 2001 at 06:04:17AM -0800, Ben Ford wrote:
> James Sutherland wrote:
[snip]
> > those firewalls should be updated to allow ECN-enabled packets
> > through. However, to break connectivity to such sites deliberately just
> > because they are not supporting an *experimental*
On Sun, Jan 28, 2001 at 01:29:52PM +, James Sutherland wrote:
> > There is nothing silly with the decision, davem is simply a modern day
> > internet hero.
>
> No. If it were something essential, perhaps, but it's just a minor
> performance tweak to cut packet loss over congested links. It's
On Sun, 28 Jan 2001, Rogier Wolff wrote:
> > This would have been easier. The firewall operators were not
> > provided with this option. This is hard-coded. I agree with the rest
> > of your message.
>
> Take "configure" with a bit of liberty. Because the firewall vendor
> chose to hard-code
jamal wrote:
>
>
> On Sun, 28 Jan 2001, Rogier Wolff wrote:
>
> > jamal wrote:
> > > > Yes,
> > > > those firewalls should be updated to allow ECN-enabled packets
> > > > through. However, to break connectivity to such sites deliberately just
> > > > because they are not supporting an
On Sun, 28 Jan 2001, Rogier Wolff wrote:
> jamal wrote:
> > > Yes,
> > > those firewalls should be updated to allow ECN-enabled packets
> > > through. However, to break connectivity to such sites deliberately just
> > > because they are not supporting an *experimental* extension to the current
On Sun, 28 Jan 2001, James Sutherland wrote:
> On Sun, 28 Jan 2001, jamal wrote:
> > We are allowing two rules to be broken, one is RFC 793 which
> > clearly and unambigously defines what a RST means. the second is
>
> This is NOT being violated: the RST is honoured as normal.
You are
[EMAIL PROTECTED] (Rogier Wolff) writes:
> If the firewall operator is sufficiently paranoid, they can say: "We
> don't trust the ECN implementation on our hosts behind the firewall,
> so we want to disable it.".
In which case would the "correct" action not be to zero the ECN bits
of packets
jamal wrote:
> > Yes,
> > those firewalls should be updated to allow ECN-enabled packets
> > through. However, to break connectivity to such sites deliberately just
> > because they are not supporting an *experimental* extension to the current
> > protocols is rather silly.
> >
>
> This is the
On Sun, 28 Jan 2001, jamal wrote:
> On Sun, 28 Jan 2001, James Sutherland wrote:
> > On Sun, 28 Jan 2001, jamal wrote:
> > > There were people who made the suggestion that TCP should retry after a
> > > RST because it "might be an anti-ECN path"
> >
> > That depends what you mean by "retry"; I
On Sun, 28 Jan 2001, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> James Sutherland <[EMAIL PROTECTED]> wrote:
> >On Sun, 28 Jan 2001, jamal wrote:
> >> The internet is a form of organized chaos, sometimes you gotta make
> >> these type of decisions to get things done.
On Sun, 28 Jan 2001, James Sutherland wrote:
> On Sun, 28 Jan 2001, jamal wrote:
> > There were people who made the suggestion that TCP should retry after a
> > RST because it "might be an anti-ECN path"
>
> That depends what you mean by "retry"; I wanted the ability to attempt a
> non-ECN
James Sutherland wrote:
> On Sun, 28 Jan 2001, Ben Ford wrote:
>
> > James Sutherland wrote:
> >
> > > I'm sure we all know what the IETF is, and where ECN came from. I haven't
> > > seen anyone suggesting ignoring RST, either: DM just imagined that,
> > > AFAICS.
> > >
> > > The one point I
On Sun, Jan 28, 2001 at 01:29:52PM +, James Sutherland wrote:
> > The internet is a form of organized chaos, sometimes you gotta make
> > these type of decisions to get things done. Imagine the joy _most_
> > people would get flogging all firewall admins who block all ICMP.
>
> Blocking out
In article <[EMAIL PROTECTED]>,
James Sutherland <[EMAIL PROTECTED]> wrote:
>On Sun, 28 Jan 2001, jamal wrote:
>> The internet is a form of organized chaos, sometimes you gotta make
>> these type of decisions to get things done. Imagine the joy _most_
>> people would get flogging all firewall
On Sun, 28 Jan 2001, Ben Ford wrote:
> James Sutherland wrote:
>
> > I'm sure we all know what the IETF is, and where ECN came from. I haven't
> > seen anyone suggesting ignoring RST, either: DM just imagined that,
> > AFAICS.
> >
> > The one point I would like to make, though, is that
James Sutherland wrote:
> I'm sure we all know what the IETF is, and where ECN came from. I haven't
> seen anyone suggesting ignoring RST, either: DM just imagined that,
> AFAICS.
>
> The one point I would like to make, though, is that firewalls are NOT
> "brain-damaged" for blocking ECN:
On Sun, 28 Jan 2001, jamal wrote:
> On Sun, 28 Jan 2001, James Sutherland wrote:
>
> > I'm sure we all know what the IETF is, and where ECN came from. I haven't
> > seen anyone suggesting ignoring RST, either: DM just imagined that,
> > AFAICS.
>
> The email was not necessarily intended for
On Sun, 28 Jan 2001, James Sutherland wrote:
> I'm sure we all know what the IETF is, and where ECN came from. I haven't
> seen anyone suggesting ignoring RST, either: DM just imagined that,
> AFAICS.
The email was not necessarily intended for you. You just pulled the pin.
There were people
I'm sure we all know what the IETF is, and where ECN came from. I haven't
seen anyone suggesting ignoring RST, either: DM just imagined that,
AFAICS.
The one point I would like to make, though, is that firewalls are NOT
"brain-damaged" for blocking ECN: according to the RFCs governing
firewalls,
I'm sure we all know what the IETF is, and where ECN came from. I haven't
seen anyone suggesting ignoring RST, either: DM just imagined that,
AFAICS.
The one point I would like to make, though, is that firewalls are NOT
"brain-damaged" for blocking ECN: according to the RFCs governing
firewalls,
On Sun, 28 Jan 2001, James Sutherland wrote:
I'm sure we all know what the IETF is, and where ECN came from. I haven't
seen anyone suggesting ignoring RST, either: DM just imagined that,
AFAICS.
The email was not necessarily intended for you. You just pulled the pin.
There were people who
On Sun, 28 Jan 2001, jamal wrote:
On Sun, 28 Jan 2001, James Sutherland wrote:
I'm sure we all know what the IETF is, and where ECN came from. I haven't
seen anyone suggesting ignoring RST, either: DM just imagined that,
AFAICS.
The email was not necessarily intended for you. You just
James Sutherland wrote:
I'm sure we all know what the IETF is, and where ECN came from. I haven't
seen anyone suggesting ignoring RST, either: DM just imagined that,
AFAICS.
The one point I would like to make, though, is that firewalls are NOT
"brain-damaged" for blocking ECN: according to
On Sun, 28 Jan 2001, Ben Ford wrote:
James Sutherland wrote:
I'm sure we all know what the IETF is, and where ECN came from. I haven't
seen anyone suggesting ignoring RST, either: DM just imagined that,
AFAICS.
The one point I would like to make, though, is that firewalls are NOT
In article [EMAIL PROTECTED],
James Sutherland [EMAIL PROTECTED] wrote:
On Sun, 28 Jan 2001, jamal wrote:
The internet is a form of organized chaos, sometimes you gotta make
these type of decisions to get things done. Imagine the joy _most_
people would get flogging all firewall admins who
On Sun, Jan 28, 2001 at 01:29:52PM +, James Sutherland wrote:
The internet is a form of organized chaos, sometimes you gotta make
these type of decisions to get things done. Imagine the joy _most_
people would get flogging all firewall admins who block all ICMP.
Blocking out ICMP
James Sutherland wrote:
On Sun, 28 Jan 2001, Ben Ford wrote:
James Sutherland wrote:
I'm sure we all know what the IETF is, and where ECN came from. I haven't
seen anyone suggesting ignoring RST, either: DM just imagined that,
AFAICS.
The one point I would like to make,
On Sun, 28 Jan 2001, James Sutherland wrote:
On Sun, 28 Jan 2001, jamal wrote:
There were people who made the suggestion that TCP should retry after a
RST because it "might be an anti-ECN path"
That depends what you mean by "retry"; I wanted the ability to attempt a
non-ECN connection.
On Sun, 28 Jan 2001, Miquel van Smoorenburg wrote:
In article [EMAIL PROTECTED],
James Sutherland [EMAIL PROTECTED] wrote:
On Sun, 28 Jan 2001, jamal wrote:
The internet is a form of organized chaos, sometimes you gotta make
these type of decisions to get things done. Imagine the joy
On Sun, 28 Jan 2001, jamal wrote:
On Sun, 28 Jan 2001, James Sutherland wrote:
On Sun, 28 Jan 2001, jamal wrote:
There were people who made the suggestion that TCP should retry after a
RST because it "might be an anti-ECN path"
That depends what you mean by "retry"; I wanted the
jamal wrote:
Yes,
those firewalls should be updated to allow ECN-enabled packets
through. However, to break connectivity to such sites deliberately just
because they are not supporting an *experimental* extension to the current
protocols is rather silly.
This is the way it's done
[EMAIL PROTECTED] (Rogier Wolff) writes:
If the firewall operator is sufficiently paranoid, they can say: "We
don't trust the ECN implementation on our hosts behind the firewall,
so we want to disable it.".
In which case would the "correct" action not be to zero the ECN bits
of packets
On Sun, 28 Jan 2001, James Sutherland wrote:
On Sun, 28 Jan 2001, jamal wrote:
We are allowing two rules to be broken, one is RFC 793 which
clearly and unambigously defines what a RST means. the second is
This is NOT being violated: the RST is honoured as normal.
You are interpreting
On Sun, 28 Jan 2001, Rogier Wolff wrote:
jamal wrote:
Yes,
those firewalls should be updated to allow ECN-enabled packets
through. However, to break connectivity to such sites deliberately just
because they are not supporting an *experimental* extension to the current
protocols
jamal wrote:
On Sun, 28 Jan 2001, Rogier Wolff wrote:
jamal wrote:
Yes,
those firewalls should be updated to allow ECN-enabled packets
through. However, to break connectivity to such sites deliberately just
because they are not supporting an *experimental* extension to
On Sun, 28 Jan 2001, Rogier Wolff wrote:
This would have been easier. The firewall operators were not
provided with this option. This is hard-coded. I agree with the rest
of your message.
Take "configure" with a bit of liberty. Because the firewall vendor
chose to hard-code this into
On Sun, Jan 28, 2001 at 01:29:52PM +, James Sutherland wrote:
There is nothing silly with the decision, davem is simply a modern day
internet hero.
No. If it were something essential, perhaps, but it's just a minor
performance tweak to cut packet loss over congested links. It's not
On Sun, Jan 28, 2001 at 06:04:17AM -0800, Ben Ford wrote:
James Sutherland wrote:
[snip]
those firewalls should be updated to allow ECN-enabled packets
through. However, to break connectivity to such sites deliberately just
because they are not supporting an *experimental* extension to
On Sun, Jan 28, 2001 at 02:09:19PM +, James Sutherland wrote:
On Sun, 28 Jan 2001, Ben Ford wrote:
Do keep in mind, we aren't breaking connectivity, they are.
Let me guess: you're a lawyer? :-)
This is a very strange definition: if someone makes a change such that
their machine can
On Sun, Jan 28, 2001 at 05:11:20PM +, James Sutherland wrote:
[snip]
The simplest thing in this chaos is to fix the firewall because it is in
violation to begin with.
It is not in violation, and you can't fix it: it's not yours.
[snip]
It's too bad we end up defining protocols using
On Sun, Jan 28, 2001 at 01:08:40PM -0500, jamal wrote:
On Sun, 28 Jan 2001, Rogier Wolff wrote:
A sufficiently paranoid firewall should block requests that he doesn't
fully understand. ECN was in this category, so old firewalls are
"right" to block these. (Sending an 'RST' is not
Gregory Maxwell wrote:
There is nothing silly with the decision, davem is simply a modern day
internet hero.
No. If it were something essential, perhaps, but it's just a minor
performance tweak to cut packet loss over congested links. It's not
IPv6. It's not PMTU. It's not even
, 28 Jan 2001 11:15:24 -0500 (EST)
From: jamal [EMAIL PROTECTED]
To: James Sutherland [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: ECN: Clearing the air (fwd)
On Sun, 28 Jan 2001, James Sutherland wrote:
On Sun, 28 Jan 2001, jamal wrote:
There were people who made
David Lang writes:
I am behind a raptor firewall and ran the test that David M posted a
couple days ago and was able to sucessfully connect to his test machine.
so either raptor tolorates ECN (at least in the verion I am running) or
the test was not valid.
Did you actually list a
James Sutherland writes:
Except you can detect and deal with these "PMTU black holes". Just as you
should detect and deal with ECN black holes. Maybe an ideal Internet
wouldn't have them, but this one does. If you can find an ideal Internet,
go code for it: until then, stick with the
On Sun, 28 Jan 2001, Chris Wedgwood wrote:
> On Sat, Jan 27, 2001 at 07:23:51PM -0500, jamal wrote:
>
> suggested blocking ECN. Article at:
>
>
>http://www.securityfocus.com/frames/?focus=ids=/focus/ids/articles/portscan.html
>
> the site is now ATM -- can someone briefly explain the
On Sat, 27 Jan 2001, jamal wrote:
>
> - ECN does not break things. It's brain damaged firewalls, Intrusion
> detection systems, and load balancers that should be shot.
> One intrusion detection "expert" was quoted suggesting the blocking of ECN
> bits should be blocked because "nmap uses them"
Just proves i am not on lk
-- Forwarded message --
Date: Sat, 27 Jan 2001 19:05:38 -0500 (EST)
From: jamal <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: ECN: Clearing the air
On Fri, 26 Jan 2001 15:29:51 +, James Sutherland wrote:
> E
Just proves i am not on lk
-- Forwarded message --
Date: Sat, 27 Jan 2001 19:05:38 -0500 (EST)
From: jamal [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: ECN: Clearing the air
On Fri, 26 Jan 2001 15:29:51 +, James Sutherland wrote:
Except you can't
On Sat, 27 Jan 2001, jamal wrote:
- ECN does not break things. It's brain damaged firewalls, Intrusion
detection systems, and load balancers that should be shot.
One intrusion detection "expert" was quoted suggesting the blocking of ECN
bits should be blocked because "nmap uses them" to
On Sun, 28 Jan 2001, Chris Wedgwood wrote:
On Sat, Jan 27, 2001 at 07:23:51PM -0500, jamal wrote:
suggested blocking ECN. Article at:
http://www.securityfocus.com/frames/?focus=idscontent=/focus/ids/articles/portscan.html
the site is now ATM -- can someone briefly explain the
75 matches
Mail list logo
