RFC 9414

Unfortunate History of Transient Numeric Identifiers

📅 published July 2023, from ietf

Unfortunate History of Transient Numeric Identifiers 🦋

RFC 9414, written by Fernando Gont (SI6 Networks) and Ivan Arce (Quarkslab), dated July 2023. It's an Informational RFC from the IRTF, published as a product of the Privacy Enhancements and Assessments Research Group (PEARG), with ISSN 2070-1721. The title block has no Obsoletes or Updates line, so it doesn't obsolete or update anything. 💜

Abstract ✨

Okay so this doc digs into the timeline of how different "transient numeric identifiers" got specified and implemented across IETF protocols. It also looks at how those choices messed with the security and privacy properties of those protocols. Spoiler: the receipts show that advice in this area is totally warranted. 🔥 It's a product of PEARG in the IRTF.

Status of This Memo 🌸

This one is not an Internet Standards Track specification, it's just published for informational purposes. 🎀

It's an IRTF product. The IRTF shares results of Internet-related research and development, and those results might not be ready for deployment. This RFC represents the consensus of PEARG in the IRTF. Documents approved by the IRSG are not candidates for any level of Internet Standard, see Section 2 of RFC 7841. 💅

Want errata, the current status, or a way to give feedback? Check https://www.rfc-editor.org/info/rfc9414. 🧚

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. Please actually read those, because they spell out your rights and restrictions for this doc. 🫶

Table of Contents 🍓

1.  Introduction
2.  Terminology
3.  Threat Model
4.  Issues with the Specification of Transient Numeric Identifiers
  4.1.  IPv4/IPv6 Identification
  4.2.  TCP Initial Sequence Numbers (ISNs)
  4.3.  IPv6 Interface Identifiers (IIDs)
  4.4.  NTP Reference IDs (REFIDs)
  4.5.  Transport-Protocol Ephemeral Port Numbers
  4.6.  DNS ID
5.  Conclusions
6.  IANA Considerations
7.  Security Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 💖

Networking protocols are full of transient numeric identifiers for all kinds of protocol objects. You've got IPv4 and IPv6 Identification values [RFC0791] [RFC8200], IPv6 Interface Identifiers (IIDs) [RFC4291], transport-protocol ephemeral port numbers [RFC6056], TCP Initial Sequence Numbers (ISNs) [RFC9293], NTP Reference IDs (REFIDs) [RFC5905], and DNS IDs [RFC1035]. These identifiers usually come with specific requirements, like uniqueness over a given period of time. If those requirements aren't met, you can end up with negative interoperability implications and a failure severity that's honestly bad news 😭 [RFC9415].

|  NOTE: Some documents refer to the DNS ID as the DNS "Query ID"
|  or "TxID".

For more than 30 years, a huge number of IETF protocol implementations have been hit with attacks. The fallout ranges from Denial of Service (DoS) and data injection to information leaks that could be used for pervasive monitoring [RFC7258]. In lots of cases, the root cause was poor selection of transient numeric identifiers, usually because the specs were insufficient or misleading. It's generally easy to find an algorithm that meets the interoperability requirements for one of these identifiers. The catch is that doing so without hurting security and/or privacy is super easy to mess up, and the empirical evidence proves it. 💀

Implementations have had security and/or privacy issues from:

  • predictable IPv4 or IPv6 Identification values (e.g., see [Sanfilippo1998a], [RFC6274], and [RFC7739]),
  • predictable IPv6 IIDs (e.g., see [RFC7217], [RFC7707], and [RFC7721]),
  • predictable transport-protocol ephemeral port numbers (e.g., see [RFC6056] and [Silbersack2005]),
  • predictable TCP Initial Sequence Numbers (ISNs) (e.g., see [Morris1985], [Bellovin1989], and [RFC6528]),
  • predictable initial timestamps in TCP timestamps options (e.g., see [TCPT-uptime] and [RFC7323]), and
  • predictable DNS IDs (see, e.g., [Schuba1993] and [Klein2007]).

Recent history shows a pattern 👀. When new protocols get standardized or new implementations get built, the security and privacy properties of these identifiers tend to get overlooked. Inappropriate algorithms to generate them either show up in the specs or get picked by implementers. That's exactly why advice in this area is warranted. 🫶

This doc has a non-exhaustive timeline of specs and vulnerability disclosures for some sample transient numeric identifiers, plus other work that pushed this area forward. The analysis shows that:

  • vulnerabilities from inappropriate generation of transient numeric identifiers have hit protocol implementations for an extremely long time,
  • those vulnerabilities, even when fixed for a given protocol version, were later reintroduced in new versions or new implementations of the same protocol, and
  • standardization efforts that discuss and give advice here can have a positive effect on IETF specs and their implementations. ✨

Yes, it's generally possible to find an algorithm that meets the interoperability requirements for a given identifier. But this doc gives empirical evidence that doing so without hurting the security and/or privacy properties of the protocols is nontrivial 🙈. Other related documents ([RFC9415] and [RFC9416]) give guidance in this area, motivated by this one.

This document represents the consensus of the Privacy Enhancements and Assessments Research Group (PEARG). 💜

2. Terminology 🎀

Transient Numeric Identifier: a data object in a protocol spec that can be used to definitively tell one protocol object (a datagram, network interface, transport-protocol endpoint, session, etc.) apart from all the other objects of the same type in a given context. These identifiers are usually defined as a series of bits and represented as integer values. They're typically picked dynamically, as opposed to statically assigned numeric identifiers (e.g., see [IANA-PROT]). Different transient numeric identifiers may have extra requirements or properties depending on how they're used in a protocol. This doc uses "transient numeric identifier" (or just "numeric identifier" or "identifier" for short) as a generic term for any data object in a protocol spec that satisfies the identification property above. 🦋

The terms "constant IID", "stable IID", and "temporary IID" are to be interpreted as defined in [RFC7721]. 💅

3. Threat Model 🔥

Throughout this document, we do not consider on-path attacks. 👀 We assume the attacker doesn't have physical or logical access to the systems being attacked, and that they can only observe traffic explicitly directed at them. The attacker also can't observe traffic moving between the sender and receiver(s) of a target protocol, but they may be able to interact with any of those entities. For example, they can send traffic to them to sample the transient numeric identifiers the target hosts use when talking to the attacker. 🧚

Take TCP ISNs. We consider that the attacker can't capture network traffic for a TCP connection between two other hosts. However, the attacker can talk to any of those hosts (e.g., establish a TCP connection with any of them) to sample the TCP ISNs those hosts use when communicating with the attacker. 🌸

