Independent Submission                                       Georgiy S.
                                                           Ospab Project
Category: Informational                                        May 2026

              The Ospab Stealth Transport Protocol (OSTP)
                         Protocol Specification

NOTICE

   This document is an Independent Submission and is NOT a product of
   the Internet Engineering Task Force (IETF). It has NOT been reviewed
   or approved by the IETF or the Internet Engineering Steering Group
   (IESG). It represents the technical specification of OSTP as
   developed by the Ospab Project and is published for informational
   and interoperability purposes only.

   This document is formatted according to the conventions described in
   RFC 7322 ("RFC Style Guide") for readability, but it is NOT an RFC
   and has not been assigned an RFC number by the IANA RFC Editor.

Abstract

   This document specifies the Ospab Stealth Transport Protocol (OSTP),
   a multiplexed, application-agnostic Layer 4 transport protocol
   designed for secure, censorship-resistant communication over
   hostile networks. OSTP employs the Noise Protocol Framework for
   authenticated key exchange, IETF ChaCha20-Poly1305 for symmetric
   encryption, HMAC-SHA-256-based per-packet header masking for
   traffic obfuscation, and a selective-repeat ARQ mechanism for
   reliability over UDP. The design goal is wire-level
   indistinguishability from random noise, resistance to Deep Packet
   Inspection (DPI), and resilience to IP-roaming events.

Table of Contents

   1. Introduction ................................................ 2
      1.1. Motivation .............................................. 2
      1.2. Terminology and Requirements Language .................. 2
      1.3. Relation to Existing Standards ......................... 3
   2. Protocol Architecture ...................................... 3
      2.1. Layer Classification ................................... 3
      2.2. Node Roles .............................................. 3
      2.3. Transport Substrate .................................... 3
   3. Frame Format ................................................ 4
      3.1. Structural Diagram ..................................... 4
      3.2. Field Descriptions ..................................... 4
   4. Header Obfuscation .......................................... 5
      4.1. Obfuscation Key Derivation ............................. 5
      4.2. Per-Packet Masking ..................................... 5
   5. Cryptographic Handshake .................................... 6
   6. Data Channel Operation ..................................... 6
      6.1. Stream Multiplexing .................................... 7
      6.2. Selective-Repeat ARQ ................................... 7
      6.3. Adaptive Padding ....................................... 7
   7. IP Roaming .................................................. 8
   8. Security Considerations .................................... 8
   9. References .................................................. 9

1. Introduction

1.1. Motivation

   Standard tunneling protocols (e.g., OpenVPN, WireGuard) produce
   traffic patterns that are reliably identified by stateful DPI
   systems through static magic bytes, fixed handshake sizes, or
   predictable sequence patterns. OSTP is designed to resist such
   fingerprinting by ensuring that every byte on the wire, including
   header fields, appears statistically indistinguishable from
   uniformly random data.

1.2. 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.

   Client / Initiator:  The node that initiates the OSTP connection.
   Server / Responder:  The node that accepts OSTP connections.
   Session ID (SID):    A 32-bit per-connection identifier, randomly
                        generated by the Initiator.
   Nonce:               A 64-bit monotonically increasing counter used
                        as both the ARQ sequence number and AEAD IV.
   Obfuscation Key:     An 8-byte key derived from the access key,
                        used exclusively for header masking.

1.3. Relation to Existing Standards

   OSTP uses the following standardized components:

   - Noise Protocol Framework [Noise] with pattern NNpsk0, using
     Curve25519 (X25519 [RFC7748]) for key agreement, ChaCha20-
     Poly1305 [RFC8439] for AEAD, and BLAKE2s [RFC7693] for hashing.
   - HMAC-SHA-256 [RFC2104][FIPS180-4] for per-packet header masking.
   - UDP [RFC0768] as the transport substrate.

   OSTP does not claim compliance with or supersede any IETF or IEEE
   standard. It is an independent protocol specification.

2. Protocol Architecture

2.1. Layer Classification

   In terms of the OSI Reference Model [ISO7498-1]:

   - OSTP occupies Layer 4 (Transport Layer) and provides reliability,
     ordering, and multiplexing services above UDP (Layer 4 substrate).
   - The cryptographic and obfuscation functions can be viewed as a
     presentation-layer concern (Layer 6), though OSTP integrates
     them inline rather than as a separate layer.

