CONCEPT Cited by 1 source
Customer-provider relationship (BGP)¶
A customer-provider relationship is one of the two primary pairwise business relationships between ASes: the customer pays the provider for Internet transit. This single relationship drives the per-side export policy that, applied consistently, yields valley-free routing.
Export policy per side¶
- Provider → customer: advertise all routes the provider knows (i.e. the full Internet table).
- Customer → provider: advertise only the customer's own routes + its own downstream customers' routes.
Crucially, the customer does not advertise routes learned from other providers or peers upstream to this provider. That would re-expose the customer as a transit conduit between two providers — a Type 1 hairpin leak.
Direction matters for forensics¶
In route-leak forensics, who is whose customer is the
load-bearing detail — see the Cloudflare Venezuela post.
Tools like BGPKIT monocle expose
this explicitly via the as2rel query (its output separates
peer from as1_upstream from as2_upstream). If the
suspected attacker is already on-path as the suspected
victim's provider, the interception motive vanishes: they
already see that traffic.
How the relationship is inferred¶
There is no protocol-level "relationship" field in BGP; it's inferred from observed AS paths across public route collectors:
- If most paths containing AS-A and AS-B have AS-A appearing towards the source (closer to the sender), AS-A tends to be the provider.
- If most paths have AS-A and AS-B appearing at the same depth across many paths, peer-peer is plausible.
Route-collector datasets (RIPE RIS, RouteViews) feed this
inference; BGPKIT's as2rel-latest.json.bz2
is one redistribution of the result.
Seen in¶
- sources/2026-01-08-cloudflare-a-closer-look-at-a-bgp-anomaly-in-venezuela — AS8048's customer-provider relationship to AS21980 (AS8048 is upstream of AS21980) is the single most load-bearing fact in Cloudflare's argument for non-malicious intent.