| Internet-Draft | USSH | June 2026 |
| x1co | Expires 9 December 2026 | [Page] |
This document describes UDP Speedy Secure Shell (USSH), an experimental remote shell protocol built on top of USTPS. USSH provides an interactive shell session over a secure UDP-based transport while preserving USTPS transport semantics. USSH reconstructs application-level terminal streams where necessary, while relying on USTPS for secure unreliable-underneath, selective-recovery transport behavior.¶
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 (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.¶
USSH is an experimental secure shell protocol built directly on top of USTPS rather than on TCP. Its goal is to provide interactive remote shell access while preserving the properties of the underlying USTPS transport, including packet-level authenticated encryption, per-client session keys, selective retransmission, and lack of transport-level Head-of-Line blocking.¶
USSH is not intended to be wire-compatible with SSH. It is a distinct protocol with its own packetization and control semantics.¶
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.¶
USSH uses USTPS as its secure transport substrate. The outer secure envelope and inner transport packet format are provided by USTPS. USSH then defines its own application messages for shell authentication, PTY setup, standard input delivery, standard output delivery, resize events, and session termination.¶
USTPS remains unordered at the transport layer. USSH therefore performs additional application-layer handling where terminal behavior requires ordered reconstruction of logical streams such as standard output.¶
USSH application messages begin with the magic value USS1, meaning "UDP Speedy Secure Shell, version 1" in the USSH application context.¶
In deployed implementations, the USTPS secure envelope also uses the identifier USS1 at the encrypted outer framing layer. The inner USTPS transport packet uses UST1. Implementers should therefore distinguish between the secure envelope, the USTPS transport packet, and the USSH application payload when analyzing packet captures or decrypted data.¶
A USSH client first establishes a USTPS session with the server. Once that secure transport session exists, the client performs USSH authentication and requests an interactive shell or PTY-backed session. Current implementations support password-based entry and derive per-client session state over the already-established USTPS channel.¶
USSH messages currently cover at least the following categories:¶
Interactive shells are highly sensitive to stream corruption and terminal redraw behavior. Although USTPS is unordered at the transport layer, a shell's logical input and output streams often require application-level ordering. USSH therefore reconstructs ordered logical output where needed before presenting terminal bytes to the local client terminal.¶
This reconstruction is an application-layer behavior of USSH. It does not convert USTPS itself into an ordered transport.¶
USSH inherits the lack of transport-level Head-of-Line blocking from USTPS. However, because terminal streams and PTY behavior often require coherent ordered interpretation, USSH may temporarily delay terminal-visible output while reconstructing the correct logical order of shell output fragments.¶
That delay occurs at the application layer and is distinct from transport-level Head-of-Line blocking.¶
USSH relies on USTPS for mandatory AEAD and per-client key establishment. Current public implementations additionally support persistent server host keys, TOFU-based server identity continuity, and application-level authentication before granting shell access.¶
Implementations SHOULD carefully protect shell spawn logic, PTY handling, session teardown, and terminal state restoration. Clients SHOULD restore local terminal settings even when the session closes unexpectedly.¶
USSH has been implemented and exercised as a Beta-grade experimental protocol. Public development has focused on stability over the USTPS substrate, interactive shell usability, session liveness, and terminal negotiation.¶
This document has no IANA actions.¶
Remote shell protocols expose high-impact capabilities. In addition to the security requirements inherited from USTPS, USSH implementations MUST authenticate clients before granting shell access, MUST avoid leaking shell access to unauthenticated peers, and SHOULD defend against terminal-state corruption, stale-session reuse, and unauthorized session migration.¶
Applications and operators should understand that USSH is experimental and not interchangeable with SSH security review, ecosystem hardening, or deployment maturity.¶