RFC 9416

Security Considerations for Transient Numeric Identifiers Employed in Network Protocols

📅 published July 2023, from ietf

Title Block: RFC 9416 💖

Okay bestie, let's start with the basics because the title block is giving us all the context 🎀. This is RFC 9416, written by F. Gont (SI6 Networks) and I. Arce (Quarkslab). It's a Best Current Practice, which is the IETF's "please, everyone, do this" tier 🫶. It was published in July 2023, and it's part of the BCP 72 series 🦋. It Updates: 3552, so it's a formal update to RFC 3552 ✨. It does not obsolete anything. The ISSN is 2070-1721 🌸.

The actual title is: Security Considerations for Transient Numeric Identifiers Employed in Network Protocols 💅

Abstract ✨

Okay so the abstract says that picking bad transient numeric identifiers in protocols like the TCP/IP suite has led to a whole bunch of attacks over the years 😭. We're talking Denial of Service (DoS), data injection, and information leaks that can get exploited for pervasive monitoring 💀. Due diligence matters when you specify these identifiers, even if you're using cryptography, because crypto might not fix every single issue 🙈. This document formally updates RFC 3552 to add requirements for transient numeric identifiers, so future protocols and implementations don't repeat the same mistakes 💜.

Status of This Memo ✨

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 went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 👑. If you want more on BCPs, check out Section 2 of RFC 7841 🌈.

For the current status, any errata, and how to give feedback, go to 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) as they stood on the date of publication 📜. Please actually read these, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include the Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Revised BSD License describes 🫶.

Table of Contents 🦋

1.  Introduction
2.  Terminology
3.  Issues with the Specification of Transient Numeric Identifiers
4.  Common Flaws in the Generation of Transient Numeric Identifiers
5.  Requirements for Transient Numeric Identifiers
6.  IANA Considerations
7.  Security Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🌸

Okay so networking protocols use a ton of transient numeric identifiers for different protocol objects 🧚. Some examples: 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 have specific requirements (like being unique over a certain period of time) that have to be met so they don't cause negative interoperability problems. There's also an associated failure severity when those requirements get missed [RFC9415] 😭.

NOTE: Some documents call the DNS ID the DNS "Query ID" or "TxID". Same energy, different name 🙈.

For more than 30 years, a bunch of IETF protocol implementations have been hit by attacks, ranging from Denial of Service (DoS) and data injection to info leaks that could get exploited for pervasive monitoring [RFC7258] 💀. The root cause in lots of cases? 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 an identifier. But doing that without hurting the security and/or privacy properties of these protocols is super easy to mess up, according to the empirical evidence [RFC9414] 🔥.

For example, 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 that when new protocols get standardized or new implementations get built, the security and privacy properties of these identifiers tend to get overlooked 😭. Then inappropriate algorithms either get suggested in the specs or picked by implementers. That's why this advice is needed 🎀.

Cryptography for confidentiality and authentication might not clear up every issue with predictable transient numeric identifiers 🙈. So due diligence in specifying them is still required, even when crypto is in use 💅.

NOTE: For example, cryptographic authentication can readily mitigate data injection attacks even when identifiers are predictable (like "sequence numbers"). But using flawed algorithms (like global counters) to generate these identifiers can still cause information leaks, even with crypto in place. Those leaks can then be used to pull off other devastating attacks (see [RFC9415] for more) 💀.

Section 3 gives an overview of common flaws in the specification of transient numeric identifiers 📜. Section 4 covers common flaws in how they get generated, plus their security and privacy implications 🦋. Finally, Section 5 has key guidelines for protocol designers 👑.

2. Terminology ✨

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. These are usually defined as a series of bits and represented as integer values. They're typically selected 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. We use "transient numeric identifier" (or just "numeric identifier" or "identifier" for short) as a generic term for any data object in a protocol specification that meets the identification property above 💜.

Failure Severity: The interoperability consequences of failing to meet the interoperability requirements of a given identifier. Severity looks at the worst potential consequence of a failure, based on the system damage and/or time lost to repair it. In this document, we define two types of failure severity: "soft" and "hard" 🌈.

Soft Failure: A recoverable condition where a protocol doesn't operate in the prescribed manner, but normal operation can resume automatically in a short period of time. For example, a simple packet loss that gets fixed with a retransmission counts as a soft failure 🌸.

Hard Failure: A non-recoverable condition where a protocol doesn't operate in the prescribed manner, or it operates with excessive degradation of service. For example, an established TCP connection that gets aborted due to an error condition is a hard failure from the transport protocol's point of view, since it enters a state that normal operation can't recover from 💀.

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🔥.

3. Issues with the Specification of Transient Numeric Identifiers 🎀

