AH või ESP? Otsustage selle järgi, mida pakett peab kaitsma

Kaks IPsec-i ettepanekut võivad nimetada sama SHA-põhist terviklusalgoritmi ja nõuda siiski erinevaid kaitseprotokolle; AH ja ESP ei ole ühe autentimisseade kaks kirjaviisi. Lugege esmalt protokolli, seejärel selle algoritme, seejärel selle režiimi, ja suurem osa ebaselgusest kaob. AH autendib paketi, sealhulgas need IP-päise väljad, mis jäävad teel muutumatuks, samas kui ESP autendib ja krüpteerib selle, mida ta kapseldab, ja jätab välise päise puutumata. See erinevus otsustab rohkem juurutusi kui ükski räsi nimi.

Mida AH katab ja ESP mitte

AH annab tervikluse, andmete päritolu autentimise ja tema enda määratletud korduskoopia tõrje teenuse ning üldse mitte konfidentsiaalsust. Selle katvus hõlmab ülemise kihi andmeid ja neid IP-päise välju, mida tema reeglid peavad muutumatuteks, täpselt see osa, mille ESP transpordirežiimis välja jätab. Kui nõue ütleb, et autentida tuleb IP-päis ise, on AH see protokoll, mis sellele vastab.

See katvus on ka põhjus, miks AH on praktikas habras. Muutuvad väljad nagu TTL, päise kontrollsumma ja mõned valikud ei ole autenditavad, sest ruuterid võivad neid ümber kirjutada, seega nullib protokoll need enne kontrolli arvutamist. Kõik, mis kirjutab aadresse ümber, rikub seega arvutuse, mitte ainult poliitika.

NAT muudab valiku piiranguks

Aadressitõlge kirjutab ümber IP-päises oleva allika või sihtkoha, mille AH just autentis, seega tervikluse kontroll ebaõnnestub kaugemas otsas ja ebaõnnestub protokolliveana, mitte loetava teatisena. ESP ei autendi välist päist, mistõttu ESP koos NAT-i läbimisega töötab ja AH NAT-i taga mitte. Tunnel, mille mõlemad pooled seisavad tavaliste ruuterite taga, on täpselt see koht, kus see esimesena ilmneb. Seega ei ole esimene küsimus, milline protokoll on tugevam, vaid kas poolte vahel on tõlkija.

Kui on, jääb AH välja ja vestlus liigub ESP ning selle algoritmivaliku juurde. See on piirang, mitte eelistus, ja seetõttu kuulub see otsuse algusesse, mitte lõppu.

Režiim korrutab küsimuse

ESP transpordirežiimis kaitseb ülemise kihi kasulikku koormust ja jätab IP-päise rahule; tunnelirežiimis kapseldab kogu sisemise paketi, sealhulgas sisemise IP-päise, ja kaitseb seda. AH-l on samad kaks režiimi, seega AH või ESP on tegelikult neli kombinatsiooni enne mis tahes algoritmi valimist.

Kombineeritud režiimiga ESP algoritmid lahendavad seejärel tervikluse ilma teise protokollita. AES-GCM ja ChaCha20-Poly1305 autendivad ja krüpteerivad ühes konstruktsioonis, seega AH lisamine peale ei osta midagi, kuid maksab veel ühe päise ja veel ühe läbirääkimise. Arhitektuur lubab AH-d ja ESP-d koos ning praktiline küsimus on kas teie lüüs ja väljalase toetavad seda kombinatsiooni ja kas keegi suudab seda hiljem hooldada.

Aus asendus ainult AH-le

Ainult terviklusega ESP variant hoiab algoritmi ja loobub krüpteerimisväitest selle teesklemise asemel ning läbib NAT-i. Kui pärandkujundus kasutas AH-d, sest vajati autentimist ilma konfidentsiaalsuseta, on see variant otsene tõlge, mitte krüpteeritud tunnel koos lisatud märkusega.

ESP nägemine ettepanekus ei ole samuti krüpteerimise tõestus. Lugege krüpteerimisalgoritmi: NULL-i kirje tähendab ainult terviklust ja kombineeritud režiimi kirje tähendab mõlemat.

Otsustage kolme küsimusega

Küsige, kas konfidentsiaalsus on vajalik, kas teel on tõlkija ja milliseid päisevälju tuleb autentida. Need kolm vastust osutavad ühele protokollile ja ühele režiimile ning nende kirjapanek võtab vähem aega kui RFC-de hilisem uuesti lugemine.

Seejärel kontrollige, mida võeti vastu, mitte mida pakuti. ip xfrm state näitab paigaldatud assotsiatsiooni protokolli, režiimi ja algoritme ning lahknevus ei paigalda midagi, mis on puhtam ebaõnnestumine kui tunnel, mis tõuseb ilma kavatsetud kaitseta.

Hoidke autentimistõrked, selektorite katvus ja marsruutimisvead sellest valikust eraldi. Need tekitavad erinevaid sümptomeid ning protokolli süüdistamine selektori probleemis on usaldusväärne viis veeta päev räsisid põhjuseta vahetades.