Poor selection of transient numerical identifiers in protocols such as the TCP/IP suite has historically led to a number of attacks on implementations, ranging from Denial of Service (DoS) or data injection to information leakages that can be exploited by pervasive monitoring. Due diligence in the specification of transient numeric identifiers is required even when cryptographic techniques are employed, since these techniques might not mitigate all the associated issues. This document formally updates RFC 3552, incorporating requirements for transient numeric identifiers, to prevent flaws in future protocols and implementations.

This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9416.

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Networking protocols employ a variety of transient numeric identifiers for different protocol objects, such as IPv4 and IPv6 Identification values [RFC 0791] [RFC 8200], IPv6 Interface Identifiers (IIDs) [RFC 4291], transport-protocol ephemeral port numbers [RFC 6056], TCP Initial Sequence Numbers (ISNs) [RFC 9293], NTP Reference IDs (REFIDs) [RFC 5905], and DNS IDs [RFC 1035]. These identifiers typically have specific requirements (e.g., uniqueness during a specified period of time) that must be satisfied such that they do not result in negative interoperability implications, and an associated failure severity when such requirements are not met [RFC 9415]. For more than 30 years, a large number of implementations of IETF protocols have been subject to a variety of attacks, with effects ranging from Denial of Service (DoS) or data injection to information leakages that could be exploited for pervasive monitoring [RFC 7258]. The root cause of these issues has been, in many cases, the poor selection of transient numeric identifiers in such protocols, usually as a result of insufficient or misleading specifications. While it is generally trivial to identify an algorithm that can satisfy the interoperability requirements of a given transient numeric identifier, empirical evidence exists that doing so without negatively affecting the security and/or privacy properties of the aforementioned protocols is prone to error [RFC 9414]. For example, implementations have been subject to security and/or privacy issues resulting from:

• predictable IPv4 or IPv6 Identification values (e.g., see [Sanfilippo1998a], [RFC 6274], and [RFC 7739]),
• predictable IPv6 IIDs (e.g., see [RFC 7217], [RFC 7707], and [RFC 7721]),
• predictable transport-protocol ephemeral port numbers (e.g., see [RFC 6056] and [Silbersack2005]),
• predictable TCP Initial Sequence Numbers (ISNs) (e.g., see [Morris1985], [Bellovin1989], and [RFC 6528]),
• predictable initial timestamps in TCP timestamps options (e.g., see [TCPT-uptime] and [RFC 7323]), and
• predictable DNS IDs (see, e.g., [Schuba1993] and [Klein2007]).

Recent history indicates that, when new protocols are standardized or new protocol implementations are produced, the security and privacy properties of the associated transient numeric identifiers tend to be overlooked, and inappropriate algorithms to generate such identifiers are either suggested in the specifications or selected by implementers. As a result, advice in this area is warranted. We note that the use of cryptographic techniques for confidentiality and authentication might not eliminate all the issues associated with predictable transient numeric identifiers. Therefore, due diligence in the specification of transient numeric identifiers is required even when cryptographic techniques are employed. Section 3 provides an overview of common flaws in the specification of transient numeric identifiers. Section 4 provides an overview of common flaws in the generation of transient numeric identifiers and their associated security and privacy implications. Finally, Section 5 provides key guidelines for protocol designers.

Transient Numeric Identifier:

A data object in a protocol specification that can be used to definitely distinguish a protocol object (a datagram, network interface, transport-protocol endpoint, session, etc.) from all other objects of the same type, in a given context. Transient numeric identifiers are usually defined as a series of bits and represented using integer values. These identifiers are typically dynamically selected, as opposed to statically assigned numeric identifiers (e.g., see [IANA-PROT]). We note that different transient numeric identifiers may have additional requirements or properties depending on their specific use in a protocol. We use the term "transient numeric identifier" (or simply "numeric identifier" or "identifier" as short forms) as a generic term to refer to any data object in a protocol specification that satisfies the identification property stated above.

Failure Severity:

The interoperability consequences of a failure to comply with the interoperability requirements of a given identifier. Severity considers the worst potential consequence of a failure, determined by the system damage and/or time lost to repair the failure. In this document, we define two types of failure severity: "soft" and "hard".

Soft Failure:

A recoverable condition in which a protocol does not operate in the prescribed manner but normal operation can be resumed automatically in a short period of time. For example, a simple packet-loss event that is subsequently recovered with a retransmission can be considered a soft failure.

Hard Failure:

A non-recoverable condition in which a protocol does not operate in the prescribed manner or it operates with excessive degradation of service. For example, an established TCP connection that is aborted due to an error condition constitutes, from the point of view of the transport protocol, a hard failure, since it enters a state from which normal operation cannot be recovered.

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

