TCP-AO RFC 5925: безпека сесій BGP, ротація MKT та автентифікація TCP

Протокол граничного шлюзу (BGP-4, RFC 4271) є основою глобальної маршрутизації в Інтернеті, підтримуючи тривалі пірингові з'єднання TCP через порт 179 між автономними системами (AS). Маршрутизатори в точках обміну трафіком (IXP), у хмарних хабах та корпоративних магістралях безперервно передають інформацію про досяжність мереж (NLRI). Оскільки базовий протокол TCP позбавлений вбудованих засобів перевірки автентичності, сигнальний трафік площини керування залишається вразливим до підробки пакетів, аварійного скидання з'єднань та перехоплення сесій.

Протягом багатьох років мережеві інженери застосовували RFC 2385 (опція підпису TCP MD5). Проте структурні вади RFC 2385 унеможливлювали зміну ключів без розриву зв'язку, що спричиняло падіння BGP і глобальну нестабільність маршрутизації. Інженерна рада Інтернету (IETF) затвердила стандарт RFC 5925, який визначає опцію автентифікації TCP (TCP-AO), доповнену криптографічним стандартом RFC 5926. TCP-AO усуває застарілі недоліки завдяки кортежам майстер-ключів (MKT), розширеним порядковим номерам, гнучкості алгоритмів та безперервній ротації ключів без втрати пакетів.

Вразливість базової маршрутизації: перехоплення TCP RST та застарілість RFC 2385 MD5

Стандартний стек TCP підтверджує валідність пакетів за 4-кортежем IP та ковзним вікном порядкових номерів. У швидкісних магістральних каналах зловмисник, здатний підібрати або вгадати порядковий номер у межах вікна прийому, може надіслати підроблений пакет TCP RST або SYN (RFC 4953, RFC 5961). Отримавши валідний пакет RST у вікні, операційна система миттєво закриває сокет. Для BGP це спричиняє раптове відкликання маршрутів та поширення хвиль нестабільності по всій мережі.

Стандарт RFC 2385 (Option Kind 19) намагався вирішити цю проблему шляхом підписування кожного сегмента гешем MD5 на основі спільного секрету. Попри широке поширення, RFC 2385 має критичні обмеження:

1. Криптографічна слабкість: Алгоритм MD5 схильний до колізій. Стандарт обчислює прямий геш замість використання структури HMAC, що не відповідає сучасним вимогам захисту.
2. Відсутність гнучкості шифрів: Алгоритм MD5 жорстко зафіксований у специфікації. Перехід на нові алгоритми потребує створення окремої опції TCP.
3. Проблема зміни ключів: Заголовок RFC 2385 не містить поля ідентифікатора ключа. Під час оновлення ключа обидва маршрутизатори мають перемикнутися абсолютно синхронно. Якщо одна сторона переходить на новий ключ, поки в каналі залишаються пакети зі старим підписом, верифікація зазнає невдачі й сесія BGP розривається.
4. Вразливість до повторів усередині сесії: RFC 2385 не захищає від повторного надсилання сегментів після циклічного переповнення порядкових номерів TCP.

Архітектура RFC 5925: структура заголовка опції автентифікації TCP

Специфікація RFC 5925 запроваджує опцію TCP Kind 29 на заміну Kind 19. Заголовок TCP-AO має компактну структуру з полями для узгодження ключів та захисту від повторів:

+---------------+---------------+---------------+---------------+
|  Kind = 29    |  Length = 16  |   KeyID       |  NextKeyID    |
+---------------+---------------+---------------+---------------+
|                    Код автентифікації повідомлень (MAC)        |
|                         (96 біт / 12 байтів)                  |
+---------------+---------------+---------------+---------------+

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

• Kind (1 байт): Значення 29, що вказує на обробку за стандартом RFC 5925.
• Length (1 байт): Загальна довжина опції (4 байти заголовка плюс довжина MAC; фіксовано 16 байтів для MAC довжиною 96 біт).
• KeyID (1 байт): Ідентифікатор кортежу майстер-ключа (MKT), використаного відправником для генерації MAC поточного сегмента.
• NextKeyID (1 байт): Ідентифікатор MKT, який відправник запитує для генерації відповідей віддаленою стороною. Це поле формує внутрішній канал узгодження ключів.
• MAC (12 байтів): Криптографічна мітка автентичності, розрахована для псевдозаголовка TCP, заголовка TCP (з обнуленими опціями) та корисного навантаження.

Відокремлення ідентифікатора ключа від внутрішнього стану сокета дозволяє підтримувати кілька активних ключів одночасно.

