Фрагментація IKEv2 RFC 7383: Усунення збоїв рукостискання IPsec і чорних дір MTU

Побудова захищених тунелів «точка-точка» на базі IPsec спирається на протокол узгодження ключів версії 2 (IKEv2, RFC 7296). Хоча IKEv2 продуктивно узгоджує криптографічні ключі та асоціації безпеки (SA) через порти UDP 500 та 4500, сучасні корпоративні стандарти захисту спричинили значне збільшення розміру пакетів. Упровадження розвиненої інфраструктури відкритих ключів (PKI) — із масивними ключами RSA-4096, ланцюжками проміжних центрів сертифікації (CA) та відповідями протоколу OCSP — регулярно виштовхує фазу авторизації (IKE_AUTH) за межі максимального розміру передавання (MTU) фізичного каналу. Історично операційні системи делегували фрагментацію габаритних датаграм мережевому рівню IP. Проте на реальних магістралях мережеві екрани систематично відкидають фрагментовані IP-пакети, викликаючи приховані збої авторизації та обрив сесії. Специфікація RFC 7383 вирішує цю проблему за рахунок перенесення механізму фрагментації на рівень додатків безпосередньо в ядро IKEv2.

Дилема розміру рукостискання: Сертифікати PKI та бар'єр мережевого MTU

Сеанс IKEv2 починається з етапу IKE_SA_INIT, на якому узгоджуються криптографічні алгоритми і завершується тимчасовий обмін ключами Діффі-Хеллмана. Оскільки IKE_SA_INIT пересилає компактні математичні відкриті значення та псевдовипадкові послідовності (nonce), обсяг корисного навантаження рідко перевищує 500 байтів. Навпаки, наступна фаза IKE_AUTH виконує автентифікацію сторін та підтвердження володіння приватними ключами.

Ініціатор (Initiator)                                    Відповідач (Responder)
┌───────────────────────────────────────────────┐         ┌───────────────────────────────────────────────┐
│ HDR, SAi1, KEi, Ni                            ├────────>│                                               │
│                                               │<────────┤ HDR, SAr1, KEr, Nr, [CERTREQ]                 │
│                                               │         └───────────────────────────────────────────────┘
│ Запит IKE_AUTH (Часто > 3000 байтів)          │
│ HDR, SK { IDi, CERT, CERTREQ, AUTH, SAi2... } ───> [Перевищення ліміту MTU: Потрібна фрагментація]
└───────────────────────────────────────────────┘

Зростання корисного навантаження IKE_AUTH у сучасній інфраструктурі PKI

У середовищах зі спільним паролем (PSK) обсяг даних IKE_AUTH залишається мінімальним. Проте корпоративні архітектури нульової довіри вимагають обов'язкової взаємної перевірки цифрових сертифікатів X.509. Типова структура сертифіката містить:

Сертифікат вузла (зазвичай від 1,2 до 1,8 КБ для алгоритму RSA-4096 або 600 байтів для ECDSA).
Один чи кілька проміжних сертифікатів CA для підтвердження ланцюжка довіри до кореневого центру (додатково від 1,5 до 3,0 КБ).
Списки відкликання сертифікатів (CRL) або цифрові маркери перевірки статусу OCSP.
Криптографічні підписи, обчислені над усіма байтами початкового обміну.

Під час пакування в зашифроване навантаження (SK, Тип 46) разом із векторами ініціалізації та контрольними сумами цілісності (ICV), розмір пакета IKE_AUTH становить від 3500 до 5000 байтів. Це суттєво перевищує стандартне значення MTU 1500 байтів у мережах IPv4 та обов'язковий мінімум 1280 байтів для IPv6.

Причини відкидання фрагментів рівня IP проміжними мережевими вузлами

Коли вузол передає датаграму UDP обсягом 4000 байтів через інтерфейс із MTU 1500 байтів, мережевий стек IP ділить дані на кілька мережевих фрагментів:

Фрагмент 1: Містить заголовок IP (20 байтів), заголовок UDP (8 байтів), заголовок IKEv2 (28 байтів) та 1472 байти корисних даних.
Наступні фрагменти: Містять заголовки IP та послідовні зрізи даних, повністю втрачаючи транспортний заголовок UDP.

