On the Generation of Transient Numeric Identifiers

7.1. Category #1: Uniqueness (soft failure)

The requirement of uniqueness with a soft failure severity can be complied with a Pseudo-Random Number Generator (PRNG).¶

NOTE:

Please see [RFC4086] regarding randomness requirements for security.¶

While most systems provide access to a PRNG, many of such PRNGs are not cryptographically secure. For example, POSIX random(3) implementations [POSIX] are usually flawed for cryptographic applications.¶

On the other hand, a number of systems provide an interface to a Cryptographically Secure PRNG (CSPRNG) [RFC8937], which usually continually "re-seeds" itself from physical sources of randomness. For example, GNU/Linux's CSPRNG implementation is available via the getrandom(2) interface, while OpenBSD's CSPRNG implementation is available via the arc4random(3) and arc4random_uniform(3) interfaces. Where available, these CSPRNGs should be preferred over e.g. POSIX random(3) implementations.¶

In scenarios where a CSPRNG is not readily available to select transient numeric identifiers of Category #1, a security and privacy assessment of employing a regular PRNG should be performed, supporting the implementation decision.¶

NOTE:

[Press2007] and [Knuth1983] discuss theoretical and practical aspects of random numbers generation, and provide guidance on how to evaluate PRNGs.¶

We note that since the premise is that collisions of transient numeric identifiers of this category only leads to soft failures, in many cases, the algorithm might not need to check the suitability of a selected identifier (i.e., the suitable_id() function, described below, could always return "true").¶

In scenarios where e.g. simultaneous use of a given numeric ID is undesirable and the implementation detects such condition, an implementation may opt to select the next available identifier in the same sequence, or select another random number. Section 7.1.1 is an implementation of the former strategy, while Section 7.1.2 is an implementation of the later. Typically, the algorithm in Section 7.1.2 results in a more uniform distribution of the generated transient numeric identifiers. However, for transient numeric identifiers where an implementation typically keeps local state about unsuitable/used identifiers, the algorithm in Section 7.1.2 may require many more iterations than the algorithm in Section 7.1.1 to generate a suitable transient numeric identifier. This will usually be affected by the current usage ratio of transient numeric identifiers (i.e., number of numeric identifiers considered suitable / total number of numeric identifiers) and other parameters. Therefore, in such cases many implementations tend to prefer the algorithm in Section 7.1.1 over the algorithm in Section 7.1.2.¶

    /* Transient Numeric ID selection function */

    id_range = max_id - min_id + 1;
    next_id = min_id + (random() % id_range);
    retry = id_range;

    do {
        if (suitable_id(next_id)) {
            return next_id;
        }

        if (next_id == max_id) {
            next_id = min_id;
        } else {
            next_id++;
        }

        retry--;

    } while (retry > 0);

    return ERROR;

    /* Transient Numeric ID selection function */

    id_range = max_id - min_id + 1;
    retry = id_range;

    do {
        next_id = min_id + (random() % id_range);

        if (suitable_id(next_id)) {
            return next_id;
        }

        retry--;

    } while (retry > 0);

    return ERROR;

7.2. Category #2: Uniqueness (hard failure)

One of the most trivial approaches for generating unique transient numeric identifier (with a hard failure severity) is to reduce the identifier reuse frequency by generating the numeric identifiers with a monotonically-increasing function (e.g. linear). As a result, any of the algorithms described in Section 7.4 ("Category #4: Uniqueness, monotonically increasing within context (hard failure)") can be readily employed for complying with the requirements of this transient numeric identifier category.¶

In cases where suitability (e.g. uniqueness) of the selected identifiers can be definitely assessed by the local system, any of the algorithms described in Section 7.1 ("Category #1: Uniqueness (soft failure)") can be readily employed for complying with the requirements of this numeric identifier category.¶

NOTE:

In the case of e.g. TCP ephemeral ports or TCP ISNs, a transient numeric identifier that might seem suitable from the perspective of the local system, might actually be unsuitable from the perspective of the remote system (e.g., because there is state associated with the selected identifier at the remote system). Therefore, in such cases it is not possible employ the algorithms from Section 7.1 ("Category #1: Uniqueness (soft failure)").¶