Same vibe for host-tracking with IPv6 Interface Identifiers. We consider that an attacker may learn the IPv6 address a victim host uses if that address gets exposed when the victim talks to an attacker-operated server. After that, the attacker may host-track by probing a set of target addresses built from a set of target prefixes and the IPv6 Interface Identifier they originally learned. 🍓 Another route: the attacker may host-track if the victim talks to an attacker-operated server while moving from one location to another, which exposes its configured addresses. Note that none of these scenarios require the attacker to observe traffic that isn't explicitly directed at them. Not me being impressed by how low-key sneaky this is. 🙈💜

4. Issues with the Specification of Transient Numeric Identifiers ✨

okay so while we were checking IETF protocol specs for how they handle transient numeric identifiers 🎀, we noticed that most of the problems come down to one of three things:

  • 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

A bunch of IETF specs under specified their transient numeric identifiers 😬, which left implementations open to lots of off-path attacks. Examples include the TCP local ports in [RFC0793] and the DNS ID in [RFC1035].

🦋 NOTE: The TCP local port in an active OPEN request is commonly known as the "ephemeral port" of the corresponding TCP connection [RFC6056].

On the flip side, some specs go way too far and over specify some of their identifiers 🙈. For example, [RFC4291] basically overloads the meaning of IPv6 Interface Identifiers (IIDs) by embedding link-layer addresses in them, even though the uniqueness requirement for interoperability could be met in other ways that don't cause negative security and privacy implications [RFC7721]. Similarly, [RFC2460] suggests using a global counter to generate Identification values, when the uniqueness requirement per {IPv6 Source Address, IPv6 Destination Address} could be achieved with other algorithms that don't cause negative security and privacy implications [RFC7739]. Too much rigidity, bestie 💀.

And then there are implementations that just don't follow the existing specs at all 😭. For example, some popular operating systems still don't do transport-protocol ephemeral port randomization, even though [RFC6056] recommends it, or TCP Initial Sequence Number randomization, as recommended in [RFC9293].

The next subsections walk through the timelines of several sample transient numeric identifiers 📜. They show how this problem has hit protocols at different layers over time. These samples have different interoperability requirements and failure severities (see Section 6 of [RFC9415]), so they're good representatives of the problem we're analyzing in this document 💅.

4.1. IPv4/IPv6 Identification 🧚

This section lays out the timeline of the Identification field used by IPv4 (in the base header) and IPv6 (in Fragment Headers). We're presenting both in the same section to make it super clear that, even though the Identification value does the same job in both protocols, the work and research done for IPv4 did not influence the IPv6 specs or implementations 🫶.

The IPv4 Identification is specified in [RFC0791], which sets the interoperability requirements for the field. Basically, the sender must choose the Identification field to be unique for a given {Source Address, Destination Address, Protocol} for as long as the datagram (or any fragment of it) could be alive in the Internet. It suggests that a sending protocol module may keep "a table of Identifiers, one entry for each destination it has communicated with in the last maximum packet lifetime for the [I]nternet". It also says that "since the Identifier field allows 65,536 different values, hosts may be able to simply use unique identifiers independent of destination". People have read this as a suggestion to use per-destination or global counters for Identification values, like, many times 🔁. [RFC0791] doesn't suggest any flawed algorithm for generating Identification values, but it skips any discussion of the security and privacy implications of predictable Identification values. So a lot of IPv4 implementations ended up generating predictable Identification values with a global counter, at least at some point in time 😩.

The IPv6 Identification was originally specified in [RFC1883] 🎀. It does the same job as its IPv4 counterpart, but instead of living in the base header, it's part of the Fragment Header (which may or may not be in an IPv6 packet). Section 4.5 of [RFC1883] states that the Identification must be different than that of any other fragmented packet sent recently (within the maximum likely lifetime of a packet) with the same Source Address and Destination Address. Then it notes that this can be met with a wrap-around 32-bit counter that gets incremented each time a packet must be fragmented, and that it's an implementation choice whether to use a global or a per-destination counter. So the IPv6 spec is pretty similar to the IPv4 one, with the difference that the suggestion to use simple counters is more explicit 👀. [RFC2460] is the first revision of the core IPv6 specification and keeps the same text for the Identification field. Then [RFC8200], the second revision of the core IPv6 specification, removes the suggestion from [RFC2460] to use a counter for generating IPv6 Identification values, and points to [RFC7739] for sample algorithms to generate them ✨.

September 1981: [RFC0791] specifies the interoperability requirements for the IPv4 Identification but does not perform a vulnerability assessment of this transient numeric identifier.

December 1995: [RFC1883], the first specification of the IPv6 protocol, is published. It suggests that a counter be used to generate the IPv6 Identification values, and notes that it's an implementation choice whether to maintain a single counter for the node or multiple counters (e.g., one for each of the node's possible Source Addresses, or one for each active {Source Address, Destination Address} set) 🌸.

December 1998: [Sanfilippo1998a] finds that predictable IPv4 Identification values (as generated by most popular implementations) can be leveraged to count the number of packets sent by a target node. [Sanfilippo1998b] explains how to leverage the same vulnerability to implement a port-scanning technique known as "idle scan". A tool that implements this attack is publicly released 💀.

December 1998: [RFC2460], a revision of the IPv6 specification, is published, obsoleting [RFC1883]. It keeps the same specification of the IPv6 Identification field as its predecessor [RFC1883] 🙄.

December 1998: OpenBSD implements randomization of the IPv4 Identification field [OpenBSD-IPv4-ID] 🔥.

November 1999: [Sanfilippo1999] discusses how to leverage predictable IPv4 Identification values to uncover the rules of a number of firewalls 🕵️.

September 2002: [Fyodor2002] documents the implementation of the "idle scan" technique in the popular Network Mapper (nmap) tool 🍓.

November 2002: [Bellovin2002] explains how the IPv4 Identification field can be exploited to count the number of systems behind a NAT 👑.

October 2003: OpenBSD implements randomization of the IPv6 Identification field [OpenBSD-IPv6-ID] 🌈.

December 2003: [Zalewski2003] explains a technique to perform TCP data injection attacks based on predictable IPv4 Identification values, which requires less effort than TCP injection attacks performed with bare TCP packets 💜.

January 2005: [Silbersack2005] discusses shortcomings in a number of techniques to mitigate predictable IPv4 Identification values 🥲.

October 2007: [Klein2007] describes a weakness in the pseudorandom number generator (PRNG) used to generate IP Identification values by a number of operating systems 😵.

June 2011: [Gont2011] describes how to perform idle scan attacks in IPv6 ⭐.