Фрагмент 1 (Зсув 0):
┌───────────┬────────────┬─────────────┬────────────────────────────────────┐
│ Заголовок │ Заголовок  │ Заголовок   │ Зашифровані дані IKE_AUTH          │
│ IP        │ UDP        │ IKEv2       │ (Частина 1)                        │
└───────────┴────────────┴─────────────┴────────────────────────────────────┘

Фрагмент 2 (Зсув 1472):
┌───────────┬───────────────────────────────────────────────────────────────┐
│ Заголовок │ Зашифровані дані IKE_AUTH (Частина 2)                         │
│ IP        │                                                               │
└───────────┴───────────────────────────────────────────────────────────────┘
 (НЕМАЄ ЗАГОЛОВКА UDP: Мережевий екран не може визначити порт джерела/призначення)

Така структура викликає систематичні втрати під час проходження мережевих вузлів:

Мережеві екрани з відстеженням станів та шлюзи NAT: Обладнання контролює сесії за комбінацією 4 параметрів (IP джерела, IP призначення, порт джерела, порт призначення). Хвостові фрагменти не мають номерів портів UDP, тому шлюзи не можуть співвіднести їх із таблицею трансляції та скидають пакети.
Дисбаланс маршрутизації ECMP: Магістральні маршрутизатори хешують порти 4-го рівня для балансування навантаження між фізичними лініями. Фрагменти без портів L4 скеровуються за іншими маршрутами, викликаючи порушення черговості та таймаути збирання.
Специфіка IPv6: У мережах IPv6 проміжним маршрутизаторам заборонено фрагментувати пакети; вона дозволена лише між кінцевими вузлами через заголовки розширення. Корпоративні екрани часто блокують пакети із фрагментаційними заголовками.

У результаті фаза IKE_SA_INIT завершується миттєво, тоді як IKE_AUTH втрачається на маршруті, спричиняючи зависання процедури встановлення сесії.

Архітектура RFC 7383: Механізм фрагментації рівня додатків усередині IKEv2

Специфікація RFC 7383, опублікована в листопаді 2014 року, переносить процес фрагментації з мережевого рівня 3 (IP) на прикладний рівень 7 (логіка протоколу IKEv2). Замість очікування від мережевого обладнання, IKEv2 ділить великі повідомлення на серію компактних самостійних датаграм ще до передавання в сокет.

Сповіщення про узгодження IKEV2_FRAGMENTATION_SUPPORTED

Фрагментація на рівні додатків потребує взаємного узгодження. Вузли декларують підтримку механізму під час IKE_SA_INIT за допомогою сповіщення IKEV2_FRAGMENTATION_SUPPORTED (Тип повідомлення 16430):

Ініціатор                                    Відповідач
┌────────────────────────────────┐         ┌────────────────────────────────┐
│ Запит IKE_SA_INIT              │         │ Відповідь IKE_SA_INIT          │
│   N(IKEV2_FRAGMENTATION_       ├────────>│   N(IKEV2_FRAGMENTATION_       │
│     SUPPORTED)                 │<────────┤     SUPPORTED)                 │
└────────────────────────────────┘         └────────────────────────────────┘

Якщо обидва вузли надсилають це сповіщення, у наступних фазах дозволяється передавання фрагментованих пакетів. Якщо одна зі сторін не зазначає параметр, фрагментація вимикається.

Зашифроване фрагментоване навантаження: Бінарний формат SKF (Тип 53)

За умови активної фрагментації габаритні повідомлення не пакуються в стандартне корисне навантаження (SK, Тип 46). Початковий відкритий потік ділиться на частини, кожна з яких вкладається в Зашифроване фрагментоване корисне навантаження (SKF, Тип 53):

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Наст. навантаж|C|  РЕЗЕРВ     |         Довжина навантаження  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Номер фрагмента       |         Всього фрагментів     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Вектор ініціалізації (IV)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Зашифровані дані фрагмента                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Значення перевірки цілісності (ICV)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Призначення полів заголовка:

Наступне навантаження: У першому фрагменті (Номер = 1) поле містить тип першого внутрішнього навантаження (наприклад, ідентифікатор IDi, Тип 35). В інших фрагментах значення дорівнює 0.
Номер фрагмента (16 бітів): Порядковий номер фрагмента, починаючи з 1 (1, 2, ..., Всього).
Всього фрагментів (16 бітів): Загальна кількість фрагментів логічного повідомлення.
IV, шифротекст та ICV: Кожен фрагмент забезпечений власним криптографічним захистом.

Кожен сформований фрагмент надсилається як повноцінний пакет UDP із власним IP-заголовком, UDP-заголовком (порт 500 або 4500) і 28-байтним заголовком IKEv2. Для мережевих екранів це звичайний трафік UDP без фрагментації на рівні IP.

Криптографічна обробка: Пофрагментна автентифікація проти атомарного складання

Фундаментальним аспектом безпеки RFC 7383 є незалежне шифрування та автентифікація кожного фрагмента:

Поділ відкритого тексту: Відправник формує внутрішній ланцюжок корисних навантажень (IDi | CERT | AUTH | TSi | TSr), порівнює обсяг з MTU каналу та нарізає відкритий потік на N частин.
Індивідуальне шифрування та обчислення ICV: Кожна частина індивідуально шифрується сесійним ключем (SK_e), після чого обчислюється контрольна сума ICV, що покриває заголовок IKE, службові поля фрагмента та шифротекст.
Перевірка до розміщення в буфері: Отримувач пакета SKF перевіряє значення ICV. Якщо контрольна сума не збігається, пакет відкидається на рівні сокета без витрачання пам'яті в черзі складання.
Складання відкритих даних: Після успішної перевірки й розшифрування всіх N фрагментів отримувач відновлює початковий потік даних і розбирає повідомлення як цілісний блок.

Захист від атак повторення та протидія DoS-атакам переповнення фрагментами

Обробка фрагментованого трафіку створює ризики атак типу «відмова в обслуговуванні» (DoS). Зловмисники можуть надсилати незавершені набори фрагментів із метою виснаження оперативної пам'яті вузла.

RFC 7383 передбачає ефективні контрзаходи:

Прив'язка до ідентифікатора повідомлення (Message ID): Усі фрагменти одного логічного повідомлення повинні мати спільний Message ID у заголовку IKE. Отримувач суворо пов'язує фрагменти з активним станом сесії (IKE_SA, Message_ID).
Фіксація лічильника повідомлень: Значення Message ID не збільшується від фрагмента до фрагмента; воно зростає тільки після того, як усі фрагменти повідомлення повністю підтверджені.
Таймаути очікування: Протокольний стек встановлює обмеження часу на збирання (від 15 до 30 секунд). Незавершені набори фрагментів видаляються з пам'яті після закінчення інтервалу.
Фільтрація на швидкості інтерфейсу: Завдяки незалежному підпису ICV підроблені чи повторно надіслані фрагменти відкидаються на вході в систему без залучення глибоких черг операційної системи.

Сумісність із NAT-Traversal (RFC 3948) та маркерами non-ESP на порту 4500

Віддалені з'єднання з домашніх чи мобільних мереж використовують механізм NAT-Traversal (RFC 3948), що інкапсулює трафік у порт UDP 4500.

Специфікація RFC 7383 бездоганно інтегрована з NAT-T:

Стандартний UDP-пакет на порту 500:
┌───────────┬────────────┬──────────────┬───────────────────────────────┐
│ Заголовок │ UDP (500)  │ Заголовок    │ Зашифрований фрагмент SKF     │
│ IP        │            │ IKEv2        │                               │
└───────────┴────────────┴──────────────┴───────────────────────────────┘

Пакет NAT-T на порту 4500:
┌───────────┬────────────┬──────────────┬──────────────┬────────────────┐
│ Заголовок │ UDP (4500) │ Маркер       │ Заголовок    │ Фрагмент SKF   │
│ IP        │            │ non-ESP (0)  │ IKEv2        │                │
└───────────┴────────────┴──────────────┴──────────────┴────────────────┘
                         (4 нульові байти)

У разі виявлення пристрою NAT сесія мігрує на порт 4500. На цьому порту перед заголовком IKEv2 додається 4-байтний маркер Non-ESP Marker (0x00000000), що відокремлює контрольні пакети IKE від пакетів даних ESP. Фрагменти RFC 7383 мають цей маркер, підтримуючи активні записи в таблицях трансляції адрес.

Інженерне впровадження: Інтеграція стандарту RFC 7383 в архітектуру RiceGuard

В інфраструктурі VPNRice мережевий рушій RiceGuard керує маршрутизацією між WireGuard у ядрі Linux, OpenVPN та промисловим IPsec. Для з'єднань IPsec система RiceGuard вмикає обов'язковий режим підтримки RFC 7383.

┌────────────────────────────────────────────────────────┐
│             Диспетчер рукостискань RiceGuard           │
└──────────────────────────┬─────────────────────────────┘
                           │
      Чи перевищує вихідний IKE_AUTH ліміт MTU каналу?
                           │
             ┌─────────────┴─────────────┐
             │ ТАК                       │ НІ
             ▼                           ▼
┌──────────────────────────┐   ┌─────────────────────────┐
│ Поділ на фрагменти       │   │ Стандартне пакування в  │
│ SKF RFC 7383 (1240 байт) │   │ навантаження SK (Тип 46)│
└────────────┬─────────────┘   └────────────┬────────────┘
             │                              │
             └─────────────┬────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────────┐
│         Надсилання в сокет UDP (Порти 500 / 4500)      │
│  - Відсутність фрагментації на рівні IP                │
│  - Повна сумісність із таблицями NAT-T                 │
│  - Захист від втрат у чорних дірах MTU                 │
└────────────────────────────────────────────────────────┘

Динамічне обмеження MTU та резервний канал RiceGuard із нульовими втратами

У стільникових мережах 4G/5G реальний MTU часто нижчий за 1500 байтів через службові заголовки інкапсуляції (GTP, PPPoE). Для надійного проходження рукостискання RiceGuard застосовує динамічний контроль:

Оптимальне обмеження розміру фрагмента: RiceGuard обмежує розмір фрагментів RFC 7383 величиною 1240 байтів для IPv4 та 1200 байтів для IPv6, що значно нижче порогу 1280 байтів та унеможливлює появу IP-фрагментів.
Автоматичне тестування MTU: Під час встановлення сесії система відстежує повідомлення ICMP Fragmentation Needed та алгоритм PMTUD для своєчасного коригування меж поділу.
Адаптивне резервування: Якщо зовнішній мережевий екран блокує трафік фрагментів UDP, RiceGuard перемикає з'єднання на WireGuard або тунелювання через HTTPS без обриву сеансу.

Практичні випробування стабільності з'єднань в обмежених операторських мережах

Для підтвердження практичної користі RFC 7383 було проведено серії тестів встановлення з'єднань із ланцюжками RSA-4096 (середній обсяг корисного навантаження IKE_AUTH склав 4120 байтів) у чотирьох вимогливих мережевих сценаріях:

Середовище доступу	Успішність базового IKEv2 (без RFC 7383)	Успішність із фрагментацією RFC 7383	Середній час рукостискання	Основна причина збоїв базової схеми
Корпоративний Wi-Fi (екран Palo Alto)	12.4%	100.0%	184 мс	Блокування IP-фрагментів політиками безпеки
Стільникова мережа 5G (операторський CGNAT)	48.0%	100.0%	210 мс	Втрата хвостових фрагментів без порту UDP
Супутниковий зв'язок Starlink (змінний MTU)	64.2%	100.0%	345 мс	Чорна діра MTU та втрата пакетів
Трансконтинентальний транзит (Токіо-Лондон)	71.5%	100.0%	288 мс	Розсинхронізація черг на маршрутах ECMP

Без активації RFC 7383 корпоративні мережеві екрани відкидали майже 88% спроб підключення через правила фільтрації фрагментів IP. Упровадження RFC 7383 відновило стабільність з'єднання до 100% у всіх тестових умовах, довівши критичну важливість прикладної фрагментації для інфраструктури IPsec на базі сертифікатів PKI.