So, curious. How many colleagues from ripe aa wg were at MAAWG brussels or the subsequent Boston meeting last month?<br><br>Were you able to talk to spamhaus there?<br><div class="gmail_quote">On Wed, 5 Nov 2014 at 21:46 Brian Nisbet <<a href="mailto:brian.nisbet@heanet.ie">brian.nisbet@heanet.ie</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Colleagues,<br>
<br>
It was pointed out in the meeting today that there were mistakes with<br>
the previous minutes and we've discovered that an important section or<br>
two were missing. Below I have pasted the new version of the RIPE 68<br>
minutes, including the conversation about LEA attendance at RIPE related<br>
meetings (Section D.3). If you could take a look at these that would be<br>
great.<br>
<br>
Also, if I could ask the NCC to look at the possibilities around the<br>
action that was assigned to them in that section.<br>
<br>
Thanks,<br>
<br>
Brian<br>
<br>
******************************<u></u>*****<br>
<br>
===<br>
<br>
A. Administrative Matters<br>
<br>
Brian welcomed the participants to the Working Group session and<br>
introduced himself and Tobias as co-chairs. and thanked the RIPE NCC for<br>
providing support in the form of chat monitor, scribe and<br>
stenographers.

The minutes from RIPE 67 and RIPE 66 were approved and<br>
there were no additions to the agenda.<br>
<br>
B. Update<br>
<br>
Brian asked the room if there was anything pertaining "abuse-c:" that<br>
needed to be raised. As nobody spoke up, Brian stated that it could be<br>
covered later on if needed.

Brian mentioned that he had circulated some<br>
text for the working group charter. He noted that there had been some<br>
discussion but was happy to keep any discussion on the list. He invited<br>
the room to make any comments there and then if needed.

There were no<br>
comments.

Brian urged the participants to read the charter on the<br>
mailing list.<br>
<br>
C. Policies<br>
<br>
Brian stated that there were no open policies at the moment.<br>
<br>
D1. Interactions With Other Working Groups<br>
<br>
Regarding interactions with other working groups on policy, Brian noted<br>
that he and Tobias had agreed with Nigel Titley and Wilfried Wober, the<br>
Database Working Group Chairs, that he and Tobias would work on the data<br>
verification policy. He mentioned that he and Tobias would not have time<br>
for this soon, and therefore urged participants that, should they want<br>
to take on the task, they were welcome.<br>
<br>
D2. Proof of identity discussions – RIPE Policy Proposal 2007-01<br>
<br>
There was some discussion about the level of proof of identity that the<br>
RIPE NCC should expect.

Athina Fragkouli, RIPE NCC, stated that this<br>
was also discussed in the Address Policy Working Group and there were<br>
not many concerns about how the RIPE NCC handles proof of identity. She<br>
added that the RIPE NCC is always open to changing procedures.

Brian<br>
asked the room whether the RIPE NCC are doing enough, too little, or to<br>
much regarding proof of identity. He asked if there should be more<br>
trust.

