Enforcing the First AS in BGP AS PATHs (opens in new tab)
Forged BGP AS_PATHs can let attackers impersonate legitimate networks, misdirect traffic, and conceal their true origin. Recent hijacks suggest some providers accept routes whose first AS does not match the customer peer that advertised them. Enforcing this “First AS” relationship check is a straightforward defense that complements RPKI and ASPA. ## Route Hijacks Involving Forged Paths - A reported hijack of Orange’s `90.98.0.0/15` included the path: `48237 1299 199524 270118 17072 41128`. - The path implied implausible commercial relationships: - `AS41128` was an unused Orange ASN. - `AS17072` was a Mexican ISP. - `AS270118` was a Mexican hosting provider. - `AS199524` was Gcore. - `AS1299` was Arelion, a Tier 1 provider. - Another hijack included Cloudflare’s ASN in the path: `199524 270118 17072 13335 36429`. - Cloudflare confirmed it had no adjacency with the unused `AS36429`, indicating that the path was fabricated. - The routes appeared to terminate behind Gcore rather than actually traversing the networks listed in the forged path. - The suspected attack sequence was: - Announce parked or unused prefixes. - Completely forge the AS_PATH without including the attacker’s ASN. - Send the route to Gcore. - Rely on the provider accepting the route without verifying its first AS. - Once accepted, the forged route could be propagated to upstream providers and peers. ## Why First AS Checking Matters - The BGP AS_PATH records the networks a route is expected to traverse. - It supports: - Route selection. - Loop prevention. - Operator routing policies. - BGP permits AS_PATH manipulation for legitimate purposes, such as AS prepending, but the same flexibility enables attackers to shorten or fabricate paths. - First AS enforcement verifies that the first AS in an advertised path matches the ASN of the customer or peer that sent the update. - Without this check, a customer can advertise a path that appears to originate from another network. ## Limits of RPKI and ASPA Alone - RPKI ROAs validate whether an origin ASN is authorized to announce a prefix. - ASPA validates provider-to-customer relationships. - However, an attacker may still bypass these mechanisms by: - Claiming an RPKI-valid origin ASN. - Including a legitimate ASPA provider in the forged path. - Omitting the attacker’s own ASN when the receiving provider does not enforce First AS. - In the example, a route forged to appear as though it originated from `AS64506` could remain RPKI-valid and attract traffic if `AS64502` accepted it without checking the peer’s first AS. ## Practical Recommendation Network operators should enable strict First AS checking on BGP sessions, alongside RPKI route-origin validation and ASPA deployment. These controls address different parts of the attack: RPKI validates the origin, ASPA checks authorized provider relationships, and First AS enforcement prevents a peer from presenting a path that does not begin with its own ASN.