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

Варіант ESP лише з цілісністю зберігає алгоритм і відмовляється від заяви про шифрування замість того, щоб її імітувати, і проходить крізь NAT. Якщо стара схема використовувала AH, бо потрібна була автентифікація без конфіденційності, цей варіант і є прямим перекладом, а не шифрований тунель із припискою.

Бачити ESP у пропозиції теж не доказ шифрування. Читайте алгоритм шифрування: запис NULL означає лише цілісність, а запис комбінованого режиму означає обидва.

Вирішіть трьома питаннями

Запитайте, чи потрібна конфіденційність, чи є на шляху транслятор і які поля заголовка треба автентифікувати. Ці три відповіді вказують на один протокол і один режим, і записати їх швидше, ніж потім перечитувати RFC.

Потім перевірте те, що прийнято, а не те, що запропоновано. ip xfrm state показує протокол, режим і алгоритми встановленої асоціації, а за невідповідності не встановлюється нічого, що є чистішим збоєм, ніж тунель, який піднімається без потрібного захисту.

Тримайте збої автентифікації, охоплення селекторів і помилки маршрутизації окремо від цього вибору. Вони дають різні симптоми, і звинувачувати протокол у проблемі селектора це певний спосіб витратити день на заміну хешів без причини.