Day 66 — Secure Internet-Edge Capstone: Default-Deny, RPKI, IRR, Max-Prefix and RTBH

1. Opening

A secure Internet edge is not one feature. It is a sequence of mutually reinforcing controls: explicit import/export policy, customer prefix authorization, max-prefix, origin validation, relationship-aware leak controls, current special-purpose filtering, source validation where appropriate, and a pre-authorized DDoS discard path.

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

The capstone combines the safety mechanisms developed across Days 55–65. RFC 8212 provides the default-reject principle; RFC 9234 adds relationship semantics; RPKI provides origin authorization state; IRR supplies operational policy data; max-prefix bounds route volume; RFC 7999/RTBH provides emergency discard signaling. Each control keeps a distinct responsibility.

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

AS65010 has Customer-A, Transit-A and Transit-B. Customer-A may advertise one /24 and selected /32 blackhole routes. Both transits provide Internet reachability. The lab must survive customer misadvertisement, RPKI-invalid origin, route leak, stale registry data and a DDoS blackhole request without creating accidental transit.

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 CUST-A-IN seq 10 permit 203.0.113.0/24
route-map CUST-A-IN permit 10
 match ip address prefix-list CUST-A-IN

ip prefix-list OWNED-OUT seq 10 permit 203.0.113.0/24
route-map TRANSIT-OUT permit 10
 match ip address prefix-list OWNED-OUT

router bgp 65010
 address-family ipv4
  neighbor 192.0.2.2 route-map CUST-A-IN in
  neighbor 192.0.2.2 maximum-prefix 5 80
  neighbor 192.0.2.1 route-map TRANSIT-OUT out
  neighbor 198.51.100.1 route-map TRANSIT-OUT out
 exit-address-family

! Add RPKI, OTC/role and BLACKHOLE controls only with
! target-platform-verified syntax and documented peer support.

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 summary
show bgp ipv4 unicast 203.0.113.0/24
show ip prefix-list
show route-map
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

Stage controls in this order: explicit import/export filters → max-prefix → RPKI visibility/policy → IRR reconciliation automation → relationship/leak controls → blackhole trigger. Validate each layer before proceeding.

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.

Inject five faults separately: unauthorized customer prefix, excessive prefix count, RPKI Invalid origin, provider-to-provider leak attempt, and unauthorized blackhole trigger. Record that each is contained by the intended layer.

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

A capstone failure occurs when one control is assumed to compensate for another—for example accepting an unapproved customer prefix because RPKI says Valid. Correct the architecture so commercial authorization, origin authorization and propagation policy remain independent checks.

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

Layered policy matrix

For each external peer document: relationship, authorized inbound prefixes, authorized origin ASes/AS-SET, RPKI policy, max-prefix, communities accepted, blackhole entitlement, export class, GTSM/authentication posture and monitoring owner.

Staged deployment

Never introduce every security control in one maintenance window. Each layer changes failure behavior. Stage, observe, and preserve rollback checkpoints.

Availability trade-offs

Fail-closed routing policy protects against leaks but can withdraw service during data/policy mistakes. Redundant validators, reviewed registry automation and warning thresholds reduce the chance that the security layer becomes the outage source.

Continuous reconciliation

Customer authorization, IRR, ROAs and live BGP all change over time. Run periodic reconciliation and alert on drift before the next BGP update exposes it.

Incident readiness

Pre-build one prefix-specific containment template, one blackhole workflow and one rollback runbook. During an incident, operators should fill approved parameters rather than inventing policy under pressure.

Final acceptance test

The secure edge is accepted only when positive routes pass, unauthorized routes fail, excess routes trigger predictably, an Invalid origin receives the approved action, and blackhole scope cannot escape the customer's entitlement.

14A. Production workflow — secure-edge acceptance plan

Treat the capstone as a staged production acceptance test. Begin with an inventory of every external BGP relationship: provider, peer, customer, route server or complex relationship. For each neighbor record remote ASN, expected prefix volume, allowed inbound route sources, permitted outbound prefixes, authentication/GTSM posture, community contract, RPKI policy, IRR source and operational owner.

Stage 1: explicit route policy. Apply default-deny import and export constructs with narrow allowlists. Verify that owned prefixes leave through the intended transits and that transit-learned routes are never exported to another transit/customer incorrectly.

Stage 2: volume protection. Apply maximum-prefix thresholds derived from observed and contracted route counts. Test warning and hard-limit behavior using lab advertisements before production.

Stage 3: origin validation. Connect redundant RPKI caches where supported, observe validation-state distribution, then deploy the organization's selected action for Invalid routes in stages. Do not combine first-time RPKI connectivity and immediate global rejection in one untested change.

Stage 4: registry reconciliation. Use approved IRR sources and AS-SET expansion to generate customer filters, cross-checking against customer inventory and RPKI. Introduce automation first in report-only mode, then canary generation, then controlled deployment.

Stage 5: relationship controls. Add BGP Roles/OTC where both sides support RFC 9234 and the commercial relationship maps cleanly. Preserve conventional filters because role signaling is defense in depth, not a replacement.

Stage 6: special-purpose/source controls. Generate registry-aware BGP special-purpose filters and deploy uRPF/source validation only after modeling asymmetry and platform interactions.

Stage 7: incident controls. Pre-stage prefix-specific emergency filtering and RTBH. Prove that only authorized prefixes can be blackholed and that withdrawal restores reachability.

The final acceptance matrix should contain both positive and negative cases. Positive: legitimate customer prefix is accepted, legitimate Internet reachability works, owned prefix is exported. Negative: unauthorized customer prefix is denied, excess prefixes trigger the approved response, RPKI Invalid gets the configured action, provider-learned route is not leaked to another external relationship, and unauthorized BLACKHOLE requests fail.

Store all evidence with the release: configs, source snapshots, validator state, route counts, tests and rollback commands. A secure edge is not “finished” when the CLI is entered; it is finished when every control has a proven normal state, failure state and reversible recovery path.

15. Production lessons

• Security controls are complementary, not interchangeable.
• Keep customer authorization separate from RPKI state.
• Fail closed at external routing boundaries.
• Monitor every automated data source for freshness.
• Stage security changes and retain per-layer rollback.
• Test the incident workflow before production use.

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 8212 — Default-reject eBGP policy
• RFC 9234 — BGP Roles/OTC
• RFC 9582 and RFC 8481 — RPKI/ROV
• RFC 7682 — IRR policy considerations
• RFC 7999 — BLACKHOLE community
• RFC 7454 — BGP Operations and Security
• Cisco IOS XE 17.18.x — BGP filtering and uRPF guidance