An HMAC Authentication Extension for the Virtual Router Redundancy Protocol (VRRP)
draft-cassen-vrrp-auth-hmac-00

Routing Area Working Group                                     A. Cassen
Internet-Draft                                                      Free
Intended status: Standards Track                             Q. Armitage
Expires: 28 December 2026                                 keepalived.org
                                                            26 June 2026

   An HMAC Authentication Extension for the Virtual Router Redundancy
                            Protocol (VRRP)
                     draft-cassen-vrrp-auth-hmac-00

Abstract

   VRRP relies on a hop limit of 255 to prove that an advertisement came
   from the local link.  That guard disappears when advertisements
   travel as unicast across a routed or overlay network, as is common in
   cloud deployments, which leaves 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.  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 for
   both unicast and multicast, independent of the VRRP version and IP
   address family.

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 December 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Cassen & Armitage       Expires 28 December 2026                [Page 1]
Internet-Draft          VRRP HMAC Authentication               June 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  . . . . . . . . . . . . . . . .   4
     5.1.  Placement and Detection . . . . . . . . . . . . . . . . .   5
     5.2.  Trailer Fields  . . . . . . . . . . . . . . . . . . . . .   5
     5.3.  Pseudo-Header . . . . . . . . . . . . . . . . . . . . . .   6
     5.4.  HMAC Computation  . . . . . . . . . . . . . . . . . . . .   7
   6.  Sending Advertisements  . . . . . . . . . . . . . . . . . . .   7
   7.  Receiving Advertisements  . . . . . . . . . . . . . . . . . .   7
   8.  Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Sequence Number . . . . . . . . . . . . . . . . . . . . .   8
     8.2.  Freshness Modes . . . . . . . . . . . . . . . . . . . . .   9
     8.3.  Per-Sender State  . . . . . . . . . . . . . . . . . . . .   9
   9.  Key Management and Rotation . . . . . . . . . . . . . . . . .  10
   10. Deployment and Migration  . . . . . . . . . . . . . . . . . .  10
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  10
     11.1.  Threat Model . . . . . . . . . . . . . . . . . . . . . .  10
     11.2.  What the Extension Provides  . . . . . . . . . . . . . .  11
     11.3.  Group Key  . . . . . . . . . . . . . . . . . . . . . . .  11
     11.4.  Denial of Service  . . . . . . . . . . . . . . . . . . .  11
     11.5.  Clock Dependence . . . . . . . . . . . . . . . . . . . .  11
     11.6.  Cryptographic Strength . . . . . . . . . . . . . . . . .  12
     11.7.  Relationship to Other Mechanisms . . . . . . . . . . . .  12
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     13.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

Cassen & Armitage       Expires 28 December 2026                [Page 2]
Internet-Draft          VRRP HMAC Authentication               June 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 one, which proves it
   originated on the local link.  This is the Generalized TTL Security
   Mechanism [RFC5082], and VRRPv3 leans on it entirely, since it
   carries no authentication of its own.

   Most VRRP deployments today no longer match that model.  Keepalived
   and similar implementations run VRRP in cloud and virtualized
   networks where multicast is unavailable, so advertisements travel as
   unicast to a configured list of peers.  Those packets are routed,
   they cross hops, and they 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 unicast VRRP

   The TTL=255 (GTSM) guard cannot fire on a routed advert, so the
   receiver relaxes the check and accepts the forgery.  With a priority
   above the active router, the spoofed advert forces the real active
   router to back off and give up the VIP.  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 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]

Cassen & Armitage       Expires 28 December 2026                [Page 3]
Internet-Draft          VRRP HMAC Authentication               June 2026

   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.

   This document defines an authentication extension that closes the
   gap.  It appends a fixed trailer to each advertisement 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 unicast it is the primary defense.  For multicast 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).  It supersedes the
   legacy VRRPv2 authentication types and MUST NOT be combined with
   them.  The extension 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.

5.  Advertisement Trailer Format

Cassen & Armitage       Expires 28 December 2026                [Page 4]
Internet-Draft          VRRP HMAC Authentication               June 2026

5.1.  Placement and Detection

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

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

5.2.  Trailer Fields

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

                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 a trailer whose Ext
             Type it does not support.

   Key ID    Selects the key that verifies the HMAC.  Values run from 1

