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

[Tobias Knecht]

>> 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.

This is not a problem of this proposal. This is a problem of the over
all situation at RIRs. We are having the problem of not having dedicated
abuse mailboxes, we are having the problem of data accuracy, we are
having the problem of complicated ways of parsing and finding abuse
contacts.

These are all self made problems.

This is not the last proposal you will see from us, because we want to
change something.

The problem you described would not exist, if RIRs would have mandatory
abuse contacts in their whois, offering these in an easy to use DNS
based service, where everybody could ask for the right contact
information and shutting restricting queries more and more, so only real
messages will be sent to the personal accounts of the abuse desks.

That is exactly the way we want to go down. But we should start
somewhere. And the problem that generates most pain at RIR members are
the not existing abuse contact objects at the moment.

The problem you described is absolutely real, but it is already today
and not a problem of this proposal. So let talk about a dedicated abuse
contact object and talk later about the other problem.


>> 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?

This would work. Absolutely.
If this is the solution AfriNIC members can live with, fine. I would
suggest adding the abuse mailbox field and the RIPE equivalent "whois
-b" option for short data output and unrestricted query access.

Restrict abuse-c to one object. Instead we are running in the same
problem than RIPE a few years ago.

I would also like to see that the abuse-mailbox attribute is just shown
if the object is linked to the abuse-c, because if not, you will have 3
different admin-c, tech-c and abuse-c objects with 3 different abuse
contacts. And that will end up in the same problem RIPE has today.


>> 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.

Nope sorry, that was not the way I wanted to say.
15 million trap hits per month coming from 10 million unique IP
addresses per month. We see 10 million different IP addresses every
month. Which is not the same as infected systems, because over an month
they switch addresses.

We are hashing this and we are offering our cache system to others to
give them more easy access to these abuse contact information, because
we know it is not that easy to get all the needed information out of
whois that quickly.

The problem is, that at the moment there is no easy way to query
different whois servers and get the right answer, so everybody is doing
it a little bit different and that is the problem.

There is the need to have a standardized way of searching and finding
the right information.

That is another point that is pointing to the IRT Object. ;-)


>> 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.

As mentioned above. Mandatory abuse contact : DNS based abuse contact DB
: setting up a local DNS cache : all good.

That would make things easy and stops thousands of different ways to do it.

>> 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.

Absolutely right. But why penetrate the whois server if there would be
another alternative?

>>>> 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.

DNS Based list for everybody?


Thanks,

Tobias


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20100616/ce3c36bf/attachment.sig>