Resumo

  • Em 24 de agosto de 2026, o IESG aprovou a revisão 16 de draft-ietf-masque-connect-udp-listen como Proposed Standard. No corte das evidências, ela ainda era um Internet-Draft na fila do RFC Editor; o anúncio registra implementações interoperáveis em Google Quiche e quic-go.
  • O mecanismo permite que uma solicitação HTTP preserve uma tupla UDP pública e converse com vários IPs e portas remotos. A tupla pública é uma alocação de alcance, não uma licença universal: suporte negociado, Context ID, política de destino e entrega observada continuam separados.

O pacote chegou; a autoridade ainda não

Um navegador pede a um proxy HTTP um endereço UDP para uma comunicação WebRTC. O proxy escolhe IP e porta públicos. O par selecionado pelo ICE envia um datagrama. Um scanner sem relação com a chamada encontra a mesma porta e envia outro.

Os dois chegaram ao socket. Isso não lhes dá a mesma condição dentro do túnel.

A situação é ilustrativa, não um incidente relatado. Ela mostra o motivo de existir de “Proxying Bound UDP in HTTP”: oferecer um ponto público estável sem transformá-lo em relay aberto. A decisão seguinte depende da solicitação autenticada, da tupla remota, do Context ID, das restrições do proxy e da opção do cliente quanto a remetentes desconhecidos.

Uma aprovação com fronteiras claras

O anúncio do IESG, de 24 de agosto às 17:58 UTC, aprova a revisão 16 como Proposed Standard. O documento é produto do grupo MASQUE.

O RFC 9298 já permite usar CONNECT-UDP com um host e uma porta fixos por solicitação. Isso atende bem a protocolos cliente-servidor, como HTTP/3. O WebRTC, porém, usa ICE e precisa testar diferentes pares. Várias solicitações comuns não garantem que o HTTP as encaminhe ao mesmo servidor proxy nem que mantenham a mesma origem pública.

A nova extensão conserva o socket numa só solicitação e leva a escolha do par em cada datagrama ou em uma associação registrada. Quiche e quic-go terem interoperado reduz a incerteza de implementação. Não demonstra habilitação geral em navegadores, escala produtiva ou conformidade de todos os serviços.

No dia 28, o Datatracker ainda mostrava um Internet-Draft ativo, com estado IESG RFC Ed Queue. A ação da IANA estava em andamento e os pareceres de especialistas estavam aprovados; o RFC Editor aguardava verificação de referências e formatação. A decisão normativa ocorreu. O RFC numerado e a adoção real ainda precisam ser observados.

O acordo precisa cruzar os dois sentidos

O cliente envia Connect-UDP-Bind: ?1. Um proxy compatível devolve o mesmo booleano verdadeiro. Um endpoint só considera a extensão habilitada depois de enviar e receber esse valor. Se o campo tiver outro tipo, é tratado como ausente.

Portanto, um status HTTP bem-sucedido não prova suporte. O proxy tampouco pode ampliar silenciosamente uma solicitação de destino fixo para vários pares.

O cliente pode informar host e porta válidos, mantendo-os como destino de recuo. Se quiser apenas o modo vinculado, coloca * em ambas as variáveis. Um asterisco em somente uma delas torna a solicitação inválida. Essa escolha deve permanecer no registro porque determina, entre outras coisas, se o Context ID zero conserva um destino fixo.

O cabeçalho público registra uma alocação

Depois de aceitar, o proxy escolhe ao menos um IP público e uma porta aberta, vincula-os à solicitação e os anuncia por Proxy-Public-Address. Quando fornece uma única tupla, precisa mantê-la até o fim do túnel. Com várias, recomenda-se estabilidade por família de endereços. Uma mudança posterior não pode ser comunicada pelo mesmo cabeçalho de resposta.

Para ICE, essa estabilidade cria um candidato útil. Para a segurança, ela não cria identidade. O par desejado e uma origem desconhecida podem alcançar o mesmo endereço.

Os eventos devem dizer exatamente o que sabem. endereço_público_alocado comprova a reserva; datagrama_recebido comprova alcance. Ainda faltam associação, veredito de política, encaminhamento, entrega ao cliente e aceitação pela aplicação.

Context IDs expressam a relação com o par

Clientes alocam números pares; proxies, ímpares. O valor zero é proibido no modo exclusivamente vinculado. Ele mantém o significado fixo do RFC 9298 apenas quando existe um destino de recuo real.

Três Capsules controlam o ciclo. COMPRESSION_ASSIGN (0x11) propõe o significado de um ID. COMPRESSION_ACK (0x12) confirma que o receptor salvou a associação. COMPRESSION_CLOSE (0x13) recusa ou encerra o estado.

