RE: Open Letter to D-Link about their NTP vandalism
"Service Area: Networks BGP-announced on the DIX" Since the intended (and announced) use of this server is just for DIX networks, blocking NTP from any other networks should be trivial. That IP address will still be hit by D-Link devices looking for a suitable server, but with no response, they'll move onto another device, and probably never try the DIX address again, at least until they're rebooted. That alone should kill off 95% of the unwanted traffic hitting the box, and probably 80% of the traffic even being sent to DIX in the first place. Chuck
On Sat, Apr 08, 2006 at 10:51:27AM -0500, Church, Chuck wrote:
Since the intended (and announced) use of this server is just for DIX networks, blocking NTP from any other networks should be trivial. That IP address will still be hit by D-Link devices looking for a suitable server, but with no response, they'll move onto another device, and probably never try the DIX address again, at least until they're rebooted. That alone should kill off 95% of the unwanted traffic hitting the box, and probably 80% of the traffic even being sent to DIX in the first place.
It would be nice if it were that simple. However there are an annoyingly large amount of poorly-written clients whose polling ratios do not decrease after they get no response from the server. There have even been some clients whose polling rate *increases* after they get no response.
On Sat, 08 Apr 2006 11:17:20 CDT, Nicholas Suan said:
It would be nice if it were that simple. However there are an annoyingly large amount of poorly-written clients whose polling ratios do not decrease after they get no response from the server. There have even been some clients whose polling rate *increases* after they get no response.
One particular piece of crapware of the tucows archive variety would retry once per second if it hadn't heard a response - but a ICMP Port Unreachable would trigger an *immediate* query, so it would basically re-query at whatever the RTT for the path was. Said software was why instead of leaving NTP disabled on the before-mentioned box, and hoping that at least *some* people would clue in from the ICMP reply, I had to basically firewall and drop the packets entirely.
On Mon, 10 Apr 2006 Valdis.Kletnieks@vt.edu wrote:
One particular piece of crapware of the tucows archive variety would retry once per second if it hadn't heard a response - but a ICMP Port Unreachable would trigger an *immediate* query, so it would basically re-query at whatever the RTT for the path was.
I've said in other forums the only solution for this sort of software is to return the wrong time (by several months). The owner might actually notice then and fix the problem. Just not returning anything means the time still works on the querying device (especially if it uses multiple servers) and the problem will not be noticed and it will continue. -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.
simon@darkmere.gen.nz (Simon Lyall) writes:
I've said in other forums the only solution for this sort of software is to return the wrong time (by several months). The owner might actually notice then and fix the problem.
that creates new liability, and isn't realistic in today's litigious world. -- Paul Vixie
On Tue, 11 Apr 2006, Paul Vixie wrote:
simon@darkmere.gen.nz (Simon Lyall) writes:
I've said in other forums the only solution for this sort of software is to return the wrong time (by several months). The owner might actually notice then and fix the problem.
that creates new liability, and isn't realistic in today's litigious world.
Everyone here runs spam filters. Many times a day you tell a remote MTA you've accepted their email but you delete it instead. Explain the difference? I run a NTP server, The only place it is advertised is a list which says "To be used by people in DK exchange only" . Explain the difference between my blocking someones packets (which causes them to just resend), send a KOD ( ntp for "go away") packet (which is ignored) and telling them the time is "2001-11-11 11:11:11" every time they ask? People running RBLs change the access policy or return 127.0.0.1 for every query sometimes. People running public Mail relays or public DNS servers regularly block access or return bad results. NTP provides a method to tell people to go away (The KOD packet) , if a remote client ignores that and keeps flooding your (or your upstream filters) with many udp packets per-second what exactly is someone supposed to do? There is no contract between the Server operator and the abusing client, The client is abusing the access policy and they have ignored the automatic request to go away. -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.
On Tue, 11 Apr 2006, Simon Lyall wrote:
Everyone here runs spam filters. Many times a day you tell a remote MTA you've accepted their email but you delete it instead. Explain the difference?
Hold on there. What you are describing is evil and bad, and I certainly hope "everyone" does not do that. When I do not wish to accept a message, I do not accept it, rejecting with an SMTP permanent delivery failure. Don't mean to go off on a tangent, but accepting and then silently discarding mail is a terrible idea. matto --matt@snark.net------------------------------------------<darwin>< Moral indignation is a technique to endow the idiot with dignity. - Marshall McLuhan
On Mon, 10 Apr 2006 23:23:06 -0700 (PDT) Matt Ghali <matt@snark.net> wrote:
On Tue, 11 Apr 2006, Simon Lyall wrote:
Everyone here runs spam filters. Many times a day you tell a remote MTA you've accepted their email but you delete it instead. Explain the difference?
Hold on there. What you are describing is evil and bad, and I certainly hope "everyone" does not do that.
When I do not wish to accept a message, I do not accept it, rejecting with an SMTP permanent delivery failure.
Don't mean to go off on a tangent, but accepting and then silently discarding mail is a terrible idea.
matto
Are you suggesting that we configure our e-mail servers to notify people upon automatic deletion of spam? Frequently, spam cannot be properly identified until closure of the SMTP conversation and that final 200 mMESSAGE ACCEPTED...or do you think that TCP/IP connection should be held open until the message can be scanned for spam and viruses just so we can give a 550 MESSAGE REJECTED error instead of silently dropping it? Because most spam originates from a bogus or stolen sender address, notification creates an even bigger problem. What's next: asking for permission to hang up on telemarketers? matthew black network services california state university, long beach
Matthew Black wrote:
On Mon, 10 Apr 2006 23:23:06 -0700 (PDT) Matt Ghali <matt@snark.net> wrote:
On Tue, 11 Apr 2006, Simon Lyall wrote:
Everyone here runs spam filters. Many times a day you tell a remote MTA you've accepted their email but you delete it instead. Explain the difference?
Hold on there. What you are describing is evil and bad, and I certainly hope "everyone" does not do that.
When I do not wish to accept a message, I do not accept it, rejecting with an SMTP permanent delivery failure.
Don't mean to go off on a tangent, but accepting and then silently discarding mail is a terrible idea.
This is way OT. Inline rejection -- best Notification after the fact -- Worst, but sometimes unavoidable Silent Disacard -- better then blanket notifications Try to limit the second in preference for the first. For anything in which your detection mechanism's accuracy is high enough, you can probably perform the last without much worry.
matto
Are you suggesting that we configure our e-mail servers to notify people upon automatic deletion of spam?
Dont do that. Notify the recpient if anything. Unfortunately they may learn to ignore such notifications, especialy if your system is fairly accurate. I advise against such "quarantine;store;notify;wait;delete" systems precisely because of this.
Frequently, spam cannot be properly identified until closure of the SMTP conversation and that final 200 mMESSAGE ACCEPTED...or do you think that TCP/IP connection should be held open until the message can be scanned for spam and viruses just so we can give a 550 MESSAGE REJECTED error instead of silently dropping it?
Yes, a 550 after completion of DATA with <cr><lf>.<cr><lf> is perfectly acceptable and preferable. Legit senders should hang around for the half minute or so to receive 220, and illegits will tend to drop the connection after being told 550.
Because most spam originates from a bogus or stolen sender address, notification creates an even bigger problem. What's next: asking for permission to hang up on telemarketers?
I do that all the time with barely a no thanks. My wife complains that I am rude to do so. I think not. The problem is in the word "most". With regards to anti-virus, "most" becomes "well upwards of 99%", and as such silent discard is more acceptable.
matthew black network services california state university, long beach
Hi Matt- On Tue, 11 Apr 2006, Matthew Black wrote:
Are you suggesting that we configure our e-mail servers to notify people upon automatic deletion of spam?
Absolutely not. I was responding to the suggestion that it's a good idea to silently drop mail which you have accepted with a 2xx SMTP rcode.
Frequently, spam cannot be properly identified until closure of the SMTP conversation and that final 200 mMESSAGE ACCEPTED..
I disagree. If your system cannot make content-based decisions on whether to accept mail until "later", it is broken by design.
.or do you think that TCP/IP connection should be held open until the message can be scanned for spam and viruses just so we can give a 550 MESSAGE REJECTED error instead of silently dropping it?
absolutely. is that actually a problem, today, in 2006?
Because most spam originates from a bogus or stolen sender address, notification creates an even bigger problem. What's next: asking for permission to hang up on telemarketers?
once again, I never advocated the generation of any such retarded blowback. matto --matt@snark.net------------------------------------------<darwin>< Moral indignation is a technique to endow the idiot with dignity. - Marshall McLuhan
Paul Vixie wrote:
simon@darkmere.gen.nz (Simon Lyall) writes:
I've said in other forums the only solution for this sort of software is to return the wrong time (by several months). The owner might actually notice then and fix the problem.
that creates new liability, and isn't realistic in today's litigious world.
(Suprise to read that from PV.) It is DIX resources/equipements... they are not oblige to offer reliable/secure/valide/etc services to anybody outside their clients. It like saying that blacklist services like spamcop should be liable for mail servers XYZ deleting your email. Anyway *litigious* is kinda limited our south neighbourgh... DIX is under a different legal system. Good luck to DLink lawyers trying to bend reality enought the make DLink right... and oblige DIX to offer NTP to DLink customers for free. Now if we can get this letter into Wired... -- Alain Hebert ahebert@pubnix.net PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7 tel 514-990-5911 http://www.pubnix.net fax 514-990-9443
On Tue, Apr 11, 2006 at 02:04:39AM -0400, Alain Hebert wrote:
Paul Vixie wrote:
simon@darkmere.gen.nz (Simon Lyall) writes:
I've said in other forums the only solution for this sort of software is to return the wrong time (by several months). The owner might actually notice then and fix the problem.
that creates new liability, and isn't realistic in today's litigious world.
(Suprise to read that from PV.)
Why? It may be the voice of experience. In this country, and in many others with hypertrophied legal systems, one may sue another for any reason whatsoever. If the person bringing suit picks the judge carefully, the suit might even not be recognised as idiotic and thrown out immediately as without merit. It is obvious that D-Link should not be doing this to DIX, no matter how short a skirt DIX may be wearing. [;-)] However, why should DIX try to turn around and do likewise to innocent D-Link customers, even given that most of them would not notice it? -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
Joseph S D Yao wrote:
On Tue, Apr 11, 2006 at 02:04:39AM -0400, Alain Hebert wrote:
Paul Vixie wrote:
simon@darkmere.gen.nz (Simon Lyall) writes:
I've said in other forums the only solution for this sort of software is to return the wrong time (by several months). The owner might actually notice then and fix the problem.
that creates new liability, and isn't realistic in today's litigious world.
(Suprise to read that from PV.)
Why? It may be the voice of experience. In this country, and in many others with hypertrophied legal systems, one may sue another for any reason whatsoever. If the person bringing suit picks the judge carefully, the suit might even not be recognised as idiotic and thrown out immediately as without merit.
It is obvious that D-Link should not be doing this to DIX, no matter how short a skirt DIX may be wearing. [;-)]
However, why should DIX try to turn around and do likewise to innocent D-Link customers, even given that most of them would not notice it?
Because its DIX ressources... They can do whatever they want with it. They owe nothing to DLink customers, and DLink customers should know to buy equipments from a better company that do not trespasses on other properties. Enough of them might see it and make enough chatter to get DLink to fire that idiotic engineering team and fix that flaw. Because at the end of the day... It is a flaw. As a device developer myself, I always ask... what would Cisco do. (;-} -- Alain Hebert ahebert@pubnix.net PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7 tel 514-990-5911 http://www.pubnix.net fax 514-990-9443
I've said in other forums the only solution for this sort of software is to return the wrong time (by several months). The owner might actually notice then and fix the problem.
that creates new liability, and isn't realistic in today's litigious world.
(Suprise to read that from PV.)
Why? It may be the voice of experience. ...
Because its DIX ressources... They can do whatever they want with it.
actually, not. who owns the resources isn't as important, to a judge, as whether someone is damaged and whether that damage resulted from an intentional act. the "voice of experience", if i have one, says that if DIX wants to cease providing this service they can do so safely, but if they decide to deliberately return the wrong time, and if that wrong time costs or loses somebody else some money, then a judge would take it seriously. again, denying service (assuming there's no explicit contract to provide it) is unquestionably safe. i was responding to the proposal that the wrong time be deliberately returned. you'd be betting that nobody would notice or that it would cost nobody money -- which isn't a safe bet, since someone can always find ways to allege that your intentional actions cost them money. (as opposed to your deliberate inaction, as in the case of denying service.) note, IANAL. but i've been sued by experts, and even stupid lawsuits cost a lot to answer/defend, and not all stupid lawsuits are provably frivolous. -- Paul Vixie
Paul Vixie wrote:
I've said in other forums the only solution for this sort of software is to return the wrong time (by several months). The owner might actually notice then and fix the problem.
that creates new liability, and isn't realistic in today's litigious world.
(Suprise to read that from PV.)
Why? It may be the voice of experience. ...
Because its DIX ressources... They can do whatever they want with it.
actually, not. who owns the resources isn't as important, to a judge, as whether someone is damaged and whether that damage resulted from an intentional act. the "voice of experience", if i have one, says that if DIX wants to cease providing this service they can do so safely, but if they decide to deliberately return the wrong time, and if that wrong time costs or loses somebody else some money, then a judge would take it seriously.
again, denying service (assuming there's no explicit contract to provide it) is unquestionably safe. i was responding to the proposal that the wrong time be deliberately returned. you'd be betting that nobody would notice or that it would cost nobody money -- which isn't a safe bet, since someone can always find ways to allege that your intentional actions cost them money. (as opposed to your deliberate inaction, as in the case of denying service.)
note, IANAL. but i've been sued by experts, and even stupid lawsuits cost a lot to answer/defend, and not all stupid lawsuits are provably frivolous.
I see that... Anyway legal thread always finish in the same dead end... Lets get DIX case into the media and get DLink to take its responasbilities. I'm sure with enought spin in the right media (blog/Wired/Computer Show) this could be solved quite rapidely. Have fun... -- Alain Hebert ahebert@pubnix.net PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7 tel 514-990-5911 http://www.pubnix.net fax 514-990-9443
This reminds me of "selective availability" (I think that's the correct term) in the GPS stream coming from US DOD orbital platforms. Sure, the data is jittered. Who sues because only authorized clients (in that case, US military forces) get unjittered time and position but folks without authorization get severely compromised time and position data? What is to prevent a network from providing unjittered NTP to its downstream clients/customers BUT jittered NTP to outsiders? How is this different from providing up-to-the-millisecond stock exchange data to paying customers but delaying the same data provided to the general public by some time period? Are we constrained by fear of litigation from taking appropriate pro-active measures to protect services from abuse and from discriminating between legitimate and questionable requests for data from our own servers? Is it time to bail out of the Internet business? David Leonard ShaysNet On 11 Apr 2006, Paul Vixie wrote:
I've said in other forums the only solution for this sort of software is to return the wrong time (by several months). The owner might actually notice then and fix the problem.
that creates new liability, and isn't realistic in today's litigious world.
(Suprise to read that from PV.)
Why? It may be the voice of experience. ...
Because its DIX ressources... They can do whatever they want with it.
actually, not. who owns the resources isn't as important, to a judge, as whether someone is damaged and whether that damage resulted from an intentional act. the "voice of experience", if i have one, says that if DIX wants to cease providing this service they can do so safely, but if they decide to deliberately return the wrong time, and if that wrong time costs or loses somebody else some money, then a judge would take it seriously.
again, denying service (assuming there's no explicit contract to provide it) is unquestionably safe. i was responding to the proposal that the wrong time be deliberately returned. you'd be betting that nobody would notice or that it would cost nobody money -- which isn't a safe bet, since someone can always find ways to allege that your intentional actions cost them money. (as opposed to your deliberate inaction, as in the case of denying service.)
note, IANAL. but i've been sued by experts, and even stupid lawsuits cost a lot to answer/defend, and not all stupid lawsuits are provably frivolous. -- Paul Vixie
On Wed, 12 Apr 2006, M. David Leonard wrote:
This reminds me of "selective availability" (I think that's the correct term) in the GPS stream coming from US DOD orbital platforms. Sure, the data is jittered.
Hasn't been for several years. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 5 OR 6, PERHAPS INCREASING 7 LATER IN NORTH. RAIN AT FIRST. MAINLY GOOD. SLIGHT OR MODERATE.
"M. David Leonard" <mdl@equinox.shaysnet.com> writes:
What is to prevent a network from providing unjittered NTP to its downstream clients/customers BUT jittered NTP to outsiders? How is this different from providing up-to-the-millisecond stock exchange data to paying customers but delaying the same data provided to the general public by some time period?
"All quotes and all NTP ticks are delayed 15 minutes" is an amusing concept.
Are we constrained by fear of litigation from taking appropriate pro-active measures to protect services from abuse and from discriminating between legitimate and questionable requests for data from our own servers? Is it time to bail out of the Internet business?
Listen to Paul; he's a past master at defending against gratuitous/stupid lawsuits. You're under no obligation to provide the service, but actively providing bad info could be construed as a tort, and defending/filing lawsuits, like horse racing (owning the horses, not going to the races), is a sport for the super-well-heeled. ---Rob
FYI: a couple of update at http://people.freebsd.org/~phk/dlink/ I've summited a suggestion for a story to Wired... We'll see. -- Alain Hebert ahebert@pubnix.net PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7 tel 514-990-5911 http://www.pubnix.net fax 514-990-9443
At 10:15 AM -0400 4/12/06, Alain Hebert wrote:
FYI: a couple of update at http://people.freebsd.org/~phk/dlink/
I've summited a suggestion for a story to Wired... We'll see.
Perhaps they could also talk to someone who actually knows how ntp works as well. -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan@renesys.com
On Tue, 11 Apr 2006, Alain Hebert wrote:
Because its DIX ressources... They can do whatever they want with it.
They owe nothing to DLink customers, and DLink customers should know to buy equipments from a better company that do not trespasses on other properties.
And how exactly will the typical person buying a consumer-grade router even know something's wrong, in this case? -- Steve Sobol, Professional Geek ** Java/VB/VC/PHP/Perl ** Linux/*BSD/Windows Apple Valley, CA Resident of Southern California - the home of beautiful people and butt-ugly traffic jams
Steve Sobol wrote:
On Tue, 11 Apr 2006, Alain Hebert wrote:
Because its DIX ressources... They can do whatever they want with it.
They owe nothing to DLink customers, and DLink customers should know to buy equipments from a better company that do not trespasses on other properties.
And how exactly will the typical person buying a consumer-grade router even know something's wrong, in this case?
(A NTP/KOD packet should be nice...) The cattle that buy those products dont care about DIX. But DLink might start to care if it gets in the media... -- Alain Hebert ahebert@pubnix.net PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7 tel 514-990-5911 http://www.pubnix.net fax 514-990-9443
On Tue, 11 Apr 2006 02:04:39 EDT, Alain Hebert said:
Paul Vixie wrote:
that creates new liability, and isn't realistic in today's litigious world. It is DIX resources/equipements... they are not oblige to offer reliable/secure/valide/etc services to anybody outside their clients.
It like saying that blacklist services like spamcop should be liable for mail servers XYZ deleting your email.
Paul is speaking from experience, having dealt with altogether too many people who *do* believe that services Spamcop should be liable... Even if it isn't a *legal* liability where you're forced to pay out damages, having to carry '$100,000 legal fees' on the balance sheet is an accounting liability, not an asset....
At 08:36 PM 10/04/2006, Simon Lyall wrote:
I've said in other forums the only solution for this sort of software is to return the wrong time (by several months). The owner might actually notice then and fix the problem.
Of our customers who have such routers, I would say 90% would not know the unit even kept time, let alone the correct or incorrect time. ---Mike
It seems to me, that the only *real* solution is for these manufacturers to implement a [responsible] strategy of automatic firmware upgrades, as it pertains to these (simple eu type) devices. How difficult would it be to have the router test a server periodically, (say once a month), and in the case of a critical flaw in the software, silently update the device? I suspect it is cost/benefit skepticism that is keeping them from doing just that. John ----- Original Message ----- From: "Mike Tancsa" <mike@sentex.net> To: "Simon Lyall" <simon@darkmere.gen.nz>; <nanog@nanog.org> Sent: Tuesday, April 11, 2006 9:05 AM Subject: Re: Open Letter to D-Link about their NTP vandalism
At 08:36 PM 10/04/2006, Simon Lyall wrote:
I've said in other forums the only solution for this sort of software is to return the wrong time (by several months). The owner might actually notice then and fix the problem.
Of our customers who have such routers, I would say 90% would not know the unit even kept time, let alone the correct or incorrect time.
---Mike
On Tue, 11 Apr 2006 10:28:32 -0400, "John Underhill" <stepnwlf@magma.ca> wrote:
It seems to me, that the only *real* solution is for these manufacturers to implement a [responsible] strategy of automatic firmware upgrades, as it pertains to these (simple eu type) devices. How difficult would it be to have the router test a server periodically, (say once a month), and in the case of a critical flaw in the software, silently update the device? I suspect it is cost/benefit skepticism that is keeping them from doing just that.
It would be a disaster. My (cable modem) ISP does that to my cable modem/NAT box. A few months ago, a buggy update made the NAT part drop all connections after 30 minutes. It took me a week or so to get enough data to nail down the problem precisely. I then had the fun of trying to get through the phone droids to reach someone who understood what "NAT" or "TCP" meant. What unusual combination of features will random upgrades break? By the way, since we're talking about D-Link, it's instructive to read the warnings on their firmware update pages. Do NOT upgrade firmware on any D-Link product over a wireless connection. Failure of the device may result. Use only hard-wired network connections. This firmware is engineered for US products only. Using this firmware on a device outside of the United States will void your warranty and may render the device unusable. Other warnings I've seen include warnings that all configuration options will be reset, version incompatibilities, and the suggestion that one should connect to a UPS before doing the upgrade, just in case. (Hmm -- there's a vicious thunderstorm approaching, and the lights are flickering. And it's time for the monthly autoupgrade!) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
As I replied in a comment offline, auto updating firmware is nothing new.. my cellphone updates itself, as does my satellite receiver, and many other devices as well, (the best of which, perform these tasks without our notice or appreciation). There is of course the potential for a bug causing some unforeseen catastrophy, but much of the risk could be mitigated with a bit of planning and a well designed system, (ex. old image is stored, and boot failure loads that image.. image is first downloaded, test md5, then flashed etc). Servers have been using these technologies for quite a while now, all tested and true. Also, one would expect the vendors to release updates only when necessary, with some serious QA before a release, (but if they did that in the first place, we wouldn't be having this discussion ;o) Just a thought. John ----- Original Message ----- From: "Steven M. Bellovin" <smb@cs.columbia.edu> To: "John Underhill" <stepnwlf@magma.ca> Cc: <simon@darkmere.gen.nz>; <nanog@nanog.org>; <mike@sentex.net> Sent: Tuesday, April 11, 2006 12:24 PM Subject: Re: Open Letter to D-Link about their NTP vandalism
On Tue, 11 Apr 2006 10:28:32 -0400, "John Underhill" <stepnwlf@magma.ca> wrote:
It seems to me, that the only *real* solution is for these manufacturers to implement a [responsible] strategy of automatic firmware upgrades, as it pertains to these (simple eu type) devices. How difficult would it be to have the router test a server periodically, (say once a month), and in the case of a critical flaw in the software, silently update the device? I suspect it is cost/benefit skepticism that is keeping them from doing just that.
It would be a disaster. My (cable modem) ISP does that to my cable modem/NAT box. A few months ago, a buggy update made the NAT part drop all connections after 30 minutes. It took me a week or so to get enough data to nail down the problem precisely. I then had the fun of trying to get through the phone droids to reach someone who understood what "NAT" or "TCP" meant. What unusual combination of features will random upgrades break?
By the way, since we're talking about D-Link, it's instructive to read the warnings on their firmware update pages.
Do NOT upgrade firmware on any D-Link product over a wireless connection. Failure of the device may result. Use only hard-wired network connections.
This firmware is engineered for US products only. Using this firmware on a device outside of the United States will void your warranty and may render the device unusable.
Other warnings I've seen include warnings that all configuration options will be reset, version incompatibilities, and the suggestion that one should connect to a UPS before doing the upgrade, just in case. (Hmm -- there's a vicious thunderstorm approaching, and the lights are flickering. And it's time for the monthly autoupgrade!)
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
On Tue, 11 Apr 2006, Steven M. Bellovin wrote:
By the way, since we're talking about D-Link, it's instructive to read the warnings on their firmware update pages.
Do NOT upgrade firmware on any D-Link product over a wireless connection. Failure of the device may result. Use only hard-wired network connections.
Cisco/Linksys says the same thing. -- Steve Sobol, Professional Geek ** Java/VB/VC/PHP/Perl ** Linux/*BSD/Windows Apple Valley, CA Resident of Southern California - the home of beautiful people and butt-ugly traffic jams
On 4/12/06, Steve Sobol <sjsobol@justthe.net> wrote:
On Tue, 11 Apr 2006, Steven M. Bellovin wrote:
By the way, since we're talking about D-Link, it's instructive to read the warnings on their firmware update pages.
Do NOT upgrade firmware on any D-Link product over a wireless connection. Failure of the device may result. Use only hard-wired network connections.
Cisco/Linksys says the same thing.
Who here hasn't been burned at least once by changing packet filters, routes or interface configurations over the wire/air? Or maybe getting your userland and kernel out of sync on a *NIX machine? It's not really that surprising that they put that in there, other than maybe the fact that it's useful advice. And maybe it'll reduce support costs. Loading a new firmware is a risky operation - I don't know of too many consumer network widgets with a reflash safety protocol to prevent you from destroying the device with an aborted upload. Heck, that's still a pretty rare feature in pee-cees. Sure it's easy to implement such a thing, but that would cost money. I think this thread has done a good job of demonstrating that those who would choose the right (and maybe slightly more expensive up front) solution are outvoted by those who would just take a quick, cheap and easy hack. CK -- GDB has a 'break' feature; why doesn't it have 'fix' too?
On Wed, 12 Apr 2006, Steve Sobol wrote:
On Tue, 11 Apr 2006, Steven M. Bellovin wrote:
By the way, since we're talking about D-Link, it's instructive to read the warnings on their firmware update pages. Do NOT upgrade firmware on any D-Link product over a wireless connection. Failure of the device may result. Use only hard-wired network connections. Cisco/Linksys says the same thing.
It is safe to do it with openwrt at least. scp the firmware to a local file, then update flash from that file. -Dan
To keep this operational: Operationally the network operator should contact a lawyer before doing something like this. Purposely and knowingly sending bad data in order to do harm is a counter-attack. As such it might be vigilantism, which is illegal in most countries. Or it might be self-defense, which is not illegal. Might. Contact a lawyer. John At 07:36 PM 4/10/2006, Simon Lyall wrote:
On Mon, 10 Apr 2006 Valdis.Kletnieks@vt.edu wrote:
One particular piece of crapware of the tucows archive variety would retry once per second if it hadn't heard a response - but a ICMP Port Unreachable would trigger an *immediate* query, so it would basically re-query at whatever the RTT for the path was.
I've said in other forums the only solution for this sort of software is to return the wrong time (by several months). The owner might actually notice then and fix the problem.
Just not returning anything means the time still works on the querying device (especially if it uses multiple servers) and the problem will not be noticed and it will continue.
-- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.
It's legal to have broken NTP server in ANY country, and it's legal in most (by number) countries to send counter-attack (except USA as usual, where lawyers want to get their money and so do not allow people to self-defence). So, it can be a GOOD prtactice in reality. But, of course, not in USA. ----- Original Message ----- From: "John Dupuy" <jdupuy-list@socket.net> To: <nanog@nanog.org> Sent: Tuesday, April 11, 2006 9:00 AM Subject: Re: Open Letter to D-Link about their NTP vandalism
To keep this operational: Operationally the network operator should contact a lawyer before doing something like this.
Purposely and knowingly sending bad data in order to do harm is a counter-attack. As such it might be vigilantism, which is illegal in most countries. Or it might be self-defense, which is not illegal. Might. Contact a lawyer.
John
At 07:36 PM 4/10/2006, Simon Lyall wrote:
On Mon, 10 Apr 2006 Valdis.Kletnieks@vt.edu wrote:
One particular piece of crapware of the tucows archive variety would
retry
once per second if it hadn't heard a response - but a ICMP Port Unreachable would trigger an *immediate* query, so it would basically re-query at whatever the RTT for the path was.
I've said in other forums the only solution for this sort of software is to return the wrong time (by several months). The owner might actually notice then and fix the problem.
Just not returning anything means the time still works on the querying device (especially if it uses multiple servers) and the problem will not be noticed and it will continue.
-- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.
On Tue, 2006-04-11 at 09:28:14 -0700, Alexei Roudnev proclaimed...
It's legal to have broken NTP server in ANY country, and it's legal in most (by number) countries to send counter-attack (except USA as usual, where lawyers want to get their money and so do not allow people to self-defence).
Usually I take my time from more than one server anyway, and discard the bogus time. You'd think that d-link's crackshot development team would do this, as well. - Eric
<law professor> I'd really suggest that readers confirm this claim (that intentional sending of false data with a malicious purpose is perfectly acceptable) with a local lawyer before trying it at home or at work.</law professor> I also bet that the claim of widespread acceptability would fail badly if we weigh countries by population. Or even connectivity. Not to mention the fact that your packets might stray across borders sometimes. On Tue, 11 Apr 2006, Alexei Roudnev wrote:
It's legal to have broken NTP server in ANY country, and it's legal in most (by number) countries to send counter-attack (except USA as usual, where lawyers want to get their money and so do not allow people to self-defence).
-- http://www.icannwatch.org Personal Blog: http://www.discourse.net A. Michael Froomkin | Professor of Law | froomkin@law.tm U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA +1 (305) 284-4285 | +1 (305) 284-6506 (fax) | http://www.law.tm -->It's warm here.<--
Hmm, if some idiot wrote my NTP IP into his hardware, I just stop to monitor my NTP and make sure that it have few hours of error in time. No one require me to CLAIM that I set up wrong time, BUT no one can require me to maintain correct time just because some idiots use my server. The same in this case - instead of long claiming, complaining and so on they could just set up wrong time (and never claim that they did it - just _oo, we have a wrong time.. Thanks, but we do not maintain this NTP server and we cannot change anything on this server so we cannot correct it_ - and problem could be solved forever. And even could maintain different NTP translation fro their customers. Just again, no one can prohibit it, even in USA. Just _DO NOT CLAIM_ that it was intentionally. Here is a difference - _coffee is hot, someone's server is brokn, if 'Ivan||Paul||Lisa' have a CD he/she always can make a copy, fire can burn, dog can bite_ - everyone should know it; if he do not know, it's his personal problems, not someone's liability. Kids MUST learn such things when they are young. It is COMMON SENSE. ----- Original Message ----- From: "Michael Froomkin - U.Miami School of Law" <froomkin@law.miami.edu> To: "Alexei Roudnev" <alex@relcom.net> Cc: <nanog@nanog.org>; "John Dupuy" <jdupuy-list@socket.net> Sent: Tuesday, April 11, 2006 11:29 AM Subject: Re: Open Letter to D-Link about their NTP vandalism
<law professor> I'd really suggest that readers confirm this claim (that intentional sending of false data with a malicious purpose is perfectly acceptable) with a local lawyer before trying it at home or at work.</law professor>
I also bet that the claim of widespread acceptability would fail badly if we weigh countries by population. Or even connectivity.
Not to mention the fact that your packets might stray across borders sometimes.
On Tue, 11 Apr 2006, Alexei Roudnev wrote:
It's legal to have broken NTP server in ANY country, and it's legal in
most
(by number) countries to send counter-attack (except USA as usual, where lawyers want to get their money and so do not allow people to self-defence).
-- http://www.icannwatch.org Personal Blog: http://www.discourse.net A. Michael Froomkin | Professor of Law | froomkin@law.tm U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA +1 (305) 284-4285 | +1 (305) 284-6506 (fax) | http://www.law.tm -->It's warm here.<--
On 12/04/06, Alexei Roudnev <alex@relcom.net> wrote:
Hmm, if some idiot wrote my NTP IP into his hardware, I just stop to monitor my NTP and make sure that it have few hours of error in time. No one require me to CLAIM that I set up wrong time, BUT no one can require me to maintain correct time just because some idiots use my server.
That works well as long as you don't have any legitimate users of your NTP service. -- Tony Sarendal - tony@polarcap.org IP/Unix -= The scorpion replied, "I couldn't help it, it's my nature" =-
Thus spake "Alexei Roudnev" <alex@relcom.net>
Hmm, if some idiot wrote my NTP IP into his hardware, I just stop to monitor my NTP and make sure that it have few hours of error in time. No one require me to CLAIM that I set up wrong time, BUT no one can require me to maintain correct time just because some idiots use my server.
What most people participating in this subthread seem to be missing is that if one did decide to send (or accidentally sent) false time to these D-Link devices, NOBODY WOULD EVER KNOW OR CARE. Doing so does not solve any problems, so whatever the legal risk of acting is, no matter how small, it's not worth it. On the plus side, after seeing D-Link's (lack of) reaction to this, I'll bet none of us will buy another of their products again. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
On Wed, Apr 12, 2006 at 01:32:26PM -0500, Stephen Sprunk wrote:
On the plus side, after seeing D-Link's (lack of) reaction to this, I'll bet none of us will buy another of their products again.
If it was legal to sell whatever you people are smoking that makes you think dlink gives a flying crap about you as customers, I'd be a very rich man. What part of "mass consumer product" isn't clear here, 99.9% of their target market doesn't know NTP is, and doesn't care. I am absolutely appalled by the number of "slashdot warriors" here, ready to launch a crusade of spreading misinformation to the media in hopes of obtaining a large monetary payout or otherwise causing dlink, in the name of "doing the right thing", and without any consideration or understanding of the facts at hand. You know why dlink can't just come forward and say "woops we're sorry, we didn't see that you wanted this used for DIX members only, our bad"? Because they have to contend with people who will take that apology and then use it in court as an admission of guilt, and seek many tens of thousands of dollars or more in non-existent damages. I think we all know that dlink was wrong. They should have double-checked the list of NTP servers they included in their default shipping firmware to make certain that the owners were ok with having their services used publically, there is no question about this. However, just because they made this mistake, it is not an excuse for everyone involved to start cashing in like they hit the lottery. Imagine that you get rear ended in traffic by an inattentive driver, and they dent your bumper. Yes it is their fault, yes they made a mistake and they should be responsible for it, but it is not okay for you to start screaming whiplash as soon as you see that you got hit by a Mercedes. It also doesn't mean that you are going to get a new car instead of them paying to have your bumper fixed. If anyone else is going to carry this as a story, please act responsibly and do a little fact checking. We're talking about 37 packets/sec, less than a dialup worth of bandwidth, and any number of technical solutions which could completely mitigate that traffic without ANY additional expenses. Also, IANAL, but I think that refusing to take reasonable action to mitigate the damages because you feel the other party is "at fault" and should be 100% responsible is probably a good way to hurt any kind of case you might actually have against them too. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Well, With the way you named your address book (North American Noise and Off-topic Gripes). We now know where to fill your futur comments. (In the killfile that is) Richard A Steenbergen wrote:
On Wed, Apr 12, 2006 at 01:32:26PM -0500, Stephen Sprunk wrote:
On the plus side, after seeing D-Link's (lack of) reaction to this, I'll bet none of us will buy another of their products again.
If it was legal to sell whatever you people are smoking that makes you think dlink gives a flying crap about you as customers, I'd be a very rich man. What part of "mass consumer product" isn't clear here, 99.9% of their target market doesn't know NTP is, and doesn't care.
I am absolutely appalled by the number of "slashdot warriors" here, ready to launch a crusade of spreading misinformation to the media in hopes of obtaining a large monetary payout or otherwise causing dlink, in the name of "doing the right thing", and without any consideration or understanding of the facts at hand. You know why dlink can't just come forward and say "woops we're sorry, we didn't see that you wanted this used for DIX members only, our bad"? Because they have to contend with people who will take that apology and then use it in court as an admission of guilt, and seek many tens of thousands of dollars or more in non-existent damages.
As a (older, since '87) operator of a small network, I'll always help other operators when its question of making the 'net better. Good luck advocating the next turd coming from sub-standard design flow that contributed to the DIX issues with DLink. Me, I prefer to strive for excellence...
I think we all know that dlink was wrong. They should have double-checked the list of NTP servers they included in their default shipping firmware to make certain that the owners were ok with having their services used publically, there is no question about this. However, just because they made this mistake, it is not an excuse for everyone involved to start cashing in like they hit the lottery. Imagine that you get rear ended in traffic by an inattentive driver, and they dent your bumper. Yes it is their fault, yes they made a mistake and they should be responsible for it, but it is not okay for you to start screaming whiplash as soon as you see that you got hit by a Mercedes. It also doesn't mean that you are going to get a new car instead of them paying to have your bumper fixed.
FYI I didn't read anything about somebody looking to make money on this...
If anyone else is going to carry this as a story, please act responsibly and do a little fact checking. We're talking about 37 packets/sec, less than a dialup worth of bandwidth, and any number of technical solutions which could completely mitigate that traffic without ANY additional expenses. Also, IANAL, but I think that refusing to take reasonable action to mitigate the damages because you feel the other party is "at fault" and should be 100% responsible is probably a good way to hurt any kind of case you might actually have against them too.
Yeap.... x packets/sec times millions... -- Alain Hebert ahebert@pubnix.net PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7 tel 514-990-5911 http://www.pubnix.net fax 514-990-9443
Alain Hebert wrote:
With the way you named your address book (North American Noise and Off-topic Gripes).
We now know where to fill your futur comments. (In the killfile that is)
You don't seem to want to act very responsibly, based on your comments here, so it doesn't surprise me that you don't want to see Richard taking you to task for not acting responsibly. What bothers me is that you seem to think you are in the right and don't want to listen to suggestions to the contrary. The intended audience of the NANOG mailing list consists primarily of professionals who are paid to operate computer networks on behalf of large numbers of other people. Said professionals have a responsibility to operate said networks in a professional manner. You're wrong. Richard is right. **SJ "you're allowed to express your opinion here, just as I'm allowed to tell you your opinion is silly" S -- Steve Sobol, Professional Geek ** Java/VB/VC/PHP/Perl ** Linux/*BSD/Windows Apple Valley, CA Resident of Southern California - the home of beautiful people and butt-ugly traffic jams
Steve Sobol wrote:
Alain Hebert wrote:
With the way you named your address book (North American Noise and Off-topic Gripes).
We now know where to fill your futur comments. (In the killfile that is)
You don't seem to want to act very responsibly, based on your comments here, so it doesn't surprise me that you don't want to see Richard taking you to task for not acting responsibly.
What bothers me is that you seem to think you are in the right and don't want to listen to suggestions to the contrary.
Its a cultural issue... Its not right versus wrong but amelioration versus status-quo... Its DLink creating hardship to DIX and answering "make me" to DIX request...
The intended audience of the NANOG mailing list consists primarily of professionals who are paid to operate computer networks on behalf of large numbers of other people. Said professionals have a responsibility to operate said networks in a professional manner.
R didnt show that naming his addressbook that way...
You're wrong. Richard is right.
... long punt deleted ... Well I just saw your .sig... Can't give any credit to your statement.
**SJ "you're allowed to express your opinion here, just as I'm allowed to tell you your opinion is silly" S
Duh. -- Alain Hebert ahebert@pubnix.net PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7 tel 514-990-5911 http://www.pubnix.net fax 514-990-9443
Alain Hebert wrote:
Its a cultural issue...
I acknowledge that there are cultural differences, but... y'know, two wrongs, etc.
Its not right versus wrong but amelioration versus status-quo...
It is *both.* DLink is being obnoxious. That doesn't mean being obnoxious back is the right answer.
Well I just saw your .sig... Can't give any credit to your statement.
Your choice. I don't see any sense in arguing the point further, as you probably won't change your mind. -- Steve Sobol, Professional Geek ** Java/VB/VC/PHP/Perl ** Linux/*BSD/Windows Apple Valley, CA Resident of Southern California - the home of beautiful people and butt-ugly traffic jams
SS> Date: Thu, 13 Apr 2006 22:22:11 -0700 SS> From: Steve Sobol Apologies in advance for the OT post... SS> > Well I just saw your .sig... Can't give any credit to your statement. SS> SS> Your choice. I don't see any sense in arguing the point further, as you SS> probably won't change your mind. The irony is that ad hominem attacks and signature debates truly _do_ make the list noise and off-topic gripes. (Not directed at anyone in particular. Steve's post seemed like a logical place to respond.) Let's at least keep the flames relevant. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
[ In response to Richard A Steenbergen ] Alain Hebert said:
Well,
With the way you named your address book (North American Noise and Off-topic Gripes).
We now know where to fill your futur comments. (In the killfile that is)
That Cc: came from my message, and RAS didn't change it back to something inoffensive when he replied to me. While one can certainly find reasons to killfile RAS, this is not one of them. Grow a sense of humor, already... S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
What most people participating in this subthread seem to be missing is
that
if one did decide to send (or accidentally sent) false time to these D-Link devices, NOBODY WOULD EVER KNOW OR CARE. Doing so does not solve any problems, so whatever the legal risk of acting is, no matter how small, it's not worth it.
But there is a larger issue of NTP abuse here that needs a coordinated technical and legal approach. I suggest that if you are going to operate a public NTP server you should also run a web server at the same IP address and publish your terms of service. If you have given public advance notice of what constitutes normal use, and what constitutes abuse, then you are on stronger legal ground. And if you state that those abusing the service will be disconnected by sending a KoD packet, and that users who persist after the KoD packet will receive a jittered time signal (or delayed or whatever), then you are on even stronger legal ground. Of course, you should always consult your lawyer on the legalities, but it helps your lawyer if you have a clear and well-thought out approach to present to him. This thread has had a lot of good info about NTP best practices so I consider it worthwhile, even if most of the responses were tangential to the original issue. --Michael Dillon
participants (29)
-
Alain Hebert -
Alexei Roudnev -
Chris Kuethe -
Church, Chuck -
Edward B. DREGER -
Eric Pancer -
goemon＠anime.net -
Joe Maimon -
John Dupuy -
John Underhill -
Joseph S D Yao -
M. David Leonard -
Martin Hannigan -
Matt Ghali -
Matthew Black -
Michael Froomkin - U.Miami School of Law -
Michael.Dillon＠btradianz.com -
Mike Tancsa -
Nicholas Suan -
Paul Vixie -
Richard A Steenbergen -
Robert E.Seastrom -
Simon Lyall -
Stephen Sprunk -
Steve Sobol -
Steven M. Bellovin -
Tony Finch -
tony sarendal -
Valdis.Kletnieks＠vt.edu