[148800] in North American Network Operators' Group
Re: Why not to use RPKI (Was Re: Argus: a hijacking alarm system)
daemon@ATHENA.MIT.EDU (Christopher Morrow)
Mon Jan 23 10:29:18 2012
In-Reply-To: <CA+rW-LCWfEzyKYbazYVveXv0=9ni0TGRoLb3CLOBY5RRd68FRA@mail.gmail.com>
Date: Mon, 23 Jan 2012 10:28:36 -0500
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Yang Xiang <xiangy08@csnet1.cs.tsinghua.edu.cn>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Mon, Jan 23, 2012 at 10:19 AM, Yang Xiang
<xiangy08@csnet1.cs.tsinghua.edu.cn> wrote:
> Hi chris,
>
> 2012/1/23 Christopher Morrow <morrowc.lists@gmail.com>
>>
>> On Fri, Jan 20, 2012 at 8:08 AM, Yang Xiang
>> <xiangy08@csnet1.cs.tsinghua.edu.cn> wrote:
>> > 2012/1/20 Arturo Servin <aservin@lacnic.net>
>>
>> >> > while Argus can discover potential hijackings caused by anomalous A=
S
>> >> path.
>>
>> reading the preceding section (III.B) you check 3 things in the AMM
>> (anomaly monitoring module)
>> =A01) proper origin (based on what?)
>> =A02) anomalous neighbour (based on what?)
>> =A03) 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,=A0neighbor=A0and p=
olicy
> 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=92
> hijackings, but not 'exact' hijackings.
> =A0 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=94) 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
