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

Re: [anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
by Carlos Friaças 22 Mar '19

22 Mar '19

Hi Erik, All, Thanks for your input. Your message was quite long, so i'll try to answer several aspects of it below, after quoting what you wrote. ======= > 1. "The official reaction to Dutch parliament was, that it was too hard > to prosecute or even find the actual people behind the hijack and they > decided not to go after them." This means they decided this time, it doesn't mean they wouldn't decide differently in a subsequent timeframe. The hijackers could easily repeat their wrongdoings? Yes, they could, with the same set of resources (same ASN and same other legitimate prefixes to support the 'operation'). It's important also to state that a different victim might feel differently and it could value extra tools in fighting this. Remember, a non-dutch victim will have some extra difficulty engaging with dutch courts because those victims will lack in knowledge about dutch law. This is also a case which involved #politics. A private company (as a victim), would probably in the first place defend their own interests and their shareholders, regardless of its country's politics. ======= > 2. "Even IF they would have proceeded .. under Dutch law, BGP Hijacking > isn't a criminal offence and as a result, not directly illegal or > criminal.. Performing a (D)DOS or breaking into a computer system is.. > but BGP hijacking as such isn't. Especially if the IP space wasn't in > use.. so nothing broke or stopped working .." So, acting at RIR level could be seen as actually filling in for a gap in Dutch law? If this is the case, good, as this gap affects people well beyond dutch (and EU) borders. Again, i think we are dismissing the relevance of the other type of victims involved... those who *receive* the hijacked routes announcements and can be easily tricked by "oh, this is the dutch parliament's space, so this should be fine" and then their packets go towards the hijacker's network/systems. That's a clear path to enable "impersonation", "fraud", and so on... ======= > 3. "So even if they would get the Bulgarian spammer/hijackers in front > of a Dutch judge .. the change was that ... they would walk, because there > was no harm done .. No law was broken, no system invaded and nothing > stopped working..." I think 2019-03's goal is not to bring more people from around the world in front of Dutch judges. :-) With this self-regulatory framework in place hijackers (and everyone) will have in writing that their actions are not tolerated by the community, and if it comes to that, their 'business model' will be somewhat affected if they need to gather/find new numbers to resume their line of 'business'. ======= > 4. "So in this case, the Italian Police (ROS) used (forced??) an Italian > ISP to hijack some IP space to regain control of their lost RAT C&C > server.. (endpoint for RAT infected machines.) This wasn't an accident > .. but was it criminal by the ISP to assist their local police ? And > what would have been the impact if they didn't... ?" While this might be indifferent for the average Internet User in Kazakhstan, Malaysia, Chile, Canada, Seychelles or Belize, and any of them might argue this line of action should have a consequence, the best way 2019-03 tries to accomodate this type of corner cases is the ratification phase. Those who will have to ratify a 2nd instance report can be provided with enough evidence (an Italian court order?) so that ratification doesn't occur. Even if this isn't the case (and no evidence is provided) or the report even disputed, the ISP can only get a warning (and the concrete consequence is out of 2019-03's scope). ======= > 5. "These are your/our tax dollars at work ... They either don't care > or are the bad actor themselves." It depends on the viewpoint and the available set of evidence. In this case it can also be argued that it was a good actor. :-) Additionally, nothing guarantees that a report/complaint is going to be issued against _every_ hijack. Also, admissible evidence (from historical routing data) will have an expiration timeframe in version 2.0. ======= > 6. "So the customers that hold an SSA or End-User Agreement (PI Holders > for IP space and AS number) look to be the 'target' of the policy, > however that leaves out the legacy resource holders.." That is unaccurate. The 'target' is everyone who intentionally performs an hijack. About the legacy resource holders, if they violate RIPE policies, i don't see why their access to NCC's Services can't be denied (permanently or temporarily?) -- that's my interpretation, but we can also have a line about that in version 2.0. If RPKI is not available for legacy resources, that might have some impact. ======= > 7. "And with the current transfer policies in place, yes it is possible > to obtain a legacy AS number and a legacy IPv4 prefix ...for yourself .. > and those can't be 'retrieved' with this policy .. And even with the > policy, it isn't the RIPE NCC that COULD de-register them as they are > not allocated by the RIPE NCC in the first place ..." Exactly. Here we agree. The only possible consequence/effect (imho) is denying access to services, based on non-compliance with RIPE policies. Anyway, 2019-03 doesn't have the "recovering" of resources back to the NCC as a goal. ======= > 8. "So Legacy holders (resources with a legacy status) are for obvious > reasons, excluded for penalties and out of reach. Also according to the > policy that specifies services to Legacy holders, as this policy doesn't > state that it wants to include and impact legacy holders." I don't agree. If you check i was one of the co-authors of 2012-07 :-) In my initial drafts for 2019-03, there was a line about legacy holders. It seems now clear it needs to be recovered for version 2.0 :-) ======= > 9. "The biggest issue what I see in this policy, is that the RIPE NCC ( > either themselves or the Exec Board. ) is desired / aimed to pull the > trigger on a membership or contractual relationship." And they could (the Exec Board) decide not to do it, due to the ratification section. But *today*, it's a tool they don't have. If you are uncomfortable with the Exec Board, would the RIPE Chair/Vice-Chair be an acceptable alternative? Or should a different set of people be selected to have control over the ratification knob? ======= > 10. "These kind of actions or decisions should be kept out of the RIPE > NCC office and the actual case and decision should be made by a court > and court order." I fully agree the NCC staff should be completely kept out of this process. I'm not entirely sure about the Exec Board, but would easily agree on an independent set of people. As you already stated, Dutch law has a loophole (ok, you might not see it as a loophole) where a BGP hijack is not illegal, so saying "come back with a court order" is something that obviously won't happen and hijacks can happily proceed without any major disturbance. ======= > 11. "If someone likes to make the case that someone is in violation, > there should be a neutral judge that should review the case and the > accuser can go to the RIPE NCC with the result .. And the RIPE NCC will > just execute based on the outcome." That's what we tried to design with 2019-03, where the "neutral judge" is a set of experts -- i.e. more than one. ======= > 12. "I can understand the sentiment or intent of the policy, but I'm > against any form of policy where the RIPE NCC or the Exec Board will be > involved in the actual decision like this as it will impact their > neutral status and the fact they are opening themselves for liability > claims." As i've written above, i'm open to suggestions about how to take the Exec Board out of the picture, so that could be incorporated in version 2.0 (please see #9 above). ======= Best Regards, Carlos

5 5

2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
by António Manuel Araújo Da Silva Rio Costa 22 Mar '19

22 Mar '19

Hi, I express my support to the 2019-03 proposal Best Regards; António Rio Costa UTAD ICT email: acosta(a)utad.pt sip: acosta(a)voip.utad.pt ext: 4668 Tlf: +351 259350668 ___________________________________________ I do not fear computers. I fear the lack of them. "Isaac Asimov" __________________________________________________________ ---Nota de Confidencialidade--- Os dados constantes da presente mensagem são destinados apenas à(s) pessoa(s) ou entidade(s) acima referida(s), podendo conter informação CONFIDENCIAL, cuja divulgação está expressamente vedada nos termos da lei. Se não é o destinatário da mensagem, ou se ela lhe foi enviada por engano, por favor informe de imediato enviando um email para acosta(a)utad.pt e apague a mesma. --- Confidentiality Note --- The data contained in this message is intended only for the person (s) or entity (s) referred to above, and may contain CONFIDENTIAL information whose disclosure is expressly prohibited under the law. If you are not the recipient of the message, or if it was sent to you in error, please inform immediately by sending an email to acosta(a)utad.pt and delete it.

1 0

Re: [anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
by Gert Doering 22 Mar '19

22 Mar '19

Hi, On Thu, Mar 21, 2019 at 07:38:34AM +0000, Suresh Ramasubramanian wrote: > Ah that way. Then - > > Do we have rough consensus? If not at what point is it reached? Now this is left to the AA WG chairs to decide :-) As per the RIPE PDP, we're in "discussion phase", which is run to the end date Marco announced (too lazy to look it up). Then, the proposers decide together with the relevant WG chairs if they think it makes sense to go ahead (it does not have to have consensus, but should have some amount of support, and no counter arguments that are compelling enough to outright kill the proposal). If yes, the RIPE NCC does the Impact Analysis, and the proposal moves to review phase. At the end of the review phase, the WG chairs determine rough consensus. Here's a nice video about the phases https://www.ripe.net/participate/policies plus the link to the formal document https://www.ripe.net/publications/docs/ripe-710 Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

4 4

2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
by CSIRT.UMINHO Jose Ramada 21 Mar '19

21 Mar '19

Hello all. I support the 2019-03 proposal. Cumprimentos, Jose Ramada ---------------------------------------------------------------------------- --------------------------------------------------------------- CSIRT.UMINHO - Universidade do Minho Serviços de Comunicações - Campus de Gualtar, 4710-057 Braga - Portugal Tel.: + <callto:351%20253%2060%2010%2020> 351 253 60 10 20, Fax: <callto:+351%20253%2060%2010%2029> +351 253 60 10 29 <https://csirt.uminho.pt/> https://csirt.uminho.pt | <mailto:report@csirt.uminho.pt> report(a)csirt.uminho.pt | <mailto:info@csirt.uminho.pt> info(a)csirt.uminho.pt ---------------------------------------------------------------------------- --------------------------------------------------------------- This email is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this mail in error, please tell us immediately by return email and delete the document --- Este e-mail foi verificado em termos de vírus pelo software antivírus Avast. https://www.avast.com/antivirus

1 0

Re: [anti-abuse-wg] 2019-03 New Policy Proposal (BGP
by CSIRT.UMINHO Amandio Antunes 21 Mar '19

21 Mar '19

Hi all! I support the 2019-03 proposal. Cumprimentos, Amândio Antunes ----------------------------------------------------------------- CSIRT.UMINHO Universidade do Minho Serviços de Comunicações Campus de Gualtar, 4710-057 Braga - Portugal Tel.: + 351 253 60 40 20, Fax: +351 253 60 40 21 email: amandio(a)csirt.uminho.pt | http://www.csirt.uminho.pt ----------------------------------------------------------------- This email is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this mail in error, please tell us immediately by return email and delete the document. -- Este email é confidêncial. Se não é o destinatário do mesmo, não deve nem revelar, nem usar o seu conteúdo. Se recebeu esta mensagem por engano, por favor informe-nos Imediatamente, devolvendo e apagando este email.

1 0

2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
by Filipe Manuel Rebelo 21 Mar '19

21 Mar '19

Hi, I would like to express my support to the 2019-03 proposal. Regards. ________________________________ AVISO - Esta mensagem e quaisquer documentos anexos seus podem conter informa??o confidencial sujeita a sigilo profissional para uso exclusivo do(s) seu(s) destinat?rio(s). Cabe ao destinat?rio assegurar a verifica??o da exist?ncia de v?rus ou erros, uma vez que a informa??o contida pode ser intercetada ou corrompida. Se n?o for o destinat?rio, n?o dever? usar, distribuir ou copiar este e-mail, devendo proceder ? sua elimina??o e informar o emissor. ? estritamente proibido o uso, a distribui??o, c?pia ou qualquer forma de dissemina??o n?o autorizada do conte?do desta mensagem. DISCLAIMER - This message, as well as any attachments to it, may contain confidential information for exclusive use of the intended recipients. The recipients are responsible for the verification of the existence of viruses or errors, since the information transmitted could have been intercepted or in any way corrupted. If you?re not the intended recipient, you cannot use, distribute or copy this message, and you should destroy it and inform the originator of it. It?s strictly prohibited the use, distribution copy or any other form of unauthorized dissemination of this message?s content.

1 0

@EXT: 2019-03 New Policy Proposal
by Marcolla, Sara Veronica 20 Mar '19

20 Mar '19

Hi all, +1 for the proposal as is. Thank you both Carlos and Jordi for bringing this topic up for discussion. Kind regards, Sara Marcolla Europol - O3 European Cyber Crime Centre (EC3) www.europol.europa.eu ******************* DISCLAIMER : This message is sent in confidence and is only intended for the named recipient. If you receive this message by mistake, you may not use, copy, distribute or forward this message, or any part of its contents or rely upon the information contained in it. Please notify the sender immediately by e-mail and delete the relevant e-mails from any computer. This message does not constitute a commitment by Europol unless otherwise indicated. *******************

1 0

Re: [anti-abuse-wg] 2019-03 New Policy Proposal
by Karl-Josef Ziegler 20 Mar '19

20 Mar '19

Hello! I'm also supporting this new policy proposal. Best regards, - Karl-Josef Ziegler

1 0

Re: [anti-abuse-wg] [routing-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation) to be discussed on Anti-Abuse Working Group Mailing List
by Andrey Korolyov 19 Mar '19

19 Mar '19

> > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-03 Hey WG, out of curiosity, why neighboring ASNs are not carrying any responsibility for not filtering out a malicious advertisement from a directly-peered neighbor in the proposal? AFAIU most leaks happen because large parties are letting their ACL loose, not because some state-backed player decides to take a pick on someone's else traffic (though both variants exists). The peer who allows any prefix announcement originating from its direct neighbor is no less responsible for the hijack as the origin AS itself. Could you please suggest a possibility to include that kind of relations (determined by third parties, as currently stated for hijacker's AS in the draft) and measures against a transit/upstream in same manner as they are currently defined for a hijacker? Thanks.

3 4

Re: [anti-abuse-wg] [routing-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation) to be discussed on Anti-Abuse Working Group Mailing List
by Daniel Suchy 19 Mar '19

19 Mar '19

Hello, my comments: - section 4.0: Assessers should be under direct community control (voted/approved by community/members), not just defined by NCC. - section 4.0 + 7.0 should define minimal number of assessers - reported incidents (reported by web-form defined at 4.0) should be public, at least some metadata (prefix, offending ASN) to avoid duplicate reports - with indication of assessment stage on that list - Daniel On 3/19/19 1:42 PM, Marco Schmidt wrote: > Dear colleagues, > > A new RIPE Policy proposal, 2019-03, "BGP Hijacking is a RIPE Policy > Violation", is now available for discussion. > > This proposed policy is of interest to both the Anti-Abuse and Routing > working groups. The chairs of both these working groups have agreed to > keep the discussion on one single mailing list to avoid duplication, and > for formal consideration of the proposal within the RIPE Policy > Development Process. > > You are therefore requested to share your feedback on this proposal with > the Anti-Abuse mailing list. > > The goal of this proposal is to define that BGP hijacking is not > accepted as normal practice within the RIPE NCC service region. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-03 > > We encourage you to review this proposal and send your comments to > <anti-abuse-wg(a)ripe.net> before 17 April 2019. > > Kind regards, > > Marco Schmidt > Policy Officer > RIPE NCC > >

2 1

RIPE NCC Report: Law Enforcement Agency Requests 2018
by Linda Slaakweg 19 Mar '19

19 Mar '19

Dear colleagues, We have published a transparency report that details the nature of the requests we received from law enforcement agencies (LEAs) in 2018. You can find the report at: https://www.ripe.net/publications/docs/ripe-715/ <https://www.ripe.net/publications/docs/ripe-715/> Kind regards, Linda Slaakweg Legal Counsel RIPE NCC

3 2

Webzilla
by Ronald F. Guilmette 18 Mar '19

18 Mar '19

Perhaps some folks here might be interested to read these two report, the first of which is a fresh news report published just a couple of days ago, and the other one is a far more detailed investigative report that was completed some time ago now. https://www.buzzfeednews.com/article/kenbensinger/dossier-gubarev-russian-h… https://www.documentcloud.org/documents/5770258-Fti.html Please share these links widely. The detailed technical report makes it quite abundantly clear that Webzilla, and all of its various tentacles... many of which even I didn't know about until seeing this report... most probably qualifies as, and has qualified as a "bullet proof hosting" operation for some considerable time now. As the report notes, the company has received over 400,000 complaints or reports of bad behavior, and it is not clear to me, from reading the report, if anyone at the company even bothered to read any more than a small handful of those. I have two comments about this. First, I am inclined to wonder aloud why anyone is even still peering with any of the several ASNs mentioned in the report. To me, the mere fact that any of these ASNs still have connectivity represents a clear and self-evident failure of "self policing" in and among the networks that comprise the Internet. Second, its has already been a well know fact, both to me and to many others, for some years now, that Webzilla is by no means alone in the category commonly refered to as "bullet proof hosters". This fact itself raises some obvious questions. It is clear and apparent, not only from the report linked to above, but from the continuous and years-long existance of -many- "bullet proof hosters" on the Internet that there is no shortage of a market for the services of such hosting companies. The demand for "bullet proof" services is clearly there, and it is not likely to go away any time soon. In addition to the criminal element, there are also various mischevious governments, or their agents, that will always be more that happy to pay premium prices for no-questions-asked connectivity. So the question naturally arises: Other than de-peering by other networks, are there any other steps that can be taken to disincentivize networks from participating in this "bullet proof" market and/or to incentivize them to give a damn about their received network abuse complaints? I have no answers for this question myself, but I felt that it was about time that someone at least posed the question. The industry generally, and especially in the RIPE region, has a clear and evident problem that traditional "self policing" is not solving. Worse yet, it is not even discussed much, and that is allowing it to fester and worsen, over time. It would be Good if there was some actual leadership on this issue, at least from -some- quarter. So far I have not noticed any such worth commenting about, and even looking out towards the future horizon, I don't see any arriving any time soon. Regards, rfg

2 2

Re: [anti-abuse-wg] Webzilla
by Fi Shing 17 Mar '19

17 Mar '19

2 1

Re: [anti-abuse-wg] Google Privacy Abuse
by Fi Shing 16 Mar '19

16 Mar '19

3 4

Re: [anti-abuse-wg] Google Privacy Abuse
by Fi Shing 15 Mar '19

15 Mar '19

1 0

Re: [anti-abuse-wg] Google Privacy Abuse
by Fi Shing 15 Mar '19

15 Mar '19

1 0

Re: [anti-abuse-wg] Google Privacy Abuse
by Esa Laitinen 14 Mar '19

14 Mar '19

On Thu, Mar 14, 2019 at 6:05 AM ac <ac(a)main.me> wrote: > HTTPS protocol, by design, is secure and private. > > The average consumer expects this to be true. > > Google had to actually go and change, in an "under cover" way, the > entire way and method that HTTPS works. This "change" is being sold as > a "good thing" to poor people and/or people with low bandwidth and that > Google is doing a "good thing" by making this change. > Dear Andre The URLs you're accessing are also available for - your ISP - your VPN provider (unless you've rolled your own) and some information is also potentially stored by - your DNS provider And Opera browser has been doing similar things when you've enabled the bandwidth savings. or am I missing something? OK. I'm ignoring here that this particular thingi is using MITM methods to do the optimization, which is for me a bit more worrying than google having access to the URLs I browse. They have them mostly anyway. But, it is a choice a user makes, it is not forced upon them. Yours, esa -- Skype: reunaesa Yahoo: reunaesa Mobile: +4178 838 57 77

