Routing Area Working Group A. Cassen Internet-Draft Free Intended status: Standards Track Q. Armitage Expires: 16 January 2027 keepalived.org 15 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 16 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Cassen & Armitage Expires 16 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 16 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 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 16 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 16 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 16 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 16 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 16 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 16 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 16 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 16 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 16 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 16 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 16 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 16 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, . [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Cassen & Armitage Expires 16 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, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . 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, . [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, . [RFC3768] Hinden, R., Ed., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, DOI 10.17487/RFC3768, April 2004, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . Cassen & Armitage Expires 16 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, . [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, . 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 16 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 16 January 2027 [Page 18]