RFC 5535
Hash-Based Addresses (HBA)
Hash-Based Addresses (HBA) 💖
okay bestie, this is RFC 5535 🎀 It's titled Hash-Based Addresses (HBA), it's a Standards Track doc, and it came out in June 2009 ✨. The author is M. Bagnulo from UC3M. Its title block doesn't list any Obsoletes or Updates entries, so it doesn't replace or patch any other RFC 💅
Status of This Memo 🌸
this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 for where the protocol actually stands, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋
Copyright Notice 📜
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents as they stood on the date it was published. You can read those at http://trustee.ietf.org/license-info, and they explain your rights and restrictions, so go read them carefully 🙈
some of the material in here may come from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008 ✨ the people who own the copyright in that older material might not have given the IETF Trust permission to allow changes outside the IETF Standards Process. So without a proper license from those copyright holders, this doc can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The one exceptions are formatting it for publication as an RFC and translating it into languages other than English 🌈
Abstract 🔮
this memo describes a mechanism for a secure binding between the multiple addresses, each with a different prefix, that a host has inside a multihomed site 💜 it uses either Cryptographically Generated Addresses (CGAs) or a new variant that's built on the same theme and uses the same address format. The big idea in the new variant is that info about the multiple prefixes gets baked right into the addresses themselves 🧚
Here's how that works: the interface identifiers of a host's addresses get generated as hashes of the available prefixes plus a random number. Then the multiple addresses are made by sticking each of the different prefixes onto those generated interface identifiers. The end result is a set of addresses, called Hash-Based Addresses (HBAs), that are inherently bound to each other 🔥
Table of Contents 📑
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview ........................................................4
3.1. Threat Model ...............................................4
3.2. Overview ...................................................4
3.3. Motivations for the HBA Design .............................5
4. Cryptographic Generated Addresses (CGAs) Compatibility
Considerations ..................................................6
5. Multi-Prefix Extension for CGA ..................................8
6. HBA-Set Generation ..............................................9
7. HBA Verification ...............................................11
7.1. Verification That a Particular HBA Address
Corresponds to a Given CGA Parameter Data Structure .......11
7.2. Verification That a Particular HBA Address Belongs to the
HBA Set Associated with a Given CGA Parameter Data
Structure .................................................11
8. Example of HBA Application in a Multihoming Scenario ...........13
8.1. Dynamic Address Set Support ...............................16
9. DNS Considerations .............................................17
10. IANA Considerations ...........................................18
11. Security Considerations .......................................18
11.1. Security Considerations When Using HBAs in the
Shim6 Protocol ...........................................20
11.2. Privacy Considerations ...................................22
11.3. SHA-1 Dependency Considerations ..........................22
11.4. DoS Attack Considerations ................................22
12. Contributors ..................................................23
13. Acknowledgments ...............................................23
14. References ....................................................24
14.1. Normative References .....................................24
14.2. Informative References ...................................241. Introduction 🎀
okay so, to keep the inter-domain routing system scalable, IPv6 sites get their addresses from their Internet Service Providers (ISPs) 💅 This keeps the number of routes in the global routing tables way down, because each ISP only announces routes for its own address blocks instead of one route per customer site. The catch is that a multihomed site ends up with multiple prefixes, one from each ISP 😭 And since each ISP only announces its own block, a multihomed site can only be reached through a given ISP when that ISP's prefix is in the destination address of the packets.
So if an established communication has to be routed through different ISPs over its lifetime, it needs addresses with different prefixes. Changing the address that carries an established communication's packets opens it up to lots of attacks, as described in [11], which means security mechanisms are needed to protect everyone involved 🛡️ This memo describes a tool that protects against some of those attacks, especially future or premeditated ones (aka time shifting attacks in [12]) 🍓
this memo describes a mechanism for a secure binding between the multiple addresses, each with a different prefix, that a host has inside a multihomed site ✨
it's worth noting that mobility is different. A mobile node doesn't know its addresses ahead of time, but the multiple addresses a host has in a multihomed site are predefined and mostly known in advance 🦋 The mechanism here uses either Cryptographically Generated Addresses (CGAs) [2] or a new variant that uses the same address format. The new variant, Hash-Based Address (HBA), takes advantage of how stable that address set is. Either way, you can get a secure binding between a node's addresses in a multihomed site 🫶 CGAs use public key cryptography and can handle changing address sets. HBAs use only symmetric key cryptography and need less computing power 💜
for Shim6 purposes, CGAs and HBAs are pretty similar. Both can be generated by the host itself with no outside infrastructure needed 🧚 Both use the same address format and the same format for the data that gets fed in to generate the addresses. It's not required for all the interface identifiers of a node's addresses to be equal, which keeps some privacy as the addresses change during communications 🌈
the big idea in HBAs is that info about the multiple prefixes is included in the addresses themselves 🔥 This works by generating the interface identifiers of a host's addresses as hashes of the available prefixes and a random number. Then the multiple addresses come from prepending the different prefixes to those generated interface identifiers. The result is a set of addresses that are inherently bound together. There's also a cheap way to check whether two addresses belong to the same set: given the prefix set and the extra parameters used to generate the HBA, a single hash operation is enough to verify whether an HBA belongs to a given HBA set 👑
2. Terminology 📖
the big capital-letter key words are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". In this document, they're to be read as described in RFC 2119 [1] 💅
3. Overview ☁️
3.1. Threat Model 🕵️♀️
the threat analysis for the multihoming problem is in [11] 📚 It basically looks at attacks that rely on a malicious attacker redirecting packets to addresses that don't belong to the multihomed node. There are two main kinds of redirection attacks: communication hijacking and flooding attacks. Communication hijacking is when an attacker steals ongoing and/or future communications from a victim 😱 Flooding attacks redirect a legitimate source's traffic to a third party, flooding them 💀
the HBA solution gives full protection against communication hijacking attacks 🫶 The Shim6 protocol [9] protects against flooding attacks 🌸 Residual threats are covered in the "Security Considerations" section ⚠️
3.2. Overview 🎀
the basic goal of the HBA mechanism is to securely bind together multiple IPv6 addresses that belong to the same multihomed host ✨ That way traffic can be rerouted without worrying that the communication is being redirected to an attacker. The trick is to put a hash of the permitted prefixes into the low-order bits of the IPv6 address 🧚
let's say, skipping some details, the available prefixes are A, B, C, and D. The host would build a prefix list P made of (A,B,C,D), plus a random number called Modifier M. Then it generates the new addresses:
A || H(M || A || P)
B || H(M || B || P)
C || H(M || C || P)
D || H(M || D || P)so, given one valid address from the group plus the prefix list P and the random Modifier M, you can figure out whether another address is part of the group. You just compute the hash and check it against the low-order bits 🔥💖
3.3. Motivations for the HBA Design 🎀
okay so the HBA crew had some big reasons for designing it this way, bestie 💅
First of all, the goal of HBA is to provide a secure binding between the IPv6 address that upper-layer protocols use as an identifier and the alternative locators available in the multihomed node, so that redirection attacks are prevented 🔒✨
Second, to get that protection, they chose to put the security info inside the identifier itself instead of leaning on third trusted parties to secure the binding, like repositories or Public Key Infrastructure. Why? Deployment costs, lowkey. Running that trusted third-party infrastructure is expensive 💸
Third, application support considerations described in [16] led to picking routable IPv6 addresses as identifiers. So the security info gets stuffed into the interface identifier part of the IPv6 address. Main character energy, literally 🦋
Fourth, performance considerations described in [17] pushed them toward a hash-based approach instead of a public-key-based approach built on pure Cryptographic Generated Addresses (CGA). The goal was to avoid making every communication in multihomed environments pay for public key operations 🔥 The HBA approach here is a cheaper option that's attractive for lots of common use cases. And ngl, HBA and CGA are not mutually exclusive. You can make addresses that are both valid CGA and HBA addresses, getting the benefits of both if you need them 🌈
4. Cryptographic Generated Addresses (CGAs) Compatibility Considerations 💜
As we covered in the last section, HBA uses the interface identifier part of the IPv6 address to encode info about the multiple prefixes a multihomed host has. BUT the interface identifier is also used to carry cryptographic info when Cryptographic Generated Addresses (CGAs) [2] are in play 😭 So if the HBA design doesn't account for this, the bits could end up with conflicting uses. There are at least two valid reasons to make HBA and CGA compatible:
First, the current Secure Neighbor Discovery (SeND) specification [3] uses the CGAs defined in [2] to prove address ownership. If HBAs aren't compatible with CGAs, nodes using HBAs for multihoming wouldn't be able to do Secure Neighbor Discovery with the same addresses (at least the parts of SeND that need CGAs). That would mean nodes have to choose between security (from SeND) and fault tolerance (from IPv6 multihoming support provided by the Shim6 protocol [9]). Honestly that's a terrible choice 🙈 Also, SeND isn't the only protocol that's expected to benefit from CGA's advantages. Mobility support protocols [13] are another example, and they couldn't be used with HBAs if the two aren't compatible.
Second, CGAs bring extra features that HBAs alone can't achieve. Because of how HBA works, it only supports a predetermined prefix set, one that's known when the HBA set is generated. You can't add new prefixes to that set after the fact. For most site multihoming cases, that's totally fine, since the prefix set isn't very dynamic. New prefixes might show up when a new ISP joins, but those events rarely happen on the same timescale as established communications. So it's enough that new prefixes aren't available to established communications, and only new communications get to use them ✨ If you do need that extra functionality, CGAs can provide it. This approach requires HBA and CGA to be compatible. If they are, you can create HBA/CGA addresses that support both CGA and HBA functionality at the same time. The inputs to the HBA/CGA generation process are both a prefix set and a public key. That way, a node with an established communication using one address from the CGA/HBA set can tell its peer to use HBA verification when one of the addresses from its HBA/CGA set is used as the locator in the communication. Or it can tell the peer to use CGA (public-/private-key-based) verification when a new address that doesn't belong to the HBA/CGA set is used as the locator 🧚
So, for all those reasons, one goal of the HBA design is to define HBAs so they're compatible with CGAs as defined in [2] and their usages described in [3]. (To understand the rest of this note, you should already be familiar with the CGA specification in [2], no cap.) This means it must be possible to generate addresses that are both an HBA and a CGA. In other words, the interface identifier holds the cryptographic info of a CGA and the prefix-set info of an HBA 💖 The CGA specification already allows extra info in the CGA generation process through Extension Fields in the CGA Parameter Data Structure. So it's possible to define a Multi-Prefix extension for CGA, which lets the prefix set info get included in the interface identifier generation process. Genius, iykyk 👑
Even though they adopted a CGA-compatible approach, HBAs and CGAs are still different concepts. A CGA is inherently bound to a public key, while an HBA is inherently bound to a prefix set. So a public key is not required to generate an HBA-only address. Because of that, three different types of addresses get defined:
- CGA-only addresses: These are addresses generated as specified in [2] without including the Multi-Prefix extension. They're bound to a public key and to a single prefix (contained in the basic CGA Parameter Data Structure). These addresses can be used for SeND [3]. If they're used for multihoming, their application has to be based on the public key usage 🌸
- CGA/HBA addresses: These addresses are CGAs that include the Multi-Prefix extension in the CGA Parameter Data Structure used for their generation. They're bound to a public key and a prefix set, and they provide both CGA and HBA functionalities. They can be used for SeND as defined in [3] and for any usage defined for HBA (such as a Shim6 protocol) 🔥
- HBA-only addresses: These addresses are bound to a prefix set but not to a public key. Because HBAs are compatible with CGA, the CGA Parameter Data Structure is used for their generation, but a random nonce is included in the Public Key field instead of a public key. These addresses can be used for HBA-based multihoming protocols, but they cannot be used for SeND 🙃
5. Multi-Prefix Extension for CGA 🦋
The Multi-Prefix extension has the following TLV format, as defined in [8]:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type | Extension Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix[1] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix[2] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix[n] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field does 👀
Ext Type: 16-bit type identifier of the Multi-Prefix extension (see the "IANA Considerations" section).Ext Len: 16-bit unsigned integer. Length of the Extension in octets, not including the first 4 octets.P flag: Set if a public key is included in the Public Key field of the CGA Parameter Data Structure, reset otherwise.Reserved: 31-bit reserved field. MUST be initialized to zero, and ignored upon receipt. ⚠️Prefix[1...n]: Vector of 64-bit prefixes, numbered 1 to n.
6. HBA-Set Generation ✨
okay so the HBA generation process is basically a glow-up of the CGA generation process from Section 4 of [2] 💅 the whole goal is to change as little as possible, bestie. it's only valid for Sec values of 0, 1, and 2 though 🫶 for any other Sec value, RFC 4982 [10] set up a CGA SEC registry, and the generation procedures in those specs must be used instead 🌸
so a CGA gets generated on its own, but all the HBAs in an HBA set have to be made with the same parameters 😭 that means the addresses in a set get made in a coordinated way, not one at a time. the mechanism here makes all of them in one go, and each HBA's generation is heavily based on CGA generation from [2]. honestly it's a sequence of lightly modified CGA generations, and that is iconic 🦋
for a single HBA, there are two changes to CGA generation. first, the Multi-Prefix extension has to go into the CGA Parameter Data Structure 🎀 second, if the address is an HBA-only address, a random nonce gets used as the input instead of a real public key. for backwards compatibility with pure CGAs, the random nonce MUST be encoded as a public key as defined in [2] 👑 specifically, the random nonce MUST be formatted as a DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo, defined in the Internet X.509 certificate profile [5]. the algorithm identifier MUST be rsaEncryption, which is 1.2.840.113549.1.1.1, and the random nonce MUST be formatted by using the RSAPublicKey type as specified in Section 2.3.1 of RFC 3279 [4]. the random nonce length is 384 bits 🔥
here's the HBA-set generation process 🧚
The inputs to the HBA generation process are:
- A vector of n 64-bit prefixes,
- A Sec parameter, and
- In the case of the generation of a set of HBA/CGA addresses, a public key is also provided as input (not required when generating HBA-only addresses).
The output of the HBA generation process are:
- An HBA-set
- their respective CGA Parameter Data Structures
The steps of the HBA-set generation process are:
- Multi-Prefix extension generation. Generate the Multi-Prefix extension with the format defined in Section 5. Include the vector of n 64-bit prefixes in the Prefix[1...n] fields. The Ext Len field value is
(n*8 + 4). If a public key is provided, then the P flag is set to one. Otherwise, the P flag is set to zero. 💖 - Modifier generation. Generate a Modifier as a random or pseudorandom 128-bit value. If a public key has not been provided as an input, generate the Extended Modifier as a 384-bit random or pseudorandom value. Encode the Extended Modifier value as an RSA key in a DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo defined in the Internet X.509 certificate profile [5]. 🌈
- Concatenate from left to right the Modifier, 9 zero octets, the encoded public key or the encoded Extended Modifier (if no public key was provided), and the Multi-Prefix extension. Execute the SHA-1 algorithm on the concatenation. Take the 112 leftmost bits of the SHA-1 hash value. The result is Hash2. 🍓
- Compare the
16*Secleftmost bits of Hash2 with zero. If they are all zero (or if Sec=0), continue with step (5). Otherwise, increment the Modifier by one and go back to step (3). 🙈 - Set the 8-bit collision count to zero. ✨
- For i=1 to n (number of prefixes) do:
- 6.1. Concatenate from left to right the final Modifier value, Prefix[i], the collision count, the encoded public key or the encoded Extended Modifier (if no public key was provided), and the Multi-Prefix extension. Execute the SHA-1 algorithm on the concatenation. Take the 64 leftmost bits of the SHA-1 hash value. The result is Hash1[i].
- 6.2. Form an interface identifier from Hash1[i] by writing the value of Sec into the three leftmost bits and by setting bits 6 and 7 (i.e., the "u" and "g" bits) both to zero. 🦋
- 6.3. Generate address HBA[i] by concatenating Prefix[i] and the 64-bit interface identifier to form a 128-bit IPv6 address with the subnet prefix to the left and interface identifier to the right as in a standard IPv6 address [6]. 🎀
- 6.4. Perform duplicate address detection if required. If an address collision is detected, increment the collision count by one and go back to step (6). However, after three collisions, stop and report the error. 😭
- 6.5. Form the CGA Parameter Data Structure that corresponds to HBA[i] by concatenating from left to right the final Modifier value, Prefix[i], the final collision count value, the encoded public key or the encoded Extended Modifier, and the Multi-Prefix extension. 👑
Note: most of the steps of the process are taken from [2].
7. HBA Verification
The following procedure is only valid for Sec values of 0, 1, and 2. For other Sec values, RFC 4982 [10] has defined a CGA SEC registry that will contain the specifications used to verify CGAs. The verification procedures defined in such specifications must be used for Sec values other than 0,1, or 2. 🌸
7.1. Verification That a Particular HBA Address Corresponds to a Given CGA Parameter Data Structure
HBAs are constructed as a CGA Extension, so a properly formatted HBA and its correspondent CGA Parameter Data Structure will successfully finish the verification process described in Section 5 of [2]. Such verification is useful when the goal is the verification of the binding between the public key and the HBA. 💅
7.2. Verification That a Particular HBA Address Belongs to the HBA Set Associated with a Given CGA Parameter Data Structure
for multihoming applications, it's also relevant that the receiver of the HBA information checks whether a given HBA address belongs to a certain HBA set 🌈 an HBA set is identified by a CGA Parameter Data Structure that contains a Multi-Prefix extension, so the receiver needs to verify if a given HBA belongs to the HBA set defined by that structure. the receiver may need to verify if an HBA belongs to the HBA set defined by the CGA Parameter Data Structure of another HBA of the set 🫣 if that's the case, HBAs will fail the CGA verification process defined in [2], because the prefix in the Subnet Prefix field of the CGA Parameter Data Structure won't match the prefix of the HBA being verified. the fix: verify that the HBA prefix is included in the prefix set defined in the Multi-Prefix extension, and if it is, substitute the prefix in the Subnet Prefix field with the prefix of the HBA, then run the CGA verification process defined in [2]. ✨
so the process to verify that an HBA belongs to an HBA set determined by a CGA Parameter Data Structure is called HBA verification 🎀 it goes like this:
The inputs to the HBA verification process are:
- An HBA
- A CGA Parameter Data Structure
The steps of the HBA verification process are the following:
- Verify that the 64-bit HBA prefix is included in the prefix set of the Multi-Prefix extension. If it is not included, the verification fails. If it is included, replace the prefix contained in the Subnet Prefix field of the CGA Parameter Data Structure by the 64-bit HBA prefix. 🍓
- Run the verification process described in Section 5 of [2] with the HBA and the new CGA Parameters Data Structure (including the Multi-Prefix extension) as inputs. The steps of the process are included below, extracted from [2]:
- 2.1. Check that the collision count in the CGA Parameter Data Structure is 0, 1, or 2. The CGA verification fails if the collision count is out of the valid range. 🙈
- 2.2. Check that the subnet prefix in the CGA Parameter Data Structure is equal to the subnet prefix (i.e., the leftmost 64 bits) of the address. The CGA verification fails if the prefix values differ. Note: This step always succeeds because of the action taken in step 1. 💖
- 2.3. Execute the SHA-1 algorithm on the CGA Parameter Data Structure. Take the 64 leftmost bits of the SHA-1 hash value. The result is Hash1. 🌸
- 2.4. Compare Hash1 with the interface identifier (i.e., the rightmost 64 bits) of the address. Differences in the three leftmost bits and in bits 6 and 7 (i.e., the "u" and "g" bits) are ignored. If the 64-bit values differ (other than in the five ignored bits), the CGA verification fails. 🦋
- 2.5. Read the security parameter Sec from the three leftmost bits of the 64-bit interface identifier of the address. (Sec is an unsigned 3-bit integer.) 🧚
- 2.6. Concatenate from left to right the Modifier, 9 zero octets, the public key, and any extension fields (in this case, the Multi-Prefix extension will be included, at least) that follow the public key in the CGA Parameter Data Structure. Execute the SHA-1 algorithm on the concatenation. Take the 112 leftmost bits of the SHA-1 hash value. The result is Hash2. 🌈
- 2.7. Compare the
16*Secleftmost bits of Hash2 with zero. If any one of them is non-zero, the CGA verification fails. Otherwise, the verification succeeds. (If Sec=0, the CGA verification never fails at this step.) 👑
8. Example of HBA Application in a Multihoming Scenario ✨
okay so this section is where we get to see HBA actually doing a job 💅 we're looking at how it could be used for IPv6 multihoming, which is basically when a site is connected to the internet through more than one provider at the same time 🌸
here's the setup we're working with: a multihomed site gets its internet from two providers, ISPA and ISPB. each provider has handed the site a prefix, which are PrefA::/nA and PrefB::/nb. to actually benefit from multihoming, the hosts inside the site configure more than one IP address, one for each prefix they have available. here's the picture:
+-------+
| Host2 |
|IPHost2|
+-------+
|
|
(Internet)
/ \
/ \
+------+ +------+
| ISPA | | ISPB |
| | | |
+------+ +------+
| |
\ /
\ /
+---------------------+
| multihomed site |
| PA::/nA |
| PB::/nB +------+ |
| |Host1 | |
| +------+ |
+---------------------+we're assuming both Host1 and Host2 speak Shim6 🦋
Host2 is NOT sitting in a multihomed site, so it doesn't need to make any HBAs of its own 🙅♀️ it still has to be able to verify them, though, because that's how Shim6 works, and we'll get to that in a sec.
Host1 lives in the multihomed site, so it generates its addresses as HBAs 🎀 to do that, it runs the HBA-set generation process from Section 6 of this memo. the inputs are: a prefix vector with the two prefixes on its link (PA:LA::/64 and PB:LB::/64), a Sec parameter value, and optionally a public key. in this example we DO include a public key, so we can also show how a renumbering event gets handled when HBA/CGA addresses are in play (more on that in the dynamic address set part!). after the generation runs, Host1 ends up with an HBA-set of two addresses, PA:LA:iidA and PB:LB:iidB, each with its own CGA Parameter Data Structure, CGA_PDS_A and CGA_PDS_B. the cool part is that iidA and iidB are different, but both of them carry info about the whole set of prefixes available in the site 🧚
now let's talk about a conversation between Host1 and Host2. both ISPs are working fine, so either of Host1's addresses could be used. let's say they start talking using PA:LA:iidA on Host1's side and IPHost2 on Host2's side. so far nothing fancy is needed, and PA:LA:iidA just gets used like any normal global IP address 💖
then at some point one of the hosts decides it wants multihoming support for this conversation. basically that means one of them wants extra fault tolerance, so if an outage hits, the conversation can be moved over to the other provider 🔥
when that happens, the Shim6 Host-Pair Context establishment exchange runs between the two hosts (see [9]). during this exchange, Host1 sends CGA_PDS_A over to Host2.
once Host2 gets CGA_PDS_A, it has to check that this structure actually matches the address being used, PA:LA:iidA. so Host2 runs the HBA verification process from Section 7 of this memo, using PA:LA:iidA and CGA_PDS_A as the inputs. in this case the check passes, because the CGA Parameter Data Structure and the addresses used in the verification line up 👑
as long as the ISPA path is healthy, packets keep flowing 🌈 but if something breaks the ISPA path, Host1 tries to re-home the conversation onto its other address, PB:LB:iidB. to pull that off, Host1 first detects the outage, then tells Host2 about the new address. Host2 then has to confirm the new address belongs to the HBA set of the original address. it does this by running the HBA verification process with CGA_PDS_A (from the original address) and PB:LB:iidB (the new address) as inputs. this check succeeds because PB:LB::/64 was included in the Multi-Prefix extension during HBA-set generation. extra verification might be needed to guard against flooding attacks (check out the comments about flooding attack prevention in the Security Considerations section of this memo) 🚨
once the new address passes verification, it can be used as an alternative locator to re-home the conversation, while the original address (PA:LA:iidA) stays as the identifier for the upper layers. so from here on, packets go to and come from the new address 🦋 and no more HBA verification is needed for the following packets, since the verified address can just be stored on Host2 💅
one more thing: in this example, only the HBA features of Host1's addresses were used. that means neither the public key in the CGA Parameter Data Structure nor its matching private key ever got used in the protocol. in the next section we'll look at a case where they ARE needed 🔑
8.1. Dynamic Address Set Support 🌸
okay, so the last section covered how a host can switch between addresses from a set that was fixed and known when the conversation started. that only needed the HBA features of the addresses. this part is about the trickier case: using addresses that WEREN'T known when the conversation began 😭 a classic example is when a new prefix shows up in the site after a renumbering event. then the hosts that got the new address might want to use it in conversations that were already going before the renumbering happened. in that situation, HBA features alone aren't enough, and CGA capabilities have to come in 🫶
let's go back to the Host1 and Host2 conversation. same deal: it's up and running, Host1 is using PA:LA:iidA and Host2 is using IPHost2. now say a new address, PC:LC:addC, shows up on Host1. this one is just a regular IPv6 address, NOT an HBA and NOT a CGA, so the HBA mechanism from the previous section can't verify it. it doesn't belong to the HBA set, because that prefix wasn't around when the set got generated 💀 so we'll need different verification mechanisms here.
to verify this new address, we use the CGA capabilities of PA:LA:iidA. same address, just a different verification method, which is kind of iconic ✨ so if Host1 wants to use PC:LC:addC in the existing conversation, it sends an UPDATE message from the Shim6 protocol [9], carrying the new address PC:LC:addC. that message gets signed with the private key that matches the public key inside CGA_PDS_A. when Host2 gets the message, it checks the signature using the public key in the CGA Parameter Data Structure linked to the address used to set up the conversation, which means CGA_PDS_A and PA:LA:iidA. once the signature checks out, PC:LC:addC can be used in the conversation 🎀
heads up: a renumbering event affects any site that's using the HBA technique. the new prefix won't be part of the existing HBA set, so the new prefix can only be used alongside the existing HBA set if CGA capabilities are used. that's fine for the short term, but long term the site has to renumber its HBA addresses. to do that, it needs to regenerate the HBA sets assigned to hosts so they include the new prefix in the prefix set. that gives different addresses, not just because a new address gets added with the new prefix, but also because the addresses with the existing prefixes change too, since the prefix set now has a new prefix in it. and since HBA addresses have to be generated locally, once they're regenerated after the renumbering, the new address info has to be passed to the DNS manager if it's going to be published in the DNS (see the DNS considerations section for more details) 🌈💜
9. DNS Considerations 💅🌸
okay so HBA sets can be generated using ANY prefix set 🫶 The only thing that makes HBA special is that it stores info about the prefix set inside the interface identifier part of the address, as a hash. But there are NO assumptions made about the properties of the prefixes used for the generation ✨ So it's giving "it depends." Depending on which prefixes you used, it may or may not be recommended to publish the resulting (HBA) addresses in the DNS 🧚
For example, when Unique Local Address (ULA) prefixes [18] get included in the HBA generation process, you have to think about the DNS stuff that comes with the local nature of the ULA 🙈 specific DNS considerations related to the local nature of the ULA should be taken into account, and you should follow the proper recommendations about publishing those prefixes in the DNS (yes, it's "should followed" in the original, bestie, I'm keeping it as is 💀).
Also, a host can have some HBAs AND some other IPv6 addresses at the same time 👑 The consequence? Only the HBA addresses get bound together by the HBA technique. The other addresses are NOT bound to the HBA set. So if one of those other addresses is used to start a Shim6 communication, you can't use the HBA technique to bind that address to the HBA set 😭 And since HBA addresses look exactly like any other IPv6 address format-wise, an initiator can't tell just by looking which ones belong to the HBA set and which ones don't. So alternative means would be required, and the initiator is supposed to use only HBA for establishing communications when there are non-HBA addresses in the DNS 🔥
Lowkey important: the actual HBA values are the result of the HBA generation procedure, which means they can't be arbitrarily chosen 💖 This matters for DNS management because the party that generates the HBA address set needs to convey the address info to the DNS manager, so the addresses get published. NOT the other way around 🍓 It's the same vibe as regular CGA addresses and even stateless address autoconfiguration. To do that, you can use Dynamic DNS updates [19] or other proprietary tools 🦋
Same goes for reverse-DNS entries 🌈 Since the host needs to generate its HBA addresses, it will need to convey the address information to the DNS manager so the proper reverse-DNS entry is populated in case it's needed. Here's the tea: neither the Shim6 protocol nor the HBA technique rely on the reverse DNS to work properly ✨ The general reasons for requiring reverse-DNS population apply the same as for any other regular IPv6 address 💅
10. IANA Considerations 🎀
This document defines a new CGA Extension, the Multi-Prefix extension 🧚 It has been assigned the CGA Extension Type value 0x0012 💜
11. Security Considerations 🚨💀
Okay bestie, this is the serious part, so pay attention 👑 The goal of HBAs is to create a group of addresses that are securely bound, so they can be used interchangeably when communicating with a node. If there's NO secure binding between a node's different addresses, a bunch of attacks get enabled, as described in [11] 😱 The scariest one: an attacker could redirect a victim's communications to an address the attacker picked, hijacking the whole conversation 🙈
With HBAs, only the addresses belonging to an HBA set can be used interchangeably. That limits the addresses that can be used to redirect the communication to a predetermined set that belongs to the original node involved in the communication 🫶 So, when using HBAs, a node communicating with address A can redirect the communication to a new address B if and only if B belongs to the same HBA set as A 🔐
So here's the attacker's problem. If they want to redirect communications addressed to HBA1 to an alternative address IPX, they'll need to create a CGA Parameter Data Structure that generates an HBA set containing BOTH HBA1 and IPX 😈 To build that set, the attacker needs to find a CGA Parameter Data Structure that meets these conditions:
- the prefix of HBA1 and the prefix of IPX are included in the Multi-Prefix extension.
- HBA1 is included in the HBA set generated.
Note: this assumes that it is acceptable for the attacker to redirect HBA1 to any address of the prefix of IPX.
The other fields the attacker can change at will to meet those conditions are: the Modifier, other prefixes in the Multi-Prefix extension, and other extensions 🧩 Either way, to get the desired HBA set, the attacker has to use a brute-force attack, which means generating multiple HBA sets with different parameters (for instance, with a different Modifier) until the desired conditions are met. The expected number of times the generation has to be repeated until the desired HBA set is found is exponentially related to the number of bits containing hash information in the interface identifier of the HBA. Since 59 of the 64 bits of the interface identifier contain hash bits, the expected number of generations the attacker has to perform is O(2^59) 😭🔥 That is a LOT of attempts, babe.
Note: We assume brute force is the best attack against HBA/CGAs. Also, note that the assumption that the Sec tool defined in [2] multiplies the attack factor holds for brute-force attacks but may not hold for other attack classes.
The protection against brute-force attacks can be improved by increasing the Sec parameter ✨ A non-zero Sec parameter means steps 3-4 of the generation process get repeated O(2^(16*Sec)) times (expected number of times). If we treat the cost of repeating steps 3-4 as the cost of generating the HBA address, then we can estimate the number of times the generation has to be repeated as O(2^(59+16*Sec)), in the case of Sec values of 1 and 2 💖 For other Sec values, Sec protection mechanisms will be defined by the specifications pointed to by the CGA SEC registry defined in RFC 4982 [10] 🦋
11.1. Security Considerations When Using HBAs in the Shim6 Protocol
okay bestie, this part is where we look at how much security HBAs actually give you inside the Shim6 protocol from Section 8 of this memo 🔍✨
First things first: HBAs cannot prevent man-in-the-middle (hereafter MITM) attacks. 😭 If an attacker is sitting on the path between Host1 and Host2 for the whole life of the communication, they can change the addresses being used. They can add or remove prefixes whenever they feel like it 🙈 BUT, and this is the important part, they have to make sure the CGA Parameter Data Structure and the HBA set get changed to match. That basically means the attacker has to change the interface identifier part of the addresses involved, because a change in the prefix set gives different interface identifiers for the addresses in the HBA set. The only exception is when the right Modifier value is used, and finding that would take O(2(59+16*Sec)) attempts. So HBAs don't stop MITM attacks, but a MITM attacker has to change the addresses used in the communication just to change the prefix set that's valid for it. main character energy for the HBA design 💅
HBAs provide protection against time shifting attacks [11], [12]. In the multihoming context, the attacker does this: they're placed along the path of the communication and modify packets to add an extra address as a valid address for the communication. Then they leave the on-path spot, but the damage is still there, because the address still counts as valid for that communication. Let's see how HBAs stop this 👀
If the attacker isn't on-path when the initial CGA Parameter Data Structure gets exchanged, their only shot at a redirection attack is to fake the signature on the message that adds new addresses, using the CGA capabilities of the addresses. That would mean discovering the public key in the CGA Parameter Data Structure and then cracking the key pair, which doesn't seem feasible 🔐 So to pull off a redirection attack, the attacker needs to be on-path when the CGA Parameter Data Structure is exchanged, so they can modify it. To launch the redirection attack, they need to add their own prefix to the prefix set of the CGA Parameter Data Structure. We covered two possible approaches for this in the previous section:
- Find the right Modifier value, so that the address initially used in the communication is contained in the new HBA set. The cost of this attack is
O(2(59+16*Sec))iterations of the generation process, so it is deemed unfeasible. 🙅♀️ - Use any Modifier value, so that the address initially used in the communication is probably not included in the HBA set. In this case, the attacker must remain on-path, since they need to rewrite the address carried in the packets (if not, the endpoints will notice a change in the address used in the communication). This basically means the attacker cannot launch a time shifted attack, but they have to be a full-time man-in-the-middle. 🫶
So, the conclusion is that HBAs provide protection against time shifted attacks 🎀
HBAs do not provide complete protection against flooding attacks, so the SHIM6 protocol has other ways to deal with them. However, HBAs make it very difficult to launch a flooding attack towards a specific address. It is possible, though, to launch a flooding attack against a prefix. And of course, the protection HBA offers only applies to nodes that use it. HBA provides no solution for general-purpose flooding-attack protection for other nodes. 🌸
Suppose an attacker has easy access to a prefix PX::/nX and wants to launch a flooding attack on a host located at P:iid. The attack would go like this: they set up communication with a server S and request a heavy flow from it. Then they redirect the flow to P:iid, flooding the target. 😈 To do this, the attacker needs to generate an HBA set that includes P and PX in the prefix set, and make sure the resulting HBA set contains P:iid. To get there, they need to find the right Modifier value. The expected number of attempts needed to find that Modifier value is O(2(59+16*Sec)), as shown earlier. So we can conclude that this attack is not feasible. 🙌
The target of a flooding attack isn't limited to specific hosts, though. It can also be aimed at other parts of the infrastructure, like router or access links. To do that, the attacker can set up communication with a server S and request a download of a heavy flow. Then the attacker redirects the communication to any address in the target network. Even if the target address isn't assigned to any host, the flow will flood the access link of the target site, and the site access router will also get overloaded 💀 This kind of attack can't be prevented using HBAs, since the attacker can easily generate an HBA set using their own prefix and the target network prefix. To prevent attacks like this, additional mechanisms are required, such as reachability tests. 🚧
11.2. Privacy Considerations
HBAs can be used as RFC 4941 [7] addresses. ✨ If a node wants to use temporary addresses, it will need to periodically generate new HBA sets. The effort for this depends on the Sec parameter value. If Sec=0, the cost of generating a new HBA set is similar to the cost of generating a random number, which is one iteration of the HBA set generation procedure. But if Sec>0, generating an HBA set gets way more expensive, since it requires O(2(16*Sec)) iterations of the generation process. 💸 So depending on how often the address needs to change, supporting RFC 4941 addresses may end up costing more.
11.3. SHA-1 Dependency Considerations
Recent attacks on currently used hash functions have raised a lot of concern in the Internet community 😬 The recommended approach [14] [15] is to first analyze the impact of these attacks on the different Internet protocols that use hash functions, and second, to make sure those protocols can move to an alternative (more secure) hash function without a major disruption to the Internet's operation. 🔄
The analysis for CGAs and their extensions (including HBAs) is done in RFC 4982 [10]. The conclusion is that the security of protocols using CGAs and their extensions is not affected by these recently available attacks against hash functions. 🙌 Even so, the CGA specification [2] was updated by RFC 4982 [10] to enable support for alternative hash functions. very responsible of them, honestly 🎀
11.4. DoS Attack Considerations
To use the HBA technique, the owner of the HBA set must tell its peer about the CGA Parameter Data Structure, so the peer can verify that the different HBAs belong to the same HBA set. The peer then has to store that information so it can verify alternative addresses in the future. 🗂️ This can be a vector for DoS attacks, since the peer has to commit resources (in this case, memory) to use the HBA technique for address verification. So an attacker could launch a DoS attack by sending HBA information to a victim, making them use memory for HBA-related state, and eventually running them out of memory for other genuine operations. 😱 To prevent this, protocols that use the HBA technique should implement proper DoS prevention techniques.
For instance, the Shim6 protocol [9] includes a 4-way handshake to establish the Shim6 context and, in particular, the HBA-related state. In this 4-way handshake, the receiver stays stateless during the first 2 messages, while the initiator must keep state through the exchange of all 4 messages. So setting up the context costs more in memory for the initiator (the potential attacker) than for the receiver (the potential victim). 🛡️ On top of that, the 4-way handshake stops spoofed addresses from off-path attackers, since the initiator must be able to receive information through the address it used as its source address. That makes it possible to track the location the attack came from. 🕵️♀️
12. Contributors
This document was originally produced by a MULTI6 design team made up of (in alphabetical order): Jari Arkko, Marcelo Bagnulo, Iljitsch van Beijnum, Geoff Huston, Erik Nordmark, Margaret Wasserman, and Jukka Ylitalo. 👑
13. Acknowledgments
The initial discussion about HBA benefited from contributions from Alberto Garcia-Martinez, Tuomas Aura, and Arturo Azcorra. 💜
The HBA-set generation and HBA verification processes described in this document contain several steps extracted from [2].
Jari Arkko, Matthew Ford, Francis Dupont, Mohan Parthasarathy, Pekka Savola, Brian Carpenter, Eric Rescorla, Robin Whittle, Matthijs Mekking, Hannes Tschofenig, Spencer Dawkins, Lars Eggert, Tim Polk, Peter Koch, Niclas Comstedt, David Ward, and Sam Hartman have reviewed this document and provided valuable comments. 🫶
The text included in Section 3.2 was provided by Eric Rescorla.
The author would also like to thank Francis Dupont for providing the first implementation of HBA. 🧚
14. References
14.1. Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [2] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
- [3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
- [4] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
- [5] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
- [6] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
- [7] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
- [8] Bagnulo, M. and J. Arkko, "Cryptographically Generated Addresses (CGA) Extension Field Format", RFC 4581, October 2006.
- [9] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
- [10] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)", RFC 4982, July 2007.
14.2. Informative References 📚✨
okay bestie, these are the "if you want the deep lore" ones 🧠💅 Not required reading, just the receipts 🧾
[11] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming
Solutions", RFC 4218, October 2005.
[12] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005.
[13] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007.
[14] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes
in Internet Protocols", RFC 4270, November 2005.
[15] Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm",
2005 September.
[16] Nordmark, E., "Multi6 Application Referral Issues", Work
in Progress, October 2004.
[17] Bagnulo, M., Garcia-Martinez, A., and A. Azcorra, "Efficient
Security for IPv6 Multihoming", ACM Computer Communications
Review Vol 35 n 2, April 2005.
[18] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[19] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.Author's Address 🎀
this is who wrote the whole thing, so you know who to thank 🫶🌸
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: 34 91 6249500
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es📦 where this page comes from
- ietf: rfc5535 2009-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms