Résumé

  • TCP-AO peut authentifier un reset lorsque les deux extrémités possèdent encore l’état de connexion et les clés correspondantes.
  • Après un redémarrage, un reset non vérifiable est rejeté ; la connexion devenue obsolète doit alors être éliminée par la détection de vivacité ou par la récupération applicative.

Quand un seul pair a oublié la connexion

Avant la panne, chaque extrémité connaît la connexion TCP, ses numéros de séquence initiaux et les clés de trafic dérivées. Un reset reçu dans ce contexte peut donc être authentifié.

Le redémarrage d’un routeur peut toutefois effacer cet historique. Il peut encore savoir qu’il utilise TCP-AO avec son voisin, sans pouvoir reconstituer le contexte de l’ancienne connexion. RFC 5925 indique que, lorsque la paire de numéros de séquence initiaux est inconnue, le reset doit être envoyé sans authentification. Le pair qui exige TCP-AO ne peut pas valider ce segment et le rejette.

L’asymétrie est volontaire : l’un dit que la connexion n’existe plus, tandis que l’autre conserve une connexion pour laquelle il n’a reçu aucune preuve acceptable.

Pourquoi le reset honnête doit être rejeté

Accepter cette exception permettrait à un attaquant de fabriquer le même reset non authentifié et de fermer une session protégée. Le protocole ne peut pas distinguer l’intention bienveillante d’un pair redémarré de celle d’un forgeur sur la seule base du paquet.

Le coût est un nettoyage moins rapide. Le pair survivant peut garder un état obsolète jusqu’à l’expiration d’un mécanisme de vivacité. RFC 5925 recommande les keepalives TCP ou applicatifs et demande aux implémentations de détecter puis de supprimer les états de connexion excessifs afin de protéger la mémoire.

Sources