RIPE 59

RIPE 59 Meeting Lisbon
Anti-Abuse Working Group
Thursday, 8 October 2009, 16:00

Chair: Brian Nisbet
Scribe: Pedro Vaz, RIPE NCC
Jabber: Gerardo Viviers, RIPE NCC

A. Administrative Matters
The Working Group (WG) Chair, Brian Nisbet, welcomed the attendees and explained that the WG Co-Chair, Richard Cox, was unable to attend. He announced an extra presentation that was not included in the initial agenda: "Phishing Lock". Ian Meikle, Nominet presented

The minutes from RIPE 58 were approved without any comments.

B2. Recent List Discussion - Abuse contacts, Sanctions etc.

Brian asked if there was someone in the audience who had any opinion about about methods of contacting ISPs about abuse and if the audience could contribute any suggestions on how to handle it.

Marco Hogewoning (xs4all) mentioned that there has been an increase in people trying to contact, for example, admin contacts in the organisation attribute in the Database. He added that it all comes down to educating people. He suggested that tutorials on how to use the RIPE Database to get to the correct contacts are created. They could be made available on RIPE Labs. He also added that there seemed to have been better common sense but this has been slipping away lately.

Pavel Kácha (CESNET) said that he sees this from both sides. He stands on the side that generates the email and that side that reaches the abuse box. He pointed out a problem that they often run into, which is that the contact mailboxes are often not valid so they have to escalate and use other means.

Brian asked Pavel what his default action was.

Pavel replied that it is to use the right box.

Brian asked on what level checking can be done on the validity of anti-abuse contacts in the database and what kind of sanctions could be applied if these are not valid.

Marco said that these kind of checks were very difficult to perform, took a lot of work and might not even be valid. This is the same with the sanctions to be applied.

Wilfred Woeber (Vienna University) said that he saw a couple of developments. He mentioned that it's now fashionable to install automatic tools which perform intrusion detection. An individual complaint is created every time a new case is verified. The problem is that this could be become another sort of spam and could even be used as a way to perform a 'denial of service' attack, if you get it from many sources at the same time.

Wilfred added that some parties claim that the right way to go is to retrieve the responsible party for some resources up the tree, and then send them an individual notification. He said however, that his own experience tells him that no one really sees this as the way to go. He asked the community if anyone agrees that this is the right method.

Lance Wright (Chocolate Redhead) stated that people spam because they make money with it. He mentioned that he worked with a number of companies that use a community-based system, where if someone marks a piece of spam, then everyone else in the community will know it. This makes it possible to detect spam and send it back to where it came from. It deals with spam on the financial level and ends up demotivating spammers and this will end up leaving the community members alone. He added that in the UK this community consists of about 150,000-170,000 users.

Marco asked how the system knows where the mails are sent from because normally these emails use fake envelopes.

Lance answered that it is proprietary information but that that if Marco would sign a Non-Disclosure Agreement he would be glad to discuss it offline.

Brian agreed with Marco on the point that he doesn't know of any way to test if an abuse contact is valid or not.

He posed the question of whether it is appropriate for people to search for admin or billing contacts if the abuse contact is not valid. And, if people, by default, already consider the abuse contact less likely to be valid they go immediately in search of admin or billing contacts.

Lance said that it depended on the spam. If the spammer is a company trying to sell you something, you'd go back to them. The one offering the technology won't take any responsibility.

Marco acknowledged that more or less everybody in the room kind of like behaves himself and looks for abuse contacts, and only when these are not valid, does he go to the admin contacts. However he said that these complaints also become a form of spam and might end up being filtered. He put the question to the audience: where would someone go next if everyone just starts filtering admin contacts?

Brian asked if anyone thought that the right way to go is to get to the highest point of registration and handle things there, or contact the most accurate object, which was what's right in his opinion.

Marco said that maybe this question should be asked in the plenary when there is a bigger audience.

Brian posed a new question for people who operate an abuse desk: would they prefer a complaint email per incident would they would rather receive single emails, single points.

Pavel replied absolutely not.

Brian thought that individual emails would be preferable.

Pavel said that he would prefer a method where complaints are aggregated in some way. He pointed out the fact that if a complaint was generated for each and every spam, then by definition, you would be generating spam as well. He added that this creates collateral damage.

Brian thanked the WG for the comments.

B3. Dutch ISPs Antibotnet Action
Marco Hogewoning, XS4ALL
http://www.ripe.net/ripe/meetings/ripe-59/presentations/hogewoning-ISP-botnet-nl.pdf

There were no questions.

B4. Phishing Lock
Ian Meikle, Nominet
http://www.ripe.net/ripe/meetings/ripe-59/presentations/meikle-phishing-lock.pdf

There were no questions.

C. Technical Measures
C1. RIPE NCC Tools for Anti-Abuse
Emile Aben, RIPE NCC
http://www.ripe.net/ripe/meetings/ripe-59/presentations/aben-rex.pdf

Shane Kerr (ISC) asked if anyone had approached him with concerns that this information is published in such an easy to get format would make them look bad. For example, someone with a network with lots of blacklisted entries.

Emile answered no and added that this all publicly available information anyways.

Shane said that this was like saying that DNS is public so he could do everything he wants with it, which is not strictly true. He added that he could discuss this offline afterwards.

Brian said that if people did not like, it would just be a pity for them.

Shane agreed but added that if he would have been an LIR with bad information published about it, he would have been annoyed. He said however, that he's glad that this is being done and that he was just asking if these issues have come up.

Emile said that this is why it's on RIPE Labs. It's a prototype and not a production service. If serious issues arise it could be removed from the site.

Brian said that it's a nice tool to get historical information from net blocks.

D. Interactions

D1. Working Groups

Database Working Group: irt objects.

No comments have been made, so this point was closed

D2. Law Enforcement Interaction

Brian brought up the topic of registry closures. He asked the attendees if it was clear what the RIPE NCC can and cannot do regarding root resources at the moment.

There were no comments from the audience.

He also asked if it was clear enough that if the community thought that the RIPE NCC should be able do something about this, it would have to be raised at policy level. He said that the Anti Abuse Working Group would be the most likely place for this to be done.

There were no comments from the audience.

Brian mentioned a set of meetings and talks with people from governments and law enforcement agencies where it's explained to them how the RIPE community and the RIPE NCC operate, and how they can be involved in the process. He asked the audience if there was anything that they thought could be brought to these meetings.

There were no comments from the audience.

E. Documents

E1. BCP Documentation - IRT object/abuse contact recommendations

Brian said that this is not finished yet but it will be completed.

X. A.O.B.

There was no other business.

Z. Agenda for RIPE 61 - Plenary Presentations

Brian thanked the attendees and closed the Working Group session at 17:15.