Interior Routing Protocol Security Guide: Authenticating OSPF, IS-IS, EIGRP and First-Hop Redundancy

Inside most enterprise and campus networks, any device that can send a well-formed OSPF, EIGRP or VRRP packet onto a routed segment can change where traffic goes. Interior gateway protocols (IGPs) and first-hop redundancy protocols were designed for cooperative networks, and many still run with no authentication, MD5 keys set a decade ago, or passive interfaces that were never configured. This guide covers how to authenticate OSPFv2, OSPFv3, IS-IS and EIGRP with current algorithms, what the replay and key lifetime limits of each mechanism are, how to deal with HSRP and VRRP, and how control plane protection, GTSM and monitoring fit around them. It is written for network engineers and security architects who run routed enterprise, data centre or provider-edge networks. Internet routing (BGP, RPKI, route leaks) is covered separately in the BGP and Routing Security Guide, and administrative access to devices in the Network Device Management Plane Hardening Guide.

Key takeaways

• Unauthenticated adjacencies are an open door. EIGRP's own specification calls the protocol promiscuous: it will peer with any router that sends a valid hello, so neighbour authentication and passive interfaces are the first controls, not optional extras.
• Move from MD5 to HMAC-SHA-256. RFC 5709 makes HMAC-SHA-256 mandatory to implement for OSPFv2, RFC 7166 makes it the default for the OSPFv3 authentication trailer, and RFC 5310 brings the SHA family to IS-IS.
• Authentication is not replay protection. Classic OSPFv2 cryptographic authentication and IS-IS generic cryptographic authentication both state that they do not stop replay; RFC 7474 and the OSPFv3 trailer close that gap with 64-bit sequence numbers.
• VRRPv3 has no authentication by design. RFC 9568 explains why it was removed and relies on TTL 255 checks and switch-port filtering instead, so first-hop protection is a Layer 2 and access-port job.
• Routing keys are machine secrets. They are shared, long-lived and usually sit in device configurations and backups, so they need an owner, an inventory and a rotation plan like any other non-human credential.

Why interior routing is an attack surface

An IGP builds the forwarding table for every subnet inside an autonomous system. Whoever can inject a route, form an adjacency or win a first-hop election can attract, black-hole or inspect traffic without touching a single endpoint. The realistic attackers are not exotic: a compromised server on a routed segment, a misconfigured lab router plugged into a production VLAN, a contractor laptop, or an intruder who already holds a foothold on one network device and wants to steer traffic through it.

In MITRE ATT&CK terms the outcomes map to Adversary-in-the-Middle (T1557) when traffic is redirected through an attacker, Network Boundary Bridging (T1599) when routing changes let traffic cross a segmentation boundary, and Network Denial of Service (T1498) when bogus routes or packet floods destabilise the control plane. Long-running intrusions into telecommunications networks have shown that once attackers hold network devices, they read and change configuration, including routing and key material: see the Salt Typhoon Telecom Intrusions 2025 page.

The joint guidance Enhanced Visibility and Hardening Guidance for Communications Infrastructure, published by CISA, NSA, FBI and partner agencies in Australia, Canada and New Zealand on 3 December 2024, tells operators to enable authentication on routing and control protocols where supported, naming OSPF and HSRP among them, to disable IP source routing, and to watch for unusual route updates.

Authentication options by protocol

Every IGP offers some form of neighbour authentication, but the algorithms, key handling and replay behaviour differ. The table summarises what the specifications say.

OSPFv2

RFC 5709 keeps the OSPFv2 packet format and adds HMAC-SHA algorithms to cryptographic authentication. Each security association is selected by an 8-bit Key ID and binds an algorithm, a key and optional start and stop times for accepting and generating packets, which is what makes hitless key rollover possible. The RFC is candid about the limits: there is no automated key management, so keys tend to live for years; symmetric keys prove only that the sender knew the key, not which router sent the packet; and an on-link attacker can still replay recorded packets. RFC 7474 fixes replay by extending the sequence number to 64 bits, with a boot count kept in non-volatile storage in the upper 32 bits, and by including the source address in the hash. Ask your vendor whether it is implemented before relying on it.

OSPFv3

OSPFv3 originally relied only on IPsec. RFC 7166 added an authentication trailer modelled on RFC 5709, with HMAC-SHA-256 as the default and a 64-bit sequence number that must keep increasing across restarts. It also authenticates the IPv6 source address, which OSPFv3 otherwise accepts from hellos without verification. For most networks the trailer is simpler to operate than per-interface IPsec security associations. See the IPv6 Security Guide for the wider IPv6 control plane.

IS-IS

