route-leak

2 posts

cloudflare

ASPA: making Internet routing more secure (opens in new tab)

ASPA (Autonomous System Provider Authorization) extends RPKI-based routing security from verifying a route’s destination to validating the path it takes. By publishing cryptographically signed lists of authorized providers, networks can detect BGP route leaks and some forged-origin hijacks. Cloudflare Radar now tracks ASPA adoption and records across the five Regional Internet Registries. ## From Origin Validation to Path Validation - RPKI uses Route Origin Authorizations (ROAs) to verify that an Autonomous System (AS) is authorized to announce specific IP prefixes. - ROAs protect against origin hijacks, where an attacker falsely claims ownership of someone else’s address space. - ASPA complements ROAs by validating the AS_PATH—the sequence of networks through which a route propagates. - Each AS publishes its authorized upstream providers, allowing other networks to check whether the observed path follows approved relationships. ## Detecting Route Leaks - Normal Internet routing generally follows a “valley-free” pattern: - Traffic moves upward from a customer through providers. - It may cross a peering connection near the top. - It then moves downward through providers toward the destination. - A route leak creates a “valley,” such as traffic traveling down to a customer and then back up to another provider. - ASPA evaluates the path from both directions: - The “up-ramp” is checked from the route origin toward its providers. - The “down-ramp” is checked backward from the destination. - A path is valid when both authorized chains meet. If they leave a gap, the route is considered ASPA Invalid, indicating a likely leak or unauthorized propagation. ## Example of ASPA Validation - In the example, AS65539 receives a route from customer AS65538. - AS65538 improperly propagates traffic received from provider AS65537 toward another provider, acting as a bridge between providers. - The upstream validation chain ends at AS65537, while the downstream chain ends at AS65538. - Because the two chains do not connect, ASPA identifies the route as invalid. ## Protection Against Forged-Origin Hijacks - ASPA can detect attacks in which the legitimate origin AS is retained but the attacker fabricates the path leading to it. - The victim’s signed provider list reveals that the attacker is not an authorized provider, allowing the route to be rejected. - ASPA is not universal protection: the article notes that a provider may still forge a path advertisement to its customer, a case the supplied text does not fully explain. ## Monitoring ASPA Adoption - Cloudflare Radar’s ASPA deployment monitoring feature shows adoption trends across all five RIRs. - It also lets users inspect ASPA records and changes for individual Autonomous Systems. ASPA provides an important second layer of routing security: ROAs verify where traffic should end, while ASPA helps verify how it gets there. Wider publication and validation of ASPA records should make route leaks and path manipulation easier to detect and prevent.

cloudflare

Route leak incident on January 22, 2026 (opens in new tab)

On January 22, 2026, a routing-policy automation error caused Cloudflare to leak IPv6 BGP prefixes from its Miami data center. For 25 minutes, external traffic was redirected through Miami, congesting backbone links, increasing latency and packet loss, and causing some traffic to be dropped by firewall filters. The incident resulted from removing prefix-list constraints, leaving a Juniper policy that accepted and externally advertised unintended internal routes. ## What a BGP Route Leak Is - A route leak occurs when an autonomous system advertises routes it is not supposed to forward. - This violates valley-free routing principles, such as sending routes learned from a peer onward to another peer or provider. - The leaking network may lack the capacity or firewall rules to handle the redirected traffic. - Cloudflare’s incident involved a mixture of Type 3 and Type 4 route leaks under RFC 7908. ## Incident Impact and Timeline - The triggering automation change was merged at **19:52 UTC**. - At **20:25 UTC**, it ran on a single Miami edge router and caused unexpected advertisements to peers and transit providers. - The network team began investigating at **20:40 UTC** and formally coordinated the incident at **20:44 UTC**. - At **20:50 UTC**, an operator reverted the bad configuration and paused automation on the router. - The leak lasted approximately **25 minutes**, causing: - Congestion on Miami backbone infrastructure - Increased packet loss and latency for some Cloudflare customers - Traffic from unrelated external networks to be funneled through Miami - Packet drops from firewalls configured to accept only Cloudflare-related traffic - The triggering code change was reverted at **21:47 UTC**, and automation was later verified and resumed. ## The Configuration Error - Cloudflare intentionally removed Miami advertisements for a Bogotá data center after infrastructure changes made the Miami-to-Bogotá forwarding path unnecessary. - The change removed `6-BOG04-SITE-LOCAL` prefix-list conditions from multiple export policies. - Those prefix lists had constrained policies to specific Bogotá prefixes. - Once removed, policies such as `6-TELIA-ACCEPT-EXPORT` still matched routes with `route-type internal` and accepted them for export. - On Juniper JunOS and JunOS EVO, `route-type internal` matches any non-external route, including Internal BGP (IBGP) routes. - Consequently, routes that should have remained internal were treated as exportable and advertised to external peers and providers. - The problem affected IPv6 traffic only. ## Response and Remediation - Operators manually reverted the generated router configuration. - Automation was paused on the affected Miami router to prevent the faulty policy from being reapplied. - The source-code change was reverted, and the router was checked before automation resumed. Cloudflare’s incident demonstrates that removing seemingly obsolete route filters can unintentionally broaden a policy. Export policies should explicitly constrain acceptable prefixes and include validation or safeguards that prevent internal routes from being advertised externally.