Zusammenfassung

  • Eine Nicht-NAT-Middlebox kann TCP-Optionen ändern, wenn beide Endpunkte alle Nicht-AO-Optionen aus der MAC-Berechnung ausschließen.
  • NAT oder NAPT ändert Adressen oder Ports. Diese definieren die authentisierte Verbindung, daher reicht die Optionskonfiguration dafür nicht aus.

Zwei Arten von Änderungen

Das Flag im Master Key Tuple legt für alle TCP-Optionen außer TCP-AO fest, ob sie in die MAC eingehen. Bei Aktivierung werden sie in ihrer Übertragungsreihenfolge geschützt; bei Deaktivierung werden sie vollständig ausgelassen. TCP-AO selbst bleibt geschützt. Damit kann ein Gerät toleriert werden, das etwa einen Zeitstempel umschreibt. Der Preis ist eine schwächere Absicherung: Zeitstempel und Window-Scale können verändert werden und dadurch Effizienz oder korrekten Betrieb beeinträchtigen.

IP-Adressen und TCP-Ports sind dagegen nicht optional. RFC 5925 erklärt, dass sie die Verbindung definieren und ihre Abdeckung deshalb nicht abgeschaltet werden kann. Ändert ein Übersetzer das Tupel, berechnen die Endpunkte die MAC über unterschiedliche Verbindungsidentitäten. TCP-AO kann daher nicht nativ über ein unkoordiniertes NAT/NAPT funktionieren.

Als mögliche Wege nennt RFC 5925 die Koordination der sichtbaren Werte, Kapselung oder IPsec mit NAT-Traversal. Ein einheitliches natives TCP-AO-Verfahren oder einen bestimmten Tunnel schreibt der RFC nicht vor.

Eine prüfbare Grenze

Entscheidend ist nicht nur, dass ein Datenstrom funktioniert. Ermittelt werden muss, welche Bytes jeder Endpunkt in die MAC einbezog und welches Gerät sie ändern durfte. Erreichbarkeit beweist nicht, dass die übersetzten TCP-Header Ende zu Ende authentisiert wurden.

Quellen