MARAM: Multi-layer Address Randomization and Authentication Mechanism
draft-yarmohammadi-maram-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Reza Yarmohammadi , Mohammadmahdi Vahed , Amirreza Shams , Amirhossien Fayazbakhsh , Mahdyar | ||
| Last updated | 2026-06-13 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yarmohammadi-maram-00
Independent Submission R. Yarmohammadi
Internet-Draft
Intended status: Experimental M. M. Vahed
Expires: 13 December 2026
A. Shams
A. Fayazbakhsh
M. Entezami
11 June 2026
MARAM: Multi-layer Address Randomization and Authentication Mechanism
draft-yarmohammadi-maram-00
Abstract
This document specifies MARAM (Multi-layer Address Randomization and
Authentication Mechanism), an IPv6 extension that encrypts real
endpoint addresses inside a Destination Option and uses ephemeral
outer addresses with per-packet authentication. The key exchange is
FYES (Fayazbakhsh, Yarmohammadi, Entezami, Shams), and a dedicated
Vahed's Seal ensures protocol identification. The key derivation
(FYES-KDF) uses domain separation strings for deriving independent
keys.
Status of This Memo
This note is to be removed before publishing as an RFC.
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
This note is to be removed before publishing as an RFC.
Yarmohammadi, et al. Expires 13 December 2026 [Page 1]
Internet-Draft MARAM June 2026
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Requirements Notation . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
4. FYES Key Exchange and Key Derivation . . . . . . . . . . . . 4
5. MARAM Destination Option Header . . . . . . . . . . . . . . . 5
6. Address Hiding and Packet Construction . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
Appendix A. Enhanced Security Against Modern Threats . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
Yarmohammadi, et al. Expires 13 December 2026 [Page 2]
Internet-Draft MARAM June 2026
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:
Yarmohammadi, et al. Expires 13 December 2026 [Page 3]
Internet-Draft MARAM June 2026
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)
Figure 1
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)
Yarmohammadi, et al. Expires 13 December 2026 [Page 4]
Internet-Draft MARAM June 2026
Figure 2
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) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
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.
Yarmohammadi, et al. Expires 13 December 2026 [Page 5]
Internet-Draft MARAM June 2026
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
Figure 4
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:
Yarmohammadi, et al. Expires 13 December 2026 [Page 6]
Internet-Draft MARAM June 2026
* *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.
9. 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>.
[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>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
Yarmohammadi, et al. Expires 13 December 2026 [Page 7]
Internet-Draft MARAM June 2026
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC3849] Huston, G., "IPv6 Documentation Prefix", RFC 3849,
DOI 10.17487/RFC3849, July 2004,
<https://www.rfc-editor.org/info/rfc3849>.
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
Reza Yarmohammadi
Email: rezayarmohammadi730@gmail.com
MohammadMehdi Vahed
Email: mohammadmahdi.Vahed@gmail.com
Amirreza Shams
Yarmohammadi, et al. Expires 13 December 2026 [Page 8]
Internet-Draft MARAM June 2026
Email: theamirrezashams@gmail.com
Amirhossien Fayazbakhsh
Email: fayazamirh@gmail.com
Mahdyar Entezami
Email: mahdyaren@gmail.com
Yarmohammadi, et al. Expires 13 December 2026 [Page 9]