- anti-abuse-wg - mailman.ripe.net

abuse-c attributes in resource objects
by Thomas Hungenberg 04 Jan '18

04 Jan '18

The "FAQs for abuse-c" says: You can have an "abuse-c:" attribute on both your ORGANISATION object AND your RESOURCE object (inetnum, inet6num and aut-num). The "abuse-c:" reference on applicable RESOURCE objects will override the value in the "abuse-c:" of your ORGANISATION object. [https://www.ripe.net/manage-ips-and-asns/resource-management/faqs-for-abuse…] However, in the RIPE documentation, the list of all possible attributes allowed in AUT-NUM and INETNUM objects does *not* include "abuse-c": [https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-1-description-of-the-aut-num-object] [https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-4-description-of-the-inetnum-object] There are currently some RESOURCE objects in the RIPE database having abuse-c attributes (which should not be allowed according to the documentation). For example: inetnum: 62.27.57.0 - 62.27.57.255 netname: TIS-D406483-NET descr: Cheetah Digital Germany GmbH country: DE admin-c: NET12312-RIPE tech-c: NET12312-RIPE abuse-c: CDAC23-RIPE status: ASSIGNED PA mnt-by: AS12312-MNT So we wonder what is correct? We would prefer sticking to the documentation allowing abuse-c attributes only in ORGANISATION objects but not in RESOURCE objects as this makes maintaining a local abuse contact database (for CERTs sending thousands of abuse reports per day) much easier. For example, for our local contact database, we import all ORGANISATION objects with "country: DE" and use "org-name" for the contact's name. Then, we link all RESOURCE objects referencing this ORG to the respective contact in our database. Also evaluating abuse-c attributes directly included in RESOURCE objects would make building a local contact database much more complex. - Thomas CERT-Bund Incident Response & Malware Analysis Team

1 0

Help Re: anti-abuse-wg Digest, Vol 73, Issue 5
by Ervin Radosavlevici 19 Dec '17

19 Dec '17

Sent from my iPhone > On Dec 19, 2017, at 11:00 AM, anti-abuse-wg-request(a)ripe.net wrote: > > Send anti-abuse-wg mailing list submissions to > anti-abuse-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.ripe.net/mailman/listinfo/anti-abuse-wg > or, via email, send a message with subject or body 'help' to > anti-abuse-wg-request(a)ripe.net > > You can reach the person managing the list at > anti-abuse-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of anti-abuse-wg digest..." > > > Today's Topics: > > 1. DMARC Solution Applied to this Mailing List (Adam Castle) > 2. Re: DMARC Solution Applied to this Mailing List (ox) > 3. Re: DMARC Solution Applied to this Mailing List (ox) > 4. Re: DMARC Solution Applied to this Mailing List (Gert Doering) > 5. Re: DMARC Solution Applied to this Mailing List (ox) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 18 Dec 2017 12:29:01 +0100 > From: Adam Castle <acastle(a)ripe.net> > To: anti-abuse-wg(a)ripe.net > Subject: [anti-abuse-wg] DMARC Solution Applied to this Mailing List > Message-ID: <a2863ca3-d7f8-6b1e-a1db-3fb8c5af8c35(a)ripe.net> > Content-Type: text/plain; charset=utf-8; format=flowed > > Dear Working Group, > > As more email providers enable Domain Message Authentication Reporting & > Conformance (DMARC), some people find they can no longer receive emails > from the mailing lists they are subscribed to. We have deployed a > Mailman setting change to address this problem. > > After consultation with the RIPE Working Group Chairs, we have enabled > the DMARC "Munge From" setting on all RIPE mailing lists. This means > that if your email service provider has DMARC enabled, you will continue > to receive all emails sent to this mailing list, but the "From" part of > the header will change. If you don't have DMARC enabled, you won't see > any change to the emails you receive from this mailing list. > > You can find more information about how we have been handling DMARC in > the following RIPE Labs articles: > > https://labs.ripe.net/Members/adam_castle/dmarc-and-the-ripe-ncc > > https://labs.ripe.net/Members/adam_castle/ripe-mailing-lists-and-dmarc > > To ensure all working group participants are aware of the changes, I am > sending this mail to all working groups. If you have any questions or > encounter any issues on this mailing list, please let me know. > > Many thanks. > > Adam Castle > Web Services Manager > RIPE NCC > > > > ------------------------------ > > Message: 2 > Date: Mon, 18 Dec 2017 14:16:43 +0200 > From: ox <andre(a)ox.co.za> > To: Adam Castle <acastle(a)ripe.net> > Cc: anti-abuse-wg(a)ripe.net > Subject: Re: [anti-abuse-wg] DMARC Solution Applied to this Mailing > List > Message-ID: <mailman.4.1513681201.2983.anti-abuse-wg(a)ripe.net> > Content-Type: text/plain; charset=US-ASCII > > > Hi Adam, > > Please enlighten me why RIPE does not support publish any SPF records? > > I do see the RRSIG, so am keen on understanding why RIPE supports DMARC > and no SPF? > > Andre > > -- > dig TXT ripe.net > ; <<>> DiG 9.9.9-P1 <<>> TXT ripe.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25373 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;ripe.net. IN TXT > > ;; AUTHORITY SECTION: > ripe.net. 299 IN SOA manus.authdns.ripe.net. > dns.ripe.net. 1513415885 3600 600 864000 300 > > > On Mon, 18 Dec 2017 12:29:01 +0100 > Adam Castle <acastle(a)ripe.net> wrote: > >> Dear Working Group, >> >> As more email providers enable Domain Message Authentication >> Reporting & Conformance (DMARC), some people find they can no longer >> receive emails from the mailing lists they are subscribed to. We have >> deployed a Mailman setting change to address this problem. >> >> After consultation with the RIPE Working Group Chairs, we have >> enabled the DMARC "Munge From" setting on all RIPE mailing lists. >> This means that if your email service provider has DMARC enabled, you >> will continue to receive all emails sent to this mailing list, but >> the "From" part of the header will change. If you don't have DMARC >> enabled, you won't see any change to the emails you receive from this >> mailing list. >> >> You can find more information about how we have been handling DMARC >> in the following RIPE Labs articles: >> >> https://labs.ripe.net/Members/adam_castle/dmarc-and-the-ripe-ncc >> >> https://labs.ripe.net/Members/adam_castle/ripe-mailing-lists-and-dmarc >> >> To ensure all working group participants are aware of the changes, I >> am sending this mail to all working groups. If you have any questions >> or encounter any issues on this mailing list, please let me know. >> >> Many thanks. >> >> Adam Castle >> Web Services Manager >> RIPE NCC >> > > > > > ------------------------------ > > Message: 3 > Date: Mon, 18 Dec 2017 14:23:06 +0200 > From: ox <andre(a)ox.co.za> > To: Adam Castle <acastle(a)ripe.net> > Cc: anti-abuse-wg(a)ripe.net > Subject: Re: [anti-abuse-wg] DMARC Solution Applied to this Mailing > List > Message-ID: <mailman.5.1513681201.2983.anti-abuse-wg(a)ripe.net> > Content-Type: text/plain; charset=US-ASCII > > > I just realised that my question is confusing :) > > I mean > > RIPE does not have dmarc or spf (but does dnssec) so, for me, my spam > filters score points on lack of SPF or even hard bounce on wrong SPF > > RIPE emails (from the mailing list) attracts points - for not having SPF > > So, more directly, I am asking if it is possible to add SPF even with a "~" is fine? > > > Andre > > On Mon, 18 Dec 2017 14:16:43 +0200 > ox <andre(a)ox.co.za> wrote: > >> Hi Adam, >> >> Please enlighten me why RIPE does not support publish any SPF records? >> >> I do see the RRSIG, so am keen on understanding why RIPE supports >> DMARC and no SPF? >> >> Andre >> >> -- >> dig TXT ripe.net >> ; <<>> DiG 9.9.9-P1 <<>> TXT ripe.net >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25373 >> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: >> 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 512 >> ;; QUESTION SECTION: >> ;ripe.net. IN TXT >> >> ;; AUTHORITY SECTION: >> ripe.net. 299 IN SOA >> manus.authdns.ripe.net. dns.ripe.net. 1513415885 3600 600 864000 300 >> >> >> On Mon, 18 Dec 2017 12:29:01 +0100 >> Adam Castle <acastle(a)ripe.net> wrote: >> >>> Dear Working Group, >>> >>> As more email providers enable Domain Message Authentication >>> Reporting & Conformance (DMARC), some people find they can no longer >>> receive emails from the mailing lists they are subscribed to. We >>> have deployed a Mailman setting change to address this problem. >>> >>> After consultation with the RIPE Working Group Chairs, we have >>> enabled the DMARC "Munge From" setting on all RIPE mailing lists. >>> This means that if your email service provider has DMARC enabled, >>> you will continue to receive all emails sent to this mailing list, >>> but the "From" part of the header will change. If you don't have >>> DMARC enabled, you won't see any change to the emails you receive >>> from this mailing list. >>> >>> You can find more information about how we have been handling DMARC >>> in the following RIPE Labs articles: >>> >>> https://labs.ripe.net/Members/adam_castle/dmarc-and-the-ripe-ncc >>> >>> https://labs.ripe.net/Members/adam_castle/ripe-mailing-lists-and-dmarc >>> >>> To ensure all working group participants are aware of the changes, I >>> am sending this mail to all working groups. If you have any >>> questions or encounter any issues on this mailing list, please let >>> me know. >>> >>> Many thanks. >>> >>> Adam Castle >>> Web Services Manager >>> RIPE NCC >>> >> >> > > > > > ------------------------------ > > Message: 4 > Date: Mon, 18 Dec 2017 16:46:37 +0100 > From: Gert Doering <gert(a)space.net> > To: ox <andre(a)ox.co.za> > Cc: Adam Castle <acastle(a)ripe.net>, anti-abuse-wg(a)ripe.net > Subject: Re: [anti-abuse-wg] DMARC Solution Applied to this Mailing > List > Message-ID: <20171218154637.GV45648(a)Space.Net> > Content-Type: text/plain; charset="us-ascii" > > Hi, > >> On Mon, Dec 18, 2017 at 02:16:43PM +0200, ox wrote: >> Please enlighten me why RIPE does not support publish any SPF records? >> >> I do see the RRSIG, so am keen on understanding why RIPE supports DMARC >> and no SPF? > > Adam did not state RIPE NCC would "support DMARC". DMARC is full of shit. > > What the RIPE NCC does is "activate workarounds to avoid mailing list > issues caused by other people running their domain with p=reject". > > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >

1 0

Re: [anti-abuse-wg] DMARC Solution Applied to this Mailing List
by Gert Doering 19 Dec '17

19 Dec '17

Hi, On Mon, Dec 18, 2017 at 02:16:43PM +0200, ox wrote: > Please enlighten me why RIPE does not support publish any SPF records? > > I do see the RRSIG, so am keen on understanding why RIPE supports DMARC > and no SPF? Adam did not state RIPE NCC would "support DMARC". DMARC is full of shit. What the RIPE NCC does is "activate workarounds to avoid mailing list issues caused by other people running their domain with p=reject". Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

2 1

DMARC Solution Applied to this Mailing List
by Adam Castle 18 Dec '17

18 Dec '17

Dear Working Group, As more email providers enable Domain Message Authentication Reporting & Conformance (DMARC), some people find they can no longer receive emails from the mailing lists they are subscribed to. We have deployed a Mailman setting change to address this problem. After consultation with the RIPE Working Group Chairs, we have enabled the DMARC "Munge From" setting on all RIPE mailing lists. This means that if your email service provider has DMARC enabled, you will continue to receive all emails sent to this mailing list, but the "From" part of the header will change. If you don't have DMARC enabled, you won't see any change to the emails you receive from this mailing list. You can find more information about how we have been handling DMARC in the following RIPE Labs articles: https://labs.ripe.net/Members/adam_castle/dmarc-and-the-ripe-ncc https://labs.ripe.net/Members/adam_castle/ripe-mailing-lists-and-dmarc To ensure all working group participants are aware of the changes, I am sending this mail to all working groups. If you have any questions or encounter any issues on this mailing list, please let me know. Many thanks. Adam Castle Web Services Manager RIPE NCC

2 2

Abuse auto responders & Legacy resources
by ox 16 Dec '17

16 Dec '17

Hi Everyone, Just when you thought it was safe to go in the water again..[1] (I did not expect to be posting again in 2017 :) ) Currently many people are not bothering to even monitor Abuse-C email boxes. As a real world example: 163.172.0.0 - 163.172.255.255 Right now, multiple Online SAS resources (in a bot net) is attempting to brute force web cms and there is no easy way to: Report the abuse or Notify the resource 'owner' - effectively the abuse-c has become useless and non relevant and it makes no difference that abuse-c exists as it is not monitored and means absolutely nothing. Legacy resources do this quite often and with everything: The argument is that new policies do not have to apply to legacy resources as these are somehow 'special' or 'old' or not relevant to policies. Legacy resources are actually MORE responsible for new policies than "new" resources. As legacy resources are OLD, outdated and not in line with the modern, new and present issues facing the Internet as a whole. So, my point is that as far as abuse is concerned: Policies should target legacy resources much more directly and with much more relevance as quite frequently, policy delinquency is directly tied and related to mostly legacy resources. Then, with regards the practical example: ONLINESAS-MNT's legacy range: So, the choices are: drop everything from the range - firewall only the affected port and spend our resources on tracking only the affected ip numbers (which with the eventual advent of ipv6 will make absolutely no sense) or simply just to dev/null everything from the entire range. What should concern abuse admins is that practically, the simplest, cheapest, easiest and most effective method is just to null the entire range. If we all start doing that, the planet will become less and less connected, except through the large peers with adequate resources to actively filter on a short term basis only the precise bot nets for that slice of time. ONLINESAS-MNT has configured an autoresponder that basically tells anyone sending mail there that they have to create an account on the company website, submit a ticket after figuring out how the web platform works, then interact with the system etc. Of course reporting abuse to ONLINESAS-MNT is so resource intensive, takes so long and is so involved that it is not done. My point is that ONLINESAS-MNT is not alone. managing abuse is a cost. Large companies want to make money - but they want to spend as little as possible to make that money. They are all the same. Avoiding a working abuse-c is a simple and easy way to cut down on your abuse management costs. In my opinion, this is a very bad practice and it does render the whole abuse-c as non functional anyway. As more and more companies figure out how they can avoid managing abuse, with no/limited blowback, they will all probably start doing exactly that - this will render abuse-c as pointless and futile as it will mean nothing - and it also devalues much of what RIPE/RIR does to ensure some sort of responsibility for maintaining functional data. It is patently pointless to have a resource record, like abuse-c - if it means absolutely nothing. Andre -- [1] Peter Benchley - JAWS 2 Just as an additional over share - I live by the ocean and yesterday morning we (me and my family) swam in close proximity to some great white sharks (the lifeguards then closed the beach) - beautiful creatures.

