IKEv2 Seamless Rekeying RFC 7296: Make-Before-Break та зміна ключів SA

Високопродуктивні зашифровані тунелі VPN передають гігабіти конфіденційного корпоративного трафіку через публічні магістральні мережі. В архітектурі безпеки IPsec (RFC 4301) цілісність та конфіденційність даних забезпечуються односпрямованими асоціаціями безпеки (Security Association, SA). Кожна SA визначає симетричні ключі шифрування, криптографічні алгоритми та лічильники номерів послідовності, узгоджені протоколом IKEv2 (RFC 7296). Проте криптографічні ключі не можуть використовуватись нескінченно. Без контрольованого періодичного оновлення ключів деградація шифрів та переповнення лічильників порушують безпеку або призводять до розриву зв'язку.

У ранніх реалізаціях IPsec зміна ключів спричиняла відчутні перебої в роботі мережі. Застарілий підхід «Break-Before-Make» видаляв активну SA до підтвердження готовності нової. На швидкісних магістралях навіть 50 мілісекунд простою спричиняють втрату тисяч пакетів, руйнування вікна перевантаження TCP та збої у передачі голосу чи відеопотоків. Розділ 2.8 стандарту RFC 7296 визначає концепцію «Make-Before-Break» — асинхронний автомат станів, що дозволяє старій та новій SA безперешкодно співіснувати під час ротації.

Make-Before-Break (Плавний перехід за RFC 7296):
Стара вхідна SA    ══════════════════════════════[ Вікно скидання трафіку ]════> [ Видалено ]
Нова вхідна SA     ─────────────[ Встановлено ]════════════════════════════════════════>
Вихідний трафік    ─────────────[ Старий SPI ]─> ───[ Перемикання на новий SPI ]───────>
Потік даних        ────────────────────── 0 втрачених пакетів ─────────────────────────>

Криптографічна необхідність оновлення ключів у тунелях

Сучасні симетричні блокові шифри, такі як AES-GCM та ChaCha20-Poly1305, гарантують високу швидкість апаратного прискорення та автентифіковане шифрування з приєднаними даними (AEAD). Тим не менш, криптографічні властивості алгоритмів погіршуються при обробці колосальних обсягів інформації на незмінному ключі.

Зношування шифрів та вичерпання номерів послідовності

У режимі Galois/Counter Mode (GCM) конфіденційність безпосередньо залежить від унікальності векторів ініціалізації (IV) та простору nonce. Якщо 96-бітний IV або лічильник повториться на тому самому 128- чи 256-бітному ключі, зловмисник зможе підробити автентифікаційні теги та відновити відкритий текст.

Протокол ESP (RFC 4303) запобігає атакам повторення за допомогою монотонно зростаючого 32-бітного поля Sequence Number. Зі стандартними 32-бітними номерами тунель може надіслати щонайбільше $2^{32} - 1$ (4 294 967 295) пакетів до вичерпання лічильника. На каналі 10 Гбіт/с зі стандартними пакетами 1500 байт лічильник вичерпується менш ніж за 58 хвилин:

$$\text{Швидкість пакетів} = \frac{10 \times 10^9 \text{ біт/с}}{1500 \times 8 \text{ біт/пакет}} \approx 833 333 \text{ пакетів/с}$$

$$\text{Час вичерпання} = \frac{4 294 967 295}{833 333} \approx 5 153 \text{ с} \approx 85.8 \text{ хвилин}$$

Згідно з вимогами RFC 4303, передавач НЕ ПОВИНЕН скидати лічильник назад у нуль у межах діючої SA. При наближенні до межі місткості тунель зобов'язаний погодити нові ключі або негайно відкидати наступні вихідні пакети.

Ковзне вікно захисту від повторів та порушення черговості пакетів

ESP реалізує ковзне вікно захисту від повторів (розміром 64, 128 або 1024 пакети) для відкидання дублікатів. У мережах із багатошляховою маршрутизацією (ECMP) балансування трафіку спричиняє надходження пакетів із порушенням хронологічного порядку.

Якщо шлюз одноосібно видалить старий ключ, доки затримані пакети перебувають у дорозі, шлюз-отримувач сприйме їх як пакети для застарілого або неіснуючого індексу SPI. Надійний механізм оновлення ключів зобов'язаний зберігати контекст захисту від повторів для обох асоціацій паралельно.

Недоліки підходу Break-Before-Make: мікрозбої та втрати даних

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

Стан гонитви під час видалення та інвалідація пакетів у польоті

