AH eller ESP? Avgjer ut frå kva pakken må verne

To IPsec-framlegg kan nemne den same SHA-baserte integritetsalgoritmen og likevel krevje ulike verneprotokollar; AH og ESP er ikkje to stavemåtar for éi autentiseringsinnstilling. Les protokollen først, så algoritmane, så modusen, og det meste av uklarleiken forsvinn. AH autentiserer pakken, medrekna dei IP-hovudfelta som blir uendra undervegs, medan ESP autentiserer og krypterer det han kapslar inn, og lèt det ytre hovudet vere. Den skilnaden avgjer fleire utrullingar enn noko hash-namn.

Kva AH dekkjer som ESP ikkje gjer

AH gjev integritet, autentisering av datakjelda og den anti-replay-tenesta han sjølv definerer, og inga konfidensialitet. Dekninga omfattar data frå øvre lag og dei IP-hovudfelta som reglane hans reknar som uforanderlege, nettopp den delen ESP i transportmodus lèt stå utanfor. Når eit krav seier at sjølve IP-hovudet må autentiserast, er AH protokollen som svarar på det.

Den dekninga er også grunnen til at AH er skøyr i praksis. Foranderlege felt som TTL, hovudkontrollsummen og nokre val kan ikkje autentiserast fordi rutarar kan skrive dei om, så protokollen nullstiller dei før kontrollen blir rekna ut. Alt som skriv om adresser øydelegg derfor utrekninga, ikkje berre policyen.

NAT gjer valet til ei avgrensing

Adresseomsetjing skriv om kjelda eller målet i det IP-hovudet som AH nettopp autentiserte, så integritetskontrollen feilar i den andre enden, og han feilar som ein protokollfeil og ikkje som ei leseleg melding. ESP autentiserer ikkje det ytre hovudet, og difor verkar ESP med NAT-gjennomgang medan AH bak NAT ikkje gjer det. Ein tunnel der begge sider står bak vanlege rutarar, er nettopp staden der dette dukkar opp først. Det første spørsmålet er difor ikkje kva protokoll som er sterkast, men om det står ein omsetjar mellom sidene.

Er det tilfelle, fell AH bort, og samtalen flyttar til ESP og algoritmevala der. Dette er ei avgrensing og ikkje ei preferanse, og difor høyrer ho heime øvst i avgjerda og ikkje til slutt.

Modusen multipliserer spørsmålet

ESP i transportmodus vernar nyttelasta i det øvre laget og lèt IP-hovudet vere; i tunnelmodus kapslar han inn heile den indre pakken, medrekna det indre IP-hovudet, og vernar han. AH har dei same to modusane, så AH eller ESP er faktisk fire kombinasjonar før nokon algoritme blir vald.

ESP-algoritmar i kombinert modus avgjer så integriteten utan ein annan protokoll. AES-GCM og ChaCha20-Poly1305 autentiserer og krypterer i éin konstruksjon, så AH på toppen kjøper ingenting, men kostar eit ekstra hovud og nok ei forhandling. Arkitekturen tillèt AH og ESP saman, og det praktiske spørsmålet er om gatewayen og utgåva di støttar kombinasjonen og om nokon kan vedlikehalde han etterpå.

Den ærlege erstatninga for berre AH

ESP-varianten med berre integritet held på algoritmen og slepp krypteringspåstanden i staden for å late som, og han klarer NAT. Viss eit eldre design brukte AH fordi det trong autentisering utan konfidensialitet, er den varianten den direkte omsetjinga, ikkje ein kryptert tunnel med ein lapp på.

Å sjå ESP i eit framlegg er heller ikkje prov på kryptering. Les krypteringsalgoritmen: ein NULL-oppføring tyder berre integritet, og ein oppføring i kombinert modus tyder begge.

Avgjer med tre spørsmål

Spør om konfidensialitet er naudsynt, om det er ein omsetjar på vegen, og kva hovudfelt som må autentiserast. Dei tre svara peikar på éin protokoll og éin modus, og å skrive dei ned tek kortare tid enn å lese RFC-ane på nytt seinare.

Verifiser deretter det som vart godteke, og ikkje det som vart føreslått. ip xfrm state viser protokoll, modus og algoritmar for den installerte assosiasjonen, og eit avvik installerar ingenting, noko som er ein reinare feil enn ein tunnel som kjem opp utan vernet du hadde tenkt.

Hald autentiseringsfeil, selektordekning og rutingsfeil åtskilde frå dette valet. Dei gjev ulike symptom, og å skylde på protokollen for eit selektorproblem er ein påliteleg måte å bruke ein dag på å byte hashar utan grunn.