An HMAC Authentication Extension for the Virtual Router Redundancy Protocol (VRRP)
draft-cassen-vrrp-auth-hmac-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Alexandre Cassen , Quentin Armitage | ||
| Last updated | 2026-07-27 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Additional Web Page
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-cassen-vrrp-auth-hmac-01
Routing Area Working Group A. Cassen
Internet-Draft Free
Intended status: Standards Track Q. Armitage
Expires: 28 January 2027 keepalived.org
27 July 2026
An HMAC Authentication Extension for the Virtual Router Redundancy
Protocol (VRRP)
draft-cassen-vrrp-auth-hmac-01
Abstract
VRRP relies on a hop limit of 255 to prove that an advertisement came
from the local link. That guard cannot apply when advertisements
travel as multi-hop unicast across a routed or overlay network, as is
common in cloud deployments, leaving the protocol open to off-segment
injection and replay. The legacy VRRPv2 authentication types do not
close this gap and were removed from later VRRP specifications. This
document defines an authentication extension that appends an HMAC-
SHA256 trailer and a time-based sequence number to VRRPv3
advertisements, authenticating the sender as a holder of the group
key, protecting message integrity and bounding replay, for both IP
address families. The extension is the primary defense where the
hop-limit check cannot apply, and defense in depth for multicast and
single-hop unicast, where that check remains in force.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Cassen & Armitage Expires 28 January 2027 [Page 1]
Internet-Draft VRRP HMAC Authentication July 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Advertisement Trailer Format . . . . . . . . . . . . . . . . 5
5.1. Placement and Detection . . . . . . . . . . . . . . . . . 5
5.2. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 6
5.3. Pseudo-Header . . . . . . . . . . . . . . . . . . . . . . 7
5.4. HMAC Computation . . . . . . . . . . . . . . . . . . . . 7
6. Sending Advertisements . . . . . . . . . . . . . . . . . . . 8
7. Receiving Advertisements . . . . . . . . . . . . . . . . . . 8
8. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Sequence Number . . . . . . . . . . . . . . . . . . . . . 9
8.2. Freshness Modes . . . . . . . . . . . . . . . . . . . . . 10
8.3. Per-Sender State . . . . . . . . . . . . . . . . . . . . 11
9. Key Management and Rotation . . . . . . . . . . . . . . . . . 11
10. Deployment and Migration . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 13
11.2. What the Extension Provides . . . . . . . . . . . . . . 13
11.3. Group Key . . . . . . . . . . . . . . . . . . . . . . . 13
11.4. Migration Exposure . . . . . . . . . . . . . . . . . . . 13
11.5. Denial of Service . . . . . . . . . . . . . . . . . . . 14
11.6. Clock Dependence . . . . . . . . . . . . . . . . . . . . 14
11.7. State Loss and Replay . . . . . . . . . . . . . . . . . 14
11.8. Cryptographic Strength . . . . . . . . . . . . . . . . . 14
11.9. Relationship to Other Mechanisms . . . . . . . . . . . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 17
A.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Cassen & Armitage Expires 28 January 2027 [Page 2]
Internet-Draft VRRP HMAC Authentication July 2026
1. Introduction
The Virtual Router Redundancy Protocol [RFC9568] lets a group of
routers share a virtual IP address so that a backup takes over when
the active router fails. VRRP was designed as a first-hop protocol
that runs on a single link, and its only built-in protection against
a forged advertisement is the hop limit. An active router sends
every advertisement with an IPv4 TTL or an IPv6 Hop Limit of 255, and
a receiver drops any advertisement that does not arrive with that
value. Because a router cannot raise a hop limit, an advertisement
that arrives with 255 cannot have crossed a router, which proves it
originated on the local link. This is the Generalized TTL Security
Mechanism (GTSM) [RFC5082], and VRRPv3 leans on it entirely.
Unicast operation by itself does not lose that guard. A unicast VRRP
specification that keeps the group on a shared link
[I-D.abinabraham-vrrp-unicast] sends with a hop limit of 255 and
rejects anything lower, so GTSM holds exactly as it does for
multicast, and that specification explicitly excludes multi-hop
operation. The gap opens in the deployments that go further.
Implementations commonly run VRRP in cloud and virtualized networks
where multicast is unavailable and the peers sit behind routers, so
advertisements travel as unicast to a configured list of peers. They
cross hops, arrive with a hop limit well below 255, and the receiver
has to relax the check to accept them. The moment it does, the only
guard VRRP had is gone. Anyone who can place a packet at the
receiver with a spoofed source address can inject a forged
advertisement that raises priority to demote the legitimate active
router or sets priority 0 to force an immediate failover. Captured
advertisements replay just as easily.
Routed path: no multicast, TTL decremented en route
ACTIVE --- advert (VRID 51, prio 200) ---> BACKUP
198.51.100.10 192.0.2.10
^
| spoofed advert: src = 192.0.2.10 (a peer), prio 255
ATTACKER
203.0.113.9
Figure 1: Off-segment injection against multi-hop unicast VRRP
The same attack and defense apply over IPv6, where a deployment would
use addresses such as 2001:db8::10 in place of those above.
The authentication types of earlier VRRP versions were removed as
ineffective [RFC3768] and never carried into VRRPv3. In practice,
unicast VRRP runs unauthenticated.
Cassen & Armitage Expires 28 January 2027 [Page 3]
Internet-Draft VRRP HMAC Authentication July 2026
This document defines an authentication extension that closes the
gap. It appends to each advertisement a trailer carrying an HMAC-
SHA256 and a time-based sequence number. The HMAC authenticates the
sender as a holder of the group key and protects integrity, the
sequence number bounds replay, and both work the same way for unicast
and multicast. For multi-hop unicast, where the hop-limit check
cannot apply, the extension is the primary defense. For multicast
and single-hop unicast it adds defense in depth against a compromised
host on the local link.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Definitions
Trailer The authentication trailer this document appends to an
advertisement.
HMAC The truncated HMAC-SHA256 carried in the trailer.
Group key A symmetric key shared by every node of the virtual router
group. A group holds one or more of them under distinct Key
IDs (Section 9) and a sender signs with one.
Single-hop Sender and receiver share a link. No router forwards the
advertisement, so the hop limit arrives intact and GTSM
holds.
Multi-hop The advertisement crosses one or more routers, each of
which decrements the hop limit, so GTSM cannot apply.
4. Applicability
The extension applies to VRRPv3 [RFC9568] advertisements, for both
address families. A group either uses it on every node or on none,
since a node that does not understand the trailer sees a longer
packet and rejects it (Section 10). It authenticates advertisements
only. It does not protect any other VRRP traffic and provides no
confidentiality, which VRRP does not need because an advertisement
carries routing intent rather than secret data.
Three deployment models differ in what the hop limit still proves,
and the extension plays a different role in each.
Cassen & Armitage Expires 28 January 2027 [Page 4]
Internet-Draft VRRP HMAC Authentication July 2026
multicast
The hop-limit check of [RFC9568] is mandatory and GTSM holds. The
extension adds group-key-holder authentication, integrity and
replay protection on top of it.
single-hop unicast
The group stays on a shared link and the hop-limit check of
[I-D.abinabraham-vrrp-unicast] is equally mandatory. The
extension plays the same defense-in-depth role.
multi-hop unicast
The advertisement crosses routers, the hop-limit check cannot
succeed and is relaxed. The extension is the primary defense.
In multicast and single-hop unicast operation a receiver MUST keep
enforcing the hop-limit check, since this extension complements GTSM
and never replaces it.
Multi-hop operation itself is out of scope for this document. Hop-
limit policy, source address selection, peer validation and routing
behaviour for a routed VRRP deployment belong to a dedicated
specification, and [I-D.abinabraham-vrrp-unicast] notes that multi-
hop operation needs a security model of its own. This extension
supplies the authentication and anti-replay component of that model.
A multi-hop deployment or a future multi-hop specification SHOULD
require it in enforce mode (Section 10) or an equivalent
authenticated channel, since GTSM cannot apply there.
5. Advertisement Trailer Format
5.1. Placement and Detection
A sender appends the trailer after the last virtual IP address, 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 the checksum covers
the VRRP message without the trailer [RFC9568], while on IPv6 the
mandatory transport checksum covers the whole IP payload, trailer and
HMAC included. The coverage difference cannot affect authentication,
because the checksum field is read as zero when the HMAC is computed
and verified (Section 5.4).
VRRP has no spare header bit to flag the extension, so a receiver
detects the trailer by length. The trailer starts at the expected
VRRP message length, which follows from the address count in the VRRP
header, and its total length is a fixed property of its Ext Type
(Section 12), 28 octets for the scheme of this document. The IP
Cassen & Armitage Expires 28 January 2027 [Page 5]
Internet-Draft VRRP HMAC Authentication July 2026
payload length is taken from the IP header, the IPv4 Total Length
minus the header length or the IPv6 Payload Length, so link-layer
padding never reaches the test. The receive rules of Section 7
accept an exact scheme length, in the migration modes the bare
message length, and drop everything else.
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Authentication trailer, Ext Type 1 (28 octets)
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 an advertisement
carrying an Ext Type it does not support or is configured
not to accept.
Key ID Selects the key that verifies the HMAC (Section 9). Values
run from 1 to 255, and 0 is invalid.
Reserved MUST be zero on send and MUST be checked as zero on
receipt.
Seconds The integer-seconds part of the sequence number, 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 (Section 8.1).
Counter A 16-bit tie-breaker for advertisements that share one
timestamp, in network byte order (Section 8.1).
HMAC The truncated HMAC computed over the inputs in Section 5.4.
Cassen & Armitage Expires 28 January 2027 [Page 6]
Internet-Draft VRRP HMAC Authentication July 2026
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 A padding octet set to zero. It rounds the fields before
the Address to 4 octets and keeps the pseudo-header at its
fixed 20 octets.
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 with its Checksum field read as
zero and the trailer with its HMAC field read as zero, truncated to
the high-order 128 bits:
HMAC = HMAC-SHA256(K, pseudo || vrrp || prefix || Z) [0..15]
where K is the key identified by Key ID, pseudo is the 20-octet
pseudo-header (Section 5.3), vrrp is the VRRP message from the start
of the VRRP header through the octet before the trailer, that is
through the last address (the IP header is not included), with the
16-bit VRRP Checksum field taken as zero, 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.
Cassen & Armitage Expires 28 January 2027 [Page 7]
Internet-Draft VRRP HMAC Authentication July 2026
Both the VRRP Checksum field and the HMAC field are read as zero for
HMAC computation and verification, whatever value they carry in the
packet. The substitution is logical, it does not modify the packet
that the checksum is computed or verified over. Excluding the
checksum removes a circular dependency on IPv6, where the transport
checksum covers the trailer and therefore the HMAC, and makes the
HMAC input identical across address families and independent of where
a stack computes the checksum. The IP header is excluded so that a
change to the hop limit or the header checksum in transit does not
break the HMAC.
6. Sending Advertisements
To send an advertisement, a sender proceeds in this order:
1. Build the VRRP message as usual and append the trailer.
2. Set Ext Type to its scheme, Key ID to its active key (Section 9),
Reserved to zero, and fill the sequence number as in Section 8.1.
3. Compute the HMAC of Section 5.4 and write the result into the
HMAC field.
4. Compute and insert the VRRP checksum over the completed packet,
on IPv4 over the VRRP message only and on IPv6 over the whole IP
payload, typically by the sending stack.
The VRRP checksum comes last because on IPv6 it covers the trailer
and therefore the HMAC just written. On IPv4 the checksum does not
cover the trailer, and since the HMAC input reads the checksum field
as zero either way, a stack that fills the IPv4 checksum before
signing produces the same packet. A sender MUST allocate one
Sequence Number and compute one HMAC per logical advertisement. In
unicast mode every peer copy carries those same authentication
fields, only the destination address and, on IPv6, the resulting
checksum differ between copies [I-D.abinabraham-vrrp-unicast].
7. Receiving Advertisements
A receiver processes the trailer before any advertisement field
reaches the VRRP state machine, so that a forged or stale packet
never influences the election. Given an advertisement of expected
VRRP message length L and an IP payload length P taken from the IP
header:
Cassen & Armitage Expires 28 January 2027 [Page 8]
Internet-Draft VRRP HMAC Authentication July 2026
1. If P equals L, the advertisement carries no trailer. In receive-
only and permissive modes (Section 10) the receiver accepts it
and skips the remaining steps. In enforce mode the receiver
drops it.
2. Otherwise the trailer starts at offset L. If Ext Type identifies
a scheme the receiver does not accept, or P does not equal L plus
the trailer length that scheme defines, drop the advertisement as
malformed. A payload shorter than L never reaches this step, the
length checks of [RFC9568] already discard it.
3. If Reserved is non-zero, drop the advertisement as malformed.
4. In time mode (Section 8.2), compute the difference between the
local clock and the Seconds field as in Section 8.1. If its
magnitude exceeds the freshness window, drop the advertisement as
stale. This test runs on an unauthenticated timestamp, so it
only rejects and never grants trust.
5. Look up the key identified by Key ID. If no such key exists,
drop the advertisement.
6. Recompute the HMAC of Section 5.4 over the advertisement as
received and compare it to the HMAC field in constant time. On
any mismatch, drop the advertisement. The VRRP checksum itself
is validated under the normal rules of the address family, which
on IPv6 the receiving stack typically does before delivery.
7. Resolve the per-sender replay state (Section 8) and require the
sequence to be newer than the stored high-water mark, compared as
in Section 8.1. If it is not, drop the advertisement as a
replay. Otherwise raise the high-water mark to this sequence and
accept the advertisement.
The replay high-water mark advances only after the HMAC verifies in
step 6, so forged or replayed data never moves it.
8. Anti-Replay
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
Cassen & Armitage Expires 28 January 2027 [Page 9]
Internet-Draft VRRP HMAC Authentication July 2026
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 sequence does not move backward across a backward clock
step, including a leap second, and needs no persistent storage as
long as the clock advances across a restart. One exception recovers
a corrected forward step in time mode, where the sender resets the
sequence to the clock once the stored timestamp lies more than the
freshness window (Section 8.2) ahead of it, since receivers already
reject such advertisements as stale. Monotonic mode grows strictly,
with no exception.
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.
time mode
The receiver keeps the freshness window from step 4 of Section 7
and also the per-sender high-water mark, so a valid but old
capture is rejected both by absolute time and by the sequence.
Time mode is the default and the security baseline of this
document, and requires the group to keep its clocks in sync, for
instance with NTP. The freshness window defaults to three times
the configured advertisement interval with a floor of 5 seconds,
and is configurable from 1 to 300 seconds. The receiver expires a
high-water mark whose timestamp lies outside the window. This
loses nothing, the window already rejects anything the mark would
order, and it lets a sender that reset after a clock step recover.
monotonic mode
Cassen & Armitage Expires 28 January 2027 [Page 10]
Internet-Draft VRRP HMAC Authentication July 2026
The receiver drops the freshness 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 sender that cannot guarantee that
advance 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 the high-water mark of a sender that
has been silent for a configured time, so a restarted sender is
treated as new, at the cost of a replay window as long as that
time. Monotonic mode gives no inter-session replay protection
once receiver state is lost and is unsuitable where that
protection is required, unless sender and receiver persist their
state.
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.
9. Key Management and Rotation
A key is 32 to 64 octets of secret material with an identifier from 1
to 255. The 32-octet floor gives a 256-bit key, which keeps a
128-bit security margin against Grover's quantum search algorithm
[GROVER], and 64 octets matches the HMAC-SHA256 block, so a longer
key would only be pre-hashed. Every node in a group MUST hold the
same keys under the same identifiers. Key material MUST be
cryptographically random or derived by a key derivation function
[RFC4086], a human-chosen passphrase of the minimum length does not
carry the intended entropy. A key MUST NOT be reused by other
protocols or unrelated groups.
A sender signs with one active key. A receiver verifies against
whichever key the Key ID identifies, so a group can hold several keys
at once. That overlap makes rotation safe without downtime. The
Cassen & Armitage Expires 28 January 2027 [Page 11]
Internet-Draft VRRP HMAC Authentication July 2026
operator installs the new key under a new identifier on every node,
then moves the active key to the new identifier one node at a time,
and once no node signs with the old identifier, removes that key
everywhere. Signing and verifying keys never have to change in the
same instant, matching the send and accept lifetimes of [RFC8177].
A key SHOULD be stored outside the VRRP configuration where the
platform allows it, for instance as an encrypted system credential
that the service manager unseals at start and exposes only to the
running process. Keeping the secret off disk at rest and out of the
configuration file limits its exposure.
10. Deployment and Migration
A node runs the extension in one of three modes, which differ only in
whether the node sends a trailer and whether it tolerates the absence
of one. A trailer that is present is always verified, and an
advertisement whose trailer fails verification is always dropped, in
every mode.
receive-only
The node holds the keys and verifies a present trailer, accepts an
advertisement without a trailer, and sends without a trailer.
permissive
The node signs every advertisement it sends and still accepts one
without a trailer.
enforce
The node signs every advertisement it sends and drops one without
a valid trailer. This is the default, and a deployment that
requires every advertisement to be authenticated MUST use it.
Because a receiver detects the trailer by length, a node that does
not implement the extension, or that does not hold the keys yet, can
drop the longer advertisements. A node therefore MUST NOT send a
trailer before every peer can accept one, which is the state receive-
only establishes. Migration takes three sweeps, and each sweep is
hitless with no timing constraint between nodes. First the operator
configures the keys with receive-only on every node, which changes
nothing on the wire while every node becomes able to verify. Then
the operator switches every node to permissive, and signing starts
against peers that already accept trailers. Once trailers verify in
both directions everywhere, the operator switches every node to
enforce, after which untrailered advertisements are dropped.
11. Security Considerations
Cassen & Armitage Expires 28 January 2027 [Page 12]
Internet-Draft VRRP HMAC Authentication July 2026
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
(Section 5.3) stops a captured trailer from being 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 the extension 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. Migration Exposure
The receive-only and permissive modes accept advertisements that
carry no trailer, so while any node runs one of them, an attacker who
can place a packet at that node injects an unsigned advertisement
exactly as before the extension. The protections of this document
only hold once every node in the group enforces. Migration modes
exist to sequence a rollout, not to operate in, so an operator SHOULD
bound the time a group spends outside enforce mode.
Cassen & Armitage Expires 28 January 2027 [Page 13]
Internet-Draft VRRP HMAC Authentication July 2026
11.5. 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 well-formed packet under a known key 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.6. Clock Dependence
Time mode drops advertisements when the sender and receiver clocks
differ by more than the freshness 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. An operator SHOULD secure the time
synchronization itself, since stepping a sender or receiver clock
becomes an availability attack.
11.7. State Loss and Replay
Replay state is volatile. After a receiver restart, time mode
accepts a valid capture once if it still lies inside the freshness
window, so the replay protection of this document is bounded by the
window rather than absolute. Monotonic mode accepts a valid capture
of any age once after state loss. After a sender recovers from a
forward clock step (Section 8.1), the advertisements signed during
the incident stay replayable until their timestamps leave the window.
11.8. 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.9. Relationship to Other Mechanisms
Compared with IPsec and the IP Authentication Header [RFC4302], the
extension avoids IKE and security-association state, works
identically for multicast and unicast, and rotates keys without
downtime, at the cost of being specific to VRRP and using a single
group key. For a routed pair, pairwise IPsec with IKEv2 additionally
authenticates individual peers and automates rekeying, properties
this extension trades for deployment simplicity.
Cassen & Armitage Expires 28 January 2027 [Page 14]
Internet-Draft VRRP HMAC Authentication July 2026
12. IANA Considerations
This document requests a new registry, "VRRP Authentication Extension
Types", for the 8-bit Ext Type field of Figure 2. The initial
contents are:
+=======+=======================+================+===============+
| Value | Description | Trailer Length | Reference |
+=======+=======================+================+===============+
| 0 | Reserved | | This document |
+-------+-----------------------+----------------+---------------+
| 1 | HMAC-SHA256, | 28 octets | This document |
| | truncated to 128 bits | | |
+-------+-----------------------+----------------+---------------+
| 2-255 | Unassigned | | |
+-------+-----------------------+----------------+---------------+
Table 1
New assignments are made under the Specification Required policy of
[RFC8126] and MUST define the total trailer length, which receivers
use for detection (Section 7). An Ext Type identifies one complete
construction, algorithm, truncation and trailer length.
Constructions that differ in any of these need distinct values, so
the length always follows from the type. The Key ID field of the
trailer is a local selector and is not managed by IANA.
13. References
13.1. Normative References
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
DOI 10.17487/RFC1982, August 1996,
<https://www.rfc-editor.org/rfc/rfc1982>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/rfc/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Cassen & Armitage Expires 28 January 2027 [Page 15]
Internet-Draft VRRP HMAC Authentication July 2026
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/rfc/rfc6234>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9568] Lindem, A. and A. Dogra, "Virtual Router Redundancy
Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 9568,
DOI 10.17487/RFC9568, April 2024,
<https://www.rfc-editor.org/rfc/rfc9568>.
13.2. Informative References
[GROVER] Grover, L. K., "A Fast Quantum Mechanical Algorithm for
Database Search", Proceedings of the 28th Annual ACM
Symposium on Theory of Computing (STOC '96), 1996,
<https://doi.org/10.1145/237814.237866>.
[I-D.abinabraham-vrrp-unicast]
Dogra, A., Abraham, A. M., and S. Krishnamurthy, "Unicast
Support for the Virtual Router Redundancy Protocol
(VRRP)", Work in Progress, Internet-Draft, draft-
abinabraham-vrrp-unicast-01, 28 May 2026,
<https://datatracker.ietf.org/doc/html/draft-abinabraham-
vrrp-unicast-01>.
[RFC3768] Hinden, R., Ed., "Virtual Router Redundancy Protocol
(VRRP)", RFC 3768, DOI 10.17487/RFC3768, April 2004,
<https://www.rfc-editor.org/rfc/rfc3768>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/rfc/rfc4086>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/rfc/rfc4302>.
Cassen & Armitage Expires 28 January 2027 [Page 16]
Internet-Draft VRRP HMAC Authentication July 2026
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/rfc/rfc5082>.
[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J.
Zhang, "YANG Data Model for Key Chains", RFC 8177,
DOI 10.17487/RFC8177, June 2017,
<https://www.rfc-editor.org/rfc/rfc8177>.
Appendix A. Test Vectors
Both vectors use VRRPv3, VRID 51, priority 200, a one-second
advertisement interval and a single virtual address, signed with Ext
Type 1 under Key ID 1 and this 32-octet key:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
The trailer carries Seconds 0x68000000, Subseconds 0x8000 and Counter
0. The dumps show the payload as transmitted, so the Checksum field
at octets 6 and 7 and the HMAC in the last 16 octets carry their
final values, and both are read as zero in the HMAC input.
A.1. IPv4
The sender 198.51.100.10 advertises the virtual address 192.0.2.100.
The pseudo-header of Section 5.4 is:
04 03 33 00 c6 33 64 0a 00 00 00 00 00 00 00 00
00 00 00 00
The full HMAC-SHA256 before truncation is:
1b84bc4e8e43892dc6d98448f8ee2265
f674824d1bfd1c6e62aa1b5f4312fe4a
The IP payload as transmitted, VRRP message then trailer, is:
31 33 c8 01 00 64 44 02 c0 00 02 64 01 01 00 00
68 00 00 00 80 00 00 00 1b 84 bc 4e 8e 43 89 2d
c6 d9 84 48 f8 ee 22 65
The checksum 0x4402 covers the message only [RFC9568], without a
pseudo-header, and is therefore identical in every unicast peer copy.
Cassen & Armitage Expires 28 January 2027 [Page 17]
Internet-Draft VRRP HMAC Authentication July 2026
A.2. IPv6
The sender fe80::10 addresses the peer fe80::20 and advertises the
virtual address fe80::100, link-local as [RFC9568] requires. The
pseudo-header of Section 5.4 is:
06 03 33 00 fe 80 00 00 00 00 00 00 00 00 00 00
00 00 00 10
The full HMAC-SHA256 before truncation is:
c8c56146ebfd66ee10ec4d8186461b78
016459dfdb722df2300edca011646494
The IP payload as transmitted is:
31 33 c8 01 00 64 a2 e9 fe 80 00 00 00 00 00 00
00 00 00 00 00 00 01 00 01 01 00 00 68 00 00 00
80 00 00 00 c8 c5 61 46 eb fd 66 ee 10 ec 4d 81
86 46 1b 78
The transport checksum 0xa2e9 covers the whole payload, trailer and
HMAC included, which is why it is computed last and read as zero in
the HMAC input.
Appendix B. Acknowledgements
This extension grew out of the keepalived project. Its design
matured over several iterations there, shaped by reports from
operators who run keepalived at scale and by seeing how widely VRRP
now runs as unicast in cloud and virtualized networks. The authors
thank the keepalived users and contributors whose feedback, testing,
and field experience guided the work.
The authors thank Aditya Dogra for his thorough review, which
uncovered real defects and sharpened both the mechanism and this
document.
Authors' Addresses
Alexandre Cassen
Free / keepalived.org
Email: acassen@corp.free.fr
Quentin Armitage
keepalived.org
Email: quentin@armitage.org.uk
Cassen & Armitage Expires 28 January 2027 [Page 18]