BGP Route-Leak Defense 2.0 — RFC 9234 Roles + ASPA Operator Playbook

Date: 2026-03-28
Category: knowledge
Audience: ISP / IX / backbone network operators, peering engineers, NOC/SRE

1) Why this matters now

Route Origin Validation (ROV) made origin hijacks harder, but it does not verify whether an AS path is policy-plausible end-to-end.

• RFC 7908 frames route leaks as announcements propagated beyond intended policy scope.
• RFC 9234 adds in-band role negotiation and OTC signaling to reduce leak creation/detection gaps.
• ASPA (IETF SIDROPS drafts) adds cryptographic provider authorization for AS_PATH plausibility checks.

Practical takeaway: ROV alone is not enough for route-leak resilience. You need a layered control stack.

2) The layered model (what each layer catches)

Layer A — ROA/ROV (origin correctness)

• Validates: “Is this AS authorized to originate this prefix?”
• Misses: many policy leaks and forged-but-origin-valid path manipulations.

Layer B — RFC 9234 Roles + OTC (session/path-policy enforcement)

• Negotiates BGP relationship intent in OPEN.
• Uses OTC to tag paths learned from non-customers and prevent improper propagation.
• Helps prevent local misconfiguration from becoming global leaks.

Layer C — ASPA verification (AS_PATH plausibility)

• Uses signed customer→provider attestations in RPKI.
• Detects implausible customer/provider transitions and valley violations.
• Output model: Valid / Unknown / Invalid.

The strongest posture is A + B + C together.

3) ASPA in one page (2026 status)

ASPA is specified in active SIDROPS drafts (profile + verification), not yet final RFC at the time of writing.

Core model:

• A customer AS publishes signed object(s) listing authorized upstream providers.
• Validators ingest ASPA objects and expose validated payloads over RTR.
• Routers run ASPA path verification on ingress and classify received routes.

Important registration guidance from draft-ietf-sidrops-aspa-verification:

1. Include all provider ASes (and non-transparent RS ASes where relevant).
2. In complex relationships, include neighbors that play provider role for any subset.
3. Prefer one ASPA object per customer AS to reduce race conditions.
4. Keep “backup/surge” providers pre-listed when possible.

4) RFC 9234 + ASPA are complementary, not alternatives

A frequent mistake is treating ASPA as a replacement for RFC 9234 controls.

Per the ASPA verification draft, ASPA may fail to stop:

• leaks initiated by the local AS itself toward a neighbor,
• some complex-relationship edge cases.

That is exactly where RFC 9234 OTC helps.
So operationally:

• deploy roles + OTC first where possible,
• then add ASPA verification and policy enforcement.

5) Safe deployment sequence (recommended)

Phase 0 — Hygiene baseline

• Ensure ROA/ROV is stable first.
• Confirm IRR/prefix-limits/max-prefix and basic ingress sanity are healthy.
• Establish telemetry baselines (update volume, leak alarms, rejected-route counters).

Phase 1 — Enable RFC 9234 roles/OTC

• Configure per-neighbor role intent (provider/customer/peer/rs/rs-client).
• Prefer role cross-check enforcement on sessions that can support it.
• Track session failures due to role mismatch before broad enforcement.

Phase 2 — Enable ASPA in RP + RTR pipeline

• Upgrade validator/router stack to components that can carry ASPA payloads.
• If using Routinator, explicitly enable ASPA (--enable-aspa or config flag).
• Ensure RTR version compatibility (ASPA payload transport requires updated RTR support; OpenBGPD docs call out minimum RTRv2 for ASPA sync).

Phase 3 — Observe-only policy

• Ingest ASPA states but do not hard-drop at first.
• Monitor Invalid and Unknown by neighbor, prefix, and customer cone.
• Verify false-positive patterns (stale or incomplete provider lists).

Phase 4 — Controlled enforcement

• Start rejecting clearly invalid routes in lower-risk edges first.
• Keep Unknown = accept during partial ecosystem adoption.
• Expand scope gradually to transit/peer edges after stability proof.

6) Policy matrix (pragmatic defaults)

This aligns with draft guidance that Unknown should be treated at Valid preference and Invalid should be made ineligible.

7) Operational gotchas that cause outages

1. Forgetting one upstream in ASPA
   Routes via that upstream can become Invalid at ASPA-aware networks.

2. Treating ASPA as set-and-forget
   Provider changes must be reflected quickly (change-management coupling required).

3. Dropping Unknown too early
   During partial adoption, this can self-inflict reachability loss.

4. No role discipline
   Without RFC 9234 role correctness and OTC, local leaks can still escape.

5. Weak observability
   If you cannot answer “why invalid?” per prefix/peer, you are not ready for hard enforcement.

8) Minimal telemetry you should keep

• Count of routes by ASPA state (Valid/Unknown/Invalid) per edge session.
• Top AS_PATH pairs causing Invalid (candidate bad provider assertions).
• Prefix impact list for each Invalid event.
• Time-to-fix for ASPA data mismatches (provider omitted, stale object).
• Session role mismatch counters for RFC 9234 capability checks.

Alerting suggestions:

• spike in Invalid rate,
• sudden increase of Unknown on a specific validator/RTR cluster,
• abrupt session resets tied to role-capability mismatch.

9) Quick readiness checklist

Before turning on Invalid-drop globally, verify all boxes:

• ROV already stable in production.
• RFC 9234 roles configured on major eBGP edges.
• OTC handling enabled where platform supports it.
• Validator + RTR path exports ASPA payloads reliably.
• ASPA objects include all active + contingency providers.
• NOC has runbook for Invalid triage and emergency exception.
• Unknown paths are accepted (unless exceptional, controlled policy).

If any of these are missing, stay in observe-only mode longer.

10) Bottom line

For modern inter-domain defense, think in layers:

1. ROV for origin integrity,
2. RFC 9234 roles/OTC for policy-aligned propagation,
3. ASPA for cryptographic AS_PATH plausibility.

The winning strategy is not “flip one switch.” It is incremental rollout + strict data hygiene + good telemetry.

References

1. RFC 7908 — Problem Definition and Classification of BGP Route Leaks
   https://www.rfc-editor.org/rfc/rfc7908

2. RFC 9234 — Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages
   https://www.rfc-editor.org/rfc/rfc9234

3. IETF Draft — A Profile for Autonomous System Provider Authorization
   https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-profile

4. IETF Draft — BGP AS_PATH Verification Based on ASPA Objects
   https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification

5. RIPE NCC — Autonomous System Provider Authorization (ASPA)
   https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/aspa/

6. Routinator docs — Advanced Features (ASPA enablement)
   https://routinator.docs.nlnetlabs.nl/en/stable/advanced-features.html

7. NLnet Labs — Routinator 0.14.1 released (ASPA inclusion note)
   https://nlnetlabs.nl/news/2025/Jan/22/routinator-0.14.1-released/

8. OpenBSD bgpd.conf(5) manual (role/OTC/ASPA-related knobs)
   https://man.openbsd.org/bgpd.conf

9. RIPE Labs — ASPA in the RPKI Dashboard (implementation/deployment commentary)
   https://labs.ripe.net/author/tim_bruijnzeels/aspa-in-the-rpki-dashboard-a-new-layer-of-routing-security/