Re: Great Suggestion for the DNS problem...?

* Brian Dickson · * Thu Aug 28 23:35:33 2008

Alex Pilosov wrote:

On Thu, 28 Aug 2008, Brian Dickson wrote:

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

Very true. Tying allocations and assignments to ASN-of-origin and
providing a suitable place

to validate such, for building prefix and as-path filters, would do a
lot towards further limiting

the ability to hijack prefixes - but only to the degree to which
providers filter their customers.
And that's only on routes - to say nothing of packet filtering (BCP 38)...
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.

True, there is nothing actually stopping you from doing this.
However, (and this is both the key, and a big presumption) changes to
as-sets are the kind of thing

that automatic provisioning tools should alert on, and require
confirmation of, before updating prefix-lists

and as-path lists based on the new members of the as-set.
While prefixes are routinely added, new transit relationships at a BGP
level don't happen all *that* often.
The idea isn't just to stop the prefix announcement, it is to trap
activity that would otherwise permit the

prefix hijack, at the time it occurs and before it takes effect.
The closer this occurs to the hijacker, the more likely it is that
appropriate responses can be directed at the bad guy,

and with a greater likelihood of success (e.g. prosecution).
The threat alone of such response may act as a suitable deterrent...
As for the filter building and enforcement mechanisms:
The inbound as-path filters need to permit the permutations of paths
that result from expanding as-sets, but that can

be accomplished unilaterally on ingress, without enforcement beyond the
immediate peering session. The expansion

is for each as-set behind an ASN, there should be a corresponding
as-set, and so on... each gets expanded and added to

the expansion of the permitted paths via that ASN. Lather, rinse, repeat.
All filtering is local, although the more places filtering happens, the
better.
Brian