USTP

USTP significa UDP Speedy Transmission Protocol.

USTP mantiene lo stesso modello di trasporto autenticato, ma il nome del progetto ora è semplicemente USTP di nuovo.

Per impostazione predefinita, USTP utilizza AEAD per DATA.

Supporta inoltre una modalità opzionale negoziata cleartext + HMAC per DATA, in cui i byte del payload sono visibili sul filo ma le manomissioni vengono rilevate e rifiutate.

USTP ora supporta un controller di congestione opzionale chiamato USTP Congestion. Rimane UDP-first, ma può opzionalmente rallentare e risalire quando il percorso inizia a mostrare segnali di congestione.

Stato: Beta

USTP non è più solo una proof of concept. Attualmente è in fase Beta.

USTP può essere utilizzato per molti tipi di applicazioni e trasporti.

Questo repository, tuttavia, è focalizzato specificamente sullo streaming su USTP.

Novità

• 02/08/2026: USTP-Secure è ora tornato a essere USTP.
  • USTP-Secure era un vecchio nome del progetto e non è più adatto al progetto.
  • Il nome più corto USTP è ora nuovamente preferito.
  • Il nome completo è ora UDP Speedy Transmission Protocol, senza Secure nel titolo.
• 2026-07-18: USTP/2 Beta è stato rimosso dall'albero corrente.
  • Il comportamento reale era meno stabile di USTP/1.1 in condizioni di perdita.
  • Il percorso di trasporto stabile corrente è solo USTP/1.1.
  • L'handshake di trasporto ora utilizza record ASCII in chiaro.

Nota sulla build

• Compilato con Codex usando GPT-5.4 (Low).
• Verificato senza blocchi a --loss 33.
• Percorso di test: Brazil -> Canada con circa 140ms di RTT.

Modello di sicurezza

• Il trasporto rimane UDP (nessun tunnel TCP)
• Cifrari AEAD:
  • chacha20 = CHACHA20_POLY1305
  • aes-256-gcm = AES_256_GCM
  • aes-128-gcm = AES_128_GCM
• Cifrario AEAD predefinito: chacha20
• La modalità di protezione DATA predefinita è AEAD.
• La modalità di protezione DATA opzionale è cleartext + HMAC per pacchetto.
• In modalità cleartext, i byte del payload non sono cifrati, ma le modifiche vengono rilevate e i pacchetti non validi vengono scartati.
• I pacchetti di controllo del trasporto (HELLO, ACK, RETRANSMIT_REQUEST, CLOSE) rimangono in chiaro di proposito.
• I pacchetti di controllo sono serializzati come record di trasporto ASCII.
• ACK e NACK/RETRANSMIT_REQUEST rimangono in chiaro, ma sono autenticati con un tag HMAC per sessione.
• Questo impedisce che pacchetti di controllo ACK/NACK falsificati off-path possano forzare attacchi ACK o DoS da ritrasmissione dopo che la sessione sicura è stabilita.
• I pacchetti DATA utilizzano un formato di frame binario chiamato UPACK (UPAK sul filo).
• Non viene utilizzata alcuna PSK statica.
• Ogni client esegue uno scambio di chiavi X25519 quando si unisce.
• Ogni client ottiene una chiave di sessione AEAD separata.
• I server supportano più client.
• Il server convalida il client con un round-trip di challenge sull'IP:port di origine.
• Se --cipher è impostato sul server, il server utilizza esattamente quel cifrario.
• Se --cipher è omesso o impostato su auto, il server utilizza il cifrario richiesto dal client.
• I client rifiutano negoziazioni di cifrario inattese.
• La modalità di protezione DATA viene negoziata separatamente dalla scelta del cifrario:
  • server: --cleartext auto|on|off
  • client: --cleartext on|off
  • predefinito server: auto
  • predefinito client: off
• Con server auto, il server segue la richiesta del client.
• Con server on, il server forza cleartext + HMAC.
• Con server off, il server forza AEAD.
• TOFU (Trust On First Use) è abilitato sul client per rilevare cambiamenti imprevisti della chiave del server dopo la prima connessione.
• Il server mantiene una chiave host X25519 persistente in ~/.ustps_host_key per impostazione predefinita, in modo che TOFU rimanga stabile tra riconnessioni e riavvii.
• Un normale riavvio del server non cambia la chiave host.
• Usa --regen-key sul server solo quando vuoi intenzionalmente ruotare quella chiave host.

