UDP Speedy Secure Shell (USSH)
draft-x1co-ussh-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | x1co! | ||
| Last updated | 2026-06-12 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-x1co-ussh-02
Independent Submission X. x1co
Internet-Draft x1colegal
Intended status: Experimental 12 June 2026
Expires: 14 December 2026
UDP Speedy Secure Shell (USSH)
draft-x1co-ussh-02
Abstract
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.
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 14 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 14 December 2026 [Page 1]
Internet-Draft USSH June 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Relationship to USTPS . . . . . . . . . . . . . . . . . . . . 2
4. Session Establishment . . . . . . . . . . . . . . . . . . . . 3
5. Message Identification . . . . . . . . . . . . . . . . . . . 3
6. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 3
7. Interactive Stream Handling . . . . . . . . . . . . . . . . . 4
8. Head-of-Line Considerations . . . . . . . . . . . . . . . . . 4
9. Network Change Recovery . . . . . . . . . . . . . . . . . . . 4
10. Security Model . . . . . . . . . . . . . . . . . . . . . . . 4
11. Operational Status . . . . . . . . . . . . . . . . . . . . . 5
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
13. Security Considerations . . . . . . . . . . . . . . . . . . . 5
14. Normative References . . . . . . . . . . . . . . . . . . . . 5
15. Informative References . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. 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 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.
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. Relationship to USTPS
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.
x1co Expires 14 December 2026 [Page 2]
Internet-Draft USSH June 2026
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.
4. Session Establishment
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.
5. 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 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.
6. Protocol Model
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:
* Authentication and session setup
* Standard input delivery
* Standard output delivery
* Terminal resize events
* Keepalive and liveness signaling
x1co Expires 14 December 2026 [Page 3]
Internet-Draft USSH June 2026
* Session close and exit signaling
7. 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.
8. 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.
9. Network Change Recovery
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.
10. Security Model
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.
x1co Expires 14 December 2026 [Page 4]
Internet-Draft USSH June 2026
11. 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, path
recovery, and terminal negotiation.
12. IANA Considerations
This document has no IANA actions.
13. 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.
14. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
15. Informative References
[USTPS-DRAFT]
x1co, X., "UDP Speedy Transmission Protocol Secure
(USTPS)", Work in Progress, Internet-Draft, draft-x1co-
ustps-04, June 2026,
<https://datatracker.ietf.org/doc/draft-x1co-ustps/>.
Author's Address
x1co
x1colegal
Email: x1colegal@outlook.com.br
x1co Expires 14 December 2026 [Page 5]