]> Fastly Inc.

fde@00f.net

Internet-Draft This document specifies methods for encrypting and obfuscating IP addresses, providing both deterministic format‑preserving and non‑deterministic constructions. These methods address privacy concerns raised in and regarding pervasive monitoring and data collection. The methods apply uniformly to both IPv4 and IPv6 addresses by converting them into a 16‑byte representation. Two generic constructions are defined—one using a 128‑bit block cipher and the other using a 128‑bit tweakable block cipher—along with three concrete instantiations:

• ipcrypt-deterministic: Deterministic encryption using AES128 (applied as a single‑block operation).
• ipcrypt-nd: Non‑deterministic encryption using the KIASU‑BC tweakable block cipher with an 8‑byte tweak.
• ipcrypt-ndx: Non‑deterministic encryption using the AES‑XEX tweakable block cipher with a 16‑byte tweak.

Deterministic mode produces a 16‑byte ciphertext (enabling format preservation), while non‑deterministic modes prepend a randomly sampled tweak (which MUST be uniformly random when generated, as specified in ) to produce larger ciphertexts that resist correlation attacks. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction This document specifies a standard for the encryption and obfuscation of IP addresses for both operational use and privacy preservation. The objective is to enable network operators, researchers, and privacy advocates to share or analyze data while protecting sensitive address information, addressing concerns raised in regarding confidentiality in the face of pervasive surveillance.

Use Cases and Motivations The main motivations include:

• Privacy Protection: Encrypting IP addresses prevents the disclosure of user-specific information when data is logged or measured, as discussed in .
• Format Preservation: Ensuring that the encrypted output remains a valid IP address allows network devices to process the data without modification.
• Mitigation of Correlation Attacks: Deterministic encryption reveals repeated inputs; non‑deterministic modes use a random tweak to obscure linkability while keeping the underlying input confidential.

Terminology 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 when, and only when, they appear in all capitals, as shown here. Throughout this document, the following terms and conventions apply:

• IP Address: An IPv4 or IPv6 address as defined in .
• 16‑Byte Representation: A fixed-length representation used for both IPv4 (via IPv4‑mapped IPv6) and IPv6 addresses.
• Tweak: A non‑secret, additional input to a tweakable block cipher that further randomizes the output.
• Deterministic Encryption: Encryption that always produces the same ciphertext for a given input and key.
• Non‑Deterministic Encryption: Encryption that produces different ciphertexts for the same input due to the inclusion of a randomly sampled tweak.
• (Input, Tweak) Collision: A scenario where the same input is encrypted with the same tweak; this reveals that the input was repeated but not the input’s value.

IP Address Conversion This section describes the conversion of IP addresses to and from a 16‑byte representation. This conversion is necessary to operate a 128‑bit cipher on both IPv4 and IPv6 addresses.

Converting to a 16‑Byte Representation

IPv6 Addresses IPv6 addresses are natively 128 bits and are converted directly using network‑byte order (big‑endian) as specified in . Example:

IPv4 Addresses IPv4 addresses (32 bits) are mapped using the IPv4‑mapped IPv6 format:

Converting from a 16‑Byte Representation to an IP Address The conversion algorithm is as follows:

1. Examine the first 12 bytes of the 16-byte representation
2. If they match the IPv4‑mapped prefix (10 bytes of 0x00 followed by 0xFF, 0xFF):
   • Interpret the last 4 bytes as an IPv4 address in dotted‑decimal notation
3. Otherwise:
   • Interpret the 16 bytes as an IPv6 address in colon‑hexadecimal notation

(For additional illustration, see Appendix B.)

Generic Constructions This specification defines two generic cryptographic constructions:

1. 128-bit Block Cipher Construction:
   • Used in deterministic encryption
   • Operates on a single 16-byte block
   • Example: AES‑128 treated as a permutation
2. 128-bit Tweakable Block Cipher (TBC) Construction:
   • Used in non‑deterministic encryption
   • Accepts a key, a tweak, and a message
   • The tweak is typically randomly sampled (and MUST be uniformly random when generated)
   • Reuse of the same tweak on different inputs does not compromise confidentiality

Valid options for implementing a tweakable block cipher include, but are not limited to:

• SKINNY
• DEOXYS-BC
• KIASU-BC
• AES-XEX

Implementers MUST choose a cipher that meets the required security properties and provides robust resistance against related-tweak and other cryptographic attacks.

Deterministic Encryption Deterministic encryption applies a 128‑bit block cipher directly to the 16‑byte representation of an IP address.

Specific Instantiation: ipcrypt-deterministic This instantiation employs AES128 in a single‑block operation. Since AES128 is a permutation, every distinct 16‑byte input maps to a unique 16‑byte ciphertext, preserving the IP address format.

Operation Flow Diagram

Format Preservation

• If the 16‑byte ciphertext begins with an IPv4‑mapped prefix, it MUST be rendered as a dotted‑decimal IPv4 address.
• Otherwise, it is interpreted as an IPv6 address.

• Note: To ensure IPv4 format preservation, implementers MUST consider using cycle‑walking or an FPE mode if required.

