USTP

USTP signifie UDP Speedy Transmission Protocol.

USTP conserve le même modèle de transport authentifié, mais le nom du projet est désormais simplement USTP à nouveau.

Par défaut, USTP utilise AEAD pour DATA.

Il prend également en charge un mode optionnel négocié cleartext + HMAC pour DATA, où les octets de charge utile sont visibles sur le réseau mais toute altération est détectée et rejetée.

USTP prend désormais en charge un contrôleur de congestion optionnel appelé USTP Congestion. Il reste prioritairement basé sur UDP, mais il peut éventuellement ralentir et remonter en débit lorsque le chemin commence à montrer des signaux de congestion.

Statut : Beta

USTP n'est plus seulement une preuve de concept. Il est actuellement en phase Beta.

USTP peut être utilisé pour de nombreux types d'applications et de transports.

Ce dépôt, cependant, se concentre spécifiquement sur le streaming sur USTP.

Actualités

• 02/08/2026 : USTP-Secure redevient USTP.
  • USTP-Secure était un ancien nom de projet qui ne convient plus au projet.
  • Le nom plus court USTP est désormais à nouveau préféré.
  • Le nom complet est maintenant UDP Speedy Transmission Protocol, sans Secure dans le titre.
• 2026-07-18 : USTP/2 Beta a été retiré de l'arborescence actuelle.
  • Le comportement en conditions réelles était moins stable qu'USTP/1.1 en cas de perte.
  • Le chemin de transport stable actuel est uniquement USTP/1.1.
  • La poignée de main du transport utilise désormais des enregistrements ASCII en clair.

Note de compilation

• Compilé avec Codex en utilisant GPT-5.4 (Low).
• Vérifié sans blocage à --loss 33.
• Chemin de test : Brazil -> Canada avec environ 140ms de RTT.

Modèle de sécurité

• Le transport reste UDP (pas de tunnel TCP)
• Chiffrements AEAD :
  • chacha20 = CHACHA20_POLY1305
  • aes-256-gcm = AES_256_GCM
  • aes-128-gcm = AES_128_GCM
• Chiffrement AEAD par défaut : chacha20
• Le mode de protection DATA par défaut est AEAD.
• Le mode de protection DATA optionnel est cleartext + HMAC par paquet.
• En mode cleartext, les octets de charge utile ne sont pas chiffrés, mais les modifications sont détectées et les paquets invalides sont écartés.
• Les paquets de contrôle du transport (HELLO, ACK, RETRANSMIT_REQUEST, CLOSE) restent en clair volontairement.
• Les paquets de contrôle sont sérialisés sous forme d'enregistrements de transport ASCII.
• ACK et NACK/RETRANSMIT_REQUEST restent en clair, mais sont authentifiés avec un tag HMAC par session.
• Cela empêche les paquets de contrôle ACK/NACK forgés hors chemin de forcer des attaques ACK ou un déni de service par retransmission après l'établissement de la session sécurisée.
• Les paquets DATA utilisent un format de trame binaire nommé UPACK (UPAK sur le réseau).
• Aucune PSK statique n'est utilisée.
• Chaque client effectue un échange de clés X25519 lors de sa connexion.
• Chaque client obtient une clé de session AEAD distincte.
• Les serveurs prennent en charge plusieurs clients.
• Le serveur valide le client par un aller-retour de challenge sur l'IP:port source.
• Si --cipher est défini sur le serveur, le serveur utilise exactement ce chiffrement.
• Si --cipher est omis ou défini sur auto, le serveur utilise le chiffrement demandé par le client.
• Les clients rejettent toute négociation de chiffrement inattendue.
• Le mode de protection DATA est négocié séparément du choix du chiffrement :
  • serveur : --cleartext auto|on|off
  • client : --cleartext on|off
  • valeur par défaut du serveur : auto
  • valeur par défaut du client : off
• Avec le serveur en auto, le serveur suit la demande du client.
• Avec le serveur en on, le serveur force cleartext + HMAC.
• Avec le serveur en off, le serveur force AEAD.
• TOFU (Trust On First Use) est activé sur le client pour détecter les changements inattendus de clé du serveur après la première connexion.
• Le serveur conserve une clé d'hôte X25519 persistante dans ~/.ustps_host_key par défaut afin que TOFU reste stable entre les reconnexions et les redémarrages.
• Un redémarrage normal du serveur ne change pas la clé d'hôte.
• Utilisez --regen-key sur le serveur uniquement lorsque vous souhaitez intentionnellement faire tourner cette clé d'hôte.

Valeurs magiques des paquets

• ACK:, NACK:, HELLO: et CLOSE: sont les préfixes des enregistrements de contrôle en clair.
• USS1 signifie UDP Speedy Secure, version 1.
• USC1 signifie UDP Speedy Clear, version 1.
• UPAK est le marqueur binaire de trame DATA UPACK.
• Dans USTP, le contrôle en clair est de l'ASCII lisible par l'humain tel que ACK: 10, NACK: 42, HELLO: ... et CLOSE:.
• Dans USTP, UPAK identifie les paquets DATA binaires après déchiffrement.
• Dans USTP, USS1 est le format d'enveloppe AEAD sécurisée externe.
• Dans USTP, USC1 est le format d'enveloppe DATA en clair+HMAC externe.
• Ainsi, sur le réseau, on voit normalement :
  • USS1... pour les DATA protégées par AEAD
  • USC1... pour les DATA en clair+HMAC
  • des lignes de contrôle lisibles pour le contrôle du transport

Modèle de transport

• USTP peut fonctionner avec USTP Congestion optionnel, négocié pendant la poignée de main.
• Les paquets portent à la fois un seq de transport et un stream_pos destiné à l'application.
• seq est utilisé pour l'ACK, la détection de perte, la retransmission et l'échantillonnage du RTT.
• stream_pos indique à l'application où la charge utile se situe dans le flux d'octets logique.
• Dans l'implémentation actuelle, seq est un compteur 32 bits qui commence à 1 pour chaque nouvelle session.
• Dans l'implémentation actuelle, stream_pos est un compteur d'octets 64 bits qui commence à 0 pour chaque nouveau flux logique.
• Le récepteur accepte les paquets immédiatement au lieu de bloquer la livraison derrière un paquet manquant.

Modèle de poignée de main et de session

• Le client commence par un HELLO de transport en clair portant sa clé publique X25519, le chiffrement demandé, le mode de contrôle de congestion demandé (on ou off) et le mode de protection DATA demandé (cleartext on|off).
• Le serveur n'envoie pas immédiatement de média. Il envoie d'abord un défi en clair contenant :
  • un jeton de nouvelle tentative aléatoire
  • un session_id Base64 généré
  • le chiffrement sélectionné
  • le mode de contrôle de congestion négocié
  • le mode de protection DATA négocié
  • la clé publique du serveur
• Le client doit répondre avec exactement ce même jeton et ces mêmes métadonnées de session.
• Ce n'est qu'après la réussite de cet aller-retour de jeton que le serveur crée la session et commence à envoyer des DATA.
• Après validation, la session est liée à la source IP:port qui a complété le défi.
• session_id est toujours utilisé comme étiquette de session, mais il n'est pas accepté depuis une autre IP:port.