AH czy ESP? Zdecyduj według tego, co pakiet musi chronić
AH uwierzytelnia większą część pakietu i niczego nie szyfruje; ESP może szyfrować i uwierzytelniać. Wybierz według pól, które trzeba chronić, a potem uzgodnij tryb.
Dwie propozycje IPsec mogą wskazać ten sam algorytm integralności oparty na SHA, a mimo to żądać różnych protokołów ochrony; AH i ESP to nie dwa zapisy jednego ustawienia uwierzytelniania. Przeczytaj najpierw protokół, potem jego algorytmy, potem jego tryb, a większość niejasności znika. AH uwierzytelnia pakiet, w tym pola nagłówka IP, które pozostają niezmienione w drodze, natomiast ESP uwierzytelnia i szyfruje to, co enkapsuluje, a nagłówek zewnętrzny zostawia w spokoju. Ta różnica rozstrzyga o więcej wdrożeniach niż jakakolwiek nazwa skrótu.
Co AH obejmuje, a ESP nie
AH zapewnia integralność, uwierzytelnianie pochodzenia danych i zdefiniowaną przez siebie usługę ochrony przed powtórzeniem, i żadnej poufności. Jego zakres obejmuje dane wyższej warstwy oraz pola nagłówka IP, które jego reguły uznają za niezmienne, czyli dokładnie tę część, którą ESP w trybie transportowym zostawia poza ochroną. Gdy wymaganie mówi, że uwierzytelniony musi być sam nagłówek IP, AH jest protokołem, który na to odpowiada.
Ten zakres jest też powodem, dla którego AH jest w praktyce kruchy. Pola zmienne, takie jak TTL, suma kontrolna nagłówka i niektóre opcje, nie mogą być uwierzytelnione, bo routery mogą je przepisywać, więc protokół zeruje je przed obliczeniem sumy. Wszystko, co przepisuje adresy, psuje więc obliczenie, a nie tylko politykę.
NAT zamienia wybór w ograniczenie
Tłumaczenie adresów przepisuje źródło lub cel w nagłówku IP, który AH właśnie uwierzytelnił, więc kontrola integralności zawodzi na drugim końcu, i zawodzi jako błąd protokołu, a nie jako czytelny komunikat. ESP nie uwierzytelnia nagłówka zewnętrznego, dlatego ESP z przechodzeniem przez NAT działa, a AH za NAT nie. Tunel, którego obie strony stoją za zwykłymi routerami, jest właśnie miejscem, w którym to pojawia się najpierw. Pierwsze pytanie nie brzmi więc, który protokół jest silniejszy, ale czy między stronami jest translator.
Jeśli jest, AH wypada, a rozmowa przechodzi do ESP i jego wyboru algorytmów. To ograniczenie, a nie preferencja, dlatego należy na początek decyzji, a nie na jej koniec.
Tryb mnoży pytanie
ESP w trybie transportowym chroni ładunek wyższej warstwy i nie rusza nagłówka IP; w trybie tunelowym enkapsuluje cały pakiet wewnętrzny, wraz z wewnętrznym nagłówkiem IP, i chroni go. AH ma te same dwa tryby, więc AH albo ESP to w rzeczywistości cztery kombinacje, zanim wybierze się jakikolwiek algorytm.
Algorytmy ESP w trybie łączonym rozstrzygają potem integralność bez drugiego protokołu. AES-GCM i ChaCha20-Poly1305 uwierzytelniają i szyfrują w jednej konstrukcji, więc dodanie AH na wierzchu nic nie kupuje, ale kosztuje kolejny nagłówek i kolejne negocjacje. Architektura dopuszcza AH i ESP razem, a praktyczne pytanie brzmi czy twoja brama i twoje wydanie obsługują tę kombinację i czy ktoś będzie mógł ją później utrzymywać.
Uczciwy zamiennik dla samego AH
Wariant ESP tylko z integralnością zachowuje algorytm i porzuca twierdzenie o szyfrowaniu zamiast je udawać, i przechodzi przez NAT. Jeśli stary projekt używał AH, bo potrzebował uwierzytelniania bez poufności, ten wariant jest tłumaczeniem bezpośrednim, a nie zaszyfrowanym tunelem z dopisaną notatką.
Widok ESP w propozycji też nie jest dowodem szyfrowania. Przeczytaj algorytm szyfrowania: wpis NULL oznacza tylko integralność, a wpis trybu łączonego oznacza oba.
Zdecyduj w trzech pytaniach
Zapytaj, czy poufność jest wymagana, czy na ścieżce jest translator i które pola nagłówka muszą być uwierzytelnione. Te trzy odpowiedzi wskazują jeden protokół i jeden tryb, a zapisanie ich zajmuje mniej czasu niż późniejsze ponowne czytanie RFC.
Potem sprawdź to, co przyjęto, a nie to, co zaproponowano. ip xfrm state pokazuje protokół, tryb i algorytmy zainstalowanej asocjacji, a niezgodność nie instaluje niczego, co jest czystszym niepowodzeniem niż tunel, który wstaje bez zamierzonej ochrony.
Trzymaj niepowodzenia uwierzytelniania, pokrycie selektorów i błędy routingu z dala od tego wyboru. Dają różne objawy, a obwinianie protokołu za problem z selektorem to pewny sposób na spędzenie dnia na zmianie skrótów bez powodu.