When connected to an Internet peering exchange(IXP), what is a good way to make sure that people don't send you prefixes that they shouldn't be announcing?
With regards to bogons I'm aware of the Team Cymru Bogon Reference project but when it comes to filtering anything else from peers I have no idea where to begin. My understanding is this is what RPKI and similar are for?
As the others stated, RPKI would be the way to go, but it's not there yet. At exchange points we generally put a max-prefix limit on every session.
Additionally we use the following rules:
No default route
No bogons, more exactly this list:
route-filter 0.0.0.0/8 orlonger reject;
route-filter 127.0.0.0/8 orlonger reject;
route-filter 10.0.0.0/8 orlonger reject;
route-filter 172.16.0.0/12 orlonger reject;
route-filter 192.168.0.0/16 orlonger reject;
route-filter 224.0.0.0/4 orlonger reject;
route-filter 240.0.0.0/4 orlonger reject;
route-filter 169.254.0.0/16 orlonger reject;
route-filter 192.0.2.0/24 orlonger reject;
route-filter 198.51.100.0/24 orlonger reject;
route-filter 203.0.113.0/24 orlonger reject;
route-filter 100.64.0.0/10 orlonger reject;
No prefixes longer than /24
No private AS numbers in the path
None of our own prefixes
For IPv6 we do the same, only the bogons are different. I pasted our filter below this. Please be aware that the syntax might be a bit odd but that is due to the Juniper way of matching prefixes. For Cisco syntax you can go here: IPv6 BGP filter recommendations (The Juniper example on the page is buggy, please use the one below if you want.)
term ebgp-relaxed {
from {
family inet6;
route-filter 3ffe::/16 orlonger;
route-filter 0000::/8 orlonger;
route-filter 2001:db8::/32 orlonger;
route-filter 2001::/32 exact next policy;
route-filter 2001::/32 longer;
route-filter 2002::/16 exact next policy;
route-filter 2002::/16 longer;
route-filter fe00::/9 orlonger;
route-filter ff00::/8 orlonger;
route-filter 2000::/3 prefix-length-range /49-/128;
route-filter 0::/0 orlonger;
}
then reject;
}
At the moment (until RPKI is more widespread), we generally just filter common bogons and apply a max-prefix filter to exchange peers. We also filter certain ASNs, ones we are certain will never show up in most peering sessions, such as Level3 or Cogent, or should not be transited over an exchange.
We usually find that most of the common route leaks are not in the 1-2 digit range. That's very hard to catch anyway, unless you filter all your peers by building a prefix/ASN list or filter by radb, etc. Most leaks end up being closer to 10k-100k+, which is easily caught by a fairly low (100-500) max-prefix filter. You can then adjust that per-session as needed.
Depending on how you're using the peering exchange, you've got a few different options:
Firstly I'll cover RPKI and say that whilst it's something you should definitely go ahead and deploy, both for your own routes and validating others, it's unfortunately in such low use that you cannot at this point expect it to do all that much. The real solution here is WHOIS - Merit's RaDB is arguably the best since it'll allow you to return results for all RIRs at once. But, if you prefer to query each RIR directly, go for it.
Now, if you're on the exchange and you're just getting a pile of prefixes from the IXP's route server, depending on the tools you've got available to you and the capabilities of your router, you have two possibilities:
1. Filter by origin AS
Essentially, this consists of validating the origin AS of a prefix against the one in WHOIS - if the origin AS isn't matching the one in WHOIS, you drop the prefix and any more-specifics that might also be announced. This is generally a good protection against unintentional hijacks. The vast majority of prefixes should have this data.
2. Filter by transit AS
This takes it a step further and filters routes with any AS in the path that isn't authorised within WHOIS - you can't do this for every prefix however, since not everybody will have created objects specifying who their authorised transit AS providers are.
On the other hand, if you're using the peering exchange to directly peer with others, then your life gets a whole lot simpler; you can lookup what prefixes they have in WHOIS and permit those. Good practice in my opinion is to permit peers to announce more-specifics up to a max length of /24 whilst also setting a sensible maximum-prefix value (i.e. proportional to the number of subnets they have) on your peering so that they can't flood you with routes but can respond to a prefix hijack.
If you're looking for tools, check out IRRToolSet and IRR PowerTools
You've basically answered your own question. Your assumption that using RPKI is the way to go is absolutely correct. More specifically Route Origination Authorizations are used to validate a prefix to an AS. Obviously bogons will not be valid because they're not assigned to anyone, so that problem will take care of itself. A lot of this information is available on the RPKI Wikipedia page. Another good resource is ARIN's RPKI page.
If you need configuration help I suggest you create another question asking for specific configuration help.
It's also worth noting that RPKI won't work for everything, because not everyone is using it. At some point you just have to trust the routes you're receiving.
Ask your peers what AS macro they will be announcing and build filters for them using IRRToolSet or rpsltool or irrpt. Encourage them to have correct information published in an IRRdb. Don't forget to update your own aut-num object in your nearest friendly IRRdb to reflect the adjacency.
RPKI is not the way forward as it does not protect against route leaks.
