Resumen

  • Un middlebox que conserva las direcciones y los puertos puede modificar opciones TCP si ambos extremos excluyen de la MAC todas las opciones que no sean TCP-AO.
  • NAT o NAPT cambia direcciones o puertos, que TCP-AO trata como identidad de la conexión; el indicador de opciones no resuelve ese cambio.

Una diferencia que importa

El indicador del Master Key Tuple controla todas las opciones TCP distintas de TCP-AO. Cuando está activado, las cubre en el orden transmitido; cuando está desactivado, las omite todas. TCP-AO sigue protegido. Esto permite tolerar un reescritor de opciones, pero con un coste: un atacante puede modificar esas opciones, alterando, por ejemplo, marcas de tiempo o escalas de ventana.

Las direcciones IP y los puertos no son una categoría opcional. RFC 5925 los incluye entre los parámetros de seguridad y afirma que su cobertura no puede desactivarse porque definen una conexión. Si un traductor cambia la tupla, los extremos calculan la MAC sobre identidades distintas. Por eso TCP-AO no puede interoperar nativamente a través de NAT/NAPT no coordinado.

El RFC apunta a coordinar los valores visibles, encapsular el tráfico o utilizar IPsec con NAT traversal. No establece un protocolo universal de traducción para TCP-AO ni prescribe un túnel concreto.

La frontera que debe conservarse

La evidencia útil no es solamente que el flujo funcione. Hay que saber qué campos incluyó cada extremo en la MAC y qué elemento del camino podía modificarlos. Un flujo exitoso no demuestra por sí mismo que TCP-AO autenticara los encabezados posteriores a la traducción.

Fuentes