<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<div>Hi Florian, NANOG, </div>
<div><br>
</div>
<div>While the symptom of (automatically) proxy registered route objects is problematic, perhaps we could also take this opportunity to discuss the underlying issue: we as an industry appear to place our trust in various IRR sources operated by entities that
 either can't or don't validate whether the actual owner of the involved resource approves the creation of the IRR database object.</div>
<div><br>
</div>
<div>We should start to push our customers to maintain their route origin information in databases operated by the RIR or NIR which assigned the resource, or even through RPKI ROAs that were optionally converted into IRR route objects for the ease of consumption.
 It's also time for the RIRs to take their responsibility in this matter by facilitating services like IRR, RPKI, PTR, etc for legacy IP space under conditions which are palatable to corporate lawyers, if they haven't already done so. </div>
<div><br>
</div>
<div>Finally, there doesn't have to be a global "flip the switch" day where we decide to stop trusting 3rd party databases, but even if we start holding ourselves to a higher standard one customer at a time that's still going to have the potential to make a
 big difference a couple of years down the road. </div>
<div><br>
</div>
<div>Best regards, </div>
<div>Martijn Schmidt </div>
<div><span style="font-family: "Segoe UI WestEuropean", "Segoe UI", Helvetica, Arial, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400;"><br>
</span></div>
<div><span style="font-family: "Segoe UI WestEuropean", "Segoe UI", Helvetica, Arial, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400;">PS, a small disclaimer: none of the above are
 new ideas, nor did I come up with them myself - but it still makes sense to work towards implementing them.. </span></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> NANOG <nanog-bounces@nanog.org> on behalf of Florian Brandstetter <florianb@globalone.io><br>
<b>Sent:</b> 25 January 2020 00:06<br>
<b>To:</b> nanog@nanog.org <nanog@nanog.org><br>
<b>Subject:</b> Rogue objects in routing databases</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">It appears that there is currently an influx of rogue route<br>
objects created within the NTTCOM and RaDB IRR databases, in<br>
connection to Quadranet (AS8100) and China Mobile<br>
International (CMI).<br>
<br>
Examples of affected networks are:<br>
<br>
193.30.32.0/23<br>
45.129.92.0/23<br>
45.129.94.0/24<br>
<br>
Networks, which have seemingly no affiliation with<br>
Quadranet, nor China Mobile International (CMI), which<br>
merely appears to be an upstream of Quadranet and hence<br>
creates the route objects in an automated manner.<br>
<br>
Another person has already reached out to Quadranet to find<br>
out the root cause of the creation of these objects. Their<br>
support gave an ETA of 24-72 hours.<br>
<br>
The route objects are all identical:<br>
<br>
route:      193.30.32.0/23<br>
descr:      CMI  (Customer Route)<br>
origin:     AS8100<br>
mnt-by:     MAINT-AS58453<br>
changed:    qas_support@cmi.chinamobile.com 20200117<br>
source:     RADB<br>
<br>
There appears to be a correlation with the affected<br>
networks, a fair share of them is part of AS-SBAG, which in<br>
turn is part of AS-VMHAUS, which in turn is part of AS-<br>
QUADRANET and could yield the importing of these prefixes.<br>
AS-VMHAUS appears to be a customer of Quadranet, listed<br>
within AS-QUADRANET-CUSTOMER-ASSET.<br>
<br>
These networks do however have no direct connection to<br>
Quadranet, and are not affiliated with Quadranet, nor are<br>
currently connected to Quadranet, which, entirely ignoring<br>
that the `origin` points to Quadranet, makes the route<br>
object illicit.<br>
<br>
Basically this has given AS8100, whether that be<br>
legitimately Quadranet, or somebody impersonating/spinning<br>
up a rogue AS8100, theoretical control over a massive amount<br>
of prefixes, as these can be advertised without restrictions<br>
and very likely reach a fairly high percentage of global<br>
visibility.<br>
<br>
--<br>
Florian Brandstetter<br>
President & Founder<br>
SquareFlow Network LTD.<br>
<br>
</div>
</span></font></div>
</body>
</html>