[routing-wg] /24 prefix "hijackability" metric (defining "better than avg AS")

On Tue, Aug 14, 2018 at 07:58:00PM +0000, nusenu wrote:
> I'm currently estimating how "vulnerable" certain IP addresses are to
> BGP hijacking.
> 
> To do that, I put them into different categories (multiple can apply):
> 
> a) RPKI validity state is "NotFound" (no ROA) and IP located in a prefix shorter than /24 (IPv4)  or /48 (IPv6)
> b) Valid ROA but weak maxlength
> c) Valid ROA with proper maxlength
> d) is announced in a /24 prefix (IPv4) or /48 (IPv6)
> e) = (c) + (d)

Interesting approach! This is the first time I've seen someone phrase it
this formally, but you are correct I think.

> In addition to the distinction of prefix length (/24 vs. </24) I'd like to
> subcategorize /24 prefixes into
> - /24 prefix located in "well" connected AS (attacker's BGP visibility is presumed lower than the authentic AS visibility)
> - /24 prefix located in "poorly" connected AS (better for the attacker)
>
> The question is: What is the threshold and metric to tell these two
> apart?
> 
> I'm having 3 approaches in mind and wanted to hear if you have any
> preferences, opinions or other approaches:
> 
> Approach 1:
> -----------
> If avg AS PATH length as provided by [1] is <2 in more than 50% of
> given locations and DE-CIX and AMS-IX is among them, then consider it
> a "well connected AS"

I'd try to avoid building in a bias towards institutions such as AMS-IX
or DE-CIX.

> Approach 2:
> -----------
> Use CAIDA's AS rank data and define the top 50% ASes as "well" connected

Perhaps create multiple buckets, in order of 'weakness':

- single-homed stub network
- dual-homed stub network
- bottom 50% ASNs on CAIDA's AS rank
- top 50% ASNs on CAIDA's AS rank
- ASNs in the top 100 on CAIDA's AS rank

> Approach 3:
> -----------
> define "well connected" as avg AS PATH as seen in [1] is shorter than
> the global avg. AS PATH length (defined in [2])
> 
> Also: If there are already well established metrics for "well connected" 
> AS I'd be happy to hear about them.
> 
> Currently I'm leaning towards approach 1 as it is probably the
> strictest and most conservative approach. I also might compare the
> results of all 3 approaches.

Perhaps you can try both approach 1, approach 2 and approach 2bis and
compare the results.

Since we know we are *not* seeing tons of BGP paths (the collectors only
receive what they receive, which is a subset of all BGP data), the trick
is to find a proxy metric that through which you can attempt to model
reality.

> Because it is hard to collect ROV data and the list on
> https://rov.rpki.net is still short I do not try to include a ROV
> metric (yet).

I'm sad to have to report that the listing on rov.rpki.net is presented
in a misleading way, and useless for your purpose. I'd ignore any data
from rov.rpki.net entirely for now.

Kind regards,

Job