Internet Engineering Task Force (IETF) Georgiy S. Request for Comments: 9842 Ospab Foundation Category: Standards Track May 2026 ISSN: 2070-1721 The Ospab Stealth Transport Protocol (OSTP) Abstract This document specifies the Ospab Stealth Transport Protocol (OSTP), a high-entropy, multiplexed Layer 4 transport pipeline developed to achieve secure, resilient data replication between distributed nodes across networks characterized by severe stochastic disturbance and hostile packet-level telemetry inspections. OSTP incorporates session-state scrambling matrices and cryptographic block boundary realignment to completely suppress statistical traffic signatures, guaranteeing absolute wire-level protocol indistinguishability. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Table of Contents 1. Introduction ................................................ 2 1.1. Terminology and Requirements Language .................. 2 2. Architecture and Operations Model ........................... 3 3. In-Place Scrambling Transformation (IPST) .................. 3 3.1. Derived Entropy Initialization ......................... 3 3.2. Operational State Scrambling ........................... 4 4. Frame Specification and Formatting .......................... 4 4.1. Structural Diagram ..................................... 5 5. Cryptographic Synchronization ............................... 5 6. Multiplexing Support ........................................ 6 7. IANA Considerations ......................................... 6 8. Security Considerations ..................................... 6 9. References .................................................. 7 1. Introduction Traditional encapsulation protocols often introduce static sequence headers, identifiable magic byte vectors, or structural invariants at the commencement of payload exchange. In adversarial networking environments, such invariants facilitate immediate categorization and subsequent drop-filtering via automated Deep Packet Inspection (DPI) appliances. The Ospab Stealth Transport Protocol (OSTP) addresses this threat model by employing mathematical state scrambling and randomized frame-boundary injection prior to final serialization. The primary design goal is complete convergence toward Maximum Uniform Entropy, yielding UDP datagrams statistically identical to pure line noise. 1.1. Terminology and Requirements Language 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. 2. Architecture and Operations Model OSTP operates in a client-server paradigm, hereinafter referred to as the "Relay Bridge" (initiator) and "Collector Node" (responder). Payload communication routes over a singular bidirectional UDP socket. Multiple logical sub-streams MAY occupy the shared socket state, utilizing internal cryptographic multiplex channels. 3. In-Place Scrambling Transformation (IPST) Before transit onto the network layer, every frame is subject to In-Place Scrambling Transformation (IPST). This operation mutates static parameters dynamically, removing spatial correlation patterns across packets. 3.1. Derived Entropy Initialization Nodes MUST configure an authorized ASCII Registration Key (denoted as 'Key_reg'). Upon instantiation, both nodes statically derive an 8-octet scrambler matrix vector ('K_scram') via the Secure Hash Algorithm (SHA-256): K_scram = SHA-256(Key_reg)[0..7] The derived vector 'K_scram' MUST remain local to the nodes and SHALL NEVER traverse the physical media. 3.2. Operational State Scrambling Each frame contains a 4-octet Session ID (SID) and an 8-octet inbound/outbound sequence counter (Nonce). 1. Initialization Vector Phase: During initialization, raw payload fields are combined via bitwise exclusive OR (XOR) against the derivation vector: Serialized[i] = Raw[i] ^ K_scram[i mod 8], for i in [0..3] 2. Active Session Phase: Once the secure channel is established, multi-tier scrambling obliterates deterministic sequences: A. The Nonce field is scrambled using the static vector: Nonce_scr[i] = Nonce_raw[i] ^ K_scram[i], for i in [0..7] B. The Session ID is scrambled using high-frequency entropy extracted from the least significant 32 bits of the raw Nonce: SID_scr[i] = SID_raw[i] ^ (Nonce_raw & 0xFFFFFFFF)[i] As the raw Nonce incrementation cycles through consecutive integer states, the resulting wire-level SID representation changes probabilistically on a per-packet basis, rendering pattern-based prefix filters ineffective. 4. Frame Specification and Formatting An OSTP packet serialized for transport MUST conform to the physical maximum transmission unit (MTU) alignments. Framing consists of a pre-scrambled header envelope succeeded by the ciphered, padded payload. 4.1. Structural Diagram The serialized datagram representation is depicted below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scrambled Session Identifier (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Scrambled Nonce (64 bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ AEAD Authenticated Ciphertext ~ | (Variable Length Payload) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Cryptographic Dynamic Padding Block ~ | (Randomized Noise Density) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 16-Octet Authentication Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. Cryptographic Synchronization OSTP implementations MUST execute a Noise Protocol Framework exchange utilizing the `Noise_NNpsk0_25519_ChaChaPoly_BLAKE2s` pattern. 1. The Registration Key (Key_reg) is converted to a 32-octet strong pre-shared key (PSK) via keyed hash derivation. 2. The PSK is integrated into the state at pattern position zero, authorizing and encrypting the very first handshaking datagram. 3. Ephemeral Curve25519 key exchange is evaluated to synthesize autonomous symmetric keys for subsequent read/write channels. 6. Multiplexing Support To prevent head-of-line (HoL) bottlenecks associated with reliable message delivery, OSTP permits binding multiple logical channel instances to a common hardware UDP socket. Individual channels execute independent Noise state engines. Endpoint transitions (IP roaming) are handled dynamically via automatic remote source updates upon successful AEAD authentication validation. 7. IANA Considerations This document has no actions for IANA. All assignments of local UDP ports are considered system-local, and registry configurations are intentionally omitted to deny static footprint registration. 8. Security Considerations All implementations MUST rigorously safeguard sequence counter integrity. Under zero circumstances SHALL a Nonce overflow or cycle backward, as keystream reuse within AEAD_ChaChaPoly yields immediate key leakage. Upon boundary approach (Nonce == 2^64 - 1), the implementation MUST terminate the active session and force a clean re-key process. Padding areas MUST contain true high-entropy randomness. Replicating zero-padding (0x00) is strictly forbidden, as variable compressibility profiles in intermediary compression layers may leak payload lengths. 9. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase %s in RFC 2119 Ambiguity", BCP 14, RFC 8174, May 2017. [Noise] Trevor Perrin, "The Noise Protocol Framework", 2018.