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