How to Validate Proxy AS Paths with RPKI ASPA Before Production

Cloudflare Radar added an RPKI ASPA path-validation tool on 24 August 2026. It accepts a BGP AS_PATH and evaluates adjacent autonomous systems against published Autonomous System Provider Authorization records. For proxy buyers and operators, this is a useful new preflight signal: it can reveal whether the provider relationships implied by an observed route are consistent with the current ASPA data set.

It is not a proxy-quality score and it does not prove that an endpoint is residential, private, fast, or safe. Use it as one layer in a route-evidence workflow, alongside origin validation, endpoint identity, latency, session behavior, and contractual controls.

What ASPA validates

The public Internet is divided into autonomous systems, each identified by an ASN. A BGP AS_PATH is the ordered list of autonomous systems through which a route announcement has travelled. ASPA lets one AS publish which upstream providers are authorized to propagate its routes. A validator can then inspect customer-to-provider relationships along the path.

This helps detect some route leaks and malformed propagation patterns. It answers a narrow question: is the path relationship consistent with available ASPA records? It does not validate application traffic, encryption, proxy ownership, or the business identity behind an IP address.

Interpret the three outcomes correctly

An Unknown result is expected while deployment and coverage are incomplete. Treating Unknown as Invalid will reject legitimate routes; treating it as Valid will erase the distinction that the validator is designed to preserve.

Build a controlled proxy-route sample

Do not copy an arbitrary path from a public screenshot and attach it to a provider. Build evidence that links an observed proxy exit to a specific time, region, address family, and destination.

1. Select one proxy endpoint, one requested region, one destination you are authorized to test, and one stable session.
2. Record the timestamp in UTC, exit IP, IP family, observed origin ASN, proxy product, and session identifier that contains no secret.
3. Obtain the BGP path for the exit prefix from an approved route collector, your own network telemetry, or a provider-supplied diagnostic.
4. Preserve the collector vantage point because two networks can observe different valid paths at the same time.
5. Normalize the path without silently deleting meaningful ASNs. Document how confederations, sets, private ASNs, and prepending were handled.
6. Validate the normalized path and retain the result with the data-set timestamp.

Repeat the sample from at least two independent vantage points when the route will carry important production traffic. A single view can miss a localized leak or propagation anomaly.

Normalize without rewriting the evidence

AS paths often contain repeated ASNs because of prepending. Consecutive duplicates may be collapsed for a validator if its input contract requires that format, but keep the raw path beside the normalized version. Do not remove an ASN merely because it looks unexpected.

Use a record such as:

sample_id: eu-static-017
observed_at_utc: 2026-08-27T07:15:00Z
address_family: IPv4
collector_region: Western Europe
raw_as_path: 64500 64510 64510 64520 64530
normalized_as_path: 64500 64510 64520 64530
aspa_result: Unknown

Use documentation-safe example numbers in public material. Production evidence may contain real public ASNs, but it should remain in access-controlled operational records.

Run a four-part acceptance test

ASPA should be one gate in a larger route-acceptance matrix.

1. Origin authorization

Check whether the route origin and prefix length are consistent with the relevant RPKI Route Origin Authorization. Origin validation and ASPA path validation answer different questions; passing one does not imply passing the other.

2. Path relationship

Run ASPA validation on the observed path. Record Valid, Invalid, or Unknown without converting it into a binary score. For Invalid, capture the failing relationship if the tool exposes it.

3. Endpoint behavior

Verify the expected country, ASN, address family, DNS path, TLS behavior, first-attempt success, p50 and p95 latency, and sticky-session persistence. Route correctness cannot compensate for an endpoint that changes identity mid-session or fails the workload.

4. Commercial and compliance controls

Confirm permitted use, regional coverage, data handling, abuse response, retention, subprocessors, and incident escalation. A technically valid route is not automatically suitable for a regulated workflow.

Set practical decision rules

Use rules that preserve uncertainty instead of hiding it:

• Valid + stable endpoint: eligible for a controlled production cohort after the remaining checks pass.
• Valid + unstable endpoint: investigate proxy inventory or session behavior; ASPA does not override a failed endpoint test.
• Unknown + stable endpoint: allow only under the organization’s documented risk threshold, with monitoring and a recheck schedule.
• Invalid once: reproduce from a second vantage point and rule out collection or normalization errors.
• Invalid repeatedly: quarantine the affected prefix or route, stop automatic expansion, and send the provider the raw path, vantage point, address family, and timestamps.

Do not rotate away from every Invalid result and discard the evidence. That makes the user-visible symptom disappear while preventing the network team or provider from diagnosing the relationship.

Automate a low-noise monitor

Run validation when a new prefix or origin ASN enters the pool, when a region changes upstream path, after a routing incident, and on a modest periodic schedule. Validating every request provides little additional value and can create unnecessary external load.

Store these fields:

• proxy product and requested region;
• exit prefix and address family;
• origin ASN and raw AS path;
• collector or telemetry vantage point;
• observation and validation timestamps;
• ASPA result and data-set version;
• ROA origin status;
• endpoint test result;
• previous result and change reason;
• incident or provider ticket reference.

Alert on a transition to Invalid, a new origin ASN, a material path change, or disagreement between independent vantage points. A transition from Unknown to Valid is useful audit evidence but usually does not require an urgent alert.

Procurement checklist

• Ask which ASNs originate the advertised proxy ranges.
• Request a process for reporting routing anomalies and route leaks.
• Confirm whether new upstreams or origin ASNs are announced to customers.
• Sample both IPv4 and IPv6; do not infer one from the other.
• Test every purchased geography rather than one flagship region.
• Keep raw and normalized AS paths with timestamps.
• Combine ASPA, ROA, endpoint, session, and performance evidence.
• Define quarantine and re-entry criteria before an incident.
• Revalidate when prefixes, providers, or routing policy change.

FAQ

Does a Valid result prove that a proxy IP is residential?

No. ASPA evaluates AS-provider relationships in a BGP path. Residential classification requires separate inventory, ASN, access-network, and contractual evidence.

Is Invalid always an attack?

No. It can reflect a route leak, a configuration error, stale or mismatched observations, or an input-normalization mistake. Reproduce the path before escalating, but do not ignore a persistent Invalid result.

Can Unknown routes be used?

That depends on the workflow’s risk threshold. Unknown means insufficient ASPA evidence, not failure. Apply additional controls, limit exposure, and schedule revalidation.

Does ASPA replace ROA validation?

No. ROA validation checks whether an origin AS is authorized for a prefix. ASPA examines provider relationships along the AS path. Use both.

Compliance note

Validate only routes and endpoints you are authorized to test. Do not use proxy infrastructure to bypass authentication, access controls, contractual restrictions, or destination policies. Minimize retained network and user data, restrict access to operational evidence, and follow applicable privacy, telecommunications, and incident-reporting requirements.

Continue with the IPv6 proxy path testing guide, the residential proxy session-stickiness test, and the proxy-versus-target control-route plan.

Internal research record: Cloudflare Radar, RPKI ASPA path validation launch, 24 August 2026; IETF SIDROPS, ASPA verification draft, work in progress.