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

[John Kemp <kemp () network-services uoregon edu>]

On 1/23/2012 7:28 AM, Christopher Morrow wrote:
> 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 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

Minor correction there.  If you are talking about our IX collectors
(LINX, PAIX,
EQIX Ashburn, SYDNEY, etc.) those are at exchanges and peering
directly.  The
collectors at Univ of Oregon (rv,rv2,rv3,rv4, rv6), yeah, those are
multi-hop.
Doesn't detract from your point, but I think it helps if people are
aware of whether
they are on the exchange or on a multihop when using routeviews collectors.

Only other thing to add, I don't think anyone mentioned Cyclops in this
thread.
Just as another data point, see also: http://cyclops.6watch.net or
http://cyclops.cs.ucla.edu

John Kemp (kemp () routeviews org)