UDP Speedy Secure Shell (USSH)

Introduction 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.

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 when, and only when, they appear in all capitals, as shown here.

Relationship to USTPS 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.

Message Identification 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.

Protocol Model 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:

Authentication and session setup
Standard input delivery
Standard output delivery
Terminal resize events
Keepalive and liveness signaling
Session close and exit signaling

Interactive Stream Handling 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.

Head-of-Line Considerations 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.

Security Model 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.

Operational Status 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.

IANA Considerations This document has no IANA actions.

Security Considerations 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.