Jim Reid, unaffiliated, felt that things should be left as they<br>
are. He expressed that he thought it was bad to collect personal data<br>
unless there is a strong need for the data. However, he can appreciate<br>
the RIPE NCC's point and can see how it's useful in some cases, such as<br>
for law enforcement and other aspects of anti-abuse.<br>
Brian agreed that it's okay for the RIPE NCC to continue as it is.<br>
<br>
D3. RIPE NCC Government/LEA Interactions Update<br>
-Marco Hogewoning, RIPE NCC<br>
<br>
The presentation is available online:<br>
<a href="https://ripe68.ripe.net/presentations/387-AA-LEA-Update-MH1_AG.pdf" target="_blank">https://ripe68.ripe.net/<u></u>presentations/387-AA-LEA-<u></u>Update-MH1_AG.pdf</a><br>
<br>
Alexander Isavnin, NetLine, asked if it was possible for a Dutch<br>
membership organisation to join closed meetings and not reveal what was<br>
discussed.<br>
<br>
Marco responded that he thought it was possible.<br>
<br>
Alexander stated that the community wants to know what happens at these<br>
meetings and urged for no secrecy. He wanted to know the name, rank, and<br>
position of those attending these meetings with law enforcement.<br>
<br>
Marco stressed that these meetings are with law enforcement agencies<br>
(LEAs), not with the intelligence community.<br>
<br>
Alexander responded that name, rank and position will support that the<br>
attendees are not from the intelligence community.<br>
<br>
Marco responded that the RIPE NCC is looking at a way to improve the<br>
reporting but needs to work with LEAs about the information that can be<br>
published. He added that it may be possible to publish attendee lists<br>
and or give more information about the attendees, however, it's<br>
important that the trust level is maintained between the LEAs and the<br>
RIPE NCC.<br>
<br>
Alexander responded that he wants European interaction to be more clear.<br>
<br>
Jochem De Ruig, RIPE NCC, stated that Brian Nisbet is invited to these<br>
meetings so that he can provide input from the community's perspective.<br>
<br>
Brian added that he has been asked by someone from the National Crime<br>
Agency (NCA) to remove their name from a public agenda as their friends<br>
and family did not know with whom they were employed. Brian felt that<br>
there would not be much cooperation if a full list of attendees was to<br>
be published.<br>
<br>
Malcolm Hutty, LINX, added that it's about balance and satisfying all<br>
parties reasonably. With some advance planning, he feels that basic<br>
information could be disclosed and some transparency added. He added<br>
that it would be best to avoid mentioning whether anything operational<br>
was discussed (or not). He also noted that some individuals would<br>
probably need their names kept secret and off lists, and therefore it<br>
may make sense to ask them if the name of their organisation could be<br>
published.<br>
<br>
Brian agreed that he fully advocates transparency and agreed with the<br>
need for balance.<br>
<br>
Jim Reid agreed with Malcolm, and urged for more forward planning. He<br>
also added that he felt it would be wrong to disclose the name, rank and<br>
identity of everybody attending a meeting because that, in itself, could<br>
disclose operational details.<br>
<br>
Marco concluded that that he will take this back to law enforcement and<br>
work with them on future events to achieve better reporting.<br>
<br>
E1. "Anti-Abuse: The View from the Messaging World"<br>
-Jerome Cudelou, M3AAWG<br>
<br>
The presentation is available<br>
online:
<a href="https://ripe68.ripe.net/presentations/373-M3AAWG.pdf" target="_blank">https://ripe68.ripe.net/<u></u>presentations/373-M3AAWG.pdf</a>

Brian<br>
asked whether there are any more areas of mutual engagement that could<br>
be touched upon.

Jerome responded that it would be best to become<br>
members of M3AAWG.

Brian asked whether non-members of M3AAWG could<br>
contribute to M3AAWG’s documentation.

Jerome responded that he didn’t<br>
think it was easy to do and that it is better to become a<br>
member.

Rüdiger Volk, Deutsche Telekom, asked if there were documents<br>
that would explain what is expected of an abuse contact.

 Jerome<br>
responded that the document is under discussion.

Vincent Schonau,<br>
abuseix and co-chair of the Training Committee at M3AAWG, further<br>
clarified that there is the Abuse Desk Best Practises document that is<br>
now a few years old.  He added that the Abuse Desk Special Interest<br>
Group has revived the document and would work on it in upcoming<br>
meetings.

Alex de Joode, LeaseWeb, stated that LeaseWeb is not a member<br>
of M3AAWG but are participating in the Hosting Special Interest Group<br>
(SIG) and the Abuse SIG so participation is possible without becoming a<br>
member.

Brian asked Alex what the procedure was for<br>
participation.

Alex responded that he had sent a message to Gerry Upton<br>
and received a free invitation.

