mirror of https://github.com/ospab/ostp.git
206 lines
9.2 KiB
Plaintext
206 lines
9.2 KiB
Plaintext
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.
|