Recent work on transient numeric identifier usage in protocol specifications and implementations [RFC 9414] [RFC 9415] revealed that most of the issues discussed in this document arise as a result of one of the following conditions:

• protocol specifications that under specify their transient numeric identifiers
• protocol specifications that over specify their transient numeric identifiers
• protocol implementations that simply fail to comply with the specified requirements

Both under specifying and over specifying transient numeric identifiers is hazardous. TCP local ports [RFC 0793], as well as DNS IDs [RFC 1035], were originally under specified, leading to implementations that resulted in predictable values and thus were vulnerable to numerous off-path attacks. Over specification, as for IPv6 Interface Identifiers (IIDs) [RFC 4291] and IPv6 Identification values [RFC 2460], left implementations unable to respond to security and privacy issues stemming from the mandated or recommended algorithms -- IPv6 IIDs need not expose privacy-sensitive link-layer addresses, and predictable IPv6 Fragment Header Identification values invite the same off-path attacks that plague TCP. Finally, there are protocol implementations that simply fail to comply with existing protocol specifications. That is, appropriate guidance is provided by the protocol specification (whether it be the core specification or an update to it), but an implementation simply fails to follow such guidance. For example, some popular operating systems still fail to implement transport-protocol port randomization, as specified in [RFC 6056]. Clear specification of the interoperability requirements for the transient numeric identifiers will help identify possible algorithms that could be employed to generate them and also make evident if such identifiers are being over specified. A protocol specification will usually also benefit from a vulnerability assessment of the transient numeric identifiers they specify to prevent the corresponding considerations from being overlooked.

This section briefly notes common flaws associated with the generation of transient numeric identifiers. Such common flaws include, but are not limited to:

• employing trivial algorithms (e.g., global counters) that result in predictable identifiers,
• employing the same identifier across contexts in which constancy is not required,
• reusing identifiers across different protocols or layers of the protocol stack,
• initializing counters or timers to constant values when such initialization is not required,
• employing the same increment space across different contexts, and
• use of flawed Pseudorandom Number Generators (PRNGs).

Employing trivial algorithms for generating the identifiers means that any node that is able to sample such identifiers can easily predict future identifiers employed by the victim node. When one identifier is employed across contexts where such constancy is not needed, activity correlation is made possible. For example, employing an identifier that is constant across networks allows for node tracking across networks. Reusing identifiers across different layers or protocols ties the security and privacy properties of the protocol reusing the identifier to the security and privacy properties of the original identifier (over which the protocol reusing the identifier may have no control regarding its generation). Besides, when reusing an identifier across protocols from different layers, the goal of isolating the properties of a layer from those of another layer is broken, and the vulnerability assessment may be harder to perform since the combined system, rather than each protocol in isolation, will have to be assessed. At times, a protocol needs to convey order information (whether it be sequence, timing, etc.). In many cases, there is no reason for the corresponding counter or timer to be initialized to any specific value, e.g., at system bootstrap. Similarly, there may not be a need for the difference between successive counter values to be predictable. A node that implements a per-context linear function may share the increment space among different contexts (please see the "Simple PRF-Based Algorithm" section in [RFC 9415]). Sharing the same increment space allows an attacker that can sample identifiers in other context to, e.g., learn how many identifiers have been generated between two sampled values. Finally, some implementations have been found to employ flawed PRNGs (e.g., see [Klein2007]).

Protocol specifications that employ transient numeric identifiers MUST explicitly specify the interoperability requirements for the aforementioned transient numeric identifiers (e.g., required properties such as uniqueness, along with the failure severity if such requirements are not met). A vulnerability assessment of the aforementioned transient numeric identifiers MUST be performed as part of the specification process. Such vulnerability assessment should cover, at least, spoofing, tampering, repudiation, information disclosure, DoS, and elevation of privilege. Protocol specifications SHOULD NOT employ predictable transient numeric identifiers, except when such predictability is the result of their interoperability requirements. Protocol specifications that employ transient numeric identifiers SHOULD recommend an algorithm for generating the aforementioned transient numeric identifiers that mitigates the vulnerabilities identified in the previous step, such as those discussed in [RFC 9415]. As discussed in Section 1, use of cryptographic techniques for confidentiality and authentication might not eliminate all the issues associated with predictable transient numeric identifiers. Therefore, the advice from this section MUST still be applied for cases where cryptographic techniques for confidentiality or authentication are employed.

This document has no IANA actions.

This entire document is about the security and privacy implications of transient numeric identifiers and formally updates [RFC 3552] such that the security and privacy implications of transient numeric identifiers are addressed when writing the "Security Considerations" section of future RFCs.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC3552]

