AH eller ESP? Avgör utifrån vad paketet måste skydda

Två IPsec-förslag kan nämna samma SHA-baserade integritetsalgoritm och ändå kräva olika skyddsprotokoll; AH och ESP är inte två stavningar av en autentiseringsinställning. Läs protokollet först, sedan dess algoritmer, sedan dess läge, och det mesta av oklarheten försvinner. AH autentiserar paketet, inklusive de IP-huvudfält som förblir oförändrade på vägen, medan ESP autentiserar och krypterar det den kapslar in och låter det yttre huvudet vara. Den skillnaden avgör fler utrullningar än något hash-namn.

Vad AH täcker som ESP inte gör

AH ger integritet, autentisering av datans ursprung och den anti-replay-tjänst den själv definierar, och ingen konfidentialitet. Täckningen omfattar data från det övre lagret och de IP-huvudfält som dess regler anser vara oföränderliga, just den del som ESP i transportläget lämnar utanför. När ett krav säger att själva IP-huvudet måste autentiseras är AH det protokoll som svarar på det.

Den täckningen är också skälet till att AH är ömtåligt i praktiken. Föränderliga fält som TTL, huvudets kontrollsumma och vissa alternativ kan inte autentiseras eftersom routrar får skriva om dem, så protokollet nollställer dem innan kontrollen beräknas. Allt som skriver om adresser bryter därför beräkningen, inte bara policyn.

NAT gör valet till en begränsning

Adressöversättning skriver om källan eller målet i det IP-huvud som AH just autentiserade, så integritetskontrollen misslyckas i andra änden, och den misslyckas som ett protokollfel och inte som ett läsbart meddelande. ESP autentiserar inte det yttre huvudet, därför fungerar ESP med NAT-genomgång medan AH bakom NAT inte gör det. En tunnel vars båda sidor står bakom vanliga routrar är just den plats där detta dyker upp först. Den första frågan är därför inte vilket protokoll som är starkast, utan om det står en översättare mellan sidorna.

Om så är fallet faller AH bort, och samtalet flyttar till ESP och dess algoritmval. Det är en begränsning och inte en preferens, därför hör den hemma högst upp i beslutet och inte i slutet.

Läget multiplicerar frågan

ESP i transportläge skyddar nyttolasten i det övre lagret och låter IP-huvudet vara; i tunnelläge kapslar den in hela det inre paketet, inklusive det inre IP-huvudet, och skyddar det. AH har samma två lägen, så AH eller ESP är i själva verket fyra kombinationer innan någon algoritm väljs.

ESP-algoritmer i kombinerat läge avgör sedan integriteten utan ett andra protokoll. AES-GCM och ChaCha20-Poly1305 autentiserar och krypterar i en enda konstruktion, så AH ovanpå köper ingenting men kostar ett extra huvud och ännu en förhandling. Arkitekturen tillåter AH och ESP tillsammans, och den praktiska frågan är om din gateway och din utgåva stöder kombinationen och om någon kan underhålla den efteråt.

Den ärliga ersättningen för bara AH

ESP-varianten med bara integritet behåller algoritmen och släpper krypteringspåståendet i stället för att låtsas, och den klarar NAT. Om en äldre design använde AH eftersom den behövde autentisering utan konfidentialitet, är den varianten den direkta översättningen, inte en krypterad tunnel med en lapp på.

Att se ESP i ett förslag är inte heller bevis på kryptering. Läs krypteringsalgoritmen: en NULL-post betyder bara integritet, och en post i kombinerat läge betyder båda.

Avgör med tre frågor

Fråga om konfidentialitet krävs, om det finns en översättare på vägen och vilka huvudfält som måste autentiseras. De tre svaren pekar på ett protokoll och ett läge, och att skriva ned dem tar kortare tid än att läsa RFC-erna igen senare.

Verifiera sedan det som accepterades och inte det som föreslogs. ip xfrm state visar protokoll, läge och algoritmer för den installerade associationen, och en avvikelse installerar ingenting, vilket är ett renare misslyckande än en tunnel som kommer upp utan det skydd du avsåg.

Håll autentiseringsfel, selektortäckning och routingfel åtskilda från detta val. De ger olika symtom, och att skylla på protokollet för ett selektorproblem är ett pålitligt sätt att lägga en dag på att byta hash utan skäl.