USTP

USTP significa UDP Speedy Transmission Protocol.

USTP mantiene el mismo modelo de transporte autenticado, pero el nombre del proyecto ahora vuelve a ser simplemente USTP.

Por defecto, USTP usa AEAD para DATA.

También admite un modo opcional negociado de cleartext + HMAC para DATA, en el que los bytes de carga útil son visibles en el cable pero la manipulación se detecta y se rechaza.

USTP ahora admite un controlador de congestión opcional llamado USTP Congestion. Sigue siendo UDP-first, pero opcionalmente puede ralentizarse y volver a acelerar cuando la ruta empieza a mostrar señales de congestión.

Estado: Beta

USTP ya no es solo una prueba de concepto. Actualmente se encuentra en fase Beta.

USTP puede usarse para muchos tipos de aplicaciones y transportes.

Sin embargo, este repositorio se centra específicamente en streaming sobre USTP.

Noticias

• 02/08/2026: USTP-Secure vuelve a ser USTP.
  • USTP-Secure era un nombre de proyecto antiguo y ya no encaja bien con el proyecto.
  • El nombre más corto USTP vuelve a ser el preferido.
  • El nombre completo ahora es UDP Speedy Transmission Protocol, sin Secure en el título.
• 2026-07-18: USTP/2 Beta se eliminó del árbol actual.
  • El comportamiento en el mundo real era menos estable que USTP/1.1 bajo pérdida.
  • La ruta de transporte estable actual es únicamente USTP/1.1.
  • El handshake de transporte ahora usa registros ASCII en texto plano.

Nota de compilación

• Compilado con Codex usando GPT-5.4 (Low).
• Verificado sin congelarse con --loss 33.
• Ruta de prueba: Brazil -> Canada con aproximadamente 140ms de RTT.

Modelo de seguridad

• El transporte sigue siendo UDP (sin túnel TCP)
• Cifrados AEAD:
  • chacha20 = CHACHA20_POLY1305
  • aes-256-gcm = AES_256_GCM
  • aes-128-gcm = AES_128_GCM
• Cifrado AEAD por defecto: chacha20
• El modo de protección de DATA por defecto es AEAD.
• El modo de protección de DATA opcional es cleartext + HMAC por paquete.
• En modo cleartext, los bytes de carga útil no se cifran, pero las modificaciones se detectan y los paquetes inválidos se descartan.
• Los paquetes de control de transporte (HELLO, ACK, RETRANSMIT_REQUEST, CLOSE) permanecen en texto plano a propósito.
• Los paquetes de control se serializan como registros de transporte ASCII.
• ACK y NACK/RETRANSMIT_REQUEST siguen en texto plano, pero se autentican con una etiqueta HMAC por sesión.
• Esto evita que paquetes de control ACK/NACK falsificados fuera de ruta fuercen ataques ACK o DoS por retransmisión una vez establecida la sesión segura.
• Los paquetes DATA usan un formato de trama binario llamado UPACK (UPAK en el cable).
• No se usa PSK estática.
• Cada cliente realiza un intercambio de claves X25519 cuando se une.
• Cada cliente obtiene una clave de sesión AEAD separada.
• Los servidores admiten múltiples clientes.
• El servidor valida al cliente con un round-trip de desafío sobre el IP:port de origen.
• Si se establece --cipher en el servidor, el servidor usa exactamente ese cifrado.
• Si se omite --cipher o se establece en auto, el servidor usa el cifrado solicitado por el cliente.
• Los clientes rechazan negociaciones de cifrado inesperadas.
• El modo de protección de DATA se negocia por separado de la elección de cifrado:
  • servidor: --cleartext auto|on|off
  • cliente: --cleartext on|off
  • valor por defecto del servidor: auto
  • valor por defecto del cliente: off