2.2. Node Roles

   OSTP operates in a client-server paradigm:

   Initiator (Client):  Establishes connections, generates Session IDs,
                        and drives handshake initiation.
   Responder (Server):  Accepts connections, validates credentials,
                        and relays application-layer traffic.

2.3. Transport Substrate

   All OSTP datagrams are carried over UDP. The Initiator MUST support
   IP-roaming by allowing the Responder to update the peer address upon
   receiving an authenticated packet from a new source address.

3. Frame Format

3.1. Structural Diagram

   All multi-byte fields are in network byte order (big-endian).

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Masked Session Identifier (32 bits)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    Plaintext Nonce (64 bits)                  +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~              AEAD Ciphertext (Variable Length)                ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              16-Octet Poly1305 Authentication Tag             |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Total header size: 12 octets (4 SID + 8 Nonce).
   Minimum frame size: 12 + 16 = 28 octets (empty payload + tag).

3.2. Field Descriptions

   Masked Session Identifier (32 bits):
      The Session ID XOR-masked with the first 4 bytes of
      HMAC-SHA-256(K_obf, Nonce). See Section 4.

   Plaintext Nonce (64 bits):
      A monotonically increasing counter. MUST start at 0 and
      increment by 1 for each transmitted packet. The Nonce is
      transmitted in cleartext to allow the receiver to compute the
      identical HMAC mask and recover the Session ID. The Nonce is
      authenticated as Additional Authenticated Data (AAD) by the
      AEAD cipher, preventing tampering.

   AEAD Ciphertext:
      The inner payload encrypted with ChaCha20-Poly1305 using the
      session key, Nonce as IV, and the 12-byte header as AAD.

   Authentication Tag:
      The 16-byte Poly1305 MAC produced by the AEAD operation.

4. Header Obfuscation

4.1. Obfuscation Key Derivation

   Both nodes MUST independently derive an 8-byte obfuscation key
   from the shared access key prior to the handshake:

      K_obf = SHA-256(access_key || 0x6F626675736361) [0..7]

   where 0x6F626675736361 is the ASCII encoding of "obfusca".
   K_obf MUST NOT be transmitted over the network.

4.2. Per-Packet Masking

   To ensure that the Session ID field is statistically independent
   across consecutive packets, it is masked using a per-packet
   pseudorandom value derived via HMAC-SHA-256:

      mask[0..3] = HMAC-SHA-256(K_obf, Nonce)[0..3]
      Masked_SID[i] = SID_raw[i] XOR mask[i],   for i in [0..3]

   Because the Nonce is unique per packet, the mask is
   cryptographically independent for every datagram. A passive
   observer cannot distinguish Masked_SID values across packets
   without knowledge of K_obf.

   The Nonce is transmitted in plaintext. The receiver computes the
   same HMAC using the received Nonce and K_obf to recover SID_raw:

      SID_raw[i] = Masked_SID[i] XOR HMAC-SHA-256(K_obf, Nonce)[0..3]

   This construction is integrity-protected: if either K_obf or the
   Nonce is incorrect, the recovered SID will not match any known
   session, and the packet is silently discarded.

5. Cryptographic Handshake

   OSTP uses the Noise Protocol Framework [Noise] with the following
   parameters:

      Noise_NNpsk0_25519_ChaChaPoly_BLAKE2s

   - Handshake pattern: NNpsk0 (mutual ephemeral, PSK at position 0)
   - DH function: X25519 [RFC7748]
   - AEAD cipher: ChaCha20-Poly1305 [RFC8439]
   - Hash function: BLAKE2s [RFC7693]

   The PSK is derived from the access key via SHA-256:

      PSK = SHA-256(access_key)

   The handshake payload carried in the initiator's first message
   includes a Unix timestamp (8 bytes), the Session ID (4 bytes), and
   the raw access key bytes for server-side authentication. The server
   validates the access key against its configured set and MUST reject
   handshakes with timestamps deviating more than 30 seconds from
   server local time to prevent replay attacks.

6. Data Channel Operation

   After a successful handshake, the Noise session yields two
   symmetric ChaCha20-Poly1305 keys: one for each direction. These
   keys are used for all subsequent data frames.