7.3. Category #3: Uniqueness, stable within context (soft failure)

The goal of the following algorithm is to produce identifiers that are stable for a given context (identified by "CONTEXT"), but that change when the aforementioned context changes.¶

In order to avoid storing in memory the transient numeric identifiers computed for each CONTEXT, the following algorithm employs a calculated technique (as opposed to keeping state in memory) to generate a stable transient numeric identifier for each given context.¶

    /* Transient Numeric ID selection function  */

    id_range = max_id - min_id + 1;

    retry = 0;

    do {
        offset = F(CONTEXT, retry, secret_key);
        next_id = min_id + (offset % id_range);

        if (suitable_id(next_id)) {
            return next_id;
        }

        retry++;

    } while (retry <= MAX_RETRIES);

    return ERROR;

In this algorithm, the function F() provides a stateless and stable per-CONTEXT offset, where CONTEXT is the concatenation of all the elements that define the given context.¶

For example, if this algorithm is expected to produce IPv6 IIDs that are unique per network interface and SLAAC autoconfiguration prefix, the CONTEXT should be the concatenation of e.g. the network interface index and the SLAAC autoconfiguration prefix (please see [RFC7217] for an implementation of this algorithm for generation of stable IPv6 IIDs).¶

F() is a pseudorandom function (PRF). It must not be computable from the outside (without knowledge of the secret key). F() must also be difficult to reverse, such that it resists attempts to obtain the secret_key, even when given samples of the output of F() and knowledge or control of the other input parameters. F() should produce an output of at least as many bits as required for the transient numeric identifier. SipHash-2-4 (128-bit key, 64-bit output) [SipHash] and BLAKE3 (256-bit key, arbitrary-length output) [BLAKE3] are two possible options for F(). Alternatively, F() could be implemented with a keyed-hash message authentication code (HMAC) [RFC2104]. HMAC-SHA-256 [FIPS-SHS] would be one possible option for such implementation alternative. Note: Use of HMAC-MD5 [RFC1321] is not recommended for F() [RFC6151].¶

The result of F() is no more secure than the secret key, and therefore 'secret_key' must be unknown to the attacker, and must be of a reasonable length. 'secret_key' must remain stable for a given CONTEXT, since otherwise the numeric identifiers generated by this algorithm would not have the desired stability properties (i.e., stable for a given CONTEXT). In most cases, 'secret_key' should be selected with a PRNG (see [RFC4086] for recommendations on choosing secrets) at an appropriate time, and stored in stable or volatile storage (as necessary) for future use.¶

The result of F() is stored in the variable 'offset', which may take any value within the storage type range, since we are restricting the resulting identifier to be in the range [min_id, max_id] in a similar way as in the algorithm described in Section 7.1.1.¶

suitable_id() checks whether the candidate identifier has suitable uniqueness properties. Collisions (i.e., an identifier that is not unique) are recovered by incrementing the 'retry' variable and recomputing F(), up to a maximum of MAX_RETRIES times. However, recovering from collisions will usually result in identifiers that fail to remain constant for the specified context. This is normally acceptable when the probability of collisions is small, as in the case of e.g. IPv6 IIDs resulting from SLAAC [RFC7217] [RFC4941].¶

For obvious reasons, the transient numeric identifiers generated with this algorithm allow for network activity correlation and fingerprinting within "CONTEXT". However, this is essentially a design goal of this category of transient numeric identifiers.¶