Cassen & Armitage       Expires 28 December 2026                [Page 5]
Internet-Draft          VRRP HMAC Authentication               June 2026

             to 255, and 0 is invalid.  Holding several keys at once is
             what lets a group rotate keys (Section 9).

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

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

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

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

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

5.3.  Pseudo-Header

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

   Family   4 for IPv4, 6 for IPv6.

   Version  The VRRP version of the advertisement.

   VRID     The virtual router identifier.

   Zero     Set to zero.

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

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

Cassen & Armitage       Expires 28 December 2026                [Page 6]
Internet-Draft          VRRP HMAC Authentication               June 2026

5.4.  HMAC Computation

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

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

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

6.  Sending Advertisements

   To send an advertisement, a sender builds the VRRP message as usual,
   appends the trailer, sets Ext Type to its scheme and Key ID to its
   active key, fills the sequence number as in Section 8, zeroes the
   HMAC field, computes the HMAC of Section 5.4 and writes it.  It 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 length L and a received IP payload of length P:

   1.  If P equals L, the advertisement carries no trailer.  In
       permissive mode (Section 10) the receiver accepts it and skips
       the remaining steps.  In enforce mode it drops it.

   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, compute the difference between the local clock and
       the Seconds field as a signed 32-bit difference modulo 2^32,
       which stays correct across the field wrap (Section 8.1).  If its
       magnitude exceeds the freshness window, drop the advertisement as
       stale.  This test runs on an unauthenticated timestamp, so it

Cassen & Armitage       Expires 28 December 2026                [Page 7]
Internet-Draft          VRRP HMAC Authentication               June 2026

       only rejects and never grants trust.  It comes before the HMAC so
       that a flood of replayed captures cannot force one HMAC per
       packet.

   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 and compare it to the HMAC
       field in constant time.  On any mismatch, drop the advertisement.

   7.  Resolve the per-sender replay state (Section 8) and require the
       sequence to be newer than the stored high-water mark under serial
       number arithmetic [RFC1982], so the comparison survives the field
       wrap (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.

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

Cassen & Armitage       Expires 28 December 2026                [Page 8]
Internet-Draft          VRRP HMAC Authentication               June 2026

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

8.2.  Freshness Modes

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

8.3.  Per-Sender State

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

Cassen & Armitage       Expires 28 December 2026                [Page 9]
Internet-Draft          VRRP HMAC Authentication               June 2026

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.  This is what makes rotation safe without downtime: install the
   new key under a new id on every node, then move the active key to the
   new id one node at a time, and once no node signs with the old id,
   remove it 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

   Because a receiver detects the trailer by length, a node that does
   not implement the extension may drop the longer advertisements, so
   every node in a group SHOULD implement the extension before any node
   enforces it.  Migration uses the permissive mode for this.  In
   permissive mode a receiver accepts both an advertisement that carries
   a valid trailer and one that carries none, which lets an operator
   roll the extension out node by node.  Once every node sends a trailer
   and trailers verify in both directions, the operator switches every
   node to enforce mode, after which untrailered advertisements are
   dropped. enforce is the default, and a deployment that runs VRRP in
   strict mode MUST use it.

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

Cassen & Armitage       Expires 28 December 2026               [Page 10]
Internet-Draft          VRRP HMAC Authentication               June 2026

   seize the virtual address by advertising a high priority, to force a
   failover with priority 0, or to flap the group.

11.2.  What the Extension Provides

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

11.3.  Group Key

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

11.4.  Denial of Service

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

11.5.  Clock Dependence

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

Cassen & Armitage       Expires 28 December 2026               [Page 11]
Internet-Draft          VRRP HMAC Authentication               June 2026

11.6.  Cryptographic Strength

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

11.7.  Relationship to Other Mechanisms

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

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.
   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>.

Cassen & Armitage       Expires 28 December 2026               [Page 12]
Internet-Draft          VRRP HMAC Authentication               June 2026

   [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>.

   [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>.

   [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>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc2338>.

   [RFC3768]  Hinden, R., Ed., "Virtual Router Redundancy Protocol
              (VRRP)", RFC 3768, DOI 10.17487/RFC3768, April 2004,
              <https://www.rfc-editor.org/rfc/rfc3768>.

   [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 December 2026               [Page 13]
Internet-Draft          VRRP HMAC Authentication               June 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>.

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.

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 December 2026               [Page 14]