Resumen

  • El 24 de agosto de 2026, el IESG aprobó la revisión 16 de draft-ietf-masque-connect-udp-listen como Proposed Standard. En la fecha de corte seguía siendo un Internet-Draft en la cola del RFC Editor; el anuncio informa de interoperabilidad entre Google Quiche y quic-go.
  • El mecanismo conserva una dirección y un puerto UDP públicos para múltiples tuplas remotas dentro de una sola solicitud HTTP. Esa dirección asigna alcance, pero no permiso universal: la negociación, el registro del contexto, la política de destino y el reenvío observado conservan decisiones independientes.

Dos datagramas llaman a la misma puerta

Un navegador obtiene de un proxy una dirección UDP pública para una sesión WebRTC. El candidato elegido mediante ICE envía su primer datagrama. Casi al mismo tiempo llega otro desde un escáner que encontró el puerto por azar.

Ambos alcanzaron el socket. Solo uno pertenece a la conversación prevista.

El ejemplo es ilustrativo, no la descripción de un ataque conocido. Sirve para situar la innovación de “Proxying Bound UDP in HTTP”: el proxy puede publicar un punto estable de llegada sin convertirlo en un permiso para cualquier origen. La autorización se resuelve después, con el estado de la solicitud, la tupla remota, el Context ID, la política local y la entrega real.

La noticia normativa y sus límites

El IESG anunció el 24 de agosto, a las 17:58 UTC, la aprobación de la revisión 16 para su publicación como Proposed Standard. El trabajo pertenece al grupo MASQUE.

RFC 9298 define CONNECT-UDP para un destino fijo por solicitud. Es una solución natural para protocolos cliente-servidor, incluido HTTP/3. WebRTC depende de ICE y puede necesitar tráfico con varios candidatos. Varias solicitudes ordinarias no garantizan que el tráfico pase por la misma instancia de proxy ni que conserve la misma IP pública; por eso no aportan necesariamente el punto estable que requiere la comprobación de conectividad.

La extensión mantiene el socket dentro de una sola solicitud y mueve la selección del par a cada datagrama o a un registro compartido. El anuncio cita dos implementaciones interoperables. Esa prueba demuestra que el diseño puede ejecutarse entre dos pilas; no mide adopción, escala, política de producción ni compatibilidad con todos los navegadores.

El 28 de agosto, Datatracker todavía mostraba la revisión como Internet-Draft activo. Su estado IESG era RFC Ed Queue; IANA continuaba el trabajo con las revisiones expertas aceptadas, y el RFC Editor esperaba comprobación de referencias y formato. Hay una aprobación inequívoca, pero aún no un RFC numerado ni una obligación desplegada.

El enlace no se presume

El cliente solicita la función con Connect-UDP-Bind: ?1. El proxy devuelve el mismo booleano verdadero si la admite. El mecanismo solo queda habilitado para un extremo después de que haya enviado y recibido ese valor; otra clase de valor cuenta como campo ausente.

La simetría evita dos atajos peligrosos. Un cliente no puede interpretar cualquier respuesta exitosa como soporte, y un proxy no puede ampliar sin aviso una solicitud de destino fijo.

Hay dos formas de petición. Una puede incluir un host y puerto válidos para poder volver a CONNECT-UDP ordinario. La otra coloca * en ambos campos y exige funcionamiento enlazado sin destino fijo. Usar el asterisco en uno solo es un error de cliente. Registrar esta modalidad es imprescindible para explicar luego por qué se usó o se prohibió el Context ID cero.

La dirección anunciada es inventario, no identidad

Al aceptar, el proxy elige al menos una IP pública y un puerto libre, los vincula a la solicitud y los entrega mediante Proxy-Public-Address. Si anuncia una sola tupla, debe mantenerla durante toda la vida del túnel. Con varias, se recomienda estabilidad por familia IP. El campo de respuesta no permite comunicar un cambio posterior.

Esta es una garantía de asignación útil para ICE. No autentica al que llama. Una fuente legítima y una desconocida pueden alcanzar la misma tupla. Afirmar dirección_asignada o paquete_recibido solo prueba esas etapas; falta demostrar asociación, decisión de política, reenvío y resultado en el cliente.

La distinción es especialmente importante cuando una IP es compartida. Lo que se observa desde fuera es un recurso del proxy. La autoridad vive en un estado interior mucho más preciso.

Una asociación explícita para cada tupla

Los clientes asignan Context IDs pares y los proxies impares. El valor cero queda prohibido cuando la solicitud no tiene destino fijo; si existe un destino real de reserva, cero conserva el significado de RFC 9298.

El ciclo usa tres Capsules. COMPRESSION_ASSIGN (0x11) propone una asociación. COMPRESSION_ACK (0x12) confirma que el receptor la guardó. COMPRESSION_CLOSE (0x13) la rechaza o termina.

