[Dshield] Possible solution for ISP (was DShield's public goals)
dshield at oitc.com
Sat Jan 14 23:35:46 GMT 2006
This is one thing I am having problems with (eg ISPs are poor) My
understanding is that
1) ISPs in the far east (Korea etc) provide residential dsl to
customers at ~20Mbps and greater at the price point many in the US
pay for "dumbed down dsl" at 128Kbps and that residential customers
in France get 10Mbps.
2) Telcoms are spending huge $ lobbying Congress to allow them to
take over. Why would they do that if they can't make money in the biz?
3) Telecoms in North America are telling their conventional dialup
customers to stuff it if they can't get performance siting that "by
FCC/CTRC we don't have to provide service other than < 3 KHz for
voice BUT it you opt for us as an ISP we'll fix it." This has been
rammed down rural users throats in bioth Canada and US.
Large ISPs just want to grab profits without having to provide even a
modicum of service. They cry that they can't do this or that because
they have such small margins yet they spend huge money for lobbying
states and federal governments, spend large money trying to litigate
smaller ISPs out of business and spend big $ on advertising. What's
wrong with this picture?
We use a small ISP who provides great service for us and their
residential users and they keep their employees well paid, respond to
their own help desk calls rather than sending them to India, and are
not crying to regulators.
At 2:39 AM -0500 1/14/06, Valdis.Kletnieks at vt.edu wrote:
>Content-Type: multipart/signed; boundary="==_Exmh_1137224398_2901P";
> micalg=pgp-sha1; protocol="application/pgp-signature"
>On Fri, 13 Jan 2006 10:08:31 CST, Laura Vance said:
>> The ISPs don't have to start blocking until a majority of ISPs are
>> onboard with the system.
>Exactly the point. Not only do they not have to start blocking,
>*can't* start blocking. As a result, you have a very *large* dis-incentive to
>Profit margins in the ISP arena are razor thin - it's quite possible
>for an ISP
>to lose money on a customer that generates *one* help desk call per
>year. As a
>1) Yours is not the only scheme looking for deployment - and they can't afford
>to deploy all of them. There simply isn't enough money to go around. So,
>given 5 proposals, and only enough resources for 2 - which 2 do you support?
>Keep in mind that the 3 you don't support may end up stillborn - and the 2 you
>decided to support may *also* not work if your competitor decides to support 2
>others instead. All the ISPs have to *agree* on which 2 of 5 to support -
>*before* you have any actual deployment experience with any of the 5.
>2) A good trick to pull on your competitors is to announce you'll also support
>their pet proposal, and after they deploy, announce you're not going to,
>causing them to expend resources. You're betting your business plan on your
>competitor's announcements that aren't under your control - never conducive to
>3) It may come as a shock, but there are rogue ISPs out there, which
>they're participating, but in fact don't bother to. You remember Comcast's big
>"We will block port 25" PR-fest a while ago? How's that working
>out? Well, we
>can check SenderBase:
>"showing 1-50 of 49705". Yow. Lots of magnitude 5 and 6 entries. For
>comparison, listserv.vt.edu has been generating a relatively minor 30K emails
>per day off-campus per day of late, and only gets a magnitude 4.4. So *each*
>of those top 50 is pushing a quarter million e-mails per day and more.
>(Question - why are only 17 of the top 50 their official outbound
>and why are they not the top 17? ;)
>4) You fail to address what to do about address space that lies
>outside the US,
>or that is allocated to entities outside the US but has BGP announcements
>sourced inside the US. Do you block them, or allow them? Discuss the
>challenges of dealing with (3) when the offender is on another continent.
>5) There's also a very real possibility that unless your scheme has some sort
>of legislative backing, that a participating ISP could get sued into
>by a non-participating competitor ISP for restraint-of-trade issues.
>> The basic idea is very flexible, but it seems that all you are trying to
>> do is dismiss it or shoot it down with statements that have already been
>> addressed. If you spent the same effort helping to cultivate the idea
>> it would become a better system that could have ISPs jumping onboard.
>Simply repeating "ISPs dont' have to do this till they've all deployed it"
>because it's your mantra doesn't mean you're actually addressing the real
>problem, which is that you're asking some 3,000 ISPs to agree to deploy
>something that's untested, cannot be tested until their competitors
>it, and which they get no benefit from until it's fully deployed, and you're
>not making an actual *business case* for the ISP to shell out all these
>up-front resources, when the ISP would much rather put resources into projects
>that have either immediate or incremental gain, so they see benefits right off
>As Fergie pointed out, getting enough ISPs to deploy this will be difficult,
>given that even no-brainers like BCP38 (which *does* have immediate and
>incremental benefits for the ISP when they deploy, whether or not their
>competitors do as well) are only deployed by some 75% of the address space.
>In fact, the fact that the MIT Spoofer project is having trouble even getting
>an accurate *estimate* of how many places deploy BCP38 should be a big warning
>sign. See http://momo.lcs.mit.edu/spoofer/ for details....
>And as Fergie will attest, if you're thinking that *I* am being negative on
>your idea, you're in for a very rude awakening if/when you try to sell your
>idea on the IETF and NANOG lists (if you don't understand why you'll be on
>those lists to sell your idea, you're in over your head).
>Vernon Schryver got so tired of hearing modifications on the same
>ideas by people who didn't realize that maybe the idea had been
>of, examined, and discarded as unworkable multiple times, that he wrote this:
>(For bonus points - why did Vernon put the "critical thinker" entry on there?)
>Attachment converted: Macintosh HD:Untitled 257 ( / ) (0009B822)
>Learn about Intrusion Detection in Depth from the comfort of your own couch:
>send all posts to list at lists.dshield.org
>To change your subscription options (or unsubscribe), see:
Tom Shaw - Chief Engineer, OITC
<tshaw at oitc.com>, http://www.oitc.com/
US Phone Numbers: 321-984-3714, 321-729-6258(fax),
Text Paging: http://www.oitc.com/Pager/sendmessage.html
AIM/iChat: trshaw at mac.com
More information about the list