IS-IS runs directly over Layer 2, not IP, which already limits who can reach it. RFC 5310 adds HMAC with the SHA family under Auth Type 3, with a two-octet Key ID per security association. Configure hello authentication per link and LSP/SNP authentication per area or domain, and remember that the RFC states plainly that the mechanism gives integrity and sender authentication but no replay protection and no confidentiality. The optional transition mode that ignores authentication data should exist only during a migration window.

EIGRP

RFC 7868 documents EIGRP for information only and says the protocol will peer with any router that sends a valid hello, so policy must limit peering to trusted routers. It lists MD5 and SHA2-256 authentication types and leaves denial-of-service protection to control plane rate limiting and neighbour authentication. Where your platform supports SHA-256 for EIGRP (named-mode configuration on Cisco IOS XE, for example), prefer it over MD5.

First-hop redundancy: HSRP, VRRP and GLBP

First-hop redundancy protocols decide which router answers for the default gateway address. A host that wins the election receives every packet leaving the subnet, which makes these protocols an attractive man-in-the-middle target on user and server VLANs.

• VRRPv3: RFC 9568 (April 2024) removes authentication because experience showed it did not stop a hostile node becoming active and misconfigured secrets caused multiple active routers. Instead, senders must set TTL or Hop Limit to 255 and receivers must discard anything else, receivers should validate version, type, checksum and VRID, and the RFC suggests switch-port filtering to block VRRP from end-host ports. Only one router per VRID should hold priority 255.
• HSRP and GLBP: these are Cisco protocols; configure MD5 authentication from a key chain rather than plain-text strings, which the joint CISA guidance specifically lists among protocols to authenticate.
• Access layer filtering: the strongest control is not letting end hosts send FHRP traffic at all. Port ACLs or VLAN ACLs that drop VRRP (IP protocol 112) and HSRP (UDP 1985 for IPv4 versions 1 and 2, UDP 2029 for HSRP for IPv6) from host-facing ports remove the attack. See the Layer 2 Attacks Guide for ARP, DHCP and spanning tree protections that belong alongside it.

Reducing exposure: passive interfaces, filtering and GTSM

Authentication stops a stranger forming an adjacency, but the cheapest control is never sending or accepting routing packets where no router should be.

• Passive by default: make every interface passive for the IGP and enable adjacency only on named transit links. User, server and guest VLANs should never carry IGP hellos.
• Route filtering at area and redistribution boundaries: use prefix lists and route maps where routes are redistributed between protocols or summarised between areas, and cap the number of redistributed prefixes, so one bad injection cannot flood the table.
• Disable IP source routing and unused protocols: both appear in the CISA joint hardening guidance.
• GTSM (RFC 5082): peers send with TTL 255 and the receiver treats anything with an unexpected TTL as dangerous. It is lightweight protection against forged packets from off-link sources for TCP-based sessions such as BGP and LDP. The RFC is clear that it is not a substitute for authentication and does not stop an attacker on the same link.

Protecting the control plane itself

Routing processes run on the device CPU. A flood of OSPF hellos, malformed LSAs or ICMP can starve them and drop adjacencies across the network. RFC 6192 (Informational, 2011) describes the standard approach: identify every legitimate protocol the control plane needs, filter traffic destined to the router in the forwarding plane, permit known peers, and rate-limit or drop the rest. Its example policy permits OSPF (IP protocol 89) only from the infrastructure range and OSPFv3 from fe80::/10, iBGP and eBGP on TCP 179 only from listed peers, NTP (UDP 123), DNS, SSH (TCP 22) and SNMP (UDP 161) from named sources, rate-limits ICMP, and drops fragments.

RFC 6192 recommends starting with a rate-limited default class so you can see what legitimate traffic you missed, then moving the default to drop. On Cisco platforms this is Control Plane Policing (CoPP) under the control-plane configuration; Juniper applies a firewall filter to the loopback interface of the Routing Engine. Neither replaces protocol authentication.

Where identity fits: routing keys as non-human credentials

Every routing key is a shared secret held by a set of machines. It has no human owner by default, it is often reused across a whole area, it appears in configuration backups and in the configuration management tool, and with Cisco type 7 or similar reversible storage it can be read by anyone who obtains the file. The joint CISA guidance warns against type 5 and type 7 passwords and favours type 8. Treat routing, FHRP, NTP and TACACS+ keys as a credential class:

• Inventory: record each key's scope (link, area, VRID), where it is stored and which automation can read it.
• Storage: keep keys in a secrets manager that your automation reads at deployment, and encrypt or redact them in configuration backups. See the Secrets Management Guide.
• Scope: use per-link keys for hellos where the protocol allows, so one leaked key does not expose an entire area.
• Rotation: use key chains with overlapping accept and send lifetimes (the RFC 5709 and RFC 5310 security association model supports this) and rotate on a schedule and after any device compromise or staff departure with configuration access.

Implementing authentication without an outage

