Alex P wrote:
*) There is no currently deployable solution to this problem yet.
*) Filtering your customers using IRR is a requirement, however, it is
not
a solution - in fact, in the demonstration, we registered the /24 prefix
we hijacked in IRR. RIRs need to integrate the allocation data with their
IRR data.
-alex [your former moderator]
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