7.4. Category #4: Uniqueness, monotonically increasing within context (hard failure)

    /* Transient Numeric ID selection function */

    id_range = max_id - min_id + 1;
    retry = id_range;
    id_inc = increment() % id_range;

    if( (next_id = lookup_counter(CONTEXT)) == ERROR){
         next_id = min_id + random() % id_range;
    }

    do {
        if ( (max_id - next_id) >= id_inc){
            next_id = next_id + id_inc;
        }
        else {
            next_id = min_id + id_inc - (max_id - next_id);
        }

        if (suitable_id(next_id)){
            store_counter(CONTEXT, next_id);
            return next_id;
        }

        retry = retry - id_inc;

    } while (retry > 0);

    return ERROR;

    /* Initialization code */
    counter = 0;

    /* Transient Numeric ID selection function  */

    id_range = max_id - min_id + 1;
    id_inc = increment() % id_range;
    offset = F(CONTEXT, secret_key);
    retry = id_range;

    do {
        next_id = min_id + (offset + counter) % id_range;
        counter = counter + id_inc;

        if (suitable_id(next_id)) {
            return next_id;
        }

        retry = retry - id_inc;

    } while (retry > 0);

    return ERROR;

    /* Initialization code */

    for(i = 0; i < TABLE_LENGTH; i++) {
        table[i] = random();
    }

    /* Transient Numeric ID selection function */

    id_range = max_id - min_id + 1;
    id_inc = increment() % id_range;
    offset = F(CONTEXT, secret_key1);
    index = G(CONTEXT, secret_key2) % TABLE_LENGTH;
    retry = id_range;

    do {
        next_id = min_id + (offset + table[index]) % id_range;
        table[index] = table[index] + id_inc;

        if (suitable_id(next_id)) {
            return next_id;
        }

       retry = retry - id_inc;

    } while (retry > 0);

    return ERROR;

8.1. Network Activity Correlation

An identifier that is predictable within a given context allows for network activity correlation within that context.¶

For example, a stable IPv6 Interface Identifier allows for network activity to be correlated within the context in which the Interface Identifier is stable [RFC7721]. A stable-per-network IPv6 Interface Identifier (as in [RFC7217]) allows for network activity correlation within a network, whereas a constant IPv6 Interface Identifier (that remains constant across networks) allows not only network activity correlation within the same network, but also across networks ("host tracking").¶

Similarly, an implementation that generates TCP ISNs with a global counter could allow for fingerprinting and network activity correlation across networks, since an attacker could passively infer the identity of the victim based on the TCP ISNs employed for subsequent communication instances. Similarly, an implementation that generates predictable IPv6 Fragment Identification values could be subject to fingerprinting attacks (see e.g. [Bellovin2002]).¶

8.2. Information Leakage

Transient numeric identifiers that result in specific patterns can produce an information leakage to other communicating entities. For example, it is common to generate transient numeric identifiers with an algorithm such as:¶

ID = offset(CONTEXT) + mono(CONTEXT);

This generic expression generates identifiers by adding a monotonically-increasing function (e.g. linear) to a randomized offset. offset() is constant within a given context, whereas mono() produces a monotonically-increasing sequence for the given context. Identifiers generated with this expression will generally be predictable within CONTEXT.¶

The predictability of mono(), irrespective of the predictability of offset(), can leak information that may be of use to attackers. For example, a node that selects ephemeral port numbers as in:¶

ephemeral_port = offset(Dest_IP) + mono()

that is, with a per-destination offset, but a global mono() function (e.g., a global counter), will leak information about total number of outgoing connections that have been issued by the vulnerable implementation.¶

Similarly, a node that generates Fragment Identification values as in:¶

Frag_ID = offset(IP_src_addr, IP_dst_addr) + mono()

will leak out information about the total number of fragmented packets that have been transmitted by the vulnerable implementation. The vulnerabilities described in¶

[Sanfilippo1998a], [Sanfilippo1998b], and [Sanfilippo1999] are all associated with the use of a global mono() function (i.e., with a global and constant "context") -- particularly when it is a linear function (constant increments of 1).¶

Predicting transient numeric identifiers can be of help for other types of attacks. For example, predictable TCP ISNs can open the door to trivial connection-reset and data injection attacks (see Section 8.6).¶

8.3. Fingerprinting

Fingerprinting is the capability of an attacker to identify or re-identify a visiting user, user agent or device via configuration settings or other observable characteristics. Observable protocol objects and characteristics can be employed to identify/re-identify a variety of entities, ranging from the underlying hardware or Operating System (vendor, type and version), to the user itself (i.e. his/her identity). [EFF] illustrates web browser-based fingerprinting, but similar techniques can be applied at other layers and protocols, whether alternatively or in conjunction with it.¶