November 2011: Linux mitigates predictable IPv6 Identification values [RedHat2011] [SUSE2011] [Ubuntu2011] 🫶.

December 2011: [draft-gont-6man-predictable-fragment-id-00] describes the security implications of predictable IPv6 Identification values and possible mitigations. This document has the intended status of "Standards Track", with the intention to formally update [RFC2460] to introduce security and privacy requirements on the generation of IPv6 Identification values 📝.

May 2012: [Gont2012] notes that some major IPv6 implementations still employ predictable IPv6 Identification values 😤.

March 2013: The 6man WG adopts [draft-gont-6man-predictable-fragment-id-03] but changes the track to "BCP" (while still formally updating [RFC2460]), posting the resulting document as [draft-ietf-6man-predictable-fragment-id-00] 🔄.

June 2013: A patch to incorporate support for IPv6-based idle scans in nmap is submitted [Morbitzer2013] 🛠️.

December 2014: The 6man WG changes the intended status of [draft-ietf-6man-predictable-fragment-id-01] to "Informational" and posts it as [draft-ietf-6man-predictable-fragment-id-02]. As a result, it no longer formally updates [RFC2460], and security and privacy requirements on the generation of IPv6 Identification values are eliminated 😱. Not it, honestly.

June 2015: [draft-ietf-6man-predictable-fragment-id-08] notes that some popular host and router implementations still employ predictable IPv6 Identification values 🥺.

February 2016: [RFC7739] (based on [draft-ietf-6man-predictable-fragment-id-10]) analyzes the security and privacy implications of predictable IPv6 Identification values and provides guidance for selecting an algorithm to generate such values. However, being published as an "Informational" RFC, it does not formally update [RFC2460] and does not introduce security and privacy requirements on the generation of IPv6 Identification values 🧐.

June 2016: [draft-ietf-6man-rfc2460bis-05], a draft revision of [RFC2460], removes the suggestion from [RFC2460] to use a counter for generating IPv6 Identification values. But it does not perform a vulnerability assessment of how IPv6 Identification values are generated, and it does not introduce security and privacy requirements on their generation 😮‍💨.

July 2017: [draft-ietf-6man-rfc2460bis-13] is finally published as [RFC8200], obsoleting [RFC2460] and pointing to [RFC7739] for sample algorithms for generating IPv6 Identification values. However, it does not introduce security and privacy requirements on the generation of IPv6 Identification values 🥱.

October 2019: [IPID-DEV] notes that the IPv6 Identification generators of two popular operating systems are flawed 🚩.

4.2. TCP Initial Sequence Numbers (ISNs) 🎀

okay bestie, so [RFC0793] says the ISN of a connection isn't just picked at random. It's meant to cut down the chances that a stale segment from an older incarnation of a connection gets accepted by a new one 👀. It even suggests a global 32-bit ISN generator that goes up by 1 roughly every 4 microseconds ⏱️. ngl though, what really keeps stale segments out is a different rule: a new incarnation of a previous connection can't be created until 2*MSL has passed since a segment from the old incarnation was last seen (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]). That's handled by the TIME-WAIT state and TCP's "quiet time" concept (see Appendix B of [RFC1323]) 🦋.

Here's where it gets iconic. Lots of stacks (e.g., 4.2BSD-derived ones) assume ISNs keep increasing across connections, so they use the ISN of an incoming SYN segment for "heuristics" that let a new incarnation get created while the old one is still sitting in TIME-WAIT (see p. 945 of [Wright1994]) 💅. This avoids an interoperability problem that can pop up when a node establishes connections to one specific TCP end-point at a high rate [Silbersack2005] 🫶.

The interoperability requirements for TCP ISNs are probably not as clearly spelled out as you'd expect 🙈. And the global counter suggested in [RFC0793] hurts the security and privacy properties of the protocol 💀.

September 1981: [RFC0793] suggests a global 32-bit ISN generator, whose lower bit is incremented roughly every 4 microseconds. But that kind of generator makes it trivial to predict the ISN a TCP implementation will use for new connections, which opens the door to a whole bunch of attacks against TCP 😭.

February 1985: [Morris1985] is the first to describe how to exploit predictable TCP ISNs to forge TCP connections, which could then be leveraged for trust relationship exploitation 🥀.

April 1989: [Bellovin1989] covers the security considerations for predictable ISNs, along with a bunch of other protocol-based vulnerabilities 🔥.

January 1995: [Shimomura1995] reports a real-world exploitation of the vulnerability described in [Morris1985], ten years after it was described in 1985 👀.

May 1996: [RFC1948] is the first IETF effort to tackle predictable TCP ISNs, and it was authored by Steven Bellovin 👑. Still, [RFC1948] does not formally update [RFC0793]. Note: the same concept this document specifies for TCP ISNs was later proposed for TCP ephemeral ports [RFC6056], TCP Timestamps, and eventually even IPv6 Interface Identifiers [RFC7217] 🌈.

July 1996: OpenBSD implements TCP ISN randomization based on random increments (please see Appendix A.2 of [RFC9415]) [OpenBSD-TCP-ISN-I] 🌸.

December 2000: OpenBSD implements TCP ISN randomization using simple randomization (please see Section 7.1 of [RFC9415]) [OpenBSD-TCP-ISN-R] ✨.

March 2001: [Zalewski2001] gives a detailed analysis of statistical weaknesses in some TCP ISN generators and surveys the algorithms popular TCP implementations were using. Vulnerability advisories [USCERT2001] were released about statistical weaknesses in some TCP ISN generators, affecting popular TCP implementations. Other advisories on the same vulnerability, such as [CERT2001], came out later 🚨.

March 2002: [Zalewski2002] updates and complements [Zalewski2001]. It concludes that "while some vendors [...] reacted promptly and tested their solutions properly, many still either ignored the issue and never evaluated their implementations, or implemented a flawed solution that apparently was not tested using a known approach" [Zalewski2002]. The vendors really did get called out 💅.

June 2007: OpenBSD implements TCP ISN randomization based on the algorithm specified in [RFC1948] (currently obsoleted and replaced by [RFC6528]) for the TCP endpoint doing the active open. It keeps the simple randomization scheme for the endpoint doing the passive open [OpenBSD-TCP-ISN-H]. This gives monotonically increasing ISNs for the "client side" (so the BSD heuristics work as expected) while avoiding any patterns in the ISN generation for the "server side" 🧚.

February 2012: [RFC6528], published 27 years after Morris's original work [Morris1985], formally updates [RFC0793] to mitigate predictable TCP ISNs. Finally 🎉.