Con versión IP cero, el contexto no está comprimido: cada datagrama lleva IP y puerto. En sentido cliente-proxy son el destino; en sentido proxy-cliente son el origen recibido. Con IPv4 o IPv6, la tupla se registra una vez y los datagramas posteriores llevan solo la carga UDP bajo el identificador.

No se puede asignar dos veces un ID, ni mantener dos IDs para la misma tupla, ni reutilizar un ID cerrado. Un datagrama reordenado que llega después del cierre se descarta silenciosamente. Estas prohibiciones impiden que un nombre viejo recupere autoridad sobre una relación nueva.

Se permite enviar antes del ACK para reducir latencia, pero el emisor asume posibles pérdidas si la asignación aún no llegó o fue rechazada. Por tanto, el uso anticipado de un ID demuestra una apuesta del emisor, no la aceptación del receptor.

El contexto sin compresión es una puerta controlada por el cliente

Solo el cliente puede solicitar ese contexto y solo puede haber uno abierto. Su amplitud viene de que cada datagrama declara una tupla nueva. Si permanece abierto, el cliente debe estar preparado para recibir de cualquier destino admitido por la política del proxy.

El cliente puede no abrirlo o cerrarlo. Entonces el proxy filtra en la práctica a los remitentes desconocidos. Las asociaciones comprimidas existentes siguen vivas, pero el proxy no puede crear otras nuevas después del cierre: hacerlo devolvería por otra vía la capacidad que el cliente retiró.

Así, el puerto no necesita desaparecer para reducir el permiso. La infraestructura pública sigue asignada, los pares expresamente asociados siguen funcionando y lo desconocido queda fuera.

La política acompaña a cada destino variable

En CONNECT-UDP ordinario, el proxy examina el destino al crear el túnel. Cuando el destino cambia dentro de la sesión, el control debe seguirlo. El proxy revisa cada IP y puerto incluidos en un datagrama sin compresión y cada tupla presentada para una asociación comprimida.

La organización puede prohibir loopback, direcciones privadas, enlaces locales, redes administrativas o servicios concretos. La norma no pretende decidir toda esa política; fija el punto mínimo donde un cambio de tupla no puede evitarla.

TURN ayuda a razonar sobre la separación. Una dirección de relé se asigna primero; permisos y asociaciones de canal añaden estados para los pares. No es el mismo protocolo, pero sí la misma advertencia: una dirección de relé no equivale a consentimiento ilimitado.

Los límites de recursos también autorizan

Cada Context ID ocupa memoria. Las respuestas ACK o CLOSE que no pueden salir por control de flujo o congestión ocupan buffers. El borrador exige un máximo de contextos simultáneos y otro para las respuestas pendientes. Cuando el segundo se agota, el proxy debe abortar el flujo de la solicitud.

Esos límites tienen consecuencias de servicio. Deben registrarse configuración, ocupación, rechazos, tiempo de cola, abortos y población afectada. Sin datos, una protección legítima parece una avería aleatoria y resulta tentador quitarla.

También cambia el tamaño efectivo. Un datagrama sin compresión incluye IP y puerto; uno comprimido no. Cambiar durante el flujo puede perturbar DPLPMTUD. Pedir la compresión pronto reduce la transición, pero solo la telemetría de tamaño, pérdida y éxito confirma el resultado.

La atribución necesita más que una IP

RFC 6269 documenta los problemas de compartir direcciones: reputación conjunta, bloqueos excesivos y atribución débil. En este caso, una IP del proxy puede representar muchos puertos, clientes, túneles, contextos y pares.

Una investigación de abuso necesita el puerto, la identidad del túnel, el cliente autenticado, el Context ID, la tupla remota, la versión de política y el efecto de reenvío. Si se conserva solo IP y hora, un escaneo descartado puede parecer tráfico entregado y un cliente inocente puede heredar la reputación de otro.

Qué debe demostrar una ejecución

La cadena mínima incluye:

  1. solicitud autenticada e identidad del túnel;
  2. negociación verdadera en ambos sentidos;
  3. destino de reserva o modalidad exclusiva;
  4. tupla pública y vigencia;
  5. quién asignó el Context ID y su unicidad;
  6. ASSIGN, ACK y CLOSE;
  7. semántica comprimida o no comprimida;
  8. origen o destino remoto exacto;
  9. política aplicada y veredicto;
  10. capacidad disponible;
  11. aceptación, descarte o espera del datagrama;
  12. transmisión o recepción en el socket;
  13. entrega al cliente y resultado ICE o de la aplicación.

Una asociación correcta puede terminar en pérdida o en una comprobación ICE fallida. El estado del protocolo permite procesar; la observación final demuestra funcionamiento. Esa es la frontera de Running-Code Primacy: el documento define reglas comunes mínimas, pero ningún sello normativo sustituye a la evidencia local.

Fuentes