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

Re: [anti-abuse-wg] Defining routing abuse
by Doug Madory 13 Apr '19

13 Apr '19

> Should that also be treated as a policy violation? This is clearly intentional. I believe what’s described in the Qrator article could be a leaking route optimizer (like Noction) not a new hijack type. Doug Madory Director of Internet Analysis, Oracle @internetintel Hanover, NH +1 603-676-5067

3 5

Defining routing abuse
by Töma Gavrichenkov 12 Apr '19

12 Apr '19

Peace, This is to continue the discussion around 2019-03. Here's our today's article about the ways some operators do traffic engineering: https://radar.qrator.net/blog/new-hijack-attack-in-the-wild Should that also be treated as a policy violation? This is clearly intentional. -- Töma

3 3

2019-03
by Fernando EA. Reis 12 Apr '19

12 Apr '19

I support 2019-03. Regards, Fernando Reis CCCTII - Center for the Coordination of Communications, Information Technology and Innovation Regional Directorate for Public Works and Communications | Azores Government Rua de São Joaquim, n° 1, 9500-112 Ponta Delgada T: +351 296 206 556 | M: +351 911 966 248 | @: fernando.ea.reis(a)azores.gov.pt<mailto:fernando.ea.reis@azores.gov.pt>

1 0

On +1s and Policy Awareness
by Brian Nisbet 09 Apr '19

09 Apr '19

Colleagues, Two (broad) things to address, while, of course, noting that I would ask you all to assume best intent in all of your fellow working group members. And to post as politely as possible yourself! I have, repeatedly, pointed out that all of the emails are being read by the Co-Chairs and the RIPE PDO. Short messages of support or +1s are noted and considered, but this is not a vote. I think I've said that twice now, hopefully the third time will be enough. We have also read the opinions of people about this, however the original statement remains unchanged. If, at the appropriate points, anyone in the working group feels the Co-Chairs have erred in our decision regarding consensus, then there is an appeals process. RIPE 710 covers the whole PDP and section 4 specifically covers appeals - https://www.ripe.net/publications/docs/ripe-710 On the general awareness of the policy, the announcement on 2019-03 was posted to the Policy Announce list and to Routing-WG in addition to here. It has also been raised in a few other locations. Given where we are right now in the initial Discussion Phase and the plans by the authors to produce a v2.0 of the document, I would strongly suggest (but note that it is not certain) that nothing will have been decided by RIPE 78, when even more people will become aware. If people choose not to join the mailing list nor use the RIPE Forum to participate, then there is little the AA-WG can do. So please, especially given all the nice things people have said about the Co-Chairs, and thank you for that, can you trust that we are both seeing all of the messages and treating them as stated, and if you don't agree, there is a process by which you can express this, rather than all going back and forth again here. You can also always contact the Co-Chairs directly on aa-wg-chair(a)ripe.net 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

9 18

telia.lt: Ignoring abuse complaints (?)
by Ronald F. Guilmette 07 Apr '19

07 Apr '19