1 0

DRAFT WG Minutes - RIPE75
by Brian Nisbet 13 Dec '17

13 Dec '17

Colleagues, The RIPE NCC staff have put together the draft minutes from RIPE75. I would appreciate if you could take a look and let me know of any errors, issues or required corrections. RIPE 75 Anti-Abuse Working Group Minutes Wednesday, 25 October 2017, 11:00 - 12:30 WG Co-Chair: Brian Nisbet  Scribe: Nathalie Trenaman, RIPE NCC  Status: Draft A. Administrative Matters Brian Nisbet opened the meeting and welcomed the working group. There was one addition to the agenda: Jan Žorž will do a brief presentation about the BCOP work. The minutes for the RIPE 74 meeting were approved. B. Update B1. Recent list Discussion Brian mentioned that there was nothing much to reference content-wise on the mailing list apart from the usual discussions. The RIPE community Code of Conduct is extended and includes the mailing list. There was positive feedback about this development. C. Policies C1. Policies: 2017-02 (Regular Abuse-C Validation) - Gregory Mounier and Hervé Clemens The presentation is available at: https://ripe75.ripe.net/presentations/119-Policy-change-proposal-RIPE-75-Du… Jan Žorž, ISOC, said he liked the idea of an auto-responder and wanted to give RIPE NCC the mandate to validate contacts, but he was not sure about the frequency of once-a-year for validation. Jan thinks that over 90% of the contacts are probably correct. Ruediger Volk, Deutsche Telekom, stressed his point that he would like to see a guideline document for abuse-c contact information. Brian Nisbet pointed out that this has been a discussion before and that more input was then requested and not received. Ruediger Volk added that the RIPE NCC already has the mandate to keep the registry accurate and that there is no need for a separate policy to enforce that. A repercussion of closing an LIR from this policy violates the Standard Service Agreement (SSA). Nigel Titley, RIPE NCC Executive Board, stated that if this becomes a policy, it becomes automatically part of the SSA. Piotr Strzyžewski, Silesian University of Technology, Computer Centre, said he missed the financial impact slide in this presentation. Gregory Mounier, Europe, explained that it would be in the impact analysis, produced by the RIPE NCC. Piotr Strzyžewski said that in the General Meeting yesterday, it was discussed that there should not be an increase of more RIPE NCC staff members. He added that he feared robots and automation will be set up by members to deal with the process. Andrew de la Haye, RIPE NCC, explained that there would be an impact analysis published in the next phase of the policy process. If the policy would reach consensus, they would not include the cost factor. The cost factor will be discussed in the General Meeting. Erik Bais, A2B Internet, said that he thought the ARC (Assisted Registry Check) process was the right process for this and that the RIPE NCC had enough issues chasing members for ARCs. He added that he was strongly against the part of this policy proposal that mentions closing members. Andrea Cima, RIPE NCC, commented that the RIPE NCC wouldn’t be able to contact all the members through ARCs on a yearly basis, but they can partially use ARCs to prioritise those members where they think the abuse-c information is incorrect. He added that they do not know the numbers yet, so ARCs may not be enough to fulfil. ARCs can help but it's not the full solution. Peter Hessler, Hostserver GmbH, stated that he is very much against this policy. He said it was a waste of resources in all areas and he is extremely against the closure clause of this policy proposal. Alexander Isavin, Internet Protection Society, said that what is sad about this policy proposal, was that is comes from law enforcement. He added that RIPE is not about helping law enforcement, but to support networks. Brian Nisbet says that they should not forget that law enforcement is part of their community. Gregory Mounier said that by monitoring an email address, law enforcement would not be able to investigate criminals and that this policy proposal is for the good of the community. William Sylvester, Addrex, asked if this policy proposal excluded legacy space holders. Brian replied that it did because they have no ability to impose policy on legacy address space. William said he opposes policies that reclaim any space. Brian added that this raised an interesting point because it's been said a couple of times and this is something for the community to consider, not specifically to this. If people don't support a policy which may lead potentially to the revocation of resources (speaking purely as himself here), it puts the community in a very interesting position in regards to what they may or may not be able to do in the future and the policies which currently exist which can lead to closure of members and revocation of resources. It is a very general comment, that is an interesting thing because it was referenced during the General Meeting last time as well. Gregory commented that he would also like to include the legacy space, but he was told not to. Jordi Palet Martinez, The IPv6 Company, said that he was in favour of this proposal because it improved contact information. He said that a form is not a good idea, because it is a waste of resources. An email should be answered in a certain amount of days. Brian added that version two of this policy proposal would be sent to the mailing list soon. D. Interactions D1. Working Groups - RIPE Database and Implementation of “abuse-c" Brian encouraged everyone to look at the conversations on the Database mailing list and to attend the Database Working Group session if they wanted to discuss this topic. He said he was not going to go into it here because it was a piece of work on the database but it was worth referencing because it's about the abuse‑c. E. Presentation E1. Netflow Based Botnet Detection - Alireza Vaziri  The presentation is available at: https://ripe75.ripe.net/presentations/89-Botnet-V3.pdf There were no questions or comments. E2. Pre-Transfer Clean-Up of Abused Prefixes - Erik Bais  The presentation is available at:  https://ripe75.ripe.net/wp-content/uploads/presentations/45-Prefix-Broker-p… Brian asked how to make contact with the larger RBLs (Real-Time Blackhole Lists) and how to persuade them to update their information. Erik said they had some experience with them because of GRUMbot, but the people from Shadowserver have very good contacts. Typically is wasn’t that hard to get them to update their information. Gregory Mounier asked if he knew how the bad guys got the IPs, was it hijacking. Erik replied that the IP space was from a Dutch hosting provider that was a member of the RIPE NCC. So it was customers that were in this space that were using it for this type of activity and hiding their command and control servers. X. AOB Jan Žorž presented about a new idea from the BCOP (Best Current Operational Practice) Task Force. It is about IPv6 and mail servers; how to protect them, including DKIM, DMARC etc. Jan asked if there were any volunteers in the WG to help write this document. Jan will send a mail to the mailing list as well. Peter Koch, DENIC, asked about the scope of this best practice document and if there was a guideline for these operational best practices. Jan Žorž replied that Franck Martin from LinkedIn wrote something already, but he wants a BCOP document for a broader audience. Z. Agenda for RIPE 76 Brian closed the meeting and reminded people to submit topics for the RIPE 76 agenda. -- Brian Nisbet Network Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet(a)heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

