Resumo

  • RFC 3360 alertou que caminhos com políticas diferentes para bits reservados poderiam bloquear extensões TCP e até mudar de comportamento quando a rota mudasse.
  • Um retry sem ECE/CWR prova somente conectividade reduzida pelo caminho observado; não prova incapacidade do servidor, origem do reset, estabilidade multipath nem reparo.

O primeiro fluxo atravessou o provedor A e negociou ECN. Depois de uma mudança de rota, a nova tentativa passou pelo provedor B, recebeu RST no SYN com ECE e CWR e conectou apenas quando o cliente removeu os dois bits.

Os endpoints eram os mesmos. A política efetiva de TCP não era.

RFC 3360 foi publicada em agosto de 2002 como BCP 60. O documento descreve firewalls e load balancers que resetavam SYNs por usarem partes antes reservadas do cabeçalho TCP. Não é uma medição do mercado atual e não comprova comportamento de nenhum operador presente. Seu valor duradouro está em mostrar que um caminho contém participantes capazes de ampliar ou reduzir o protocolo sem aparecer como endpoints.

O reset fala a língua do estado remoto

RFC 793 reservou RST para contradições delimitadas de conexão: um segmento parece não pertencer ao estado corrente, uma solicitação chega a uma conexão inexistente, ou outra condição de máquina de estados exige abortar. RFC 9293 preserva regras próprias para gerar e validar reset.

Por isso a aplicação interpreta RST como decisão forte. Ela não espera RTO; encerra. Quando um middlebox usa a mesma forma para expressar “não reconheço este flag”, ele atribui sua limitação ao servidor.

Isso não elimina política de segurança. RFC 2979 permite ao site bloquear tráfego que considere ilegítimo. A pergunta é se o bloqueio permanece identificável como decisão local. RFC 3360 não discute o simples fechamento de uma porta inteira, mas a situação em que o equipamento encaminha TCP comum e rejeita um formato válido do mesmo protocolo.

ECN expôs a dependência do caminho

RFC 3168 definiu a negociação TCP de ECN com ECE e CWR, alocados no antigo campo Reserved. O iniciador configura ambos no SYN. Um peer compatível responde no padrão ECN; um peer antigo deveria ignorar bits desconhecidos e devolver SYN-ACK comum.

O mecanismo evitava exigir implementação de ECN em todos os intermediários. Bastava que eles não transformassem desconhecimento em falha. Alguns transformaram. RFC 3360 registrou em março de 2002 resets em 203 e drops em 420 dos 12.364 sites testados. O número é histórico; a relação causal é arquitetônica.

Uma captura única não localiza o emissor. Endereço, ACK, TTL e tempo ajudam a comparar hipóteses, mas um appliance on-path consegue fabricar campos coerentes. Observações antes e depois do dispositivo, bypass, logs e repetição por rotas distintas são a evidência mais forte.

Multipath quebra conclusões binárias

Em uma rede com ECMP, trânsito alternativo, anycast ou failover, um teste bem-sucedido pode usar uma sequência de middleboxes diferente da sessão seguinte. RFC 3360 já observava a dificuldade de políticas diferentes caso o caminho mudasse durante a vida de uma conexão.

Assim, “o servidor suporta ECN” e “este caminho permite negociar ECN” não são a mesma afirmação. A primeira pertence ao endpoint sob determinada configuração. A segunda combina endpoint, rota, aparelhos, firmware e regras naquele instante.

O inventário precisa guardar a topologia de observação, não apenas o par de IPs. Uma taxa agregada por destino pode misturar um caminho saudável e outro intolerante, produzindo um valor intermediário que não descreve nenhum deles.

Fallback não normaliza os caminhos

O workaround envia um SYN sem ECE/CWR depois de RST ao SYN ECN. Se funciona, estabelece TCP sem ECN; se recebe outro reset, aborta. Para o usuário, a recuperação é valiosa. Para a investigação, ela cria um ramo separado.

O sucesso do ramo simples não mostra que o peer não entendia ECN. O primeiro SYN pode ter sido perdido. O reset pode ter vindo do servidor ou da rota. O retry pode ainda ter tomado outro caminho. Sem registrar esses fatos, fallback apaga exatamente a condição necessária para corrigir a rede.

Alguns implementadores evitaram o mecanismo porque ele podia ignorar o primeiro reset válido, atrasar a conexão e legitimar equipamento quebrado. RFC 7413 descreve tensão semelhante no TCP Fast Open: unknown options e SYN data podem ser descartados, levando ao handshake normal. Disponibilidade final e preservação da capability precisam de indicadores distintos.

Segurança de reset é outra camada

RFC 5961 passou a exigir challenge ACK para certos resets em conexões estabelecidas, dificultando injeção cega. A validação de sequence reduz falsos encerramentos por atacante off-path.

Ela não autentica o motivo de um reset ao SYN inicial. Também não elimina middleboxes que mantêm estado incompatível; o próprio RFC analisa loops ACK/RST e challenge ACKs descartados após a caixa apagar o flow.

Uma mensagem pode ser válida para o parser e ilegítima como atribuição. Automação que transforma RST observed diretamente em server refused pula esse limite.

Ossificação é dependência sem contrato

RFC 3360 advertiu que caixas instaladas poderiam congelar TCP. Uma extensão padronizada continua impraticável se caminhos suficientes a rejeitam. Os endpoints então removem a novidade para preservar alcance, e o comportamento privado vira especificação operacional.

RFC 6709 e RFC 9170 mostram que extension points sobrevivem por uso ativo e feedback. RFC 8701 usa GREASE em TLS para provocar valores desconhecidos e revelar intolerância. A técnica não resolve todo caso TCP, mas expressa o dever de testar variação antes que a dependência endureça.

Na formulação de Heng Lu, decisões futuras devem permanecer localizadas e a adoção deve ser voluntária. Um operador pode negar uma função. Mas seu dispositivo não deveria fazer essa negativa parecer estado inevitável do outro endpoint. Quando faz, o operador exerce poder sobre a evolução sem assumir a autoria da decisão.

Provar o caminho que falhou

O pacote original precisa ser preservado com flags, options, endereços e tempo. Cada saída relevante recebe seu próprio identificador de caminho e versão de middlebox. O RST é validado, mas sua origem continua uma conclusão a demonstrar.

Uma regra intencional precisa de owner, motivo, aprovação, versão e expiração. O fallback registra se nasceu de RST ou timeout e se o retry permaneceu no mesmo caminho. Testes controlados devem fixar rota quando possível ou, no mínimo, observar as diferenças.

Depois da mudança, o SYN com extensão deve atravessar o dispositivo, chegar ao peer e obter resposta condizente. Só então vêm dados no modo negociado e resultado da aplicação. O fato de um firmware ter sido atualizado não prova o efeito.

O fechamento operacional exige matriz de caminhos. Um exit saudável e outro degradado não formam uma média saudável; formam duas realidades que precisam de decisões próprias.

Limites

As fontes não apontam implantação atual nem dizem que todo RST ECN é impróprio. Também não obrigam firewall a aceitar qualquer bit desconhecido. Política explícita continua possível.

Handshake simples não comprova falta de ECN. Handshake ECN não comprova congestion marking, feedback, reação do sender ou ganho da aplicação. E um teste por uma rota não certifica todas as rotas.

A conclusão é sobre escopo: capacidade TCP é uma propriedade observada do caminho inteiro. O endpoint sozinho não pode garantir aquilo que intermediários têm poder de apagar.

Fontes