IKEv2 Session Resumption RFC 5723: Відновлення за 1-RTT та сесійні квитки

Мобільні робочі станції та смартфони стикаються з постійними змінами мережевих підключень протягом усього робочого дня. Операційні системи переводять радіомодулі в режим глибокого заощадження енергії, базові станції мобільного зв'язку перемикають абонентів у русі, а користувачі регулярно переводять ноутбуки в режим сну між зустрічами. За таких умов активні тунелі IPsec втрачають синхронізацію або примусово розриваються.

Коли пристрій виходить із режиму сну та прагне відновити захищений канал, стандартний протокол IKEv2 вимагає проведення тривалого криптографічного узгодження в кілька мережевих циклів. Стандартизований у RFC 5723 механізм відновлення сесій IKEv2 (Session Resumption) оптимізує цей процес за рахунок видачі клієнтам непрозорих зашифрованих сесійних квитків. Пред'являючи чинний квиток, мобільний пристрій відновлює захищений тунель лише за один мережевий цикл (1-RTT) без потреби виконання ресурсомістких асиметричних обчислень.

Дилема мобільного перепідключення: асиметрична криптографія та мережеві затримки

Класичне встановлення з'єднання IKEv2 спирається на модульне піднесення до степеня (MODP) або узгодження Діффі-Хеллмана на еліптичних кривих (ECDH) у поєднанні з перевіркою цифрових підписів чи транзакціями EAP. Незважаючи на бездоганну надійність, багаторазове повторення цих операцій створює відчутне навантаження на систему.

Чому класичне повне рукостискання IKEv2 уповільнює мобільних клієнтів

Стандартне узгодження з'єднання IKEv2 вимагає щонайменше двох послідовних фаз обміну:

Клієнт (Ініціатор)                              Шлюз (Відповідач)
   │                                                     │
   ├─── IKE_SA_INIT: SAi1, KEi, Ni ─────────────────────►│ (Фаза 1: обчислення DH)
   │◄── IKE_SA_INIT: SAr1, KEr, Nr ──────────────────────┤
   │                                                     │
   ├─── IKE_AUTH: IDi, CERT, AUTH, SAi2, TSi, TSr ──────►│ (Фаза 2: автентифікація)
   │◄── IKE_AUTH: IDr, CERT, AUTH, SAr2, TSi, TSr ───────┤

У стільникових мережах із високою затримкою (наприклад, під час роумінгу між вежами 4G/5G із затримками 80–120 мс) виконання двох послідовних циклів спричиняє відчутну паузу до надсилання першого корисного пакета. У разі застосування EAP-TLS або серверів RADIUS кількість циклів зростає ще більше. До того ж часте виконання важких математичних розрахунків на мобільних чипах прискорює розряджання акумулятора.

Розростання стану пам'яті шлюзів при високій щільності мобільних пристроїв

На стороні шлюзу необхідність утримувати контексти сесій в оперативній пам'яті для сотень тисяч періодично активних мобільних клієнтів спричиняє значне вичерпання ресурсів:

[100 000 неактивних мобільних пристроїв]
           │
           ├───► Витрати пам'яті: контексти тунелів, сесійні ключі, лічильники
           │
           └───► Брак пам'яті шлюза & складнощі горизонтального масштабування

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

Архітектура відновлення сесій згідно з RFC 5723

Специфікація RFC 5723 адаптує принципи сесійних квитків без збереження стану на сервері, які довели свою ефективність у TLS Session Resumption (RFC 5077), для стека протоколів IPsec. Архітектура звільняє оперативну пам'ять шлюза від утримання стану, інкапсулюючи всі необхідні параметри сесії в зашифрований квиток, що зберігається виключно на стороні клієнта.

Запит та видача криптографічних сесійних квитків

Під час первинного узгодження з'єднання клієнт сповіщає про підтримку функції відновлення сесій, додаючи корисне навантаження TICKET_SUPPORTED у запит IKE_AUTH:

Клієнт                                           Шлюз
  │                                                 │
  ├─── IKE_AUTH (із прапорцем TICKET_SUPPORTED) ───►│
  │                                                 │ (Створення основного IKE_SA)
  │◄── IKE_AUTH (відповідь із TICKET_SUPPORTED) ────┤ (Підтвердження підтримки)
  │                                                 │
  │◄── INFORMATIONAL (N(TICKET_OPAQUE, ДаніКвитка))─┤ (Видача зашифрованого квитка)
  ├─── INFORMATIONAL (Порожнє підтвердження) ──────►│

Параметри корисного навантаження:

Тип сповіщення: TICKET_SUPPORTED (Значення: 16403).
Ідентифікатор протоколу: 0 (стосується всього контексту IKE SA).
Розмір SPI: 0.

Після успішної автентифікації шлюз надсилає квиток усередині захищеного обміну INFORMATIONAL. Клієнт зберігає отриманий двійковий блок в ізольованому системному сховищі з прив'язкою до ідентифікатора шлюза.

Формат квитка та ієрархія деривації криптографічних ключів

