Routing Area Working Group A. Cassen Internet-Draft Free Intended status: Standards Track Q. Armitage Expires: 8 January 2027 keepalived.org 7 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 VRRP advertisements, giving origin authentication, integrity and replay protection independent of the VRRP version and IP address family. 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 8 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Cassen & Armitage Expires 8 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 . . . . . . . . . . . . . . . . . . . . . 5 5.3. Pseudo-Header . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 12 11.2. What the Extension Provides . . . . . . . . . . . . . . 12 11.3. Group Key . . . . . . . . . . . . . . . . . . . . . . . 13 11.4. Migration Exposure . . . . . . . . . . . . . . . . . . . 13 11.5. Denial of Service . . . . . . . . . . . . . . . . . . . 13 11.6. Clock Dependence . . . . . . . . . . . . . . . . . . . . 13 11.7. Cryptographic Strength . . . . . . . . . . . . . . . . . 13 11.8. Relationship to Other Mechanisms . . . . . . . . . . . . 14 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 13.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Cassen & Armitage Expires 8 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, cross hops, and arrive with a hop limit well below 255. The receiver has to relax the hop-limit check to accept them, and 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, raise its priority to demote the legitimate active router, or set priority 0 to force an immediate failover. Captured advertisements replay just as easily. Routed / overlay: 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 legacy VRRPv2 authentication types do not help. The cleartext password of [RFC2338] travels in the clear and carries no integrity, so an observer replays or forges it at will, which is why [RFC3768] removed it. The IP Authentication Header option was VRRPv2 only and was removed as well, and it never existed for VRRPv3. In practice, unicast VRRP runs unauthenticated. Cassen & Armitage Expires 8 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 fixed trailer carrying an HMAC-SHA256 and a time-based sequence number. The HMAC gives origin authentication and integrity, the sequence number gives replay protection, 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, which can forge a hop limit of 255 as easily as any other field. 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. 4. Applicability The extension applies to any VRRP advertisement, independent of version and address family. 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 may reject it (Section 10). The extension supersedes the legacy VRRPv2 authentication types and MUST NOT be combined with them. 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. In multicast operation [RFC9568] the hop-limit check is mandatory and GTSM holds, so the extension adds origin authentication, integrity and replay protection on top of it. In single-hop unicast operation [I-D.abinabraham-vrrp-unicast] the group stays on a shared link, the hop-limit check is equally mandatory, and the extension plays the same defense-in-depth role. In multi-hop unicast operation the advertisement crosses routers, the hop-limit check cannot succeed and is relaxed, and the extension is the primary proof of origin. In Cassen & Armitage Expires 8 January 2027 [Page 4] Internet-Draft VRRP HMAC Authentication July 2026 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 that security model. A multi-hop deployment or a future multi-hop specification SHOULD require it in enforce mode (Section 10), because such a deployment has no other proof of origin. 5. Advertisement Trailer Format 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. A VRRPv2 message still ends with 8 octets of Authentication Data even when its Auth Type is 0 [RFC3768], while a VRRPv3 message ends at the last address. 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 keeps the coverage the advertisement's VRRP version defines, the VRRP message without the trailer, 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 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. The expected length follows from the version and address count in the VRRP header and includes any version-2 authentication area. Normal advertisements never carry trailing padding of that size, so the test is unambiguous. 5.2. Trailer Fields Cassen & Armitage Expires 8 January 2027 [Page 5] Internet-Draft VRRP HMAC Authentication July 2026 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 (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. 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. 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. Cassen & Armitage Expires 8 January 2027 [Page 6] Internet-Draft VRRP HMAC Authentication July 2026 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 named 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 and any version-2 authentication area (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 8 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 per the rules of its VRRP version 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. The sender signs once per transmitted packet so that every receiver observes a strictly growing sequence. 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 a received IP payload of length P: 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. Cassen & Armitage Expires 8 January 2027 [Page 8] Internet-Draft VRRP HMAC Authentication July 2026 2. If P equals L plus 28, the last 28 octets are the trailer. Any other length is left to the normal VRRP length checks. 3. If Ext Type names an unsupported scheme, or 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 named 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 version and 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 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. Cassen & Armitage Expires 8 January 2027 [Page 9] Internet-Draft VRRP HMAC Authentication July 2026 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 the sequence stays monotonic across a backward step of the clock, including a leap second, and 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. 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 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. monotonic mode 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. Cassen & Armitage Expires 8 January 2027 [Page 10] Internet-Draft VRRP HMAC Authentication July 2026 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. A sender signs with one active key. A receiver verifies against whichever key the Key ID names, so a group can hold several keys at once. That overlap makes rotation safe without downtime. The 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. 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 Cassen & Armitage Expires 8 January 2027 [Page 11] Internet-Draft VRRP HMAC Authentication July 2026 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 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 Cassen & Armitage Expires 8 January 2027 [Page 12] Internet-Draft VRRP HMAC Authentication July 2026 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. 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. 11.7. 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. Cassen & Armitage Expires 8 January 2027 [Page 13] Internet-Draft VRRP HMAC Authentication July 2026 11.8. Relationship to Other Mechanisms Compared with IPsec and the IP Authentication Header [RFC4302], the extension avoids IKE and 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. 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 | Reference | +=======+====================================+===============+ | 0 | Reserved | This document | +-------+------------------------------------+---------------+ | 1 | HMAC-SHA256, truncated to 128 bits | This document | +-------+------------------------------------+---------------+ | 2-255 | Unassigned | | +-------+------------------------------------+---------------+ Table 1 New assignments are made under the Specification Required policy of [RFC8126]. 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 8 January 2027 [Page 14] 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, . [RFC2338] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, D., Hunt, P., Higginson, P., Shand, M., and A. Lindem, "Virtual Router Redundancy Protocol", RFC 2338, DOI 10.17487/RFC2338, April 1998, . [RFC3768] Hinden, R., Ed., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, DOI 10.17487/RFC3768, April 2004, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . Cassen & Armitage Expires 8 January 2027 [Page 15] 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, . Appendix A. 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 review of the initial revision, which uncovered an IPv6 checksum circular dependency and motivated the receive-only mode. Authors' Addresses Alexandre Cassen Free / keepalived.org Email: acassen@corp.free.fr Quentin Armitage keepalived.org Email: quentin@armitage.org.uk Cassen & Armitage Expires 8 January 2027 [Page 16]