Real-Time Defense Recommedations for BGP Route Security

The Border Gateway Protocol (BGP) is still working hard to route every public packet worldwide three decades on. With so many years passing since its backbone links lit up, its weaknesses are as old and familiar as the protocol itself. Time and again, we see Autonomous Systems (AS) claim an IP prefix they don’t own; it’s believed by everyone unless another network filters the claim, leading to a costly prefix-hijack that is all too common. Last year (2024), in the first quarter alone, more than 15,000 AS-level hijacks and leaks were reported by analysts, along with countless other micro-events littering CDN logs.

A BGP failure can soon cascade because it sits beneath TLS and zero-trust overlays. While a hijacked route’s traffic can’t be decrypted by the hijacker, the ciphertext is passed on, and the intermediary can delay, throttle, and discard whatever they like. Too many detours can have devastating results, especially in SaaS architectures with complex service meshes and multiple micro-services. One single path change can spawn thousands of failed API calls, desynchronize queues, and destroy tuned autoscaling heuristics. For example, an upstream’s acceptance of a forged /24 could misroute a payroll platform’s traffic into an unintended jurisdiction for about 14 minutes, during which transaction failures could spike to roughly 67%.

An AS 1 → AS 2 → AS 3 traffic flow is being advertised by rogue AS 4, misrouting users before filters kick in.

Resource Public Key Infrastructure (RPKI) is the industry’s solution. With around half of the global IPv4 table now covered by ROAs, invalid routes that once propagated widely stall at many networks due to RPKI enforcement. The progress comes at the hands of a growing cohort of operators, that Melbicom is proud to be a part of, that enforce a drop-invalid stance for all peering and transit edge.

How RPKI Mitigates Border Gateway Protocol Attacks

Protecting border gateways relies on origin validation. It is easy enough to deploy when you break it down into five disciplined phases:

Phase 3 is where the potential risk is at its highest. Consider the following: A cloud tenant originating a /22 from a forgotten AS; a DevOps team forgetting to extend an ROA before migrating to multi-cloud. So, you can see the importance of cleaning up to prevent outages when the day reject-invalid goes live. Tight prefix caps help. At Melbicom, we accelerate the process with 16 prefixes per session, as well as IRR vetting during onboarding and scheduled reviews. The customers are oblivious, but the hijacker with a bogus /24 can’t escape our edge.

The Importance of Strict IRR Filtering

As RPKI only covers around half of the IPv4 table as of yet, the gap must be closed with IRR filters until it becomes universal. A well-maintained route-object set needs to:

• Block any prefix outside of a customer’s allocation
• Reject RFC 1918 leaks.
• Attach max-prefix quotas to limit catastrophic full-table leaks.

The issue then becomes data hygiene: IRR entries don’t age well, and so prefix lists should be maintained from current IRR data and be constantly reviewed and only applied by engineers. IRR can’t substitute for RPKI, but together they can provide a solid layered defence. An IRR record can be forged by an attacker, but without acquiring a resource holder’s private key, forging a matching ROA is next to impossible.

Despite the risks, some hosts still accept a route “as-is”, but the strict IRR plus RPKI that Melbicom’s hardware employs gives our customers asymmetric protection, ensuring that only legitimately verified routes propagate outward while the announcements of hijackers die at the border.

Monitoring the Table With Real-Time Validation Dashboards

Even with filters, the table needs monitoring to ensure verification; luckily, BGP dashboards have significantly matured and can be watched in real-time. Failure to monitor in modern times is essentially negligence. Do the following:

• Public telemetry – Look for any sudden origin changes via Cloudflare Radar, RIPE RIS Live, and Qrator Radar, which stream updates.
• RPKI status portals – Validate routes through NIST RPKI Monitor or Cloudflare’s lookup, which will tell you whether a route is valid, unknown, or invalid.
• Local alerting – Use BGPalerter, a tool that feeds events into Slack, PagerDuty, or a SIEM, letting you know the instant an upstream accepts a new path.

These feeds are essentially data sets when working at a large scale. Melbicom’s NOC groups incidents by ASN and upstream, overlaying latency traces, meaning that engineers can see the RTT delta and user-impact scores when an unvalidated path creeps in, before the first ticket lands.

RPKI-ROV analysis of unique prefix-origin pairs (IPv4)

ROAs cover a little over half the IPv4 table, and invalids remain below 1 %.

Looking Forward: BGPsec and ASPA

Although RPKI authenticates the origin, it doesn’t validate the path. The future looks brighter with safeguards such as BGPsec and ASPA.

• BGPsec, once perfected, will further protect against tampering by sealing paths cryptographically by signing every AS hop. At the moment, live deployments are few and far between because the CPU and memory overheads and early hardware are currently struggling under full-table loads.
• AS Provider Authorisation (ASPA) links customer-provider relationships in RPKI, enabling routers to detect a leak should a customer suddenly appear to transit. In early testing, ASPA has been shown to catch over 90% of leaks missed by RPKI alone.

Conclusion: Secure Routing by Default

BGP security has grown from merely an academic talking point to an operational imperative in recent years. RPKI origin validation is now backed by half the table globally, and when enforced by security-minded networks, the blast radius for hijacking halves as well. Until ROA becomes universal, strict IRR filtering can help close the gap, aided by vigilant team monitoring through real-time dashboard feeds and alarms. Emerging technology is set to bring further control, with BGPsec and ASPA promising to validate paths and prevent leaks automatically in the years to come. All of which spells a future where hijacking will fade into the background.

Networks that drop invalids are dragging the rest of the industry forward. We at Melbicom committed early: edge routers on transit and peering links enforce drop-invalid, sessions are capped and IRR-verified during provisioning, and prefix events are actively monitored with real-time alerts. In a world where a single leaked /24 can crater latency or funnel traffic to a bogus site, that vigilance is non-negotiable.