Кратко

  • GTSM проверяет близость пакета по TTL IPv4 или Hop Limit IPv6; он не аутентифицирует отправителя и не заменяет криптографическую защиту TCP-сессии BGP.
  • Смысл результата зависит от радиуса переходов, входной фильтрации, доверия к прямому соседу и поведения туннелей.
  • Для гарантии пира нужна связанная запись: значение переходов, интерфейс и туннель, утверждённый сосед, состояние ключа TCP-AO, сессия и владелец каждого контроля.

Кросс-коннект только что перенесли. Оба BGP-маршрутизатора по-прежнему отправляют управляющие пакеты с TTL 255, и каждый принятый пакет проходит проверку GTSM. Поэтому в журнале изменений написано, что удалённый пир аутентифицирован.

Вывод шире доказательства. Проверка показывает, что пакет прибыл из допустимого радиуса переходов. Сама по себе она не показывает, какая утверждённая система его создала, могло ли устройство на том же канале подделать пакет, изменил ли туннель видимую дистанцию и был ли у сегмента действительный криптографический аутентификатор. Сессия может работать, GTSM — выполнять проектную функцию, а слово «аутентифицирован» всё равно оставаться необоснованным.

RFC 4271 размещает BGP поверх TCP. Две системы создают TCP-соединение, а затем обмениваются сообщениями BGP. Поэтому вопросы различны: пришёл ли IP-пакет с правдоподобного расстояния; принадлежит ли TCP-сегмент защищённому соединению; принял ли настроенный сосед сессию; сохраняет ли стоящая за ним организация право обмениваться маршрутами? Один зелёный индикатор не отвечает на все четыре.

RFC 5082 строит GTSM на простой асимметрии. Непосредственно подключённый протокольный пир отправляет с максимальным значением 255. Каждый пересылающий маршрутизатор уменьшает это значение; получатель, ожидающий 255, может отбросить трафик, вероятно возникший дальше. Если классификация выполняется близко к линейному оборудованию, поддельные управляющие пакеты не расходуют дефицитные ресурсы control plane.

Это полезная защита. Она сужает поверхность атаки и даёт дешёвую топологическую проверку до дорогой протокольной обработки. Поэтому RFC 7454 рекомендует TTL security для непосредственно подключённых BGP-пирингов.

Граница столь же ясна. RFC 5082 прямо говорит, что GTSM не заменяет аутентификацию и не защищает от подделки или повторной передачи на самом канале. Скомпрометированное соседнее устройство достаточно близко. Злоумышленник в доверенном сегменте — тоже. Пакет, созданный или декапсулированный на допустимом конце туннеля, также может выглядеть близким. Успех доказывает настроенную близость, а не авторство.

При multihop разница ещё заметнее. Для loopback или многошаговой сессии GTSM может принимать настроенный радиус TTL, а не ровно один переход. Но каждый дополнительный переход расширяет множество мест, откуда способен прийти правдоподобный пакет. Изменение топологии меняет смысл даже без изменения числа.

Туннели добавляют неоднозначность. RFC 5082 рассматривает варианты IP и MPLS, потому что внутренний TTL, видимый пиру, зависит от инкапсуляции, режима распространения и от того, является ли декапсулятор конечной точкой протокола. Целостность и место окончания туннеля становятся частью доказательства. Тревога GTSM после миграции может выявить новый путь; успешная проверка не сертифицирует туннель.

Криптографическая аутентификация сегмента отвечает на другой вопрос. RFC 5925 определяет TCP-AO для длительных TCP-соединений, включая BGP. Код аутентификации вычисляется по материалу, связанному с соединением, с использованием управляемых наборов мастер-ключей и ключей трафика для конкретного соединения. Расширения номера последовательности предотвращают replay после оборота обычного пространства TCP. Действительный результат подтверждает, что сегмент создал обладатель принятого ключевого материала для этого соединения.

TCP-AO не отменяет управление. Операторы должны привязать ключ к отношению пиринга, установить его на обоих концах, определить срок действия, согласовать ротацию и удалить старый материал. Действительный MAC под ключом, который следовало вывести, может быть криптографически верен и операционно не разрешён. И наоборот, успешный GTSM при отсутствующем или неуспешном TCP-AO нельзя повышать до идентичности.

Контроли сильнее вместе, потому что отказывают по-разному. GTSM заранее фильтрует неправдоподобно удалённый трафик, входная фильтрация сокращает подделку источника, TCP-AO аутентифицирует сегменты, а конфигурация BGP-соседа связывает сессию с утверждённым отношением. Ни один контроль не должен присваивать имя другого.

Источники