Re: ECN: Clearing the air (fwd)
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 > > frustrated and give it up for a little bit. > Arguably so. In theory a vindictive probabilistic queueing is sufficient > (do RED but then drop -every- frame from the same route as the packet chosen > from the queue) THAT actually sounds very similar to what some ATM switches are doing when congestion results in lost cells in an IP datagram. Some time ago, a buddy up at Sandia National Laboratories was explaining the problem with congestion and IP over ATM. Once the congestion level reachs a certain point, the probability of the ATM network dropping a single cell out of the many cells comprising a complete IP datagram exceeds unity. All the transmitted cells, however, are contributing to the congestion. The datagram eventually gets retried and adds even more to the congestion. Net result is that once you pass this congestion threshold, IP throughput completely collapses and retries keep it there until higher layers fail. The answer for some intelligent ATM switches is to recognize the higher layer IP traffic and, when dropping an ATM cell in the middle of an IP datagram, to drop ALL the cells in a datagram if any of the cells are going to be dropped. That way the remaining cells are not contributing to the congestion when the entire IP datagram is going to be retransmitted anyways. Purists MIGHT argue that this is a layering violation, but it would seem to be a good one. :-/ You could call it vindictive, or maybe congestion with extreme prejudice... :-) Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 frustrated and give it up for a little bit. Arguably so. In theory a vindictive probabilistic queueing is sufficient (do RED but then drop -every- frame from the same route as the packet chosen from the queue) THAT actually sounds very similar to what some ATM switches are doing when congestion results in lost cells in an IP datagram. Some time ago, a buddy up at Sandia National Laboratories was explaining the problem with congestion and IP over ATM. Once the congestion level reachs a certain point, the probability of the ATM network dropping a single cell out of the many cells comprising a complete IP datagram exceeds unity. All the transmitted cells, however, are contributing to the congestion. The datagram eventually gets retried and adds even more to the congestion. Net result is that once you pass this congestion threshold, IP throughput completely collapses and retries keep it there until higher layers fail. The answer for some intelligent ATM switches is to recognize the higher layer IP traffic and, when dropping an ATM cell in the middle of an IP datagram, to drop ALL the cells in a datagram if any of the cells are going to be dropped. That way the remaining cells are not contributing to the congestion when the entire IP datagram is going to be retransmitted anyways. Purists MIGHT argue that this is a layering violation, but it would seem to be a good one. :-/ You could call it vindictive, or maybe congestion with extreme prejudice... :-) Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
> 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 theory a vindictive probabilistic queueing is sufficient (do RED but then drop -every- frame from the same route as the packet chosen from the queue) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 theory a vindictive probabilistic queueing is sufficient (do RED but then drop -every- frame from the same route as the packet chosen from the queue) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air
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 historical purposes, let it be noted that it was the Linux ECN implementation in the 2.0 days that made this change in the RFC possible. "we believe in running code ..." -- yes, indeed. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Maxwell strikes the heart (ECN: Clearing the air)
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 synchronization. > I would appreciate couple of links >to reputable studies or discussions on the subject. See http://www.aciri.org/floyd/ecn.html http://www.aciri.org/floyd/red.html (I particularly like ftp://ftp.ee.lbl.gov/talks/vj-nanog-red.pdf) RED and ECN can be considered independently (although they do work together quite well). You can see ECN as a way of the network telling the endpoints "Normally I would have dropped this datagram, but I'll let you get away with it this time". TCP behavior on reception of an ECN should be the same as when a datagram is dropped, but without the latency (and jitter) that is the result of a lost datagram. JDB. [using RED/ECN-like protocols for latency sensitive video communications over a wireless link] -- LART. 250 MIPS under one Watt. Free hardware design files. http://www.lart.tudelft.nl/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Maxwell strikes the heart (ECN: Clearing the air)
> 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, 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 very useful right now! > > 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. > > It's a real issue, and it's actually important to have it implemented. It's > not just a performance hack. I always "knew" that the stability of the Internet is secured by the exponential backoff in TCP. A small packet loss on uncongested links is a part of this technique, and it existed long before ATM studies produced RED (which infiltrated backwards). It also requires sending stacks to "give up for a little bit" (actually to give up a lot, and together with the slow start it produced the well known "saw" of the window size). 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. I would appreciate couple of links to reputable studies or discussions on the subject. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
> "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 an internet draft?
There is no guarantee it'll even be an informational rfc, much less
standards track.
-JimC
--
James H. Cloos, Jr. 1024D/ED7DAEA6
<[EMAIL PROTECTED]> E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air
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 PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air
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. > The idea is to "detect" port scanners. > Queso sets the two TCP reserved bits in the SYN (now allocated for ECN). > Some OSes reflect that back in the SYN-ACK (Linux < 2.0.2? for example > was such a culprit). Does not that mean that Linux 2.0.10 mistakenly announces it is ECN capable when offered ECN connection? Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
[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 > connection. So write a script to disable ECN via sysctl, retry your outgoing MTA queue, and re-enable ECN. Run it via cron about once a day. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
[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 connection. So write a script to disable ECN via sysctl, retry your outgoing MTA queue, and re-enable ECN. Run it via cron about once a day. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air
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 to "detect" port scanners. Queso sets the two TCP reserved bits in the SYN (now allocated for ECN). Some OSes reflect that back in the SYN-ACK (Linux 2.0.2? for example was such a culprit). Does not that mean that Linux 2.0.10 mistakenly announces it is ECN capable when offered ECN connection? Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air
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 PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
"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 an internet draft?
There is no guarantee it'll even be an informational rfc, much less
standards track.
-JimC
--
James H. Cloos, Jr. http://jhcloos.com/public_key 1024D/ED7DAEA6
[EMAIL PROTECTED] E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Maxwell strikes the heart (ECN: Clearing the air)
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, 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 very useful right now! 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. It's a real issue, and it's actually important to have it implemented. It's not just a performance hack. I always "knew" that the stability of the Internet is secured by the exponential backoff in TCP. A small packet loss on uncongested links is a part of this technique, and it existed long before ATM studies produced RED (which infiltrated backwards). It also requires sending stacks to "give up for a little bit" (actually to give up a lot, and together with the slow start it produced the well known "saw" of the window size). 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. I would appreciate couple of links to reputable studies or discussions on the subject. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Maxwell strikes the heart (ECN: Clearing the air)
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 synchronization. I would appreciate couple of links to reputable studies or discussions on the subject. See http://www.aciri.org/floyd/ecn.html http://www.aciri.org/floyd/red.html (I particularly like ftp://ftp.ee.lbl.gov/talks/vj-nanog-red.pdf) RED and ECN can be considered independently (although they do work together quite well). You can see ECN as a way of the network telling the endpoints "Normally I would have dropped this datagram, but I'll let you get away with it this time". TCP behavior on reception of an ECN should be the same as when a datagram is dropped, but without the latency (and jitter) that is the result of a lost datagram. JDB. [using RED/ECN-like protocols for latency sensitive video communications over a wireless link] -- LART. 250 MIPS under one Watt. Free hardware design files. http://www.lart.tudelft.nl/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 real one. It's all we've got. Guess what, Linux works not around PMTU black holes either for the same exact reason we will not work around ECN. I'm getting a bit tired of you, and I suppose others are as well. You are being nothing but a pompous ass. Anyways, let me quote a comment from the Linux source code where we would have done PMTU black hole detection: /* 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 to make it. It is disguisting. It does not work in any case. Let me to cite the same draft, which requires for us to implement this: "The one security concern raised by this memo is that ICMP black holes are often caused by over-zealous security administrators who block all ICMP messages. It is vitally important that those who design and deploy security systems understand the impact of strict filtering on upper-layer protocols. The safest web site in the world is worthless if most TCP implementations cannot transfer data from it. It would be far nicer to have all of the black holes fixed rather than fixing all of the TCP implementations." Golden words :-). */ Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 directory or something and make sure my workstation made a new connection _back_ to you? If you are using passive FTP and/or did not do a directory listing, you did the test incorrectly. The directory listing is what will test the ECN'ness of your local firewall. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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. David Lang On Sun, 28 Jan 2001, jamal wrote: > Date: 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 Jan 2001, jamal wrote: > > > There were people who made the suggestion that TCP should retry after a > > > RST because it "might be an anti-ECN path" > > > > That depends what you mean by "retry"; I wanted the ability to attempt a > > non-ECN connection. i.e. if I'm a mailserver, and try connecting to one of > > Hotmail's MX hosts with ECN, I'll get RST every time. I would like to be > > able to retry with ECN disabled for that connection. > > > > We are allowing two rules to be broken, one is RFC 793 which > clearly and unambigously defines what a RST means. the second is > the firewall or IDS box which clearly is in violation. > The simplest thing in this chaos is to fix the firewall because it is in > violation to begin with. > I think it is silly to try to be "robust against RSTs" because of ECN. > What if the RST was genuine? > > I see that we mostly have philosphical differences. You'd rather adapt > to the criminal and most people would rather have the criminal adjust to > society. > > I think CISCO have been very good in responding fast. I blame the site > owners who dont want to go beyond their 9-5 job and upgrade their boxes. > In the old internet where only hackers were qualified for such jobs, the > upgrade would have happened by now at hotmail. I suppose it's part of > growing pains. > If you think the CISCOs were bad sending RSTs, i am sure you havent heard > about the Raptor firewalls. They dont even bother to send you anything if > you have ECN enabled ;-> Simply swallow your SYNs. > So tell me, what do you propose we deal with these? Do we further > disambiguate or assume the packet was lost? > I actually bothered calling Raptor, they chose to ignore me. > > You should never ASSume anything about something that is "reserved". > I posted the definition from the collegiate dictionary, but i am sure most > dictionaries would give the same definition. > > It's too bad we end up defining protocols using English. We should use > mathematical equations to remove any ambiguity ;-> > > cheers, > jamal > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 very useful right now! > > 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. There are other forms of probabilistic queuing, and RED+ECN may not be one of the ones which scales as the net gets larger We're keen on latency, burst avoidance and other quality guarantees these days. ECN is an improvement of just RED alone of course. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 elegant. So be it.) > > > > However, ECN is now "understood", and operators are now in a position > > to configure their firewall to "do the right thing". This is > > 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. They chose their vendor. In the case of Cisco, they aparently chose OK as cisco fixed their product right away. In the case of Raptor they made a bad decision as the vendor still has not fixed the problem... They could have chose Linux where if there had been an issue they could have gotten it fixed without respect to the vendors idea of how important the problem is... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 English. We should use > > mathematical equations to remove any ambiguity ;-> > > No, just use English properly. "Must be zero" doesn't actually mean "must > be set to zero when sending, and ignored when receiving/processing", which > is probably what the standard SHOULD have said. I see your problem now... You can't read! The standard don't just say "Must be zero" it also says that it is reserved. Reserved is very explicitly defined elseware... In the language of RFCs (and most of engineering) it means 'you must always set it as specified' when generating, and you must never behave differently because of it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 no longer communicate with existing systems, I would say > the person making the incompatible change is the one who broke it. No. If one day your city decides to make the rode into and out of your neighorbhood only 1 meter wide, sooner or later someone will expects to drive a car or truck into the area (rather then a motorcycle), the person city is at fault for building a non-standard road. The person who chose to operate a perfectly standard car/truck is not in the wrong. > Maybe my mains sockets should be waterproof: it's still my fault when > pouring water over them causes problems, even if the standards say the > socket should be waterproof! No it's not. If you had a waterproof socket, it would certantly be the makers fault if it wasn't actually waterproof. I suppose you think I should be tried for murder because my sneeze was an element that contributed to a weather pattern which caused a monsoon on the other side of the world and killed people? It's perfectly reasonable for Linux to impliment an IETF standard. It's not reasonable for networks to make expectations/decisions about reserved bits in headers. If you want to break your networks, great, do things like that. But it's your problem to fix it when it becomes an issue. They expended effort to willfully break their networks, they can now expend the effort to fix them. This type of thing is part of the total-cost-of-ownership of a firewall, it isn't Linux's fault if they were too foolish to understand they would have ongoing costs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 the current > > protocols is rather silly. > > Do keep in mind, we aren't breaking connectivity, they are. Thats the crux of the argument. No one made them run a firewall, they chose one that blocks undefined behavior. The Internet is a dynamic system, they broke the end-to-end model with their firewall, the onus is on them to keep up. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 > IPv6. It's not PMTU. It's not even very useful right now! 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. It's a real issue, and it's actually important to have it implemented. It's not just a performance hack. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 the firmware. "configuring" in this case > means reconfiguring new software on the firewall. Blame the vendor. Perhaps the most famous writting on protocol design was by Jon Postel. Interestingly in RFC 793 (Section 2.10) " be conservative in what you do, be liberal in what you accept from others." That should be the mantra. There is no librety when you hard-code. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 the current > > > > protocols is rather silly. > > > > > > > > > > This is the way it's done with all protocols. or i should say the way it > > > used to be done. How do you expect ECN to be deployed otherwise? > > > > Thinking about this a bit more: > > > > 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 elegant. So be it.) > > > > However, ECN is now "understood", and operators are now in a position > > to configure their firewall to "do the right thing". This is > 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 the firmware. "configuring" in this case means reconfiguring new software on the firewall. Blame the vendor. Roger. -- ** [EMAIL PROTECTED] ** 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 is rather silly. > > > > > > > This is the way it's done with all protocols. or i should say the way it > > used to be done. How do you expect ECN to be deployed otherwise? > > Thinking about this a bit more: > > 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 elegant. So be it.) > > However, ECN is now "understood", and operators are now in a position > to configure their firewall to "do the right thing". This is 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. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 RST to mean "it says RST but maybe it was not RST; let me try again" I dont think thats honoring it ;-> [Just like the anti-harassment campaign goes: What part of NO dont you understand, is it the N or the O?] > > > the firewall or IDS box which clearly is in violation. > > Disagreed: it is complying with firewall RFCs, rejecting suspect > packets. Sending an RST isn't a very bright way to do it, but that's > irrelevant: it happens. Deal with it. It is what some idiot designer thought it meant. If the administrator configured it, that is complying with RFCs. > > I see that we mostly have philosphical differences. You'd rather adapt > > to the criminal and most people would rather have the criminal adjust to > > society. > > There is no "criminal": no rules are being broken. Since it is > "society" (or a tiny minority thereof) which has changed the rules, it is > "society" which must adapt to be compatible with existing rules. > ;-> We are on different extremes for sure. It is "society" which clearly says now that if you misunderstood the rule and didnt pay attention to the definition of "reserved", here's the definition. You understand it better? good, please conform. You are saying that "society" should now say ok, since you misunderstood we'll make our lives a lot more miserable and just live with your ignorance. > > I'd have said that's still true - only "hackers" are qualified. The > problem is just that the staff doing (or attempting) the job aren't > necessarily qualified to do it properly... The internet is growing so fast and the shortage of people is affecting it. Look at what happened to MS ;-> ;-> > > > If you think the CISCOs were bad sending RSTs, i am sure you havent heard > > about the Raptor firewalls. They dont even bother to send you anything if > > you have ECN enabled ;-> Simply swallow your SYNs. > > That's regarded as a better response, actually: just drop suspect packets. > But then how do you "degrade" nicely from it? If you want Linux to be able to degrade nicely, what do you do in this case? > > So tell me, what do you propose we deal with these? Do we further > > disambiguate or assume the packet was lost? > > I actually bothered calling Raptor, they chose to ignore me. > > You mean they are still shipping a firewall which drops ECN > packets? Hrm... > Yeah, as far as i know > No, just use English properly. "Must be zero" doesn't actually mean "must > be set to zero when sending, and ignored when receiving/processing", which > is probably what the standard SHOULD have said. > > However, it's too late now: ECN-disabled routes exist. ECN implementations > should degrade as well as possible when handling these circumstances. I think this is the right moment for this to be fixed. Way before it is too late. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
[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 passing through the firewall? This would have the effect of informing the ECN aware hosts (both within and outside the firewall) that ECN is not available for that connection. This would not prevent ECN aware systems from connecting. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 with all protocols. or i should say the way it > used to be done. How do you expect ECN to be deployed otherwise? Thinking about this a bit more: 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 elegant. So be it.) However, ECN is now "understood", and operators are now in a position to configure their firewall to "do the right thing". This is subjective. 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.". Firewall operators make "lose connectivity to certain hosts/ports" decisions all the time. That's what a firewall is about. So... I think that the hotmail operators (or was it somewhere else that started this debate?) simply get to chose. Lose connectivity to part of the world because they block ECN or not. But let it be known that it is THEIR decision. - If you implement a standard badly, you can get to be inoperable if the standard gets expanded. That's what's happening here. Happens all the time. - Note that Dave politely waited with announcing the impending "cutoff" until he verified for sure that they did have a CHOICE. - The users (/customers) have gotten two weeks to bother the operators into action, and the operators then have two weeks left to schedule the upgrade. That seems pretty fair and resonable to me. Roger. -- ** [EMAIL PROTECTED] ** 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 ability to attempt a > > non-ECN connection. i.e. if I'm a mailserver, and try connecting to one of > > Hotmail's MX hosts with ECN, I'll get RST every time. I would like to be > > able to retry with ECN disabled for that connection. > > We are allowing two rules to be broken, one is RFC 793 which > clearly and unambigously defines what a RST means. the second is This is NOT being violated: the RST is honoured as normal. > the firewall or IDS box which clearly is in violation. Disagreed: it is complying with firewall RFCs, rejecting suspect packets. Sending an RST isn't a very bright way to do it, but that's irrelevant: it happens. Deal with it. > 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. > I think it is silly to try to be "robust against RSTs" because of ECN. > What if the RST was genuine? It is genuine, and is treated as such. There is no "robust against RSTs" or anything else: just graceful handling of non-ECN routes. > I see that we mostly have philosphical differences. You'd rather adapt > to the criminal and most people would rather have the criminal adjust to > society. There is no "criminal": no rules are being broken. Since it is "society" (or a tiny minority thereof) which has changed the rules, it is "society" which must adapt to be compatible with existing rules. > I think CISCO have been very good in responding fast. I blame the site > owners who dont want to go beyond their 9-5 job and upgrade their boxes. > In the old internet where only hackers were qualified for such jobs, the > upgrade would have happened by now at hotmail. I suppose it's part of > growing pains. I'd have said that's still true - only "hackers" are qualified. The problem is just that the staff doing (or attempting) the job aren't necessarily qualified to do it properly... > If you think the CISCOs were bad sending RSTs, i am sure you havent heard > about the Raptor firewalls. They dont even bother to send you anything if > you have ECN enabled ;-> Simply swallow your SYNs. That's regarded as a better response, actually: just drop suspect packets. > So tell me, what do you propose we deal with these? Do we further > disambiguate or assume the packet was lost? > I actually bothered calling Raptor, they chose to ignore me. You mean they are still shipping a firewall which drops ECN packets? Hrm... > You should never ASSume anything about something that is "reserved". > I posted the definition from the collegiate dictionary, but i am sure most > dictionaries would give the same definition. It isn't just reserved, though, it's stated "must be zero". Very poor wording, but it's too late now. > It's too bad we end up defining protocols using English. We should use > mathematical equations to remove any ambiguity ;-> No, just use English properly. "Must be zero" doesn't actually mean "must be set to zero when sending, and ignored when receiving/processing", which is probably what the standard SHOULD have said. However, it's too late now: ECN-disabled routes exist. ECN implementations should degrade as well as possible when handling these circumstances. James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 _most_ > >> people would get flogging all firewall admins who block all ICMP. > > > >Blocking out ICMP doesn't bother me particularly. I know they should be > >selective, but it doesn't break anything essential. > > It breaks Path MTU Discovery. If you have a link somewhere in your > network (not at an endpoint, or TCP MSS will take care of it) that > has an MTU < 1500, you cannot reach hotmail and a lot of other sites > either currently. It _does_ break essential things. Daily. I would > get a lot of joy from flogging all firewall admins who block all ICMP. 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 real one. It's all we've got. James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
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 the suggestion that TCP should retry after a > > RST because it "might be an anti-ECN path" > > That depends what you mean by "retry"; I wanted the ability to attempt a > non-ECN connection. i.e. if I'm a mailserver, and try connecting to one of > Hotmail's MX hosts with ECN, I'll get RST every time. I would like to be > able to retry with ECN disabled for that connection. > We are allowing two rules to be broken, one is RFC 793 which clearly and unambigously defines what a RST means. the second is the firewall or IDS box which clearly is in violation. The simplest thing in this chaos is to fix the firewall because it is in violation to begin with. I think it is silly to try to be "robust against RSTs" because of ECN. What if the RST was genuine? I see that we mostly have philosphical differences. You'd rather adapt to the criminal and most people would rather have the criminal adjust to society. I think CISCO have been very good in responding fast. I blame the site owners who dont want to go beyond their 9-5 job and upgrade their boxes. In the old internet where only hackers were qualified for such jobs, the upgrade would have happened by now at hotmail. I suppose it's part of growing pains. If you think the CISCOs were bad sending RSTs, i am sure you havent heard about the Raptor firewalls. They dont even bother to send you anything if you have ECN enabled ;-> Simply swallow your SYNs. So tell me, what do you propose we deal with these? Do we further disambiguate or assume the packet was lost? I actually bothered calling Raptor, they chose to ignore me. You should never ASSume anything about something that is "reserved". I posted the definition from the collegiate dictionary, but i am sure most dictionaries would give the same definition. It's too bad we end up defining protocols using English. We should use mathematical equations to remove any ambiguity ;-> cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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, though, is that firewalls are NOT > > > "brain-damaged" for blocking ECN: according to the RFCs governing > > > firewalls, and the logic behind their design, blocking packets in an > > > unknown format (i.e. with reserved bits set) is perfectly legitimate. 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. > > > > 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 no longer communicate with existing systems, I would say > the person making the incompatible change is the one who broke it. > > Maybe my mains sockets should be waterproof: it's still my fault when > pouring water over them causes problems, even if the standards say the > socket should be waterproof! > Bad analogy. Try this. Jim-Bob down at your local Post Office starts rejecting all your mail that has the 4 digit zip code extension (Not in wide use, but a "proposed standard") because he's old school and doesn't know what it is -- maybe its secret spy communications!!! (Although this would have the side benefit of really reducing the amount of junk mail received . . . . . . ) And no, I'm not a lawyer. -b - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 doesn't bother me particularly. I know they should be > selective, but it doesn't break anything essential. Ever heard of path mtu discovery? For example you essentially blocked out most people behind IP tunnels from your site (at least those who do not do MSS hacks) In addition to breaking pmtu disc (which is a real showstopper for many setups), it also have some negative effects on your servers. For example when your mail server is for some reason trying to contact an unreachable host to deliver a mail it'll not notice except after having wasted lots of bandwidth and resources trying to contact the host again and again, even when the ICMP clearly tells that it won't work. -Andi (who would join into Miquel's flogging) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 block all ICMP. > >Blocking out ICMP doesn't bother me particularly. I know they should be >selective, but it doesn't break anything essential. It breaks Path MTU Discovery. If you have a link somewhere in your network (not at an endpoint, or TCP MSS will take care of it) that has an MTU < 1500, you cannot reach hotmail and a lot of other sites either currently. It _does_ break essential things. Daily. I would get a lot of joy from flogging all firewall admins who block all ICMP. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 > > "brain-damaged" for blocking ECN: according to the RFCs governing > > firewalls, and the logic behind their design, blocking packets in an > > unknown format (i.e. with reserved bits set) is perfectly legitimate. 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. > > 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 no longer communicate with existing systems, I would say the person making the incompatible change is the one who broke it. Maybe my mains sockets should be waterproof: it's still my fault when pouring water over them causes problems, even if the standards say the socket should be waterproof! James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 the RFCs governing > firewalls, and the logic behind their design, blocking packets in an > unknown format (i.e. with reserved bits set) is perfectly legitimate. 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. Do keep in mind, we aren't breaking connectivity, they are. -b - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 pulled the pin. > There were people who made the suggestion that TCP should retry after a > RST because it "might be an anti-ECN path" That depends what you mean by "retry"; I wanted the ability to attempt a non-ECN connection. i.e. if I'm a mailserver, and try connecting to one of Hotmail's MX hosts with ECN, I'll get RST every time. I would like to be able to retry with ECN disabled for that connection. > > 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, and the logic behind their design, blocking packets in an > > unknown format (i.e. with reserved bits set) is perfectly legitimate. > > I dont agree that unknown format == reserved. I think it is bad design to > assume that. You may be forgiven if you provide the operator > opportunities to reset your assumptions via a config option. > It has nothing to do with a paranoia setting, just a bad design. Nothing > legit about that. On the contrary: rejecting weird-looking traffic is perfectly legit. I agree RST is the wrong response, but it's too late to tell Cisco that now... > > 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 with all protocols. or i should say the way it > used to be done. How do you expect ECN to be deployed otherwise? The current versions of these firewalls handle ECN OK. I just want Linux to degrade gracefully when unable to use ECN: it will be a while before all these firewalls have gone. > 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 doesn't bother me particularly. I know they should be selective, but it doesn't break anything essential. > 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 very useful right now! James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 made the suggestion that TCP should retry after a RST because it "might be an anti-ECN path" > > 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, and the logic behind their design, blocking packets in an > unknown format (i.e. with reserved bits set) is perfectly legitimate. I dont agree that unknown format == reserved. I think it is bad design to assume that. You may be forgiven if you provide the operator opportunities to reset your assumptions via a config option. It has nothing to do with a paranoia setting, just a bad design. Nothing legit about that. > 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 with all protocols. or i should say the way it used to be done. How do you expect ECN to be deployed otherwise? 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. There is nothing silly with the decision, davem is simply a modern day internet hero. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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, and the logic behind their design, blocking packets in an unknown format (i.e. with reserved bits set) is perfectly legitimate. 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. James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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, and the logic behind their design, blocking packets in an unknown format (i.e. with reserved bits set) is perfectly legitimate. 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. James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 made the suggestion that TCP should retry after a RST because it "might be an anti-ECN path" 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, and the logic behind their design, blocking packets in an unknown format (i.e. with reserved bits set) is perfectly legitimate. I dont agree that unknown format == reserved. I think it is bad design to assume that. You may be forgiven if you provide the operator opportunities to reset your assumptions via a config option. It has nothing to do with a paranoia setting, just a bad design. Nothing legit about that. 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 with all protocols. or i should say the way it used to be done. How do you expect ECN to be deployed otherwise? 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. There is nothing silly with the decision, davem is simply a modern day internet hero. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 pulled the pin. There were people who made the suggestion that TCP should retry after a RST because it "might be an anti-ECN path" That depends what you mean by "retry"; I wanted the ability to attempt a non-ECN connection. i.e. if I'm a mailserver, and try connecting to one of Hotmail's MX hosts with ECN, I'll get RST every time. I would like to be able to retry with ECN disabled for that connection. 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, and the logic behind their design, blocking packets in an unknown format (i.e. with reserved bits set) is perfectly legitimate. I dont agree that unknown format == reserved. I think it is bad design to assume that. You may be forgiven if you provide the operator opportunities to reset your assumptions via a config option. It has nothing to do with a paranoia setting, just a bad design. Nothing legit about that. On the contrary: rejecting weird-looking traffic is perfectly legit. I agree RST is the wrong response, but it's too late to tell Cisco that now... 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 with all protocols. or i should say the way it used to be done. How do you expect ECN to be deployed otherwise? The current versions of these firewalls handle ECN OK. I just want Linux to degrade gracefully when unable to use ECN: it will be a while before all these firewalls have gone. 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 doesn't bother me particularly. I know they should be selective, but it doesn't break anything essential. 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 very useful right now! James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 the RFCs governing firewalls, and the logic behind their design, blocking packets in an unknown format (i.e. with reserved bits set) is perfectly legitimate. 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. Do keep in mind, we aren't breaking connectivity, they are. -b - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 "brain-damaged" for blocking ECN: according to the RFCs governing firewalls, and the logic behind their design, blocking packets in an unknown format (i.e. with reserved bits set) is perfectly legitimate. 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. 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 no longer communicate with existing systems, I would say the person making the incompatible change is the one who broke it. Maybe my mains sockets should be waterproof: it's still my fault when pouring water over them causes problems, even if the standards say the socket should be waterproof! James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 block all ICMP. Blocking out ICMP doesn't bother me particularly. I know they should be selective, but it doesn't break anything essential. It breaks Path MTU Discovery. If you have a link somewhere in your network (not at an endpoint, or TCP MSS will take care of it) that has an MTU 1500, you cannot reach hotmail and a lot of other sites either currently. It _does_ break essential things. Daily. I would get a lot of joy from flogging all firewall admins who block all ICMP. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 doesn't bother me particularly. I know they should be selective, but it doesn't break anything essential. Ever heard of path mtu discovery? For example you essentially blocked out most people behind IP tunnels from your site (at least those who do not do MSS hacks) In addition to breaking pmtu disc (which is a real showstopper for many setups), it also have some negative effects on your servers. For example when your mail server is for some reason trying to contact an unreachable host to deliver a mail it'll not notice except after having wasted lots of bandwidth and resources trying to contact the host again and again, even when the ICMP clearly tells that it won't work. -Andi (who would join into Miquel's flogging) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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, though, is that firewalls are NOT "brain-damaged" for blocking ECN: according to the RFCs governing firewalls, and the logic behind their design, blocking packets in an unknown format (i.e. with reserved bits set) is perfectly legitimate. 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. 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 no longer communicate with existing systems, I would say the person making the incompatible change is the one who broke it. Maybe my mains sockets should be waterproof: it's still my fault when pouring water over them causes problems, even if the standards say the socket should be waterproof! Bad analogy. Try this. Jim-Bob down at your local Post Office starts rejecting all your mail that has the 4 digit zip code extension (Not in wide use, but a "proposed standard") because he's old school and doesn't know what it is -- maybe its secret spy communications!!! (Although this would have the side benefit of really reducing the amount of junk mail received . . . . . . ) And no, I'm not a lawyer. -b - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
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 the suggestion that TCP should retry after a RST because it "might be an anti-ECN path" That depends what you mean by "retry"; I wanted the ability to attempt a non-ECN connection. i.e. if I'm a mailserver, and try connecting to one of Hotmail's MX hosts with ECN, I'll get RST every time. I would like to be able to retry with ECN disabled for that connection. We are allowing two rules to be broken, one is RFC 793 which clearly and unambigously defines what a RST means. the second is the firewall or IDS box which clearly is in violation. The simplest thing in this chaos is to fix the firewall because it is in violation to begin with. I think it is silly to try to be "robust against RSTs" because of ECN. What if the RST was genuine? I see that we mostly have philosphical differences. You'd rather adapt to the criminal and most people would rather have the criminal adjust to society. I think CISCO have been very good in responding fast. I blame the site owners who dont want to go beyond their 9-5 job and upgrade their boxes. In the old internet where only hackers were qualified for such jobs, the upgrade would have happened by now at hotmail. I suppose it's part of growing pains. If you think the CISCOs were bad sending RSTs, i am sure you havent heard about the Raptor firewalls. They dont even bother to send you anything if you have ECN enabled ;- Simply swallow your SYNs. So tell me, what do you propose we deal with these? Do we further disambiguate or assume the packet was lost? I actually bothered calling Raptor, they chose to ignore me. You should never ASSume anything about something that is "reserved". I posted the definition from the collegiate dictionary, but i am sure most dictionaries would give the same definition. It's too bad we end up defining protocols using English. We should use mathematical equations to remove any ambiguity ;- cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 _most_ people would get flogging all firewall admins who block all ICMP. Blocking out ICMP doesn't bother me particularly. I know they should be selective, but it doesn't break anything essential. It breaks Path MTU Discovery. If you have a link somewhere in your network (not at an endpoint, or TCP MSS will take care of it) that has an MTU 1500, you cannot reach hotmail and a lot of other sites either currently. It _does_ break essential things. Daily. I would get a lot of joy from flogging all firewall admins who block all ICMP. 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 real one. It's all we've got. James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 ability to attempt a non-ECN connection. i.e. if I'm a mailserver, and try connecting to one of Hotmail's MX hosts with ECN, I'll get RST every time. I would like to be able to retry with ECN disabled for that connection. We are allowing two rules to be broken, one is RFC 793 which clearly and unambigously defines what a RST means. the second is This is NOT being violated: the RST is honoured as normal. the firewall or IDS box which clearly is in violation. Disagreed: it is complying with firewall RFCs, rejecting suspect packets. Sending an RST isn't a very bright way to do it, but that's irrelevant: it happens. Deal with it. 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. I think it is silly to try to be "robust against RSTs" because of ECN. What if the RST was genuine? It is genuine, and is treated as such. There is no "robust against RSTs" or anything else: just graceful handling of non-ECN routes. I see that we mostly have philosphical differences. You'd rather adapt to the criminal and most people would rather have the criminal adjust to society. There is no "criminal": no rules are being broken. Since it is "society" (or a tiny minority thereof) which has changed the rules, it is "society" which must adapt to be compatible with existing rules. I think CISCO have been very good in responding fast. I blame the site owners who dont want to go beyond their 9-5 job and upgrade their boxes. In the old internet where only hackers were qualified for such jobs, the upgrade would have happened by now at hotmail. I suppose it's part of growing pains. I'd have said that's still true - only "hackers" are qualified. The problem is just that the staff doing (or attempting) the job aren't necessarily qualified to do it properly... If you think the CISCOs were bad sending RSTs, i am sure you havent heard about the Raptor firewalls. They dont even bother to send you anything if you have ECN enabled ;- Simply swallow your SYNs. That's regarded as a better response, actually: just drop suspect packets. So tell me, what do you propose we deal with these? Do we further disambiguate or assume the packet was lost? I actually bothered calling Raptor, they chose to ignore me. You mean they are still shipping a firewall which drops ECN packets? Hrm... You should never ASSume anything about something that is "reserved". I posted the definition from the collegiate dictionary, but i am sure most dictionaries would give the same definition. It isn't just reserved, though, it's stated "must be zero". Very poor wording, but it's too late now. It's too bad we end up defining protocols using English. We should use mathematical equations to remove any ambiguity ;- No, just use English properly. "Must be zero" doesn't actually mean "must be set to zero when sending, and ignored when receiving/processing", which is probably what the standard SHOULD have said. However, it's too late now: ECN-disabled routes exist. ECN implementations should degrade as well as possible when handling these circumstances. James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 with all protocols. or i should say the way it used to be done. How do you expect ECN to be deployed otherwise? Thinking about this a bit more: 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 elegant. So be it.) However, ECN is now "understood", and operators are now in a position to configure their firewall to "do the right thing". This is subjective. 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.". Firewall operators make "lose connectivity to certain hosts/ports" decisions all the time. That's what a firewall is about. So... I think that the hotmail operators (or was it somewhere else that started this debate?) simply get to chose. Lose connectivity to part of the world because they block ECN or not. But let it be known that it is THEIR decision. - If you implement a standard badly, you can get to be inoperable if the standard gets expanded. That's what's happening here. Happens all the time. - Note that Dave politely waited with announcing the impending "cutoff" until he verified for sure that they did have a CHOICE. - The users (/customers) have gotten two weeks to bother the operators into action, and the operators then have two weeks left to schedule the upgrade. That seems pretty fair and resonable to me. Roger. -- ** [EMAIL PROTECTED] ** 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
[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 passing through the firewall? This would have the effect of informing the ECN aware hosts (both within and outside the firewall) that ECN is not available for that connection. This would not prevent ECN aware systems from connecting. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 RST to mean "it says RST but maybe it was not RST; let me try again" I dont think thats honoring it ;- [Just like the anti-harassment campaign goes: What part of NO dont you understand, is it the N or the O?] the firewall or IDS box which clearly is in violation. Disagreed: it is complying with firewall RFCs, rejecting suspect packets. Sending an RST isn't a very bright way to do it, but that's irrelevant: it happens. Deal with it. It is what some idiot designer thought it meant. If the administrator configured it, that is complying with RFCs. I see that we mostly have philosphical differences. You'd rather adapt to the criminal and most people would rather have the criminal adjust to society. There is no "criminal": no rules are being broken. Since it is "society" (or a tiny minority thereof) which has changed the rules, it is "society" which must adapt to be compatible with existing rules. ;- We are on different extremes for sure. It is "society" which clearly says now that if you misunderstood the rule and didnt pay attention to the definition of "reserved", here's the definition. You understand it better? good, please conform. You are saying that "society" should now say ok, since you misunderstood we'll make our lives a lot more miserable and just live with your ignorance. I'd have said that's still true - only "hackers" are qualified. The problem is just that the staff doing (or attempting) the job aren't necessarily qualified to do it properly... The internet is growing so fast and the shortage of people is affecting it. Look at what happened to MS ;- ;- If you think the CISCOs were bad sending RSTs, i am sure you havent heard about the Raptor firewalls. They dont even bother to send you anything if you have ECN enabled ;- Simply swallow your SYNs. That's regarded as a better response, actually: just drop suspect packets. But then how do you "degrade" nicely from it? If you want Linux to be able to degrade nicely, what do you do in this case? So tell me, what do you propose we deal with these? Do we further disambiguate or assume the packet was lost? I actually bothered calling Raptor, they chose to ignore me. You mean they are still shipping a firewall which drops ECN packets? Hrm... Yeah, as far as i know No, just use English properly. "Must be zero" doesn't actually mean "must be set to zero when sending, and ignored when receiving/processing", which is probably what the standard SHOULD have said. However, it's too late now: ECN-disabled routes exist. ECN implementations should degrade as well as possible when handling these circumstances. I think this is the right moment for this to be fixed. Way before it is too late. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 is rather silly. This is the way it's done with all protocols. or i should say the way it used to be done. How do you expect ECN to be deployed otherwise? Thinking about this a bit more: 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 elegant. So be it.) However, ECN is now "understood", and operators are now in a position to configure their firewall to "do the right thing". This is 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. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 the current protocols is rather silly. This is the way it's done with all protocols. or i should say the way it used to be done. How do you expect ECN to be deployed otherwise? Thinking about this a bit more: 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 elegant. So be it.) However, ECN is now "understood", and operators are now in a position to configure their firewall to "do the right thing". This is 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 the firmware. "configuring" in this case means reconfiguring new software on the firewall. Blame the vendor. Roger. -- ** [EMAIL PROTECTED] ** 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 the firmware. "configuring" in this case means reconfiguring new software on the firewall. Blame the vendor. Perhaps the most famous writting on protocol design was by Jon Postel. Interestingly in RFC 793 (Section 2.10) " be conservative in what you do, be liberal in what you accept from others." That should be the mantra. There is no librety when you hard-code. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 IPv6. It's not PMTU. It's not even very useful right now! 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. It's a real issue, and it's actually important to have it implemented. It's not just a performance hack. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 the current protocols is rather silly. Do keep in mind, we aren't breaking connectivity, they are. Thats the crux of the argument. No one made them run a firewall, they chose one that blocks undefined behavior. The Internet is a dynamic system, they broke the end-to-end model with their firewall, the onus is on them to keep up. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 no longer communicate with existing systems, I would say the person making the incompatible change is the one who broke it. No. If one day your city decides to make the rode into and out of your neighorbhood only 1 meter wide, sooner or later someone will expects to drive a car or truck into the area (rather then a motorcycle), the person city is at fault for building a non-standard road. The person who chose to operate a perfectly standard car/truck is not in the wrong. Maybe my mains sockets should be waterproof: it's still my fault when pouring water over them causes problems, even if the standards say the socket should be waterproof! No it's not. If you had a waterproof socket, it would certantly be the makers fault if it wasn't actually waterproof. I suppose you think I should be tried for murder because my sneeze was an element that contributed to a weather pattern which caused a monsoon on the other side of the world and killed people? It's perfectly reasonable for Linux to impliment an IETF standard. It's not reasonable for networks to make expectations/decisions about reserved bits in headers. If you want to break your networks, great, do things like that. But it's your problem to fix it when it becomes an issue. They expended effort to willfully break their networks, they can now expend the effort to fix them. This type of thing is part of the total-cost-of-ownership of a firewall, it isn't Linux's fault if they were too foolish to understand they would have ongoing costs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 English. We should use mathematical equations to remove any ambiguity ;- No, just use English properly. "Must be zero" doesn't actually mean "must be set to zero when sending, and ignored when receiving/processing", which is probably what the standard SHOULD have said. I see your problem now... You can't read! The standard don't just say "Must be zero" it also says that it is reserved. Reserved is very explicitly defined elseware... In the language of RFCs (and most of engineering) it means 'you must always set it as specified' when generating, and you must never behave differently because of it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 elegant. So be it.) However, ECN is now "understood", and operators are now in a position to configure their firewall to "do the right thing". This is 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. They chose their vendor. In the case of Cisco, they aparently chose OK as cisco fixed their product right away. In the case of Raptor they made a bad decision as the vendor still has not fixed the problem... They could have chose Linux where if there had been an issue they could have gotten it fixed without respect to the vendors idea of how important the problem is... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 very useful right now! 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. There are other forms of probabilistic queuing, and RED+ECN may not be one of the ones which scales as the net gets larger We're keen on latency, burst avoidance and other quality guarantees these days. ECN is an improvement of just RED alone of course. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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. David Lang On Sun, 28 Jan 2001, jamal wrote: Date: 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 Jan 2001, jamal wrote: There were people who made the suggestion that TCP should retry after a RST because it "might be an anti-ECN path" That depends what you mean by "retry"; I wanted the ability to attempt a non-ECN connection. i.e. if I'm a mailserver, and try connecting to one of Hotmail's MX hosts with ECN, I'll get RST every time. I would like to be able to retry with ECN disabled for that connection. We are allowing two rules to be broken, one is RFC 793 which clearly and unambigously defines what a RST means. the second is the firewall or IDS box which clearly is in violation. The simplest thing in this chaos is to fix the firewall because it is in violation to begin with. I think it is silly to try to be "robust against RSTs" because of ECN. What if the RST was genuine? I see that we mostly have philosphical differences. You'd rather adapt to the criminal and most people would rather have the criminal adjust to society. I think CISCO have been very good in responding fast. I blame the site owners who dont want to go beyond their 9-5 job and upgrade their boxes. In the old internet where only hackers were qualified for such jobs, the upgrade would have happened by now at hotmail. I suppose it's part of growing pains. If you think the CISCOs were bad sending RSTs, i am sure you havent heard about the Raptor firewalls. They dont even bother to send you anything if you have ECN enabled ;- Simply swallow your SYNs. So tell me, what do you propose we deal with these? Do we further disambiguate or assume the packet was lost? I actually bothered calling Raptor, they chose to ignore me. You should never ASSume anything about something that is "reserved". I posted the definition from the collegiate dictionary, but i am sure most dictionaries would give the same definition. It's too bad we end up defining protocols using English. We should use mathematical equations to remove any ambiguity ;- cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 directory or something and make sure my workstation made a new connection _back_ to you? If you are using passive FTP and/or did not do a directory listing, you did the test incorrectly. The directory listing is what will test the ECN'ness of your local firewall. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
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 real one. It's all we've got. Guess what, Linux works not around PMTU black holes either for the same exact reason we will not work around ECN. I'm getting a bit tired of you, and I suppose others are as well. You are being nothing but a pompous ass. Anyways, let me quote a comment from the Linux source code where we would have done PMTU black hole detection: /* 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 to make it. It is disguisting. It does not work in any case. Let me to cite the same draft, which requires for us to implement this: "The one security concern raised by this memo is that ICMP black holes are often caused by over-zealous security administrators who block all ICMP messages. It is vitally important that those who design and deploy security systems understand the impact of strict filtering on upper-layer protocols. The safest web site in the world is worthless if most TCP implementations cannot transfer data from it. It would be far nicer to have all of the black holes fixed rather than fixing all of the TCP implementations." Golden words :-). */ Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air
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 logic in > blocking it? > It is Queso they quoted not nmap, sorry -- same thing. The idea is to "detect" port scanners. Queso sets the two TCP reserved bits in the SYN (now allocated for ECN). Some OSes reflect that back in the SYN-ACK (Linux < 2.0.2? for example was such a culprit). Queso could then use that information to narow down the OS detection. I suppose the idea is to detect Queso and react to it ;-> cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air
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 probe systems. > should proof read before posting. The intrusion detection expert suggested blocking ECN. Article at: http://www.securityfocus.com/frames/?focus=ids=/focus/ids/articles /portscan.html cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ECN: Clearing the air (fwd)
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 retry without ECN, because DaveM wants to do a > Microsoft and force ECN on everyone, whether they like it or not. I think there is some serious misinformation going on here. Hopefully, this will straighten things out: - ECN is not a standard that DaveM came up with, or some cabal within the Linux community pulled out of a hat. It was the Internet Engineering Task Force that endorsed it. If you want to blame anybody, blame the IETF. Specifically you should also blame Sally Floyd and KK Ramakrishnan who proposed it after years of research. In case those names dont ring a bell look, them up in the internet whos-who almanac. Dont ask me where you'll find one. In case the IETF doesnt ring a bell either to some people, it is the same standard body that made the internet happen. It is the same standard body that also ensures that although the internet is anarchical in nature, there are some simple governing rules that should be defined to keep it alive. They are called protocols. The IETF has a very simple motto "we believe in running code ...". [Although that's not neccesarily true these days, but let's not tread there]. People, Linux is no longer a baby. We are leaders as far as the internet is concerned. We are there first. We set trends and other follow. We have "running code" to flush out all the heretics out there. We have the best TCP/IP people in the world today coding for you and i. Blaspheming with "DaveM wants to pull a MS" doesnt help. We need to encourage these kind of activities because we are making the internet a better place. Yes, Al Gore might have funded some good causes on the internet, but today _we_ make them happen. - ECN is a good thing. It has been proven for years to be a good thing. Standards normally go through a experimental phase before becoming proposed standard. If you dont want it turn it off. - ECN is going to become a proposed standard perhaps by this coming IETF at Mineapolis. - A lot of OS vendors and good router vendors will be deploying ECN soon. There is nothing wrong with Linux being first. We code in the open, others prefer press releases. - 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 probe systems. Any commercial non-open-source entity designing and abusing reserved fields should at least have the courtesy of providing a config option to stop that abuse. If it was open source we would have fixed their sins. - Any design which blatantly ASSumes that "reserved" means no one should use something simply amazes me. The collegiate dictionary definition of "reserved" is: - Main Entry: reserve Pronunciation: ri-'z Function: transitive verb Inflected Form(s): reserved; reserving Etymology: Middle English, from Middle French reserver, from Latin reservare, literally, to keep back, from re- + servare to keep -- more at CONSERVE Date: 14th century 1 a : to hold in reserve : keep back b : to set aside (part of the consecrated elements) at the Eucharist for future use c : to retain or hold over to a future time or place : DEFER d : to make legal reservation of 2 : to set or have set aside or apart synonym see KEEP - reservable /-'z&-b/ adjective --- Now where is the ambiguity in that? And where really is the ambiguity in the meaning of a TCP RST? Maybe an analogy in a very ambiguos protocol called "English Language" would help. The word "no" in response to the packet "davem please add an extra meaning to RST". Where is the ambiguity in that? phew! just my 2 .ca cents cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ECN: Clearing the air (fwd)
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 retry without ECN, because DaveM wants to do a Microsoft and force ECN on everyone, whether they like it or not. I think there is some serious misinformation going on here. Hopefully, this will straighten things out: - ECN is not a standard that DaveM came up with, or some cabal within the Linux community pulled out of a hat. It was the Internet Engineering Task Force that endorsed it. If you want to blame anybody, blame the IETF. Specifically you should also blame Sally Floyd and KK Ramakrishnan who proposed it after years of research. In case those names dont ring a bell look, them up in the internet whos-who almanac. Dont ask me where you'll find one. In case the IETF doesnt ring a bell either to some people, it is the same standard body that made the internet happen. It is the same standard body that also ensures that although the internet is anarchical in nature, there are some simple governing rules that should be defined to keep it alive. They are called protocols. The IETF has a very simple motto "we believe in running code ...". [Although that's not neccesarily true these days, but let's not tread there]. People, Linux is no longer a baby. We are leaders as far as the internet is concerned. We are there first. We set trends and other follow. We have "running code" to flush out all the heretics out there. We have the best TCP/IP people in the world today coding for you and i. Blaspheming with "DaveM wants to pull a MS" doesnt help. We need to encourage these kind of activities because we are making the internet a better place. Yes, Al Gore might have funded some good causes on the internet, but today _we_ make them happen. - ECN is a good thing. It has been proven for years to be a good thing. Standards normally go through a experimental phase before becoming proposed standard. If you dont want it turn it off. - ECN is going to become a proposed standard perhaps by this coming IETF at Mineapolis. - A lot of OS vendors and good router vendors will be deploying ECN soon. There is nothing wrong with Linux being first. We code in the open, others prefer press releases. - 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 probe systems. Any commercial non-open-source entity designing and abusing reserved fields should at least have the courtesy of providing a config option to stop that abuse. If it was open source we would have fixed their sins. - Any design which blatantly ASSumes that "reserved" means no one should use something simply amazes me. The collegiate dictionary definition of "reserved" is: - Main Entry: reserve Pronunciation: ri-'zrv Function: transitive verb Inflected Form(s): reserved; reserving Etymology: Middle English, from Middle French reserver, from Latin reservare, literally, to keep back, from re- + servare to keep -- more at CONSERVE Date: 14th century 1 a : to hold in reserve : keep back reserve grain for seed b : to set aside (part of the consecrated elements) at the Eucharist for future use c : to retain or hold over to a future time or place : DEFER reserve one's judgment on a plan d : to make legal reservation of 2 : to set or have set aside or apart reserve a hotel room synonym see KEEP - reservable /-'zr-v-bl/ adjective --- Now where is the ambiguity in that? And where really is the ambiguity in the meaning of a TCP RST? Maybe an analogy in a very ambiguos protocol called "English Language" would help. The word "no" in response to the packet "davem please add an extra meaning to RST". Where is the ambiguity in that? phew! just my 2 .ca cents cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air
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 probe systems. should proof read before posting. The intrusion detection expert suggested blocking ECN. Article at: http://www.securityfocus.com/frames/?focus=idscontent=/focus/ids/articles /portscan.html cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air
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 logic in blocking it? It is Queso they quoted not nmap, sorry -- same thing. The idea is to "detect" port scanners. Queso sets the two TCP reserved bits in the SYN (now allocated for ECN). Some OSes reflect that back in the SYN-ACK (Linux 2.0.2? for example was such a culprit). Queso could then use that information to narow down the OS detection. I suppose the idea is to detect Queso and react to it ;- cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