• Con el servidor en auto, el servidor sigue la solicitud del cliente.
• Con el servidor en on, el servidor fuerza cleartext + HMAC.
• Con el servidor en off, el servidor fuerza AEAD.
• TOFU (Trust On First Use) está habilitado en el cliente para detectar cambios inesperados en la clave del servidor tras la primera conexión.
• El servidor mantiene una clave de host X25519 persistente en ~/.ustps_host_key por defecto para que TOFU siga siendo estable entre reconexiones y reinicios.
• Un reinicio normal del servidor no cambia la clave de host.
• Use --regen-key en el servidor solo cuando quiera rotar intencionadamente esa clave de host.

Valores mágicos de los paquetes

• ACK:, NACK:, HELLO: y CLOSE: son los prefijos de los registros de control en texto plano.
• USS1 significa UDP Speedy Secure, versión 1.
• USC1 significa UDP Speedy Clear, versión 1.
• UPAK es el marcador binario de la trama DATA de UPACK.
• En USTP, el control en texto plano es ASCII legible por humanos, como ACK: 10, NACK: 42, HELLO: ... y CLOSE:.
• En USTP, UPAK identifica los paquetes DATA binarios tras el descifrado.
• En USTP, USS1 es el formato de envoltura AEAD seguro externo.
• En USTP, USC1 es el formato de envoltura DATA de texto claro+HMAC externo.
• Por lo tanto, en el cable normalmente se ve:
  • USS1... para DATA protegido con AEAD
  • USC1... para DATA en texto claro+HMAC
  • líneas de control legibles para el control del transporte

Modelo de transporte

• USTP puede ejecutarse con USTP Congestion opcional, negociado durante el handshake.
• Los paquetes llevan tanto un seq de transporte como un stream_pos orientado a la aplicación.
• seq se utiliza para ACK, detección de pérdidas, retransmisión y muestreo de RTT.
• stream_pos indica a la aplicación dónde pertenece la carga útil dentro del flujo lógico de bytes.
• En la implementación actual, seq es un contador de 32 bits que comienza en 1 para cada sesión nueva.
• En la implementación actual, stream_pos es un contador de bytes de 64 bits que comienza en 0 para cada flujo lógico nuevo.
• El receptor acepta los paquetes de inmediato en lugar de bloquear la entrega detrás de un paquete perdido.

Modelo de handshake y sesión

• El cliente comienza con un HELLO de transporte en texto plano que transporta su clave pública X25519, el cifrado solicitado, el modo de control de congestión solicitado (on u off) y el modo de protección de DATA solicitado (cleartext on|off).
• El servidor no envía medios de inmediato. Primero envía un desafío en texto plano que contiene:
  • un token de reintento aleatorio
  • un session_id generado en Base64
  • el cifrado seleccionado
  • el modo de control de congestión negociado
  • el modo de protección de DATA negociado
  • la clave pública del servidor
• El cliente debe responder con ese mismo token exacto y los metadatos de sesión.
• Solo después de que ese intercambio de token tiene éxito, el servidor crea la sesión y comienza a enviar DATA.
• Tras la validación, la sesión queda vinculada al IP:port de origen que completó el desafío.
• session_id se sigue usando como etiqueta de sesión, pero no se acepta desde un IP:port diferente.

Token de reintento

• USTP utiliza un paso de token de reintento en texto plano antes de que se acepte cualquier sesión de medios cifrada.
• Flujo:
  • el cliente envía HELLO
  • el servidor responde con USTPS-CHALLENGE1 que transporta token, session_id, el cifrado seleccionado, el modo de control de congestión negociado, el modo de protección de DATA negociado y la clave pública del servidor
  • el cliente devuelve ese token en USTPS-CHALLENGE-REPLY1
  • solo entonces el servidor crea la sesión y envía USTPS-SESSION1
• Propósito:
  • demostrar que el emisor en ese IP:port de origen puede realmente recibir paquetes allí
  • evitar enviar medios cifrados de inmediato a una dirección de origen no validada
  • vincular la creación final de la sesión al endpoint que completó el intercambio
• El token de reintento no es la clave de sesión.
• Es solo una prueba de alcanzabilidad y una puerta de handshake antes de que se cree la sesión USTP real.
• Tampoco se usa como nonce, ni como clave MAC de ACK/NACK por sí mismo, ni se reutiliza como estado de carga útil de paquetes.