ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-ff-pdp-may08] Crafting a solution for fast flux

  • To: dave.piscitello@xxxxxxxxx
  • Subject: Re: [gnso-ff-pdp-may08] Crafting a solution for fast flux
  • From: Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>
  • Date: Thu, 17 Jul 2008 10:01:17 -0700

Dave commented:

#YES on public encouragement to ISPs to provide abuse reporting. I am 
#curious whether you mean "flag the ISP" 

I'm saying "explicitly note that an ISP has declined to provide abuse
reporting channels" (asuming that's the case). 

Currently, IF no abuse reporting channel is listed, that can mean, "an 
abuse reporting channel may exist, but it isn't listed because this is an 
old whois entry that dates from pastoral days when abuse reporting wasn't 
a pressing issue," or that lack of a documented abuse reporting channel 
can reflect an explicit choice, perhaps "abuse handling is a cost center 
rather than a profit center, and so as a result we've decided not to have 
one. Now b*gger off and don't bother us about stuff we don't care about."

Their domain, their network, their choice. 

I'd just like a way to distinguish the two otherwise indistinguishable 
possibilities, and I'd like to encourage documentation of the address(es)
that people want used since RFC2142-standard values such as abuse@<domain>
seem to be largely ignored. (again, if we could get this fixed, the need
for third party abuse reporting address clearinghouse projects like 
abuse.net, would go way down). If we can improve abuse reporting channels,
we can notify sites that appear to be hosting fastflux nodes.

I think I also probably speak for many people who routinely monitor other 
POC addresses (administrative, technical, routing, peering, billing, 
whatever), that there really should be a *security* or *abuse* point of 
contact wherever there's any of those other channels because all those other 
channels are *sick* *to* *death* when it comes to being bugged by people 
reporting spam, scanning incidents, ssh brute force attacks or other abuse 
to the only contacts they can dredge up for a domain, wrong or not, you 
know? :-;

Something like RIPE's explicit policy on abuse-mailbox: (see
http://www.ripe.net/db/news/abuse-implemented-20050421.html ) would go
a long way to handling that point (although I dislike their approach of
hiding attributes (other than the abuse-mailbox from the default output
and some other aspects of that policy). .

#I'm not fond of the "hi, you're ugly, can I help you with your makeup?" 
#style of marketing ideas and products :-)

Think of it more as, "I can tell you're gasping and having trouble 
breathing, no doubt from allergies or the altitude, can I help get you 
some oxygen or your rescue inhaler, perhaps?" :-)

If I've said anything too bluntly, my apologies, please. All too often
I'm accused of sounding like the former Fed chairman or a career 
diplomat, with an interpreter being required to extract the underlying
nuanced message that *must* exist under all the verbiage somewhere. :-)

Regards,

Joe

Disclaimer: all opinions strictly my own.



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy