Fwd: [stat-dev] RIPE routing registry (ab)used to legitimize prefix hijacks
Dear colleagues, maybe this is something you could find time to discuss at today's face-to-face meeting. I believe the points Rene raises are worth considering. I do not have a concrete proposal how to improve this undesirable state of things. Of course RPKI is the a better tool. But do we need to do something here before it is deployed widely? Daniel -------- Forwarded Message -------- Subject: [stat-dev] RIPE routing registry (ab)used to legitimize prefix hijacks Date: Thu, 06 Nov 2014 01:32:29 +0100 From: Rene Wilhelm <wilhelm@ripe.net> ... As per the below message from nanog.org list, AS201640 is hijacking a total of eleven routes to IP space scattered all over the world... none of which appears to belong to anybody in or near Bulgaria. Interestingly, as shown in the RIPEstat AS routing consistency widget[*], some of the announcements get a touch of legitimacy by corresponding route objects in the RIPE routing registry; because the IP space is from other RIRs (apnic, afrinic), the usual checks for hierarchical authorization do not apply and hijackers can fool RIPE DB users, claim AS201640 is allowed to originate the hijacked prefixes. Is there anything we can do about that? remove the rogue objects? disallow new route objects with origin AS201640 in non-RIPE space? Do the RIPE DB terms and conditions have clauses which deal with entering false information? Even if it has no impact on the hijack in progress, I think it helps quality and reputation of RIPE routing registry if we act on dubious, most likely false, entries which are brought to our attention. -- Rene [*] https://stat.ripe.net/widget/as-routing-consistency#w.resource=AS201640 -------- Original Message -------- Return-path: <nanog-bounces@nanog.org> Envelope-to: wilhelm@ripe.net Delivery-date: Wed, 05 Nov 2014 23:00:02 +0100 Received: from koko.ripe.net ([193.0.19.72]) by titi.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from <nanog-bounces@nanog.org>) id 1Xm8cT-0008Am-OP; Wed, 05 Nov 2014 23:00:01 +0100 Received: from mail.nanog.org ([2001:1838:2001:8::10]) by koko.ripe.net with esmtp (Exim 4.72) (envelope-from <nanog-bounces@nanog.org>) id 1Xm8cS-0002Ry-LF; Wed, 05 Nov 2014 23:00:01 +0100 Received: from mail.nanog.org (localhost [127.0.0.1]) by mail.nanog.org (Postfix) with ESMTP id 9D2632D41A9; Wed, 5 Nov 2014 21:59:24 +0000 (UTC) X-Original-To: nanog@nanog.org Delivered-To: nanog@nanog.org Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mail.nanog.org (Postfix) with ESMTP id C10362D415F for <nanog@nanog.org>; Wed, 5 Nov 2014 21:59:17 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 297803AF26 for <nanog@nanog.org>; Wed, 5 Nov 2014 13:59:17 -0800 (PST) From: Ronald F. Guilmette <rfg@tristatelogic.com> To: nanog@nanog.org Subject: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud Date: Wed, 05 Nov 2014 13:59:17 -0800 Message-ID: <81757.1415224757@server1.tristatelogic.com> X-BeenThere: nanog@nanog.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: North American Network Operators Group <nanog.nanog.org> List-Unsubscribe: <http://mailman.nanog.org/mailman/options/nanog>, <mailto:nanog-request@nanog.org?subject=unsubscribe> List-Archive: <http://mailman.nanog.org/pipermail/nanog/> List-Post: <mailto:nanog@nanog.org> List-Help: <mailto:nanog-request@nanog.org?subject=help> List-Subscribe: <http://mailman.nanog.org/mailman/listinfo/nanog>, <mailto:nanog-request@nanog.org?subject=subscribe> Errors-To: nanog-bounces@nanog.org Sender: "NANOG" <nanog-bounces@nanog.org> X-RIPE-Spam-Level: + X-RIPE-Spam-Report: Spam Total Points: 1.5 points pts rule name description ---- ---------------------- ------------------------------------ -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 4.0 DCC_CHECK Detected as bulk mail by DCC (dcc-servers.net) X-RIPE-Signature: b6ab524b1e2ef58d696cc0c68bdb4d998c7e56c7a3ace7a0c536a4fd780385ef I already posted about this rogue AS days ago, but nothing has really changed much, since then, with respect to its hijacking of IP space. Well, at least Brian Krebs was kind anough to write about it: http://krebsonsecurity.com/2014/11/still-spamming-after-all-these-years/ (Please note that that is a convicted felon spamming from the hijacked IP space. He's not allowed to own firearms, but he _can_ apparently own a keyboard.) As of today, AS201640 is still hijacking a total of eleven routes to IP space scattered all over the world... none of which appears to belong to anybody in or near Bulgaria. In fact, it would appear that the organization that is the registrant of AS201640 currently has exactly -zero- IP addresses to call its own. Nobody in a postion to _do_ anything about this gives a darn? As of today: 36.0.56.0/21 41.92.206.0/23 41.198.80.0/20 41.198.224.0/20 61.242.128.0/19 119.227.224.0/19 123.29.96.0/19 177.22.117.0/24 177.46.48.0/22 187.189.158.0/23 202.39.112.0/20
Daniel,
maybe this is something you could find time to discuss at today's face-to-face meeting. I believe the points Rene raises are worth considering. I do not have a concrete proposal how to improve this undesirable state of things. Of course RPKI is the a better tool. But do we need to do something here before it is deployed widely?
I'd be happy to try to find some time to discuss this during the AOB. It is a topic that came up before, presented by George Michelson, and more discussion would be welcome. Is there anybody that would like to speak to it? Rob
+1 Generic passwords for Maintainer objects...is an issue... On Thu, Nov 6, 2014 at 9:26 AM, Rob Evans <rhe@nosc.ja.net> wrote:
Daniel,
maybe this is something you could find time to discuss at today's face-to-face meeting. I believe the points Rene raises are worth considering. I do not have a concrete proposal how to improve this undesirable state of things. Of course RPKI is the a better tool. But do we need to do something here before it is deployed widely?
I'd be happy to try to find some time to discuss this during the AOB. It is a topic that came up before, presented by George Michelson, and more discussion would be welcome. Is there anybody that would like to speak to it?
Rob
-- Kindest regards, Tom Smyth Mobile: +353 87 6193172 --------------------------------- PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL This email contains information which may be confidential or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify me by telephone or by electronic mail immediately. Any opinions expressed are those of the author, not the company's .This email does not constitute either offer or acceptance of any contractually binding agreement. Such offer or acceptance must be communicated in writing. You are requested to carry out your own virus check before opening any attachment. Thomas Smyth accepts no liability for any loss or damage which may be caused by malicious software or attachments.
participants (3)
-
Daniel Karrenberg -
Rob Evans -
Tom Smyth