Transient numeric identifiers are one of the observable protocol components that could be leveraged for fingerprinting purposes. That is, an attacker could sample transient numeric identifiers to infer the algorithm (and its associated parameters, if any) for generating such identifiers, possibly revealing the underlying Operating System (OS) vendor, type, and version. This information could possibly be further leveraged in conjunction with other fingerprinting techniques and sources.¶

Evasion of protocol-stack fingerprinting can prove to be a very difficult task: most systems make use of a wide variety of protocols, each of which have a large number of parameters that can be set to arbitrary values or generated with a variety of algorithms with multiple parameters.¶

NOTE:

General protocol-based fingerprinting is discussed in [RFC6973], along with guidelines to mitigate the associated vulnerability. [Fyodor1998] and [Fyodor2006] are classic references on Operating System detection via TCP/IP stack fingerprinting. Nmap [nmap] is probably the most popular tool for remote OS identification via active TCP/IP stack fingerprinting. p0f [Zalewski2012], on the other hand, is a tool for performing remote OS detection via passive TCP/IP stack fingerprinting. Finally, [TBIT] is a TCP fingerprinting tool that aims at characterizing the behaviour of a remote TCP peer based on active probes, and which has been widely used in the research community.¶

Algorithms that, from the perspective of an observer (e.g., the legitimate communicating peer), result in specific values or patterns, will allow for at least some level of fingerprinting. For example, the algorithm from Section 7.3 will typically allow fingerprinting within the context where the resulting identifiers are stable. Similarly, the algorithms from Section 7.4 will result in a monotonically-increasing sequences within a given context, thus allowing for at least some level of fingerprinting (when the other communicating entity can correlate different sampled identifiers as belonging to the same monotonically-increasing sequence).¶

Thus, where possible, algorithms from Section 7.1 should be preferred over algorithms that result in specific values or patterns.¶

8.4. Exploitation of the Semantics of Transient Numeric Identifiers

Identifiers that are not semantically opaque tend to be more predictable than semantically-opaque identifiers. For example, a MAC address contains an OUI (Organizationally-Unique Identifier) which identifies the vendor that manufactured the corresponding network interface card. This can be leveraged by an attacker trying to "guess" MAC addresses, who has some knowledge about the possible NIC vendor.¶

[RFC7707] discusses a number of techniques to reduce the search space when performing IPv6 address-scanning attacks by leveraging the semantics of the IIDs produced by traditional SLAAC algorithms (eventually replaced by [RFC7217]) that embed MAC addresses in the IID of IPv6 addresses.¶

8.5. Exploitation of Collisions of Transient Numeric Identifiers

In many cases, the collision of transient network identifiers can have a hard failure severity (or result in a hard failure severity if an attacker can cause multiple collisions deterministically, one after another). For example, predictable Fragment Identification values open the door to Denial of Service (DoS) attacks (see e.g. [RFC5722].).¶

8.6. Exploitation of Predictable Transient Numeric Identifiers for Injection Attacks

Some protocols rely on "sequence numbers" for the validation of incoming packets. For example, TCP employs sequence numbers for reassembling TCP segments, while IPv4 and IPv6 employ Fragment Identification values for reassembling IPv4 and IPv6 fragments (respectively). Lacking built-in cryptographic mechanisms for validating packets, these protocols are therefore vulnerable to on-path data (see e.g. [Joncheray1995]) and/or control-information (see e.g. [RFC4953] and [RFC5927]) injection attacks. The extent to which these protocols may resist off-path (i.e. "blind") injection attacks depends on whether the associated "sequence numbers" are predictable, and effort required to successfully predict a valid "sequence number" (see e.g. [RFC4953] and [RFC5927]).¶

We note that the use of unpredictable "sequence numbers" is a completely-ineffective mitigation for on-path injection attacks, and also a mostly-ineffective mitigation for off-path (i.e. "blind") injection attacks. However, many legacy protocols (such as TCP) do not natively incorporate cryptographic mitigations, but rather only as optional features (see e.g. [RFC5925]), if at all available. Additionally, ad-hoc use of cryptographic mitigations might not be sufficient to relieve a protocol implementation of generating appropriate transient numeric identifiers. For example, use of the Transport Layer Security (TLS) protocol [RFC8446] with TCP will protect the application protocol, but will not help to mitigate e.g. TCP-based connection-reset attacks (see e.g. [RFC4953]). Similarly, use of SEcure Neighbor Discovery (SEND) [RFC3971] will still imply reliance on the successful reassembly of IPv6 fragments in those cases where SEND packets do not fit into the link Maximum Transmission Unit (MTU) (see [RFC6980]).¶

