mirror of https://github.com/ospab/ostp.git
docs: rewrite ieee_spec and rfc_ostp as honest independent specifications
This commit is contained in:
ospab
parent
c5d43a4666
commit
96003a1dc8
|
|
@ -1,93 +1,173 @@
|
||||||
# IEEE P2974.1™ Draft Standard for High-Assurance Multiplexed Industrial Telemetry Transport
|
# OSTP Technical Specification
|
||||||
|
## OSI Layer Classification and Protocol Architecture
|
||||||
|
|
||||||
**Status:** Work-in-Progress Draft (For Engineering Consortium Review Only)
|
**Document Type:** Independent Technical Specification
|
||||||
**Document Reference:** IEEE-P2974.1-D04
|
**Status:** Informational
|
||||||
**Subject Area:** Networked Sensors, Distributed Industrial Grids, SCADA Relaying
|
**Issuer:** Ospab Project (independent open-source project, not a registered legal entity)
|
||||||
|
**Last Updated:** May 2026
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 1. Overview and Scope
|
> [!IMPORTANT]
|
||||||
|
> This document is an **independent technical specification** authored by the Ospab Project. It is **not** an IEEE standard, an IETF RFC, or a product of any recognized standards body. It is formatted for clarity and references real, published standards (IEEE, IETF, ISO/IEC) to clarify how OSTP relates to existing specifications.
|
||||||
### 1.1 Introduction
|
|
||||||
This standard defines the wire format, state machine, and operational parameters of the **Ospab Stealth Transport Protocol (OSTP)**. OSTP is an application-agnostic, Layer 4 multiplexed transport pipeline designed to facilitate high-entropy, low-latency data replication between telemetry collectors (Collectors) and localized sensor bridges (Relays) over unreliable, packet-switched networks exhibiting severe electromagnetic line noise or analytical monitoring intercepts.
|
|
||||||
|
|
||||||
### 1.2 Scope
|
|
||||||
The scope of this specification includes:
|
|
||||||
* Differential spectral framing architectures to minimize traffic signature footprints.
|
|
||||||
* Zero-trust pre-shared cryptographic node initialization channels.
|
|
||||||
* Encapsulated channel multiplexing routines allowing distinct synchronous sub-streams to traverse parallel transport instances without mutual head-of-line blocking.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 2. Mathematical Notation and Conventions
|
## 1. OSI Reference Model Classification
|
||||||
|
|
||||||
* **$\oplus$**: Bitwise Exclusive OR (XOR).
|
OSTP is classified according to the **ISO/IEC 7498-1:1994** Open Systems Interconnection (OSI) Basic Reference Model:
|
||||||
* **$\text{SHA-256}(X)$**: Secure Hash Algorithm yielding 32 octets.
|
|
||||||
* **$\text{AEAD}_{\text{ChaChaPoly}}(Key, Nonce, AAD, PT)$**: Authenticated Encryption with Associated Data using IETF ChaCha20-Poly1305.
|
| OSI Layer | Number | OSTP Role |
|
||||||
* **$\text{Noise\_NNpsk0}$**: Noise Protocol Framework initialization pattern with a 32-octet Pre-Shared Key applied at pattern zero index.
|
|---|---|---|
|
||||||
|
| Application | 7 | Not in scope (handled by the client application) |
|
||||||
|
| Presentation | 6 | **Partial** — OSTP performs encryption and data transformation |
|
||||||
|
| Session | 5 | **Partial** — OSTP manages session state (handshake, teardown, roaming) |
|
||||||
|
| **Transport** | **4** | **Primary** — OSTP provides reliable, ordered, multiplexed delivery over UDP |
|
||||||
|
| Network | 3 | Not in scope (uses IP, provided by OS) |
|
||||||
|
| Data Link | 2 | Not in scope |
|
||||||
|
| Physical | 1 | Not in scope |
|
||||||
|
|
||||||
|
OSTP's primary classification is **Layer 4 (Transport)**, operating above UDP. It is analogous in positioning to QUIC [RFC 9000] and KCP, which are also Transport-layer protocols implemented above UDP.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 3. Core Frame Format (Wire Specification)
|
## 2. IETF Protocol Category
|
||||||
|
|
||||||
OSTP datagrams traversing the physical network interface are restricted to maximum MTU alignments and are categorized into Handshake Frames and Data Frames. All frames undergo an **In-Place Matrix Scrambling (IPMS)** transformation before transit to maintain constant uniform entropy across all fields.
|
The Ospab Project does not hold an RFC number. The following table shows the correct category this protocol *would* fall into under IETF taxonomy (RFC 2026, RFC 7841):
|
||||||
|
|
||||||
### 3.1 In-Place Matrix Scrambling (IPMS)
|
| Attribute | Value |
|
||||||
|
|---|---|
|
||||||
|
| Intended category | **Informational** (not Standards Track) |
|
||||||
|
| Submission type | **Independent Submission** (via Independent Submissions Editor) |
|
||||||
|
| RFC number | **None assigned** — this is not a published RFC |
|
||||||
|
| Standards body | None — this is not an IETF, IEEE, or ISO standard |
|
||||||
|
|
||||||
Prior to ingestion by physical Layer 3 endpoints, static identification values must undergo dynamic byte-layer transformations to suppress consistent statistical signatures (e.g., constant prefixes).
|
The distinction matters: a protocol can be well-designed and use only standardized primitives without itself being standardized. OSTP is in this category, alongside many production protocols (e.g., WireGuard was an Informational RFC 8669, VXLAN was an Informational RFC 7348).
|
||||||
|
|
||||||
Let $K_{\text{obf}}$ be the static 8-octet signal obfuscation key derived as:
|
|
||||||
$$K_{\text{obf}} = \text{SHA-256}(Key_{\text{access}})[0..7]$$
|
|
||||||
|
|
||||||
#### 3.1.1 Handshake Mode IPMS
|
|
||||||
For initial channel establishment packets (where $S_{\text{active}} = \text{False}$):
|
|
||||||
$$\text{Payload}_{\text{scrambled}}[i] = \text{Payload}_{\text{raw}}[i] \oplus K_{\text{obf}}[i \pmod 8], \quad \forall i \in [0..3]$$
|
|
||||||
|
|
||||||
#### 3.1.2 Operational Mode IPMS
|
|
||||||
For subsequent high-speed transmission cycles (where $S_{\text{active}} = \text{True}$):
|
|
||||||
The 8-octet packet counter ($Nonce_{\text{raw}}$) and 4-octet channel address ($SessionID_{\text{raw}}$) undergo two-tier skew-shaping:
|
|
||||||
|
|
||||||
1. **Counter Masking:**
|
|
||||||
$$Nonce_{\text{scrambled}}[i] = Nonce_{\text{raw}}[i] \oplus K_{\text{obf}}[i], \quad i \in [0..7]$$
|
|
||||||
2. **Channel Identity Masking:**
|
|
||||||
$$SessionID_{\text{scrambled}}[i] = SessionID_{\text{raw}}[i] \oplus (Nonce_{\text{raw}} \& \text{0xFFFFFFFF})[i], \quad i \in [0..3]$$
|
|
||||||
|
|
||||||
Since $Nonce_{\text{raw}}$ increments deterministically upon each transmission, the resultant $SessionID_{\text{scrambled}}$ prefix exhibits zero operational auto-correlation across consecutive packets, rendering statistical filtering models obsolete.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 4. Cryptographic Pipeline Initialization
|
## 3. Cryptographic Primitive Classification
|
||||||
|
|
||||||
The validation handshake sequence utilizes the `Noise_NNpsk0_25519_ChaChaPoly_BLAKE2s` specification. All verification variables, including node registry tokens ($Key_{\text{access}}$), are wrapped in the initial cipher payload $e, psk$ pattern.
|
All cryptographic components used by OSTP are standardized and published by recognized bodies:
|
||||||
|
|
||||||
```text
|
| Primitive | Standard | Published By |
|
||||||
Initiator (Relay Bridge) Responder (Collector Node)
|
|---|---|---|
|
||||||
------------------------ --------------------------
|
| Key Agreement | X25519 (ECDH over Curve25519) | RFC 7748 (IETF) |
|
||||||
| |
|
| AEAD Cipher | ChaCha20-Poly1305 | RFC 8439 (IETF) |
|
||||||
| [Scrambled e, es, psk] |
|
| Hash / HMAC | SHA-256, HMAC-SHA-256 | FIPS PUB 180-4 (NIST), RFC 2104 (IETF) |
|
||||||
|------------------------------------------->| (Session Instantiation)
|
| Handshake Framework | Noise Protocol Framework (NNpsk0) | Independent Spec [noiseprotocol.org] |
|
||||||
| |
|
| Hash (Noise internal) | BLAKE2s | RFC 7693 (IETF) |
|
||||||
| [Scrambled e, ee] |
|
| Transport Substrate | UDP | RFC 768 (IETF) |
|
||||||
|<-------------------------------------------| (Transport Key Split)
|
|
||||||
| |
|
OSTP does **not** use any proprietary or unreviewed cryptographic algorithms. All primitives listed above are publicly specified and have received significant academic and industry scrutiny.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Frame Format Specification
|
||||||
|
|
||||||
|
### 4.1 Wire Format
|
||||||
|
|
||||||
|
All multi-byte fields use network byte order (big-endian), consistent with IETF convention (RFC 1700).
|
||||||
|
|
||||||
|
```
|
||||||
|
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 + Padding (Variable) ~
|
||||||
|
| |
|
||||||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||||
|
| 16-Octet Poly1305 Authentication Tag |
|
||||||
|
| |
|
||||||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||||
```
|
```
|
||||||
|
|
||||||
---
|
**Header size:** 12 bytes (fixed)
|
||||||
|
**Minimum datagram size:** 28 bytes (12 header + 16 auth tag, empty payload)
|
||||||
|
**Maximum datagram size:** bounded by UDP MTU (typically ≤ 1472 bytes for standard Ethernet)
|
||||||
|
|
||||||
## 5. Spectral Frame Padding (Adaptive Alignment)
|
### 4.2 Header Obfuscation
|
||||||
|
|
||||||
To counter traffic profiling through Packet Length Analysis (PLA), the protocol utilizes a discrete adaptive alignment system. Telemetry payloads are dynamically resized by the `AdaptivePadder` sub-system using one of the conformant scaling strategies specified below prior to the AEAD application block.
|
The Session ID field is masked per-packet using HMAC-SHA-256, so that no static identifier appears on the wire:
|
||||||
|
|
||||||
### 5.1 Scaling Strategies
|
```
|
||||||
1. **Fixed Boundary Alignment**: Payload lengths are expanded to static preconfigured telemetry buffer alignments.
|
K_obf = SHA-256(access_key || "obfusca")[0..7]
|
||||||
2. **High-Fidelity Adaptive Grid**: Padding lengths are bucketed dynamically to modulo-64 boundaries, augmented by cryptographically generated high-entropy noise vectors ranging between $0$ and $96$ octets to randomize analytical signatures.
|
mask[0..3] = HMAC-SHA-256(K_obf, Nonce)[0..3]
|
||||||
3. **Profile-Aligned Block Sizes**: Frames are structured to conform strictly to common operational system thresholds, such as VideoStream (MTU-optimized) or RPC Burst topologies.
|
Wire_SID = SID_raw XOR mask
|
||||||
|
```
|
||||||
|
|
||||||
### 5.2 Data Padding Composition
|
Because the Nonce is unique per packet, `mask` is cryptographically independent for every datagram. The Nonce is transmitted in plaintext; its integrity is protected by the AEAD authentication tag which covers the 12-byte header as Additional Authenticated Data (AAD).
|
||||||
Conformant implementations MUST fill designated padding regions with true cryptographic randomness derived from an OS-provided entropy pool (e.g., `/dev/urandom`) to negate secondary information leaks through dynamic packet compression analyzer attempts.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 6. Multiplexing Geometry
|
## 5. ARQ Reliability Classification
|
||||||
|
|
||||||
The protocol supports internal transport pipeline splitting, defined as the capability to host multiple logically separate Noise sessions over a singular physical local socket descriptor. This guarantees High Availability (HA) failover, seamless edge-node IP-roaming, and load distribution under high sensor grid polling frequency conditions.
|
OSTP's reliability mechanism is classified as **Selective Repeat ARQ** (SR-ARQ), a well-established technique described in:
|
||||||
|
|
||||||
|
- Tanenbaum, A. S., "Computer Networks", 5th ed., Prentice Hall, 2011. (Chapter 3.4)
|
||||||
|
- Forouzan, B. A., "Data Communications and Networking", 5th ed., McGraw-Hill, 2012.
|
||||||
|
- ISO/IEC 7498-1 (error recovery at transport layer)
|
||||||
|
|
||||||
|
Selective Repeat ARQ allows the receiver to request retransmission of only lost packets, unlike Go-Back-N ARQ which requires retransmitting all packets after a loss. This makes OSTP more efficient on high-loss links.
|
||||||
|
|
||||||
|
| Parameter | Default Value | Description |
|
||||||
|
|---|---|---|
|
||||||
|
| Sequence number width | 64 bits | Nonce field, monotonically increasing |
|
||||||
|
| Reorder window | 2^18 (262,144) | Maximum acceptable out-of-order offset |
|
||||||
|
| Reorder buffer | 8,192 packets | Maximum buffered-out-of-order packets |
|
||||||
|
| RTO | 100 ms | Retransmission timeout |
|
||||||
|
| ACK delay | 5 ms | Coalescing delay before sending ACK |
|
||||||
|
| Max retries | 8 | Per-packet retransmission limit |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Comparison to Related Protocols
|
||||||
|
|
||||||
|
| Feature | OSTP | WireGuard | QUIC | OpenVPN (UDP) |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| Transport substrate | UDP | UDP | UDP | UDP |
|
||||||
|
| OSI Layer | 4 | 3–4 | 4 | 3–4 |
|
||||||
|
| Handshake framework | Noise NNpsk0 | Noise IKpsk2 | TLS 1.3 | TLS |
|
||||||
|
| AEAD cipher | ChaCha20-Poly1305 | ChaCha20-Poly1305 | AES-GCM / ChaCha | AES-CBC / AES-GCM |
|
||||||
|
| Built-in reliability (ARQ) | Yes (Selective Repeat) | No (relies on IP) | Yes (QUIC streams) | No |
|
||||||
|
| Traffic obfuscation | Yes (HMAC-masked headers, adaptive padding) | No | Partial (QUIC spin bit) | No |
|
||||||
|
| IP roaming support | Yes | Yes | Yes | No |
|
||||||
|
| Stream multiplexing | Yes | No (single tunnel) | Yes | No |
|
||||||
|
| Standardized | No (independent) | RFC 8669 (Informational) | RFC 9000 (Standards Track) | No |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. Threat Model Summary
|
||||||
|
|
||||||
|
OSTP is designed against the following adversary model:
|
||||||
|
|
||||||
|
1. **Passive deep packet inspection (DPI):** Mitigated by per-packet HMAC-masked headers and adaptive payload padding, ensuring no static signatures are present on the wire.
|
||||||
|
2. **Active probing:** An active prober sends arbitrary data to the server. Mitigated by requiring a valid authenticated Noise handshake — the server produces no response to invalid packets.
|
||||||
|
3. **Replay attacks:** Mitigated by a 30-second timestamp window in the handshake payload and a short-lived handshake replay cache.
|
||||||
|
4. **Session flooding (DoS):** Mitigated by a hard cap of 1,024 concurrent sessions on the server; excess handshakes are silently dropped.
|
||||||
|
5. **IP roaming attacks:** Prevented by the requirement that all peer address updates are gated on successful AEAD authentication of the incoming packet.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 8. Standards Referenced
|
||||||
|
|
||||||
|
The following published standards are referenced or used by OSTP:
|
||||||
|
|
||||||
|
| Standard | Title | Body |
|
||||||
|
|---|---|---|
|
||||||
|
| ISO/IEC 7498-1:1994 | OSI Basic Reference Model | ISO/IEC JTC 1 |
|
||||||
|
| RFC 768 | User Datagram Protocol | IETF |
|
||||||
|
| RFC 2104 | HMAC: Keyed-Hashing for Message Authentication | IETF |
|
||||||
|
| RFC 2119 | Key words for use in RFCs | IETF |
|
||||||
|
| RFC 7693 | The BLAKE2 Cryptographic Hash and MAC | IETF |
|
||||||
|
| RFC 7748 | Elliptic Curves for Security (X25519) | IETF |
|
||||||
|
| RFC 8174 | Ambiguity of Uppercase vs Lowercase in RFC 2119 | IETF |
|
||||||
|
| RFC 8439 | ChaCha20 and Poly1305 for IETF Protocols | IETF |
|
||||||
|
| FIPS PUB 180-4 | Secure Hash Standard (SHA-256) | NIST |
|
||||||
|
| Noise Spec Rev.34 | The Noise Protocol Framework | Trevor Perrin (independent) |
|
||||||
|
|
|
||||||
|
|
@ -1,205 +1,358 @@
|
||||||
Internet Engineering Task Force (IETF) Georgiy S.
|
Independent Submission Georgiy S.
|
||||||
Request for Comments: 9842 Ospab Foundation
|
Ospab Project
|
||||||
Category: Standards Track May 2026
|
Category: Informational May 2026
|
||||||
ISSN: 2070-1721
|
|
||||||
|
|
||||||
|
|
||||||
The Ospab Stealth Transport Protocol (OSTP)
|
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
|
Abstract
|
||||||
|
|
||||||
This document specifies the Ospab Stealth Transport Protocol (OSTP),
|
This document specifies the Ospab Stealth Transport Protocol (OSTP),
|
||||||
a high-entropy, multiplexed Layer 4 transport pipeline developed to
|
a multiplexed, application-agnostic Layer 4 transport protocol
|
||||||
achieve secure, resilient data replication between distributed nodes
|
designed for secure, censorship-resistant communication over
|
||||||
across networks characterized by severe stochastic disturbance and
|
hostile networks. OSTP employs the Noise Protocol Framework for
|
||||||
hostile packet-level telemetry inspections. OSTP incorporates
|
authenticated key exchange, IETF ChaCha20-Poly1305 for symmetric
|
||||||
session-state scrambling matrices and cryptographic block boundary
|
encryption, HMAC-SHA-256-based per-packet header masking for
|
||||||
realignment to completely suppress statistical traffic signatures,
|
traffic obfuscation, and a selective-repeat ARQ mechanism for
|
||||||
guaranteeing absolute wire-level protocol indistinguishability.
|
reliability over UDP. The design goal is wire-level
|
||||||
|
indistinguishability from random noise, resistance to Deep Packet
|
||||||
Status of This Memo
|
Inspection (DPI), and resilience to IP-roaming events.
|
||||||
|
|
||||||
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
|
Table of Contents
|
||||||
|
|
||||||
1. Introduction ................................................ 2
|
1. Introduction ................................................ 2
|
||||||
1.1. Terminology and Requirements Language .................. 2
|
1.1. Motivation .............................................. 2
|
||||||
2. Architecture and Operations Model ........................... 3
|
1.2. Terminology and Requirements Language .................. 2
|
||||||
3. In-Place Scrambling Transformation (IPST) .................. 3
|
1.3. Relation to Existing Standards ......................... 3
|
||||||
3.1. Derived Entropy Initialization ......................... 3
|
2. Protocol Architecture ...................................... 3
|
||||||
3.2. Operational State Scrambling ........................... 4
|
2.1. Layer Classification ................................... 3
|
||||||
4. Frame Specification and Formatting .......................... 4
|
2.2. Node Roles .............................................. 3
|
||||||
4.1. Structural Diagram ..................................... 5
|
2.3. Transport Substrate .................................... 3
|
||||||
5. Cryptographic Synchronization ............................... 5
|
3. Frame Format ................................................ 4
|
||||||
6. Multiplexing Support ........................................ 6
|
3.1. Structural Diagram ..................................... 4
|
||||||
7. IANA Considerations ......................................... 6
|
3.2. Field Descriptions ..................................... 4
|
||||||
8. Security Considerations ..................................... 6
|
4. Header Obfuscation .......................................... 5
|
||||||
9. References .................................................. 7
|
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. Introduction
|
||||||
|
|
||||||
Traditional encapsulation protocols often introduce static sequence
|
1.1. Motivation
|
||||||
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
|
Standard tunneling protocols (e.g., OpenVPN, WireGuard) produce
|
||||||
model by employing mathematical state scrambling and randomized
|
traffic patterns that are reliably identified by stateful DPI
|
||||||
frame-boundary injection prior to final serialization. The primary
|
systems through static magic bytes, fixed handshake sizes, or
|
||||||
design goal is complete convergence toward Maximum Uniform Entropy,
|
predictable sequence patterns. OSTP is designed to resist such
|
||||||
yielding UDP datagrams statistically identical to pure line noise.
|
fingerprinting by ensuring that every byte on the wire, including
|
||||||
|
header fields, appears statistically indistinguishable from
|
||||||
|
uniformly random data.
|
||||||
|
|
||||||
1.1. Terminology and Requirements Language
|
1.2. Terminology and Requirements Language
|
||||||
|
|
||||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
|
||||||
and "OPTIONAL" in this document are to be interpreted as described
|
and "OPTIONAL" in this document are to be interpreted as described
|
||||||
in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in
|
in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in
|
||||||
all capitals, as shown here.
|
all capitals.
|
||||||
|
|
||||||
2. Architecture and Operations Model
|
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.
|
||||||
|
|
||||||
OSTP operates in a client-server paradigm, hereinafter referred to
|
1.3. Relation to Existing Standards
|
||||||
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)
|
OSTP uses the following standardized components:
|
||||||
|
|
||||||
Before transit onto the network layer, every frame is subject to
|
- Noise Protocol Framework [Noise] with pattern NNpsk0, using
|
||||||
In-Place Scrambling Transformation (IPST). This operation mutates
|
Curve25519 (X25519 [RFC7748]) for key agreement, ChaCha20-
|
||||||
static parameters dynamically, removing spatial correlation
|
Poly1305 [RFC8439] for AEAD, and BLAKE2s [RFC7693] for hashing.
|
||||||
patterns across packets.
|
- HMAC-SHA-256 [RFC2104][FIPS180-4] for per-packet header masking.
|
||||||
|
- UDP [RFC0768] as the transport substrate.
|
||||||
|
|
||||||
3.1. Derived Entropy Initialization
|
OSTP does not claim compliance with or supersede any IETF or IEEE
|
||||||
|
standard. It is an independent protocol specification.
|
||||||
|
|
||||||
Nodes MUST configure an authorized ASCII Registration Key (denoted
|
2. Protocol Architecture
|
||||||
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]
|
2.1. Layer Classification
|
||||||
|
|
||||||
The derived vector 'K_scram' MUST remain local to the nodes and
|
In terms of the OSI Reference Model [ISO7498-1]:
|
||||||
SHALL NEVER traverse the physical media.
|
|
||||||
|
|
||||||
3.2. Operational State Scrambling
|
- 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.
|
||||||
|
|
||||||
Each frame contains a 4-octet Session ID (SID) and an 8-octet
|
2.2. Node Roles
|
||||||
inbound/outbound sequence counter (Nonce).
|
|
||||||
|
|
||||||
1. Initialization Vector Phase:
|
OSTP operates in a client-server paradigm:
|
||||||
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]
|
Initiator (Client): Establishes connections, generates Session IDs,
|
||||||
|
and drives handshake initiation.
|
||||||
|
Responder (Server): Accepts connections, validates credentials,
|
||||||
|
and relays application-layer traffic.
|
||||||
|
|
||||||
2. Active Session Phase:
|
2.3. Transport Substrate
|
||||||
Once the secure channel is established, multi-tier scrambling
|
|
||||||
obliterates deterministic sequences:
|
|
||||||
|
|
||||||
A. The Nonce field is scrambled using the static vector:
|
All OSTP datagrams are carried over UDP. The Initiator MUST support
|
||||||
Nonce_scr[i] = Nonce_raw[i] ^ K_scram[i], for i in [0..7]
|
IP-roaming by allowing the Responder to update the peer address upon
|
||||||
|
receiving an authenticated packet from a new source address.
|
||||||
|
|
||||||
B. The Session ID is scrambled using high-frequency entropy
|
3. Frame Format
|
||||||
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
|
3.1. Structural Diagram
|
||||||
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
|
All multi-byte fields are in network byte order (big-endian).
|
||||||
|
|
||||||
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
|
||||||
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
|
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) |
|
| Masked Session Identifier (32 bits) |
|
||||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||||
| |
|
| |
|
||||||
+ Scrambled Nonce (64 bits) +
|
+ Plaintext Nonce (64 bits) +
|
||||||
| |
|
| |
|
||||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||||
| |
|
| |
|
||||||
~ AEAD Authenticated Ciphertext ~
|
~ AEAD Ciphertext (Variable Length) ~
|
||||||
| (Variable Length Payload) |
|
|
||||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
||||||
| |
|
| |
|
||||||
~ Cryptographic Dynamic Padding Block ~
|
|
||||||
| (Randomized Noise Density) |
|
|
||||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||||
| 16-Octet Authentication Tag |
|
| 16-Octet Poly1305 Authentication Tag |
|
||||||
|
| |
|
||||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||||
|
|
||||||
5. Cryptographic Synchronization
|
Total header size: 12 octets (4 SID + 8 Nonce).
|
||||||
|
Minimum frame size: 12 + 16 = 28 octets (empty payload + tag).
|
||||||
|
|
||||||
OSTP implementations MUST execute a Noise Protocol Framework exchange
|
3.2. Field Descriptions
|
||||||
utilizing the `Noise_NNpsk0_25519_ChaChaPoly_BLAKE2s` pattern.
|
|
||||||
|
|
||||||
1. The Registration Key (Key_reg) is converted to a 32-octet strong
|
Masked Session Identifier (32 bits):
|
||||||
pre-shared key (PSK) via keyed hash derivation.
|
The Session ID XOR-masked with the first 4 bytes of
|
||||||
2. The PSK is integrated into the state at pattern position zero,
|
HMAC-SHA-256(K_obf, Nonce). See Section 4.
|
||||||
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
|
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.
|
||||||
|
|
||||||
To prevent head-of-line (HoL) bottlenecks associated with reliable
|
AEAD Ciphertext:
|
||||||
message delivery, OSTP permits binding multiple logical channel
|
The inner payload encrypted with ChaCha20-Poly1305 using the
|
||||||
instances to a common hardware UDP socket. Individual channels execute
|
session key, Nonce as IV, and the 12-byte header as AAD.
|
||||||
independent Noise state engines. Endpoint transitions (IP roaming)
|
|
||||||
are handled dynamically via automatic remote source updates upon
|
|
||||||
successful AEAD authentication validation.
|
|
||||||
|
|
||||||
7. IANA Considerations
|
Authentication Tag:
|
||||||
|
The 16-byte Poly1305 MAC produced by the AEAD operation.
|
||||||
|
|
||||||
This document has no actions for IANA. All assignments of local UDP
|
4. Header Obfuscation
|
||||||
ports are considered system-local, and registry configurations
|
|
||||||
are intentionally omitted to deny static footprint registration.
|
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. Security Considerations
|
||||||
|
|
||||||
All implementations MUST rigorously safeguard sequence counter integrity.
|
8.1. Nonce Exhaustion
|
||||||
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
|
The Nonce field is 64 bits wide. At 1,000,000 packets per second,
|
||||||
zero-padding (0x00) is strictly forbidden, as variable compressibility
|
a single session would exhaust the nonce space in approximately
|
||||||
profiles in intermediary compression layers may leak payload lengths.
|
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
|
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
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||||
|
|
||||||
[RFC8174] Leiba, B., "Ambiguity of Uppercase %s in RFC 2119
|
[RFC7322] Flanagan, H., Ginoza, S., "RFC Style Guide", RFC 7322,
|
||||||
Ambiguity", BCP 14, RFC 8174, May 2017.
|
September 2014.
|
||||||
|
|
||||||
[Noise] Trevor Perrin, "The Noise Protocol Framework", 2018.
|
[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
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue