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

Mysteries of the Internet: AS65000
by Ronald F. Guilmette 15 Apr '19

15 Apr '19

As I believe I have made abundantly clear, I am in favor of the proposal 2019-03, and more generally, I am supportive of the notion that order is preferable to chaos, particularly when it comes to routing on the Internet. The reasons for this preference of mine are so manifest that they do not even warrant recitation here. My hope is that I have made Carlos and Jordi aware, via my postings here, of at least some of the particular points on which we may differ, and which I would like to see changed in the next draft of 2019-03. There is one important point of disagreement on which I have not yet spoken however, and that is Carlos' belief, which may or may not be shared also by Jordi, that I personally qualify as an "expert" (for purposes of 2019-03) simply because I have, in some small number of instances, become aware of what have appeared to be quite deliberate and malevolent hijackings. I need to state for the record that this is just wrong. I am NOT an "expert" with regard to Internet routing, either legitimate or otherwise. I do not run a network. Nor have I ever done so, with the only exception being my own tiny little network here at home . I do not own any equipment that speaks BGP, nor have I ever done so. I am just a simple end-luser who has been mad as hell about spammers for about the past 20 years, and who has simply educated himself, as best as he could, to follow clues and to try to figure how what the spammers are doing and how they are doing it. In this process, I have been required to learn a small bit about routing along the way, but that does not in any sense qualify me as an "expert" in the area of Internet routing. In fact, there are and have been, up to and including the present day, things that I see happening on the Internet that make absolutely no sense to me whatsoever, and that I cannot for the life of me explain. I have just seen one such thing today, and I would like to ask those on this list who actually -are- qualified experts to please explain it to me, because all I see here is a mystery wrapped inside of a riddle and stuffed inside of an enigma. Here is what I am hoping some actual expert can explain to me: https://bgp.he.net/AS65000#_asinfo https://bgp.he.net/AS65000#_prefixes https://bgp.he.net/AS65000#_prefixes6 https://bgp.he.net/AS65000#_peers https://bgp.he.net/AS65000#_peers6 I will save all further comment until someone offers me some kind of an explanation of this apparently strange stuff. For now, I will only add that whereas bgp.he.net is showing there as being a total of 66 IPv4 prefixes announced by this (reserved) ASN, the data I am getting from RIPEstat is indicating a much smaller number of IPv4 announcements (35). Either way, I am unable to fathom how and why a reserved ASN should be announcing -anything- at -any- place or point where anybody on the outside can see it. (And at least some of those blocks -can- be successfully tracerout'd to from where I am sitting here in California, so this is by no means a merely local phenomenon.) The only other thing I feel compelled to say, or ask right now, is just this: Who should I be notifying if there is an issue with this ASN? It has no WHOIS reords, and thus, no contacts... no email addresses, no phone numbers, no snail-mail addresses. Nothing... ... and yet this thing has, according to bgp.he.net, no fewer than 27 IPv4 peers and another 2 for IPv6 only! I await an explanation from some actual expert. For myself, I can only say that none of this makes a damn bit of sense to me. But I am willing and eager to be educated. Regards, rfg P.S. If I have seems self-effacing about the limits of my knowledge above, that was entirely intentional and deliberate. Upon looking at this case of AS65000, I was convinced rather quickly that something is horribly wrong here. But trying to figure out who should be held accountable for this mess is, I confess, utterly beyond me.

5 8

Re: [anti-abuse-wg] Mysteries of the Internet: AS65000
by Suresh Ramasubramanian 15 Apr '19

15 Apr '19

