Great Suggestion for the DNS problem...?

Brian Dickson briand at ca.afilias.info
Thu Aug 28 22:35:24 CDT 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




More information about the NANOG mailing list