Hash-Based Addresses (HBA)
Extracted elements (24)
HBAs use a hash-based (symmetric key) approach rather than pure CGA (public-key) approach to avoid the performance cost of public-key operations for every communication in multihomed environments. The HBA and CGA approaches are not mutually exclusive — addresses can be both valid HBA and CGA simultaneously.
HBAs use routable IPv6 addresses as identifiers (rather than separate identifier namespaces) based on application support considerations, which required stuffing security information into the interface identifier part of the IPv6 address.
Security information is embedded directly in the IPv6 interface identifier rather than relying on trusted third parties (e.g., PKI or repositories), driven by deployment cost considerations and the desire to avoid external infrastructure dependencies.
HBA addresses are indistinguishable from other IPv6 addresses in their format. DNS publishers and Shim6 initiators cannot determine which addresses belong to an HBA set by inspection alone; alternative mechanisms are required if an initiator must use only HBA addresses when non-HBA addresses are also present in DNS.
HBAs are designed to be fully compatible with CGAs as defined in RFC 3972. It is possible to generate addresses that are simultaneously valid CGAs and HBAs by including the Multi-Prefix extension in the CGA Parameter Data Structure, enabling use with Secure Neighbor Discovery (SeND) and other CGA-based protocols.
When verifying that an HBA from a different prefix belongs to the same HBA set, direct CGA verification from RFC 3972 will fail because the Subnet Prefix field will not match. The HBA verification procedure explicitly substitutes the HBA prefix before running CGA verification to handle this cross-prefix case.
For HBA-only addresses, the random nonce MUST be encoded as a public key as defined in RFC 3972, specifically as a DER-encoded ASN.1 SubjectPublicKeyInfo structure with algorithm identifier rsaEncryption (1.2.840.113549.1.1.1) and formatted using the RSAPublicKey type. The random nonce length is 384 bits.
The HBA-set generation and verification procedures defined in this specification are only valid for Sec values of 0, 1, and 2. For other Sec values, the specifications referenced by the CGA SEC registry defined in RFC 4982 MUST be used.
The Reserved field in the Multi-Prefix extension MUST be initialized to zero and ignored upon receipt.
HBAs can be used as RFC 4941 temporary addresses by periodically generating new HBA sets. When Sec=0, the cost is low (one generation iteration); when Sec>0, the cost grows as O(2^(16*Sec)) iterations per new HBA set, which may make frequent address changes expensive.
Dynamic address set support (adding addresses with prefixes not in the original HBA set) requires CGA capabilities: the new address is announced via a Shim6 UPDATE message signed with the private key corresponding to the public key in the CGA Parameter Data Structure. HBA-only verification cannot validate addresses with prefixes not included at HBA generation time.
Hash-Based Addresses (HBAs) are IPv6 addresses where the interface identifier is generated as a hash of the available prefixes and a random Modifier, then multiple addresses are formed by prepending each prefix to the generated interface identifier. This creates a set of addresses inherently bound to each other without requiring public-key cryptography.
HBA-set generation step 3 computes Hash2 by SHA-1 over (Modifier || 9 zero octets || public_key_or_extended_modifier || Multi-Prefix extension), taking the 112 leftmost bits. Steps 3-4 are iterated until the 16*Sec leftmost bits of Hash2 are all zero, providing the Sec-based brute-force resistance.
HBA-set generation step 6 computes Hash1[i] by SHA-1 over (Modifier || Prefix[i] || collision_count || public_key_or_extended_modifier || Multi-Prefix extension), takes the 64 leftmost bits, writes Sec into the three leftmost bits, sets u and g bits to zero, and forms HBA[i] by concatenating Prefix[i] with this 64-bit interface identifier.
HBA verification checks that the HBA prefix is included in the Multi-Prefix extension's prefix set, substitutes the HBA prefix into the Subnet Prefix field of the CGA Parameter Data Structure, then runs the standard CGA verification process from RFC 3972 Section 5 on the modified structure.
The HBA-set generation process takes as inputs a vector of n 64-bit prefixes, a Sec parameter, and optionally a public key. It outputs an HBA-set and their respective CGA Parameter Data Structures, reusing the CGA generation process from RFC 3972 with the Multi-Prefix extension included.
Three address types are defined: CGA-only addresses (bound to a public key and single prefix, no Multi-Prefix extension), CGA/HBA addresses (bound to both a public key and a prefix set, support both SeND and HBA), and HBA-only addresses (bound to a prefix set, use a random nonce instead of a public key, cannot be used for SeND).
This document defines a new CGA Extension, the Multi-Prefix extension, which has been assigned CGA Extension Type value 0x0012 in the CGA Extension Type registry.
An attacker can launch a DoS attack by sending large amounts of HBA state (CGA Parameter Data Structures) to a victim, exhausting the victim's memory. Protocols using HBA SHOULD implement DoS prevention techniques; the Shim6 protocol addresses this via a 4-way stateless handshake.
HBAs depend on SHA-1. RFC 4982 analyzed the impact of hash function attacks on CGAs and their extensions, concluding that known attacks do not affect the security of CGA/HBA-based protocols. RFC 4982 also updated the CGA specification to support alternative hash algorithms via the CGA SEC registry.
HBAs do not prevent man-in-the-middle (MITM) attacks. An on-path attacker can modify the CGA Parameter Data Structure and change the prefix set, but must also change the interface identifiers of all addresses accordingly; otherwise, verification will fail.
HBAs provide limited protection against flooding attacks: flooding a specific host address requires O(2^(59+16*Sec)) attempts, making it infeasible. However, flooding attacks targeting a network prefix (router, access link) rather than a specific host address cannot be prevented by HBAs alone and require additional mechanisms such as reachability tests.
HBAs provide security against time-shifting (premeditated) redirection attacks. An off-path attacker who wants to redirect communications to an address outside the HBA set must find a Modifier producing an HBA set containing both the original address and the attacker's address, costing O(2^(59+16*Sec)) hash operations.
The Multi-Prefix Extension uses a TLV format with a 16-bit Extension Type (value 0x0012), 16-bit Extension Data Length, a 1-bit P flag (set if a public key is present), 31-bit Reserved field (must be zero), and a vector of 64-bit prefixes Prefix[1..n]. The Ext Len field value is (n*8 + 4).