In enterprise networks, routing tends to get configured with the comforting assumption that “we’re already inside, so we’re fine.” But the routing domain is a control plane that can turn into a major outage very quickly — through a wrong adjacency, a forged LSA/LSP, or a mishandled redistribution. That’s why on the OSPF/IS-IS side I keep two goals in mind together:
- Who is talking? (authentication)
- From where can they talk? (control-plane hardening)
Threat model: which risks are real in production?
Realistic risk classes for OSPF/IS-IS:
- Rogue neighbor: an unintended device on the same L2 segment brings up OSPF/IS-IS and forms an adjacency.
- Route injection: incorrect or malicious prefixes leak into the routing domain.
- Control-plane overload: routing CPU gets pushed by unnecessary control traffic, and adjacency flaps start.
- Operational mistake: an authentication key change is poorly planned and adjacencies drop at scale.
Authentication on its own won’t fix everything, but it dramatically reduces the “rogue neighbor” and “accidental conversation” classes of incident.
OSPF/IS-IS authentication: what should you pick?
The exact options vary by vendor and version, but the pragmatic decision logic is the same:
- Avoid weak / outdated mechanisms (especially the very old cleartext / legacy options).
- Prefer modern HMAC-based methods (when your hardware supports them).
- Plan rotation with a key chain plus time windows (don’t do a single-key “big bang” cutover).
Key management: key chain plus a transition window
The approach that gives me the fewest field issues:
- Add a new key to the chain (with controlled accept + send windows)
- Once every neighbor accepts the new key, switch send over to it
- Keep the old key in the accept list a while longer (rollback window)
- Then remove the old one
This model dramatically lowers the “one bad night” outage risk.
Control-plane hardening: stop adjacency from being a “surface area”
You need to back authentication up with these guardrails:
1) Shrink the adjacency surface
- Enable routing only on the interfaces that actually need it.
- Use a “default passive” stance to prevent adjacencies forming on the wrong port.
- Don’t let routing protocols run on access ports (especially at the edge / access layer).
2) Make L2/L3 boundaries explicit
The segments where OSPF/IS-IS is speaking should ideally live in a separate transit VLAN/VRF. In an “L2 everywhere” model, the chance of the wrong device joining the conversation goes up sharply.
3) ACL/CPP/CoPP for control traffic
Routing protocol packets, management access (SSH/SNMP), NTP, and log traffic should all be classified and protected on the control plane. I’ll cover CoPP/CPP separately in a follow-up; the critical message here is:
Even if authentication is right, if the control-plane capacity collapses, the adjacency drops anyway.
Monitoring: don’t let authentication go “silent”
For an operable model, watch at least these signals:
- Adjacency count (vs. expected number of neighbors)
- Adjacency flap rate
- Authentication failure logs and counters
- LSDB / LSP size and rate of change (sudden spikes)
- Control-plane CPU and punted-packet counts
Change plan: routing auth is maintenance work
The safest change model:
- Pick a pilot area / small POP in the live network first
- Prepare the key chain and open the accept window
- Once every neighbor is ready, switch send over
- Watch for 30–60 minutes: adjacency, SPF, CPU, logs
- Then roll it out wave by wave
For rollback:
- Plan it so “send” can be flipped back to the old key
- Don’t delete the old key right away (rollback window)
Wrap-up: routing security is a discipline, not a product
OSPF/IS-IS authentication and control-plane hardening pull routing out of the “invisible internal service” category and turn it into a manageable control plane. The success criterion here isn’t whether a command runs — it’s whether rotation and change can be operated without service interruption.