>> 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.
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?
Thus your other option as a Network administrator becomes to look up
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