Кратко

  • RFC 2385 проверял каждый защищённый TCP-сегмент общим секретом и требовал молча отбрасывать результат с неверным отпечатком.
  • Ради дефицитного пространства опций формат не нёс идентификатора алгоритма или ключа; успешная проверка свидетельствовала о сегменте при локальной конфигурации, а не о свежести ключа, полномочиях соседа или истинности маршрута.

Малый пакет, крупный сбой

BGP получил от TCP упорядоченный надёжный поток, но стал зависеть от состояния TCP-соединения. Если сторонний атакующий угадывал конечные адреса и подходящий диапазон последовательности, поддельный RST мог закрыть соединение. Маршрутизатор восстанавливал сессию и иногда временно удалял полученные маршруты.

Опция Kind 19 включала байты типа и длины и 16 байтов MD5. В расчёт входили псевдозаголовок IPv4, TCP-заголовок без опций и с нулевой контрольной суммой, данные и заранее известный обеим сторонам секрет.

Получатель вычислял значение заново. Несовпавший сегмент следовало отбросить без ответа. Журналирование рекомендовалось, но не становилось квитанцией для отправителя. Молчание не помогало атакующему и одновременно не объясняло законному соседу ошибку конфигурации.

IESG Note ограничивал обещание: это действующая практика против некоторых простых атак, уязвимая перед целенаправленными. RFC 2385 защищал вход в автомат TCP, а не всю правду BGP.

Граница доказательства

Совпавший отпечаток означал, что байты сегмента, адреса псевдозаголовка и локально выбранный секрет дали один результат. Он не устанавливал юридическую личность оператора, право AS анонсировать префикс или прохождение UPDATE через импортную политику. Он не доказывал запись в RIB и FIB либо доставку трафика.

На проводе не было даже имени ключа. Если две стороны по-разному понимали «текущий ключ», сегмент не мог разрешить спор. Каждая реализация проверяла свою локальную версию.

Поэтому отправка, наличие опции, выбор секрета, проверка, приём TCP, сохранение BGP-сессии, принятие UPDATE, установка маршрута и доставка пакета — разные квитанции. RFC 2385 закрывал лишь начало цепочки.

Сильная локальная политика и скрытая координация

Применение опции не согласовывалось внутри TCP. Его определяли политика площадки и приложение. Если SYN/ACK приходил без подписи, защищённая сторона не понижала требования: она игнорировала ответ, и соединение не создавалось. Непроверенный сосед не мог отменить локальную защиту.

Но секрет и время включения приходилось согласовывать вне пакетов. KeyID отсутствовал. Документ допускал смену пароля в открытом соединении при синхронизации сторон и сразу предупреждал о ретрансляциях. Сегмент, созданный старым секретом, мог прийти после перехода получателя на новый. Сам сегмент не называл свою эпоху.

Формула была детерминированной только после того, как локальное состояние подставляло невидимый параметр.

Сэкономленный байт

Полный TCP-заголовок ограничен 60 байтами. После фиксированных двадцати остаётся сорок для всех опций. MD5 занимал 18. В примере RFC опции MSS, масштаб окна, timestamp, MD5 и заполнение целиком занимали доступные сорок байтов SYN.

Проблемы MD5 уже обсуждались, но развёрнутый формат не имел поля алгоритма. Один дополнительный байт сделал бы опцию 19-байтной и, вероятно, 20-байтной после выравнивания. В малом бюджете это казалось существенной ценой.

Экономия помогла немедленному внедрению и лишила Kind 19 способа назвать преемника. Новый алгоритм потребовал новой опции. Errata 4432 исправила «32-байтные слова» на «32-битные». RFC 6691 исправил правило MSS: именно отправитель сокращает данные на фактический размер опций. Ни одно уточнение не добавило селектор.

Жизненный цикл вернулся в конфигурации

RFC 3562 рекомендовал ключи длиной 12–24 байта, ограничение их общего использования и смену не реже раза в 90 дней. Так проявилась работа, вынесенная из формата. Короткий секрет можно подобрать, повторное использование увеличивает радиус утечки, несинхронная замена обрывает нормальную сессию.

RFC 5925 заменил TCP MD5 механизмом TCP-AO. Он добавил расширяемые алгоритмы, KeyID, обозначение следующего принимаемого ключа, производные ключи соединения и защиту от повторов. Но он не распределяет мастер-секреты и не авторизует BGP-маршруты.

В реестре BTW уже есть отдельная статья об эпохах ключей TCP-AO. Здесь предмет иной и более ранний: RFC 2385 говорил «сегмент соответствует общему состоянию», не указывая, какое заменяемое состояние имелось в виду.

Историческая оценка

RFC 2385 не был бесполезен из-за последующего устаревания. Он дал узкую работающую защиту оборудованию 1998 года и не позволял удалённому неподписанному сигналу включить downgrade.

Урок относится к минимальной общей спецификации. Она должна быть достаточно тонкой для внедрения и достаточно явной для проверки и замены независимыми реализациями. Успешный digest не равен праву на маршрут; Established не равен доставке.

RFC 2385 защитил сегмент. Отсутствующий селектор сделал смену алгоритма отдельным протокольным проектом.

Источники