AH или ESP? Решението зависи от това какво трябва да защити пакетът

Две предложения за IPsec могат да посочат един и същ алгоритъм за цялост, базиран на SHA, и въпреки това да изискват различни протоколи за защита; AH и ESP не са два правописа на една настройка за удостоверяване. Прочетете първо протокола, после алгоритмите му, после режима му и по-голямата част от неяснотата изчезва. AH удостоверява пакета, включително онези полета на IP заглавката, които остават непроменени по пътя, докато ESP удостоверява и криптира това, което инкапсулира, и оставя външната заглавка недокосната. Тази разлика решава повече внедрявания, отколкото което и да е име на хеш.

Какво покрива AH, а ESP не

AH осигурява цялост, удостоверяване на произхода на данните и дефинираната от него услуга срещу повторение, и никаква поверителност. Обхватът му включва данните от горния слой плюс полетата на IP заглавката, които правилата му третират като неизменни, точно частта, която ESP в транспортен режим оставя навън. Когато изискване казва, че самата IP заглавка трябва да бъде удостоверена, AH е протоколът, който отговаря.

Този обхват е и причината AH да е чуплив на практика. Променливите полета като TTL, контролната сума на заглавката и някои опции не могат да бъдат удостоверени, защото рутерите може да ги пренапишат, затова протоколът ги нулира преди изчисляването на проверката. Следователно всичко, което пренаписва адреси, чупи изчислението, а не само политиката.

NAT превръща избора в ограничение

Транслацията на адреси пренаписва източника или дестинацията в IP заглавката, която AH току-що е удостоверил, затова проверката за цялост се проваля в далечния край и се проваля като протоколна грешка, а не като съобщение, което може да се прочете. ESP не удостоверява външната заглавка и затова ESP с обхождане на NAT работи, а AH зад NAT не. Тунел, чиито страни стоят зад обикновени рутери, е точно мястото, където това се появява първо. Затова първият въпрос не е кой протокол е по-силен, а дали между страните има транслатор.

Ако има, AH отпада и разговорът се мести към ESP и избора на алгоритми. Това е ограничение, а не предпочитание, и затова мястото му е в началото на решението, а не в края.

Режимът умножава въпроса

ESP в транспортен режим защитава полезния товар на горния слой и оставя IP заглавката на мира; в тунелен режим инкапсулира целия вътрешен пакет, включително вътрешната IP заглавка, и го защитава. AH има същите два режима, така че AH или ESP всъщност са четири комбинации преди избора на който и да е алгоритъм.

Алгоритмите на ESP в комбиниран режим после решават цялостта без втори протокол. AES-GCM и ChaCha20-Poly1305 удостоверяват и криптират в една конструкция, затова добавянето на AH отгоре не купува нищо, но струва още една заглавка и още едно договаряне. Архитектурата позволява AH и ESP заедно и практическият въпрос е поддържат ли вашият шлюз и издание тази комбинация и дали някой може да я поддържа после.

Честната замяна на AH-only

Вариантът на ESP само с цялост запазва алгоритъма и се отказва от претенцията за криптиране, вместо да я имитира, и преминава през NAT. Ако наследен дизайн е използвал AH, защото е трябвало удостоверяване без поверителност, този вариант е директният превод, а не криптиран тунел с прикачена бележка.

Виждането на ESP в предложение също не е доказателство за криптиране. Прочетете алгоритъма за криптиране: запис NULL означава само цялост, а запис с комбиниран режим означава и двете.

Решете с три въпроса

Попитайте дали е нужна поверителност, дали на пътя има транслатор и кои полета на заглавката трябва да се удостоверят. Тези три отговора сочат един протокол и един режим и записването им отнема по-малко време, отколкото повторното четене на RFC по-късно.

После проверете какво е прието, а не какво е предложено. ip xfrm state показва протокола, режима и алгоритмите на инсталираната асоциация и при несъответствие не се инсталира нищо, което е по-чист провал от тунел, който се вдига без предвидената защита.

Дръжте отказите при удостоверяване, покритието на селекторите и грешките в маршрутизацията отделно от този избор. Те дават различни симптоми и обвиняването на протокола за проблем със селектор е надежден начин да прекарате ден в смяна на хешове без причина.