Day 65 — Route-Leak and Prefix-Hijack Incident Containment

1. Opening

A sudden path change can look like a hijack even when the real problem is a customer's accidental transit leak, a stale ROA, a provider policy error or normal maintenance. Fast containment matters, but correct classification matters too: the wrong fix can disconnect legitimate routes or hide evidence.

Internet-edge security works best when each source of routing truth has a clearly defined job. The local configuration expresses business policy. IRR data documents routing intent. RPKI validates origin authorization. BGP exposes what is actually being announced. None of those sources alone replaces the others.

The objective is therefore not merely to create a filter. It is to create a repeatable authorization workflow with enough evidence to explain why a prefix is accepted, rejected, blackholed or escalated.

2. Concept and standards behavior

RFC 4272 describes classes of BGP security vulnerability, including bogus routing information. RFC 9234 focuses on route leaks that violate expected relationship propagation. RPKI ROV detects unauthorized origin conditions but does not validate the entire path. RFC 8212 and explicit filters reduce accidental propagation risk.

The series continues to separate four layers:

1. Standards behavior — what an RFC defines.
2. Registry or authorization data — what IRR/RPKI/IANA sources say.
3. Cisco implementation — how IOS XE expresses the mechanism.
4. Operator policy — what this network chooses to accept, advertise or discard.

A safe production design must state which layer is making each decision. For example, a route can be RPKI NotFound yet explicitly authorized by a customer contract and IRR object; conversely, an IRR object does not cryptographically prove resource control.

3. Scenario

Monitoring detects 203.0.113.0/24 arriving from Transit-B with an unexpected path/origin. EDGE1 must classify the event using live BGP evidence, customer authorization, IRR and RPKI before selecting containment.

Common lab topology

                    Transit-A / AS65020
                           |
                     192.0.2.0/30
                           |
                    EDGE1 / AS65010
                      /           \
             Customer-A           Scrubber/RTBH
              AS65030               control
                 |
          203.0.113.0/24
                           |
                    Transit-B / AS65040

All addresses and ASNs are documentation/private lab values. External registry examples are conceptual; no real organization is impersonated and no real ROA is created.

Success criteria

1. Only explicitly authorized customer prefixes are accepted.
2. Export policy cannot accidentally create transit.
3. RPKI validation state is visible but policy action remains explicit.
4. Special-purpose/bogon controls are registry-aware.
5. Blackhole signaling can be invoked only by approved sources and prefixes.
6. Incident containment is reversible and evidence-preserving.

4. Topology diagram

A matching editable SVG and PNG are stored under media/diagrams/.

5. Prerequisites

• IOS XE 17.18.x documentation baseline.
• Stable eBGP sessions.
• A documented customer prefix inventory.
• Time-synchronized logging.
• Independent management access.
• For IRR/RPKI exercises: local snapshots or lab fixtures, not live production credentials.
• For blackhole exercises: a dedicated discard next hop/community policy and strict trigger authorization.

6. Baseline configuration

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

ip prefix-list INCIDENT-BLOCK seq 10 deny 203.0.113.0/24
ip prefix-list INCIDENT-BLOCK seq 100 permit 0.0.0.0/0 le 32

route-map TRANSIT-B-IN permit 10
 match ip address prefix-list INCIDENT-BLOCK
!
! This is a temporary lab containment example.
! Production changes require peer/direction review and expiry.

Generated policy must be reviewed before deployment. Registry automation must never push directly to production without validation, diff, canary and rollback controls.

7. Verification before modification

show bgp ipv4 unicast summary
show bgp ipv4 unicast
show bgp ipv4 unicast neighbors
show bgp ipv4 unicast neighbors 192.0.2.2 received-routes
show bgp ipv4 unicast neighbors 192.0.2.2 advertised-routes
show ip prefix-list
show route-map
show logging
show bgp ipv4 unicast 203.0.113.0/24
show bgp ipv4 unicast neighbors 198.51.100.1 received-routes
show logging

The verification question is not “does the prefix exist somewhere?” but “which evidence source authorized it, which policy matched it, and what did the router actually do?”

8. Controlled modification

First capture all alternate paths and validation state. Then apply a prefix-specific inbound containment only on the affected peer while preserving unaffected routes.

Before the change, predict whether the affected object is Adj-RIB-In, Loc-RIB, Adj-RIB-Out, FIB forwarding or an external authorization state. Re-check the same evidence after the change.

9. Fault injection

Illustrative lab — not a real incident.

Misdiagnose an RPKI Valid but relationship-invalid leaked route as 'safe' merely because the origin is authorized. The path should still be investigated for leak semantics.

The lab changes one authorization or policy variable at a time. Do not combine an RPKI fault, IRR fault and BGP policy fault in the same experiment unless the post explicitly reaches the capstone stage.

10. Step-by-step troubleshooting

1. Identify the exact prefix, origin AS and neighbor relationship.
2. Confirm the BGP session remains Established unless session loss is part of the event.
3. Capture the received AS_PATH, origin and communities.
4. Compare the prefix against the approved customer inventory.
5. Check current IRR/RPSL data or the lab fixture.
6. Check RPKI validation state where available.
7. Check special-purpose/IANA classification when relevant.
8. Inspect import policy and prefix-list/AS-path/community matches.
9. Inspect export policy before changing inbound controls.
10. Determine whether the issue is unauthorized origin, route leak, stale registry data, bad automation or a legitimate operational change.
11. Apply the narrowest proven containment.
12. Verify forwarding, negative containment and rollback readiness.

