Вопросы безопасности
Реализация BGP должна поддерживать механизм аутентификации, определенный в RFC 2385 [RFC2385]. Аутентификация на основе этого механизма может осуществляться независимо для каждого партнера.
BGP использует протокол TCP для организации надежного обмена трафиком между маршрутизаторами-партнерами. Для обеспечения целостности соединений и аутентификации источников данных в соединениях между парами узлов спецификация BGP задает использование механизма, определенного в RFC 2385. Этот механизм предназначен для детектирования и предотвращения активного перехвата (wiretapping attacks) данных из соединений TCP между маршрутизаторами. В отсутствие такого рода механизмов обеспечения безопасности атакующие могут разрывать соединения TCP и/или маскироваться под легитимные партнерские маршрутизаторы. Поскольку определенный в RFC механизм не обеспечивает аутентификацию партнеров, протокольные соединения могут служить объектом некоторых атак с повторным использованием перехваченных ранее данных (replay attack), которые не будут детектироваться уровнем TCP. Такие атаки могут приводить к доставке (от уровня TCP) «испорченных» или «подмененных» сообщений BGP.
Механизм, определенный в RFC 2385, добавляет к обычным контрольным суммам TCP 16-байтовый код аутентификации сообщения (MAC) который рассчитывается на основе тех же данных, что и контрольная сумма TCP. Расчет MAC основан на использовании необратимой хэш-функции (MD5) и закрытых ключей. Ключ известен паре маршрутизаторов-партнеров и используется для генерации значений MAC, которые не могут быть вычислены атакующим без знания ключа. Соответствующие спецификации реализации протокола должны поддерживать этот механизм и позволять администратору активизировать его использование независимо для каждого партнера.
RFC 2385 не задает механизмов поддержки ключей (например, их генерации, распространения и замены), используемых для расчета MAC. Документ RFC 3562 [RFC3562] (он имеет статус информационного) содержит некоторые рекомендации в этом направлении с обоснованием приведенных рекомендаций. В документе отмечается, что следует использовать разные ключи для связи с каждым защищенным партнером. Если один ключ используется для множества партнеров, это может привести к снижению уровня безопасности (например, за счет того, что при компрометации одного маршрутизатора становятся известными ключи, используемые для других маршрутизаторов).
Используемые для расчета MAC ключи следует периодически заменять для минимизации возможности компрометации ключа или успешной криптоаналитической атаки. В RFC 3562 предлагается устанавливать крипто-период (срок действия ключа) не более 90 дней. Более частая смена ключей снижает вероятность успеха атак с повторным использованием перехваченных данных. Однако отсутствие стандартного механизма эффективной координированной замены ключа, используемого парой маршрутизаторов, не позволяет надеяться, что реализации BGP-4, соответствующие данной спецификации, будут поддерживать такую частоту смены ключей.
Очевидно, что ключи следует выбирать так, чтобы атакующему было сложно угадать или подобрать ключ. Описанные в RFC 1750 методы генерации случайных чисел обеспечивают руководство по созданию значений, которые могут использоваться в качестве ключей. RFC 2385 предлагает разработчикам использовать ключи, представляющие собой строки печатных символов ASCII размером 80 байтов или меньше. В RFC 3562 предлагается в таком контексте использовать ключи размером от 12 до 24 байтов, состоящие из случайных (псевдослучайных) битов. Это полностью совместимо с предложениями для аналогичных алгоритмов MAC, которые обычно используют ключи размером от 16 до 20 байтов. В части обеспечения достаточного уровня случайности при использовании ключей минимальной длины в RFC 3562 также отмечается,что типичная срока текста ACSII будет близка к верхней границе диапазона длины ключей, заданного в RFC 2385.
Анализ уязвимостей протокола BGP приводится в документе [RFC4272].