Samaneh Tajalizadehkhoob, Delft<br>
University of Technology, asked if M3AAWG cooperate with research<br>
institutions. She mentioned that Delft University of Technology are<br>
working on banking malware and mobile malware, and asked if M3AAWG share<br>
data with them.

Jerome responded that they do share data with research<br>
institutions.

Vincent noted that M3AAWG has a very open policy about<br>
inviting people to come to the European meetings and the emerging groups<br>
such as the Hosting SIG. He directed interested parties to Gerry, Jerome<br>
or himself for an invitation.

Brian asked an open question to RIPE NCC<br>
members in the room whether there had been any interaction with M3AAWG<br>
since RIPE 45 in Barcelona. Jochem de Ruig, RIPE NCC, responded that<br>
the RIPE NCC would try to come to Brussels and that the RIPE NCC did<br>
find the meeting useful for engagement with the community.<br>
<br>
E2: Impact of abuse-c<br>
<br>
-Bengt Gördén, Resilans

The presentation is available<br>
online:
<a href="https://ripe68.ripe.net/presentations/383-impact_abuse-c.pdf" target="_blank">https://ripe68.ripe.net/<u></u>presentations/383-impact_<u></u>abuse-c.pdf</a>

Ruediger<br>
asked whether the message to the abuse-c at Spamhaus was<br>
successful.

Bengt replied that it was not, and asked if there were<br>
questions about that.

Ruediger continued, adding that Spamhaus is<br>
bullying people on the Internet and that a joke he had heard is that it<br>
may be possible to send a claim of copyright or trademark infringement<br>
with the name Spamhaus and send it to .org.

Bengt added that it would<br>
work.

Ruediger added that the Internet community needs to make sure<br>
that things are balanced out, thanking Bengt for his presentation.

Erik<br>
Bais, ATB Internet, added that they had been in the same situation with<br>
Spamhaus and it had been well-documented.

Bengt responded that he had<br>
read about it.

Erik continued that they had disclosed fully about their<br>
interactions with Spamhaus, who had behaved brazenly in return, finding<br>
the situation amusing and even blogging about it on their website. Erik<br>
added that Spamhaus do not care and that they have been invited to the<br>
RIPE Anti-Abuse Working Group sessions, to have a panel and discuss the<br>
proper policies, but had refused the invitation.

Brian added that that<br>
the relations between the Working Group and Spamhaus were not as good as<br>
they would like, and redirected the discussion back to “abuse-c:”.

Erik<br>
stated that they transferred some of their address blocks and even after<br>
six months they still receive emails to their abuse mailbox regarding<br>
blocks that they don’t own anymore. He called for people to use the RIPE<br>
Database and asked how it is possible to make people update their<br>
information.

Bengt replied that he feels the community needs to work on<br>
this issue collectively, but not necessarily in a way that results in<br>
any legislation or policy.

Erik added that it’s good to remember that<br>
Spamhaus does not block mail and there is always a need for well-managed<br>
block lists.

Peter Koch, DENIC, asked Bengt about his slides as they<br>
seemed somewhat contradictory to him, as they looked more like a<br>
“suffering story” rather than a success story and he did not understand<br>
why it was being used as an example, as Bengt’s “I told you so.”

Bengt<br>
responded that maybe it is time that they give up on optimising the<br>
“abuse-c:” for an audience that cannot be educated.

Brian invited<br>
Tobias Knecht, his fellow chair of the Anti-Abuse Working Group to<br>
comment on similar policies in other regions.

Tobias stated that the<br>
policy about “abuse-c:” was brought into APNIC in a different way, as<br>
well as at AFRINIC. While the implementations were different, the end<br>
result was the same - that there is an abuse contact in the Whois<br>
Database, a single space.

Bengt noted that he had tried to get an abuse<br>
contact for Spamhaus and it hadn’t worked.