Valori magici dei pacchetti

• ACK:, NACK:, HELLO: e CLOSE: sono i prefissi dei record di controllo in chiaro.
• USS1 significa UDP Speedy Secure, versione 1.
• USC1 significa UDP Speedy Clear, versione 1.
• UPAK è il marcatore del frame DATA binario UPACK.
• In USTP, il controllo in chiaro è ASCII leggibile dall'uomo come ACK: 10, NACK: 42, HELLO: ... e CLOSE:.
• In USTP, UPAK identifica i pacchetti DATA binari dopo la decifratura.
• In USTP, USS1 è il formato dell'involucro esterno sicuro AEAD.
• In USTP, USC1 è il formato dell'involucro esterno DATA in chiaro+HMAC.
• Quindi, sul filo si vede normalmente:
  • USS1... per DATA protetto da AEAD
  • USC1... per DATA in chiaro+HMAC
  • righe di controllo leggibili per il controllo del trasporto

Modello di trasporto

• USTP può funzionare con USTP Congestion opzionale, negoziato durante l'handshake.
• I pacchetti trasportano sia un seq di trasporto sia uno stream_pos rivolto all'applicazione.
• seq è usato per ACK, rilevamento delle perdite, ritrasmissione e campionamento RTT.
• stream_pos indica all'applicazione dove appartiene il payload nel flusso di byte logico.
• Nell'implementazione attuale, seq è un contatore a 32 bit che parte da 1 per ogni nuova sessione.
• Nell'implementazione attuale, stream_pos è un contatore di byte a 64 bit che parte da 0 per ogni nuovo flusso logico.
• Il ricevitore accetta i pacchetti immediatamente invece di bloccare la consegna dietro un pacchetto mancante.

Modello di handshake e sessione

• Il client inizia con un HELLO di trasporto in chiaro che trasporta la sua chiave pubblica X25519, il cifrario richiesto, la modalità di controllo della congestione richiesta (on o off) e la modalità di protezione DATA richiesta (cleartext on|off).
• Il server non invia immediatamente i media. Invia prima una sfida in chiaro contenente:
  • un token di retry casuale
  • un session_id Base64 generato
  • il cifrario selezionato
  • la modalità di controllo della congestione negoziata
  • la modalità di protezione DATA negoziata
  • la chiave pubblica del server
• Il client deve rispondere con esattamente lo stesso token e gli stessi metadati di sessione.
• Solo dopo che questo round-trip del token ha successo il server crea la sessione e inizia a inviare DATA.
• Dopo la validazione, la sessione è vincolata all'IP:port di origine che ha completato la sfida.
• session_id è ancora usato come etichetta di sessione, ma non è accettato da un IP:port diverso.

Token di retry

• USTP usa un passaggio con token di retry in chiaro prima che qualsiasi sessione media cifrata venga accettata.
• Flusso:
  • il client invia HELLO
  • il server risponde con USTPS-CHALLENGE1 che trasporta token, session_id, cifrario selezionato, modalità di controllo della congestione negoziata, modalità di protezione DATA negoziata e chiave pubblica del server
  • il client rimanda indietro quel token in USTPS-CHALLENGE-REPLY1
  • solo allora il server crea la sessione e invia USTPS-SESSION1
• Scopo:
  • dimostrare che il mittente a quell'IP:port di origine può effettivamente ricevere pacchetti lì
  • evitare di inviare immediatamente media cifrati a un indirizzo di origine non validato
  • vincolare la creazione finale della sessione all'endpoint che ha completato il round-trip
• Il token di retry non è la chiave di sessione.
• È solo una prova di raggiungibilità e un cancello di handshake prima che venga creata la vera sessione USTP.
• Inoltre non è usato come nonce, non è usato da solo come chiave MAC per ACK/NACK e non è riutilizzato come stato del payload dei pacchetti.