While NANOG is a nice stopgap for getting to the right people, it seems to me that we should, collectively, come up with a better system for doing this. If only the RIR databases were verified so that all contacts listed were reading, willing and able to act on abuse issues...
[..]
The RIR data only pointed to abuse@btbroadband.com, and that was getting me nowhere. [..]
RIR data is 'too open' for real contacts to be found. Like spam can cause abuse@ addresses to become useless, the information in the RIR data mostly also get overspammed and thus often are not properly read.
Thus your other option as a Network administrator becomes to look up
Today, RIRs only give you email contacts for the abuse desk. This is part of the problem. Most companies operate some sort of internal departmentalization for abuse issues and the RFC 2142 mailbox names are no longer sufficient. It would be better if the RIR database had a set of URLs which led to information about reporting various issues. At a minimum, email issues and network issues should be separated. Most large network operators do have a set of web pages where they explain their AUP, peering policies, email filtering systems, and so on. But there is no standard for finding these and they are not listed in RIR databases unless someone puts them in the comments field. We could do a lot better. I know that the MAAWG is doing some work on defining best practices in this area, in fact our head of Internet Customer Security is presenting at the Dublin meeting. But, I believe that we also need more documented best practices in the area of general network abuse reporting processes. Often, when network abuse crosses borders and there is a crime involved, the ISPs find themselves stuck in the middle in an awkward way. The customer who is the victim of the crime reports to local police, but the local police often don't know how to deal with getting information from the ISP in the foreign country, and have no prior police contacts there. Legal matters are always rather touchy as you will know if you have followed the CALEA thread. ISPs always have to act lawfully and cannot act as an arm of the police or they may themselves be the target of court actions. However, it should be possible for the ISPs to facilitate police-to-police communications. In previous jobs I have been involved in doing that. In one case, I provided a local police email address to a foreign ISP so that they could give that to their own police. In another case, I asked a foreign ISP to provide an email contact for their local police force so that a customer could include this in his crime report to the local police. It seems to me that this is something that all ISPs could provide quite openly on their websites in the same way we provide Investor Relations and Media contacts. After all, if we receive a report that a customer has committed a crime, there is not much that we can do about it directly. But if we would publish our local police contact address along with instructions about reporting crimes to police in the victim's jurisdiction, then hopefully, we would get fewer such reports because they would all go directly to the police. But how do we sort out these abuse reporting issues? How do we write the best practices document? Is NANOG the right place? ARIN/RIPE? the
contact data in the Peering Database: https://www.peeringdb.com
Assuming that you know the peering database exists. And why is that info not in the RIR's own database? Why is it scattered?
For BT this lists a NOC email address, and a direct person for Technical and Policy decisions, which has an email and phone contact for your perusal. Not directly the right person, but it at least brings you somewhat in the right direction.
I'll see if we can get the abuse address added to that. We have recently centralised responsibility for all abuse reporting across all countries, markets, lines of business. We also have installed a system using StreamShield to proactively identify and report spam sources on our network so that we can deal with them faster than by waiting for 3rd party reports.
Next to that, of course never hesitate to setup an INOC-DBA account and hook yourself up there. That brings your complaint only a simple asn-dail away ;)
I'm going to pass along that suggestion internally. However, once again, I wonder why INOC-DBA is not better known. Why don't we have an ISP best practices document published as an RFC to update RFC 2142 and include more than just email. It's been 10 years now and 2142 is old in the tooth. If anyone wants to send me suggestions for content for a best practices document, I'm willing to put something together. --Michael Dillon