# BGP Route Filtering
BGP route filtering is the operational discipline of controlling which network prefixes a router accepts from and advertises to its BGP peers. The Border Gateway Protocol was designed for reachability, not security, and its original architecture trusts peers to announce only the routes they legitimately own or have authority to propagate. That trust model has proven catastrophically insufficient at internet scale. Route filtering corrects that gap by imposing explicit policy on what a router will accept, what it will pass along, and what it will refuse entirely. Organizations that skip route filtering expose themselves and the broader internet to hijacking, leaks, and misdirection events that can disrupt services for hours or days.
---
BGP route filtering is the set of policies and mechanisms that restrict the prefixes, AS paths, and routing attributes a BGP speaker will accept from peers (inbound filtering) or send to peers (outbound filtering). It operates at the control plane level, meaning it shapes the routing information exchanged between autonomous systems before any data-plane forwarding decisions are made.
Route filtering exists because the internet's routing infrastructure was designed for cooperation among trusted academic networks, not for a global commercial network where mistakes have financial consequences and malicious actors operate freely. The original BGP specification assumed that autonomous systems would announce only prefixes they legitimately controlled and would not intentionally or accidentally leak routes they learned from other peers. This trust model worked when the internet comprised a few hundred networks operated by known entities. It fails completely when applied to 70,000+ autonomous systems operated by organizations with varying levels of competence, oversight, and intent.
Route filtering is distinct from firewalling. A firewall acts on data packets in transit; route filtering acts on routing announcements before those packets even have a path to follow. It is also distinct from traffic shaping or QoS policies, which manage how packets are treated once a route exists. Route filtering determines whether a route exists in the table at all.
The discipline encompasses several complementary techniques: prefix-based filtering permits or denies routes based on the specific IP prefix announced; AS path filtering examines the sequence of autonomous system numbers in the routing path; community-based filtering uses BGP community tags to signal routing scope; bogon filtering explicitly rejects reserved or unallocated address space; and RPKI-based filtering uses cryptographic validation to verify route origin authorization. Each technique addresses different attack vectors and operational failure modes.
---
BGP route filtering is implemented through a combination of prefix lists, AS path access lists, route maps, and maximum-prefix limits applied to individual BGP neighbor sessions. Each component addresses a different attack surface or misconfiguration risk.
Prefix lists define an ordered set of permit and deny statements matching IP prefixes and their lengths. A well-constructed prefix list for a customer session permits only the specific prefixes that customer has registered in the Internet Routing Registry (IRR) or covered by a valid Route Origin Authorization (ROA), and denies everything else. The specificity of prefix-length matching matters: accepting 192.0.2.0/24 does not mean accepting 192.0.2.0/25 unless the list explicitly permits it, which prevents a customer from advertising more-specific routes to attract traffic they should not control.
Consider a concrete example. Enterprise Corp has registered 203.0.113.0/24 in the IRR and obtained a ROA for this prefix with their ASN 65001. Their ISP's inbound prefix list permits 203.0.113.0/24 exactly, with no longer prefixes allowed. When an attacker at ASN 65002 attempts to announce 203.0.113.0/25 (claiming half of Enterprise Corp's address space), the ISP's filter rejects this announcement because 203.0.113.0/25 is not in the permitted prefix list. The more-specific prefix never enters the global routing table from this ISP, preventing the hijack.
AS path filters examine the AS_PATH attribute of received routes. A simple inbound filter on a customer session rejects any route whose AS path does not begin with the customer's registered ASN. More sophisticated filters reject routes containing private AS numbers (64512 to 65534 in the 16-bit range, 4200000000 to 4294967294 in the 32-bit range) that should never appear in public routing tables, routes with implausibly long AS paths suggesting route manipulation, and routes with excessive AS path prepending that could indicate attempt to game routing policies.
Route maps combine multiple match conditions, including prefix, AS path, community, and Multi-Exit Discriminator (MED) values, into compound policies. They also allow attribute manipulation: setting local preference, adjusting MED, or tagging routes with communities before accepting them into the local table. A transit provider might use a route map to accept a customer's prefix but tag it with a community that signals to upstream peers to limit its propagation to a specific geographic region.
Maximum-prefix limits cap how many prefixes a session will accept from any single peer. When a misconfigured router begins advertising tens of thousands of routes it should not own, the maximum-prefix limit trips a threshold and either generates an alert, reduces the session to a warning state, or tears down the peering entirely. This directly mitigates route table flooding and the kind of configuration errors that caused the 2019 Cloudflare outage when a small ISP accidentally leaked a more-specific prefix that attracted massive traffic volumes.
RPKI Route Origin Validation (ROV) adds a cryptographic layer to prefix filtering. Network operators deploy a local RPKI validator such as Routinator, OctoRPKI, or FORT Validator that fetches signed ROAs from Regional Internet Registries. When a BGP route arrives, the router queries the validator to determine whether the originating ASN and prefix match a valid ROA. Routes that are "invalid" under RPKI can be dropped automatically or given a lower local preference, preventing them from being installed in the forwarding table.
The practical deployment of these filters requires automation. Manually maintaining prefix lists across hundreds of BGP sessions is error-prone and operationally unscalable. Tools such as bgpq4, IRRd, and vendor-specific automation platforms generate prefix lists automatically from IRR objects and RPKI data. These generated lists are pushed to routers on scheduled intervals, ensuring that when a customer adds or removes a prefix through proper registration channels, the filter updates within hours rather than requiring manual intervention.
Outbound filtering is equally important but frequently neglected. An organization that accidentally redistributes internal routes, customer routes, or routes learned from one ISP into a session with a different ISP becomes a route leak source. The 2019 incident involving Verizon accepting leaked routes from a customer disrupted significant portions of internet traffic because those routes made Verizon appear to be the best path for traffic that should have taken entirely different routes through the global internet.
Proper outbound filters operate on a default-deny basis: only explicitly authorized prefixes are permitted outbound, and the authorization chain must be documented and auditable. For a regional ISP, this means announcing only their own allocated prefixes and explicitly approved customer prefixes. For an enterprise with dual-homed connectivity, this means announcing only their own registered prefix and never redistributing routes learned from one ISP to another.
Community-based filtering provides a more granular approach to routing policy. BGP communities are 32-bit tags attached to routes that signal various attributes: geographic scope (announce only in North America), relationship type (customer vs. peer), or special handling requirements (backup path only). Communities allow receiving networks to apply their own policies based on the sender's intent. The BLACKHOLE community (65535:666) signals that a prefix should be discarded, commonly used for DDoS mitigation by making an attacked prefix unreachable.
The effectiveness of route filtering depends on deployment at multiple points in the routing path. A filter at the edge of the network catches problems at their source, but problems that originate elsewhere require filtering at tier-1 and tier-2 providers. The internet's routing security improves as more operators deploy filtering, creating overlapping layers of protection that catch different categories of routing anomalies.
---
Without BGP route filtering, the internet's routing infrastructure operates on implicit trust that every participant behaves correctly. That assumption fails regularly, with consequences ranging from brief service disruptions to prolonged traffic interception and financial loss.
The most serious risk is route hijacking, where an attacker announces prefixes they do not own to attract traffic through their infrastructure. This enables traffic interception, man-in-the-middle attacks against unencrypted connections, and credential harvesting at scale. The 2018 attack on Amazon Route 53, where attackers redirected DNS traffic for MyEtherWallet by announcing Amazon's prefix through a complicit ISP, resulted in approximately $152,000 in stolen cryptocurrency from users who connected to attacker-controlled DNS servers. The attack succeeded because the originating ISP did not filter the hijacked routes, and downstream providers did not validate the route origin.
Route leaks, which result from misconfiguration rather than malicious intent, cause similar disruption through different mechanisms. When a network accidentally propagates routes it should keep internal, or forwards customer routes to peers when it should only forward them to upstream transit providers, it can become an unintended transit path for traffic flows that overwhelm its capacity. The leaked routes often represent more-specific prefixes that become preferred over legitimate routes, creating black holes or severe congestion.
Financial impact extends beyond direct theft or service disruption. Organizations whose prefixes are hijacked lose customer traffic, which translates to lost revenue during the incident and potentially longer-term customer attrition. Cloud providers face service level agreement penalties when routing incidents disrupt customer applications. The reputational damage from being associated with a high-profile routing incident can affect customer acquisition and partner relationships.
A persistent misconception is that route filtering is only relevant for Internet Service Providers and large network operators. In reality, any organization with BGP peering sessions needs filtering controls. Enterprises with dual-homed connections can accidentally leak routes between their ISPs, making them liable for disrupting other networks. Data centers with their own autonomous systems regularly connect to multiple providers and need both inbound filtering to protect their routing tables and outbound filtering to prevent accidental leaks.
Another dangerous misconception is that RPKI deployment eliminates the need for traditional route filtering. RPKI validates that an autonomous system is authorized to originate a specific prefix, but it does not validate the entire AS path, does not prevent leaks of legitimately originated routes, and depends on ROA coverage that remains incomplete for significant portions of the global routing table. As of 2024, approximately 35% of the routed IPv4 address space has RPKI coverage, meaning 65% of routes cannot be validated cryptographically.
The business case for route filtering extends beyond preventing incidents. Regulatory frameworks increasingly expect organizations to demonstrate due diligence in protecting critical infrastructure. The European Union's NIS2 directive explicitly requires essential service operators to maintain appropriate technical measures for network security. In the United States, CISA's cybersecurity guidelines for critical infrastructure operators include routing security as a fundamental requirement. Organizations that experience routing incidents without having deployed basic filtering controls face potential regulatory scrutiny and liability.
Route filtering also provides operational benefits during normal network operations. Clean routing tables improve convergence times when legitimate topology changes occur. Reduced route churn from blocked invalid announcements decreases CPU load on route processors. More predictable routing behavior simplifies troubleshooting when performance issues arise.
---
CDA approaches BGP route filtering through the Planetary Defense Model's Vector Surface Domain (VSD), treating each BGP peering session as an exposed attack surface that must be reduced to its minimum necessary footprint. The core methodology is Continuous Surface Reduction: every surface you expose is a surface we eliminate.
In the context of BGP, this means that each neighbor session represents a vector through which malicious or malformed routing information can enter the network. The surface reduction approach constructs filter policies that permit only explicitly authorized routing information and deny everything else. Unlike conventional approaches that may start with permissive policies and add restrictions over time, CDA begins with default-deny policies derived from authoritative data sources.
For customer-facing sessions, CDA generates prefix lists directly from Internet Routing Registry data and RPKI ROA records, establishing a cryptographically anchored baseline of what each customer is authorized to announce. These lists are not configuration artifacts set once during customer onboarding; they are living security controls that regenerate automatically every four hours from upstream authoritative sources. When a customer registers a new prefix in the IRR or publishes a new ROA, the filter policy updates without human intervention. When a customer's ROA expires or is revoked, the prefix becomes unauthorized and gets blocked.
The CDA approach treats routing policy as a security artifact with the same rigor applied to firewall rulesets or access control lists. Route filter configurations are stored in version control systems, reviewed through formal change management processes, and tested in staging environments before production deployment. Most organizations treat routing policy as infrastructure configuration managed by network engineering teams; CDA treats it as a security control that requires accountability, auditability, and continuous validation by security operations teams.
CDA also mandates real-time monitoring of route filter effectiveness. BGP session telemetry feeds into security information and event management platforms, generating alerts when prefix counts exceed expected baselines, when new prefixes appear that are not in authorized lists, or when RPKI-invalid routes arrive but are not dropped. These alerts enable rapid investigation before a policy failure becomes a security incident.
What distinguishes the CDA methodology is the integration of routing security into the broader cybersecurity program rather than treating it as a separate network operations concern. Route filter policy violations trigger the same incident response procedures as intrusion detection alerts. Routing anomalies are correlated with threat intelligence feeds to identify whether they represent targeted attacks or accidental misconfigurations. Route filter bypass attempts are logged and analyzed as indicators of compromise.
CDA also emphasizes the principle of defense in depth for routing security. Single-layer filtering at the network edge provides basic protection, but sophisticated attacks or widespread misconfigurations can bypass edge filters. CDA deployments include filtering at multiple network layers: edge routers filter customer and peer announcements, core routers apply bogon and RPKI validation, and border routers enforce outbound policies that prevent accidental leaks. Each layer catches different failure modes and provides redundancy when individual controls fail.
---
---
---