Turning on authentication on a live adjacency takes it down if the two ends disagree. A staged approach avoids that.

1. Inventory adjacencies: export neighbour tables for every IGP and FHRP instance and record current authentication state, algorithm and key ID. Confirm platform support for HMAC-SHA-256, RFC 7474 and the OSPFv3 trailer.
2. Make interfaces passive first: this changes nothing on transit links and removes exposure on access segments immediately.
3. Build key chains centrally: generate random keys, store them in the secrets manager, and template them into configuration through your automation, not by hand.
4. Pilot one link or area: where supported, use a transition or accept-both mode (IS-IS transition mode, OSPF key chains with an accept-only key) so neighbours authenticate before you enforce. Schedule a change window anyway.
5. Enforce and verify: confirm adjacencies are up, check authentication failure counters are zero, and confirm routes are unchanged against a saved routing table snapshot.
6. Roll out by area or site: work outward from the backbone, leaving the transition mode on for the shortest possible time.
7. Roll back: keep the previous configuration staged; reverting removes authentication from both ends of the affected link, never one end.
8. Add CoPP and FHRP filtering: deploy control plane policies with a rate-limited default class and host-port FHRP drops, then tighten after two to four weeks of counter review (an NHI Mgmt Group recommendation).

Decision guidance

Detection and measurement

Routing attacks are visible if you log the right events and compare state against a baseline. Forward the following to your SIEM and see the Network Device Syslog and Configuration Change Detection Guide for collection design.

• Adjacency changes: neighbour up and down messages, especially a new neighbour on an interface that should be passive.
• Authentication failures: OSPF, IS-IS and EIGRP authentication mismatch counters and logs; a steady trickle on one segment means either a misconfiguration or someone probing.
• FHRP state changes: any change of the active or master router outside a change window.
• Route table drift: new prefixes, more-specific routes or changed next hops compared with a stored snapshot; route count spikes on redistribution points.
• Control plane drops: CoPP class counters, CPU spikes on routing processes.
• Configuration changes: removal of authentication, a changed key ID or a new passive-interface exception.

Common failure patterns

• Authentication on transit links, IGP live on user VLANs: the interface was never made passive, so a host can still send hellos and, in some implementations, learn the topology or trigger errors.
• MD5 keys set once and forgotten: the same key has been in every configuration backup for years and was shared with integrators and former staff.
• Keys stored reversibly: type 7 strings in backups and ticket attachments are effectively plain text, which is why attackers who harvest configurations, as in the Salt Typhoon telecom intrusions, gain far more than one device.
• Assuming authentication means replay protection: RFC 5709 and RFC 5310 both say it does not; without RFC 7474 or the OSPFv3 trailer an on-link attacker can replay recorded packets.
• VRRP authentication left over from VRRPv2: teams believe the gateway is protected when VRRPv3 has no authentication and nothing filters VRRP from host ports.
• CoPP deployed straight to drop: a missed protocol such as BFD or LDP is dropped and adjacencies flap, so the policy is removed and never returns.

Framework mapping

Practitioner checklist

• Make every IGP interface passive by default and keep an approved list of transit interfaces.
• Enable HMAC-SHA-256 for OSPFv2 (RFC 5709), the OSPFv3 authentication trailer (RFC 7166) and IS-IS Type 3 (RFC 5310); retire simple password and plain-text modes.
• Enable RFC 7474 extended sequence numbers where your platforms support it.
• Configure EIGRP SHA-256 authentication or, where not available, MD5 with a scheduled rotation and a migration plan.
• Block VRRP, HSRP and GLBP packets from host-facing ports and use MD5 key chains for HSRP.
• Deploy CoPP or a loopback filter based on RFC 6192, starting with a rate-limited default class.
• Store routing keys in a secrets manager, remove reversible password types and redact keys in backups.
• Alert on new adjacencies, authentication failures, FHRP state changes and route table drift.

Standards and references

• IETF: RFC 5709 OSPFv2 HMAC-SHA Cryptographic Authentication
• IETF: RFC 7474 Security Extension for OSPFv2 When Using Manual Key Management
• IETF: RFC 7166 Supporting Authentication Trailer for OSPFv3
• IETF: RFC 5310 IS-IS Generic Cryptographic Authentication
• IETF: RFC 9568 Virtual Router Redundancy Protocol (VRRP) Version 3
• IETF: RFC 6192 Protecting the Router Control Plane
• IETF: RFC 5082 The Generalized TTL Security Mechanism (GTSM)
• CISA: Enhanced Visibility and Hardening Guidance for Communications Infrastructure

Related NHI Mgmt Group resources: BGP and Routing Security Guide · Network Device Management Plane Hardening Guide · Layer 2 Attacks Guide · MPLS and Carrier WAN Security Guide