[anti-abuse-wg] 2010-09 New Policy Proposal (Frequent Update Request)

In the ARIN region we attempted to safe guard against the list being
missued, by making the data available only to entities who have
qualified to obtain bulk whois data from ARIN.  In order to obtain
bulk whois data, you must sign an agreement with ARIN and meet certain
qualifications:

https://www.arin.net/resources/services/poc_validation_readme.html

Ideally, the data would be used for good and not evil -- that service
providers would check against the list before permitting a prefix to
be announced.

--Heather

On Wed, Nov 10, 2010 at 8:18 AM, Shane Kerr <shane at time-travellers.org> wrote:
> Hello,
>
> I recall when ARIN was discussing automatically marking non-responsive
> contacts in their database, a concern did come up. The concern was that
> address hijackers would have an excellent pre-filtered list of networks
> that are likely to be poorly maintained.
>
> A spammer could:
>
>     1. Download the latest list of non-responsive object owners.
>     2. Download the latest list of inetnum in the RIPE Database.
>     3. Extract out the network ranges with non-responsive object
>        owners.
>     4. Find those network ranges that also happen to be missing from
>        BGP.
>     5. Advertise those ranges.
>     6. Send spam from those ranges.
>     7. Profit!
>
> Since the spammer knows that the mail for these ranges don't work, she
> can be pretty sure that it will take a while for the good guys to figure
> out what is going on. By that time she's sipping cocktails on the beach.
>
> I am not opposed to having regular checks of contact information. I am
> not even opposed to providing a public view of the "quality" of contact
> information, as proposed in 2010-09.
>
> However, perhaps a better way forward would be to make this something
> handled in the context of the RIPE NCC/LIR relationship.
>
> Keeping in mind that these are people who have been contacted via the
> LIR Portal and e-mail, they need to be encouraged to care a bit. There
> are several ways this could be done:
>
>      * Changing the contact information on the maintainers to the
>        contact for the LIR, along with an appropriate message
>        explaining it (I think the LIR contact information is corrected
>        at least often enough to send an annual invoice)
>      * Require checking of maintainer information before receiving
>        future RIPE NCC registration services (this will probably be
>        less important post-IPv4 runout... what services do I need after
>        I get my IPv6 /32 block!?!)
>      * Adding a penalty in the annual membership fees if maintainer
>        information is not confirmed (I suppose this could be named a
>        "Good Quality Discount" instead, but that amounts to the same
>        thing)
>      * Revoking the resources from the LIR
>
> The problem here, as always, is that LIRs set the policies, and I think
> they are unlikely to approve a policy that can be used against them. I
> doubt the RIPE NCC actually wants to enforce this kind of stuff either!
>
> --
> Shane
>
>