★★★Advanced🔐 Network Security

BGPRPKISecurityRoutingWANBest Practices

BGP Security: RPKI, Route Filtering, and Prefix Hijack Prevention

March 13, 2026·10 min read

Overview

BGP has no built-in authentication for the routes it carries — any AS can announce any prefix. BGP route hijacks (malicious or accidental mis-origination) and route leaks have caused major internet outages. RPKI (Resource Public Key Infrastructure) lets IP address holders cryptographically sign which ASes are authorized to originate their prefixes, and lets routers reject anything that doesn't match.

Attack Vectors BGP Security Addresses

Threat	Description	Mitigation
Prefix hijack	AS announces a prefix it doesn't own — attracts traffic away from legitimate owner	RPKI origin validation
More-specific hijack	AS announces /25 inside someone's /24 — longer prefix wins	RPKI + max-prefix length enforcement
Route leak	Customer re-advertises provider routes to another provider — becomes accidental transit	BGP communities, NO_EXPORT, ASPA
BGP session hijack	TCP session reset or injection between BGP peers	MD5/TCP-AO peer authentication + TTL security
Bogon prefix injection	Advertisement of RFC 1918, link-local, or unallocated space	Bogon prefix filters (IRR/RPKI)

Part 1 — RPKI Origin Validation

How RPKI Works