Recent work on transient numeric identifier usage in protocol specs and implementations [RFC9414] [RFC9415] revealed that most of the issues in this document come down to one of these 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 [RFC0793] and DNS IDs [RFC1035] were originally under specified, so implementations ended up with predictable values and were vulnerable to lots of off-path attacks 😭. Over specification, like with IPv6 Interface Identifiers (IIDs) [RFC4291] and IPv6 Identification values [RFC2460], left implementations unable to respond to security and privacy issues caused by the mandated or recommended algorithms. IPv6 IIDs don't need to expose privacy-sensitive link-layer addresses, and predictable IPv6 Fragment Header Identification values invite the same off-path attacks that plague TCP 🙈.

Finally, some protocol implementations simply don't comply with existing specs 🫠. Good guidance exists in the protocol specification (whether that's the core spec or an update to it), but an implementation just doesn't follow it. For example, some popular operating systems still fail to implement transport-protocol port randomization, as specified in [RFC6056] 💅.

Clearly specifying the interoperability requirements for transient numeric identifiers helps identify possible algorithms to generate them, and makes it obvious when identifiers are over specified ✨. A protocol spec also benefits from a vulnerability assessment of the identifiers it specifies, so those considerations don't get overlooked 🦋.

Part 1 done, bestie! 🌈 More parts are coming, so stay tuned 💖

4. Common Flaws in the Generation of Transient Numeric Identifiers 🫶

okay so this section is basically the "pls don't do this" list 💅 It briefly calls out common flaws people run into when generating transient numeric identifiers. These 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). 💀

Okay, so the trivial algorithms thing is the big one 🙈 If you use something super basic like a global counter, then any node that can sample those identifiers can easily predict the future ones that the victim node is going to use. Not cute.

Next up, using the same identifier in places where it doesn't need to stay constant means activity correlation becomes possible 👀 For example, if an identifier stays the same across networks, it lets someone track a node across networks. Main character energy for the tracker, not for you 😭

Reusing identifiers across different layers or protocols is sneaky too 🦋 It ties the security and privacy properties of the protocol that's reusing the identifier to the security and privacy properties of the original identifier. The thing is, the protocol reusing it may have no control over how that original identifier gets generated. Plus, when you reuse an identifier across protocols from different layers, the goal of isolating one layer's properties from another's gets broken. And the vulnerability assessment gets way harder, because you have to assess the combined system, rather than each protocol in isolation. Ngl, that's a lot of work 💅

Sometimes a protocol needs to convey order information (whether it be sequence, timing, etc.) 🧚 In many cases though, there's no real reason for the corresponding counter or timer to start at any specific value, like at system bootstrap. And similarly, there may not be a need for the difference between successive counter values to be predictable. So don't overthink it 🌈

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 [RFC9415]). The catch is that sharing the same increment space lets an attacker who can sample identifiers in other contexts do things like learn how many identifiers have been generated between two sampled values. Yikes 😬

Finally, some implementations have been found to employ flawed PRNGs (e.g., see [Klein2007]). Iconic behavior from the randomness department, not the good kind 💀

5. Requirements for Transient Numeric Identifiers 📜

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). Basically, spec writers have to spell out what the identifiers need to do and how bad it is if they don't 🎀

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. That's a whole list of villain arcs to check for ✨

   |  NOTE: Sections 8 and 9 of [RFC9415] provide a general
   |  vulnerability assessment of transient numeric identifiers,
   |  along with a vulnerability assessment of common algorithms for
   |  generating transient numeric identifiers.  Please see
   |  [Shostack2014] for further guidance on threat modeling.

Protocol specifications SHOULD NOT employ predictable transient numeric identifiers, except when such predictability is the result of their interoperability requirements. So predictable IDs are a big no-no, unless the interoperability requirements literally need them 🙅‍♀️

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 [RFC9415]. Translation: pick a generation algorithm that actually fixes the problems you just found, and point people to [RFC9415] for the good stuff 🦋

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. Encryption is not a free pass, bestie. Keep applying this advice even when you've got crypto on the job 🔐

6. IANA Considerations 🌸

Good news: this document has no IANA actions 🎀

7. Security Considerations 🔐

This entire document is about the security and privacy implications of transient numeric identifiers, and it formally updates [RFC3552]. The goal is that the security and privacy implications of transient numeric identifiers get addressed when people write the "Security Considerations" section of future RFCs. Honestly this is the whole point of the doc, so please take it seriously 🫶

8. References 📚

8.1. Normative References

[RFC2119]  Bradner, S., "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]  Rescorla, E. 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]  Leiba, B., "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>.

8.2. Informative References 📚

okay bestie, these are the receipts 🧾 the extra reading that backs up everything above, and I'm keeping every single one exactly as it's written 💅

Acknowledgements 🫶

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. ⚽✨

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
📦 where this page comes from