Let us put it this way. There might be several simultaneous leaks of this same private asn because multiple country netblocks are being announced. Or this is actually malicious. I have no way to tell without checking what abuse is coming from there. I'm sure RFG is researching that part of it, and won't ask him about it till he's ready to disclose. On 15/04/19, 10:02 AM, "anti-abuse-wg on behalf of ac" <anti-abuse-wg-bounces(a)ripe.net on behalf of ac(a)main.me> wrote: On Mon, 15 Apr 2019 09:40:35 +0530 Suresh Ramasubramanian <ops.lists(a)gmail.com> wrote: > On 15/04/19, 9:26 AM, "anti-abuse-wg on behalf of ac" > <anti-abuse-wg-bounces(a)ripe.net on behalf of ac(a)main.me> wrote: > > Sorry for top posting, but I fail to see how any of this is > > abuse related? > > Given that it is RFG raising this, I think it is a pretty safe bet > that this ASN is associated with some abusive activity that he has > seen. > Okay, but this is not yet clear? pvt asn is leaked often (and sometimes voluminous) - so is common/frequent and in itself means nothing, if this is that, - but as this affects that network, there is no abuse? or I am missing something?

1 0

Re: [anti-abuse-wg] Mysteries of the Internet: AS65000
by Ángel González Berdasco 15 Apr '19

15 Apr '19

Well, someone is announcing those prefixes as linked to AS65000. If he itself was using AS65000 internally with those prefixes, and that leaked to their public interface, it would be a false positive, but lacking some agreement between the receiver and their peer involving AS65000, imho those entries were used internally by some party, which then inadvertently shared them to peers that didn't filter it, etc. With the end result that such entries could made these prefixes unreachable. Here, one side will be the owners of those ip ranges, but there's not an owner of the AS as such. Who should be complaining that they are 'advettising their AS' incorrectly? What if a prefix was 10.0.0.0/8 ? Would IANA need to state that it didn't allow AS x to advertise a private range? Maybe that step should be skipped for reserved ranges. Most likely, this case is a self-inflicted damage, though. Best regards

2 1

Re: [anti-abuse-wg] telia.lt: Ignoring abuse complaints (?)
by Fi Shing 13 Apr '19

13 Apr '19

2 1

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

Astroturfing?
by Michele Neylon - Blacknight 04 Apr '19

04 Apr '19

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

10 18

2019-03
by GEANTY Damien (RIC-CH) 03 Apr '19

03 Apr '19

I support 2019-03. Regards, Damien Geanty Cyber Specialist | Richemont International SA ________________________________ Chemin de la Chênaie 50 | CP30 | 1293 Bellevue, Genève | Switzerland (tel) +41227213000 | (direct) +41225811161 | (mobile) +41791385643 (email) damien.geanty(a)richemont.com<mailto:damien.geanty@richemont.com> © 2019 Richemont International SA. All Rights Reserved The information contained in this e-mail message is confidential - please do not cross-post. This communication is intended for the use of the addressee(s) only. If you are not the intended recipient, you are hereby notified that any review, reliance, disclosure, distribution or copying of this communication may be prohibited by law and might constitute a breach of confidence. If you have received this communication in error, please notify us immediately and delete it and all copies (including attachments) from your system.

3 2

I support 2019-03
by TRAILL Neville (RIC-US) 03 Apr '19

03 Apr '19

Dear RIPE NCC I support 2019-03. Neville Traill Cyber Specialist | Richemont North America, Inc. ________________________________ 3 Enterprise Drive | Shelton CT 06484 | United States (tel) +12039256400 | (direct) +18177852548 (email) neville.traill(a)richemont.com<mailto:neville.traill@richemont.com> (c) 2019 Richemont North America, Inc.. All Rights Reserved The information contained in this e-mail message is confidential - please do not cross-post. This communication is intended for the use of the addressee(s) only. If you are not the intended recipient, you are hereby notified that any review, reliance, disclosure, distribution or copying of this communication may be prohibited by law and might constitute a breach of confidence. If you have received this communication in error, please notify us immediately and delete it and all copies (including attachments) from your system.

3 2

I support 2019-03
by FONG Eddie (RIC-HK) 03 Apr '19

03 Apr '19

I support 2019-03 Eddie Fong CYBER SPECIALIST | Richemont Asia Pacific Ltd ________________________________ 909 Cheung Sha Wan Road | Kowloon | Hong Kong (direct) +85225322912 (email) eddie-ht.fong(a)richemont.com<mailto:eddie-ht.fong@richemont.com> (c) 2019 Richemont Asia Pacific Ltd. All Rights Reserved The information contained in this e-mail message is confidential - please do not cross-post. This communication is intended for the use of the addressee(s) only. If you are not the intended recipient, you are hereby notified that any review, reliance, disclosure, distribution or copying of this communication may be prohibited by law and might constitute a breach of confidence. If you have received this communication in error, please notify us immediately and delete it and all copies (including attachments) from your system.

1 0

I support 2019-03
by HUEN Jason (RIC-HK) 03 Apr '19

03 Apr '19

I support 2019-03 (c) 2019 Richemont Asia Pacific Ltd. All Rights Reserved The information contained in this e-mail message is confidential - please do not cross-post. This communication is intended for the use of the addressee(s) only. If you are not the intended recipient, you are hereby notified that any review, reliance, disclosure, distribution or copying of this communication may be prohibited by law and might constitute a breach of confidence. If you have received this communication in error, please notify us immediately and delete it and all copies (including attachments) from your system.

1 0

I support 2019-03
by furio ercolessi 03 Apr '19

03 Apr '19

Me too. Furio Ercolessi

1 0

Re: [anti-abuse-wg] I support 2019-03
by Fi Shing 02 Apr '19

02 Apr '19

1 0

I support 2019-03
by MATASCI Andrea (RIC-CH) 02 Apr '19

02 Apr '19

I support 2019-03 © 2019 Richemont International SA. All Rights Reserved The information contained in this e-mail message is confidential - please do not cross-post. This communication is intended for the use of the addressee(s) only. If you are not the intended recipient, you are hereby notified that any review, reliance, disclosure, distribution or copying of this communication may be prohibited by law and might constitute a breach of confidence. If you have received this communication in error, please notify us immediately and delete it and all copies (including attachments) from your system.

1 0

2019-03
by FERREIRA DE OLIVEIRA Edgar (RIC-CH) 02 Apr '19

02 Apr '19

I support 2019-03 Regards, Edgar Oliveira © 2019 Richemont International SA. All Rights Reserved The information contained in this e-mail message is confidential - please do not cross-post. This communication is intended for the use of the addressee(s) only. If you are not the intended recipient, you are hereby notified that any review, reliance, disclosure, distribution or copying of this communication may be prohibited by law and might constitute a breach of confidence. If you have received this communication in error, please notify us immediately and delete it and all copies (including attachments) from your system.

1 0

Re: [anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)
by Ángel González Berdasco 02 Apr '19

02 Apr '19

Let's use a less loaded analogy than a gun store :-) Suppose we are dealing with a logistics company that uses stolen lorries/trucks. May their use of stolen vehicles potentially affect their carrier license? Note that, even if after many months of processes the agreement with the rir was terminated and the AS taken back, still that does not preclude the company from having ip addresses or having access to the internet. I expect the next draft not to rely on a single expert, but a panel of 3 experts (plus then the appealing phase). Would that solve your concerns? > Blocking content distribution methods is > effectively blocking the content itself. If your > newspaper was unable to print and distribute > their news because their electricity had been > shut off (for anything outside of nonpayment), > it would still be considered censorship. No. The newspaper may pay its electricity punctually, yet be required to have its electrical power shut off. A good example of that would be non-compliance with the local electricity regulation, which may range from an install so bad that could cause a fire to simply having an old meter which doesn't support real-time reading Should the action against the above-mentioned logistics company differ if it was used for delivery by a newspaper? You raise a good point that the allowance of reports by the general public could lead to attacks against 'unpopular' entities (such as a certain political party) by means of fake reports. However, given that it has to be based on technical facts, I'm not sure if that's already enough or there should be some additional speedy path in the proposal for them to be discarded (and where to put the line?). Ángel

1 0

Proposal 2019-03 BGP Hijacking
by Vitor Leitao 01 Apr '19

01 Apr '19

I would like to manifest my support to the proposal 2019-03. Rgds, Vitor Leitao

8 8