Independent Submission X. x1co Internet-Draft x1colegal Intended status: Experimental 17 June 2026 Expires: 19 December 2026 UDP Speedy Transmission Protocol Secure (USTPS) draft-x1co-ustps-04 Abstract This document describes UDP Speedy Transmission Protocol Secure (USTPS), an experimental transport built directly on UDP for low- latency and loss-tolerant applications. USTPS provides authenticated encryption for DATA packets, readable plaintext control records authenticated by HMAC where applicable, binary UPACK DATA framing, selective retransmission, out-of-order acceptance, adaptive retransmission timeout, optional congestion control, 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 19 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. x1co Expires 19 December 2026 [Page 1] Internet-Draft USTPS June 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Transport Overview . . . . . . . . . . . . . . . . . . . . . 4 5. Wire Formats . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Plaintext Control Records . . . . . . . . . . . . . . . . 5 5.2. UPACK DATA Format . . . . . . . . . . . . . . . . . . . . 5 5.3. Outer Secure Envelope . . . . . . . . . . . . . . . . . . 6 6. Handshake and Session Model . . . . . . . . . . . . . . . . . 6 6.1. Implementation Flow . . . . . . . . . . . . . . . . . . . 6 7. Reliability Model . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Receiver Behavior . . . . . . . . . . . . . . . . . . . . 7 7.2. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 7 8. Head-of-Line Blocking . . . . . . . . . . . . . . . . . . . . 8 9. Congestion Control . . . . . . . . . . . . . . . . . . . . . 8 10. Security Model . . . . . . . . . . . . . . . . . . . . . . . 8 11. Session Binding and Network Changes . . . . . . . . . . . . . 9 12. Implementation Guidance . . . . . . . . . . . . . . . . . . . 9 13. Operational Notes . . . . . . . . . . . . . . . . . . . . . . 10 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 15. Security Considerations . . . . . . . . . . . . . . . . . . . 10 16. Normative References . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 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. Current public implementations focus primarily on streaming, but the transport can also be adapted to other applications that either tolerate reordering or explicitly rebuild logical order at a higher layer. x1co Expires 19 December 2026 [Page 2] Internet-Draft USTPS June 2026 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 a single in-order byte stream in the transport itself. Unlike an individual QUIC stream, USTPS does not define in-order transport semantics inside the transport. Instead, it exposes both a packet sequence number and an application-facing stream position so that upper layers can reconstruct ordered output only 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. This document uses the following terms: * seq: transport sequence number used for acknowledgement, loss detection, retransmission, and RTT measurement. * stream_pos: application-facing byte position indicating where a payload belongs in the logical ordered byte stream. * UPACK: the binary USTPS DATA frame format, identified on the wire by the marker UPAK. * Retry Token: the challenge token that proves reachability of the apparent source address before the server begins sending encrypted DATA. 3. Design Goals USTPS has the following goals: * Run directly over UDP. * Provide authenticated protection for DATA packets. * 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. x1co Expires 19 December 2026 [Page 3] Internet-Draft USTPS June 2026 * Authenticate the retry-token handshake before the server starts sending encrypted DATA. * Allow optional sender-side congestion control without changing the unordered transport model. USTPS is not intended to emulate TCP semantics. In particular, it does not provide transport-layer ordered byte-stream delivery. Optional congestion control, when implemented, changes only the sender rate policy and does not turn USTPS into a TCP-like ordered transport. 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, 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 5. Wire Formats USTPS uses three practical wire layers in current public implementations: * plaintext transport control records * binary DATA packets using UPACK * an outer AEAD envelope for DATA packets x1co Expires 19 December 2026 [Page 4] Internet-Draft USTPS June 2026 5.1. Plaintext Control Records Current public implementations serialize transport control packets as readable ASCII records. Typical forms include: * ACK: 10 MAC: * ACK: 10 11 12 MAC: * NACK: 42 MAC: * NACK: 42 43 44 MAC: * HELLO: BASE64... * CLOSE: ACK and NACK records remain plaintext for observability and debugging, but current implementations authenticate them with an HMAC derived from session state. The MAC: value is verified before the control record reaches the transport state machine. Current implementations batch up to 128 acknowledged or missing sequence numbers in one control record. 5.2. UPACK DATA Format 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: * Magic: 4 octets * Type: 1 octet * Flags: 1 octet * 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. x1co Expires 19 December 2026 [Page 5] Internet-Draft USTPS June 2026 5.3. Outer Secure Envelope Current public implementations protect DATA packets with an outer AEAD envelope identified by the magic value USS1, meaning "UDP Speedy Secure, version 1". After decryption, DATA typically begins with UPAK, while plaintext transport control remains readable ASCII. 6. Handshake and Session Model A client begins by sending a plaintext HELLO carrying its X25519 public key, requested AEAD cipher, and requested congestion-control mode. The server does not send application DATA immediately. Instead, it replies with a plaintext challenge containing: * a random retry token * a generated Base64 session identifier * the selected cipher * the negotiated congestion-control mode * the server public key The client MUST answer with the received token and matching session metadata. Only after that token round-trip succeeds does the server derive the AEAD session key and begin sending DATA. The retry token proves reachability of the apparent source IP address and UDP port before the server starts sending encrypted payload data. In current public implementations, the resulting session is bound to the IP address and UDP source port that successfully completed the challenge. The session identifier remains useful as a label, but is not currently accepted from a different source address for path migration. 6.1. Implementation Flow A conforming implementation based on the current public model SHOULD behave roughly as follows: Client -> HELLO(client_pub, requested_cipher, requested_cc) Server -> CHALLENGE(token, session_id, selected_cipher, negotiated_cc, server_pub) Client -> CHALLENGE-REPLY(token, session_id, selected_cipher, negotiated_cc, client_pub) Server -> derive session key Server -> SESSION(session_id, selected_cipher, negotiated_cc, server_pub) Client -> derive session key Data path -> encrypted DATA packets begin x1co Expires 19 December 2026 [Page 6] Internet-Draft USTPS June 2026 7. 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) 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. Only the missing packets are retransmitted. Receipt of later packets does not require discarding or rewinding already accepted later packets. 7.1. Receiver Behavior A receiver implementation SHOULD: * accept out-of-order DATA packets immediately * track newly seen seq values to detect duplicates * generate ACK for unique packets * generate NACK only for missing sequence numbers * retain enough metadata to reconstruct logical order by stream_pos if required by the application 7.2. Sender Behavior A sender implementation SHOULD: * assign a unique increasing seq to each DATA packet * store transmitted DATA packets in a retransmission buffer * retire a packet from the retransmission buffer after successful acknowledgement * retransmit only the missing packets identified by NACK or by RTO fallback x1co Expires 19 December 2026 [Page 7] Internet-Draft USTPS June 2026 8. 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. 9. Congestion Control USTPS Congestion is OPTIONAL in current implementations. When enabled, it adjusts the sender's effective send window and burst size without changing USTPS reliability semantics, unordered delivery semantics, or selective retransmission behavior. Current public implementations negotiate congestion-control mode during the handshake. Server policy may be auto, on, or off. Client preference may be on or off. With server policy auto, the server follows the client request. With server policy on or off, the server forces the final mode. Current public implementations start from normal transport speed and back off only after sustained congestion signals. Isolated loss events are intentionally tolerated so that a single loss event is less likely to be treated the same way as true persistent congestion. Current implementations examine a combination of measured RTT inflation, retransmission timeout events, and explicit retransmission pressure. Congestion control therefore affects only the sender rate policy; it does not alter the unordered transport model or the selective-repeat recovery model. 10. Security Model USTPS uses mandatory AEAD for DATA packets. Implementations currently support ChaCha20-Poly1305, AES-256-GCM, and AES-128-GCM. A user-facing naming convention MAY map to those cipher suites as follows: * chacha20 = CHACHA20_POLY1305 * aes-256-gcm = AES_256_GCM x1co Expires 19 December 2026 [Page 8] Internet-Draft USTPS June 2026 * aes-128-gcm = AES_128_GCM Current public implementations default to chacha20 when a different explicit choice is not forced by configuration. Clients and servers perform an X25519-based key exchange when a client joins, and a separate session key is derived per client session. ACK and NACK records remain plaintext in current implementations for observability and debugging, but they are authenticated with an HMAC derived from the session key. This is intended to reduce off-path forged ACK or NACK attacks while preserving readable control format. 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. 11. Session Binding and Network Changes Earlier experimental implementations attempted client path migration and session resumption across source IP address or UDP port changes. Current public implementations removed that behavior because it created practical reliability and security problems, including migration floods, stale sessions that appeared recovered but stopped delivering data, long silent periods followed by gap-only behavior, and ambiguity between a legitimate roaming client and spoofed packets claiming an existing session identifier. Current public implementations therefore use a simpler model: complete the retry-token challenge on the current source IP address and UDP port, bind the resulting session to that endpoint, and reconnect cleanly if the endpoint changes. 12. Implementation Guidance An implementation that needs ordered application output SHOULD keep a reorder buffer keyed by stream_pos, not by seq. The sequence number exists for transport reliability logic; it is not the application's authoritative logical ordering key. An implementation that can consume unordered chunks directly MAY process payloads immediately without ordered release. Applications that bridge USTPS into a TCP-like local compatibility socket should understand that any ordered byte stream visible on that local side is an application choice above USTPS, not transport-level ordering inside USTPS. x1co Expires 19 December 2026 [Page 9] Internet-Draft USTPS June 2026 13. 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, stream container choice, and optional congestion-control policy. These are implementation details and not normative wire requirements unless later specified. 14. IANA Considerations This document has no IANA actions. 15. Security Considerations USTPS relies on correct AEAD use, correct nonce handling, correct key derivation, authenticated peer identity checks, and correct validation of the retry-token challenge before encrypted DATA is sent. 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. Because current public implementations keep ACK and NACK records in plaintext, implementations that follow this model SHOULD authenticate those control records, for example with an HMAC derived from session state. Implementations that expose optional congestion control SHOULD avoid treating an isolated single loss event as automatically equivalent to sustained path congestion. 16. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . x1co Expires 19 December 2026 [Page 10] Internet-Draft USTPS June 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . Author's Address x1co x1colegal Email: x1colegal@outlook.com.br x1co Expires 19 December 2026 [Page 11]