У глобальних мережах (WAN) час розповсюдження сигналу становить від 10 до 150 мілісекунд. Коли ініціатор видаляє вихідну SA та надсилає сповіщення INFORMATIONAL з корисним навантаженням DELETE, пакети, буферизовані на проміжних вузлах або підводних кабелях, все ще рухаються до адресата.

Якщо приймач видалить вхідну SA одразу після отримання DELETE, транзитні пакети надійдуть на незареєстрований SPI. Мережевий стек ядра скине їх із помилкою INVALID_SPI. На завантажених магістралях це спричиняє раптові втрати сотень мегабайтів трафіку.

Роздування буфера, затримки TCP та шторм повторних надсилань

Алгоритми керування перевантаженням TCP інтерпретують раптову втрату пакетів як критичну аварію каналу:

Отримувач припиняє відправлення підтверджень (ACK) і переходить на дублюючі селективні підтвердження (SACK).
Відправник вмикає Fast Retransmit, зменшуючи вікно перевантаження (cwnd) удвічі або скидаючи його до розміру одного сегмента (MSS) за таймаутом RTO.
Численні сесії TCP одночасно намагаються повторно надіслати втрачені дані через щойно відкриту SA, перевантажуючи черги мережевих інтерфейсів.

Для чутливого UDP-трафіку реального часу (VoIP або тунелювання WireGuard) це призводить до спотворень голосу, зависання зображення та розриву з'єднань.

Механізм Make-Before-Break у RFC 7296: автомат станів подвійної SA

Розділ 2.8 стандарту RFC 7296 розв'язує проблему втрат завдяки розділенню життєвих циклів вхідної та вихідної SA. Замість одночасної заміни ключів кінцеві вузли спершу встановлюють нову вхідну дочірню SA (Child SA), перемикають вихідний трафік і підтримують стару вхідну SA до повного прибуття затриманих пакетів.

Обмін CREATE_CHILD_SA та отримання матеріалу з Nonce

Ротація ключів Child SA здійснюється всередині наявного зашифрованого каналу IKE_SA через обмін CREATE_CHILD_SA. Ініціатор надає:

Новий згенерований вхідний SPI (SPI_in_new).
Криптографічний nonce (Ni) для захисту від повторів.
Опційні відкриті частини Діффі-Хеллмана (KEi) для забезпечення цілковитої прямої секретності (PFS).
Повідомлення REKEY_SA із зазначенням старого замінюваного SPI.

Відповідач перевіряє параметри, виділяє власний SPI (SPI_resp_new), генерує nonce Nr та вираховує робочі ключі за допомогою псевдовипадкової функції:

$$\text{KEYMAT} = \text{prf+}(\text{SK_d}, \text{Ni} \mid \text{Nr})$$

Якщо для PFS обрано нову групу DH, спільний секрет $g^{ir}$ безпосередньо додається до обчислення: $\text{KEYMAT} = \text{prf+}(\text{SK_d}, g^{ir} \mid \text{Ni} \mid \text{Nr})$.

Таймери вичерпання вхідних черг та плавне перемикання вихідного SPI

Після завершення обміну CREATE_CHILD_SA сторони оновлюють внутрішні бази даних SPD та SAD:

Миттєве перемикання виходу: Усі нові пакети негайно шифруються з новим вихідним SPI, а лічильник номерів скидається на 1.
Паралельне приймання: Шлюз залишає активною стару вхідну SA поряд із новою в таблиці ядра SAD. Пакети з будь-яким із двох SPI розшифровуються прозоро.
Вікно вичерпання черги: Для старої SA запускається таймер зворотного відліку (зазвичай 30 секунд), що гарантує отримання буферизованих пакетів.
Узгоджене очищення: Після завершення таймера або отримання сповіщення DELETE стара асоціація остаточно видаляється з пам'яті ядра.

Вирішення колізій при одночасному оновленні ключів і гонках SPI

У симетричних середовищах Site-to-Site обидва шлюзи використовують однакові ліміти часу та обсягу даних. При синхронному зростанні трафіку обидва пристрої можуть розпочати оновлення в одну мілісекунду, надіславши зустрічні запити CREATE_CHILD_SA.

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

Виявлення: Вузол, який отримав запит на оновлення тієї самої SA, для якої він щойно надіслав свій запит, фіксує колізію.
Правило порівняння Nonce: Сторони порівнюють числові значення nonce (Ni) у взаємних запитах. Сторона з меншим значенням відкликає власну ініціативу та приймає запит партнера.
Видалення зайвих SA: Якщо через затримки обидві дочірні SA все ж були створені, сторона з меншим nonce ЗОБОВ'ЯЗАНА закрити дублікат повідомленням INFORMATIONAL з корисним навантаженням DELETE.

