[anti-abuse-wg] RIPE 68 Minutes for the Anti-Abuse Working Group Session

I might add that ARIN, ICANN and the IETF regularly attend M3AAWG meetings.

In fact ISOC and ICANN are M3AAWG members in their own right.

And I believe ARIN has a regular presence at MAAWG as well

It would be trivial to have RIPE NCC attend M3AAWG meetings - the
suggestion that they email Jerry Upton and ask for guest passes is
correct.

--srs

On Fri, Sep 12, 2014 at 3:54 PM, Brian Nisbet <brian.nisbet at heanet.ie> wrote:
> Colleagues,
>
> Here are the draft minutes from the RIPE68 AA-WG meeting in Warsaw. It would
> be great if people could review these and note any issues and/or action
> points prior to our meeting in London.
>
> As a reminder, there is still space on the agenda for the London meeting.
>
> Thanks,
>
> Brian
>
> *****************
>
> Anti-Abuse Working Group Minutes – RIPE 68
>
> ===
> A. Administrative Matters
> ===
>
> Brian welcomed the participants to the Working Group session and introduced
> himself and Tobias as co-chairs. and thanked the RIPE NCC for providing
> support in the form of chat monitor, scribe and stenographers.
>
> The minutes from RIPE 67 and RIPE 66 were approved and there were no
> additions to the agenda.
>
> ===
> B. Update
> ===
>
> Brian asked the room if there was anything pertaining "abuse-c:" that needed
> to be raised. As nobody spoke up, Brian stated that it could be covered
> later on if needed.
>
> Brian mentioned that he had circulated some text for the working group
> charter. He noted that there had been some discussion but was happy to keep
> any discussion on the list. He invited the room to make any comments there
> and then if needed.
>
> There were no comments.
>
> Brian urged the participants to read the charter on the mailing list.
>
> ===
> C. Policies
> ===
>
> Brian stated that there were no open policies at the moment.
>
> ===
> D1. Interactions With Other Working Groups
> ===
>
> Regarding interactions with other working groups on policy, Brian noted that
> he and Tobias had agreed with Nigel Titley and Wilfried Wober, the Database
> Working Group Chairs, that he and Tobias would work on the data verification
> policy. He mentioned that he and Tobias would not have time for this soon,
> and therefore urged participants that, should they want to take on the task,
> they were welcome.
>
> ===
> D2. Proof of identity discussions – RIPE Policy Proposal 2007-01
> ===
>
> There was some discussion about the level of proof of identity that the RIPE
> NCC should expect.
>
> Athina Fragkouli, RIPE NCC, stated that this was also discussed in the
> Address Policy Working Group and there were not many concerns about how the
> RIPE NCC handles proof of identity. She added that the RIPE NCC is always
> open to changing procedures.
>
> Brian asked the room whether the RIPE NCC are doing enough, too little, or
> to much regarding proof of identity. He asked if there should be more trust.
>
> Jim Reid, unaffiliated, felt that things should be left as they are. He
> expressed that he thought it was bad to collect personal data unless there
> is a strong need for the data. However, he can appreciate the RIPE NCC's
> point and can see how it's useful in some cases, such as for law enforcement
> and other aspects of anti-abuse.
>
> Brian agreed that it's okay for the RIPE NCC to continue as it is.
>
> ===
> E1. "Anti-Abuse: The View from the Messaging World" - Jerome Cudelou, M3AAWG
> ===
>
> The presentation is available online:
> https://ripe68.ripe.net/presentations/373-M3AAWG.pdf
>
> Brian asked whether there are any more areas of mutual engagement that could
> be touched upon.
>
> Jerome responded that it would be best to become members of M3AAWG.
>
> Brian asked whether non-members of M3AAWG could contribute to M3AAWG’s
> documentation.
>
> Jerome responded that he didn’t think it was easy to do and that it is
> better to become a member.
>
> Rüdiger Volk, Deutsche Telekom, asked if there were documents that would
> explain what is expected of an abuse contact.
>
> Jerome responded that the document is under discussion.
>
> Vincent Schonau, abuseix and co-chair of the Training Committee at M3AAWG,
> further clarified that there is the Abuse Desk Best Practises document that
> is now a few years old.  He added that the Abuse Desk Special Interest Group
> has revived the document and would work on it in upcoming meetings.
>
> Alex de Joode, LeaseWeb, stated that LeaseWeb is not a member of M3AAWG but
> are participating in the Hosting Special Interest Group (SIG) and the Abuse
> SIG so participation is possible without becoming a member.
>
> Brian asked Alex what the procedure was for participation.
>
> Alex responded that he had sent a message to Gerry Upton and received a free
> invitation.
>
> Samaneh Tajalizadehkhoob, Delft University of Technology, asked if M3AAWG
> cooperate with research institutions. She mentioned that Delft University of
> Technology are working on banking malware and mobile malware, and asked if
> M3AAWG share data with them.
>
> Jerome responded that they do share data with research institutions.
>
> Vincent noted that M3AAWG has a very open policy about inviting people to
> come to the European meetings and the emerging groups such as the Hosting
> SIG. He directed interested parties to Gerry, Jerome or himself for an
> invitation.
>
> Brian asked an open question to RIPE NCC members in the room whether there
> had been any interaction with M3AAWG since RIPE 45 in Barcelona.
>
> Jochem de Ruig, RIPE NCC, responded that the RIPE NCC would try to come to
> Brussels and that the RIPE NCC did find the meeting useful for engagement
> with the community.
>
> ====
> E2: Impact of abuse-c
> Bengt Gördén, Resilans
>
> The presentation is available online:
> https://ripe68.ripe.net/presentations/383-impact_abuse-c.pdf
>
> Ruediger asked whether the message to the abuse-c at Spamhaus was
> successful.
>
> Bengt replied that it was not, and asked if there were questions about that.
>
> Ruediger continued, adding that Spamhaus is bullying people on the Internet
> and that a joke he had heard is that it may be possible to send a claim of
> copyright or trademark infringement with the name Spamhaus and send it to
> .org.
>
> Bengt added that it would work.
>
> Ruediger added that the Internet community needs to make sure that things
> are balanced out, thanking Bengt for his presentation.
>
> Erik Bais, ATB Internet, added that they had been in the same situation with
> Spamhaus and it had been well-documented.
>
> Bengt responded that he had read about it.
>
> Erik continued that they had disclosed fully about their interactions with
> Spamhaus, who had behaved brazenly in return, finding the situation amusing
> and even blogging about it on their website. Erik added that Spamhaus do not
> care and that they have been invited to the RIPE Anti-Abuse Working Group
> sessions, to have a panel and discuss the proper policies, but had refused
> the invitation.
>
> Brian added that that the relations between the Working Group and Spamhaus
> were not as good as they would like, and redirected the discussion back to
> “abuse-c:”.
>
> Erik stated that they transferred some of their address blocks and even
> after six months they still receive emails to their abuse mailbox regarding
> blocks that they don’t own anymore. He called for people to use the RIPE
> Database and asked how it is possible to make people update their
> information.
>
> Bengt replied that he feels the community needs to work on this issue
> collectively, but not necessarily in a way that results in any legislation
> or policy.
>
> Erik added that it’s good to remember that Spamhaus does not block mail and
> there is always a need for well-managed block lists.
>
> Peter Koch, DENIC, asked Bengt about his slides as they seemed somewhat
> contradictory to him, as they looked more like a “suffering story” rather
> than a success story and he did not understand why it was being used as an
> example, as Bengt’s “I told you so.”
>
> Bengt responded that maybe it is time that they give up on optimising the
> “abuse-c:” for an audience that cannot be educated.
>
> Brian invited Tobias Knecht, his fellow chair of the Anti-Abuse Working
> Group to comment on similar policies in other regions.
>
> Tobias stated that the policy about “abuse-c:” was brought into APNIC in a
> different way, as well as at AFRINIC. While the implementations were
> different, the end result was the same - that there is an abuse contact in
> the Whois Database, a single space.
>
> Bengt noted that he had tried to get an abuse contact for Spamhaus and it
> hadn’t worked.
>
> Alex Le Heux, Kobo Inc, added that they had similar experiences with many of
> those blacklists. He stated that Spamhaus regularly attends M3AAWG and
> advised those who wanted to meet with them, to go to the Brussels meeting.
> He invited those with similar experiences to come to the meeting so that
> some sort of best practises for blacklists can be set up.
>
> Brian confirmed that a best practises document that has come out of M3AAWG
> already exists.
>
> ===
> E3: Abuse-c: Next Steps for “abuse-c:”
> Denis Walker and Christian Teuschel, RIPE NCC
> ===
>
> The presentation is available online:
> https://ripe68.ripe.net/presentations/162-aa_wg.pdf
>
> Brian noted that time was running short, and some discussion may need to be
> directed to the mailing list.
>
> Ruediger asked if it was explained anywhere how ORGANISATION objects should
> be used.
>
> Denis responded that it was one of the big problems with the RIPE Database.
>
> Ruediger noted that there is no documentation and explanation of the data
> model that the RIPE NCC says that the community should be following.
>
> Denis replied, saying that no business rules were built into the software to
> enforce any of this, and agreeing that there are no guidelines.
>
> Ruediger argued that, if there is a data architecture that should be
> followed, it should be documented and agreed upon. He called for a document
> that explains what the architecture is.
>
> Brian asked whether this discussion would be something better suited to the
> Database Working Group.
>
> Peter thanked Denis and Christian for their hard work. He noted that the
> RIPE Policy Development Process allows early and often objections and he
> believes that they are at risk of going completely overboard in a variety of
> aspects. He stated that he thinks that the model is in the wrong direction,
> and he is opposed to “salami tactics”. His interpretation of one of the
> slides is that there is an ORG object and the addresses hang off it, and he
> cannot find any document that describes it that way. The database model with
> which he is familiar is one built around the objects you ask for, and the
> information attached to the objects, in other objects. He called for changes
> to the model. He added that if this were moved to the Database Working
> Group, that would only partly help as the changes proposed from the
> Anti-Abuse Working Group may not be compatible with the Database Working
> Group point of view.
>
> Brian clarified that, if there were issues with the architecture and
> business rules and documentation, then it would be more appropriate for the
> Database Working Group to work with the RIPE NCC to get that written.
>
> Peter stated that it may be time to reconfirm the mission of the RIPE
> Database, adding that it should not become a “compliance stick” for Local
> Internet Registries or resource holders.
>
> Christian asked Peter what he had meant by “salami tactic” regarding the
> validation.
>
> Peter clarified that having a mailbox does not mean that mail is delivered
> or read. The next slice of salami is to validate, so that mail can be
> expected to be deliverable. He envisioned that, three  months later, it
> won’t only be deliverable, but there would be a reply.
>
> Christian replied that this is what they had proposed, improving the data
> quality.
>
> Peter added that caution would need to be taken when regarding data quality
> as it is a topic for the admin-c and the resource holder. He believes that
> the data should be correct because that is the core mission.
>
> Via remote participation, Gilles Massen asked if, as the existing IRT
> objects are becoming more invisible, would it be possible to reference an
> IRT from the “abuse-c:” or at least add the useful IRT features like BGP
> keys to the “abuse-c:”. He stated that he would like to see relaxed
> constraints like a copyright-abuse-mailbox: NULL for signalling that one
> should not expect a reply to those sorts of messages. He also asked that IRT
> objects not be touched without prior discussion in the Working Group.
>
> Denis responded that the RIPE NCC understands that the IRT object is not
> very popular and that they have been asked to propose to the community as to
> how the IRT could be made more useful. He will provide feedback to the
> Working Group for further review.
>
> Piotr Strzyżewski, Silesian University of Technology, referred to Bengt’s
> presentation, noting that some of these corporations don’t care about the
> “abuse-c:” and therefore it wouldn’t be useful to establish another point of
> contact for them. He added that he loves the idea of national
> responsibility. Regarding validation, he feels there should be some policy
> about that.
>
> Christian responded that he thinks validation and extending the ROLE object
> should go through the RIPE Policy Development Process.
>
> Brian stated that he thinks it must go through that process.
>
> Christian continued, stating that extending the ROLE object is something
> that has come from the community. While he acknowledges that some countries
> have more than one national CSIRT, the implementation needs to be clear and
> the list of contact details for all of them should be provided. He added
> that the RIPE NCC is trying to work with them, in the case that the
> “abuse-c:” fails.
>
> Brian asked about the origin of the request from the community.
>
> Christian replied that it hadn’t come from the mailing list, and had come
> from a meeting of the computer security community.
>
> Kaveh Ranjbar, RIPE NCC, added that the provision of a proper abuse contact
> was a recurring point in the RIPE NCC Survey 2013’s results and therefore
> the RIPE NCC had started to attend security conferences.
>
> Ruediger asked Christian if the CSIRTS were happy about getting the reports,
> or if they were unhappy.
>
> Christian replied that they were happy.
>
> Ruediger expressed doubt and surprise that they would be happy to be
> “flooded” by copyright abuse reports. He called for guidelines and
> information as to what kind of report people should be sending to abuse
> contact, and how people should be responding to these reports.
>
> Denis added that, if Ruediger wants the RIPE NCC to provide these
> guidelines, then the community should provide the text.
>
> Ruediger agreed with Denis that this is a task for the Working Group.
>
> Brian added that he was surprised that the CSIRTS were happy, and noted that
> many countries don’t have a CSIRT. He added that he would put out a call for
> volunteers to help work on the guidelines.
>
> Ruediger added that, without guidelines, doing validation beyond mechanics
> is meaningless.
>
> ===
> E4: Introduction to Contact Databases for Abuse Handling
> Aaron Kaplan, nic.at
> ===
>
> Aaron explained how they do contact lookups at csirt.at, a national CSIRT
> for Austria. He noted that a national CSIRT is usually just a router for
> abuse contact information and that there are different approaches in
> different countries. Aaron asked those involved with the RIPE Database to
> have IRT objects, “abuse-c”, etc. as specific and up-to-date as possible as
> it will help those sending information to national CSIRTS for lookups.
>
> Brian asked where the information about Aaron’s presentation would be
> available and if he could publish it to the list.
>
> Aaron added that it is a document on Github.
>
> Brian asked if he could email the list with the URL.
>
> Aaron replied that it is part of a document that Christian Teuschel and
> Mirjam Keuhne, RIPE NCC, and Wilfried Woeber started. It is connected to a
> GitHub project called GitHub.com/CERTtools that is a contact cache/contact
> database for national CSIRTs so that they can build on the process.
>
> Brian added that it might be good to discuss this in more depth at a future
> RIPE Meeting.
>
> Aaron stated again that the CSIRT is just acting as a router, passing
> copyrights through, and the copyrights end up with network owners under
> their policies. However, he noted that the routing process can be optimised.
>
> There were no further questions or comments.
>
> Brian thanked Aaron for his presentation and invited the room to contribute
> agenda items for RIPE 69 in London. He thanked the scribe, speakers,
> stenographers and participants before closing the session.
>
>
>
>



-- 
Suresh Ramasubramanian (ops.lists at gmail.com)