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.
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