2 1

Re: [anti-abuse-wg] Google Privacy Abuse
by Cynthia Revström 14 Mar '19

14 Mar '19

How is this relevant to RIPE? - Cynthia Thu Mar 14 06:05:10 GMT+01:00 2019 ac <ac(a)main.me>: > On Wed, 13 Mar 2019 14:28:24 -0700 > "Ronald F. Guilmette" wrote: > > ac you wrote: > > >Now Google has apparently started saving, tracking and keeping all > > >https URL's that its chrome/chrome lite products use. > > And? > > If you don't like it, vote with your feet and use a different browser. > > If you have trouble finding any such, try googleing for "browser > > download". > > Oops! But I guess that would expose you to mind numbing and > > tragically horrible snooping on your private parts. > > Sorry. My bad. > > Regards, > > rfg > > P.S. My apologies to the list for indulging that which should not be > > indulged. > > > > I see that you are ignorant of what this actually means? > > Maybe their are other tech's that are also ignorant of what this really > means? > > HTTPS protocol, by design, is secure and private. > > The average consumer expects this to be true. > > Google had to actually go and change, in an "under cover" way, the > entire way and method that HTTPS works. This "change" is being sold as > a "good thing" to poor people and/or people with low bandwidth and that > Google is doing a "good thing" by making this change. > > I know already: Everything Google is not always what it seems and it is > a slippery slope. Soon Google will also be storing all Chrome https url's > > Now: Here is the REAL bad evil - that is coming to YOU (and Me) in the > future: > > So, Chrome, for its tracking, will be faster. > > User will think - ooh, faster = better. > > In all probability this is just the very first change in how local > software manages HTTPS url's and other browsers may be forced to do > similar EVIL as the user (sheep) experience of Chrome users will be > faster (the local device will now store the actual media and link it > with the stored URL) > > By our silence and by our acceptance of the method and how Google does > what it does we allow this business to dominate and control. > > One could also argue that not only is this abuse, but it is fraud. > > As many things Google is often misrepresented. > > It should be made clear to consumers that they are products. > > Society should step up and Governments should do much much more > > to protect the weak, the stupid and all the sheep. > > The Google users do not expect, understand or agree that all the > https url's they visit will be tracked, used and stored. > > And, this is why this is abuse and/or evil. > > Andre > > > >

