AH eller ESP? Avgjør ut fra hva pakken må beskytte

To IPsec-forslag kan nevne den samme SHA-baserte integritetsalgoritmen og likevel kreve ulike beskyttelsesprotokoller; AH og ESP er ikke to stavemåter for én autentiseringsinnstilling. Les protokollen først, så algoritmene, så modusen, og det meste av uklarheten forsvinner. AH autentiserer pakken, inkludert de IP-headerfeltene som forblir uendret underveis, mens ESP autentiserer og krypterer det den kapsler inn, og lar den ytre headeren være. Den forskjellen avgjør flere utrullinger enn noe hash-navn.

Hva AH dekker som ESP ikke gjør

AH gir integritet, autentisering av dataopprinnelsen og den anti-replay-tjenesten den selv definerer, og ingen konfidensialitet. Dekningen omfatter data fra øvre lag og de IP-headerfeltene som reglene dens regner som uforanderlige, nettopp den delen ESP i transportmodus lar stå utenfor. Når et krav sier at selve IP-headeren må autentiseres, er AH protokollen som svarer på det.

Den dekningen er også grunnen til at AH er skjør i praksis. Foranderlige felt som TTL, headerkontrollsummen og noen valg kan ikke autentiseres fordi rutere kan skrive dem om, så protokollen nullstiller dem før kontrollen beregnes. Alt som skriver om adresser ødelegger derfor beregningen, ikke bare policyen.

NAT gjør valget til en begrensning

Adresseoversettelse skriver om kilden eller målet i den IP-headeren som AH nettopp autentiserte, så integritetskontrollen feiler i den andre enden, og den feiler som en protokollfeil og ikke som en lesbar melding. ESP autentiserer ikke den ytre headeren, og derfor virker ESP med NAT-gjennomgang mens AH bak NAT ikke gjør det. En tunnel der begge sider står bak vanlige rutere, er nettopp stedet der dette dukker opp først. Det første spørsmålet er derfor ikke hvilken protokoll som er sterkest, men om det står en oversetter mellom sidene.

Er det tilfelle, faller AH bort, og samtalen flytter til ESP og algoritmevalgene der. Dette er en begrensning og ikke en preferanse, og derfor hører den hjemme øverst i beslutningen og ikke til slutt.

Modusen multipliserer spørsmålet

ESP i transportmodus beskytter nyttelasten i det øvre laget og lar IP-headeren være; i tunnelmodus kapsler den inn hele den indre pakken, inkludert den indre IP-headeren, og beskytter den. AH har de samme to modusene, så AH eller ESP er faktisk fire kombinasjoner før noen algoritme velges.

ESP-algoritmer i kombinert modus avgjør så integriteten uten en annen protokoll. AES-GCM og ChaCha20-Poly1305 autentiserer og krypterer i én konstruksjon, så AH på toppen kjøper ingenting, men koster en ekstra header og nok en forhandling. Arkitekturen tillater AH og ESP sammen, og det praktiske spørsmålet er om gatewayen og utgivelsen din støtter kombinasjonen og om noen kan vedlikeholde den etterpå.

Den ærlige erstatningen for bare AH

ESP-varianten med bare integritet beholder algoritmen og slipper krypteringspåstanden i stedet for å late som, og den klarer NAT. Hvis et eldre design brukte AH fordi det trengte autentisering uten konfidensialitet, er den varianten den direkte oversettelsen, ikke en kryptert tunnel med en lapp på.

Å se ESP i et forslag er heller ikke bevis på kryptering. Les krypteringsalgoritmen: en NULL-oppføring betyr bare integritet, og en oppføring i kombinert modus betyr begge.

Avgjør med tre spørsmål

Spør om konfidensialitet er nødvendig, om det er en oversetter på veien, og hvilke headerfelt som må autentiseres. De tre svarene peker på én protokoll og én modus, og å skrive dem ned tar kortere tid enn å lese RFC-ene på nytt senere.

Verifiser deretter det som ble akseptert, og ikke det som ble foreslått. ip xfrm state viser protokoll, modus og algoritmer for den installerte assosiasjonen, og et avvik installerer ingenting, noe som er en renere feil enn en tunnel som kommer opp uten beskyttelsen du hadde tenkt.

Hold autentiseringsfeil, selektordekning og rutingsfeil atskilt fra dette valget. De gir ulike symptomer, og å skylde på protokollen for et selektorproblem er en pålitelig måte å bruke en dag på å bytte hasher uten grunn.