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

Mon Jan 23 05:27:19 UTC 2012

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.
>>
>>         Can you explain how?
>>
>
> Only a imprecisely detection.
>
> Section III.C in our paper
> http://argus.csnet1.cs.tsinghua.edu.cn/static/Argus.FIST11.pdf
>
> A brief explanation is:
> If an anomalous AS path hijacked a prefix,
> I can get replies in normal route-server, and can not get reply in abnormal
> route-servers.
>
> Here we only consider hijackings that black-hole the prefix.
> If a hijacking doesn't black-hole the prefix (i.e., redirect, interception,
> ...), is hard to detect :(
>
> I think network operators are only careless, but not trust-less,
> so black-hole hijacking is the majority case.

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)

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?

-chris