Sascha's Toolbox
• 5 min read
Infrastructure Networking BGP Security RPKI Compliance

GP Hijacking: The Internet’s Original Sin and the Paradox of Scale

GP Hijacking: The Internet’s Original Sin and the Paradox of Scale

The global internet is not a single, cohesive entity managed by a central authority. It is a loose federation of approximately 75,000 Autonomous Systems (AS)—independent networks managed by ISPs, universities, and tech giants—held together by a protocol designed in 1989 on the back of a few napkins.

This is the Border Gateway Protocol (BGP). It is the “Postal Service” of the internet, and it operates on a principle that would be considered a catastrophic security failure in any other layer of the stack: Implicit Trust.

The Mechanism: How BGP Dictates Reality

To understand a BGP hijack, you must understand NLRI (Network Layer Reachability Information). BGP doesn’t route based on “addresses”; it routes based on “paths.” When a router wants to tell the world it has a destination, it sends a BGP Update message containing a list of Path Attributes (PAs).

The Best Path Algorithm

Routers receive multiple updates for the same prefix and must decide which one to install in their RIB (Routing Information Base). While there are many tie-breakers (Weight, Local Preference, Origin), the most critical for global stability is the AS_PATH.

  1. Prefix Propagation: AS1234 announces 1.2.3.0/24.
  2. AS_PATH Prepending: As this announcement moves across the world, each network adds its own AS number to the list.
  3. Shortest Path Wins: A router at AS9999 sees two paths for 1.2.3.0/24:
    • Path A: AS555 AS444 AS1234 (3 hops)
    • Path B: AS888 AS1234 (2 hops)
    • Result: The router chooses Path B and ignores Path A.

The Anatomy of a Hijack: A Terminal Post-Mortem

The vulnerability lies in the fact that BGP accepts these path announcements without verifying ownership. Here is what a Prefix Hijack looks like on a Cisco/Aruba-style CLI during an event:

# show ip bgp 1.2.3.0/24
BGP routing table entry for 1.2.3.0/24, version 45678
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     1          2
  Path 1: AS_PATH 65001 701 1234 (Valid, Internal, Not Best)
    192.0.2.1 from 192.0.2.1 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, valid, internal
  
  Path 2: AS_PATH 65001 999 555 (Best)  <-- THE HIJACK
    203.0.113.5 from 203.0.113.5 (172.16.0.5)
      Origin IGP, metric 0, localpref 150, valid, external

In this scenario, AS555 (the hijacker) has announced a more “attractive” path (or a more specific prefix, like a /25) than the legitimate owner, AS1234. Because Path 2 has a higher Local Preference or a shorter path, the router silently diverts all traffic destined for 1.2.3.0/24 to the hijacker’s infrastructure.

The Macro-Micro Paradox: ISO vs. Infrastructure

As a Senior Director, I find the delta between our Micro-Compliance and our Macro-Fragility to be the ultimate engineering irony.

  • The Micro Level (ISO/SOC2/TISAX): We subject our internal systems to grueling audits. We document every “Change Request.” We lose certification points if a single developer’s access isn’t revoked within 24 hours. We meticulously polish the doorknobs on a house built on a “sidewalk” of absolute granularity.
  • The Macro Level (BGP): The very backbone that carries our audited, encrypted, and “compliant” data is susceptible to a “fat-finger” configuration error half a world away. A single engineer at a Tier-3 ISP can bypass every “High-Side” security control you’ve implemented by simply misconfiguring a route-map.

The Solution: RPKI and Cryptographic Origin Validation

The industry’s response to this “Original Sin” is RPKI (Resource Public Key Infrastructure). RPKI replaces implicit trust with explicit, cryptographic proof of ownership.

The ROA (Route Origin Authorization)

An owner creates a ROA, a signed object that specifies which AS is authorized to originate a particular prefix.

{
  "asn": "AS1234",
  "prefix": "1.2.3.0/24",
  "maxLength": 24,
  "ta": "RIPE NCC"
}

Route Origin Validation (ROV)

When a router receives a BGP update, it checks the prefix/ASN pair against a local cache of the RPKI database. This produces a Validation State:

# show ip bgp 1.2.3.0/24
BGP routing table entry for 1.2.3.0/24
Paths: (1 available, best #1)
  65001 999 555
    203.0.113.5 from 203.0.113.5
      RPKI State: Invalid (ASN 555 is not authorized for 1.2.3.0/24)
      Action: Route Rejected (Policy: DROP_INVALID)

The Systemic Hurdles of RPKI Adoption

If the solution exists, why is the internet still breaking?

  1. The Geopolitical Trust Anchor: RPKI relies on the five Regional Internet Registries (RIRs) to act as the “Certificate Authorities.” This introduces a layer of centralized trust that many operators—particularly in regions sensitive to US or European influence—view as a sovereignty risk.
  2. The Partial Protection Gap: RPKI only works if the receiving router actually drops “Invalid” announcements. If your upstream provider accepts an “Invalid” route because they haven’t implemented Route Origin Validation (ROV), your data is still at risk.
  3. Hardware Lifecycle: Validating millions of prefixes against a cryptographic database requires NPU/CPU cycles. For legacy “Edge” routers, this is a non-trivial performance tax that often requires a forklift upgrade.

The Architect’s Pivot: Pressure the Upstream

We cannot fix the global routing table individually, but we can address the Communication Debt that allows this fragility to be ignored.

  1. Upstream Audit: Do not just ask your ISP about their “99.99% Uptime.” Ask if they implement MANRS (Mutually Agreed Norms for Routing Security). If they don’t enforce RPKI/ROV, they are a liability to your true compliance posture.
  2. BGP Telemetry: Utilize tools like BGPStream or Cisco ThousandEyes to monitor your prefixes. You need to know when your data takes a “Desire Path” through an unvetted AS.
  3. The Compliance Realignment: We should begin pushing for “Macro-Infrastructure” requirements in our SOC2 and ISO audits. It is time the “sidewalk” auditors started looking at the “road” we use to get to work.

Infrastructure is only as strong as its weakest peer. In the world of BGP, we are all peered with the entire world.

Technical References & Fact Checks

  • BGP Protocol Specification: IETF RFC 4271: A Border Gateway Protocol 4 (BGP-4). Link
  • RPKI Deployment Statistics: NIST: RPKI Monitor. Link
  • MANRS Implementation: Mutually Agreed Norms for Routing Security. Link
  • Google Outage Post-Mortem: ThousandEyes: Analysis of the 2018 Google/MainOne BGP Hijack.
  • ISO 27001 Context: ISO/IEC 27001:2022 - Control A.8.14 (Network Security).
← Back to all posts