Non‑Deterministic Encryption Non‑deterministic encryption leverages a tweakable block cipher together with a random tweak. Although the tweak is generated uniformly at random (and thus may occasionally collide per birthday bounds), such collisions are benign when they occur with different inputs. An (input, tweak) collision reveals that the same input was encrypted with the same tweak but does not disclose the input’s value. The usage limits discussed below apply per cryptographic key; rotating keys can extend secure usage beyond these bounds. This document defines two instantiations:

• ipcrypt-nd: Uses the KIASU‑BC tweakable block cipher with an 8‑byte (64‑bit) tweak. See for details.
• ipcrypt-ndx: Uses the AES‑XEX tweakable block cipher with a 16‑byte (128‑bit) tweak. See for background.

In both cases, if a tweak is generated randomly, it MUST be uniformly random. Reusing the same randomly generated tweak on different inputs is acceptable from a confidentiality standpoint.

ipcrypt-nd (KIASU‑BC)

• Tweak: 8 bytes (64 bits).
• Output: 24 bytes total (8‑byte tweak concatenated with a 16‑byte ciphertext).

Usage Considerations Random sampling of an 8‑byte tweak yields an expected collision for a specific tweak value after about 2^(64/2) = 2^32 operations. If an (input, tweak) collision occurs, it indicates that the same input was processed with that tweak without revealing the input’s value. These collision bounds apply per cryptographic key; by rotating keys regularly, secure usage can be extended well beyond these bounds. Ultimately, the effective security is determined by the underlying block cipher’s strength (≈2^128 for AES‑128).

ipcrypt-ndx (AES‑XEX)

• Tweak: 16 bytes (128 bits).
• Output: 32 bytes total (16‑byte tweak concatenated with a 16‑byte ciphertext).

Usage Considerations Independent sampling of a 16‑byte tweak results in an expected collision after about 2^(128/2) = 2^64 operations. As with ipcrypt-nd, an (input, tweak) collision reveals repetition without compromising the input value. These limits are per key; regular key rotation further extends secure usage. The effective security is governed by the strength of AES‑128 (approximately 2^128 operations).

Comparison of Modes

• Deterministic (ipcrypt-deterministic): Produces a 16‑byte output; preserves format but reveals repeated inputs.
• Non‑Deterministic:
  • ipcrypt-nd (KIASU‑BC): Produces a 24‑byte output using an 8‑byte tweak; (input, tweak) collisions reveal repeated inputs (with the same tweak) but not their values.
  • ipcrypt-ndx (AES‑XEX): Produces a 32‑byte output using a 16‑byte tweak; supports higher secure operation counts per key.

Security Considerations

• Deterministic Mode: AES‑128’s permutation behavior ensures distinct inputs yield distinct outputs; however, repeated inputs result in identical ciphertexts, thereby revealing repetition.
• Non‑Deterministic Mode: The inclusion of a random tweak ensures that encrypting the same input generally produces different outputs. In cases where an (input, tweak) collision occurs, an attacker learns only that the same input was processed with that tweak, not the value of the input itself. Security is determined by the underlying block cipher (≈2^128 for AES‑128) on a per-key basis. Key rotation is recommended to extend secure usage beyond the per-key collision bounds.

IANA Considerations This document does not require any IANA actions.

References Normative References National Institute of Standards and Technology National Institute of Standards and Technology This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered. In this document, we develop a threat model that describes these attacks on Internet confidentiality. We assume an attacker that is interested in undetected, indiscriminate eavesdropping. The threat model is based on published, verified attacks. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] Informative References

Acknowledgments The author gratefully acknowledges the contributions and insightful comments from members of the IETF independent stream community and the broader cryptographic community that have helped shape this specification.

Appendices

Appendix A. Pseudocode and Examples This appendix provides detailed pseudocode for key operations described in this document.

IPv4 Address Conversion Example: For "192.0.2.1", the function returns

IPv6 Address Conversion > 8) & 0xFF low_byte = word & 0xFF bytes16.append(high_byte) bytes16.append(low_byte) return bytes16 ]]> Example: For "2001:0db8:85a3:0000:0000:8a2e:0370:7334", the output is the corresponding 16‑byte sequence.

Conversion from a 16-Byte Array to an IP Address

Deterministic Encryption (ipcrypt-deterministic)

Non‑Deterministic Encryption using KIASU‑BC (ipcrypt-nd)

Non‑Deterministic Encryption using AES‑XEX (ipcrypt-ndx)

Appendix B. Diagrams

IPv4 Address Conversion Diagram

Deterministic Encryption Flow

Non‑Deterministic Encryption Flow (ipcrypt-nd) 16-Byte Representation | v [Generate Random 8-Byte Tweak] | v [KIASU-BC Tweakable Encrypt] | v 16-Byte Ciphertext | v [Concatenate Tweak || Ciphertext] | v 24-Byte Output (`ipcrypt-nd`) ]]>

Non‑Deterministic Encryption Flow (ipcrypt-ndx) 16-Byte Representation | v [Generate Random 16-Byte Tweak] | v [AES-XEX Tweakable Encrypt] | v 16-Byte Ciphertext | v [Concatenate Tweak || Ciphertext] | v 32-Byte Output (`ipcrypt-ndx`) ]]>