[arin-ppml] IPv4 SWIP requirements (?)

[Ronald F. Guilmette]

In message <1f134479-998d-30d1-2b59-5ec7eb887f30 at linuxmagic.com>, 
Michael Peddemors <michael at linuxmagic.com> wrote:

>Of course, we are supposed to 'report it to hostmaster', but after many 
>such reports, and seeing no effect, it makes it hard to bother with 
>reporting it..

Yes.  Statistically speaking, it has appeared to me that approximately
98 times out of a hundred, any report regarding either an utterly non-
functioning rwhois server and/or big swaths of spammer-infested IPv4
space where the IP blocks are clearly and provably "live" (and spewing
spam) and where the relevant rwhois server simply returns -no- information,
such reports are greeted with abject silence and no change to anything
whatsoever, even when allowed to percolate for a week or more.

And indeed, the problem is getting worse.  The latest, biggest, and most
disappointing such failure is for the entirity of 38.0.0.0/8 aka
rwhois://rwhois.cogentco.com:4321 which appears to have been recently
emptied of -all- information, with the exception of a single common
one-line greeting banner.

But that is just one example.  If pressed, I'm quite sure that I could
cite innumerable others in short order.  I come across these broken
(or deliberately disabled) rwhois servers every day now, and often
multiple times each day.

(Sometimes, I can't help but think to myself that the relevant providers
might just as well hang big signs around their necks saying "Yes, we know
that we are harboring snowshoe spammers, but they are paying us not to let
on to anyone who they are.")

>We see daily bad SWIP entries, entries pointing to bad or non 
>functioning 'rwhois' servers, and without the 'stick', that is unlikely 
>to change.

Quite so.

>Maybe an independent movement to 'blackhole' IP space with bad SWIP 
>practices?? (not entirely kidding)

It isn't always done with malice, and is, in my opinion, just as often 
done out of carelessness, laziness, or a simple failure, on the part of
the lowest-level operational worker bees to understand or even be aware
of the ARIN requirements.

Over time, at a lot of these places, management changes, ownership changes,
and worker bees come and go or are swapped out for newer ones, and the
internal company memo about the ARIN requirements gets lost in the shuffle
and ends up in the dumpster out back.  There are never any downside
consequences, and thus, the overworked and underpaid worker bees focus
their daily efforts on keeping the network running and all of the customer
machines up, just as we all would, if placed in similar positions.

I might be tempted to suggest that perhaps John C. and his team might
possibly be able to render some useful service with respect to this
large and growing problem, via something that would fall well short of
any kind of formal "enforcement" action... e.g. just sending a polite/
friendly email to the relevant provider in each case, asking them to
please consider turning their rwhois servers back on... but I'm afraid
that there would likely be resistance, both in the community and from
ARIN itself, to having ARIN do even that sort of minimalist thing,
because ARIN has not been explicitly tasked to do it, formally or
otherwise, by the community.

On the other hand, if ARIN -were- ever so tasked, they wouldn't need to
go out searching for providers with broken or non-functioning rwhois
servers, as I could, and would, gladly, email them a daily stream of
reports of exactly such providers.

(Remarkable as it may seem to some, real-world experience indicates that
there is a dramaticaally high degree of intersection/overlap between the
set of providers that, on any given day, can be shown to be hosting
snowshoe spammers, and the set of providers that, on that same day,
are demonstratably failing to run a functioning or useful rwhois server
or to use WHOIS/SWIPs to properly document their sub-allocations.  I know
what you're thinking... "Gee!  Who woulda thunk it?"... Right? :-)


Regards,
rfg