An HMAC Authentication Extension for the Virtual Router Redundancy Protocol (VRRP)

5.1. Placement and Detection

A sender appends the trailer after the VRRP advertisement, that is, after the last virtual IP address and after any version-2 authentication area, as the final octets of the IP payload. The IPv4 Total Length or the IPv6 Payload Length grows by the trailer size. Integrity of both the message and the trailer comes from the HMAC, not from the VRRP checksum, which anyone can recompute. On IPv4 that checksum is computed over the VRRP message and excludes the trailer, while on IPv6, where the kernel checksums the whole payload, it includes it. The difference is harmless, because every node in a group computes and verifies it the same way.¶

VRRP has no spare header bit to flag the extension, so a receiver detects the trailer by length. The trailer is a fixed 28 octets. When the received IP payload is exactly the expected VRRP message length plus 28 octets, the last 28 octets are the trailer. Normal advertisements never carry trailing padding of that size, so the test is unambiguous. The trailer counts against the link MTU like the address list does, and a sender MUST keep the whole advertisement within the MTU to avoid fragmentation.¶

5.2. Trailer Fields

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Ext Type   |     Key ID    |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Seconds                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Subseconds           |            Counter            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                 HMAC (128 bits, truncated)                    |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ext Type

The authentication scheme. This document defines value 1, HMAC-SHA256 truncated to 128 bits. A sender uses one configured scheme. A receiver drops a trailer whose Ext Type it does not support.¶

Key ID

Selects the key that verifies the HMAC. Values run from 1 to 255, and 0 is invalid. Holding several keys at once is what lets a group rotate keys (Section 9).¶

Reserved

MUST be zero on send and MUST be checked as zero on receipt.¶

Seconds

The integer-seconds part of the sequence number, the sender UTC time as an unsigned count of seconds since the Unix epoch modulo 2^32, in network byte order (Section 8.1).¶

Subseconds

The fractional-seconds part of the sequence number, a 16-bit binary fraction giving a timestamp resolution of 2^-16 s, in network byte order.¶

Counter

A 16-bit tie-breaker for advertisements that share one timestamp (Section 8.1).¶

HMAC

The truncated HMAC computed over the inputs in Section 5.4.¶

5.3. Pseudo-Header

The HMAC binds a 20-octet pseudo-header that never travels on the wire. Family, Version, VRID and Zero each occupy one octet, followed by a 16-octet Address. Both sender and receiver reconstruct it from fields they already hold:¶

Family

4 for IPv4, 6 for IPv6.¶

Version

The VRRP version of the advertisement.¶

VRID

The virtual router identifier.¶

Zero

Set to zero.¶

Address

The sender IP source address. For IPv4 it occupies the first 4 octets and the rest is zero. For IPv6 it fills all 16.¶

Binding the family, version and VRID stops a captured trailer from being spliced onto a different instance that happens to share a key. Binding the source address ties the advertisement to its claimed sender. The receiver builds the pseudo-header from the source address of the packet it received, so a spoofed source still has to carry an HMAC computed over that same address, which an attacker without the key cannot produce. By the same token, the address the receiver observes must match the one the sender signed, so the extension does not operate across a source NAT between peers.¶

5.4. HMAC Computation

The HMAC is HMAC-SHA256 [RFC2104] [RFC6234] over the concatenation of the pseudo-header, the VRRP message and the trailer with its HMAC field zeroed, truncated to the high-order 128 bits:¶

   HMAC = HMAC-SHA256(K, pseudo || vrrp || prefix || Z) [0..15]

where K is the key named by Key ID, pseudo is the 20-octet pseudo-header of the previous section, vrrp is the VRRP message from the start of the VRRP header through the last address (the IP header is not included), prefix is the first 12 octets of the trailer, that is Ext Type through Counter, and Z is 16 zero octets standing in for the HMAC field. The sender writes the 16-octet result into the HMAC field. The IP header is excluded so that a change to the hop limit or the header checksum in transit does not break the HMAC.¶

8.1. Sequence Number

The sequence number is an unsigned 64-bit value made of the 32-bit Seconds, the 16-bit Subseconds and the 16-bit Counter, most significant first. Seconds is the sender UTC time in seconds since the Unix epoch (1970-01-01T00:00:00Z), the same absolute reference on every node, which NTP distributes as UTC. Subseconds adds a binary fraction of a second, so the high 48 bits form a high-resolution timestamp and the Counter only separates advertisements that share one timestamp. A handful of Counter values suffice, because the 10 ms minimum advertisement interval caps a sender near a hundred advertisements per second, and the immediate advertisement a higher-priority router sends on seeing a lower-priority one (Section 6.4.3 of [RFC9568]) adds only a few.¶

A sender keeps the last sequence it used. On each transmission it loads its clock into Seconds and Subseconds with Counter zero, then sends that value if it exceeds the stored one, otherwise the stored value plus one. The increment raises Counter and carries into the timestamp on overflow, so the sequence advances even when the clock has not. The sender never lets the sequence move backward, so a backward step of the clock, including a leap second, keeps monotonicity, and the sequence needs no persistent storage as long as the clock advances across a restart.¶

All three fields are unsigned and wrap, so all comparisons are modular rather than absolute. A receiver orders two sequences under serial number arithmetic [RFC1982] and forms the time-mode difference from the Seconds field as a signed 32-bit value modulo 2^32. A legitimate clock difference is far smaller than the 2^32-second wrap period, so the wrap is a non-event and the extension needs no epoch other than the Unix one.¶

8.2. Freshness Modes

The receiver enforces freshness in one of two modes. In time mode, the default, it keeps the freshness window of step 4 and also keeps the per-sender high-water mark, so a valid but old capture is rejected both by absolute time and by the sequence. Time mode requires the group to keep its clocks in sync, for instance with NTP. In monotonic mode it drops the window and relies on the high-water mark alone, which removes the dependency on synchronized clocks at the cost of bounding freshness only against the last packet seen from each sender. The sequence is still clock-derived, so monotonic mode drops only the need for clocks to agree between nodes, not the need for a sender's clock to advance across a restart (Section 8.1). A node that cannot guarantee the latter SHOULD persist its last sequence or use time mode, otherwise a restart can leave its advertisements rejected until the sequence climbs back above the stored high-water mark. A receiver MAY instead expire a long-silent sender's high-water mark so a restarted sender is treated as new, at the cost of a replay window as long as that timeout. The window defaults to three advertisement intervals with a floor of 5 seconds, and is configurable from 1 to 300 seconds.¶

8.3. Per-Sender State

Replay state is per sender, because each active router signs an independent sequence. For unicast, the receiver anchors the state on the configured peer whose address matches the packet source, and it drops a packet whose source is not a configured peer. For multicast there is no configured peer list, so the receiver keeps a small table of recent senders keyed by source address and evicts the least recently used entry when the table is full. The table is touched only after the HMAC verifies, so an attacker who floods forged source addresses cannot churn it. A handful of slots suffice, because several legitimate senders for one VRID appear only during a transient election.¶

11.1. Threat Model

The extension targets an adversary who can place a packet at a receiver with a spoofed source address but does not hold the group key. For unicast this includes any party that can reach the receiver across the routed or overlay network, such as another tenant in a shared fabric or a compromised host in a different subnet. For multicast it includes a host on the local link. The adversary may inject forged advertisements and replay captured ones, aiming to seize the virtual address by advertising a high priority, to force a failover with priority 0, or to flap the group.¶

11.2. What the Extension Provides

A valid HMAC proves that the sender holds the group key and that the VRRP message and the bound fields arrived intact. The pseudo-header binds the family, version, VRID and source address, so a captured trailer cannot be spliced onto another instance or accepted from another source. The sequence number and, in time mode, the freshness window reject replays. Against the off-segment unicast attacker this restores the protection that the hop-limit check gave on a shared link, and it does so whether or not that check still applies.¶

11.3. Group Key

The scheme uses one symmetric key per group, so every member can impersonate every other member. It defends the group perimeter, not one member against another, which matches the VRRP trust model where all routers in a group are mutually trusting. A compromised node exposes the key for the whole group, and the response is to rotate the key out as in Section 9.¶

11.4. Denial of Service

A receiver computes at most one HMAC per packet that passes the cheap length check and, in time mode, the freshness window, so replayed captures are shed before the digest. Monotonic mode keeps no window, so there every length-correct packet reaches the digest. A flood that clears these checks still forces one HMAC per packet, so an operator SHOULD keep the usual rate limiting and network-layer filtering in place.¶

11.5. Clock Dependence

Time mode drops advertisements when the sender and receiver clocks differ by more than the window, so a group that uses it depends on time synchronization for availability. Where that is not assured, monotonic mode (Section 8.2) removes the dependency on clock agreement between nodes, though a sender's clock must still advance across a restart unless the sender persists its last sequence (Section 8.1).¶

11.6. Cryptographic Strength

HMAC-SHA256 truncated to 128 bits gives 128-bit forgery resistance, which is appropriate for a per-packet HMAC on a control protocol. The 256-bit minimum key preserves a 128-bit margin under Grover's quantum search algorithm [GROVER]. The receiver compares the HMAC in constant time so that the comparison leaks no timing information about the expected HMAC.¶

11.7. Relationship to Other Mechanisms

On a multicast link the extension complements the hop-limit check rather than replacing it, since a host on the link can forge a hop limit of 255 but cannot forge the HMAC. Compared with IPsec and the IP Authentication Header [RFC4302], the extension avoids IKE and per-packet security-association state, works identically for VRRPv2 and VRRPv3, and carries its own key rotation, at the cost of being specific to VRRP and using a single group key.¶