2 1

Re: [anti-abuse-wg] Google Privacy Abuse
by Ronald F. Guilmette 14 Mar '19

14 Mar '19

ac <ac(a)main.me> you wrote: >Now Google has apparently started saving, tracking and keeping all https >URL's that its chrome/chrome lite products use. And? If you don't like it, vote with your feet and use a different browser. If you have trouble finding any such, try googleing for "browser download". Oops! But I guess that would expose you to mind numbing and tragically horrible snooping on your private parts. Sorry. My bad. Regards, rfg P.S. My apologies to the list for indulging that which should not be indulged.

2 2

Re: [anti-abuse-wg] Verification of abuse contact addresses ?
by Fi Shing 13 Mar '19

13 Mar '19

5 4

Google Privacy Abuse
by ac 13 Mar '19

13 Mar '19

Hi All, https is meant to be secure and Google pushed hard for general adoption all over the planet. The premise was that the pages users visit and user traffic would be more private. Now Google has apparently started saving, tracking and keeping all https URL's that its chrome/chrome lite products use. Google says that Cookies and other personal data is not saved on their servers. https://www.slashgear.com/chrome-lite-pages-bring-data-saver-to-https-websi… The really bad and evil part is that Google is softly softly selling the Kool-Aid (https://en.wikipedia.org/wiki/Drinking_the_Kool-Aid ) and introducing this major, bulk and brutal invasion of privacy (to all the Google sheep/products) as something "good" and saving of bandwidth etc. Yet, technically, the products with the bandwidth issue still have little benefit in trade for this brutal invasion as they still have to download over the same slow network connection... WTF! This type of abuse is also an abuse of common sense and if Google wants to milk their sheep or track their products they should do so more directly and openly so that their products know and understand what the effect of being a google product is. Instead a big play is made that Google does not store the cookies or other personal data. Wow. Andre

