OSPF Explained: How Link-State Routing Works and How to Secure It

OSPF, Open Shortest Path First, is the link-state routing protocol that routers inside one organisation use to learn the full topology of their network and compute the shortest path to every destination. OSPFv2 for IPv4 is defined by RFC 2328 (Internet Standard STD 54, April 1998) and OSPFv3 for IPv6 by RFC 5340 (July 2008). It runs directly over IP as protocol number 89, not over TCP or UDP.

Most OSPF trouble in production is about trust, not the Dijkstra calculation: which routers may become neighbours, and whether a forged or replayed packet can tear down an adjacency. This post covers how OSPF works on the wire, what the IETF's own analysis (RFC 6863) says is weak, and how HMAC-SHA authentication (RFC 5709, RFC 7474) and the OSPFv3 Authentication Trailer (RFC 7166) close those gaps, with commands from the official FRRouting and BIRD documentation. For routing between organisations, see how BGP works and how to secure it.

Key takeaways

• OSPF is an interior gateway protocol: every router in an area holds the same link-state database and runs the same shortest path first (SPF) calculation. BGP carries policy-driven routes between autonomous systems over TCP port 179.
• Five packet types (Hello, Database Description, Link State Request, Link State Update, Link State Acknowledgment) drive a neighbour state machine from Down to Full.
• No OSPF authentication type provides confidentiality (RFC 2328). RFC 6863 (March 2013) found weak replay protection in both versions and an unprotected IP header in OSPFv2.
• The fixes: HMAC-SHA for OSPFv2 with HMAC-SHA-256 mandatory to implement (RFC 5709, October 2009), a 64-bit sequence number with a persistent boot count plus source address binding (RFC 7474, April 2015), and the OSPFv3 Authentication Trailer (RFC 7166, March 2014).
• Authentication stops outsiders, not a compromised or misconfigured router with valid keys. Passive interfaces, area design, filtering and change control cover that.
• In practice: HMAC-SHA-256 on every adjacency, passive everywhere else, clocks that never go backwards, and adjacency logging.

What OSPF is for, where it sits and which standards define it

A router needs a forwarding table: for each destination prefix, the next hop. Static routes work for a handful of routers; past that, a dynamic routing protocol recomputes tables when the network changes.

OSPF uses the link-state approach. Instead of telling neighbours "I can reach network X at cost 5", as a distance-vector protocol does, every OSPF router describes its own links: its neighbours, its attached networks and the cost of each. These descriptions are called link state advertisements (LSAs). LSAs are flooded reliably to every router in the area, so every router ends up with the same database, a complete map of the topology. Each router then runs Dijkstra's shortest path algorithm over that map, with itself at the root, and builds its forwarding table from the resulting tree. RFC 2328 names the Dijkstra algorithm explicitly in section 16.1.

Where OSPF sits in the stack

OSPF runs directly over IP. RFC 2328 states that "OSPF is IP protocol number 89", and RFC 5340 says the same number goes in the Next Header field of the IPv6 header for OSPFv3. There is no TCP connection and no UDP port. OSPF implements its own reliability, with acknowledgments and retransmission timers, for the packets that need it.

On broadcast networks OSPF uses two link-local multicast groups:

RFC 2328 says packets sent to these groups should never be forwarded and that their IP TTL must be set to 1, so they travel a single hop. The exception is virtual links, which carry OSPF packets across a transit area as unicast.

That single-hop design matters for security: anything that lets a packet arrive from further away, or lets an untrusted device join the link, changes the threat model.

The defining standards

The "updated by" lists come from the RFC Editor's metadata. IANA's OSPFv2 and OSPFv3 registries hold the code points.

OSPF vs BGP in one paragraph

OSPF and BGP solve different problems. OSPF is an interior gateway protocol: one organisation, one administrative domain, every router trusted to describe its own links honestly, and the goal is the fastest convergence to the lowest cost paths. BGP-4 (RFC 4271, January 2006) is the exterior protocol: it carries reachability between autonomous systems that do not trust each other, it listens on TCP port 179, and its route selection is driven by policy rather than a shared metric. A typical enterprise or data centre runs OSPF (or IS-IS) inside to find loopbacks and next hops, then runs BGP on top to carry customer or internet routes. Our BGP explainer covers RFC 7454 controls and origin validation, and route leaks vs hijacks explains the two failure modes that dominate BGP incidents.

How OSPF works on the wire

The OSPFv2 packet header

Every OSPFv2 packet starts with the same 24-byte header, defined in RFC 2328 Appendix A.3.1. The receiving router uses it to decide whether to process the packet at all.

With cryptographic authentication, the Authentication field holds an 8-bit Key ID, an 8-bit Auth Data Length and a 32-bit cryptographic sequence number; the digest is appended after the OSPF packet.

OSPFv3 shrinks this to a 16-byte header. RFC 5340 removed the AuType and Authentication fields entirely and added an 8-bit Instance ID, which lets several OSPF instances share one link.