Alex Le Heux, Kobo Inc,<br>
added that they had similar experiences with many of those blacklists.<br>
He stated that Spamhaus regularly attends M3AAWG and advised those who<br>
wanted to meet with them, to go to the Brussels meeting. He invited<br>
those with similar experiences to come to the meeting so that some sort<br>
of best practises for blacklists can be set up.

Brian confirmed that a<br>
best practises document that has come out of M3AAWG already exists.<br>
<br>
E3: Abuse-c: Next Steps for “abuse-c:”<br>
-Denis Walker and Christian Teuschel, RIPE NCC

The presentation is<br>
available<br>
online:
<a href="https://ripe68.ripe.net/presentations/162-aa_wg.pdf" target="_blank">https://ripe68.ripe.net/<u></u>presentations/162-aa_wg.pdf</a>

Brian noted<br>
that time was running short, and some discussion may need to be directed<br>
to the mailing list.

Ruediger asked if it was explained anywhere how<br>
ORGANISATION objects should be used.

Denis responded that it was one of<br>
the big problems with the RIPE Database.

Ruediger noted that there is<br>
no documentation and explanation of the data model that the RIPE NCC<br>
says that the community should be following.

Denis replied, saying that<br>
no business rules were built into the software to enforce any of this,<br>
and agreeing that there are no guidelines.

Ruediger argued that, if<br>
there is a data architecture that should be followed, it should be<br>
documented and agreed upon. He called for a document that explains what<br>
the architecture is.

Brian asked whether this discussion would be<br>
something better suited to the Database Working Group.

Peter thanked<br>
Denis and Christian for their hard work. He noted that the RIPE Policy<br>
Development Process allows early and often objections and he believes<br>
that they are at risk of going completely overboard in a variety of<br>
aspects. He stated that he thinks that the model is in the wrong<br>
direction, and he is opposed to “salami tactics”. His interpretation of<br>
one of the slides is that there is an ORG object and the addresses hang<br>
off it, and he cannot find any document that describes it that way. The<br>
database model with which he is familiar is one built around the objects<br>
you ask for, and the information attached to the objects, in other<br>
objects. He called for changes to the model. He added that if this were<br>
moved to the Database Working Group, that would only partly help as the<br>
changes proposed from the Anti-Abuse Working Group may not be compatible<br>
with the Database Working Group point of view.

Brian clarified that, if<br>
there were issues with the architecture and business rules and<br>
documentation, then it would be more appropriate for the Database<br>
Working Group to work with the RIPE NCC to get that written.

Peter<br>
stated that it may be time to reconfirm the mission of the RIPE<br>
Database, adding that it should not become a “compliance stick” for<br>
Local Internet Registries or resource holders.

Christian asked Peter<br>
what he had meant by “salami tactic” regarding the validation.

Peter<br>
clarified that having a mailbox does not mean that mail is delivered or<br>
read. The next slice of salami is to validate, so that mail can be<br>
expected to be deliverable. He envisioned that, three  months later, it<br>
won’t only be deliverable, but there would be a reply.

Christian<br>
replied that this is what they had proposed, improving the data<br>
quality.

Peter added that caution would need to be taken when regarding<br>
data quality as it is a topic for the admin-c and the resource holder.<br>
He believes that the data should be correct because that is the core<br>
mission.

Via remote participation, Gilles Massen asked if, as the<br>
existing IRT objects are becoming more invisible, would it be possible<br>
to reference an IRT from the “abuse-c:” or at least add the useful IRT<br>
features like BGP keys to the “abuse-c:”. He stated that he would like<br>
to see relaxed constraints like a copyright-abuse-mailbox: NULL for<br>
signalling that one should not expect a reply to those sorts of<br>
messages. He also asked that IRT objects not be touched without prior<br>
discussion in the Working Group.

Denis responded that the RIPE NCC<br>
understands that the IRT object is not very popular and that they have<br>
been asked to propose to the community as to how the IRT could be made<br>
more useful. He will provide feedback to the Working Group for further<br>
review.

