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 не защищает от повторной отправки перехваченных пакетов при циклическом переполнении порядковых номеров.

Архитектура 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 еще до передачи в стек обработки состояний TCP.

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

Ранее администраторы открытых платформ применяли устаревший MD5 из-за отсутствия TCP-AO в Linux. Начиная с ядра Linux 6.7, модуль CONFIG_TCP_AO был интегрирован в основную ветку, обеспечив паритет с коммерческими сетевыми платформами.

Параметры сокетов ядра и регистрация кортежей MKT через Setsockopt

Программное обеспечение управляет MKT через специализированные вызовы 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) и точками обмена IXP.

Обеспечение постоянной доступности 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) для своевременного обнаружения попыток атаки.