| Internet-Draft | USSH | June 2026 |
| x1co | Expires 14 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, including challenge-validated session setup, per-session key establishment, selective retransmission, and support for session recovery when the client changes networks.¶
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.¶
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 protection for DATA packets, 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, readable plaintext control records, and binary UPACK DATA framing are provided by USTPS. USSH then defines its own application messages for shell authentication, PTY setup, standard input delivery, standard output delivery, resize events, keepalives, and session termination.¶
USTPS remains unordered at the transport layer. USSH therefore performs application-layer reconstruction where terminal behavior requires ordered reconstruction of logical streams such as standard output.¶
A USSH client first establishes a USTPS session with the server. In current public implementations, this includes a plaintext HELLO, a plaintext challenge containing a token and generated Base64 session identifier, and a validated challenge response before DATA traffic is accepted.¶
Only after the secure USTPS session exists does the client perform USSH authentication and request an interactive shell or PTY-backed session.¶
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 uses the identifier USS1 at the encrypted outer framing layer for DATA. Plaintext USTPS control appears as readable ASCII lines such as ACK: ..., NACK: ..., and HELLO: ..., while decrypted USTPS DATA uses binary UPAK framing. Implementers should therefore distinguish between the secure envelope, USTPS control, USTPS DATA framing, and the USSH application payload when analyzing packet captures or decrypted data.¶
Current implementations support password-based authentication after the secure USTPS session is established. Once authenticated, the server launches a PTY-backed shell on behalf of the client.¶
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 inherits path-recovery capability from USTPS. If the client's active UDP path dies, the secure session may be resumed on a new path using the stored session identifier instead of immediately forcing a brand-new shell session.¶
This behavior is intended to let a client change networks without automatically losing the interactive shell as soon as the previous UDP path breaks.¶
USSH relies on USTPS for mandatory AEAD protection of DATA packets 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, path recovery, 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.¶