2 1

Proposal Update 2017-02
by Brian Nisbet 30 Nov '17

30 Nov '17

Colleagues, I just wanted to update you on the status of 2017-02. Grégory & Hervé have finalised the new version of the proposal and the NCC are creating the impact analysis based on this version. Both will hopefully be shared with the mailing list for discussion in early January. Thanks, Brian Co-Chair, RIPE AA-WG -- Brian Nisbet Network Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet(a)heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

1 0

New on RIPE Labs: How to Build a Security Operations Centre
by Mirjam Kuehne 20 Nov '17

20 Nov '17

Dear colleagues, The Dutch National Cyber Security Centre (NCSC) has published a document outlining some guidelines on how you can easily set up a security operations centre in your organisation. Please find a summary on RIPE Labs: https://labs.ripe.net/Members/mirjam/how-to-build-a-security-operations-cen… Kind regards, Mirjam Kühne RIPE NCC

1 0

2017-02 New Policy Proposal (Regular abuse-c Validation)
by Marco Schmidt 27 Oct '17

27 Oct '17

Dear colleagues, A new RIPE Policy proposal, 2017-02, "Regular abuse-c Validation", is now available for discussion. The goal of this proposal is to give the RIPE NCC a mandate to regularly validate "abuse-c:" information and to follow up in cases where contact information is found to be invalid. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2017-02 As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the RIPE Working Group Chairs, decides how to proceed with the proposal. We encourage you to review this proposal and send your comments to <anti-abuse-wg(a)ripe.net> before 6 October 2017. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

10 15

2017-02 Policy Proposal (Regular abuse-c Validation)
by herve.clement＠orange.com 23 Oct '17

23 Oct '17

Hello all, We (Grégory and I) are working on a new version of the "regular abuse-c validation" trying to take into account the various remarks held by the community during the discussion phase. The new version first includes a reference to ARC and specifies the limits of ARC reviews that are not able to cover the validation of Abuse-c contact points. It clarifies what a validation procedure should be, specifying what a validated answer is after RIPE NCC first attempt of contact and defining two validation periods. The first one covers the timeline the RIPE NCC is supposed to receive an answer after its first request and a second one is dedicated to the efforts made by the two parties to solve the issue in case of no validated answer during the first period. We recall that additional operational validation details (including RIPE NCC work load) will be part of the Impact Analysis. There is finally a clear reference to the ripe-676 "Closure of Members, Deregistration of Internet Resources..." underlining what are the ultimate cases a closure or deregistration could occur. The discussion with regard to these updates will be on the agenda for the Anti Abuse WG meeting on Wednesday. Regards Greg and Hervé _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

1 0