However, if *AS-path* filtering is done based on IRR data, specifically on the as-sets of customers and customers' customers etc., then the attack *can* be prevented.
The as-path prepending depends on upstreams and their peers accepting the prefix with a path which differs from the expected path (if the upstreams register their as-sets in the IRR). You are thinking about this specific exploit - which may in fact be stopped by as-path-filtering. However, that's not the problem you are solving. Problem is the hijacking. There are many other ways to reinject
On Thu, 28 Aug 2008, Brian Dickson wrote: traffic closer to victim - will require attacker to work a little harder, but not really fix the problem. (Think, GRE tunnels, no-export, no-export-to-specific-peer, etc). <snipped>
So, if the upstreams of as-hijacker reject all prefixes with an as-path which includes as-bar (because as-bar is not a member of any customer's as-set expansion), the attack fails. What's to stop me from adding as-bar into my as-set? To do what you are describing, you will have to enforce "export AS-LEFT" and "import AS-RIGHT" rules on every pair of AS-PATH adjacencies. And I'm not sure if existing tools can do that - or how many existing adjacencies fail that test.