RPKI uses Route Origin Authorizations (ROAs) — signed objects that specify which ASN is authorized to originate a given prefix. Your router connects to an RPKI validator (Routinator, FORT, or Cloudflare's hosted validator) via RTR protocol to download the validated ROA cache.

bash

IP Resource holder (ARIN/RIPE/APNIC) signs ROA:  Prefix: 203.0.113.0/24, Max-length: 24, Origin-AS: 65001Router receives BGP update:  Prefix: 203.0.113.0/24, Origin-AS: 65001 → VALID (matches ROA)  Prefix: 203.0.113.0/24, Origin-AS: 65999 → INVALID (wrong AS)  Prefix: 192.0.2.0/24                      → NOT FOUND (no ROA exists)

Configure RPKI on Cisco IOS-XE

cisco

! Step 1 — point router at RPKI validator (RTR protocol)router bgp 65001 bgp rpki server tcp 192.0.2.100 port 3323 refresh 300 ! Use a local Routinator/FORT validator — don't rely on external ones for production! Step 2 — enable origin-AS validationbgp bestpath prefix-validate allow-invalid! "allow-invalid" = accept INVALID routes but mark them — use for monitoring first! Change to "bgp bestpath prefix-validate" to actually prefer VALID over INVALID! Step 3 — route-map to act on validation stateroute-map RM-RPKI-FILTER deny 10 match rpki invalid ! Drop INVALID routes (confirmed hijack or mis-origination)route-map RM-RPKI-FILTER permit 20 ! Allow VALID and NOT FOUNDrouter bgp 65001 neighbor 203.0.113.1 route-map RM-RPKI-FILTER in

Tip: Start with allow-invalid and monitor for 2–4 weeks before adding the deny. Many networks have stale ROAs that would cause legitimate routes to show as INVALID.

Verify RPKI State

cisco

R1# show bgp ipv4 unicast rpki servers! Shows validator connection state: Active/Connected/IdleR1# show bgp ipv4 unicast 203.0.113.0/24! "Origin validity: valid" = matched ROA! "Origin validity: invalid" = AS mismatch! "Origin validity: not-found" = no ROA existsR1# show bgp ipv4 unicast rpki table! Lists all ROAs downloaded from validator

Routinator 3000 › 192.0.2.100:8323 — RTR port 3323 — AS 65001 ● RTR CONNECTED

Validate a prefix + origin ASN against the published ROA cache:

VALID — route origin is authorised

203.0.113.0/24 originated by AS 65001 matches a signed ROA from APNIC

Matching ROA

Prefix	Max length	Authorised ASN	Trust anchor (RIR)	ROA expires
203.0.113.0/24	/24	AS 65001	APNIC	2026-12-31

All three RPKI validation states

✓ VALID

Prefix + origin ASN match a signed ROA. Router prefers this route over NOT FOUND and INVALID.

✗ INVALID

ROA exists but wrong ASN or prefix longer than max-length. Route-map deny — drop it.

? NOT FOUND

No ROA published. Accept normally — do not prefer over VALID but do not drop.

Router config matching this validator

router bgp 65001

 bgp rpki server tcp 192.0.2.100 port 3323 refresh 300

 bgp bestpath prefix-validate allow-invalid  ← monitor mode (2-4 wks before enforcing)

Part 2 — Peer Authentication and Session Hardening

MD5 Authentication

cisco

router bgp 65001 neighbor 203.0.113.1 password Str0ngBGPpassw0rd! ! Both peers must have identical password ! MD5 is deprecated — use TCP-AO if supported! TCP-AO (stronger, replaces MD5 on IOS-XE 17.3+)ip tcp authentication-key-chain BGP-PEER-KEY key 1  key-string Str0ngTCPAOkey!  send-id 1  recv-id 1  algorithm hmac-sha-256router bgp 65001 neighbor 203.0.113.1 ao BGP-PEER-KEY

TTL Security (GTSM)

TTL Security prevents spoofed BGP TCP packets from off-path attackers — only directly-connected or single-hop peers can send packets with TTL ≥ 255.

cisco

router bgp 65001 neighbor 203.0.113.1 ttl-security hops 1 ! For eBGP peers — rejects any packet with TTL < 254 ! For multihop eBGP: ttl-security hops 2 (or however many hops away)

Part 3 — Prefix Filtering

Max-Prefix Limits

cisco

router bgp 65001 ! Peer advertising full internet table — warn at 750k, shut at 900k neighbor 203.0.113.1 maximum-prefix 900000 80 restart 5 ! 80% = warning threshold, restart 5 = try again after 5 minutes ! Customer peer — should only send their own /24s neighbor 198.51.100.1 maximum-prefix 20 75 warning-only ! warning-only = log but don't disconnect

Bogon Prefix Filter

cisco

ip prefix-list BOGONS deny 0.0.0.0/8 le 32ip prefix-list BOGONS deny 10.0.0.0/8 le 32ip prefix-list BOGONS deny 100.64.0.0/10 le 32ip prefix-list BOGONS deny 127.0.0.0/8 le 32ip prefix-list BOGONS deny 169.254.0.0/16 le 32ip prefix-list BOGONS deny 172.16.0.0/12 le 32ip prefix-list BOGONS deny 192.0.0.0/24 le 32ip prefix-list BOGONS deny 192.168.0.0/16 le 32ip prefix-list BOGONS deny 198.18.0.0/15 le 32ip prefix-list BOGONS deny 198.51.100.0/24 le 32ip prefix-list BOGONS deny 203.0.113.0/24 le 32ip prefix-list BOGONS deny 224.0.0.0/4 le 32ip prefix-list BOGONS deny 240.0.0.0/4 le 32ip prefix-list BOGONS permit 0.0.0.0/0 le 32! Apply inbound from all eBGP peersrouter bgp 65001 neighbor 203.0.113.1 prefix-list BOGONS in

Minimum Prefix Length (Anti-Deaggregation)

cisco

! Reject anything more-specific than /24 from internet peersip prefix-list MAX-PREFIX-LEN deny 0.0.0.0/0 ge 25ip prefix-list MAX-PREFIX-LEN permit 0.0.0.0/0 le 24router bgp 65001 neighbor 203.0.113.1 prefix-list MAX-PREFIX-LEN in

Real-World Scenario

The situation: During a routine ISP maintenance window, a misconfigured route reflector in AS 64500 started announcing 2,000 of its customer prefixes to its transit providers with the wrong origin-AS. Traffic destined for those customers started routing to AS 64500 instead of the correct origins.

Symptoms observed:

Traceroutes to several customer prefixes show unexpected hops through AS 64500
show bgp ipv4 unicast 203.0.113.0/24 shows Origin validity: invalid on the receiving router
RPKI validator logs show ROA mismatch: announced AS 64500, ROA says AS 65001

Fix — RPKI invalid route dropped:

cisco

! With RPKI deny in place (route-map RM-RPKI-FILTER deny 10 match rpki invalid):R1# show bgp ipv4 unicast 203.0.113.0/24! Route not in table — INVALID route was rejected by inbound route-map! Traffic correctly uses the backup path (valid ROA) or returns to correct AS

What happens without RPKI: The invalid route is accepted, traffic diverts to the wrong AS. If the wrong AS doesn't have the actual servers, those destinations become unreachable.

Troubleshooting

RPKI validator connected but all prefixes show NOT FOUND

Symptom: show bgp rpki table is empty. All prefixes show not-found validity.

Cause: RTR session established but ROAs not synced — validator may be initializing, or firewall blocking RTR port (default 3323).

Fix:

cisco

R1# show bgp rpki servers! Check "Serial Query" counter — should be incrementing! If "Error Notify" is non-zero, check firewall on TCP 3323R1# debug bgp rpki

RPKI causes legitimate prefixes to be dropped as INVALID

Symptom: Known-good ISP prefix disappears from routing table after RPKI policy applied.

Cause: ISP has a stale or incorrect ROA — origin AS doesn't match what they're actually announcing.

Fix:

cisco

! Temporarily change deny to warning to investigateroute-map RM-RPKI-FILTER deny 10 ! comment out: match rpki invalid ! add: set community 65001:9999 ! — marks INVALID routes without dropping them! Check which routes are INVALIDR1# show bgp ipv4 unicast | include invalid! Contact the prefix owner to fix their ROA

BGP session drops every few hours with MD5 error

Symptom: BGP session resets with %BGP-3-NOTIFICATION: received from neighbor passive, code 6 (cease), subcode 5.

Cause: MD5 password mismatch — common after a password rotation on one side only.

Fix:

cisco

! Verify MD5 is configured identically on both endsR1# show bgp neighbors 203.0.113.1 | include password! Both sides must show "Password configured"! If they don't match — clear and re-enter on both sides simultaneously

BGP Security Hardening Checklist

RPKI validator deployed locally (Routinator or FORT) — not relying on external public validators
ROA created and published for all prefixes you originate — check via rpki.cloudflare.com
match rpki invalid deny applied inbound on all eBGP sessions — start with monitoring mode first
MD5 or TCP-AO authentication configured on all eBGP sessions — no unauthenticated eBGP peers
TTL security (ttl-security hops 1) on all directly-connected eBGP peers
Bogon prefix-list applied inbound on all external peers — updated from Team Cymru bogon list
Max-prefix limits configured on all eBGP neighbors — sized to 110% of expected prefix count
/24 max-length enforced inbound — reject anything more-specific from internet peers
Outbound prefix-list restricts your eBGP advertisements to your own prefixes only
no bgp default ipv4-unicast to prevent accidental activation of new neighbors in IPv4 unicast