| Internet-Draft | USTPS | June 2026 |
| x1co | Expires 14 December 2026 | [Page] |
This document describes UDP Speedy Transmission Protocol Secure (USTPS), an experimental secure transport built on UDP for low-latency streaming-oriented applications. USTPS provides packet-level authenticated encryption for DATA packets, human-readable plaintext transport control, binary UPACK DATA framing, selective retransmission, out-of-order acceptance, adaptive retransmission timeout based on RTT sampling, and application-visible stream position metadata. USTPS is intentionally unordered at the transport layer and is designed to avoid transport-level Head-of-Line blocking.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 14 December 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
USTPS is an experimental transport that runs directly over UDP. It was designed for applications that prefer continuing delivery of later packets even when earlier packets are temporarily missing. Its current public implementation focus is media streaming, although the transport can be adapted to other applications that can tolerate or explicitly manage reordering.¶
USTPS combines reliable recovery of missing packets, transport-level unordered behavior, and mandatory authenticated protection for application payload packets. Unlike TCP, USTPS does not force byte-stream ordering in the transport. Unlike QUIC streams, USTPS does not define per-stream in-order delivery semantics in the transport itself. Instead, it exposes both a packet sequence number and an application-facing stream position so that upper layers may reconstruct ordered output when needed.¶
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.¶
USTPS has the following goals:¶
USTPS is not intended to emulate TCP semantics. In particular, it does not provide transport-layer ordered byte-stream delivery and does not define congestion control.¶
Each USTPS DATA packet contains a transport sequence number (seq) and a stream position (stream_pos). The sequence number is used for reliability functions such as acknowledgement, gap detection, retransmission, and RTT sampling. The stream position identifies where the payload belongs in the application's logical byte stream.¶
Upon reception of DATA packets, a receiver SHOULD acknowledge unique packets and MAY immediately pass packet payload upward, even when a lower sequence number has not yet arrived. If an application requires ordered output, it MUST use stream_pos to reconstruct that order.¶
Example arrival order:¶
Physical arrival: 1 2 3 5 6
Missing packet : 4
Receiver action: accept 5 and 6, request retransmission of 4
Later arrival : 4
Logical order : 1 2 3 4 5 6
¶
The transport uses two inner wire formats.¶
Plaintext control packets are serialized as human-readable ASCII records. Current public implementations use forms such as ACK: 10, ACK: 10 11 12, NACK: 42, HELLO: BASE64..., and CLOSE:. HELLO carries binary handshake material in Base64 when required.¶
DATA packets use a binary frame format named UPACK, identified on the wire by the 4-octet marker UPAK.¶
The UPACK DATA frame fields are:¶
Packet types currently used by implementations include DATA, ACK, RETRANSMIT_REQUEST, HELLO, and CLOSE.¶
Current public implementations protect DATA packets with an outer AEAD envelope identified by the magic value USS1. After decryption, DATA typically begins with UPAK, while plaintext control appears as readable ASCII control lines.¶
A client begins by sending a plaintext HELLO carrying its X25519 public key and requested cipher. The server does not send application DATA immediately. Instead, it replies with a plaintext challenge containing a random token, a generated Base64 session identifier, the selected cipher, and the server public key.¶
The client MUST answer with the received token. Only after that token round-trip succeeds does the server derive the AEAD session key and begin sending DATA. After validation, the session is tracked by the generated Base64 session identifier rather than solely by the original IP address and UDP source port.¶
Subsequent keepalive or rebind messages MAY use the session identifier to resume an existing session after a path change or source-port change.¶
USTPS uses selective retransmission. A sender stores transmitted packets in a retransmission buffer until they are acknowledged or otherwise retired. A receiver detects gaps in observed sequence numbers and requests retransmission only for missing packets.¶
USTPS intentionally avoids Go-Back-N behavior. Later packets are not discarded solely because an earlier packet is missing. Retransmission timeout (RTO) is used as a fallback if explicit retransmission requests are delayed or lost. Current implementations adapt RTO from measured RTT samples taken from non-retransmitted acknowledged packets.¶
USTPS is designed to avoid transport-level Head-of-Line blocking. A missing packet does not prevent receipt, acknowledgement, buffering, or application visibility of later packets. This differs from TCP, where the transport enforces ordered byte-stream delivery, and from individual QUIC streams, which remain in-order within each stream.¶
If an application chooses to emit only ordered output, any waiting that occurs is an application-layer decision, not a USTPS transport requirement.¶
USTPS uses mandatory AEAD for DATA packets. Implementations currently support ChaCha20-Poly1305, AES-256-GCM, and AES-128-GCM. Clients and servers perform an X25519-based key exchange when a client joins, and a separate session key is derived per client session.¶
The outer secure envelope begins with the magic value USS1, meaning "UDP Speedy Secure, version 1". In current implementations, USS1 identifies the encrypted/authenticated outer framing for DATA, while readable plaintext control lines identify transport control and UPAK identifies decrypted binary DATA framing.¶
Implementations described by this document use a persistent server host key and Trust On First Use (TOFU) on the client side to detect unexpected server key changes across reconnects.¶
Current public implementations support client-side path recovery. If the client detects that the active UDP path has stalled, it may recreate its UDP socket, resolve the server address again, and attempt to resume the existing session by the stored session identifier.¶
If resume fails, the client may fall back to a fresh handshake. This behavior is intended to allow mobile or roaming devices to change networks without immediately forcing a client restart.¶
USTPS has been implemented and exercised as a Beta-grade experimental protocol. Current public code and testing are primarily focused on streaming over local networks and over public Internet paths where UDP is available. Current implementations are multi-client and perform per-client session key derivation.¶
Current public implementations also expose knobs such as simulated packet loss, output buffering delay, and cipher selection. These are implementation details and not normative wire requirements unless later specified.¶
This document has no IANA actions.¶
USTPS relies on correct AEAD use, correct nonce handling, correct key derivation, and authenticated peer identity checks. Implementations MUST ensure nonce uniqueness for a given key. Implementations SHOULD authenticate server identity changes using a trust model such as TOFU or a stronger out-of-band validation method.¶
Because USTPS is unordered, applications that require ordered interpretation MUST reconstruct order using application-visible metadata such as stream_pos. Applications that incorrectly treat physical arrival order as logical order may mis-handle retransmitted data.¶
Implementations that support path migration or session resume MUST ensure that only holders of the valid session state can successfully resume the session.¶