Versão IP zero cria um contexto não comprimido: cada datagrama inclui endereço e porta. Do cliente para o proxy, eles apontam o destino; no caminho inverso, a origem recebida. Versão quatro ou seis cria um contexto comprimido, no qual a tupla é registrada uma vez e o ID passa a representá-la.

Não se pode atribuir o mesmo ID duas vezes, abrir dois IDs para a mesma tupla ou reutilizar um número fechado. Dados reordenados que chegam depois do fechamento são descartados. Assim, um identificador antigo não recupera poder sobre uma relação nova.

É permitido enviar antes do ACK para reduzir latência, sabendo que os dados podem ser perdidos se a associação ainda não chegou ou foi recusada. O envio antecipado é uma decisão de risco do emissor, não uma prova de aceitação pelo outro lado.

O cliente controla a passagem dos desconhecidos

Só o cliente pode pedir o contexto não comprimido, e apenas um pode ficar aberto. Ele é amplo porque cada datagrama pode nomear uma tupla ainda não vista.

Se o cliente não o abrir ou decidir fechá-lo, o proxy passa a filtrar remetentes desconhecidos. As associações comprimidas já existentes permanecem válidas, mas o proxy não pode criar novas depois do fechamento do contexto amplo. Isso impediria o cliente de exercer seu veto.

A porta pública continua existindo, mas o conjunto permitido diminui. Alocação, par conhecido e origem desconhecida são estados diferentes.

Cada novo destino reencontra a política

No CONNECT-UDP fixo, o proxy pode verificar o destino na criação. No modo vinculado, o destino se move para cada datagrama ou registro, e a verificação precisa acompanhá-lo.

O proxy testa IP e porta de cada datagrama não comprimido. Para um contexto comprimido, testa a tupla recebida em COMPRESSION_ASSIGN e rejeita o que a política proíbe. O operador pode proteger loopback, redes privadas, link-local, planos administrativos ou serviços específicos.

O texto não define toda a política empresarial. Ele define o local mínimo em que uma tupla variável não pode escapar ao controle.

TURN oferece uma comparação útil. Alocação do endereço de relay, permissões de pares e channel bindings são estados separados. Os mecanismos diferem, mas ensinam a mesma cautela: obter o relay não autoriza todos os interlocutores.

Limites de memória também limitam autoridade

Cada Context ID consome memória. ACKs e CLOSEs presos por controle de fluxo ou congestionamento consomem buffer. A especificação exige um teto para contextos simultâneos e outro para respostas pendentes. Se o segundo for atingido no proxy, o fluxo da solicitação deve ser abortado.

É necessário observar configuração, ocupação, recusas, filas, abortos e versões afetadas. Sem essa evidência, a defesa contra esgotamento parece uma falha aleatória e pode ser removida justamente quando está protegendo o serviço.

Alternar entre representações muda o MTU efetivo. O formato não comprimido repete IP e porta; o comprimido não. A transição pode atrapalhar DPLPMTUD, motivo para solicitar compressão cedo. Métricas de tamanho, perda e sucesso de caminho precisam confirmar a escolha.

Uma IP pública pode representar muitas decisões

O RFC 6269 descreve os efeitos de compartilhar endereços: atribuição imprecisa, reputação comum e bloqueios excessivos. Atrás de uma IP do proxy podem existir muitas portas, túneis, identidades de cliente, associações e tuplas remotas.

Uma investigação precisa ligar porta pública, túnel, cliente autenticado, Context ID, par, política e resultado do encaminhamento. Um scanner descartado na borda não deve aparecer como tráfego entregue a um usuário.

A prova completa de um datagrama

Uma trilha defensável conserva:

  1. solicitação autenticada e identidade do túnel;
  2. negociação verdadeira nos dois sentidos;
  3. modo com recuo ou exclusivamente vinculado;
  4. tupla pública e sua duração;
  5. alocador e valor único do Context ID;
  6. ASSIGN, ACK e CLOSE;
  7. semântica comprimida ou não;
  8. tupla remota exata;
  9. versão e decisão da política;
  10. orçamento de contextos e respostas;
  11. aceitação, descarte ou espera;
  12. transmissão ou recepção no socket;
  13. entrega ao cliente e resultado do ICE ou da aplicação.

Mesmo uma associação válida pode terminar em perda ou falha no teste de conectividade. O estado do protocolo permite processar; a execução observada prova que o caminho funcionou. O princípio de Running-Code Primacy deixa clara a divisão: a norma oferece o mínimo comum, enquanto o operador responde pela realidade local.

Fontes