1 0

Constructive Approach & Anonymity (Was RE: Verification of abuse contact addresses ? )
by Brian Nisbet 11 Mar '19

11 Mar '19

Folks, We aim for constructive discussion on the mailing list at all times and I would ask everyone to bear this in mind. I very much agree with " We make this a better world by helping with advice that empowers, not with diminish comments." I would also point out that there is no requirement for legal names to be used on the mailing list and there are many reasons in this world for anonymity. As a final point to consider, the word 'lame' isn't great as it is ableist. There are many, many other suitable words in the English language that merit examination that are much better in this context. Thanks, Brian Co-Chair, RIPE AA-WG Brian Nisbet Service 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 > -----Original Message----- > From: anti-abuse-wg <anti-abuse-wg-bounces(a)ripe.net> On Behalf Of > Serge Droz via anti-abuse-wg > Sent: Friday 8 March 2019 10:54 > To: anti-abuse-wg(a)ripe.net > Subject: Re: [anti-abuse-wg] Verification of abuse contact addresses ? > > Hi > > I'm fairly new here. This is a formidable task, and not easily achieved. > So kudos to RIPE for doing this. The abuse contacts already there helped me > a lot. > > I don't appreciate people who can't even stand up with their real names, just > pointing out that others are lame. > > We make this a better world by helping with advice that empowers, not with > diminish comments. > > Cheers > Serge > > > On 08.03.19 11:40, Shane Kerr wrote: > > Fi Shing, > > > > I'm sure verifying the delivery of 70k e-mails (or however many is in > > the database) can be done in a few hours. > > > > But Marco's response mentions to *correcting* the contact addresses, > > not just verifying them. That involves working with human beings, so > > it makes sense that it will take a while. > > > > Cheers, > > > > -- > > Shane > > > > On 08/03/2019 11.07, Fi Shing wrote: > >> If it takes more than a week to verify your entire database, there is > >> the first sign that something is wrong with your system. > >> > >> > >> -------- Original Message -------- > >> Subject: Re: [anti-abuse-wg] Verification of abuse contact > >> addresses ? > >> From: Marco Schmidt <mschmidt(a)ripe.net > >> <mailto:mschmidt@ripe.net>> > >> Date: Thu, March 07, 2019 10:03 pm > >> To: "Ronald F. Guilmette" <rfg(a)tristatelogic.com > >> <mailto:rfg@tristatelogic.com>>, > >> anti-abuse-wg(a)ripe.net <mailto:anti-abuse-wg@ripe.net> > >> > >> Hello Ronald, > >> > >> We are planning to publish an updated timeline soon. > >> > >> Ultimately, our implementation will depend of the level of > >> cooperation > >> we get from LIRs and the nature of issues that need to be fixed > >> before > >> an abuse contact can be updated (for example, some organisations > >> may > >> need to reset their maintainer password). > >> > >> Over the next few weeks we will be analysing our progress, to > >> make a > >> realistic estimation. From observations so far, we think we might > >> be > >> able to finish our initial validation of all abuse contacts > >> within six > >> months - but it is still too early to make any strong predictions. > >> > >> Kind regards, > >> Marco Schmidt > >> RIPE NCC > >> > >> > >> On 05/03/2019 21:51, Ronald F. Guilmette wrote: > >> > In message <9c95c110-d5a3-e94a-6b3c-b02030736e7c(a)ripe.net > >> <mailto:9c95c110-d5a3-e94a-6b3c-b02030736e7c@ripe.net>>, > >> > Marco Schmidt <mschmidt(a)ripe.net <mailto:mschmidt@ripe.net>> > wrote: > >> > > >> >> It is correct that the implementation phase is still ongoing. > >> Currently > >> >> we are validating all the abuse contact information referenced > >> in LIR > >> >> organisation objects. Then we will proceed with the validation > >> of abuse > >> >> contacts referenced in LIR resource objects - the example that > >> you > >> >> mentioned belongs to this group. And finally all abuse > >> contacts > >> >> referenced in End User (sponsored) objects will be validated. > >> > Thanks for the info Marco. > >> > > >> > I guess the only question I would ask is this: Is there a > >> published > >> > timeline for how this whole process is planned to play out, and > >> for > >> > when it is planned to be completed? > >> > > >> > > >> > Regards, > >> > rfg > >> > > >> > >> > > > > > > -- > Dr. Serge Droz > Member of the FIRST Board of Directors Senior Advisor ICT4Peace > https://www.first.org https://www.ict4peace.org

