MARAM: Multi-layer Address Randomization and Authentication Mechanism

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 13 December 2026.¶

Copyright Notice

Copyright (c) 2026 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.¶

Table of Contents

1. Introduction

The Internet Protocol exposes source and destination addresses in cleartext, enabling traffic analysis [RFC7258], source spoofing, and packet injection. MARAM (Multi-layer Address Randomization and Authentication Mechanism) defeats these threats by encrypting the real addresses and authenticating each packet via a MAC derived from a shared secret established through the FYES key exchange. The protocol design ensures endpoint privacy without requiring changes to core routing infrastructure.¶

2. Terminology and Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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.¶

Additional terms:¶

• Inner address: The actual, stable IPv6 address of the source or destination.¶
• Outer address: An ephemeral, cryptographically generated IPv6 address placed in the IP header and used for routing.¶
• Vahed's Seal: A 64-bit constant marker embedded in the MARAM Destination Option that identifies the protocol and provides a first-level integrity check.¶

3. Protocol Overview

MARAM operates between two endpoints that both support the extension. The protocol proceeds in two phases:¶

Phase 1 – FYES Key Exchange:

Endpoints perform an Elliptic Curve Diffie-Hellman (ECDH) exchange on X25519. The exchange MUST be authenticated using long-term keys or a trust-on-first-use (TOFU) model; the exact authentication mechanism is out of scope for this document. FYES refers to Fayazbakhsh, Yarmohammadi, Entezami, and Shams. From the shared secret, the FYES-KDF derives three session keys using HKDF [RFC5869] with domain separation strings.¶

Phase 2 – Data Transfer:

For each packet, the sender:¶

1. Generates fresh outer source and destination addresses from the base secret and a packet counter.¶
2. Encrypts the real source/destination addresses and ports into a MARAM Destination Option.¶
3. Constructs the IPv6 header using the ephemeral outer addresses.¶
4. Inserts the constant Vahed's Seal into the option.¶
5. Computes a MAC over the packet (with the MAC field zeroed) and places it in the option.¶
6. Sends the packet.¶

The receiver validates the seal, verifies the MAC, decrypts the inner addresses, and restores the original packet.¶

4. FYES Key Exchange and Key Derivation

FYES (Fayazbakhsh, Yarmohammadi, Entezami, Shams) is a minimal authenticated Elliptic Curve Diffie-Hellman (ECDH) key exchange performed over the X25519 curve. It establishes a shared secret between a Requestor and a Reference without requiring prior coordination beyond static or trust-on-first-use credentials. The exchange consists of a single round-trip where each side generates an ephemeral key pair. After successful authentication (out of scope for this document), both sides compute the shared secret and derive session keys through the FYES-KDF.¶

Requestor                Reference
---------------------------------------------------------------
ephemeral_pub_I = x25519(priv_I, G) ---->
                                         <----- ephemeral_pub_R

Both sides compute:
shared_secret = x25519(priv, peer_pub)

The FYES-KDF then expands the shared secret using HKDF with SHA-256:¶

PRK = HKDF-Extract(salt=0x00, IKM=shared_secret)

KE = HKDF-Expand(PRK, "maram layer encryption", 32)
KM = HKDF-Expand(PRK, "mdyrm mac", 32)
S  = HKDF-Expand(PRK, "Vahed's Keystone", 32)

KE is used for AEAD encryption of the inner address block (AES-256-GCM). KM is the key for the per-packet MAC (HMAC-SHA-256). S is the base secret for generating ephemeral outer addresses; it is referred to as Vahed's Keystone.¶

The labels are arbitrary domain separation strings and do not affect the cryptographic properties of the derived keys.¶

5. MARAM Destination Option Header

The MARAM information is carried in an IPv6 Destination Option, identified by Option Type TBD (to be assigned by IANA). The option data is aligned to 8n+2 bytes by adding zero-padding (PadN) if necessary.¶

 0                   1                   2                   3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option Type  |  Opt Data Len |       Counter (16 bits)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                   Vahed's Seal (64 bits)                      +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~            Encrypted Inner Address Block (variable)          ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                       MAC (128 bits)                          +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Type:

TBD (act=00, chg=1).¶

Vahed's Seal:

A 64-bit constant set to 0x454D414D46415354. Receivers MUST reject any packet with a different value.¶

Encrypted Inner Address Block:

The true source and destination IPv6 addresses (each 128 bits) and the true source and destination ports (each 16 bits), encrypted with AES-256-GCM using key KE. The 12-byte nonce is formed as: 0x00000000 || Counter || 0x000000000000. The GCM authentication tag (128 bits) is appended to the ciphertext.¶

MAC:

128-bit truncated HMAC-SHA-256 (first 128 bits) over the entire packet (with the MAC field set to zero), using key KM.¶

6. Address Hiding and Packet Construction

Outer addresses are built from a documentation prefix and the base secret S. For the examples in this document, the prefix 2001:db8::/48 is used. The lower 80 bits are taken from the HMAC-SHA-256 computation, as follows:¶

Outer_Src = 2001:db8:0:0:0:0:0:0/48 |
           HMAC-SHA-256(S, "MARAM outer src" || Counter)
           truncated to 80 bits

Outer_Dst = 2001:db8:0:0:0:0:0:0/48 |
           HMAC-SHA-256(S, "MARAM outer dst" || Counter)
           truncated to 80 bits

The inner (real) addresses remain unchanged and are encrypted in the Destination Option. For illustration, the following inner addresses are used in this document:¶

• Requestor: 2001:db8::6661:7961:7a00:0¶
• Reference: 2001:db8::7661:6865:6400:0¶

(These addresses lie within the documentation prefix and their lower 64 bits are arbitrary identifiers.)¶

When the Requestor communicates with the Reference, the outer addresses change every packet, while the inner addresses stay encrypted.¶

7. Security Considerations

MARAM enforces the following properties:¶

• Confidentiality of real endpoints: On-path observers see only ephemeral addresses. Inner addresses are AEAD-encrypted.¶
• Anti-spoofing: Without KM, an attacker cannot generate a valid MAC, even with knowledge of the static Vahed's Seal.¶
• Replay protection: The receiver maintains a sliding window of acceptable counter values. Packets with counters outside the window or already received are discarded, preventing replay attacks.¶
• Resistance to traffic analysis: Constant address changes prevent flow correlation, aligning with [RFC7258].¶
• Resilience against injection: Any forged RST or data packet fails MAC validation and is discarded.¶

An adversary (e.g., an on-path "Shams") cannot distinguish different flows or inject traffic. The protocol provides strong protection against DDoS, man-in-the-middle, and surveillance.¶

The use of a static salt in HKDF-Extract (salt=0x00) is acceptable if the input keying material (shared_secret) has sufficient entropy. The domain separation strings are arbitrary and do not weaken the key derivation.¶

8. IANA Considerations

IANA is requested to allocate a Destination Option type from the "Destination Options and Hop-by-Hop Options" registry under "IPv6 Parameters". The act bits are "00", the chg bit is "1". The suggested mnemonic is MARAM. The assigned value is TBD.¶

Appendix A. Enhanced Security Against Modern Threats

MARAM addresses several modern attack vectors:¶

Spoofing and DDoS:

By authenticating every packet with a MAC, source address spoofing is completely prevented, cutting off reflection and amplification DDoS attacks at the root.¶

Man-in-the-Middle (MitM):

Without the shared KM, an interceptor cannot decrypt or modify the inner addresses, rendering MitM attacks ineffective.¶

Eavesdropping and Traffic Analysis:

The ephemeral outer headers and encrypted inner addresses ensure that even a pervasive monitor cannot map communication patterns to stable identities, thereby defeating traffic correlation.¶

Packet Injection:

Any unsolicited packet (e.g., TCP RST) fails MAC validation, protecting established connections.¶

These properties make MARAM a robust privacy and anti-attack layer for the modern Internet.¶

Authors' Addresses