ospab
/
ostp
mirror of https://github.com/ospab/ostp.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

docs: replace fake standards with official OSTP specifications

This commit is contained in:
ospab 2026-05-15 18:49:32 +03:00
parent 96003a1dc8
commit 2952d3aa3c
2 changed files with 0 additions and 531 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

173
docs/en/ieee_spec.md
View File

@ -1,173 +0,0 @@
# OSTP Technical Specification
## OSI Layer Classification and Protocol Architecture
**Document Type:** Independent Technical Specification
**Status:** Informational
**Issuer:** Ospab Project (independent open-source project, not a registered legal entity)
**Last Updated:** May 2026
---
> [!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. OSI Reference Model Classification
OSTP is classified according to the **ISO/IEC 7498-1:1994** Open Systems Interconnection (OSI) Basic Reference Model:
| OSI Layer | Number | OSTP Role |
|---|---|---|
| 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.
---
## 2. IETF Protocol Category
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):
| 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 |
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).
---
## 3. Cryptographic Primitive Classification
All cryptographic components used by OSTP are standardized and published by recognized bodies:
| Primitive | Standard | Published By |
|---|---|---|
| Key Agreement | X25519 (ECDH over Curve25519) | RFC 7748 (IETF) |
| AEAD Cipher | ChaCha20-Poly1305 | RFC 8439 (IETF) |
| Hash / HMAC | SHA-256, HMAC-SHA-256 | FIPS PUB 180-4 (NIST), RFC 2104 (IETF) |
| Handshake Framework | Noise Protocol Framework (NNpsk0) | Independent Spec [noiseprotocol.org] |
| Hash (Noise internal) | BLAKE2s | RFC 7693 (IETF) |
| Transport Substrate | UDP | RFC 768 (IETF) |
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)
### 4.2 Header Obfuscation
The Session ID field is masked per-packet using HMAC-SHA-256, so that no static identifier appears on the wire:
```
K_obf = SHA-256(access_key || "obfusca")[0..7]
mask[0..3] = HMAC-SHA-256(K_obf, Nonce)[0..3]
Wire_SID = SID_raw XOR mask
```
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).
---
## 5. ARQ Reliability Classification
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) |

358
docs/en/rfc_ostp.txt
View File

@ -1,358 +0,0 @@
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