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 th
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 historica
> "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&content=/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 thin
[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
> conne
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 a
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. It's
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 protocol
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 machi
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
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 th
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 *experime
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 interpre
[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 pas
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 wa
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 wan
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. Imagin
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 conn
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 woul
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 I
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 adm
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
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: accordi
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.
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 wh
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, 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&content=/focus/ids/articles/portscan.html
>
> the site is now ATM -- can someone briefly expla
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"
35 matches
Mail list logo
