Abuse procedures... Reality Checks

Rich Kulawiec rsk at gsp.org
Fri Apr 13 11:53:41 UTC 2007


On Sat, Apr 07, 2007 at 05:12:19PM -0500, Frank Bulk wrote:
> If they're properly SWIPed why punish the ISP for networks they don't even

"punish"?

Since when is it "punishment" to refuse to extend a privilege that's been
repeatedly and systematically abused?  (You have of course, absolutely
no right whatsoever to expect any services of any kind from anyone other
than those you've contracted for.  Everything beyond that is a privilege,
generously furnished to you at the whim of those operating the service.
It may be restricted or withdrawn at any time, for any reason, with or
without notice to you.   Now as a general rule, we all have chosen to
furnish those services -- by default and without limitation.  But that
doesn't turn them into entitlements.)

The word "punish" is completely inapplicable in this context.

> operate, that obviously belong to their business customers? 

Questions:

	1. Is your name on it in any way, shape or form?
	   (This includes allocations.)
	2. Is it emitting abuse?

If the answers are "yes", then it's YOUR abuse.  Trying to evade
responsibility by claiming that "it's one of our customers" is
just another pathetic excuse for incompetence.
 
> Of course, it doesn't hurt to copy the ISP or AS owner for abuse issues from
> a sub-allocated block -- you would hope that ISPs and AS owners would want
> to have clean customers.  

Unless of course the ISP or AS owner *are* the abuser under another
name, or unless they're actively complicit.  Both are quite common.

Beyond that: any *competent* ISP or AS owner will already know about
the abuse.  They will have deployed measures designed to detect said
abuse well before anyone else out there reports it to them.  (Example:
setting up their own spamtraps explicitly designed to catch their own
customers.)  By the time an external observer reports a problem to them, it
should already be old news and already be well on its way to remediation.

---Rsk




More information about the NANOG mailing list