Independent Submission X. x1co Internet-Draft x1colegal Intended status: Experimental 7 June 2026 Expires: 9 December 2026 UDP Speedy Transmission Protocol Secure (USTPS) draft-x1co-ustps-00 Abstract 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, selective retransmission, out-of-order acceptance, 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. Status of This Memo 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 9 December 2026. Copyright Notice 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. x1co Expires 9 December 2026 [Page 1] Internet-Draft USTPS June 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Transport Overview . . . . . . . . . . . . . . . . . . . . . 3 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 3 6. Reliability Model . . . . . . . . . . . . . . . . . . . . . . 4 7. Head-of-Line Blocking . . . . . . . . . . . . . . . . . . . . 4 8. Security Model . . . . . . . . . . . . . . . . . . . . . . . 4 9. Operational Notes . . . . . . . . . . . . . . . . . . . . . . 5 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 11. Security Considerations . . . . . . . . . . . . . . . . . . . 5 12. Normative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction 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 main target in current implementations is media streaming, although the transport itself can be adapted for other applications that can tolerate or explicitly manage reordering. USTPS combines three properties: reliable recovery of missing packets, transport-level unordered behavior, and mandatory authenticated encryption. 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. 2. Terminology 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. 3. Design Goals USTPS has the following goals: * Run directly over UDP. x1co Expires 9 December 2026 [Page 2] Internet-Draft USTPS June 2026 * Provide packet-level authenticated encryption. * Recover missing packets with selective retransmission. * Accept and process later packets even when earlier packets are missing. * Expose sufficient metadata for an application to rebuild ordered output if required. USTPS is not intended to emulate TCP semantics. In particular, it does not provide transport-layer ordered byte-stream delivery. 4. Transport Overview 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, and retransmission. 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 5. Packet Format The inner USTPS transport packet begins with the magic value UST1, meaning "UDP Speedy Transmission Protocol, version 1". The transport packet fields are: * Magic: 4 octets * Type: 1 octet * Flags: 1 octet x1co Expires 9 December 2026 [Page 3] Internet-Draft USTPS June 2026 * Sequence: 32 bits * Stream Position: 64 bits * Payload Length: 16 bits * Payload: variable Packet types currently used by implementations include DATA, ACK, RETRANSMIT_REQUEST, HELLO, and CLOSE. 6. Reliability Model 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) may be used as a fallback if explicit retransmission requests are delayed or lost. 7. Head-of-Line Blocking 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. 8. Security Model USTPS uses mandatory AEAD at the packet layer. Implementations currently support ChaCha20-Poly1305, AES-256-GCM, and AES-128-GCM. A client and server perform an ephemeral 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, while UST1 identifies the decrypted inner transport packet. x1co Expires 9 December 2026 [Page 4] Internet-Draft USTPS June 2026 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. 9. Operational Notes 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, cipher selection, and optional congestion control. These are implementation details and not normative wire requirements unless later specified. 10. IANA Considerations This document has no IANA actions. 11. Security Considerations 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. 12. Normative 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 vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . Author's Address x1co Expires 9 December 2026 [Page 5] Internet-Draft USTPS June 2026 x1co x1colegal Email: x1colegal@outlook.com.br x1co Expires 9 December 2026 [Page 6]