BGP hijacking attack (i.e., an adversary falsely announces a network prefix which is not owned by the adversary) looks pretty straightforward and easy to launch.
Then, is there any way to mitigate this attack? Detecting false BGP announcements is the only way to deter it?
Also, only big ASes who have the data to detect the false announcement can do the job?
Yes, this a bigger question than can be answered here.
This is, of course, the problem that BGPSec and BGP Origin Validation sets out to mitigate.
The IETF SIDR working group has concluded its work and the SIDROPS is working on the practical problems of deployment and operation.
Why Is It Taking So Long to Secure Internet Routing? is interesting. Also BGP with BGPsec: Attacks and Countermeasures.
If ASes could "detect a false announcement" then it seems obvious that they would suppress them. But to detect a False Announcement you need a trustworthy source of True Announcements. That has proved to be a Big Problem. But it's worse than that. In "steady state" one can almost imagine a reasonable size database of True Routes. But in response to network issues, large and small, the whole point of BGP is that new routes can be announced (including new more-specific ones), to keep the traffic flowing. So your database of True Routes needs a separate protocol (with its own latency and trust issues) to keep it up to date :-(
From an ISP perspective, it is true that most customers and peers announce a limited and stable number of well known routes. So precise route filtering looks like way to mitigate the threat. But it's fiddly and time consuming and prone to error and adds complexity and only marginally (if at all) benefits the ISP... and is inflexible (why not just configure static routes !).
Of course, even if a given AS is "entitled" to announce a given route, that does not guarantee they will handle the traffic "correctly" :-(
[I wonder if the NetworkEngineering folk have an up to date view of actual deployment of BGPSec and Origin Validation etc. ?]