August 2014: The algorithm specified in [RFC6528] becomes the recommended ("SHOULD") algorithm for TCP ISN generation in [draft-eddy-rfc793bis-04], an early revision of the core TCP specification [RFC9293] 🦋.

August 2022: [RFC9293], a revision of the core TCP specification, is published, adopting the algorithm specified in [RFC6528] as the recommended ("SHOULD") algorithm for TCP ISN generation 👑💖.

4.3. IPv6 Interface Identifiers (IIDs) 🌸

IPv6 Interface Identifiers can come from different mechanisms, including Stateless Address Autoconfiguration (SLAAC) [RFC4862], DHCPv6 [RFC8415], and manual configuration. This section focuses on the Interface Identifiers that result from SLAAC 🧚.

The Interface Identifier of stable IPv6 addresses resulting from SLAAC originally embedded the underlying link-layer address in the IID. Back then, using the link-layer address was seen as a convenient way to get a unique address 🙈. But recent awareness of the security and privacy properties of this approach [RFC7707] [RFC7721] led to swapping this flawed scheme for an alternative one [RFC7217] [RFC8064] that doesn't negatively affect the security and privacy properties of the protocol 🔥.

January 1997: [RFC2073] specifies the syntax of IPv6 global addresses (called "An IPv6 Provider-Based Unicast Address Format" at the time), which is consistent with the IPv6 addressing architecture specified in [RFC1884]. Hosts are recommended to "generate addresses using link-specific addresses as Interface ID such as 48 bit IEEE-802 MAC addresses" 🍓.

July 1998: [RFC2374] specifies "An IPv6 Aggregatable Global Unicast Address Format" (obsoleting [RFC2073]). It changes the size of the IID to 64 bits and specifies that IIDs must be constructed in IEEE 64-bit Extended Unique Identifier (EUI-64) format. How such identifiers are constructed is specified in the corresponding "IPv6 over <link>" specifications, such as "IPv6 over Ethernet" ✨.

January 2001: [RFC3041] recognizes the problem of IPv6 network activity correlation and specifies IPv6 temporary addresses. Temporary addresses are to be used along with stable addresses 🦋.

August 2003: [RFC3587] obsoletes [RFC2374], making the Top-Level Aggregator (TLA) / Next-Level Aggregator (NLA) structure historic. The syntax and recommendations for the stable IIDs stay unchanged 💅.

February 2006: [RFC4291] is published as the latest "IP Version 6 Addressing Architecture", requiring the IIDs of "all unicast addresses, except those that start with the binary value 000" to employ the Modified EUI-64 format. The details of constructing such interface identifiers are defined in the corresponding "IPv6 over <link>" specifications 👑.

March 2008: [RFC5157] provides hints about how patterns in IPv6 addresses could be leveraged for address scanning 👀.

December 2011: [draft-gont-6man-stable-privacy-addresses-00] notes that the original scheme for generating stable addresses allows for IPv6 address scanning and for active host tracking (even when IPv6 temporary addresses are employed). It also specifies an alternative algorithm meant to replace IIDs based on Modified EUI-64 format identifiers 🌈.

November 2012: The 6man WG adopts [draft-gont-6man-stable-privacy-addresses-01] as a working group item (as [draft-ietf-6man-stable-privacy-addresses-00]). However, the document no longer formally updates [RFC4291]. Therefore, the specified algorithm no longer formally replaces the Modified EUI-64 format identifiers 🥀.

February 2013: An address-scanning tool (scan6 of [IPv6-Toolkit]) that leverages IPv6 address patterns is released [Gont2013] 🔥.

July 2013: [draft-cooper-6man-ipv6-address-generation-privacy-00] elaborates on the security and privacy properties of all known algorithms for generating IPv6 IIDs 🧠.

January 2014: The 6man WG posts [draft-ietf-6man-default-iids-00] ("Recommendation on Stable IPv6 Interface Identifiers"), recommending [draft-ietf-6man-stable-privacy-addresses-17] for the generation of stable addresses 🫶.

April 2014: [RFC7217] (formerly [draft-ietf-6man-stable-privacy-addresses-17]) is published, specifying "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" as an alternative to (but not replacement of) Modified EUI-64 format IIDs ✨.

March 2016: [RFC7707] (formerly [draft-gont-opsec-ipv6-host-scanning-02] and later [draft-ietf-opsec-ipv6-host-scanning-08]), about "Network Reconnaissance in IPv6 Networks", is published 🔍.

March 2016: [RFC7721] (formerly [draft-cooper-6man-ipv6-address-generation-privacy-00] and later [draft-ietf-6man-ipv6-address-generation-privacy-08]), about "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", is published 💜.

May 2016: [draft-gont-6man-non-stable-iids-00] is posted, with the goal of specifying requirements for non-stable addresses and updating [RFC4941] so that use of only temporary addresses is allowed 🌸.

May 2016: [draft-gont-6man-address-usage-recommendations-00] is posted. It analyzes how different aspects of an address (from stability to usage mode) affect its security and privacy properties and meaning, with the goal of eventually providing advice in this area 🧚.

February 2017: [draft-ietf-6man-default-iids-16], produced by the 6man WG, is published as [RFC8064] ("Recommendation on Stable IPv6 Interface Identifiers"), with requirements for stable addresses and a recommendation to employ [RFC7217] for the generation of stable addresses. It formally updates a large number of RFCs 📜.

March 2018: [draft-fgont-6man-rfc4941bis-00] is posted (as suggested by the 6man WG) to address flaws in [RFC4941] by revising it. This is an alternative to the [draft-gont-6man-non-stable-iids-00] effort, posted in March 2016 🛠️.

July 2018: [draft-fgont-6man-rfc4941bis-00] is adopted (as [draft-ietf-6man-rfc4941bis-00]) as a WG item of the 6man WG 🎀.

December 2020: [draft-ietf-6man-rfc4941bis-12] is approved by the IESG for publication as an RFC 🥳.

February 2021: [draft-ietf-6man-rfc4941bis-12] is finally published as [RFC8981] 🎉💖

4.4. NTP Reference IDs (REFIDs) 🕰️

okay so the NTP [RFC5905] Reference ID is a 32-bit code that tells you which particular server or reference clock you're getting time from 🫶 Above stratum 1 (so the secondary servers and clients), this value can be used to avoid degree-one timing loops, which is when two NTP peers are (mutually) each other's time source 💀 like, they're just passing the time back and forth forever, no cap. If you're on the IPv4 address family, the identifier is the four-octet IPv4 address. If you're on the IPv6 address family, it's the first four octets of the MD5 hash of the IPv6 address 🔥

