Resumo

  • O TCP-AO autentica resets enquanto os dois extremos ainda têm o estado da conexão e as chaves de tráfego.
  • Depois de uma reinicialização, um reset que não pode ser verificado é descartado; o estado antigo precisa ser removido por mecanismos de atividade ou pela recuperação da aplicação.

A reinicialização cria uma assimetria

Antes da falha, os dois extremos conhecem a conexão TCP, os números de sequência iniciais e as chaves derivadas para aquela conexão. Um reset nesse contexto pode ser autenticado.

Um roteador reiniciado pode continuar configurado para usar TCP-AO, mas ter perdido a conexão específica. A RFC 5925 afirma que, quando o par de números de sequência iniciais é desconhecido, como ao enviar um reset depois da reinicialização, o reset deve ser enviado sem autenticação. O outro extremo, se exigir TCP-AO, não consegue validar o segmento e o descarta.

Um lado afirma que a conexão não existe mais; o outro ainda mantém a conexão antiga, mas não recebeu uma prova que possa aceitar.

Por que o reset legítimo precisa ser recusado

Tratar o reset não autenticado como exceção permitiria que um atacante forjasse o mesmo pacote e encerrasse uma sessão protegida. O receptor não consegue distinguir a intenção de um par que reiniciou da intenção de um falsificador apenas pelo conteúdo do pacote.

A consequência é uma limpeza mais lenta. O extremo sobrevivente pode manter estado obsoleto até concluir, por seus próprios mecanismos de atividade, que a conexão não progride. A RFC 5925 recomenda keepalives TCP ou da aplicação e exige que as implementações detectem e eliminem o excesso de estado de conexões para proteger a memória.

Fontes