If they're properly SWIPed why punish the ISP for networks they don't even operate, that obviously belong to their business customers? And if the granular blocking is effectively shutting down the abuse from that sub-allocated block, didn't the network operator succeed in protecting themselves? Or is the netop looking to the ISP to push back on their customers to clean up their act? Or is the netop trying to teach the ISP a lesson? 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. Frank -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of william(at)elan.net Sent: Saturday, April 07, 2007 5:58 PM To: Fergie Cc: rsk@gsp.org; nanog@merit.edu Subject: Re: Abuse procedures... Reality Checks On Sat, 7 Apr 2007, Fergie wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
- -- Rich Kulawiec <rsk@gsp.org> wrote:
1. There's nothing "indiscriminate" about it.
I often block /24's and larger because I'm holding the *network* operators responsible for what comes out of their operation. If they can't hold the outbound abuse down to a minimum, then I guess I'll have to make up for their negligence on my end. I don't care why it happens -- they should have thought through all this BEFORE plugging themselves in and planned accordingly. ("Never build something you can't control.")
I would have to respectfully disagree with you. When network operators do due diligence and SWIP their sub-allocations, they (the sub-allocations) should be authoritative in regards to things like RBLs.
$.02,
Yes. But the answer is that it also depends how many other cases like this exist from same operator. If they have 16 suballocations in /24 but say 5 of them are spewing, I'd block /24 (or larger) ISP block. The exact % of bad blocks (i.e. when to start blocking ISP) depends on your point of view and history with that ISP but most in fact do held ISPs partially responsible. -- William Leibzon Elan Networks william@elan.net