|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Great Suggestion for the DNS problem...?
Alex P wrote: *) There is no currently deployable solution to this problem yet. Kind of true. When doing *prefix* filtering, this kind of hijack is not preventable. 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). If the as-path filter only allows generally-feasible as-paths from customers, where the permitted variations are just "N copies of ASfoo" (where "foo" is a member of an as-set), then adding a fake "ASbar" in the as-path will cause the prefix to be rejected. If you follow the diagram from the presentation, information about the *real* path to the victim, from the perspective of the hijacker, requires that the AS's on that path not see the hijacked prefix as announced by the hijackers. This means that if the AS's traversed are: as-hijacker, as-bar, as-victim, then as-bar must *not* see the hijacked victim, for the attack to work. By adding "as-bar" into the as-path of the hijacked prefix, the loop-prevention logic of BGP makes sure as-bar can't see the hijacked prefix. 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. I hope I haven't managed to confuse folks too much. But, the short answer is: If you use the IRR, the full value is best realized by adding *as-path* filters to the things you build from the IRR data, and applying them to your customers (and peers !!). Oh, and if you already do IRR stuff, it's really quite easy to do. Brian Dickson
|