AH of ESP? Beslis op basis van wat het pakket moet beschermen

Twee IPsec-voorstellen kunnen hetzelfde op SHA gebaseerde integriteitsalgoritme noemen en toch verschillende beschermingsprotocollen vragen; AH en ESP zijn geen twee spellingen van één authenticatie-instelling. Lees eerst het protocol, dan de algoritmen, dan de modus, en het meeste onduidelijkheid verdwijnt. AH authenticeert het pakket, inclusief de IP-headervelden die onderweg ongewijzigd blijven, terwijl ESP authenticeert en versleutelt wat het inkapselt en de buitenste header met rust laat. Dat verschil bepaalt meer uitrollingen dan welke hashnaam dan ook.

Wat AH dekt en ESP niet

AH levert integriteit, authenticatie van de herkomst van gegevens en de door hem gedefinieerde anti-replaydienst, en geen enkele vertrouwelijkheid. De dekking omvat gegevens van de bovenlaag en de IP-headervelden die zijn regels als onveranderlijk beschouwen, precies het deel dat ESP in transportmodus buiten beschouwing laat. Als een eis zegt dat de IP-header zelf moet worden geauthenticeerd, is AH het protocol dat daarop antwoordt.

Die dekking is ook de reden dat AH in de praktijk kwetsbaar is. Veranderlijke velden zoals TTL, de headercontrolesom en sommige opties kunnen niet worden geauthenticeerd omdat routers ze mogen herschrijven, dus zet het protocol ze op nul voordat de controle wordt berekend. Alles wat adressen herschrijft, breekt dus de berekening en niet alleen het beleid.

NAT maakt de keuze tot een beperking

Adresvertaling herschrijft de bron of bestemming in de IP-header die AH zojuist heeft geauthenticeerd, dus de integriteitscontrole faalt aan de andere kant, en wel als protocolfout en niet als een leesbaar bericht. ESP authenticeert de buitenste header niet, daarom werkt ESP met NAT-traversal en AH achter NAT niet. Een tunnel waarvan beide zijden achter gewone routers staan, is precies de plek waar dit het eerst optreedt. De eerste vraag is dus niet welk protocol sterker is, maar of er een vertaler tussen de zijden zit.

Is dat zo, dan valt AH af, en het gesprek gaat naar ESP en de algoritmekeuzes daarvan. Dat is een beperking en geen voorkeur, daarom hoort die bovenaan de beslissing en niet aan het eind.

De modus vermenigvuldigt de vraag

ESP in transportmodus beschermt de payload van de bovenlaag en laat de IP-header met rust; in tunnelmodus kapselt het het hele binnenste pakket in, inclusief de binnenste IP-header, en beschermt dat. AH heeft dezelfde twee modi, dus AH of ESP zijn in werkelijkheid vier combinaties voordat een algoritme wordt gekozen.

ESP-algoritmen in gecombineerde modus regelen dan de integriteit zonder tweede protocol. AES-GCM en ChaCha20-Poly1305 authenticeren en versleutelen in één constructie, dus AH erbovenop levert niets op maar kost een extra header en nog een onderhandeling. De architectuur staat AH en ESP samen toe, en de praktische vraag is of uw gateway en uw release de combinatie ondersteunen en of iemand die daarna kan onderhouden.

De eerlijke vervanging voor alleen AH

De ESP-variant met alleen integriteit behoudt het algoritme en laat de versleutelingsclaim vallen in plaats van die na te bootsen, en hij komt door NAT. Als een ouder ontwerp AH gebruikte omdat authenticatie zonder vertrouwelijkheid nodig was, is die variant de directe vertaling, en niet een versleutelde tunnel met een notitie erbij.

ESP in een voorstel zien is ook geen bewijs van versleuteling. Lees het versleutelingsalgoritme: een NULL-vermelding betekent alleen integriteit, en een vermelding in gecombineerde modus betekent beide.

Beslis in drie vragen

Vraag of vertrouwelijkheid nodig is, of er een vertaler op het pad zit en welke headervelden moeten worden geauthenticeerd. Die drie antwoorden wijzen op één protocol en één modus, en ze opschrijven kost minder tijd dan de RFC s later opnieuw lezen.

Controleer daarna wat is geaccepteerd en niet wat is voorgesteld. ip xfrm state toont protocol, modus en algoritmen van de geïnstalleerde associatie, en een afwijking installeert niets, wat een schonere fout is dan een tunnel die opkomt zonder de bedoelde bescherming.

Houd authenticatiefouten, selectordekking en routeringsfouten gescheiden van deze keuze. Ze geven verschillende symptomen, en het protocol de schuld geven van een selectorprobleem is een betrouwbare manier om een dag te besteden aan het zonder reden wisselen van hashes.