Кортежі майстер-ключів (MKT) та криптографічні алгоритми: специфікації RFC 5926

Архітектура RFC 5925 організована навколо кортежу майстер-ключа (Master Key Tuple, MKT). Кожен MKT визначає параметри захищеного з'єднання:

• Область охоплення: IP-адреси та маски джерела й призначення, а також порти TCP.
• Ідентифікатори: SendID (KeyID для вихідних пакетів) та RecvID (KeyID для перевірки вхідного трафіку).
• Майстер-ключ: Спільний секретний рядок із високою ентропією.
• Криптографічний набір: Алгоритм автентифікації та функція формування сесійних ключів згідно з RFC 5926.

Функції формування сесійних ключів (KDF) через псевдовипадкові примітиви

Для збереження секретності майстер-ключа TCP-AO ніколи не підписує пакети в каналі вихідним секретом безпосередньо. RFC 5926 визначає функції формування ключів (KDF) на базі псевдовипадкових примітивів (PRF):

Traffic_Key = PRF(Master_Key, Context_String)

Контекстний рядок об'єднує динамічні параметри рукостискання:

Context = Direction || Send_ISN || Recv_ISN || Algorithm_ID

Оскільки сесійні ключі формуються з урахуванням початкових порядкових номерів (ISN) та напрямку передачі, кожне з'єднання захищене двома незалежними односпрямованими ключами. Компрометація сесійного ключа не розкриває майстер-ключ і не дає змоги втрутитися у зворотний потік даних.

Порівняльний аналіз: AES-128-CMAC проти HMAC-SHA-1-96 у кремнії ASIC

Стандарт RFC 5926 визначає два обов'язкові набори: AES-128-CMAC-96 та HMAC-SHA-1-96:

У маршрутизаторах операторського рівня AES-128-CMAC гарантує стабільну пропускну здатність на повній швидкості фізичного інтерфейсу.

Вирішення проблеми зміни ключів: безперервна ротація без розриву сесій BGP

Безперервна ротація ключів — ключова інженерна перевага RFC 5925. Політики безпеки вимагають регулярного оновлення ключів, проте в RFC 2385 це призводило до зупинки передачі трафіку. TCP-AO розв'язує цю проблему за допомогою поетапного процесу узгодження:

1. Попередня конфігурація: Адміністратори додають новий MKT (KeyID = 2) на обох маршрутизаторах під час активної передачі даних за допомогою MKT (KeyID = 1).
2. Передача сигналу: Маршрутизатор A налаштовує сокет на вихідний сигнал NextKeyID = 2, продовжуючи підписувати сегменти через KeyID = 1.
3. Реакція партнера: Маршрутизатор B виявляє NextKeyID = 2, активує локальний MKT-2, починає підписувати пакети через KeyID = 2 та відповідає значенням NextKeyID = 2.
4. Завершення переходу: Маршрутизатор A отримує вхідні пакети з KeyID = 2 і остаточно перемикає вихідне підписування на KeyID = 2.

Після повного переходу старий MKT-1 безпечно вилучається. Процедура відбувається всередині сесії без скидання TCP та без розриву з'єднань BGP.

Механізм захисту від повторів: розширені порядкові номери та захист від прихованих ін'єкцій (Sneak-Path)

У магістральних мережах 100 Гбіт/с та 400 Гбіт/с 32-бітний простір номерів TCP вичерпується за лічені секунди. Швидке циклічне оновлення створює ризик повторного впровадження раніше перехоплених пакетів у нові вікна передачі.

Стандарт RFC 5925 усуває цю загрозу шляхом розширення порядкових номерів (Sequence Number Extensions, SNE):

• У заголовку пакета передається стандартний 32-бітний номер (SEQ).
• Всередині ядра операційної системи зберігається 32-бітний лічильник розширення (SNE).
• Під час переходу SEQ від 0xFFFFFFFF до 0x00000000 ядро автоматично збільшує SNE.
• Обчислення MAC охоплює повне 64-бітне значення (SNE || SEQ), блокуючи спроби впровадження застарілих пакетів.

Крім того, TCP-AO захищає від прихованих шляхів ін'єкцій (sneak-path). Несинхронізовані пакети SYN, надіслані для провокування RST, відсікаються за допомогою параметрів базового MKT ще до потрапляння в стек обробки з'єднань.

Реалізація в ядрі Linux: CONFIG_TCP_AO та архітектура Socket API

Раніше відкриті мережеві платформи залишалися на застарілому MD5 через відсутність TCP-AO в ядрі Linux. Починаючи з ядра 6.7, підтримка CONFIG_TCP_AO увійшла до офіційної гілки, зрівнявши можливості Linux із комерційними мережевими ОС.