June 2010: [RFC5905] ("Network Time Protocol Version 4: Protocol and Algorithms Specification") gets published 🎀 It says that for NTP peers with stratum higher than 1, the REFID embeds the IPv4 address of the time source, or the first four octets of the MD5 hash of the IPv6 address of the time source ✨

July 2016: [draft-stenn-ntp-not-you-refid-00] gets posted, and it's all about the information leakage that happens through the NTP REFID 👀 It proposes that NTP returns a special REFID when a packet uses an IP Source Address that isn't believed to be a current NTP peer, but otherwise it still generates and returns the common REFID. It's later adopted by the NTP WG as [draft-ietf-ntp-refid-updates-00] 🌸

April 2019: [Gont-NTP] points out that the proposed fix in [draft-ietf-ntp-refid-updates-00] is, at the very least, sub-optimal 😭 Because the WG didn't get enough support, the [draft-ietf-ntp-refid-updates-00] effort is eventually abandoned 🥀

4.5. Transport-Protocol Ephemeral Port Numbers 🦋

okay so most (if not all) transport protocols use "port numbers" to demultiplex packets to the right transport-protocol instances 🧚 "Ephemeral ports" are the local ports used in active OPEN requests, which is typically the local port number on the side that starts the communication 💖

August 1980: [RFC0768] notes that the UDP source port is optional and identifies the port of the sending process 🌷 It doesn't specify interoperability requirements for source port selection, and it doesn't suggest ways to pick port numbers either. Most popular implementations end up picking source ports from a system-wide global counter 🙈

September 1981: [RFC0793] (the TCP specification) basically describes how port numbers are used, and says port numbers should result in a unique socket pair {local address, local port, remote address, remote port} 💅 How ephemeral ports get selected, and the range they're selected from, are left unspecified 🤷‍♀️

July 1996: OpenBSD implements ephemeral port randomization [OpenBSD-PR] 🎀✨

July 2008: The CERT Coordination Center publishes details of what became known as the "Kaminsky Attack" [VU-800113] [Kaminsky2008] on the DNS 😱 The attack takes advantage of the lack of ephemeral port randomization and DNS ID randomization in many major DNS implementations, so it can poison caches in an effective and practical way 💀

January 2009: [RFC5452] requires port randomization for DNS resolvers, and says implementations must randomize ports from the range of available ports (53 or 1024 and above) that is as large as possible and practicable 🔥 It doesn't recommend specific algorithms for port randomization, although it specifically targets DNS resolvers, where simple port randomization is enough (e.g., Algorithm 1 of [RFC6056]) 🧠 This document led to port randomization being implemented in the DNS resolvers themselves, rather than in the underlying transport protocols 🫶

January 2011: [RFC6056] notes that lots of TCP and UDP implementations end up with predictable ephemeral port numbers, and that many implementations pick port numbers from a small part of the whole port number space 😤 It recommends implementing and using ephemeral port randomization, proposes a number of possible algorithms for it, and recommends randomizing port numbers over the range 1024-65535 👑

March 2016: [NIST-NTP] reports a non-normal distribution of the ephemeral port numbers used by the NTP clients of an Internet Time Service 📊

April 2019: [draft-gont-ntp-port-randomization-00] notes that some NTP implementations use the NTP service port (123) as the local port for nonsymmetric modes, and it aims to update the NTP specification to recommend port randomization in such cases, which lines up with [RFC6056] 🌈 The proposal gets some pushback in the relevant working group (NTP WG) [NTP-PORTR], but it's finally adopted as a working group item as [draft-ietf-ntp-port-randomization-00] ✨

August 2021: [draft-ietf-ntp-port-randomization-08] is finally published as [RFC9109] 🎉💜

4.6. DNS ID 🌸

The DNS ID [RFC1035] can be used to match DNS replies to outstanding DNS queries 💖

NOTE: Some documents refer to the DNS ID as the DNS "Query ID" or "TxID" 📝

November 1987: [RFC1035] specifies that the DNS ID is a 16-bit identifier assigned by the program that generates any kind of query, that this identifier is copied into the corresponding reply, and that the requester can use it to match up replies to outstanding queries 🎀 It doesn't specify interoperability requirements for this numeric identifier, and it doesn't suggest an algorithm for generating it 🤷‍♀️

August 1993: [Schuba1993] describes DNS cache poisoning attacks that require the attacker to guess the DNS ID 😬

June 1995: [Vixie1995] suggests that both the UDP source port and the DNS ID of query packets should be randomized, although that might not provide enough entropy to stop an attacker from guessing these values 🎲

April 1997: [Arce1997] finds that implementations use predictable UDP source ports and predictable DNS IDs, and argues that both should be randomized 🙈

November 2002: [Sacramento2002] finds that, by spoofing multiple requests for the same domain name from different IP addresses, an attacker may guess the DNS ID used for a victim with a high probability of success, which allows DNS cache poisoning attacks 😱

March 2007: [Klein2007c] finds that the Microsoft Windows DNS server generates predictable DNS ID values 💀

July 2007: [Klein2007b] finds that a popular DNS server software (BIND 9), which does randomize the DNS ID, is still vulnerable to DNS cache poisoning attacks by forging a large number of queries and leveraging the birthday paradox 🫠

October 2007: [Klein2007] finds that OpenBSD's DNS software (based on the BIND DNS server of the Internet Systems Consortium (ISC)) generates predictable DNS ID values 😤

January 2009: [RFC5452] is published, requiring resolvers to randomize the DNS ID of queries and to verify that the DNS ID of a reply matches that of the DNS query as part of the DNS reply validation process 🔥

May 2010: [Economou2010] finds that the Windows SMTP Service implements its own DNS resolver, which results in predictable DNS ID values 💅 On top of that, it fails to validate that the DNS ID of a reply matches that of the DNS query that supposedly prompted it 😭

5. Conclusions ✨

For more than 30 years, a lot of implementations of IETF protocols have been hit by all kinds of attacks, with effects ranging from Denial of Service (DoS) or data injection to information leakages that could be exploited for pervasive monitoring [RFC7258] 😭 The root cause of these issues has, in many cases, been the poor selection of transient numeric identifiers in such protocols, usually because of insufficient or misleading specifications 💀

While it's generally possible to find an algorithm that can satisfy the interoperability requirements for a given transient numeric identifier, this document provides empirical evidence that doing so without negatively affecting the security and/or privacy properties of the aforementioned protocols is nontrivial 🧐 So it's pretty clear that advice in this area is warranted 👑

