AH oder ESP? Entscheidend ist, was das Paket schützen muss

Zwei IPsec-Vorschläge können denselben SHA-basierten Integritätsalgorithmus nennen und dennoch unterschiedliche Schutzprotokolle verlangen; AH und ESP sind nicht zwei Schreibweisen einer Authentifizierungseinstellung. Lesen Sie zuerst das Protokoll, dann seine Algorithmen, dann seinen Modus, und der größte Teil der Unklarheit verschwindet. AH authentifiziert das Paket einschließlich der IP-Header-Felder, die während des Transits unverändert bleiben, während ESP authentifiziert und verschlüsselt, was es kapselt, und den äußeren Header in Ruhe lässt. Dieser Unterschied entscheidet über mehr Bereitstellungen als jeder Hash-Name.

Was AH abdeckt und ESP nicht

AH liefert Integrität, Datenursprungsauthentifizierung und den von ihm definierten Anti-Replay-Dienst, und keinerlei Vertraulichkeit. Die Abdeckung umfasst Daten der oberen Schicht sowie die IP-Header-Felder, die seine Regeln als unveränderlich behandeln, genau den Teil, den ESP im Transportmodus außen vor lässt. Wenn eine Anforderung verlangt, dass der IP-Header selbst authentifiziert wird, ist AH das Protokoll, das darauf antwortet.

Diese Abdeckung ist auch der Grund, warum AH in der Praxis fragil ist. Veränderliche Felder wie TTL, die Header-Prüfsumme und einige Optionen lassen sich nicht authentifizieren, weil Router sie umschreiben dürfen, deshalb nullt das Protokoll sie vor der Berechnung der Prüfsumme. Alles, was Adressen umschreibt, bricht daher die Berechnung und nicht nur die Richtlinie.

NAT macht die Wahl zur Einschränkung

Adressübersetzung schreibt die Quelle oder das Ziel im IP-Header um, den AH gerade authentifiziert hat, also scheitert die Integritätsprüfung am fernen Ende, und zwar als Protokollfehler und nicht als lesbare Meldung. ESP authentifiziert den äußeren Header nicht, deshalb funktioniert ESP mit NAT-Traversal und AH hinter NAT nicht. Ein Tunnel, dessen beide Seiten hinter gewöhnlichen Routern stehen, ist genau der Ort, an dem das zuerst auftritt. Die erste Frage ist daher nicht, welches Protokoll stärker ist, sondern ob ein Übersetzer zwischen den Seiten sitzt.

Ist das der Fall, fällt AH weg, und das Gespräch geht zu ESP und dessen Algorithmuswahl über. Das ist eine Einschränkung und keine Vorliebe, deshalb gehört sie an den Anfang der Entscheidung und nicht an ihr Ende.

Der Modus vervielfacht die Frage

ESP im Transportmodus schützt die Nutzlast der oberen Schicht und lässt den IP-Header unberührt; im Tunnelmodus kapselt es das gesamte innere Paket einschließlich des inneren IP-Headers und schützt dieses. AH hat dieselben zwei Modi, AH oder ESP sind also in Wahrheit vier Kombinationen, bevor irgendein Algorithmus gewählt wird.

ESP-Algorithmen im kombinierten Modus klären dann die Integrität ohne ein zweites Protokoll. AES-GCM und ChaCha20-Poly1305 authentifizieren und verschlüsseln in einer Konstruktion, deshalb bringt AH obendrauf nichts, kostet aber einen weiteren Header und eine weitere Aushandlung. Die Architektur erlaubt AH und ESP zusammen, und die praktische Frage ist ob Ihr Gateway und Ihre Version die Kombination unterstützen und ob jemand sie danach pflegen kann.

Der ehrliche Ersatz für reines AH

Die ESP-Variante nur mit Integrität behält den Algorithmus und lässt die Verschlüsselungsaussage fallen, statt sie vorzutäuschen, und sie übersteht NAT. Wenn ein Altentwurf AH nutzte, weil Authentifizierung ohne Vertraulichkeit gebraucht wurde, ist diese Variante die direkte Übersetzung und kein verschlüsselter Tunnel mit angehängter Notiz.

ESP in einem Vorschlag zu sehen ist ebenso wenig ein Beweis für Verschlüsselung. Lesen Sie den Verschlüsselungsalgorithmus: ein NULL-Eintrag bedeutet nur Integrität, ein Eintrag im kombinierten Modus bedeutet beides.

Entscheiden Sie in drei Fragen

Fragen Sie, ob Vertraulichkeit nötig ist, ob ein Übersetzer auf dem Pfad liegt und welche Header-Felder authentifiziert werden müssen. Diese drei Antworten zeigen auf ein Protokoll und einen Modus, und sie aufzuschreiben dauert weniger Zeit, als die RFCs später erneut zu lesen.

Prüfen Sie dann, was akzeptiert wurde, und nicht, was vorgeschlagen wurde. ip xfrm state zeigt Protokoll, Modus und Algorithmen der installierten Assoziation, und eine Abweichung installiert gar nichts, was ein saubereres Scheitern ist als ein Tunnel, der ohne den beabsichtigten Schutz hochkommt.

Halten Sie Authentifizierungsfehler, Selektorabdeckung und Routingfehler von dieser Wahl getrennt. Sie erzeugen unterschiedliche Symptome, und dem Protokoll ein Selektorproblem anzulasten ist ein verlässlicher Weg, einen Tag mit grundlosem Hashwechsel zu verbringen.