The five packet types

The IANA "OSPF Packet Type" registry lists the same five values for both OSPFv2 and OSPFv3.

The Hello protocol

A router sends a Hello on every OSPF interface every HelloInterval seconds. RFC 2328 gives 10 seconds as a sample value for a LAN and suggests the RouterDeadInterval be "some multiple of the HelloInterval (say 4)". FRRouting documents its defaults as a 10 second hello interval and a 40 second dead interval.

A Hello carries the sender's network mask, HelloInterval, RouterDeadInterval, options bits, router priority, its view of the current DR and BDR, and the Router IDs of every neighbour it has heard from on that link. RFC 2328 section 10.5 says the receiver must check the network mask (except on point-to-point links and virtual links), HelloInterval and RouterDeadInterval against its own interface configuration, and drop the packet on any mismatch. The E-bit in the options must also match the area's external routing capability, which is how a stub area keeps out routers that expect external routes. This is why two routers with different timers never become neighbours: the protocol treats those values as a description of the shared network.

When a router sees its own Router ID listed in a neighbour's Hello, it knows communication is bidirectional.

The neighbour state machine

RFC 2328 section 10.1 defines eight neighbour states:

On a point-to-point link every neighbour proceeds to Full. On a broadcast segment such as an Ethernet VLAN, routers only form full adjacencies with the Designated Router and the Backup Designated Router. Other pairs stop at 2-Way, which is normal and not a fault. The DR is elected on Router Priority, highest wins, with the highest Router ID as the tie breaker; a priority of 0 makes a router ineligible. The DR then originates a network-LSA on behalf of the segment, which keeps the number of adjacencies and LSAs on a busy LAN manageable.

Database exchange and flooding

Once two routers decide to become adjacent, they synchronise databases. The flow looks like this:

Router A (Router ID 10.0.0.1)                    Router B (Router ID 10.0.0.2)
-----------------------------                    -----------------------------
Hello (neighbours: none)            ------>      state for A: Init
                                    <------      Hello (neighbours: 10.0.0.1)
state for B: 2-Way, adjacency wanted
DD (I, M, MS set, seq x, empty)     ------>      state: ExStart
                                    <------      DD (I, M, MS set, seq y, empty)
B has the higher Router ID, so B is master; A becomes slave and adopts seq y
DD (seq y, LSA headers)             ------>      state: Exchange
                                    <------      DD (seq y+1, LSA headers)
DD (seq y+1, LSA headers)           ------>
   ... one outstanding DD at a time, master polls, slave echoes ...
LSR (LSAs A is missing)             ------>      state: Loading
                                    <------      LSU (requested LSAs)
LSAck                               ------>
both request lists empty: Full                   Full

The I (Init), M (More) and MS (Master/Slave) bits in the DD packet drive ExStart and Exchange. RFC 2328 says only one DD packet may be outstanding at a time and each is explicitly acknowledged by the next one from the other side. The DD packet also carries the interface MTU; a mismatch is the most common reason two routers sit in ExStart or Exchange forever.