Структура квитка є цілком непрозорою для клієнта. Розшифрувати та перевірити її може лише шлюз, який її видав (або кластер серверів зі спільним симетричним ключем TEK):

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 !                    Час життя квитка (4 байти)                 !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 !                  Ідентифікатор ключа TEK (4 байти)            !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 !                  Вектор ініціалізації (IV)                    !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 !          Зашифрований стан сесії (AES-GCM / ChaCha20)         !
 !  - Головний сесійний секрет (SK_d)                            !
 !  - Автентифіковані ідентифікатори (IDi, IDr)                  !
 !  - Селектори трафіку (TSi, TSr)                               !
 !  - Ліміт часу життя та лічильник повторних входів            !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 !                 Тег автентифікації / MAC                      !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Завдяки застосуванню автентифікованого шифрування (AEAD) будь-яка спроба підробки квитка зловмисником призводить до помилки дешифрування та безпечного переходу до класичного повного рукостискання.

Протокольний обмін для перепідключення за 1-RTT

У разі виявлення втрати зв'язку або після пробудження пристрою клієнт ініціює швидкий запит IKE_SESSION_RESUME.

Ініціація обміну IKE_SESSION_RESUME з передачею квитка

Замість надсилання важкого повідомлення IKE_SA_INIT клієнт відправляє оптимізований запит IKE_SESSION_RESUME зі свіжим випадковим числом і збереженим квитком:

Клієнт                                           Шлюз
  │                                                 │
  ├─── HDR, Ni, N(TICKET_OPAQUE) ──────────────────►│ (Швидке відновлення 1-RTT)
  │                                                 │ (Розшифрування квитка через TEK)
  │                                                 │ (Генерація нових ключів)
  │◄── HDR, Nr, [N(TICKET_OPAQUE)] ─────────────────┤

Складники повідомлення:

Заголовок (HDR): Прапорець обміну типу IKE_SESSION_RESUME.
Випадкове число ініціатора (Ni): 32 байти свіжої криптографічної ентропії.
Корисне навантаження квитка: Зашифрований блок із даними попередньої сесії.

Шлюз розшифровує квиток локальним ключем TEK, переконується у валідності терміну дії, витягує вихідний секрет SK_d та змішує його з Ni та Nr для формування нових ключів.

Відновлення криптографічного контексту та зміна ключів Child SA

Новий комплект ключів генерується через стандартну псевдовипадкову функцію IKEv2 (PRF):

{SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, SK_pr} = 
    prf+(SK_d_old, Ni | Nr)

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

Питання безпеки та керування життєвим циклом квитків

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

Компроміси прямої таємності та захист від атак відтворення

Оскільки відновлена сесія спирається на збережений у квитку секрет SK_d, витік ключа шифрування квитків (TEK) може дати змогу зловмиснику розшифрувати трафік відновлених з'єднань.

Для надійного захисту корпоративної інфраструктури застосовуються такі заходи:

Регулярна ротація ключів TEK: Сервери змінюють ключі TEK кожні 12–24 години, підтримуючи короткий інтервал перекриття для безперервного оновлення чинних квитків.
Контроль відтворення: Усередину квитка вбудовується унікальний порядковий ідентифікатор. Шлюз записує хеші пред'явлених квитків в оперативну пам'ять, відхиляючи повторні спроби у вікні валідності.
Суворе обмеження часу дії: Квитки мають короткий термін придатності (зазвичай від 2 до 8 годин), після чого клієнти зобов'язані пройти повну автентифікацію Діффі-Хеллмана.

Корпоративне впровадження: безсерверне кешування сесій у RiceGuard

Архітектура RiceGuard глибоко інтегрує стандарт RFC 5723 у протокольний стек мобільних клієнтів:

Критерій ефективності	Класичне рукостискання IKEv2	Відновлення в RiceGuard RFC 5723
Затримка підключення	2–4 мережевих цикли (250–500 мс)	1 мережевий цикл (<60 мс)
Навантаження на CPU шлюза	Високе (Модульне піднесення)	Мінімальне (Швидке симетричне AEAD)
Витрата заряду батареї	Відчутна (Важка арифметика)	Незначна (Мікросекундні хеш-операції)
Відмовостійкість кластера	Жорстка прив'язка до пам'яті	Без збереження стану (Спільний пул TEK)

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

Верифікація та діагностичний аудит: аналіз пакетів відновлення сесій

Фахівці з мережевої безпеки можуть досліджувати пакети RFC 5723 за допомогою аналізаторів трафіку та журналів strongSwan.

Перехоплення трафіку відновлення сесій на портах UDP 500 та 4500:

# Запис пакетів IKEv2 під час відновлення сесії
sudo tcpdump -nvvv -i any "udp port 500 or udp port 4500" -w /tmp/ikev2_resumption.pcap

Фільтрація корисного навантаження в аналізаторі Wireshark:

# Фільтр сповіщення про підтримку квитків
isakmp.notify.type == 16403

# Фільтр пакетів із зашифрованим квитком
isakmp.notify.type == 16404

Контроль стану служби strongSwan через системні журнали:

# Перегляд списку активних асоціацій SA та обробки квитків
sudo swanctl --list-sas
sudo journalctl -u strongswan -e | grep -E "(session resumption|ticket|TICKET)"

Приклад успішного відновлення зв'язку за 1-RTT:

charon: 07[IKE] received IKE_SESSION_RESUME request with valid ticket
charon: 07[IKE] decrypted session ticket successfully, restoring identity 'user@vpnrice.com'
charon: 07[IKE] derived fresh session keys using Ni/Nr entropy
charon: 08[IKE] IKE_SA resumed successfully in 38ms
charon: 08[IKE] Child SA installed, active application routes restored

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

Завантажити VPNRice.