Prefix hijacking, how to prevent and fix currently

Andy Davidson andy at
Thu Sep 4 07:26:11 UTC 2014


Matthew Petach wrote:
> Be aware that even if you don't think you're peering with them 
> directly, you may be picking up routes via the public route 
> servers at exchange points, so check to see if you need to apply
> filters on your route server peerings as well.

At the risk of receiving 1,000 critical replies along the lines of "an internet exchange is not the routing police", I will point out that an IXP route-server is actually a really elegant place to do route filtering.  

The IXPs I help to maintain (LONAP & IXLeeds in the UK) do perform IRR filtering on the MLP route-servers.  This is handy in the scenario that the ISP is manually filtering customers, where such a technique scales badly when considering how to filter peers.  We're transparent and help customers fix route objects when they don't understand why an MLP peering is not effective.  If IRR wasn't a total crock, it'd be a really good system.

Saku Ytti wrote:
> Companies who are likely target for this, like MSFT and GOOG, 
> might want to monitor DFZ and see if they are receiving prefixes
> no one else is receiving.

The more eyes on the problem, the harder it is for these attacks to work, so the more likely targets (not specifically identifying the two companies in your example, there are lots of likely targets, many in the "Enterprise" space) who feed services like RIPE RIS or Routeviews, the easier it will be to learn what the attack vectors are and fight them.


More information about the NANOG mailing list