Day 59 — RPKI Route Origin Validation: ROAs, Valid, Invalid and NotFound

1. Opening

RPKI Route Origin Validation answers a narrow but powerful question: is the origin AS in this BGP route authorized by the address-space holder to originate this prefix? It does not validate the entire AS path, and it does not automatically decide whether the router should accept or reject the route.

The recurring design principle in this security block is fail safely without confusing safety with availability. A routing control can prevent a leak and still cause an outage if thresholds, recovery logic or operator assumptions are wrong. The engineer must therefore define both the threat being contained and the service consequence of containment.

2. Concept and standards behavior

RFC 6811 defines origin validation states. RFC 8481 clarifies that all routes should receive a validation state and that validation itself must not silently impose routing policy. RFC 9582 is the current ROA profile and obsoletes RFC 6482. A ROA binds an authorized AS to one or more prefixes and may include maxLength to authorize more-specific announcements.

Protocol behavior, standards recommendations, vendor implementation and local routing policy are deliberately separated. A standards document may define a capability or validation state; the router still needs explicit configuration to decide what operational action follows.

3. Scenario

Create three lab announcements for 203.0.113.0/24: one from the authorized AS and prefix length, one from an unauthorized origin AS, and one for which the simulated RPKI dataset has no covering authorization. Classify each as Valid, Invalid or NotFound before applying any routing policy.

Common lab topology

Customer AS65010 ---- Edge-1 ---- Transit-A AS65020
          |              |
          |              +---- Transit-B AS65030
          |
      203.0.113.0/24

Documentation prefixes and private ASNs are used throughout. The topology is intentionally small enough that every prefix and policy decision can be traced manually.

Success criteria

1. The protection mechanism detects the intended unsafe condition.
2. Normal routes remain reachable during the healthy state.
3. The failure action is predictable and documented.
4. A negative test proves that an unauthorized route or state is rejected/contained.
5. Rollback restores the captured baseline without weakening unrelated controls.

4. Topology diagram

A matching SVG and PNG are stored in media/diagrams/.

5. Prerequisites

• IOS XE 17.18.x documentation baseline.
• Stable eBGP sessions.
• Explicit prefix inventory and expected route counts where applicable.
• Independent management access.
• Logging and time synchronization.
• For RPKI labs: a separate validator/cache is assumed; no private keys or real production ROAs are distributed.

6. Baseline configuration

Topic-specific configuration excerpt — not a complete deployable configuration.

router bgp 65010
 address-family ipv4
  ! Enable origin validation only after an RPKI cache/server
  ! is configured and exact IOS XE syntax is verified.
 exit-address-family
!
! Do not create real ROAs for documentation prefixes in this lab.

Any command whose exact support differs by platform must be checked against the target image before execution.

7. Verification before modification

show bgp ipv4 unicast summary
show bgp ipv4 unicast
show bgp ipv4 unicast neighbors
show logging

Topic-specific verification may add show bgp ... dampening, RPKI cache/validation output, received-prefix counts or neighbor capability/policy detail. The important question is always: what evidence proves the mechanism is acting on the intended object?

8. Controlled modification

Introduce a simulated ROA authorizing AS65020 to originate 203.0.113.0/24 with maxLength /24. Re-evaluate the three test announcements and record their validation states.

Predict the effect on the BGP session, Loc-RIB, Adj-RIB-In/Out and forwarding state before applying the change.

9. Fault injection

Illustrative lab — not a real incident.

Change the origin of the /24 to AS65030 while retaining the authorization for AS65020. The route should classify Invalid under the simulated validated data.

Inject exactly one fault and preserve the pre-fault evidence. Do not change multiple safety controls simultaneously.

10. Step-by-step troubleshooting

1. Confirm the affected peer and prefixes.
2. Confirm the BGP session state.
3. Confirm the expected baseline route count or route set.
4. Inspect the configured safety/validation mechanism.
5. Determine whether the mechanism changes state, rejects routes, or resets a session.
6. Inspect logs/NOTIFICATIONs/validation status.
7. Distinguish protocol state from operator policy.
8. Verify forwarding separately from BGP-table presence.
9. Test the approved positive case.
10. Test the forbidden/invalid case.
11. Correct the smallest proven cause.
12. Re-run the same evidence set and observe stability.

11. Root cause and correction

The origin AS does not match the authorization. Correct the BGP origination or the legitimate ROA—whichever is actually wrong. Never publish a broader ROA merely to make an unexpected route become Valid.

12. Post-fix verification

Verify BGP state, accepted prefix count, selected path, validation/policy state where relevant, forwarding, negative containment and recovery behavior.

13. Rollback

Restore the exact previous safety threshold or policy. Preserve evidence before clearing sessions. If rollback would re-open a known leak path or accept invalid routing data, use an approved temporary containment policy rather than blindly removing the control.

14. Deep-dive engineering notes

Valid

A route is Valid when a covering validated ROA authorizes the route's origin AS and prefix length.

Invalid

A route is Invalid when relevant validated authorization exists but the announcement conflicts with it—for example wrong origin AS or a prefix length longer than the authorized maxLength.

NotFound

NotFound means the validator has no covering validated ROA information that makes the route Valid or Invalid. It does not mean the route is malicious.

maxLength risk

A broad maxLength can authorize more-specifics that the holder did not intend to originate. Make ROAs as precise as operational routing requires.

Validation is not action

RFC 8481 is critical: the implementation sets state; the operator chooses policy. A common production policy is to reject Invalid, but that is a policy decision and rollout should be measured.

Origin versus path

ROV validates the origin authorization, not every AS in AS_PATH. BGPsec/ASPA-related mechanisms address different security properties.

15. Production lessons

• Teach ROV as state computation first, routing policy second.
• Use RFC 9582 as the current ROA profile.
• Keep ROA maxLength tight.
• Treat NotFound as unknown authorization state, not automatically hostile.
• Monitor Invalid causes before enforcing broad rejection.

16. Knowledge check

1. What failure mode is this control designed to contain?
2. What is the service consequence if it triggers incorrectly?
3. What evidence proves the control worked without causing unintended collateral damage?

Answers

1. The topic-specific leak, instability, invalid-origin or excessive-route condition.
2. Depending on the mechanism: route suppression, loss of prefixes, session shutdown or policy rejection.
3. Compare logs, route counts/validation state, forwarding and negative tests against the documented baseline.

17. Sources

• RFC 6811 — BGP Prefix Origin Validation
• RFC 8481 — Clarifications to BGP Origin Validation Based on RPKI
• RFC 9582 — A Profile for Route Origin Authorizations (ROAs), obsoletes RFC 6482
• RFC 8893 — RPKI Origin Validation for BGP Export