Цей математичний підхід гарантує зведення до єдиної робочої пари SA без втручання адміністратора та перезапуску тунелю.

Апаратне розвантаження шифрування та синхронізація черг ядра

Сучасні маршрутизатори вивантажують операції AES-GCM та ChaCha20 безпосередньо на мікросхеми мережевих карт (NIC ASIC) або апаратні інструкції процесора (AES-NI, AVX-512). Під час плавної заміни ключів виникають специфічні інженерні виклики:

Асинхронні кільця дескрипторів: Апаратні рушії буферизують дескриптори вхідних кадрів у пам'яті DMA. Атомарне оновлення таблиць SPI в апаратній пам'яті вимагає суворої синхронізації.
Атомарна заміна в Linux XFRM: Мережевий стек ядра Linux керує станами через сокети Netlink. Принцип Make-Before-Break спочатку додає новий запис xfrm_state до оновлення правил xfrm_policy, забезпечуючи безблокувальне паралельне читання ядрами CPU.
Перемикання контексту криптопроцесорів: Для кожного SPI створюється окремий апаратний контекст. У фазі спільного існування апаратний чип повинен підтримувати обидва контексти одночасно.

Захист корпоративних мереж: архітектура RiceGuard без втрати пакетів

Багато комерційних VPN ігнорують таймери вичерпання черг, жорстко розриваючи застарілі SA, що спричиняє зависання потоків даних і розриви сесій SSH щогодини під час зміни ключів.

VPNRice створив архітектуру RiceGuard, яка усуває ці проблеми:

Динамічні таймери утримання: RiceGuard вимірює затримку RTT та джиттер каналу в реальному часі, автоматично регулюючи вікно старої SA від 10 до 60 секунд.
Придушення колізій на Anycast: Розподілений арбітраж станів блокує появу дублюючих SA на прикордонних Anycast-серверах, заощаджуючи пам'ять апаратних таблиць.
Раннє попередження лічильників: RiceGuard відстежує 64-бітні розширені номери (ESN) та ініціює ротацію при досягненні 75% ліміту, запобігаючи аварійним зупинкам на швидкостях 40 Гбіт/с.
Неперервна передача даних: Додатки в тунелях RiceGuard не відчувають втрат пакетів, деградації вікон TCP чи затримок повторних відправлень під час оновлення ключів.

Діагностика та перевірка: моніторинг переходу SA у робочому оточенні

Мережеві інженери можуть перевірити коректність механізму Make-Before-Break на серверах Linux за допомогою набору інструментів iproute2.

Аналіз активних та паралельних записів SA

Виконайте команду ip xfrm state під час ротації для контролю подвійного стану:

# Перегляд стану XFRM під час зміни ключів
ip -s xfrm state list

Зразковий перехід відображає два паралельні вхідні індекси SPI для одного тунелю:

src 198.51.100.1 dst 203.0.113.5
    proto esp spi 0xc4a19b22 reqid 1 mode tunnel
    replay-window 64 flag esn
    auth-trunc hmac(sha256) 0x... 128
    enc cbc(aes) 0x...
    lifetime current: 3420 (s), 1482910408 (bytes)
    # Стара SA: активний таймер вичерпання вхідної черги

src 198.51.100.1 dst 203.0.113.5
    proto esp spi 0x07f3e8d1 reqid 1 mode tunnel
    replay-window 64 flag esn
    auth-trunc hmac(sha256) 0x... 128
    enc cbc(aes) 0x...
    lifetime current: 12 (s), 894210 (bytes)
    # Нова SA: успішно перебрала вихідний робочий трафік

Підтвердження нульових втрат за допомогою високонавантаженого ping

Запустіть щільний діагностичний потік ICMP і одночасно ініціюйте оновлення дочірньої SA:

# Надсилання 100 пакетів на секунду
ping -c 1000 -i 0.01 10.0.0.1

# В іншому терміналі виконайте оновлення через swanctl
swanctl --rekey-child --name net-to-net

У середовищі, що відповідає стандарту RFC 7296, підсумкова статистика демонструє нульові втрати:

1000 packets transmitted, 1000 received, 0% packet loss, time 10012ms
rtt min/avg/max/mdev = 14.120/14.852/17.310/0.412 ms

Коректне впровадження механізму Make-Before-Break, налаштування достатніх таймерів та розв'язання конфліктів утворюють основу стійкої захищеної мережі. Завдяки надійному управлінню життєвим циклом асоціацій безпеки тунелі забезпечують незламний криптографічний захист без падіння доступності сервісів.

Для побудови бездоганно стабільного та швидкісного шифрованого зв'язку, Завантажити VPNRice.