8.7. Cryptanalysis

A number of algorithms discussed in this document (such as those described in Section 7.4.2 and Section 7.4.3) rely on PRFs. Implementations that employ weak PRFs or keys of inappropriate size can be subject to cryptanalysis, where an attacker can obtain the secret key employed for the PRF, predict numeric identifiers, etc.¶

Furthermore, an implementation that overloads the semantics of the secret key can result in more trivial cryptanalysis, possibly resulting in the leakage of the value employed for the secret key.¶

NOTE:

[IPID-DEV] describes two vulnerable transient numeric ID generators that employ cryptographically-weak hash functions. Additionally, one of such implementations employs 32-bits of a kernel address as the secret key for a hash function, and therefore successful cryptanalysis leaks the aforementioned kernel address, allowing for Kernel Address Space Layout Randomization (KASLR) [KASLR] bypass.¶

9.1. Category #1: Uniqueness (soft failure)

Possible vulnerabilities associated with the algorithms from Section 7.1 include:¶

• Use of flawed PRNGs (please see e.g. [Zalewski2001], [Zalewski2002], [Klein2007] and [CVEs]).¶
• Inadvertently affecting the distribution of an otherwise suitable PRNG.¶

Where available, CSPRNGs should be preferred over regular PRNGs such as e.g. POSIX random(3) implementations. In scenarios where a CSPRNG is not readily available, a security and privacy assessment of employing a regular PRNG should be performed, supporting the implementation decision.¶

NOTE:

Please see [RFC4086] regarding randomness requirements for security. [Press2007] and [Knuth1983] discuss theoretical and practical aspects of random numbers generation, and provide guidance on how to evaluate PRNGs.¶

