Why filter routes at all
How networks publish what they announce and how their neighbours turn it into filters: Internet Routing Registries, whois queries, RPSL objects and attributes, AS-SET expansion, bgpq4, and the pitfalls of unsigned routing data.
By the end you will be able to:
- Explain why BGP sessions need prefix filters and which neighbours need which kind
- Tell authoritative from non-authoritative IRRs, and query them with whois and IRRd
- Read and write RPSL objects: inetnum, route/route6, aut-num, as-set and mntner
- Expand an AS-SET by hand, and recognise set bloat, loops and naming collisions
- Generate and safely deploy prefix filters with bgpq4
- Keep your own IRR data correct, and know what IRR data can't prove
Prerequisites: BGP Fundamentals
BGP believes what it is told. If a neighbour announces a prefix, nothing in the protocol checks that the neighbour is entitled to announce it. Two kinds of incident follow from that:
- Hijacks: a network originates address space that isn't theirs, by mistake or deliberately. Traffic for the victim goes to the wrong place.
- Route leaks: a network re-announces routes it learnt from one provider or peer to another, in violation of the intended policy (RFC 7908). Traffic takes a path that was never meant to carry it.
Most large incidents are leaks, not attacks. In June 2019, more-specific routes created by a BGP optimiser leaked through a small customer, were accepted by a large transit provider, and disrupted major services for hours. A simple customer prefix filter would have stopped it.
Who should you filter, and how?
| Neighbour | What they may send you | How to filter |
|---|---|---|
| Customer | Their prefixes and their customers' prefixes — their customer cone | Explicit prefix-list built from IRR data, plus max-prefix and RPKI |
| Peer | Their customer cone | Max-prefix and RPKI; IRR prefix-lists where practical |
| Transit | Potentially the whole internet | Bogon filters, RPKI, sanity limits |
Building that customer prefix-list by hand doesn't scale, and customers change their prefixes all the time. The industry answer is for every network to publish what it announces in a shared database, and for its neighbours to generate filters from it. Those databases are the Internet Routing Registries, and their language is RPSL.
- Normal operation. AS64501 is multihomed. It announces its own prefix to both providers.
- The customer receives a full table. AS64497 sends the customer every route on the internet. That's expected: the customer uses them to pick exits.
- The leak. A missing outbound filter on the customer's router re-advertises everything learnt from AS64497 to you. Nothing malicious, just a typo or a new router with no policy.
- Without a filter, it spreads. You give customer routes the highest LOCAL_PREF, so these leaked paths become your best paths, and you re-announce them upstream. Traffic for a large part of the internet now funnels through a small customer link.
- With an IRR filter, it stops here. Your inbound prefix-list for AS64501 is generated from the customer's AS-SET and route objects. It permits 203.0.113.0/24 and the prefixes of AS64501's own customers, and nothing else. The leak is dropped at your edge.
Check your understanding
A customer accidentally re-announces its other provider's full table to you. Which of your controls stops the leaked routes most precisely?
- An RPKI drop-invalid policy
- A prefix-list generated from the customer's AS-SET and route objects
- Maximum-prefix on the session
- TCP-MD5 on the session