6.1. Stream Multiplexing

   OSTP supports multiplexing of multiple logical application streams
   over a single UDP socket. Each datagram carries a 16-bit Stream ID
   embedded in the AEAD-encrypted payload. Multiple parallel Noise
   sessions MAY be established between the same client-server pair
   to increase throughput.

6.2. Selective-Repeat ARQ

   OSTP implements a selective-repeat ARQ mechanism:

   - Each packet carries a 64-bit Nonce (sequence number).
   - The receiver maintains a reorder buffer of configurable depth
     (default: 8192 packets, window: 2^18).
   - Unacknowledged packets are retransmitted after a configurable
     RTO (default: 100 ms), up to a maximum retry count (default: 8).
   - ACKs are piggybacked on outbound data frames with a configurable
     delay (default: 5 ms) to allow ACK coalescing.
   - Out-of-window packets are silently discarded.

6.3. Adaptive Padding

   To resist traffic analysis via packet-length fingerprinting, OSTP
   implementations SHOULD pad plaintext payloads before AEAD
   encryption. Padding bytes MUST be drawn from a cryptographically
   secure random source (e.g., OS-provided CSPRNG). The padding
   length is determined by the active traffic profile:

   - Fixed:    Pad to the nearest fixed boundary.
   - Adaptive: Pad to nearest 64-byte boundary, plus 0-96 random
               bytes.
   - Profile:  Mimic common protocol size distributions (e.g.,
               HTTP/2 bursts, video stream MTU-sized frames).

   Maximum padding is 1400 bytes (below standard Ethernet MTU of
   1500 bytes minus IP and UDP headers).

7. IP Roaming

   The server MUST support IP roaming: if an authenticated packet
   arrives from a source address different from the recorded peer
   address for an existing session, the server MUST update the
   stored peer address to the new source. This enables seamless
   network handoffs (e.g., cellular to Wi-Fi transitions) without
   session teardown.

8. Security Considerations

8.1. Nonce Exhaustion

   The Nonce field is 64 bits wide. At 1,000,000 packets per second,
   a single session would exhaust the nonce space in approximately
   585,000 years. Implementations MUST terminate and re-key a session
   before Nonce reaches 2^64 - 1 to prevent AEAD keystream reuse.

8.2. Replay Attack Prevention

   The 30-second handshake timestamp window mitigates replay of
   captured handshake packets. Implementations SHOULD additionally
   maintain a short-lived cache of recently seen handshake payloads
   to detect exact replays within the time window.

8.3. Session Exhaustion (DoS)

   The server MUST enforce a maximum number of concurrent sessions
   (recommended: 1024) and silently discard new handshake attempts
   when the limit is reached. No error response should be sent, to
   avoid amplification.

8.4. Header Obfuscation Limitations

   The header masking scheme provides obfuscation, not authentication
   of the header fields themselves. Header integrity is guaranteed
   indirectly by the AEAD authentication tag, which covers the header
   as AAD.

9. References

   [RFC0768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
               August 1980.

   [RFC2104]   Krawczyk, H., Bellare, M., Canetti, R., "HMAC:
               Keyed-Hashing for Message Authentication", RFC 2104,
               February 1997.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC7322]   Flanagan, H., Ginoza, S., "RFC Style Guide", RFC 7322,
               September 2014.

   [RFC7693]   Saarinen, M-J., Aumasson, J-P., "The BLAKE2
               Cryptographic Hash and MAC", RFC 7693, November 2015.

   [RFC7748]   Langley, A., Hamburg, M., Turner, S., "Elliptic Curves
               for Security", RFC 7748, January 2016.

   [RFC8174]   Leiba, B., "Ambiguity of Uppercase vs Lowercase in
               RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.

   [RFC8439]   Nir, Y., Langley, A., "ChaCha20 and Poly1305 for
               IETF Protocols", RFC 8439, June 2018.

   [FIPS180-4] NIST, "Secure Hash Standard (SHS)", FIPS PUB 180-4,
               August 2015.

   [ISO7498-1] ISO/IEC 7498-1:1994, "Information technology -- Open
               Systems Interconnection -- Basic Reference Model:
               The Basic Model", 1994.

   [Noise]     Perrin, T., "The Noise Protocol Framework", Revision 34,
               2018. https://noiseprotocol.org/noise.html

Author's Address

   Georgiy S.
   Ospab Project
   Email: (available via GitHub repository)
   Repository: https://github.com/ospab/ostp