Piotr Strzyżewski, Silesian University of Technology, referred<br>
to Bengt's presentation, noting that some of these corporations don't<br>
care about the "abuse-c:" and therefore it wouldn't be useful to<br>
establish another point of contact for them. He sarcastically added that<br>
he “loves" the idea of national responsibility (with the opposite being<br>
his true feelings on the matter). However, he does feel that there<br>
should be some policy regarding validation.

Christian responded that he<br>
thinks validation and extending the ROLE object should go through the<br>
RIPE Policy Development Process.

Brian stated that he thinks it must go<br>
through that process. Christian continued, stating that extending the<br>
ROLE object is something that has come from the community. While he<br>
acknowledges that some countries have more than one national CSIRT, the<br>
implementation needs to be clear and the list of contact details for all<br>
of them should be provided. He added that the RIPE NCC is trying to work<br>
with them, in the case that the “abuse-c:” fails.

Brian asked about the<br>
origin of the request from the community.

Christian replied that it<br>
hadn’t come from the mailing list, and had come from a meeting of the<br>
computer security community.

Kaveh Ranjbar, RIPE NCC, added that the<br>
provision of a proper abuse contact was a recurring point in the RIPE<br>
NCC Survey 2013’s results and therefore the RIPE NCC had started to<br>
attend security conferences.

Ruediger asked Christian if the CSIRTS<br>
were happy about getting the reports, or if they were<br>
unhappy.

Christian replied that they were happy.

Ruediger expressed<br>
doubt and surprise that they would be happy to be “flooded” by copyright<br>
abuse reports. He called for guidelines and information as to what kind<br>
of report people should be sending to abuse contact, and how people<br>
should be responding to these reports.

Denis added that, if Ruediger<br>
wants the RIPE NCC to provide these guidelines, then the community<br>
should provide the text.

Ruediger agreed with Denis that this is a task<br>
for the Working Group.

Brian added that he was surprised that the<br>
CSIRTS were happy, and noted that many countries don’t have a CSIRT. He<br>
added that he would put out a call for volunteers to help work on the<br>
guidelines.

Ruediger added that, without guidelines, doing validation<br>
beyond mechanics is meaningless.<br>
<br>
E4: Introduction to Contact Databases for Abuse Handling<br>
-Aaron Kaplan, <a href="http://nic.at" target="_blank">nic.at</a><br>
<br>
Aaron explained how they do contact lookups at <a href="http://csirt.at" target="_blank">csirt.at</a>, a national<br>
CSIRT for Austria. He noted that a national CSIRT is usually just a<br>
router for abuse contact information and that there are different<br>
approaches in different countries. Aaron asked those involved with the<br>
RIPE Database to have IRT objects, “abuse-c”, etc. as specific and<br>
up-to-date as possible as it will help those sending information to<br>
national CSIRTS for lookups.

 Brian asked where the information about<br>
Aaron’s presentation would be available and if he could publish it to<br>
the list. Aaron added that it is a document on Github.

Brian asked if<br>
he could email the list with the URL.

 Aaron replied that it is part of<br>
a document that Christian Teuschel and Mirjam Keuhne, RIPE NCC, and<br>
Wilfried Woeber started. It is connected to a GitHub project called<br>
GitHub.com/CERTtools that is a contact cache/contact database for<br>
national CSIRTs so that they can build on the process.

Brian added that<br>
it might be good to discuss this in more depth at a future RIPE<br>
Meeting.

Aaron stated again that the CSIRT is just acting as a router,<br>
passing copyrights through, and the copyrights end up with network<br>
owners under their policies. However, he noted that the routing process<br>
can be optimised.

There were no further questions or comments.

Brian<br>
thanked Aaron for his presentation and invited the room to contribute<br>
agenda items for RIPE 69 in London. He thanked the scribe, speakers,<br>
stenographers and participants before closing the session.<br>
<br>
</blockquote></div>