11. Root cause and correction

The event was a route leak, not an origin hijack: the origin AS was authorized, but the path was propagated across a relationship where it should not have been. Correct upstream/export policy and remove temporary containment only after global observations stabilize.

The correction must repair the relevant trust source or policy boundary rather than broadening filters simply to make the route appear.

12. Post-fix verification

Confirm:

• intended BGP sessions remain Established;
• approved prefixes are accepted;
• unauthorized prefixes are absent or explicitly contained;
• RPKI state/policy matches the design;
• per-neighbor export remains default-deny;
• forwarding and discard behavior match the service objective;
• logs identify the triggering event.

13. Rollback

Restore the last approved filter/policy snapshot. If the change was incident containment, preserve the evidence before removal. Never roll back by replacing a default-deny policy with permit any. A temporary exception must be prefix-, peer- and time-bounded with an owner.

14. Deep-dive engineering notes

Hijack versus leak

An origin hijack typically involves an unauthorized origin AS. A route leak can retain the legitimate origin yet propagate the route beyond its intended commercial relationship. ROV detects the first class more directly than the second.

Evidence sequence

Capture timestamp, peer, full AS_PATH, communities, RPKI state, IRR state, local preference, best-path reason and advertised routes before editing policy. That evidence allows later reconstruction.

Narrow containment

Block one prefix from one peer if that safely contains the event. Avoid withdrawing the prefix from all providers unless that is the service objective.

Communication

Routing incidents involve network operations, security, upstream providers and sometimes customers. Record who owns external coordination and what evidence can be shared.

Recovery

Do not remove containment because one route looks normal again. Observe multiple route collectors/peers where available, verify the upstream correction and define a stability interval.

14A. Production workflow — first 15 minutes of a routing incident

The first objective is to preserve facts. Record the detection time, monitoring source, affected prefixes, currently selected path, all alternate paths, neighbor that supplied each path, RPKI validation state, communities, local preference and recent configuration changes. Export relevant logs before repeated clears or route-policy edits rewrite the evidence trail.

Next classify the event. If the origin AS is unexpected and RPKI is Invalid, an unauthorized-origin incident is plausible. If the origin is legitimate but the path has crossed an unexpected provider/peer relationship, a route leak is more likely. If the route is RPKI NotFound, classification needs IRR/customer ownership evidence. If only one local router sees the anomaly, investigate local policy or stale route state before declaring an Internet-wide hijack.

Scope containment to the smallest safe boundary. If only Transit-B supplies the bad path, a prefix-specific inbound deny on Transit-B may preserve service through Transit-A. If the customer's own session is leaking thousands of routes, max-prefix shutdown or customer-specific import policy may be more appropriate. Do not withdraw a legitimate prefix globally unless the incident objective requires that.

Coordinate externally with evidence. Provide the upstream or customer with the prefix, observed path, timestamps and what policy is believed to be wrong. Avoid claiming malicious intent when the evidence supports only misconfiguration.

During containment, monitor alternate paths and data-plane reachability. A successful route filter can still produce an outage if no legitimate alternative exists. The incident commander needs to know whether containment protects integrity at the cost of availability.

Recovery starts only after the source condition is corrected and observations stabilize. Remove temporary filters one at a time, verify the expected route returns from the correct peer, and retain a monitoring window. If the event was caused by a missing export policy, implement the permanent relationship-aware fix before removing the emergency deny.

Finally, update preventive controls: RPKI/ROA maintenance, IRR filters, max-prefix thresholds, RFC 8212 default-deny posture, BGP Roles/OTC where supported, and alerting. The value of an incident review is converting one-off containment into a smaller future blast radius.

Incident exit criteria

Define exit criteria before removing emergency policy. At minimum, require the legitimate origin/path to be stable, the offending peer or upstream policy to be corrected, no recurrence during the agreed observation window, and the temporary filter to have an owner for removal. Preserve the final route snapshot after recovery so the post-incident review can compare pre-event, contained and restored states without relying on memory or external route collectors alone.

15. Production lessons

• Classify route leak versus origin hijack before choosing the fix.
• RPKI Valid does not mean the entire AS_PATH is policy-valid.
• Preserve path evidence before changing policy.
• Use narrow, reversible containment.
• Require a stability window before removing incident filters.

16. Knowledge check

1. Which source in this post documents intent, and which source can cryptographically validate origin authorization?
2. What evidence proves the router actually enforced the expected policy?
3. Why should a temporary incident exception be narrower than the permanent policy?

Answers

1. IRR/RPSL documents routing intent; RPKI ROAs support cryptographic origin authorization.
2. Received/accepted/advertised route evidence plus policy counters/logs and forwarding tests.
3. Broad exceptions can outlive the incident and silently create a new leak or hijack acceptance path.

17. Sources

• RFC 9234 — Route Leak Prevention and Detection Using Roles/OTC
• RFC 6811 / RFC 8481 — RPKI Origin Validation
• RFC 7454 — BGP Operations and Security
• RFC 4272 — BGP Security Vulnerabilities Analysis
• RFC 8212 — Default External BGP Route Propagation Behavior