[AfriNIC-rpd] abuse contact information in whois database (AFPUB-2010-GEN-002)

[Owen DeLong]

> Another request by members was that there should be the possibility to
> add some kind of object that contains 2 email addresses. One for
> personal interaction and one for automatic abuse reports. My idea was to
> ask for a abuse-mailbox attribute within the IRT Object. So that would
> fix that request.
> 
In ARIN, you can have zero or more abuse-c contacts per object.
I don't see why that couldn't work here.

Frankly, however, I don't think that will work as well as some people hope
because I have limited faith in the automated reporting systems following
the requested convention. Someone will think that the personal response
box is more responsive than the automatic reporting box and decide that
their need for response to automated reports outweighs the providers
need to sort things into different boxes. Others will simply report to both.

> How would you do that with already existing objects? Lets think about
> the abuse-mailbox attribute which can be part of every person or role
> object. What I do not want to happen that there will be more than one
> objects having an abuse-mailbox attribute. That would start the same
> trouble we have a RIPE at the moment, that there are 15 possibilities to
> put an abuse@ address and in some queries you find 10 of them with
> different addresses.
> 
Yep.  At ARIN, abuse-c is a field in an ORG object which can either be
inherited by all child objects, or, over-ridden by an abuse-c field in
a child NETWORK or ASN object. You can have zero or more abuse-c
fields in each such object. Each abuse-c field contains a handle for
a CONTACT object.

A CONTACT object is either a person or a role account.

> So would it be able to create a special role object that has a mandatory
> abuse-mailbox attribute, what I think makes sense, that can only be
> linked to an abuse-c?
> 
Why would it need to be a special role object? Why not just use the
generic CONTACT object that already exists and link to it the same
way that admin-c or tech-c links to it.

For example, say you have CONTACT objects as follows:

OD19-ARIN		Person
ABXX-ARIN		Role

Then, an ORG object, for example, could have the following
attributes:

tech-c: OD19-ARIN
admin-c: OD19-ARIN
abuse-c: ABXX-ARIN

Or, I could have ABXX-ARIN in all three fields, or, OD19-ARIN, or
any other combination. If I wanted, I could create yet another
CONTACT object for any of the fields.  Simple, easy to understand,
and pretty flexible, no?

> Or what would be another idea to handle these requests.
> 
>>>> If you need to query more than 250 abuse-c contacts per day from a given RIR,
>>>> I would argue that you are probably doing something other than legitimate abuse
>>>> reporting. As such, I do not see the whois query rate restrictions as a significant
>>>> barrier.
>>> 
>>> Wrong. Our spamtrap network receives around 15 million spam messages a
>>> day and that is just because we do not want to spend more money to
>>> receive more. That is all over round about 48.000 different AS Numbers
>>> world wide just in May 2010. 10% of the AS Numbers are based in the US.
>>> 
>> If your spam trap network is concentrating all of those messages into a single
>> location to do the queries against whois, then, you should either be using the
>> bulk whois policy to keep your own local copy of the data, or, you should be
>> optimizing your system so that it doesn't have to query the same source from
>> whois multiple times at the very least. 15 million messages probably didn't
>> come from 15 million different places.
> 
> The bulk whois is not available at LACNIC, AfriNIC, APNIC (JPNIC, KRNIC,
> ...) and will be stopped due legal issues at RIPE pretty soon.
> 
> We are working with caches, what works pretty good now, but not
> everybody wants to invest lots of hours in doing so if he just wants to
> reports a decent number of reports.
> 
> 15 million messages come from around 10 million uniq IP addresses.
> 
You're telling me that there are 10 million NEW spam source addresses
every day? I find that fairly hard to believe. Even so, I bet those 10 million
IP addresses don't represent 10 million unique NETWORK objects.
I don't think it takes lots of hours to store what you already retrieved
from whois in a hash with a time-stamp. The code for doing this is
well known and I suspect there are open source tools already available
that do so.

> But I think we can go down another road with issue. If we can not find
> consensus on the IRT Object and are not able to stop the query
> restrictions, I would propose to start a service like this:
> http://labs.ripe.net/content/updated-heuristics-abuse-finder-service
> 
That seems fairly reasonable and I suspect would be relatively trivial
to implement.

> That would probably be more easy than it is at RIPE, because if there is
> only one object containing the abuse contact information it should be
> really easy to get this done.
> 
You might have to still look at the NETWORK or ASN object and the parent
ORG object, if the child object doesn't contain an abuse-c, but, you should
never need more than two queries to build your list of contacts for a given
address range. After that, it's just a matter of querying the applicable
CONTACT objects.

>>> So in my opinion there is a need of unrestricted query access.
>>> 
>> We can, perhaps, agree to disagree on this. To me, it sounds like a problem
>> of application optimization which I would argue should not be used to place
>> additional undue burden on the RIR whois services.
> 
> Okay lets agree on that. ;-)
> 
Fair enough. Increasing the query rate limits or placing finer granularity
on them, btw, is not necessarily a bad idea in my opinion. Allowing you
to sign up an address for a higher query rate service with a signed
contract containing an AUP specifying you won't be harvesting the
data for unapproved purposes would also be a reasonable alternative.

Owen