AH ou ESP? Decida polo que o paquete debe protexer

Dúas propostas IPsec poden nomear o mesmo algoritmo de integridade baseado en SHA e aínda así pedir protocolos de protección distintos; AH e ESP non son dúas grafías dun mesmo axuste de autenticación. Lea primeiro o protocolo, logo os seus algoritmos, logo o seu modo, e a maior parte da ambigüidade desaparece. AH autentica o paquete, incluídos os campos da cabeceira IP que permanecen inalterados na viaxe, mentres que ESP autentica e cifra o que encapsula e deixa a cabeceira exterior tranquila. Esa diferenza decide máis despregamentos que calquera nome de hash.

Que cobre AH que ESP non

AH achega integridade, autenticación da orixe dos datos e o servizo anti-repetición que define, e ningunha confidencialidade. A súa cobertura inclúe os datos da capa superior e os campos da cabeceira IP que as súas regras tratan como immutables, xusto a parte que ESP en modo transporte deixa fóra. Cando un requisito di que debe autenticarse a propia cabeceira IP, AH é o protocolo que responde.

Esa cobertura é tamén a razón de que AH sexa fráxil sobre o terreo. Os campos mutables como o TTL, a suma de verificación da cabeceira e algunhas opcións non se poden autenticar porque os encamiñadores poden reescribilos, así que o protocolo pona a cero antes de calcular a verificación. Por tanto, calquera cousa que reescriba enderezos rompe o cálculo, non só a política.

NAT converte a escolla nunha restrición

A tradución de enderezos reescribe a orixe ou o destino na cabeceira IP que AH acaba de autenticar, así que a verificación de integridade falla no extremo afastado, e falla como erro de protocolo e non como unha mensaxe que se poida ler. ESP non autentica a cabeceira exterior, e por iso ESP con travesía de NAT funciona e AH detrás de NAT non. Un túnel cuxos dous extremos están detrás de encamiñadores correntes é xusto onde isto aparece primeiro. Por iso a primeira pregunta non é que protocolo é máis forte, senón se hai un tradutor entre os extremos.

Se o hai, AH queda fóra e a conversa pasa a ESP e ás súas opcións de algoritmo. É unha restrición e non unha preferencia, e por iso vai ao principio da decisión e non ao final.

O modo multiplica a pregunta

ESP en modo transporte protexe a carga útil da capa superior e deixa a cabeceira IP en paz; en modo túnel encapsula todo o paquete interior, incluída a cabeceira IP interior, e protéxeo. AH ten os mesmos dous modos, así que AH ou ESP son en realidade catro combinacións antes de escoller calquera algoritmo.

Os algoritmos ESP de modo combinado resolven despois a integridade sen un segundo protocolo. AES-GCM e ChaCha20-Poly1305 autentican e cifran nunha soa construción, así que engadir AH por riba non compra nada pero custa outra cabeceira e outra negociación. A arquitectura permite AH e ESP xuntos, e a pregunta práctica é se a súa pasarela e a súa versión admiten a combinación e se alguén poderá mantela despois.

O substituto honesto para só AH

A variante ESP de só integridade conserva o algoritmo e deixa caer a pretensión de cifrado en lugar de falsificala, e sobrevive a NAT. Se un deseño heredado usaba AH porque necesitaba autenticación sen confidencialidade, esa variante é a tradución directa, non un túnel cifrado cunha nota axunta.

Ver ESP nunha proposta tampouco é proba de cifrado. Lea o algoritmo de cifrado: unha entrada NULL significa só integridade, e unha entrada de modo combinado significa ambas.

Decida en tres preguntas

Pregunte se se require confidencialidade, se hai un tradutor no camiño e que campos da cabeceira deben autenticarse. Esas tres respostas apuntan a un protocolo e un modo, e escribilas leva menos tempo que volver ler os RFC máis adiante.

Logo verifique o aceptado e non o proposto. ip xfrm state mostra o protocolo, o modo e os algoritmos da asociación instalada, e unha discrepancia non instala nada, o que é un fallo máis limpo que un túnel que sobe sen a protección que pretendía.

Manteña os fallos de autenticación, a cobertura dos selectores e os fallos de encamiñamento aparte desta escolla. Producen síntomas distintos, e culpar o protocolo dun problema de selector é unha forma segura de pasar un día cambiando hashes sen motivo.