Why not to use RPKI (Was Re: Argus: a hijacking alarm system)

Christopher Morrow morrowc.lists at gmail.com
Mon Jan 23 09:28:36 CST 2012


On Mon, Jan 23, 2012 at 10:19 AM, Yang Xiang
<xiangy08 at csnet1.cs.tsinghua.edu.cn> wrote:
> Hi chris,
>
> 2012/1/23 Christopher Morrow <morrowc.lists at gmail.com>
>>
>> On Fri, Jan 20, 2012 at 8:08 AM, Yang Xiang
>> <xiangy08 at csnet1.cs.tsinghua.edu.cn> wrote:
>> > 2012/1/20 Arturo Servin <aservin at lacnic.net>
>>
>> >> > while Argus can discover potential hijackings caused by anomalous AS
>> >> path.
>>
>> reading the preceding section (III.B) you check 3 things in the AMM
>> (anomaly monitoring module)
>>  1) proper origin (based on what?)
>>  2) anomalous neighbour (based on what?)
>>  3) policy anomaly (where did you determine the policy?)
>>
>> later text seems to imply you track some history (1 months worth) and
>> use that as a baseline, for at least the neighbour and origin data.
>> The policy data isn't clearly outlined though, where did that come
>> from? (there's a note about use of whois, which could cover some of
>> this, but certainly not all)
>
> yes, we use history as a baseline for both the origin, neighbor and policy
> data.
> origin data: a history of <prefix, origin_AS> mappings,
> neighbor data: a history of every "adjacent two ASes" in all AS paths
> received from BGPmon,
> policy data: a history of every "adjacent three ASes" (AS triple) in all AS
> paths.
>
> origin and neighbor data is intuitive.
> for policy data, we do not gather the exact routing policies,
> since they are usually private.
> In Argus, we use all "adjacent three ASes" in all AS paths as the policy
> data.
> this is because:
> 1), AS triples reflect the import/export routing policies;
> 2), while monitoring BGP updates, we only need to discover 'possible’
> hijackings, but not 'exact' hijackings.
>   after figure out a possible hijacking, the hijacking identification
> process will be launched and make the final judgement.

ok, that seems squirrelly still :(

>
>>
>>
>> The data plane testing you propose is from the public route-servers
>> (eyes), which don't import the path you want, well routeviews I think
>> doesn't import routes to it's FIB (or maybe I'm mistaken...) but point
>> being with more than one peer on the routeserver it's not clear you
>> would be taking the path you actually want to test anyway, is it?
>
> yes, each route-server usually has several route to the target prefix.
> In Argus, we use the commands (i.e., "show route exact active-path”) to get
> the 'best routes' of the prefix,
> and consider it as the route in FIB:

so, take routeviews for example, they peer almost exclusively
ebgp-multi-hop, so any 'best path' you see there isn't actually usable
by the route-server... all traffic has to take the local transport out
of the routeviews system, off to the internet and beyond. So, your
blackhole testing isn't actually testing what you want, I think :(

-chris



More information about the NANOG mailing list