Résumé

  • Un équipement qui modifie uniquement les options TCP peut être pris en charge si les deux extrémités excluent de l’empreinte MAC toutes les options autres que TCP-AO.
  • NAT et NAPT réécrivent des adresses ou des ports, qui font partie de la paire de sockets authentifiée. Le même réglage ne peut donc pas les rendre compatibles.

Deux interventions, deux limites

Le drapeau du Master Key Tuple choisit si les options TCP autres que TCP-AO entrent dans le calcul MAC. Activé, il couvre toutes ces options dans leur ordre de transmission ; désactivé, il les omet toutes. TCP-AO reste couvert. Cette concession peut donc absorber la réécriture d’une option, mais elle affaiblit la protection : une modification d’horodatage peut réduire l’efficacité et une modification de l’échelle de fenêtre peut empêcher le fonctionnement correct.

Les adresses IP et les ports sont d’une autre nature. RFC 5925 les inclut dans les paramètres de sécurité et indique que leur couverture n’est pas facultative, car ils définissent la connexion. Un traducteur qui change le tuple fait calculer aux extrémités des valeurs différentes ; il ne s’agit plus d’une simple modification d’option. TCP-AO ne fonctionne donc pas nativement à travers un NAT ou un NAPT non coordonné.

Le RFC mentionne la coordination des valeurs, l’encapsulation ou IPsec avec traversée NAT comme voies possibles. Il ne définit pas de protocole natif universel ni de choix de tunnel obligatoire.

Une frontière de sécurité explicite

La question opérationnelle est de savoir quels octets chaque extrémité a placés dans la MAC et quel équipement pouvait les changer. Un flux qui aboutit ne prouve pas que les en-têtes après traduction ont été authentifiés de bout en bout.

Sources