Параметри сокетів ядра та реєстрація кортежів MKT через Setsockopt

Програмні комплекси взаємодіють із ядром через системні виклики setsockopt:

struct tcp_ao_add cmd;
memset(&cmd, 0, sizeof(cmd));

cmd.tcpa_addr.ss_family = AF_INET;
((struct sockaddr_in *)&cmd.tcpa_addr)->sin_addr.s_addr = inet_addr("198.51.100.1");
cmd.set_current = 1;
cmd.keyid = 1;
cmd.next_keyid = 1;
cmd.alg_name = "cmac(aes128)";
cmd.keylen = 16;
memcpy(cmd.key, "SharedMasterSecret", 16);

setsockopt(sockfd, IPPROTO_TCP, TCP_AO_ADD_KEY, &cmd, sizeof(cmd));

Ядро перевіряє передані параметри, закріплює структуру MKT за сокетом та розраховує сесійні ключі під час встановлення з'єднання.

Взаємодія з FRRouting, BIRD та корпоративними демонами маршрутизації

Провідні відкриті маршрутизатори використовують ці інтерфейси ядра:

• FRRouting (FRR): Містить команди в режимі router bgp для закріплення ідентифікатора ключа, алгоритму та секрету TCP-AO за конкретним сусідом.
• BIRD Internet Routing Daemon: Дозволяє задавати зв'язки TCP-AO у конфігураціях протоколу BGP.
• Сумісність між виробниками: Маршрутизатори Linux під керуванням нових ядер успішно встановлюють захищений піринг із пристроями Cisco IOS-XR та Juniper Junos.

Порівняння ешелонованого захисту: TCP-AO, GTSM (RFC 5082) та тунелювання IPsec

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

Механізм GTSM (RFC 5082) блокує віддалені атаки на прямих лінках через перевірку TTL = 255, проте не діє на багатохопових з'єднаннях eBGP. Тунелі IPsec шифрують увесь трафік, але суттєво зменшують MTU. Стандарт TCP-AO забезпечує автентичність транспортного рівня без втрати швидкості та без ускладнення маршрутизації.

Інфраструктура RiceGuard: зміцнення площини керування BGP у мультихмарних середовищах

Сервіс VPNRice гарантує стабільний зв'язок за допомогою мережевої архітектури RiceGuard. Під клієнтськими тунелями функціонує масштабна магістраль Anycast, підключена до операторів першого рівня (Tier 1) та міжнародних точок обміну трафіком.

Для безперервної роботи Anycast необхідний надійний захист протоколу BGP:

1. Запобігання розривам зв'язку: Використання TCP-AO на пограничних стиках дозволяє вузлам RiceGuard автоматично відхиляти підроблені пакети RST від зовнішніх джерел.
2. Автоматична ротація MKT: Центральна система керування оновлює ключі за допомогою сигналів NextKeyID RFC 5925 без переривання сервісу.
3. Багаторівнева безпека: Сигнальні сесії BGP захищені стандартом TCP-AO, а користувацькі пакети передаються через тунелі WireGuard з мінімальною задержкою.

Такий підхід гарантує стабільність маршрутизації навіть під час збоїв у зовнішніх магістральних каналах.

Чек-лист переходу у промисловому середовищі: міграція з TCP MD5 на RFC 5925

Командам системних інженерів рекомендовано дотримуватися чіткої послідовності дій:

• Перевірка системи: Переконайтеся, що сервери Linux працюють на ядрі 6.7 або новішому з активним параметром CONFIG_TCP_AO = y. Перевірте сумісність мережевих комутаторів.
• Складання матриці MKT: Сформуйте таблицю ідентифікаторів KeyID, IP-адрес сусідів та спільних ключів із довжиною не менше 128 біт.
• Вибір шифрів: Визначте AES-128-CMAC-96 пріоритетним алгоритмом для апаратного прискорення ASIC; залишайте HMAC-SHA-1-96 лише для сумісності зі старими платформами.
• Початкове перемикання: Заплануйте технологічне вікно для переведення сесій із RFC 2385 на TCP-AO; подальші зміни ключів виконуватимуться онлайн.
• Автоматизація процесів: Налаштуйте скрипти для надсилання сигналу NextKeyID завчасно до завершення терміну дії ключів.
• Контроль за метриками: Відстежуйте системні лічильники скидань у /proc/net/netstat (TCPAOBadKey, TCPAOGood та TCPAORequired) для раннього виявлення підозрілих пакетів.