[RFC9416] aims at requiring future IETF protocol specifications to contain analysis of the security and privacy properties of any transient numeric identifiers the protocol specifies, and to recommend an algorithm for generating those identifiers 🫶 [RFC9415] specifies a number of sample algorithms for generating transient numeric identifiers with specific interoperability requirements and failure severities 🎀

6. IANA Considerations 🌷

This document has no IANA actions 🙌

7. Security Considerations 🔐

This document analyzes the timeline of the specification and implementation of the transient numeric identifiers of some sample IETF protocols, and how the security and privacy properties of those protocols have been affected as a result 😱 It provides concrete evidence that advice in this area is warranted 🔥

[RFC9415] analyzes and categorizes transient numeric identifiers based on their interoperability requirements and their associated failure severities, and recommends possible algorithms that can be used to comply with those requirements without negatively affecting the security and privacy properties of the corresponding protocols 🧠

[RFC9416] formally requires IETF protocol specifications to specify the interoperability requirements for their transient numeric identifiers, to do a warranted vulnerability assessment of such identifiers, and to recommend possible algorithms for generating them, so that the interoperability requirements are complied with while any negative security or privacy properties of these identifiers are mitigated 👑💜

8. References 📚

8.1. Normative References 📚✨

Okay bestie, these are the docs the spec totally leans on, so they're the ones you need to actually read 🫶

