Rogue objects in routing databases

Sat Jan 25 12:29:34 UTC 2020

Hi Martijn,

albeit a negligible amount of edge cases it can
indeed be stated that there is too much trust put
into alternative IRR sources operated by third
partys not affiliated to RIRs. Generally, usage of
such databases however is not mis-used in a larger
scope, and the complexity involved with creating
route objects (AltDB for example validates new
MAINTAINERS, RaDB charges) diminishes the vector
in a (barely influental) manner. An option to
combat this would perhaps be to run validation at
regular intervals, and brings invalid objects to
the attention of operators. I did similar for this
incident just a moment ago with a batch of self-
written scripts.

After further analysis, there are over 5390 IPv4
prefixes pointing with their origin towards
AS8100: https://pastebin.com/Zh1YZfEq

Out of 5390 prefixes, 2287 are currently not even
visible within the global routing table: 
https://pastebin.com/cSepb7yS

Another 2714 prefixes are INVALID, that in
particular means that AS8100 is neither *within*
the announcing AS-PATH, nor originating the
prefix: https://pastebin.com/JhaxVeN0

Last but not least, there is 389 VALID prefixes
(in this case, perhaps only technically valid, as
I did probe for AS8100 within the AS-PATH
sequence, and not if AS8100 actually originates
the prefix): https://pastebin.com/UVt6nwGz

That's a conceivable 5001 IPv4 prefixes for a
potential bad actor right there. It can also
clearly be stated that, while initially mentioned,
the significance of ascendence caused by AS-SBAG
is negligible, as it appears, the entirity of
Quadranet and affiliates is affected.

Regards,
Florian Brandstetter

On Sat, 2020-01-25 at 01:02 +0000, Martijn Schmidt
wrote:
> Hi Florian, NANOG, 
> 
> 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.
> 
> 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. 
> 
> 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. 
> 
> Best regards, 
> Martijn Schmidt 
> 
> 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.. 
> From: NANOG <nanog-bounces at nanog.org> on behalf
> of Florian Brandstetter <florianb at globalone.io>
> Sent: 25 January 2020 00:06
> To: nanog at nanog.org <nanog at nanog.org>
> Subject: Rogue objects in routing databases
>  
> It appears that there is currently an influx of
> rogue route
> objects created within the NTTCOM and RaDB IRR
> databases, in
> connection to Quadranet (AS8100) and China
> Mobile
> International (CMI).
> 
> Examples of affected networks are:
> 
> 193.30.32.0/23
> 45.129.92.0/23
> 45.129.94.0/24
> 
> Networks, which have seemingly no affiliation
> with
> Quadranet, nor China Mobile International (CMI),
> which
> merely appears to be an upstream of Quadranet
> and hence
> creates the route objects in an automated
> manner.
> 
> Another person has already reached out to
> Quadranet to find
> out the root cause of the creation of these
> objects. Their
> support gave an ETA of 24-72 hours.
> 
> The route objects are all identical:
> 
> route:      193.30.32.0/23
> descr:      CMI  (Customer Route)
> origin:     AS8100
> mnt-by:     MAINT-AS58453
> changed:    qas_support at cmi.chinamobile.com
> 20200117
> source:     RADB
> 
> There appears to be a correlation with the
> affected
> networks, a fair share of them is part of AS-
> SBAG, which in
> turn is part of AS-VMHAUS, which in turn is part
> of AS-
> QUADRANET and could yield the importing of these
> prefixes.
> AS-VMHAUS appears to be a customer of Quadranet,
> listed
> within AS-QUADRANET-CUSTOMER-ASSET.
> 
> These networks do however have no direct
> connection to
> Quadranet, and are not affiliated with
> Quadranet, nor are
> currently connected to Quadranet, which,
> entirely ignoring
> that the `origin` points to Quadranet, makes the
> route
> object illicit.
> 
> Basically this has given AS8100, whether that be
> legitimately Quadranet, or somebody
> impersonating/spinning
> up a rogue AS8100, theoretical control over a
> massive amount
> of prefixes, as these can be advertised without
> restrictions
> and very likely reach a fairly high percentage
> of global
> visibility.
> 
> --
> Florian Brandstetter
> President & Founder
> SquareFlow Network LTD.
> 