]> Free / keepalived.org

acassen@corp.free.fr

keepalived.org

quentin@armitage.org.uk

Routing Routing Area Working Group VRRP authentication HMAC replay unicast 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.

Introduction The Virtual Router Redundancy Protocol 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) , 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 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.

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

The same attack and defense apply over IPv6, where a deployment would use addresses such as 2001:db8::10 in place of those above. The authentication types of earlier VRRP versions were removed as ineffective and never carried into VRRPv3. In practice, unicast VRRP runs unauthenticated. 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.

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 when, and only when, they appear in all capitals, as shown here.

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

Applicability The extension applies to VRRPv3 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 (). 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.

multicast

The hop-limit check of 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 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 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 () or an equivalent authenticated channel, since GTSM cannot apply there.

Advertisement Trailer Format

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 , 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 (). 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 (), 28 octets for the scheme of this document. The IP 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 accept an exact scheme length, in the migration modes the bare message length, and drop everything else.

Trailer Fields

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

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, in network byte order ().

HMAC

The truncated HMAC computed over the inputs in .

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.

HMAC Computation The HMAC is HMAC-SHA256 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:

where K is the key identified by Key ID, pseudo is the 20-octet pseudo-header (), 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. 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.

Sending Advertisements To send an advertisement, a sender proceeds in this order: Build the VRRP message as usual and append the trailer. Set Ext Type to its scheme, Key ID to its active key (), Reserved to zero, and fill the sequence number as in . Compute the HMAC of and write the result into the HMAC field. 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 .

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: If P equals L, the advertisement carries no trailer. In receive-only and permissive modes () the receiver accepts it and skips the remaining steps. In enforce mode the receiver drops it. 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 already discard it. If Reserved is non-zero, drop the advertisement as malformed. In time mode (), compute the difference between the local clock and the Seconds field as in . 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. Look up the key identified by Key ID. If no such key exists, drop the advertisement. Recompute the HMAC of 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. Resolve the per-sender replay state () and require the sequence to be newer than the stored high-water mark, compared as in . 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.

Anti-Replay

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

Freshness Modes The receiver enforces freshness in one of two modes.

time mode

The receiver keeps the freshness window from step 4 of 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

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

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.

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

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.

Security Considerations

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.

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

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 .

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.

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.

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

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 (), the advertisements signed during the incident stay replayable until their timestamps leave the window.

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 . The receiver compares the HMAC in constant time so that the comparison leaks no timing information about the expected HMAC.

Relationship to Other Mechanisms Compared with IPsec and the IP Authentication Header , 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.

IANA Considerations This document requests a new registry, "VRRP Authentication Extension Types", for the 8-bit Ext Type field of . The initial contents are: Value Description Trailer Length Reference 0 Reserved   This document 1 HMAC-SHA256, truncated to 128 bits 28 octets This document 2-255 Unassigned     New assignments are made under the Specification Required policy of and MUST define the total trailer length, which receivers use for detection (). 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.

The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood. This memo supplies the missing definition. It is intended to update RFC1034 and RFC1035. [STANDARDS-TRACK] This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind Federal Information Processing Standard, FIPS This document defines version 3 of the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It obsoletes RFC 5798, which previously specified VRRP (version 3). RFC 5798 obsoleted RFC 3768, which specified VRRP (version 2) for IPv4. VRRP specifies an election protocol that dynamically assigns responsibility for a Virtual Router to one of the VRRP Routers on a LAN. The VRRP Router controlling the IPv4 or IPv6 address(es) associated with a Virtual Router is called the Active Router, and it forwards packets routed to these IPv4 or IPv6 addresses. Active Routers are configured with virtual IPv4 or IPv6 addresses, and Backup Routers infer the address family of the virtual addresses being advertised based on the IP protocol version. Within a VRRP Router, the Virtual Routers in each of the IPv4 and IPv6 address families are independent of one another and always treated as separate Virtual Router instances. The election process provides dynamic failover in the forwarding responsibility should the Active Router become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup Routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. [STANDARDS-TRACK] Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC 3682. [STANDARDS-TRACK] This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). [STANDARDS-TRACK] This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list containing one or more elements containing a Key ID, key string, send/accept lifetimes, and the associated authentication or encryption algorithm. By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. Cisco Systems Cisco Systems Independent The Virtual Router Redundancy Protocol (VRRP) Version 3 as specified in RFC 9568 assumes multicast operation on a shared LAN. Some deployments require the VRRP first-hop redundancy function but cannot use multicast delivery for VRRP advertisements. This document updates RFC 9568 by defining an optional configured unicast mode for VRRP Version 3 in which advertisements are sent to configured peer addresses rather than to the VRRP multicast group. The VRRP packet format, state machine, protocol number, virtual IP semantics, and Virtual Router MAC behavior remain unchanged from RFC 9568. Proceedings of the 28th Annual ACM Symposium on Theory of Computing (STOC '96)

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:

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.

IPv4 The sender 198.51.100.10 advertises the virtual address 192.0.2.100. The pseudo-header of is:

The full HMAC-SHA256 before truncation is:

The IP payload as transmitted, VRRP message then trailer, is:

The checksum 0x4402 covers the message only , without a pseudo-header, and is therefore identical in every unicast peer copy.

IPv6 The sender fe80::10 addresses the peer fe80::20 and advertises the virtual address fe80::100, link-local as requires. The pseudo-header of is:

The full HMAC-SHA256 before truncation is:

The IP payload as transmitted is:

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.

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.