[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.

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

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

[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 1992, <https://www.rfc-editor.org/info/rfc1323>.

[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883, December 1995, <https://www.rfc-editor.org/info/rfc1883>.

[RFC1884] Hinden, R., Ed. and S. Deering, Ed., "IP Version 6 Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884, December 1995, <https://www.rfc-editor.org/info/rfc1884>.

[RFC2073] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J. Postel, "An IPv6 Provider-Based Unicast Address Format", RFC 2073, DOI 10.17487/RFC2073, January 1997, <https://www.rfc-editor.org/info/rfc2073>.

[RFC2374] Hinden, R., O'Dell, M., and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, DOI 10.17487/RFC2374, July 1998, <https://www.rfc-editor.org/info/rfc2374>.

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

[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, DOI 10.17487/RFC3041, January 2001, <https://www.rfc-editor.org/info/rfc3041>.

[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, August 2003, <https://www.rfc-editor.org/info/rfc3587>.

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

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.

[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>.

[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, DOI 10.17487/RFC5452, January 2009, <https://www.rfc-editor.org/info/rfc5452>.

[RFC6056] Larsen, M. 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>.

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

[RFC7217] Gont, F., "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>.

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

[RFC8200] Deering, S. 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>.

[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.

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

8.2. Informative References 🔍💅

These ones are the extra reading for the nerdy-but-iconic deep dive 🧚

[Arce1997] Arce, I. and E. Kargieman, "BIND Vulnerabilities and Solutions", April 1997, <http://www.openbsd.org/advisories/sni_12_resolverid.txt>.

[Bellovin1989] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", Computer Communications Review, vol. 19, no. 2, pp. 32-48, April 1989, <https://www.cs.columbia.edu/~smb/papers/ipext.pdf>.

[Bellovin2002] Bellovin, S., "A Technique for Counting NATted Hosts", IMW'02, Marseille, France, DOI 10.1145/637201.637243, November 2002, <https://www.cs.columbia.edu/~smb/papers/fnat.pdf>.

[CERT2001] CERT/CC, "CERT Advisory CA-2001-09: Statistical Weaknesses in TCP/IP Initial Sequence Numbers", May 2001, <https://resources.sei.cmu.edu/asset_files/WhitePaper/2001_019_001_496192.pdf>.

[draft-cooper-6man-ipv6-address-generation-privacy-00] Cooper, A., Gont, F., and D. Thaler, "Privacy Considerations for IPv6 Address Generation Mechanisms", Work in Progress, Internet-Draft, draft-cooper-6man-ipv6-address-generation-privacy-00, 15 July 2013, <https://www.ietf.org/archive/id/draft-cooper-6man-ipv6-address-generation-privacy-00.txt>.

[draft-eddy-rfc793bis-04] Eddy, W., Ed., "Transmission Control Protocol Specification", Work in Progress, Internet-Draft, draft-eddy-rfc793bis-04, 25 August 2014, <https://www.ietf.org/archive/id/draft-eddy-rfc793bis-04.txt>.

[draft-fgont-6man-rfc4941bis-00] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", Work in Progress, Internet-Draft, draft-fgont-6man-rfc4941bis-00, 25 March 2018, <https://www.ietf.org/archive/id/draft-fgont-6man-rfc4941bis-00.txt>.

[draft-gont-6man-address-usage-recommendations-00] Gont, F. and W. LIU, "IPv6 Address Usage Recommendations", Work in Progress, Internet-Draft, draft-gont-6man-address-usage-recommendations-00, 27 May 2016, <https://www.ietf.org/archive/id/draft-gont-6man-address-usage-recommendations-00.txt>.

[draft-gont-6man-non-stable-iids-00] Gont, F. and W. Liu, "Recommendation on Non-Stable IPv6 Interface Identifiers", Work in Progress, Internet-Draft, draft-gont-6man-non-stable-iids-00, 23 May 2016, <https://www.ietf.org/archive/id/draft-gont-6man-non-stable-iids-00.txt>.

[draft-gont-6man-predictable-fragment-id-00] Gont, F., "Security Implications of Predictable Fragment Identification Values", Work in Progress, Internet-Draft, draft-gont-6man-predictable-fragment-id-00, 15 December 2011, <https://www.ietf.org/archive/id/draft-gont-6man-predictable-fragment-id-00.txt>.

[draft-gont-6man-predictable-fragment-id-03] Gont, F., "Security Implications of Predictable Fragment Identification Values", Work in Progress, Internet-Draft, draft-gont-6man-predictable-fragment-id-03, 9 January 2013, <https://www.ietf.org/archive/id/draft-gont-6man-predictable-fragment-id-03.txt>.

[draft-gont-6man-stable-privacy-addresses-00] Gont, F., "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)", Work in Progress, Internet-Draft, draft-gont-6man-stable-privacy-addresses-00, 15 December 2011, <https://www.ietf.org/archive/id/draft-gont-6man-stable-privacy-addresses-00.txt>.

[draft-gont-6man-stable-privacy-addresses-01] Gont, F., "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)", Work in Progress, Internet-Draft, draft-gont-6man-stable-privacy-addresses-01, 31 March 2012, <https://www.ietf.org/archive/id/draft-gont-6man-stable-privacy-addresses-01.txt>.

[draft-gont-ntp-port-randomization-00] Gont, F. and G. Gont, "Port Randomization in the Network Time Protocol Version 4", Work in Progress, Internet-Draft, draft-gont-ntp-port-randomization-00, 16 April 2019, <https://www.ietf.org/archive/id/draft-gont-ntp-port-randomization-00.txt>.

[draft-gont-opsec-ipv6-host-scanning-02] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", Work in Progress, Internet-Draft, draft-gont-opsec-ipv6-host-scanning-02, 23 October 2012, <https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-host-scanning-02.txt>.

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

[draft-ietf-6man-default-iids-00] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", Work in Progress, Internet-Draft, draft-ietf-6man-default-iids-00, 24 January 2014, <https://www.ietf.org/archive/id/draft-ietf-6man-default-iids-00.txt>.

[draft-ietf-6man-default-iids-16] Gont, F., Cooper, A., Thaler, D., and W. LIU, "Recommendation on Stable IPv6 Interface Identifiers", Work in Progress, Internet-Draft, draft-ietf-6man-default-iids-16, 28 September 2016, <https://www.ietf.org/archive/id/draft-ietf-6man-default-iids-16.txt>.

[draft-ietf-6man-ipv6-address-generation-privacy-08] Cooper, A., Gont, F., and D. Thaler, "Privacy Considerations for IPv6 Address Generation Mechanisms", Work in Progress, Internet-Draft, draft-ietf-6man-ipv6-address-generation-privacy-08, 23 September 2015, <https://www.ietf.org/archive/id/draft-ietf-6man-ipv6-address-generation-privacy-08.txt>.

[draft-ietf-6man-predictable-fragment-id-00] Gont, F., "Security Implications of Predictable Fragment Identification Values", Work in Progress, Internet-Draft, draft-ietf-6man-predictable-fragment-id-00, 22 March 2013, https://www.ietf.org/archive/id/draft-ietf-6man-predictable-fragment-id-00.txt.

[draft-ietf-6man-predictable-fragment-id-01] Gont, F., "Security Implications of Predictable Fragment Identification Values", Work in Progress, Internet-Draft, draft-ietf-6man-predictable-fragment-id-01, 29 April 2014, https://www.ietf.org/archive/id/draft-ietf-6man-predictable-fragment-id-01.txt.

[draft-ietf-6man-predictable-fragment-id-02] Gont, F., "Security Implications of Predictable Fragment Identification Values", Work in Progress, Internet-Draft, draft-ietf-6man-predictable-fragment-id-02, 19 December 2014, https://datatracker.ietf.org/doc/html/draft-ietf-6man-predictable-fragment-id-02.

[draft-ietf-6man-predictable-fragment-id-08] Gont, F., "Security Implications of Predictable Fragment Identification Values", Work in Progress, Internet-Draft, draft-ietf-6man-predictable-fragment-id-08, 9 June 2015, https://www.ietf.org/archive/id/draft-ietf-6man-predictable-fragment-id-08.txt.

[draft-ietf-6man-predictable-fragment-id-10] Gont, F., "Security Implications of Predictable Fragment Identification Values", Work in Progress, Internet-Draft, draft-ietf-6man-predictable-fragment-id-10, 9 October 2015, https://www.ietf.org/archive/id/draft-ietf-6man-predictable-fragment-id-10.txt.

[draft-ietf-6man-rfc2460bis-05] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", Work in Progress, Internet-Draft, draft-ietf-6man-rfc2460bis-05, 28 June 2016, https://www.ietf.org/archive/id/draft-ietf-6man-rfc2460bis-05.txt.

[draft-ietf-6man-rfc2460bis-13] Deering, S. and R. Hinden, "draft-ietf-6man-rfc2460bis-13", Work in Progress, Internet-Draft, draft-ietf-6man-rfc2460bis-13, 19 May 2017, https://www.ietf.org/archive/id/draft-ietf-6man-rfc2460bis-13.txt.

[draft-ietf-6man-rfc4941bis-00] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", Work in Progress, Internet-Draft, draft-ietf-6man-rfc4941bis-00, 2 July 2018, https://www.ietf.org/archive/id/draft-ietf-6man-rfc4941bis-00.txt.

[draft-ietf-6man-rfc4941bis-12] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", Work in Progress, Internet-Draft, draft-ietf-6man-rfc4941bis-12, 2 November 2020, https://www.ietf.org/archive/id/draft-ietf-6man-rfc4941bis-12.txt.

[draft-ietf-6man-stable-privacy-addresses-00] Gont, F., "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)", Work in Progress, Internet-Draft, draft-ietf-6man-stable-privacy-addresses-00, 18 May 2012, https://www.ietf.org/archive/id/draft-ietf-6man-stable-privacy-addresses-00.txt.

[draft-ietf-6man-stable-privacy-addresses-17] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", Work in Progress, Internet-Draft, draft-ietf-6man-stable-privacy-addresses-17, 27 January 2014, https://www.ietf.org/archive/id/draft-ietf-6man-stable-privacy-addresses-17.txt.

[draft-ietf-ntp-port-randomization-00] Gont, F., Gont, G., and M. Lichvar, "Port Randomization in the Network Time Protocol Version 4", Work in Progress, Internet-Draft, draft-ietf-ntp-port-randomization-00, 22 October 2019, https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-00.txt.

[draft-ietf-ntp-port-randomization-08] Gont, F., Gont, G., and M. Lichvar, "Port Randomization in the Network Time Protocol Version 4", Work in Progress, Internet-Draft, draft-ietf-ntp-port-randomization-00, 10 June 2021, https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-08.txt.

[draft-ietf-ntp-refid-updates-00] Stenn, H. and S. Goldberg, "Network Time Protocol REFID Updates", Work in Progress, Internet-Draft, draft-ietf-ntp-refid-updates-00, 13 November 2016, https://www.ietf.org/archive/id/draft-ietf-ntp-refid-updates-00.txt.

[draft-ietf-opsec-ipv6-host-scanning-08] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", Work in Progress, Internet-Draft, draft-ietf-opsec-ipv6-host-scanning-08, 28 August 2015, https://www.ietf.org/archive/id/draft-ietf-opsec-ipv6-host-scanning-08.txt.

[draft-stenn-ntp-not-you-refid-00] Goldberg, S. and H. Stenn, "Network Time Protocol Not You REFID", Work in Progress, Internet-Draft, draft-stenn-ntp-not-you-refid-00, 8 July 2016, https://www.ietf.org/archive/id/draft-stenn-ntp-not-you-refid-00.txt.

[Economou2010] Economou, N., "Windows SMTP Service DNS query Id vulnerabilities", Advisory ID Internal CORE-2010-0427, May 2010, https://www.coresecurity.com/core-labs/advisories/core-2010-0424-windows-smtp-dns-query-id-bugs.

[Fyodor2002] Fyodor, "Idle scanning and related IP ID games", September 2002, https://nmap.org/presentations/CanSecWest03/CD_Content/idlescan_paper/idlescan.html.

[Gont-NTP] Gont, F., "[Ntp] Comments on draft-ietf-ntp-refid-updates-05", message to the IETF NTP mailing list, 16 April 2019, https://mailarchive.ietf.org/arch/msg/ntp/NkfTHxUUOdp14Agh3h1IPqfcRRg.

[Gont2011] Gont, F., "Hacking IPv6 Networks (training course)", Hack In Paris 2011 Conference, Paris, France, June 2011, https://www.si6networks.com/files/presentations/hip2011/fgont-hip2011-hacking-ipv6-networks.pdf.

[Gont2012] Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012 Conference, Ottawa, Canada, May 2012, https://www.si6networks.com/files/presentations/bsdcan2012/fgont-bsdcan2012-recent-advances-in-ipv6-security.pdf.

[Gont2013] Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit (help wanted!)", message to the IPv6 Hackers mailing list, 11 February 2013, https://lists.si6networks.com/pipermail/ipv6hackers/2013-February/000947.html.

[IANA-PROT] IANA, "Protocol Registries", https://www.iana.org/protocols.

[IPID-DEV] Klein, A. and B. Pinkas, "From IP ID to Device ID and KASLR Bypass (Extended Version)", DOI 10.48550/arXiv.1906.10478, October 2019, https://arxiv.org/pdf/1906.10478.pdf.

[IPv6-Toolkit] SI6 Networks, "IPv6 Toolkit", https://www.si6networks.com/tools/ipv6toolkit.

[Kaminsky2008] Kaminsky, D., "Black Ops 2008: It's The End Of The Cache As We Know It", August 2008, https://www.blackhat.com/presentations/bh-jp-08/bh-jp-08-Kaminsky/BlackHat-Japan-08-Kaminsky-DNS08-BlackOps.pdf.

[Klein2007] Klein, A., "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.

[Klein2007b] Klein, A., "BIND 9 DNS Cache Poisoning", March 2007, https://citeseerx.ist.psu.edu/doc/10.1.1.86.4474.

[Klein2007c] Klein, A., "Windows DNS Server Cache Poisoning", March 2007, https://dl.packetstormsecurity.net/papers/attack/Windows_DNS_Cache_Poisoning.pdf.

[Morbitzer2013] Morbitzer, M., "[PATCH] TCP Idle Scan in IPv6", message to the nmap-dev mailing list, 3 June 2013, https://seclists.org/nmap-dev/2013/q2/394.

[Morris1985] Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, NJ, February 1985, https://pdos.csail.mit.edu/~rtm/papers/117.pdf.

[NIST-NTP] Sherman, J. and J. Levine, "Usage Analysis of the NIST Internet Time Service", Journal of Research of the National Institute of Standards and Technology, Volume 121, March 2016, https://tf.nist.gov/general/pdf/2818.pdf.

[NTP-PORTR] Gont, F., "[Ntp] New rev of the NTP port randomization I-D (Fwd: New Version Notification for draft-gont-ntp-port-randomization-01.txt)", message to the IETF NTP mailing list, 21 May 2019, https://mailarchive.ietf.org/arch/msg/ntp/xSCu5Vhb3zoWcqEjUMmzP8pOdW4/.

[OpenBSD-IPv4-ID] OpenBSD, "Randomization of the IPv4 Identification field", December 1998, https://cvsweb.openbsd.org/src/sys/netinet/ip_id.c?rev=1.1.

[OpenBSD-IPv6-ID] OpenBSD, "Randomization of the IPv6 Identification field", October 2003, https://cvsweb.openbsd.org/src/sys/netinet6/ip6_id.c?rev=1.1.

[OpenBSD-PR] OpenBSD, "Implementation of port randomization", July 1996, https://cvsweb.openbsd.org/src/sys/netinet/in_pcb.c?rev=1.6.

[OpenBSD-TCP-ISN-H] OpenBSD, "Implementation of RFC1948 for TCP ISN randomization", June 2007, https://cvsweb.openbsd.org/src/sys/netinet/tcp_subr.c?rev=1.97.

[OpenBSD-TCP-ISN-I] OpenBSD, "Implementation of TCP ISN randomization based on random increments", July 1996, https://cvsweb.openbsd.org/src/sys/netinet/tcp_subr.c?rev=1.6.

[OpenBSD-TCP-ISN-R] OpenBSD, "Implementation of TCP ISN randomization based on simple randomization", December 2000, https://cvsweb.openbsd.org/src/sys/netinet/tcp_subr.c?rev=1.37.

[RedHat2011] Red Hat, "RHSA-2011:1465-1 - Security Advisory", November 2011, https://rhn.redhat.com/errata/RHSA-2011-1465.html.

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

[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, DOI 10.17487/RFC1948, May 1996, https://www.rfc-editor.org/info/rfc1948.

Acknowledgements ✨🫶

The authors would like to thank (in alphabetical order) Bernard Aboba, Dave Crocker, Spencer Dawkins, Theo de Raadt, Sara Dickinson, Guillermo Gont, Christian Huitema, Colin Perkins, Vincent Roca, Kris Shrishak, Joe Touch, Brian Trammell, and Christopher Wood for giving valuable comments on earlier versions of this document. 💖

The authors would also like to thank (in alphabetical order) Steven Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson for giving valuable comments on [draft-gont-predictable-numeric-ids-03], which this document is based on. 🙌

Section 4.2 of this document borrows text from [RFC6528], authored by Fernando Gont and Steven Bellovin. 📝

The authors would like to thank Sara Dickinson and Christopher Wood for their guidance during the publication process of this document. 🌸

The authors would like to thank Diego Armando Maradona for his magic and inspiration. ⚽👑

Authors' Addresses 🦋

Fernando Gont 💅

Fernando Gont
SI6 Networks
Segurola y Habana
4310 7mo piso
Ciudad Autonoma de Buenos Aires
Argentina
Email: fgont@si6networks.com
URI:   https://www.si6networks.com

Ivan Arce 🎀

Ivan Arce
Quarkslab
Segurola y Habana
4310 7mo piso
Ciudad Autonoma de Buenos Aires
Argentina
Email: iarce@quarkslab.com
URI:   https://www.quarkslab.com

That's the whole spec, bestie!! 🌈✨ 💜

📦 where this page comes from