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

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 one, which proves it originated on the local link. This is the Generalized TTL Security Mechanism , 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.

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 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 travels in the clear and carries no integrity, so an observer replays or forges it at will, which is why 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.

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.

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

Advertisement Trailer Format

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.

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

Key ID

Selects the key that verifies the HMAC. Values run from 1 to 255, and 0 is invalid. Holding several keys at once is what lets a group rotate keys ().

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

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

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

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.

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

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.

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 , zeroes the HMAC field, computes the HMAC of and writes it. It signs once per transmitted packet so that every receiver observes a strictly growing sequence.

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: If P equals L, the advertisement carries no trailer. In permissive mode () the receiver accepts it and skips the remaining steps. In enforce mode it drops it. If P equals L plus 28, the last 28 octets are the trailer. Any other length is left to the normal VRRP length checks. If Ext Type names an unsupported scheme, or Reserved is non-zero, drop the advertisement as malformed. 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 (). 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. It comes before the HMAC so that a flood of replayed captures cannot force one HMAC per packet. Look up the key named by Key ID. If no such key exists, drop the advertisement. Recompute the HMAC of and compare it to the HMAC field in constant time. On any mismatch, drop the advertisement. Resolve the per-sender replay state () and require the sequence to be newer than the stored high-water mark under serial number arithmetic , so the comparison survives the field wrap (). 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 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. 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. 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 (). 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.

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

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.

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

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 .

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.

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

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

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 Reference 0 Reserved This document 1 HMAC-SHA256, truncated to 128 bits This document 2-255 Unassigned   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.

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. 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. [STANDARDS-TRACK] 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] 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] Proceedings of the 28th Annual ACM Symposium on Theory of Computing (STOC '96)

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.