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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . 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, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [RFC3849] Huston, G., "IPv6 Documentation Prefix", RFC 3849, DOI 10.17487/RFC3849, July 2004, . 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]