Securing routing: protocol authentication, route filtering, uRPF and control plane protection

Why routing needs protecting

Routing protocols were designed to share information freely between trusted devices. If someone can form a neighbour relationship, or a misconfigured router leaks routes, traffic can be redirected through an attacker, black-holed or made to loop. Other risks include spoofed source addresses used in denial-of-service attacks and floods aimed at the router's own CPU. Defences work at several layers.

Protect neighbour relationships

• Passive interfaces: enable routing protocols only on links to other routers. passive-interface default plus explicit exceptions means a laptop on a user VLAN cannot form an OSPF or EIGRP adjacency.
• Authentication: neighbours must prove they know a shared key. Use HMAC-SHA key chains for OSPF and EIGRP where supported, and TCP-AO or MD5 passwords for BGP sessions. Rotate keys using key chain lifetimes.
• TTL security (GTSM): for eBGP between directly connected routers, only accept packets that arrive with TTL 255, which a remote attacker cannot fake.

key chain RTR-KEYS
 key 1
  key-string <your-shared-key>
  cryptographic-algorithm hmac-sha-256
interface GigabitEthernet0/1
 ip ospf authentication key-chain RTR-KEYS
router bgp 65010
 neighbor 192.0.2.1 remote-as 65020
 neighbor 192.0.2.1 password <your-session-password>
 neighbor 192.0.2.1 ttl-security hops 1

Filter the routes you accept and send

Even an authenticated neighbour can make mistakes. Use prefix lists to accept only the routes you expect from each neighbour and advertise only your own. On BGP sessions, also set a maximum-prefix limit so a sudden flood of routes tears the session down instead of filling the table.

ip prefix-list FROM-BRANCH seq 10 permit 10.64.0.0/15 le 21
router bgp 65010
 neighbor 192.0.2.1 prefix-list FROM-BRANCH in
 neighbor 192.0.2.1 maximum-prefix 100

Stop spoofed traffic and protect the CPU

Ingress filtering (best current practice BCP 38) means networks drop packets whose source addresses could not legitimately come from that direction, which limits spoofing-based attacks. Unicast reverse path forwarding (uRPF) automates this by checking the source address against the routing table:

interface GigabitEthernet0/2
 description User LAN
 ip verify unicast source reachable-via rx
 no ip redirects
 no ip proxy-arp

Control plane policing (CoPP) rate-limits traffic sent to the router's own CPU, such as routing updates, SSH, SNMP and ICMP, so a flood cannot starve the routing protocols. Combine it with infrastructure ACLs that allow management protocols only from your management network.

Internet routing: RPKI

On the internet, BGP route hijacks and leaks have repeatedly diverted traffic for well-known services. Resource Public Key Infrastructure (RPKI) lets address holders publish signed Route Origin Authorisations stating which autonomous system may announce their prefixes. Routers performing route origin validation can then reject invalid announcements. Creating ROAs for your own prefixes, asking your ISPs to validate, and following the MANRS actions are practical steps for any organisation with its own address space.

Real-world example: during a lab-to-production migration, a test router with a default route was connected to a live VLAN where OSPF was not passive. It formed an adjacency and advertised its default route, pulling part of the site's internet traffic into a dead end. Passive-interface default and OSPF authentication on the production routers would have stopped the adjacency from forming at all.

Review these protections at least once a year, and after every major change, and test them in a lab before you roll them out.