E. Rescorla, and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[Bellovin1989]

S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", April 1989,
<https://www.cs.columbia.edu/~smb/papers/ipext.pdf>.

[IANA-PROT]

IANA, "Protocol Registries",
<https://www.iana.org/protocols>.

[Klein2007]

Trusteer, A. Klein, "OpenBSD DNS Cache Poisoning and Multiple O/S Predictable IP ID Vulnerability", October 2007,
<https://dl.packetstormsecurity.net/papers/attack/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf>.

[Morris1985]

R. Morris, "A Weakness in the 4.2BSD UNIX TCP/IP Software", February 1985,
<https://pdos.csail.mit.edu/~rtm/papers/117.pdf>.

[PREDICTABLE-NUMERIC-IDS]

Quarkslab, F. Gont, and I. Arce, "Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols", Internet-Draft draft-gont-predictable-numeric-ids-03, March 2019,
<https://datatracker.ietf.org/doc/html/draft-gont-predictable-numeric-ids-03>.

[RFC0791]

J. Postel, "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.

[RFC0793]

J. Postel, "Transmission Control Protocol", RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.

[RFC1035]

P. Mockapetris, "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987,
<https://www.rfc-editor.org/info/rfc1035>.

[RFC2460]

S. Deering, and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998,
<https://www.rfc-editor.org/info/rfc2460>.

[RFC4291]

R. Hinden, and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006,
<https://www.rfc-editor.org/info/rfc4291>.

[RFC5905]

D. Mills, J. Martin, J. Burbank, and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.

[RFC6056]

M. Larsen, and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011,
<https://www.rfc-editor.org/info/rfc6056>.

[RFC6274]

F. Gont, "Security Assessment of the Internet Protocol Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011,
<https://www.rfc-editor.org/info/rfc6274>.

[RFC6528]

F. Gont, and S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 2012,
<https://www.rfc-editor.org/info/rfc6528>.

[RFC7217]

F. Gont, "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.

[RFC7258]

S. Farrell, and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014,
<https://www.rfc-editor.org/info/rfc7258>.

[RFC7323]

D. Borman, B. Braden, V. Jacobson, and R. Scheffenegger, "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>.

[RFC7707]

F. Gont, and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
<https://www.rfc-editor.org/info/rfc7707>.

[RFC7721]

A. Cooper, F. Gont, and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>.

[RFC7739]

F. Gont, "Security Implications of Predictable Fragment Identification Values", RFC 7739, DOI 10.17487/RFC7739, February 2016,
<https://www.rfc-editor.org/info/rfc7739>.

[RFC8200]

S. Deering, and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.

[RFC9293]

W. Eddy, "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.

[RFC9414]

F Gont, and I Arce, "Unfortunate History of Transient Numeric Identifiers", RFC 9414, DOI 10.17487/RFC9414, July 2023,
<https://www.rfc-editor.org/info/rfc9414>.

[RFC9415]

F Gont, and I Arce, "On the Generation of Transient Numeric Identifiers", RFC 9415, DOI 10.17487/RFC9415, July 2023,
<https://www.rfc-editor.org/info/rfc9415>.

[Sanfilippo1998a]

S. Sanfilippo, "about the ip header id", December 1998,
<https://seclists.org/bugtraq/1998/Dec/48>.

[Schuba1993]

C. Schuba, "Addressing Weakness in the Domain Name System Protocol", August 1993,
<http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/schuba-DNS-msthesis.pdf>.

[Shostack2014]

A. Shostack, "Threat Modeling: Designing for Security", February 2014.

[Silbersack2005]

The FreeBSD Project, M. Silbersack, "Improving TCP/IP security through randomization without sacrificing interoperability", January 2005,
<http://www.silby.com/eurobsdcon05/eurobsdcon_silbersack.pdf>.

[TCPT-uptime]

Securiteam, B. McDanel, "TCP Timestamping - Obtaining System Uptime Remotely", March 2001,
<https://seclists.org/bugtraq/2001/Mar/182>.

The authors would like to thank (in alphabetical order) Bernard Aboba, Brian Carpenter, Roman Danyliw, Theo de Raadt, Lars Eggert, Russ Housley, Benjamin Kaduk, Charlie Kaufman, Erik Kline, Alvaro Retana, Joe Touch, Michael Tüxen, Robert Wilton, and Paul Wouters for providing valuable comments on draft versions of this document. The authors would like to thank (in alphabetical order) Steven Bellovin, Joseph Lorenzo Hall, and Gre Norcie for providing valuable comments on [PREDICTABLE-NUMERIC-IDS], on which the present document is based. The authors would like to thank Diego Armando Maradona for his magic and inspiration.

Fernando Gont

Ivan Arce