It will be wonderful when the RIPE NCC people are able to verify that all abuse reporting addresses listed in the RIPE data base are at least able to receive incoming mail. The alone, of course, will not do anything to insure that any human ever reads any message or message sent to any such e-mail address. That separate and additional issue is a whole separate can of worms. Here is an example. I just received a spam from 195.12.186.6 which is quite clearly on the network of AS47205, aka telia.lt. so I sent a polite abuse report, inclduing the full spam headers, to the <abuse(a)telia.lt> address, just as I am instructed to do by the RIPE WHOIS record for AS47205. I received back, almost immediately, the automated response appended below. This response appears to me to be saying that the managers of AS47205 are intending to 100% ignore my spam report, unless and until I ALSO take up my time to fill out their stupid web form... a web form that has a checkbox for every other kind of network abuse EXCEPT for spamming. I do not have time in my day to figure out how to fill out the eighteen million different kinds of web forms that each separate ASN has concocted in order to try to thwart and deter people from reporting simple kinds of abuse like spamming, and I will not do so. The offense in this case was committed over email, and I do not see why the REPORT of that offense should not likewise be accepted over email. For this reason, it is my hope that whoever in NCC is doing the abuse email address verification will take some steps to find out not just that the email addresses accept incoming email, but also that some actual human sits behind each one of those email addresses. Anybody can easily program what is sometimes called an "ignorebot" to send out meaningless replies to incoming mail, just s telia.lt appears to have done, but that is not a productive way to actually resolve spamming issues. Of course, it is my hope that telia.lt will rid itself of this particular troublesome customer, but in lieu of that I would be willing to accept that their abuse handler(s) have at least been made aware of the issue. But it seems that even that minimal aspiration is too much to hope for, at least for some networks. Regards, rfg =========================================================================== Return-Path: <abuse(a)telia.lt> X-Original-To: rfg(a)tristatelogic.com Delivered-To: rfg(a)tristatelogic.com Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40089.outbound.protection.outlook.com [40.107.4.89]) by segfault.tristatelogic.com (Postfix) with ESMTP id 8670F3AFF4 for <rfg(a)tristatelogic.com>; Sat, 6 Apr 2019 12:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=TelcloudLT.onmicrosoft.com; s=selector1-telia-lt; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BUSHfNh3Hp1HFJ94NFi7MR324ExTC8M6wccKAcKo8N4=; b=GQKY/rqL0A7n4AXR3t2IsqduWIhW6ki5RCosC0lBT7UnmrbHGuhOfzUAKEcyMcys3VbG2gGtYX0VzOe3gtiouJiRB6Eql1lOEsjOi8VQlt6hqD5jGj8W7v+uS0QSIpVhm/+xLarqgPfF3G3f54jc7xc41drAf3mrlnWyWkLwyQw= Received: from AM6PR10CA0088.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:209:8c::29) by DB8PR10MB3017.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:ea::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.16; Sat, 6 Apr 2019 19:39:01 +0000 Received: from AM5EUR02FT027.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::205) by AM6PR10CA0088.outlook.office365.com (2603:10a6:209:8c::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1771.16 via Frontend Transport; Sat, 6 Apr 2019 19:39:01 +0000 Authentication-Results: spf=fail (sender IP is 88.118.134.180) smtp.mailfrom=telia.lt; tristatelogic.com; dkim=none (message not signed) header.d=none;tristatelogic.com; dmarc=none action=none header.from=telia.lt; Received-SPF: Fail (protection.outlook.com: domain of telia.lt does not designate 88.118.134.180 as permitted sender) receiver=protection.outlook.com; client-ip=88.118.134.180; helo=mail.telia.lt; Received: from mail.telia.lt (88.118.134.180) by AM5EUR02FT027.mail.protection.outlook.com (10.152.8.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1771.16 via Frontend Transport; Sat, 6 Apr 2019 19:39:01 +0000 Received: from SREHCZ2.in.telecom.lt (10.75.8.219) by mail.telia.lt (10.75.128.5) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.1.1531.3; Sat, 6 Apr 2019 22:39:00 +0300 Received: from SREMBP2.in.telecom.lt ([fe80::3d26:8437:9e0d:59e8]) by srehcz2.in.telecom.lt ([::1]) with mapi id 14.03.0439.000; Sat, 6 Apr 2019 22:39:00 +0300 From: Abuse <abuse(a)telia.lt> To: "Ronald F. Guilmette" <rfg(a)tristatelogic.com> Subject: Auto reply Thread-Topic: Auto reply Thread-Index: AdTssGDyKWhhEYekSwaq/rd/nOkgpQAAAACd Date: Sat, 6 Apr 2019 19:38:58 +0000 Message-ID: <EFBD252184E6D64D98235891A1404040520D6A18(a)SREMBP2.in.telecom.lt> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Original-Content-Type: multipart/alternative; boundary="_000_EFBD252184E6D64D98235891A1404040520D6A18SREMBP2inteleco_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:88.118.134.180;IPV:NLI;CTRY:LT;EFV:NLI;SFV:NSPM;SFS:(10009020)(376002)(346002)(136003)(39860400002)(396003)(2980300002)(1110001)(1109001)(339900001)(199004)(189003)(126002)(246002)(478600001)(8936002)(7596002)(336012)(476003)(356004)(74482002)(86362001)(8676002)(55846006)(66574012)(84326002)(6916009)(7116003)(186003)(486006)(221733001)(2906002)(85426001)(790700001)(7636002)(14444005)(33656002)(26005)(6306002)(37786003)(606006)(3480700005)(102836004)(9686003)(54896002)(5660300002)(236005)(106466001)(55016002)(105606002)(7696005)(316002)(71190400001)(16586007);DIR:OUT;SFP:1101;SCL:1;SRVR:DB8PR10MB3017;H:mail.telia.lt;FPR:;SPF:Fail;LANG:lt;PTR:mail.telia.lt;A:1;MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 77402847-696c-4e25-3856-08d6bac784f7 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328);SRVR:DB8PR10MB3017; X-MS-TrafficTypeDiagnostic: DB8PR10MB3017: X-MS-Exchange-PUrlCount: 2 X-Microsoft-Antispam-PRVS: <DB8PR10MB30178C5AEE8B4F4C7684FC76D9520(a)DB8PR10MB3017.EURPRD10.PROD.OUTLOOK.COM> X-Forefront-PRVS: 0999136621 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: 3QvdDu+iGHWCuMAjA7Vsqh3dV6p7pGf9MiaOlzahoG6BPUMJp5h8WeIYR//QoivGPneeomCWEtbWoocikmV1Wvyl0bxwER743nquRh400IfAT84z1GDcDNkwLs8QXhFfqeQAKmewe2FWU6f1ZJL3MK/Mf06/iAqlD4DixZEOJr2+VDsK+QvfU8g9cKmuXj3lLCokHDFqtRLWKQ5I3SuxFEMdNqwxy21RSp2dbRr6EIE/oSwZBKMm2B1Q3MOS3xUs0lhMBFysEVGFroOu0BB1ShE+GMwpndqVwFRG97MANcQS0y8kDdM9yKShaim0ASPluky+53gXVcer+1bWHauQpcqb2/omkPRE3zr/XOKa3xtrb0sQhM7jjj9k2l0ummiGa3cYRuCTYgyb7lk8bes1tV5ynH7NTChvD9BvH58g4ik= X-OriginatorOrg: telia.lt X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2019 19:39:01.0365 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 77402847-696c-4e25-3856-08d6bac784f7 X-MS-Exchange-CrossTenant-Id: 8f113f62-2414-4adb-b94d-b6fc780129ae X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8f113f62-2414-4adb-b94d-b6fc780129ae;Ip=[88.118.134.180];Helo=[mail.telia.lt] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR10MB3017 Sveiki, Dëkojame uþ þinutæ. Ðiuo adresu gauname daug ávairiø praneðimø. Tam, kad galëtume operatyviai iðspræsti Jûsø klausimà, praðome skirti minutæ ir patikslinti klausimà, dël kurio kreipiatës. Praðome uþpildyti trumpà anketà<https://www.telia.lt/abuse>, kuri padës mums greièiau ir tiksliau Jums atsakyti. Pagarbiai Telia Hello, Thank You for your message. We receive many different messages to this address. In order to handle your question, we are kindly requesting you to spend a minute of your time and to specify your question. Please fill in a short questionnaire<https://www.telia.lt/abuse/en>, which will help us to give a prompter and more accurate reply to your question. Kind regards, Sveiki, Dekojame uz zinute. Siuo adresu gauname daug ivairiu pranesimu. Tam, kad galetume operatyviai isspresti Jusu klausima, prasome skirti minute ir patikslinti klausima, del kurio kreipiates. Prasome uzpildyti trumpa [1]anketa, kuri pades mums greiciau ir tiksliau Jums atsakyti. Pagarbiai Telia Hello, Thank You for your message. We receive many different messages to this address. In order to handle your question, we are kindly requesting you to spend a minute of your time and to specify your question. Please fill in a short [2]questionnaire, which will help us to give a prompter and more accurate reply to your question. Kind regards, Telia References 1. https://www.telia.lt/abuse 2. https://www.telia.lt/abuse/en

2 2

213.0.0.0/8 and AS12445 (selenebs.it aka "A2A Smart City S.P.A"/Italy)
by Ronald F. Guilmette 07 Apr '19

07 Apr '19

I guess that I have a lot to learn yet about routing. Maybe some of you folks will yet again take pity on me and explain this to me. >From where I am sitting it appears that AS12445 is announcing a route to all of 213.0.0.0/8. (I only happened to find out about this because, as it happens there are some spamming inside of 213.0.0.0/8.) Anyway, this is my reference source: https://bgp.he.net/AS12445#_prefixes I did think that I should try to just email the official contacts AS12445 privately to inquire about this, and so I sent email to all three of the contact email addresses listed in the RIPE WHOIS record for AS12445, but as you can all see below, that didn't really work out very well. Anyway, this doesn't seem to be such a great idea, security-wise, i.e. to allow random network to announce routes to entire /8s (or larger) that don't actually belong to them. It is hard for me to tell how long this has been ongoing in the case of this specific prefix and this specific ASN. If anyone else can illuminate me regarding that, then I would appreciate it. ------- Forwarded Message Return-Path: <> X-Original-To: rfg(a)tristatelogic.com Delivered-To: rfg(a)tristatelogic.com Received: by segfault.tristatelogic.com (Postfix) id 323DF3AFF4; Sat, 6 Apr 2019 22:57:35 -0700 (PDT) Date: Sat, 6 Apr 2019 22:57:35 -0700 (PDT) From: MAILER-DAEMON(a)tristatelogic.com (Mail Delivery System) Subject: Undelivered Mail Returned to Sender To: rfg(a)tristatelogic.com Auto-Submitted: auto-replied MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="8E09A3AEF2.1554616655/segfault.tristatelogic.com" Message-Id: <20190407055735.323DF3AFF4(a)segfault.tristatelogic.com> This is a MIME-encapsulated message. - --8E09A3AEF2.1554616655/segfault.tristatelogic.com Content-Description: Notification Content-Type: text/plain; charset=us-ascii This is the mail system at host segfault.tristatelogic.com. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system <galasso(a)selenebs.it>: host selenebs-it.mail.protection.outlook.com[104.47.10.36] said: 550 5.4.1 [galasso(a)selenebs.it]: Recipient address rejected: Access denied [DB5EUR03FT051.eop-EUR03.prod.protection.outlook.com] (in reply to RCPT TO command) <gvinetti(a)selenebs.it>: host selenebs-it.mail.protection.outlook.com[104.47.10.36] said: 550 5.4.1 [gvinetti(a)selenebs.it]: Recipient address rejected: Access denied [DB5EUR03FT051.eop-EUR03.prod.protection.outlook.com] (in reply to RCPT TO command) - --8E09A3AEF2.1554616655/segfault.tristatelogic.com Content-Description: Delivery report Content-Type: message/delivery-status Reporting-MTA: dns; segfault.tristatelogic.com X-Postfix-Queue-ID: 8E09A3AEF2 X-Postfix-Sender: rfc822; rfg(a)tristatelogic.com Arrival-Date: Sat, 6 Apr 2019 22:57:32 -0700 (PDT) Final-Recipient: rfc822; galasso(a)selenebs.it Original-Recipient: rfc822;galasso(a)selenebs.it Action: failed Status: 5.4.1 Remote-MTA: dns; selenebs-it.mail.protection.outlook.com Diagnostic-Code: smtp; 550 5.4.1 [galasso(a)selenebs.it]: Recipient address rejected: Access denied [DB5EUR03FT051.eop-EUR03.prod.protection.outlook.com] Final-Recipient: rfc822; gvinetti(a)selenebs.it Original-Recipient: rfc822;gvinetti(a)selenebs.it Action: failed Status: 5.4.1 Remote-MTA: dns; selenebs-it.mail.protection.outlook.com Diagnostic-Code: smtp; 550 5.4.1 [gvinetti(a)selenebs.it]: Recipient address rejected: Access denied [DB5EUR03FT051.eop-EUR03.prod.protection.outlook.com] - --8E09A3AEF2.1554616655/segfault.tristatelogic.com Content-Description: Undelivered Message Content-Type: message/rfc822 Return-Path: <rfg(a)tristatelogic.com> Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 8E09A3AEF2; Sat, 6 Apr 2019 22:57:32 -0700 (PDT) From: "Ronald F. Guilmette" <rfg(a)tristatelogic.com> To: gvinetti(a)selenebs.it, galasso(a)selenebs.it, abuse(a)selenebs.it Subject: 213.0.0.0/8 Date: Sat, 06 Apr 2019 22:57:32 -0700 Message-ID: <32415.1554616652(a)segfault.tristatelogic.com> Greetings, I waas wondering if you people could explain to me why your ASN (AS12445) announcing a route at all of 213.0.0.0/8. I don't think that your network has been assigned that entire huge block of IPv4 addresses or that all of that IPv4 space belongs to you. Do you disagree? https://bgp.he.net/AS12445#_prefixes - --8E09A3AEF2.1554616655/segfault.tristatelogic.com-- ------- End of Forwarded Message

2 2

Speaking of routing funny business... what's up with AS65021?
by Ronald F. Guilmette 06 Apr '19

06 Apr '19

Apparently, not all routing funny business involves hijacked IP address space. I was just doing some preliminary testing of a tool which I hope will allow me to automate more of my spam reporting process. I don't like to report spam to the registered owner of the smallest containing IP address block of the spam source because a substantial fraction of the time, those are the very people actually doing the spamming. So I prefer instead to send spam reports to the designated abuse contacts for the entire relevant ASN. Fortunately, these days, for most RIPE and ARIN ASNs at least, the relevant abuse reporting address for any given ASN is easy to obtain, and obtaining those email addresses may be done in a fully automated fashion from the relevant ASN WHOIS records. But as I have only just now learned, while I was doing preliminary testing on my simple software tool, there are some exceptional cases where mapping an ASN to a corresponding abuse reporting address becomes problematic. Specifically, I have noticed some spammers cammped out on a block of IPv4 addresses that are currently routed by AS65021. The whois.iana.org WHOIS server tells me that this is a reserved ASN, and that it doesn't actually belong to anybody at all. Thus, my rather simple Perl script which attempts to find a proper reporting email address for this one specific spammer infestation fails rather horribly. The CIDRs currently being routed by AS65021 are: 31.13.210.0/24 31.13.241.0/24 87.120.104.0/24 87.120.253.0/24 87.120.255.0/24 87.121.116.0/24 93.123.64.0/24 216.99.221.0/24 (seen by bgp.he.net) Some of these have been routed by (bogus) AS65021 since 2018-12-03. All of those CIDRs are properly registered to cloudware.bg except for the last one which is registered to International Payout Systems Inc. (Florida). Apparently, cloudware.bg is part of Neterra, Ltd. of Bulgaria (AS34224): https://www.cloudware.bg/en/about "As part of Neterra..." I would say that this is just a very temporary mishap, and a temporary "fat fingered" anomaly if it were not for the fact that some of these routes have, according to RIPE Rotuing History, been countinuously announced for over four full months now. Can anyone explain this to me? Please? I have more than a little trouble understanding why a company like Neterra, Ltd., which -does- already have its very own ASN (AS34224), feels the need to effectively steal a reserved ASN for their own private use. Are new AS numbers really all that expensive in the RIPE region, so that some businesses might be motivated to save some money by just grabbing onto one of the reserved ones? None of this makes particularly much sense, but I do plan to send email to Neterra, Ltd. in order to ask them what the devil goes on here. Mostly, I am just reporting theis here as a sort of indirect way of asking other people on the list for their opinions about Neterra, Ltd. of Bulgaria. Is that compaony in the habit of doing routing funny business? For my own part, all I can say is that this is certainly not the first time that I have encountered that company name... and not in a good way. Regards, rfg

3 3

Re: [anti-abuse-wg] anti-abuse-wg Digest, Vol 89, Issue 15
by Karl-Josef Ziegler 05 Apr '19

05 Apr '19

> Also I would to remind all the community that usually what happens to > communities that cannot regulate themselves is that some outsider comes > and regulated them... Yes, this is also my opinion. The community should do something against this abusive behavior. If it isn't done by the community there might be some regulation coming from outside, i.e. political entities. And I doubt that this will be the better way to handle this problem. Best regards, Karl-Josef

9 16

Re: [anti-abuse-wg] On +1s and Policy Awareness AND Astro... something...
by Gert Doering 05 Apr '19

05 Apr '19

Hi, On Fri, Apr 05, 2019 at 01:33:52PM +0000, Suresh Ramasubramanian wrote: > Using mutt and elm and conventions on what you call TOFU sort of faded into the past with mutt and tin but anyway once I get in front of a laptop with a reasonable mail client I will certainly follow that charmingly old fashioned style. I do have mutt available for use. > > Yes. We won't get unanimous agreement on this. Hence rough consensus. I'm not saying that this nice and wonderful new-style quoting does not have its place. What I am saying is "if everyone *else* is using a given style, just ignoring local conventions and doing your personal preference is unconsiderate and rude". 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

1 0

Re: [anti-abuse-wg] Astroturfing?
by Suresh Ramasubramanian 04 Apr '19

04 Apr '19

It doesn't matter, mate. We are all astroturfers eh. +1. On 04/04/19, 10:36 AM, "anti-abuse-wg on behalf of ac" <anti-abuse-wg-bounces(a)ripe.net on behalf of ac(a)main.me> wrote: +1 (and if the +1 is not clear: It means I agree and I have nothing to add. If I am pressed to add a comment, to explain my +1 I would venture to say that I agree with what was said because I know there are very few people actively tracking BGP jacking. I also know that some of those that do track it have spoken out so I agree completely that identifying experts and testimony of actual cases will not be one of the top issues faced by the registry. I hope that my +1 will therefore be accepted as a simple +1 as I have nothing more to add than simply repeating what has been said and stating my agreement thereof. If my +1 is not acceptable or does not count as much, because I have not fully explained my agreement to what was said I would appreciate that being pointed out to myself) On Wed, 03 Apr 2019 19:57:35 +0530 Suresh Ramasubramanian <ops.lists(a)gmail.com> wrote: > There are very few people who actively track BGP hijacks, the world > over - even among the larger community of network security folks. > > More than one of those individuals is on this mailing list and has > spoken up during the discussion. > > Identifying experts to detect and attest to cases of hijacking will > be the least of RIPE NCC's problems. > > On 03/04/19, 7:50 PM, "anti-abuse-wg on behalf of Pavel Vraštiak" > <anti-abuse-wg-bounces(a)ripe.net on behalf of vrastiak(a)itself.cz> > wrote: > > I, for instance, subscribed to this list to express my support > for the proposal. After reviewing the comments I can say that the > only thing that we can (hopefully) agree on is that BGP hijacks are > generally bad and we would prefer technical solution instead of > policy. > I think that the idea of this proposal is good and I also think > that it could make some small difference (in a good way). The > questionable part is the process of choosing experts and impact on > the RIPE NCC budget. Looking forward to v2.0. > > -- > > Pavel > > On 03. 04. 19 15:21, Sascha Luck [ml] wrote: > > On Wed, Apr 03, 2019 at 12:52:45PM +0100, Carlos Friaas via > > anti-abuse-wg wrote: > >> Just like a few days ago i wrote that i hoped there wasn't any > >> kind of discrimination against portuguese participants, i hope > >> there isn't also any kind of discrimination against new > >> participants on this WG. > > > > Please provide evidence for your insinuation that anyone here > > discriminates against Portuguese (or any other nationality for > > that matter.) I can't but regard such an insinuation as a cheap > > rhetorical trick. > > > >> I may understand if some people prefer to have less people in > >> the WG, but i'm not part of that set. > >> While worrying about how we can improve rules/tools against > >> Abuse (that's the point of an Anti-Abuse WG, right?), i would > >> also like to see a much larger number of people involved! > > > > I've long argued that all policy should only be discussed in > > ap-wg as I don't think this limited an audience should make > > policy with far-reaching consequences. Alas, everyone wants to > > rule in Hell rather than serve in Heaven. > > > >> If someone has any doubt about if newcomers are real persons, > >> then please Google away. :-) > > > > Well, that gives me: > > https://en.wikipedia.org/wiki/Sockpuppet_(Internet)#Meatpuppet > > > > So the term "Astroturfing" is technically incorrect as that > > implies fictitious entities with some commercial interest behind > > it. > > Nobody has said that and new participants are always welcome, > > the more know about this the better. > > However: If someone shows up here only to add a "+1" to a > > proposal and is then never heard from again, I don't think their > > support should carry much weight. I trust the chairs to consider > > this, of course. > > > > > > rgds, > > SL > >> > >> > >> > >> > >> On Wed, 3 Apr 2019, Michele Neylon - Blacknight wrote: > >> > >>> All > >>> > >>> Is someone encouraging astroturfing? > >>> > >>> The number of either new or inactive members of this list who > >>> have posted one line messages in support of the recent policy > >>> discussion has reached insane levels > >>> > >>> Regards > >>> > >>> Michele > >>> > >>> -- > >>> Mr Michele Neylon > >>> Blacknight Solutions > >>> Hosting, Colocation & Domains > >>> https://www.blacknight.com/ > >>> https://blacknight.blog/ > >>> Intl. +353 (0) 59 9183072 > >>> Direct Dial: +353 (0)59 9183090 > >>> Personal blog: https://michele.blog/ > >>> Some thoughts: https://ceo.hosting/ > >>> ------------------------------- > >>> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside > >>> Business Park,Sleaty > >>> Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: > >>> 370845 > >>> > >>> > > > > > > > > >

2 1