AH eller ESP? Beslut ud fra hvad pakken skal beskytte

To IPsec-forslag kan nævne den samme SHA-baserede integritetsalgoritme og alligevel kræve forskellige beskyttelsesprotokoller; AH og ESP er ikke to stavemåder for én autentificeringsindstilling. Læs først protokollen, så dens algoritmer, så dens tilstand, og det meste af uklarheden forsvinder. AH autentificerer pakken, inklusive de felter i IP-headeren der forbliver uændrede undervejs, mens ESP autentificerer og krypterer det, den indkapsler, og lader den ydre header være. Den forskel afgør flere udrulninger end noget hash-navn.

Hvad AH dækker, som ESP ikke gør

AH giver integritet, autentificering af dataoprindelse og den anti-replay-tjeneste, den selv definerer, og ingen fortrolighed. Dækningen omfatter data fra det øverste lag plus de felter i IP-headeren, som dens regler anser for uforanderlige, præcis den del ESP i transporttilstand lader stå udenfor. Når et krav siger, at selve IP-headeren skal autentificeres, er AH den protokol, der svarer på det.

Den dækning er også grunden til, at AH er skrøbelig i praksis. Foranderlige felter som TTL, headerns kontrolsum og nogle tilvalg kan ikke autentificeres, fordi routere kan skrive dem om, så protokollen nulstiller dem, før kontrolsummen beregnes. Alt, der skriver adresser om, ødelægger derfor beregningen og ikke bare politikken.

NAT gør valget til en begrænsning

Adresseoversættelse skriver kilden eller destinationen om i den IP-header, som AH netop har autentificeret, så integritetskontrollen fejler i den anden ende, og den fejler som en protokolfejl og ikke som en besked, du kan læse. ESP autentificerer ikke den ydre header, og derfor virker ESP med NAT-gennemførsel, mens AH bag NAT ikke gør. En tunnel, hvis parter står bag almindelige routere, er netop der, hvor det viser sig først. Det første spørgsmål er derfor ikke, hvilken protokol der er stærkest, men om der står en oversætter mellem parterne.

Gør der det, er AH ude, og samtalen flytter til ESP og dens algoritmevalg. Det er en begrænsning og ikke en præference, og derfor hører den til øverst i beslutningen og ikke til sidst.

Tilstand ganger spørgsmålet

ESP i transporttilstand beskytter nyttelasten i det øverste lag og lader IP-headeren være; i tunneltilstand indkapsler den hele den indre pakke, inklusive den indre IP-header, og beskytter den. AH har de samme to tilstande, så AH eller ESP er i virkeligheden fire kombinationer, før nogen algoritme vælges.

ESP-algoritmer i kombineret tilstand afgør så integriteten uden en anden protokol. AES-GCM og ChaCha20-Poly1305 autentificerer og krypterer i én konstruktion, så AH ovenpå køber intet, men koster en ekstra header og endnu en forhandling. Arkitekturen tillader AH og ESP sammen, og det praktiske spørgsmål er om din gateway og din udgivelse understøtter kombinationen og om nogen kan vedligeholde den bagefter.

Den ærlige erstatning for kun AH

ESP-varianten med kun integritet beholder algoritmen og dropper krypteringspåstanden i stedet for at foregive den, og den klarer NAT. Hvis et ældre design brugte AH, fordi det havde brug for autentificering uden fortrolighed, er den variant den direkte oversættelse og ikke en krypteret tunnel med en note vedhæftet.

At se ESP i et forslag er heller ikke bevis på kryptering. Læs krypteringsalgoritmen: en NULL-post betyder kun integritet, og en post med kombineret tilstand betyder begge.

Beslut med tre spørgsmål

Spørg, om fortrolighed er påkrævet, om der er en oversætter på vejen, og hvilke headerfelter der skal autentificeres. De tre svar peger på én protokol og én tilstand, og at skrive dem ned tager kortere tid end at læse RFCerne igen senere.

Verificér derefter, hvad der blev accepteret, og ikke hvad der blev foreslået. ip xfrm state viser den installerede associations protokol, tilstand og algoritmer, og en uoverensstemmelse installerer intet, hvilket er et renere fejltrin end en tunnel, der kommer op uden den beskyttelse, du havde tænkt dig.

Hold autentificeringsfejl, selektordækning og routingfejl adskilt fra dette valg. De giver forskellige symptomer, og at give protokollen skylden for et selektorproblem er en pålidelig måde at bruge en dag på at skifte hashes uden grund.