Resumo

  • Antes de validar o endereço do par, uma ponta QUIC que responde não pode enviar mais de três vezes os bytes recebidos dele.
  • O registro limita amplificação com origem falsificada numa fase específica; não autentica o cliente nem elimina outros riscos de negação de serviço.
  • Contadores e a transição de validação são necessários para distinguir uma espera correta de perda ou saturação.

Imagine um servidor que recebe um datagrama Initial, prepara seu flight de handshake e consome todo o crédito permitido. O restante está pronto; o caminho pode estar alcançável e o processo pode ter recursos. Mesmo assim, o servidor precisa esperar mais bytes do cliente ou a validação do endereço.

Essa é a fronteira da RFC 9000. Um atacante pode falsificar o endereço de uma vítima e induzir o servidor a enviar tráfego para ela. Para limitar a reflexão, uma ponta que responde a endereço não validado não deve enviar mais de três vezes o volume recebido daquele endereço.

O modelo correto é um livro-caixa cumulativo. Bytes recebidos elevam o teto; bytes enviados gastam o orçamento. A regra não triplica cada pacote de entrada isoladamente, e o último datagrama não revela o saldo completo.

A Seção 8.1 aplica a conta à abertura da conexão. O servidor inclui todos os bytes de payload em datagramas atribuídos de modo único à conexão. A perda de um Initial ou Handshake do servidor consome crédito, enquanto o cliente pode não ter razão para enviar mais se tudo o que transmitiu já foi reconhecido. A RFC descreve o impasse possível nesse limite.

Um registro operacional deve guardar bytes recebidos e enviados, teto e saldo, momento do bloqueio e tamanho do flight pendente. Sem isso, perda, orçamento esgotado e pressão de recursos aparecem como o mesmo timeout.

A validação faz uma afirmação limitada. Na abertura, receber Handshake ou validar um token no Initial pode mudar o estado. Retry pode exigir que o cliente devolva um token recebido no endereço declarado. Num caminho novo, a Seção 8.2 usa PATH_CHALLENGE e PATH_RESPONSE correspondente para provar alcançabilidade entre endereços específicos. Um ACK isolado é insuficiente porque pode ser falsificado.

Isso não identifica quem usa o endereço. Demonstra capacidade de receber ou satisfaz uma regra de token; não autentica pessoa, dispositivo, conta nem aplicação. Depois da validação, a ponta pode superar o teto triplo. Controle de congestionamento, fluxo, criptografia e política continuam, mas esse registro não é um limite permanente.

Também não é proteção DDoS completa. A Seção 21.2 da RFC 9000 trata da negação de serviço no handshake, enquanto a Seção 21.9 trata de abuso que consome processamento ou estado. Separadamente, a Seção 21.3 descreve o risco residual de amplificação associado a tokens e à reatribuição de endereço. Um teto de banda antes da validação não controla CPU, memória, tabela de conexões, enchentes autenticadas ou carga posterior.

Como recomendação operacional editorial, o painel deve separar: qual evidência testa e valida a alcançabilidade do endereço; qual é o saldo exato da conta; e se métricas independentes de taxa de pacotes, CPU, memória e estado mostram pressão. Assim, a alcançabilidade não vira identidade nem garantia geral de segurança.

O recibo completo recomendado inclui identificadores de conexão e caminho; par IP/porta local e remoto; momento da observação; estado, transição e método de validação; bytes recebidos do endereço não validado e enviados a ele; teto atual de três vezes e orçamento restante; bytes pendentes do flight de handshake; resultado de Retry ou token; resultado de PATH_CHALLENGE/PATH_RESPONSE quando aplicável; contexto de perda e retransmissão; primeiro e último instante de bloqueio; resultado após a validação; e indicadores separados de CPU, memória, estado de conexão e taxa de pacotes.