Sean Donelan wrote:
Damned if they do, Damned if they don't.
It seems like every 4-6 weeks people alternate between ISPs are bad because they don't try to prevent X, Y or Z; and then 4-6 weeks later ISPs are bad because they tried to prevent A, B or C. It doesn't matter what A, B, C or X, Y, Z are; it must be the ISPs fault.
Everyone agrees that ISPs are bad, they just disagree about what ISPs are supposed to do about whatever.
And so it goes...
Odd, I definitely don't recall saying outright ISP's are bad. More to the tune of "ISP's can do more given they're in the best position to do so..." which brings things full-circle, what can be done? How about an RFC, then building from there. Anyone can comment about the potential of "I'm not adding hundreds of thousands of null0's to my Cisco!@" and the point would be missed. As an NSP/NAP/ISP (pick your poison), you have the potential to see where your machines are connecting to. And I don't mean snooping their traffic outright, but its as simple as keeping tabs on a "destination", if you KNOW and it has been CONFIRMED, that the destination is a known purveyor "of un-fine" goods, wouldn't you like to potentially help your clients before they become zombiefied? If there was a method for operators to obtain information and share it, (think an unbiased, validated, "most wanted" list) do you really want to state that you wouldn't care about it, you couldn't use it. Surely I'd like to use something similar and if I were in a position to do something on a massive scale to eliminate bad traffic from 1) reaching my customers (since money is obvious the main concern) and 2) from making sure my customers don't affect your customers (YOUR money), I would jump up and down on it doing whatever I could. So it's not the ISP's are bad (at least to me they're not), it's more like "ISP OPERATORS/OWNERS are too busy fighting AGAINST things like this from happening, often spending more time and effort against it, then they are trying to collaboratively solve a problem." Analogy: "ALL gunmakers have seen their firearms mistakenly fire off at will (purposefully or accidentally). They all agree that by putting a safety mechanism, the rates of fatalities and injuries will go down. Some choose not to, because after all, they would need to spend more money to do so... Many protest against it: Smith and Wesson doesn't have that, why should I?!... Fatalities continue and gunmakers complain: All gunmakers are bad right, sure... uh-huh" What's wrong with that analogy. What about responsibility. Forget the politricks for a moment and think about the *ultimate* bottom line here... Would you like to prevent someone from possibly wrecking havoc on your personal bank account? Remember, what goes around comes around. You're not only doing neighbors (peers) a favor but if collectively the same approach was taken by many, there would be less "dirty traffic" around. No one on this list can seriously counter this claim. We can get into: "oh yea smart ass... They could encrypt!@... They could fast flux!!!, they could..." Guess what? What is anyone going to do when they can't connect? E.g: src(my_compromised_machine):port --> dst(known_dirty_host_on_X_net) My_NSP(hourly) ---> Mega_Peer_Dirty_Host_Watcher --> get_list_apply_filter Result: src(my_compromised_machine):port --> dst(known_dirty_host_on_X_net) --> My_Provider --> ::1 Anyway, just a thought, maybe a far out there thought, but I truly believe it can be done at an upstream level with little to no cost. I believe it costs more to sit around complaining and doing nothing than it does when you start losing customers because someone compromised them and wiped out their accounts driving them to bankruptcy. (http://krebsonsecurity.com/2010/02/n-y-firm-faces-bankruptcy-from-164000-e-b...) -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E