On this page
Key points
- Risk happens before the serverTraffic can be diverted before reaching infrastructure.
- Hijack and DDoS can combineRouting abuse can bypass or amplify an attack.
- Prevention is measurableRPKI, BGP monitoring and withdrawal procedures reduce risk.
Defining the problem
An origin hijack occurs when an AS announces a prefix owned by another network. A more-specific hijack announces a longer prefix, such as a /24 inside a larger block, and often attracts more traffic. A route leak may be accidental but can still create unexpected paths.
For the affected company, packets no longer follow the intended path. They may disappear, cross an unauthorized network, bypass a DDoS platform or create extreme latency. Support sees an outage, but the root cause sits in BGP.
The dangerous part of a hijack is that the service may look healthy internally. Servers, firewalls and load balancers can show normal CPU and no attack, because the traffic has already been diverted somewhere else.
Why this matters
Many DDoS strategies assume traffic reaches the mitigation network. If a more-specific route diverts the prefix, traffic can avoid the scrubbing center entirely. A partner mistake can have the same effect as an attacker.
The commercial impact is high: partial outages by country, lost sessions, confusing DNS symptoms and DDoS dashboards showing nothing because traffic is elsewhere. Server-only monitoring wastes time.
Attackers do not need to sustain huge packet rates if they can manipulate reachability. A short routing incident can create customer-visible downtime, confuse incident response and hide the real DDoS source path.
Possible solutions
The first defense is routing hygiene: correct IRR objects, maintained AS-SET, prefix limits, inbound and outbound filters and clear documentation of authorized prefixes.
The second defense is RPKI/ROA. ROAs state which AS can originate a prefix and which maximum length is valid. They do not solve everything, but they reduce invalid announcements when networks validate.
The third defense is active monitoring: origin changes, unexpected more-specifics, sharp traffic drops on the protected path and visibility changes from multiple collectors.
RPKI should be paired with monitoring. A valid ROA does not help if no one alerts on a competing origin, and monitoring without a response contact list only confirms the outage faster.
- BGP hygiene
- IRR, AS-SET, prefix limits and filters avoid many mistakes.
- RPKI/ROA
- Reduces invalid origins when validation is applied.
- External monitoring
- Detects what servers cannot see.
| Risk | Symptom | Defense |
|---|---|---|
| Origin hijack | Wrong AS visible | ROA + origin alerts |
| More-specific | Traffic attracted elsewhere | Careful max-length + monitoring |
| Route leak | Unexpected paths | Filters and clean AS-SET |
Concrete use case
A hoster announces its /24 through a DDoS network. During an attack, another AS mistakenly announces the same /24 or a more-specific route. Some users no longer reach the hoster, but scrubbing graphs stay low.
With ROAs, transit filters and origin-change alerts, the incident is detected faster. The team can contact the faulty network, request filtering, adjust announcements or activate a backup plan.
The same process helps during planned changes. If a customer moves a prefix to protected transit, external visibility confirms that the change is seen as intended and that old announcements do not remain active.
Frequent mistakes
The most common mistake is separating BGP security from DDoS protection. Users only see that the service is unavailable.
A common error is creating a ROA that authorizes too many more-specifics. It may make operations feel easier, but it weakens the protection against unauthorized longer-prefix announcements.
- Creating ROAs with an overly broad max-length.
- Not maintaining IRR and AS-SET after customer changes.
- Missing prefix limits on BGP sessions.
- Monitoring only servers, not global route visibility.
- Waiting for an incident to find transit escalation contacts.
FAQ
Is route hijacking always malicious?
No. Many incidents are configuration mistakes or route leaks.
Does RPKI stop all hijacks?
No. It reduces invalid announcements when ROAs and validation are correct.
How is it related to DDoS?
A hijack can bypass mitigation or create an outage that looks like an attack.
What should be monitored first?
Prefix origin, more-specifics, collector visibility and traffic drops on the protected path.