After the adjacency is Full, changes travel by flooding. A router that originates or receives a new LSA sends it in an LSU on its adjacencies, each neighbour acknowledges it with an LSAck, and unacknowledged LSAs are retransmitted every RxmtInterval (RFC 2328's sample value for a LAN is 5 seconds). Each router installs the LSA only if it is newer than its copy, then floods it onward.

How "newer" is decided: the LSA header and aging

Every LSA starts with a 20-byte header containing LS age, options, LS type, Link State ID, Advertising Router, LS sequence number, LS checksum and length. LS type, Link State ID and Advertising Router identify the LSA. Sequence number, checksum and age decide which instance is newer.

The sequence number is a signed 32-bit value. RFC 2328 reserves 0x80000000, starts every LSA at InitialSequenceNumber 0x80000001 and stops at MaxSequenceNumber 0x7FFFFFFF. A higher sequence number wins. When a sequence number would wrap, the originator must first flush the old instance by prematurely aging it to MaxAge and reflooding it.

RFC 2328 Appendix B fixes the timing constants:

MinLSInterval and MinLSArrival are OSPF's built-in brakes against churn from a flapping link or a misbehaving neighbour.

Protocol number, ports and IANA

OSPF has no TCP or UDP port; it is IP protocol 89 for both versions, so packet filters match it by protocol number. IANA's separate OSPF Authentication Codes registry holds AuType values 0 to 3.

Areas, LSA types and the SPF calculation

Areas and router roles

A single flat OSPF domain floods every LSA to every router and runs SPF over the whole topology. To keep databases small and failures local, OSPF splits a domain into areas. Area 0.0.0.0 is the backbone; every other area must attach to it, physically or through a virtual link. The topology inside an area is hidden from the rest of the domain, and other areas see only summarised prefixes.

LSA types

The LSA type tells you who originated it and how far it floods.

The OSPFv2 values come from the IANA "OSPFv2 Link State (LS) Type" registry, which also lists type 6 (group membership, historical) and reserves 0 and 8. The OSPFv3 codes come from RFC 5340, where the high bits of the LS type encode the flooding scope.

Stub and NSSA areas

Not every area needs the full external routing table. A stub area refuses AS-external-LSAs; the ABR injects a default route instead, and the E-bit check in Hellos keeps out routers that disagree. RFC 3101 (January 2003) defines the Not-So-Stubby Area (NSSA), which still refuses type 5 LSAs from elsewhere but lets a local ASBR inject its own externals as type 7 LSAs, which the ABR translates. These area types are a security tool as much as a scaling tool: an area that does not accept external routes cannot have them injected into it from elsewhere.

The SPF calculation

Each router runs SPF per area in three stages, described in RFC 2328 section 16:

1. Intra-area routes. Using router-LSAs and network-LSAs, the router builds a graph of the area and runs Dijkstra's algorithm with itself as the root. Each link's cost is the interface cost the advertising router configured. The result is a shortest path tree to every router and transit network in the area.
2. Inter-area routes. The router examines summary-LSAs from ABRs and adds each advertised prefix at the cost to the ABR plus the advertised cost.
3. External routes. AS-external-LSAs and NSSA-LSAs are added last, using the cost to the ASBR (or the forwarding address) and the external metric.

The preference order is fixed: intra-area beats inter-area, which beats external type 1, which beats external type 2. Equal-cost paths can all be installed. Because every router in an area computes from the same database, the results are loop-free as long as the databases are synchronised, which is exactly why the integrity of that database matters.

Versions and history

Two older ideas still surface in configurations. RFC 2328 changed the routing table calculation to prevent loops that the older RFC 1583 rules allowed, and implementations keep a compatibility switch; BIRD documents rfc1583compat with a default of off, and FRRouting documents that its equivalent "should NOT be set normally". And many networks still run OSPFv2 with keyed MD5 or with no authentication at all, years after RFC 5709 made HMAC-SHA-256 the mandatory-to-implement algorithm.

Where OSPF is deployed, OSPFv2 typically carries IPv4 and OSPFv3 carries IPv6 alongside it. RFC 5838 (April 2010) lets OSPFv3 carry other address families, including IPv4, through the Instance ID.

What changed in OSPFv3 (RFC 5340)

OSPFv3 keeps the same core: the same five packet types, the same neighbour state machine, flooding, areas, DR election and SPF. RFC 5340 section 2 lists what changed, and most of it comes from IPv6 itself.

• Per link, not per subnet. An IPv6 link can carry several prefixes, and two routers can talk over a link without sharing a prefix. OSPFv3 runs per link.
• Addressing removed from the protocol core. Router-LSAs and network-LSAs now describe only topology; IPv6 prefixes moved into new LSAs (intra-area-prefix-LSA 0x2009 and link-LSA 0x0008). Router IDs, Area IDs and Link State IDs stay 32 bits and are no longer addresses.
• Neighbours always identified by Router ID. OSPFv2 identified neighbours by IP address on broadcast, NBMA and point-to-multipoint links.
• Explicit flooding scope in the LS type field, and multiple instances per link through the Instance ID.
• Link-local addresses. Packets are sourced from the interface's link-local address (FE80::/10) except on virtual links.
• Authentication removed. The AuType and Authentication fields are gone. RFC 5340 relies on IPsec AH and ESP as described in RFC 4552. RFC 7166 later added the Authentication Trailer as an alternative.
• Bigger options. The Options field in Hello and DD packets grew to 24 bits.

RFC 8362 (April 2018) later made OSPFv3 LSAs extensible with TLVs.

The security-relevant change is the authentication one. Removing it from the protocol assumed IPsec would be deployed. RFC 7166's abstract records that "in some environments, it has been found that IPsec is difficult to configure and maintain", which is the polite way of saying many OSPFv3 networks ran with no authentication at all until the trailer arrived.

Security properties: what OSPF guarantees and what it does not

With cryptographic authentication configured, OSPF gives you:

• Packet integrity and origin authentication between routers that share a key. A router without the key cannot produce packets its neighbours accept.
• Limited replay protection, which depends on the version and extension (see below).
• Built-in damage limits: per-LSA sequence numbers, checksums, MinLSArrival and MaxAge limit stale or flapping data.

It does not give you:

• Confidentiality. RFC 2328 says directly: "None of the OSPF authentication types provide confidentiality. Nor do they protect against traffic analysis." Anyone on the link can read the topology. Only IPsec ESP with encryption (RFC 4552) changes that for OSPFv3.
• Protection from insiders. RFC 5340's Security Considerations note that its mechanisms "do not provide protection against compromised, malfunctioning, or misconfigured routers", which can disrupt the whole routing domain. A router with the right key can advertise anything.
• End to end authentication of routing data. Authentication is hop by hop. A router that receives an LSA verifies the packet came from its neighbour, not that the LSA's originator wrote it.
• Key management. RFC 2328 says key management "is also not addressed". Keys are configured by hand. RFC 4552 mandates manual keying for IPsec too, because IKE only works between two parties and OSPF multicast is one to many.

Weakness classes, described as concepts

These come first from the standards' own Security Considerations and from RFC 6863, the IETF analysis of OSPF against the Keying and Authentication for Routing Protocols (KARP) requirements. They describe what goes wrong and why the design allows it, not how to do it.

Unauthenticated adjacencies

With AuType 0 (null), any device that can send IP protocol 89 packets onto an OSPF-enabled link and pass the Hello checks can become a neighbour. The Hello checks compare timers, mask, area and options, all of which are visible to anyone on the link. The protocol was designed for a world where everything on a router link is a router. That assumption fails when OSPF is left enabled on interfaces facing servers, user VLANs, lab networks or shared exchange segments.

Simple password authentication (AuType 1) does not change much. The password travels in clear text in every packet; FRRouting's documentation calls it "insecure and deprecated", and BIRD's calls it "very weak".

LSA injection and false topology

Once a device is an adjacent neighbour, it can flood LSAs, and the rest of the area will install them if their sequence numbers are newer. A false router-LSA or external LSA can attract traffic toward the wrong place, create black holes, or make paths look shorter than they are. The design allows it because OSPF has no way to check that an LSA's content is true; the only gate is whether the packet that carried it was accepted. The same mechanism makes a misconfigured but legitimate router dangerous: redistributing a full table or a default route by accident floods to every router that accepts externals.

One internal defence: when a router receives a newer instance of an LSA claiming to be its own, RFC 2328 requires it to originate a fresh instance with a higher sequence number, or flush the bogus one. That limits how long a forged self-originated LSA survives, but not LSAs claiming to come from a router that is down or does not exist.

Replay

Cryptographic authentication proves a packet was built with the right key. It does not, by itself, prove the packet is new. RFC 6863 section 3 describes the gaps:

• OSPFv2's per-packet sequence number only has to be non-decreasing, not strictly increasing. Some implementations used values such as seconds since reboot, so the same number repeated for a whole second, leaving a window for intra-session replay.
• Replay state is held per adjacency. When an adjacency goes down, or a router reboots and its sequence number starts again from a lower value, a captured packet with a higher sequence number can be accepted again, after which the legitimate router's lower-numbered packets are rejected. RFC 6863 calls this inter-session replay.
• The most serious impacts it lists are against Hello packets, which can break adjacencies, and against Database Description exchanges, where a packet with the wrong DD sequence number restarts the exchange. Other replays cause excess flooding or CPU use.
• OSPFv3 before the Authentication Trailer had no per-packet sequence number at all, only per-LSA sequence numbers. RFC 6863 concludes that OSPFv3 then had "no defense against denial-of-service attacks that exploit replay".

Per-LSA sequence numbers still prevent a replay from installing old routing information, because a replayed LSA is not newer than the current one. Replay in OSPF is mainly an availability problem.

The unprotected IP header and neighbour identification

OSPFv2 identifies neighbours on broadcast, NBMA and point-to-multipoint links by IP source address, but the RFC 2328 and RFC 5709 digest covers only the OSPF packet. RFC 7474's abstract says this omission "can be exploited to carry out various types of attacks": a captured packet with its source address changed can be made to look like it came from a different neighbour with a different sequence number, disrupting that adjacency. RFC 7474 fixes it by mixing the IP source address into the HMAC computation.

Resource exhaustion

Cryptographic verification costs CPU, and so does SPF. A flood of packets that must be checked before they can be rejected, a stream of LSAs that keep triggering recalculation, or replays that keep forcing database exchanges can all push a router's control plane past its limits. RFC 6863 section 6 suggests mitigations: the Generalized TTL Security Mechanism (RFC 5082) except on virtual links, accepting non-Hello packets only from existing neighbours, and prioritising Hellos from known neighbours under load. RFC 4222 (October 2005) is a Best Current Practice on prioritising Hello and acknowledgment packets so that adjacencies survive congestion. MinLSArrival and MinLSInterval are the protocol's own rate limits.

Cross-protocol key reuse

If the same pre-shared key is used for OSPF and something else, an attacker who obtains a valid MAC in one protocol might try to use it in another. RFC 6863 lists this as a gap. RFC 7166 section 4.4 addresses it for OSPFv3 by appending a two-octet OSPFv3 Cryptographic Protocol ID to the key before use, so the same secret produces different MACs in different protocols. The general lesson stands regardless of version: never share routing keys with anything else.

Insiders and misconfiguration

The hardest class has no protocol fix. A compromised router, or a router configured with the wrong area, the wrong redistribution or a duplicate Router ID, holds valid keys and speaks valid OSPF. FRRouting's documentation is blunt that the Router ID "MUST be unique within the entire OSPF domain" and that "bad things will happen" otherwise. Defences here are operational: change control, configuration review, area boundaries, route filtering at ABRs and ASBRs, and monitoring.

How OSPF authentication works, and which version to use

OSPFv2 cryptographic authentication with HMAC-SHA (RFC 5709)

RFC 2328 Appendix D defined AuType 2, cryptographic authentication, with keyed MD5. Routers on a link share a secret key identified by a Key ID. For each packet the sender computes a digest over the OSPF packet and the key and appends it; the receiver recomputes and compares. Each key has four lifetimes, two for accepting and two for generating, so a new key can be accepted before anyone sends with it and keys can roll without dropping adjacencies.

RFC 5709 (October 2009) added HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512 to the same mechanism. Implementations "MUST include support for at least HMAC-SHA-256", should support HMAC-SHA-1, and should keep keyed MD5 only for backward compatibility. The algorithm is tied to the key, so changing algorithm is just a key rollover. RFC 6863 judged this sufficient for per-packet integrity and algorithm agility.

Extended sequence numbers and IP source protection (RFC 7474)

RFC 7474 (April 2015) fixes the two OSPFv2 replay problems for manually keyed deployments:

• It defines AuType 3, "Cryptographic Authentication with Extended Sequence Numbers", registered in the IANA OSPF Authentication Codes registry.
• The sequence number grows to 64 bits. The low 32 bits are a strictly increasing per-packet counter. The high 32 bits are a boot count, which "OSPFv2 implementations are required to retain" in non-volatile storage for the router's deployment life. Because the boot count never decreases, the combined sequence number never goes backwards, even after a cold reboot.
• The constant Apad value used in the RFC 5709 HMAC is replaced by the packet's IP source address, so a packet whose source address has been changed fails verification.

RFC 7474 also describes key selection from a key table, including how to pick keys for virtual links.

OSPFv3: IPsec (RFC 4552)

RFC 4552 (June 2006) protects OSPFv3 with IPsec. Implementations must support authentication, must support ESP and may support AH. ESP in transport mode authenticates the OSPF packet but not the IPv6 header; AH also covers the immutable header fields. If confidentiality is wanted, ESP must be used. Because OSPF multicasts and IKE only negotiates between two parties, RFC 4552 mandates manual keying with static security associations. RFC 5340 adds that an implementation must check that the SA which authenticated a packet is one trusted for OSPFv3, so a key configured for another protocol on the same box cannot authenticate routing packets.

In practice the IPsec route is heavy: it depends on the platform's IPsec stack, keys are static, and encrypted control packets are harder to prioritise. FRRouting's OSPFv3 documentation lists these drawbacks when explaining why it implements the trailer.

OSPFv3 Authentication Trailer (RFC 7166)

RFC 7166 (March 2014), which obsoletes RFC 6506, adds authentication back into OSPFv3 without IPsec:

• An AT-bit in the Options field of Hello and DD packets announces that an Authentication Trailer follows. It must be set in all Hello and DD packets that carry the trailer, so both sides know what to expect.
• The trailer carries a 16-bit Authentication Type (1 means HMAC cryptographic authentication), a length, a 16-bit Security Association ID that selects the key and algorithm, a 64-bit strictly increasing sequence number and the HMAC.
• Implementations must support HMAC-SHA-256 and must use it as the default; HMAC-SHA-1 is a should; HMAC-SHA-384 and HMAC-SHA-512 are mays.
• The Apad value starts with the IPv6 source address, so the source address is authenticated, and the key has a protocol ID appended before use to block cross-protocol replay.

Which mechanism to use

Secure configuration, with defender-side check commands

The commands below come from the official documentation of FRRouting (ospfd and ospf6d) and BIRD 2, and from the Linux ss manual page. Only run them against routers and hosts you own or are authorised to administer. FRRouting commands are entered at the vtysh prompt; BIRD commands are entered in its birdc client.

Step 1: know which interfaces speak OSPF

Every interface that sends Hellos is a place a neighbour can appear. On FRRouting, list OSPF interfaces and their state, then the neighbours on each:

show ip ospf interface
show ip ospf neighbor
show ip ospf neighbor detail
show ipv6 ospf6 interface
show ipv6 ospf6 neighbor

FRRouting supports json at the end of most of these, which makes it easy to feed the output into monitoring. On BIRD:

show ospf interface
show ospf neighbors

Compare the neighbour list with what you expect from the network diagram. A neighbour with an unfamiliar Router ID, or a neighbour on an interface that faces servers or users, is the first thing to investigate.

On a Linux router running an OSPF daemon, OSPF uses raw IP sockets rather than TCP or UDP. The ss man page documents -w (--raw) to display raw sockets, -a for all sockets, -n for numeric output and -p to show the owning process:

ss -wanp

Look for the OSPF daemon's raw socket and make sure no unexpected process holds one.

Step 2: make every non-router interface passive

A passive interface still advertises its prefix but does not send or accept OSPF packets. FRRouting documents passive-interface default to make all interfaces passive by default, and ip ospf passive per interface; for OSPFv3 it documents ipv6 ospf6 passive. The ospfd documentation notes that a passive interface is advertised as a stub link in the router-LSA, which also avoids redistributing connected routes as type 5 externals. BIRD documents stub yes on an interface, which means it "does not listen to any packet and does not send any hello".

A typical FRRouting pattern is passive by default, then enable OSPF explicitly on router-facing links:

router ospf
 ospf router-id 10.0.0.1
 passive-interface default
 log-adjacency-changes detail
!
interface eth1
 no ip ospf passive
 ip ospf area 0

Step 3: turn on HMAC-SHA authentication for OSPFv2

FRRouting's ospfd documentation describes ip ospf authentication key-chain KEYCHAIN for HMAC cryptographic authentication with a key chain, and gives this example:

key chain temp
 key 13
  key-string ospf
  cryptographic-algorithm hmac-sha-256
!
interface eth0
 ip ospf authentication key-chain temp
 ip ospf area 0

Use a long random key, not the example string. The older ip ospf message-digest-key KEYID md5 KEY form is MD5 only, and ip ospf authentication-key is the simple password type the documentation calls insecure.

FRRouting also documents compatible rfc7474, which controls strict sequence number validation for OSPFv2 cryptographic authentication. When enabled, which the documentation says is the default, received packets must have strictly increasing sequence numbers; disabling it accepts equal sequence numbers for interoperability with implementations that reuse them. Leave it on unless a specific neighbour forces you otherwise, and if you must disable it, do it per interface:

ip ospf compatible rfc7474 disable

In BIRD 2, cryptographic authentication is set per interface with a password block. The BIRD documentation states the default algorithm for OSPFv2 keys is keyed MD5 and for OSPFv3 keys is HMAC-SHA-256, so set the algorithm explicitly for OSPFv2:

protocol ospf v2 core {
    area 0.0.0.0 {
        interface "eth0" {
            authentication cryptographic;
            password "use-a-long-random-secret" {
                id 1;
                algorithm hmac sha256;
            };
        };
        interface "eth2" {
            stub yes;
        };
    };
}

BIRD's password block also supports generate from, generate to, accept from and accept to dates, which map directly onto RFC 2328's four key lifetimes and make planned key rollover possible.

Step 4: turn on the OSPFv3 Authentication Trailer

FRRouting's ospf6d documentation states its trailer support is for RFC 7166, and documents two mutually exclusive ways to configure it on an interface:

interface ens192
 ipv6 ospf6 authentication key-id 10 hash-algo hmac-sha-256 key REPLACE_WITH_SECRET

or with a key chain:

interface ens192
 ipv6 ospf6 authentication keychain KEYCHAIN_NAME

The documentation notes that FRRouting supports MD5 and HMAC-SHA-256 internally and needs to be built with OpenSSL for HMAC-SHA-1, HMAC-SHA-384 and HMAC-SHA-512. Choose HMAC-SHA-256 and you avoid the dependency.

In BIRD, protocol ospf v3 with authentication cryptographic on the interface uses HMAC-SHA-256 by default for OSPFv3 keys.

Step 5: verify authentication is actually on

On FRRouting for OSPFv3, the interface output shows a line such as "Authentication trailer is enabled with manual key" and Tx and Rx drop counters:

show ipv6 ospf6 interface ens192
show ipv6 ospf6 neighbor 2.2.2.2 detail
show ipv6 ospf6

The neighbour detail shows "Authentication header present" with the last sequence numbers received for each packet type, and show ipv6 ospf6 shows the process's own authentication sequence number. Rising Rx drop counters mean packets are failing authentication: either a misconfigured neighbour or something on the link that should not be there. The counters can be reset with clear ipv6 ospf6 auth-counters interface IFNAME after you investigate.

On FRRouting for OSPFv2, confirm in the running configuration that every OSPF interface carries an ip ospf authentication key-chain line, then confirm every neighbour you expect is Full and nothing else is:

show running-config
show ip ospf interface eth0
show ip ospf neighbor detail

A neighbour that drops out right after you enable authentication is a key or algorithm mismatch on that link, which is the check doing its job.

For BIRD, show ospf interface reports per-interface settings and show ospf neighbors shows adjacency state.

Step 6: keep clocks from going backwards

FRRouting's documentation warns that OSPF MD5 and HMAC authentication require "that time never go backwards", even across resets, if ospfd is to re-establish adjacencies promptly after a restart. Its sequence numbers are derived from time. Set the clock at boot from a battery-backed clock or NTP, or save and restore it. This is the operational shadow of RFC 7474's boot count requirement: whatever the implementation uses, the sequence number must survive a reboot without decreasing.

Step 7: add TTL security where your implementation supports it

BIRD documents ttl security yes for OSPF interfaces: packets are sent with TTL 255 and received packets with any lower TTL are dropped, which makes it hard to inject OSPF packets from beyond the link. The documentation notes it "would interfere with OSPF virtual links", and both sides must agree. RFC 6863 makes the same point about GTSM and virtual links.

Step 8: log, monitor and limit what can be injected

• Turn on adjacency logging. FRRouting's log-adjacency-changes detail logs every state change; without detail it logs only changes to Full and regressions.
• Watch the LSDB for surprises. FRRouting's show ip ospf database with self-originate, adv-router and max-age filters, and BIRD's show ospf lsadb and show ospf state, let you spot unknown advertising routers, LSAs being flushed and external routes you did not expect.
• Use stub or NSSA areas where an area has no business receiving external routes, and filter summaries at ABRs.
• Use max-metric router-lsa (FRRouting) for planned maintenance so a router drains traffic before you take it down, rather than letting neighbours discover the failure.
• At the host or switch level, permit IP protocol 89 only on interfaces where routers are supposed to peer.

Step 9: keep the routing daemon itself current

OSPF daemons parse packets from the network. Track the FRRouting or BIRD version in every router, appliance and image you build, and rebuild when a parsing bug is fixed.

OSPF vs IS-IS vs BGP vs static routing: when to use which

Static routes cannot be injected over the wire, so they suit stub sites and management networks. IS-IS running directly on the link layer means a remote IP host cannot even address it. And OSPF is not designed to carry routes from parties you do not trust; use BGP at every trust boundary.

Common mistakes

• Leaving OSPF on user, server or lab interfaces. If an interface does not face another router, make it passive. This one change removes most of the unauthenticated adjacency risk.
• Treating simple password authentication as security. The password is sent in clear text in every packet.
• Staying on keyed MD5 because it works. RFC 5709 made HMAC-SHA-256 the mandatory-to-implement algorithm in 2009. Move during a planned key rollover.
• Assuming authentication hides the topology. It does not. Only IPsec ESP with encryption provides confidentiality.
• Running OSPFv3 with no authentication because IPsec was too hard. The Authentication Trailer exists for exactly this case.
• Disabling strict sequence number checks globally for one old neighbour. Scope any exception to the one interface.
• Letting router clocks go backwards after a reboot. Time-based sequence numbers then decrease and neighbours reject the router until replay state times out.
• Duplicate Router IDs. Two routers with the same ID fight over the same LSAs and the database never settles.
• Ignoring MTU mismatches. Neighbours stuck in ExStart or Exchange almost always disagree on MTU. Fix the MTU rather than reaching for the ignore option by habit.
• Redistributing everything. Redistributing connected or BGP routes into OSPF without a route map floods every prefix as an external LSA to the whole domain.

FAQ

What port does OSPF use?

None. OSPF does not use TCP or UDP. It runs directly over IP as protocol number 89, for both OSPFv2 and OSPFv3. Firewalls and packet filters match it by protocol number. Hellos go to the multicast groups 224.0.0.5 (IPv4) and FF02::5 (IPv6).

Is OSPF encrypted?

No. RFC 2328 states that none of OSPFv2's authentication types provide confidentiality. Authentication with HMAC-SHA proves packets came from a router that holds the key, but anyone on the link can still read them. For OSPFv3, IPsec ESP with encryption (RFC 4552) is the only standard way to encrypt routing packets.

What is the difference between OSPF and BGP?

OSPF is an interior gateway protocol that finds the lowest cost paths inside one organisation using a shared link-state database. BGP is a path-vector protocol that exchanges routes between organisations over TCP port 179, with selection driven by policy. Most networks use both: OSPF inside, BGP at the edge.

What are the OSPF neighbour states?

Down, Attempt (NBMA only), Init, 2-Way, ExStart, Exchange, Loading and Full, as defined in RFC 2328 section 10.1. Full means the databases are synchronised. On broadcast networks, routers that are not DR or BDR stay in 2-Way with each other, which is normal.

What are the OSPF LSA types?

In OSPFv2: type 1 router, 2 network, 3 summary for networks, 4 summary for ASBRs, 5 AS-external, 7 NSSA external, and 9 to 11 opaque. OSPFv3 renumbers them as function codes and adds link-LSAs and intra-area-prefix-LSAs to carry IPv6 prefixes.

How do I secure OSPF?

Make non-router interfaces passive, use HMAC-SHA-256 on every adjacency (RFC 5709 for OSPFv2, the RFC 7166 trailer for OSPFv3), keep router clocks from going backwards, log adjacency changes and filter what ASBRs redistribute.

OSPFv2 vs OSPFv3: what is the difference?

OSPFv2 routes IPv4. OSPFv3 was built for IPv6: it runs per link, removes addresses from the core LSAs, identifies neighbours by Router ID, encodes flooding scope in the LSA type, supports multiple instances per link and removed built-in authentication in favour of IPsec, later adding the Authentication Trailer. With RFC 5838, OSPFv3 can carry IPv4 too.

Is OSPF MD5 authentication still safe?

RFC 6863 notes MD5 had not been broken as a MAC but "is not the algorithm of choice for new MACs". RFC 5709 made HMAC-SHA-256 mandatory to implement and keeps keyed MD5 for backward compatibility only. Migrate.

OSPF vs IS-IS: which should I use?

Both are link-state IGPs that run SPF. OSPF runs over IP and splits IPv4 and IPv6 into two protocol versions; IS-IS runs directly over the link layer and carries both address families in one protocol. Pick the one your platforms and team support well; neither is inherently more secure if authentication and passive interfaces are configured properly.

How do I check OSPF neighbours on Linux?

On FRRouting, run show ip ospf neighbor or show ipv6 ospf6 neighbor in vtysh. On BIRD, run show ospf neighbors in birdc. To see the daemon's raw socket, ss -wanp lists raw sockets with their owning processes.

Where Safeguard fits

Safeguard does not inspect, capture or filter OSPF traffic, does not configure routers and does not monitor routing tables. Nothing in the hardening steps above depends on it. The honest connection is the software that implements OSPF.

OSPF often runs as open source software: FRRouting and BIRD daemons inside appliances, virtual routers and container images that teams build themselves. Safeguard's software composition analysis, generally available, builds a full transitive dependency inventory of what is inside those builds, and its SBOM generation and analysis, also generally available, records them in SPDX or CycloneDX. Container scanning, generally available as part of ESSCM, shows which routing daemon version and which crypto library sit inside each image. Vulnerability management with EPSS and KEV enrichment, and reachability analysis and prioritisation, both generally available, help you decide which findings to fix first. Asset discovery, generally available, helps find the systems you did not know were running a routing daemon. Policies and gates at build, CI and release, generally available, can stop an image that carries a known vulnerable daemon version from shipping. When a router vendor's own firmware is affected, the fix still comes from that vendor. Our post on using SBOMs to find affected products fast shows the workflow when the next routing daemon advisory lands.

Fix it without waiting for upstream

OSPF bugs that matter usually live in a routing daemon or a library it depends on, such as the packet parser in ospfd or the crypto library behind HMAC verification. When those ship inside images and appliances you build, you do not have to wait.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and remediation workflows, not routing protocol monitoring or router configuration. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. Pointed at a container image you build around a routing daemon, the same scan lists the packages inside it, including the daemon and the crypto library it uses for HMAC, with their versions and known vulnerabilities.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: the assistant reads a finding and its advisory, asks before each command, edits a dependency to the fixed version and runs the install and tests with your approval, then pushes nothing. The example is a JavaScript library, but the flow is the same when the finding is a vulnerable package in a router image's build files: read, propose, approve, test.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your projects or images ship a particular version of a routing daemon or crypto library and get the answer from your own scan data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• RFC 2328: OSPF Version 2, STD 54, April 1998
• RFC 5340: OSPF for IPv6, July 2008
• RFC 5709: OSPFv2 HMAC-SHA Cryptographic Authentication, October 2009
• RFC 7474: Security Extension for OSPFv2 When Using Manual Key Management, April 2015
• RFC 7166: Supporting Authentication Trailer for OSPFv3, March 2014
• RFC 4552: Authentication/Confidentiality for OSPFv3, June 2006
• RFC 6863: Analysis of OSPF Security According to the KARP Design Guide, March 2013
• RFC 5250: The OSPF Opaque LSA Option, July 2008
• RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option, January 2003
• RFC 8362: OSPFv3 Link State Advertisement (LSA) Extensibility, April 2018
• RFC 5838: Support of Address Families in OSPFv3, April 2010
• RFC 6987: OSPF Stub Router Advertisement, September 2013
• RFC 4222: Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance, October 2005
• RFC 5082: The Generalized TTL Security Mechanism (GTSM), October 2007
• RFC 2178: OSPF Version 2, July 1997
• RFC 1247: OSPF Version 2, July 1991
• RFC 1131: OSPF specification, October 1989
• RFC 1195: Use of OSI IS-IS for Routing in TCP/IP and Dual Environments, December 1990
• RFC 5310: IS-IS Generic Cryptographic Authentication, February 2009
• RFC 4271: A Border Gateway Protocol 4 (BGP-4), January 2006
• IANA: OSPFv2 Parameters
• IANA: OSPFv3 Parameters
• IANA: OSPF Authentication Codes
• FRRouting documentation: OSPFv2 (ospfd)
• FRRouting documentation: OSPFv3 (ospf6d)
• BIRD 2 User's Guide: Protocols (OSPF)
• BIRD 2 User's Guide: Remote control
• ss(8), Linux manual page

Last reviewed: 23 October 2026. Routing daemon defaults and command syntax change between releases; check the documentation for the FRRouting or BIRD version you actually run.