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