When employing a PRNG, many implementations "adapt" the length of its output with a modulo operator (e.g., C language's "%"), possibly changing the distribution of the output of the PRNG.¶

For example, consider an implementation that employs the following code:¶

id = random() % 50000;

This example implementation means to obtain a transient numeric identifier in the range 0-49999. If random() produces e.g. a pseudorandom number of 16 bits (with uniform distribution), the selected transient numeric identifier will have a non-uniform distribution with the numbers in the range 0-15535 having double-frequency than the numbers in the range 15536-49999.¶

NOTE:

For example, both an output of 10 and output of 50010 from the random() function will result in an 'id' value of 10.¶

This effect is reduced if the PRNG produces an output that is much longer than the length implied by the modulo operation.¶

Use of algorithms other than PRNGs for generating identifiers of this category is discouraged.¶

9.2. Category #2: Uniqueness (hard failure)

As noted in Section 7.2, this category can employ the same algorithms as Category #4, since a monotonically-increasing sequence tends to minimize the transient numeric identifier reuse frequency. Therefore, the vulnerability analysis in Section 9.4 also applies to this category.¶

Additionally, as noted in Section 7.2, some transient numeric identifiers of this category might be able to use the algorithms from Section 7.1, in which case the same considerations as in Section 9.1 would apply.¶

9.3. Category #3: Uniqueness, stable within context (soft failure)

Possible vulnerabilities associated with the algorithms from Section 7.3 are:¶

1. Use of weak PRFs, or inappropriate secret keys (whether inappropriate selection or inappropriate size) could allow for cryptanalysis, which could eventually be exploited by an attacker to predict future transient numeric identifiers.¶
2. Since the algorithm generates a unique and stable identifier within a specified context, it may allow for network activity correlation and fingerprinting within the specified context.¶

9.4. Category #4: Uniqueness, monotonically increasing within context (hard failure)

The algorithm described in Section 7.4.1 for generating identifiers of Category #4 will result in an identifiable pattern (i.e. a monotonically-increasing sequence) for the transient numeric identifiers generated for each CONTEXT, and thus will allow for fingerprinting and network activity correlation within each CONTEXT.¶

On the other hand, a simple way to generalize and analyze the algorithms described in Section 7.4.2 and Section 7.4.3 for generating identifiers of Category #4, is as follows:¶

    /* Transient Numeric ID selection function */

    id_range = max_id - min_id + 1;
    retry = id_range;
    id_inc = increment() % id_range;

    do {
        update_mono(CONTEXT, id_inc);
        next_id = min_id + (offset(CONTEXT) + \
                            mono(CONTEXT)) % id_range;

        if (suitable_id(next_id)) {
            return next_id;
        }

        retry = retry - id_inc;

    } while (retry > 0);

    return ERROR;

NOTE:

increment() returns a small integer that is employed to generate a monotonically-increasing function. Most implementations employ a constant value for "increment()" (usually 1). The value returned by increment() must be much smaller than the value computed for "id_range".¶

update_mono(CONTEXT, id_inc) increments the counter corresponding to CONTEXT by "id_inc".¶

mono(CONTEXT) reads the counter corresponding to CONTEXT.¶

Essentially, an identifier (next_id) is generated by adding a monotonically-increasing function (mono()) to an offset value, unknown to the attacker and stable for given context (CONTEXT).¶

The following aspects of the algorithm should be considered:¶

• For the most part, it is the offset() function that results in identifiers that are unpredictable by an off-patch attacker. While the resulting sequence is known to be monotonically-increasing, the use of a randomized offset value makes the resulting values unknown to the attacker.¶
• The most straightforward "stateless" implementation of offset() is with a PRF that takes the values that identify the context and a "secret_key" (not shown in the figure above) as arguments.¶
• One possible implementation of mono() would be to have mono() internally employ a single counter (as in the algorithm from Section 7.4.2), or map the increments for different contexts into a number of counters/buckets, such that the number of counters that need to be maintained in memory is reduced (as in the algorithm from algorithm in Section 7.4.3).¶
• In all cases, a monotonically increasing function is implemented by incrementing the previous value of a counter by increment() units. In the most trivial case, increment() could return the constant "1". But increment() could also be implemented to return small random integers such that the increments are unpredictable (see Appendix A of [RFC7739]). This represents a trade-off between the unpredictability of the resulting transient numeric IDs and the transient numeric ID reuse frequency.¶

Considering the generic algorithm illustrated above, we can identify the following possible vulnerabilities:¶

• Since the algorithms for this category are similar to those of Section 9.3, with the addition of a monotonically-increasing function, all the issues discussed in Section 9.3 ("Category #3: Uniqueness, stable within context (soft failure)") also apply to this case.¶
• mono() can be correlated to the number of identifiers generated for a given context (CONTEXT). Thus, if mono() spans more than the necessary context, the "increments" could be leaked to other parties, thus disclosing information about the number of identifiers that have been generated by the algorithm for all contexts. This is information disclosure becomes more evident when an implementation employs a constant increment of 1. For example, an implementation where mono() is actually a single global counter, will unnecessarily leak information the number of identifiers that have been generated by the algorithm (globally, for all contexts). [Fyodor2003] is one example of how such information leakages can be exploited. We note that limiting the span of the increments space will require a larger number of counters to be stored in memory (i.e., a larger value for the TABLE_LENGTH parameter of the algorithm in Section 7.4.3).¶
• Transient numeric identifiers generated with the algorithms described in Section 7.4.2 and Section 7.4.3 will normally allow for fingerprinting within CONTEXT since, for such context, the resulting identifiers will have an identifiable pattern (i.e. a monotonically-increasing sequence).¶

A.1. Predictable Linear Identifiers Algorithm

One of the most trivial ways to achieve uniqueness with a low identifier reuse frequency is to produce a linear sequence. This type of algorithm has been employed in the past to generate identifiers of Categories #1, #2, and #4 (please see Section 6 for an analysis of these categories).¶

For example, the following algorithm has been employed (see e.g. [Morris1985], [Shimomura1995], [Silbersack2005] and [CPNI-TCP]) in a number of operating systems for selecting IP fragment IDs, TCP ephemeral ports, etc.:¶

    /* Initialization code */

    next_id = min_id;
    id_inc= 1;


    /* Transient Numeric ID selection function */

    id_range = max_id - min_id + 1;
    retry = id_range;

    do {
        if (next_id == max_id) {
            next_id = min_id;
        }
        else {
            next_id = next_id + id_inc;
        }

        if (suitable_id(next_id)) {
            return next_id;
        }

        retry--;

    } while (retry > 0);

    return ERROR;

NOTE:

suitable_id() is a function that checks whether the resulting identifier is acceptable (e.g., whether it's in use, etc.).¶

For obvious reasons, this algorithm results in predictable sequences. Since a global counter is used to generate the transient numeric identifiers ("next_id" in the example above), an entity that learns one numeric identifier can infer past numeric identifiers and predict future values to be generated by the same algorithm. Since the value employed for the increments is known (such as "1" in this case), an attacker can sample two values, and learn the number of identifiers that have been were generated in-between the two sampled values. Furthermore, if the counter is initialized e.g. when the system its bootstrapped to some known value, the algorithm will leak additional information, such as the number of transmitted fragmented datagrams in the case of an IP ID generator [Sanfilippo1998a], or the system uptime in the case of TCP timestamps [TCPT-uptime].¶

A.2. Random-Increments Algorithm

This algorithm offers a middle ground between the algorithms that generate randomized transient numeric identifiers (such as those described in Section 7.1.1 and Section 7.1.2), and those that generate identifiers with a predictable monotonically-increasing function (see Appendix A.1).¶

    /* Initialization code */

    next_id = random();        /* Initialization value */
    id_rinc = 500;             /* Determines the trade-off */


    /* Transient Numeric ID selection function */

    id_range = max_id - min_id + 1;
    retry = id_range;


    do {
        /* Random increment */
        id_inc = (random() % id_rinc) + 1;

        if ( (max_id - next_id) >= id_inc){
            next_id = next_id + id_inc;
        }
        else {
            next_id = min_id + id_inc - (max_id - next_id);
        }

        if (suitable_id(next_id)) {
           return next_id;
        }

        retry = retry - id_inc;

    } while (retry > 0);

    return ERROR;

This algorithm aims at producing a global monotonically-increasing sequence of transient numeric identifiers, while avoiding the use of fixed increments, which would lead to trivially predictable sequences. The value "id_inc" allows for direct control of the trade-off between unpredictability and identifier reuse frequency. The smaller the value of "id_inc", the more similar this algorithm is to a predicable, global linear ID generation algorithm (as the one in Appendix A.1). The larger the value of "id_inc", the more similar this algorithm is to the algorithm described in Section 7.1.1 of this document.¶

When the identifiers wrap, there is a risk of collisions of transient numeric identifiers (i.e., identifier reuse). Therefore, "id_inc" should be selected according to the following criteria:¶

• It should maximize the wrapping time of the identifier space.¶
• It should minimize identifier reuse frequency.¶
• It should maximize unpredictability.¶

Clearly, these are competing goals, and the decision of which value of "id_inc" to use is a trade-off. Therefore, the value of "id_inc" is at times a configurable parameter so that system administrators can make the trade-off for themselves. We note that the alternative algorithms discussed throughout this document offer better interoperability, security and privacy properties than this algorithm, and hence implementation of this algorithm is discouraged.¶

A.3. Re-using Identifiers Across Different Contexts

Employing the same identifier across contexts in which stability is not required (i.e. overloading the semantics of transient numeric identifier) usually has negative security and privacy implications.¶

For example, in order to generate transient numeric identifiers of Category #2 or Category #3, an implementation or specification might be tempted to employ a source for the numeric identifiers which is known to provide unique values, but that may also be predictable or leak information related to the entity generating the identifier. This technique has been employed in the past for e.g. generating IPv6 IIDs by re-using the MAC address of the underlying network interface. However, as noted in [RFC7721] and [RFC7707], embedding link-layer addresses in IPv6 IIDs not only results in predictable values, but also leaks information about the manufacturer of the underlying network interface card, allows for network activity correlation, and makes address-based scanning attacks feasible.¶