On May 14, 2007, at 2:43 AM, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:

...

I do hope that when the UK police get tired of waiting, that they shut down everything in BT's data centre and take it all as evidence. BT deserves at least that, and frankly a whole lot more.

I've already replied privately to Jo offering my help to escalate this internally at BT to the right person. But I would like to point out that BT does not have "a" data centre that can be shut down. BT is a very large network operator with probably hundreds of data centres worldwide.

I knew that. I meant the bt broadband data centre which keeps the log data for user sessions. And anyway, I didn't expect it either. It's an ISP horror story that has happened only a few times. I was simply expressing frustration in saying that BT deserved it.

We also operate multiple IP networks and have many different lines of business. The problem appears to be with the UK consumer Internet line of business. Even though I have nothing to do with that particular group, I will still escalate this issue to make sure that the right people know about it.

Thank you.

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

I used Nanog only as a stop-gap because no other lines were working. Checking my nanog sent file, I've done with 7 times over 10 years, so I think I can say that I don't abuse this approach ;-) The RIR data only pointed to abuse@btbroadband.com, and that was getting me nowhere. Their responses to the customer were less than useful. They weren't responding to my requests for escalation at all. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550

...

...

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

Jo Rhett wrote:

Oh, yes. Because BCPs are so very good at solving problems. I wanna go live in your happy universe. Because if BCP 38 were attended to more than 40% of my job would be irrelevant, and 12-15% of our traffic load would be reduced. ...one of the only colocation providers who does implement BCP 38.

Is the alternative just to sit around, be sarcastic, and do nothing? If someone has enthusiasm to write documents and provide advice that is available to the community this is a Good Thing; they shouldn't be discouraged from it. It is enormously helpful to have a document to point people at - most ignorance is just that rather than wilful malfeasance.