Internet Routing & Core Infrastructure Security: BGP Hijacking, RPKI Validation & Kaminsky DNS Cache Poisoning

1. Fragility of the Core Internet Routing Substrate

The global Internet was designed as an open, collaborative research network where routing nodes implicitly trusted peering partners. Today, the foundational control plane protocols—the Border Gateway Protocol (BGP) for routing and the Domain Name System (DNS) for name resolution—underpin multi-trillion-dollar global economies. However, their fundamental lack of cryptographic verification makes the Internet substrate vulnerable to traffic interception, nation-state surveillance, and global denial-of-service.

2. BGP Architecture & The Mechanics of BGP Hijacking

The Border Gateway Protocol (BGP-4, RFC 4271) coordinates routing decisions between tens of thousands of Autonomous Systems (ASNs) across the globe. BGP routers exchange Network Layer Reachability Information (NLRI) containing IP prefixes and the AS-Path sequence representing the transit hops required to reach that prefix.

The Longest-Prefix Match Vulnerability

BGP operates on a deterministic routing rule: Longest-Prefix Match. If two conflicting routes exist in a router’s Routing Information Base (RIB), the router unconditionally forwards traffic to the route with the most specific prefix (the longest subnet mask), regardless of path length or administrative preference.

+-------------------------------------------------------------+
|                   BGP Route Hijack Scenario                 |
|                                                             |
|  [ Legitimate Enterprise (AS 15169) ]                       |
|  Announces: 198.51.100.0/24                                 |
|                                                             |
|  [ Rogue / Hostile Network (AS 65001) ]                     |
|  Announces More Specific Subnets:                           |
|    - 198.51.100.0/25                                        |
|    - 198.51.100.128/25                                      |
|                                                             |
|  Global Tier-1 ISPs (L3, Telia, Cogent)                     |
|  -> Evaluate /25 as More Specific than /24                  |
|  -> All Global Traffic for 198.51.100.0/24 Diverts to AS 65001!|
+-------------------------------------------------------------+

When an attacker announces a more specific prefix (e.g. splitting a legitimate /24 into two /25 subnets), global Internet traffic instantly diverts to the attacker’s Autonomous System. Attackers blackhole traffic or inspect, copy, and forward traffic to the original destination (Adversary-in-the-Middle).

3. Defending the Routing Plane: RPKI & Route Origin Authorization

Resource Public Key Infrastructure (RPKI, RFC 6480) establishes a cryptographically verifiable public key infrastructure for internet routing. Managed by the five Regional Internet Registries (RIRs – ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), RPKI allows resource holders to create signed digital certificates called Route Origin Authorizations (ROAs):

• ROA Structure: A ROA specifies three elements: the authorized IP prefix, the authorized Origin ASN, and the Maximum Prefix Length (MaxLength).
• Route Origin Validation (ROV): BGP routers run local validators (Routinator, Stayrtr) that fetch and cryptographically verify all global ROAs. When a BGP route announcement is received, the router assigns one of three validation states:
  1. Valid: Prefix and origin ASN match a signed ROA, and the announced prefix length is less than or equal to MaxLength.
  2. Invalid: Prefix matches a ROA, but origin ASN does not match, or prefix length exceeds MaxLength. (Traffic is dropped).
  3. NotFound (Unknown): No ROA exists covering the prefix. (Traffic accepted under legacy routing rules).

4. DNS Cache Poisoning & The Kaminsky Attack

The Domain Name System translates human-readable hostnames into IP addresses via UDP port 53. Because UDP is stateless, recursive resolvers are vulnerable to spoofing. Historically, resolvers matched responses to queries using only a 16-bit Transaction ID (TXID), providing only 65,536 combinations.

The Dan Kaminsky Flaw (2008)

Prior to 2008, an attacker attempting to poison example.com had to wait for the legitimate cache TTL to expire. Dan Kaminsky discovered a devastating flaw that bypassed the TTL restriction entirely:

1. The attacker queries the target recursive resolver for non-existent random subdomains: rand1.example.com, rand2.example.com.
2. Because the subdomain is not cached, the recursive resolver immediately sends an authoritative query out to the legitimate authoritative nameserver.
3. The attacker floods the resolver with thousands of spoofed UDP response packets containing guessed Transaction IDs. Crucially, the response includes an Authority Section declaring the attacker’s nameserver as the authoritative NS for the entire parent domain: example.com NS ns.attacker.com.
4. When one of the guessed TXIDs matches the pending query, the resolver accepts the poisoned NS record, routing all future queries for the entire corporate domain to the attacker.

5. Modern DNS Hardening: Source Port Randomization & DNSSEC

A. Source Port Randomization (SPR)

To mitigate Kaminsky attacks, modern resolvers randomize both the 16-bit Transaction ID and the 16-bit UDP source port (Ephemeral Port range 1024-65535). This expands the attacker’s search space from ( 2^{16} ) (65,536) to ( 2^{32} ) (( approx 4.3 times 10^9 )), making blind brute-force guessing computationally infeasible before legitimate responses arrive.

B. Domain Name System Security Extensions (DNSSEC)

DNSSEC (RFC 4033) introduces cryptographic authentication to DNS responses without altering transport mechanisms. Every record set (RRSET) is digitally signed with an RRSIG record using public key cryptography:

[ Root Zone (.) ] ── (Signs DS Record) ──> [ .COM TLD ]
                                                │
                                                ▼ (Signs DS Record)
                                       [ Example.com Zone ]
                                                │
                                                ▼
                                    [ RRSIG Signs A Record ]

• Chain of Trust: Resolvers validate digital signatures recursively from the authoritative zone up through TLDs to the Root Zone Trust Anchor.
• Authenticated Denial of Existence: NSEC and NSEC3 records cryptographically prove that a requested domain name does not exist, preventing wildcard spoofing.

6. Infrastructure Security Hardening Checklist

• Publish RPKI ROAs: Create signed ROAs with your Regional Internet Registry (ARIN/RIPE) for all enterprise public IP subnets. Set the MaxLength strictly equal to your advertised prefix length to prevent sub-prefix hijacks.
• Enable BGP Route Origin Validation (ROV): Configure border BGP edge routers to unconditionally drop Invalid BGP announcements.
• Deploy DNSSEC Validation: Enforce DNSSEC cryptographic validation across all corporate recursive DNS resolvers.
• Implement DNS over HTTPS/TLS (DoH/DoT): Protect client-to-resolver communication channels against local network eavesdropping and tampering.

Threat Hunting & Strategic Attribution Playbook

Converting forensic findings into actionable threat intelligence requires rigorous adherence to intelligence analysis standards:

1. Diamond Model Activity Threading: Correlate the observed adversary capability (malware, exploits) and infrastructure (C2 domains, IP blocks, JARM hashes) against known threat actor profiles in MITRE ATT&CK. Establish analytical confidence using the Admiralty Code.
2. Passive DNS & Infrastructure Pivoting: Query historical passive DNS (pDNS) repositories to map the attacker’s broader hosting topology. Identify SSL/TLS certificate reuse, common WHOIS registrant attributes, and co-located command servers.
3. Defensive Engineering via MITRE D3FEND: Map identified adversary TTPs to corresponding D3FEND defensive countermeasures. Deploy canary credentials, harden process execution policies, and implement network micro-segmentation to permanently deny the threat actor operational access.
4. Automated STIX/TAXII Threat Sharing: Package validated threat intelligence into standardized STIX 2.1 JSON bundles. Automate TAXII feed publication to SIEM, SOAR, and perimeter firewall blocklists for automated threat neutralization.