Abuse Contacts in the RIR’s WHOIS - Solved?

The idea of informing network owners’ abuse departments about malicious incidents is not new, but still a very effective and the most inexpensive way of letting people in charge know that there is something wrong in their own network (http://www.ietf.org/rfc/rfc2142.txt). Actually, it is one of the best methods to help enforce security on the Internet in a self-regulating way. The industry has propagated data sharing and global reporting of spam and other network incidents for years, yet has often been struggling due to the inability of finding the responsible points of contact in the RIR’s (Regional Internet Registry’s) WHOIS.

For example, the automatic and manual discovery of an abuse contact for a RIPE registered number resource is not really an easy task these days. The logic you need to parse through all the related WHOIS objects is sometimes more than inconvenient. There are too many possible places where an abuse contact can be published. It can be an IRT Object (Incident Response Team) or maybe an abuse-mailbox attribute in an IRT Object, or in any other object or even in a remark field in any given object. Since one resource can have more than one object, it happens that you get more than one answer and have to decide which one is the right one. It gets even worse when you find remarks like this:

Briefly, it means that every aut-num, inetnum and inet6num object must have a mandatory abuse-c object. This can be directly attached or can be inherited due to the hierarchical nature of the WHOIS Database. In addition, every abuse-c object must have an abuse-mailbox attribute, which is intended to receive automatic reports.

RIPE NCC (Network Coordination Centre) will come up with an implementation strategy within the next few weeks and will hopefully start implementation processes very soon. This is a big step in the right direction, but is most likely not the last change the RIPE Anti-Abuse Working Group will bring on its way. There are several points the RIPE Community has asked for, such as processes to guarantee data accuracy and clean up of existing data.

Theses policy proposals show there is a huge amount of opportunities for service providers to engage in the network operators’ community (and the other way around) that should definitively be backed.