4 3

Re: [anti-abuse-wg] Verification of abuse contact addresses ?
by Fi Shing 10 Mar '19

10 Mar '19

5 4

Re: [anti-abuse-wg] Verification of abuse contact addresses ?
by Fi Shing 08 Mar '19

08 Mar '19

4 3

Verification of abuse contact addresses ?
by Ronald F. Guilmette 07 Mar '19

07 Mar '19

Sorry folks, when this topic was discussed, I confess that I wasn't really paying much attention. So now I am forced to ask: Was someone going to verify the abuse contact addresses listed in the RIPE WHOIS data base? If so, how is that project coming along? I'll tell you why I ask. It's quite simple really. Some jerk, probably Mexican, just sent me a spam wherein he was advertising for sale his list of 18 million "business" email addreses. (I can't quite tell if those are all supposed to be specifically Mexican email addrses or what... because the spam was written in Spanish, and I don't speak Spanish.) https://pastebin.com/raw/dT11krpN Note that the specific email address of mine that was spammed was one that I only used in ancient times, and only in conjunction with my activities on one specific web site. (It obviously leaked somehow.) The envelope sender address was forged to be my own. The source IP was 109.68.33.19 as you can see. So naturally, I performed a RIPE WHOIS query on that IP address and the results I got back indicated that the contact email address for spam reports was <abuse(a)meshdigital.com>. So I emailed off a report to that address. Of course, it bounced back to me immediately as undeliverable. This causes me to suspect that either (a) that stuff that I thought that I has seen previously about a project to verify abuse addresses was all just a bunch of malarkey, or else (b) that project is still unfinished and perhaps not going all that well. Could someone please enlighten me and tell me which possibility actually applies? Regards, rfg P.s. It is annoying enough to have to lookup who the bleep should receive a report about spamming from their network _and_ to have to even write such reports, when 9 time sout of ten, the sending network could have easly prevented the spam from even going out. It is just adding insult to injury when the bloody "official" abuse reporting address doesn't even actually exist. And of course, neither meshdigital.com nor meshdigital.net even have functioning web sites. Apparently this is all the work of some dolts at a company called heg.com, in Germany. Do any of you happen to know any of the clueless nitwits who work there? If so, maybe you could put me in direct touch so that I could personally apply a much needed clue-by-four.

3 5