Кратко

  • При GTSM защищённый трафик BGP отправляется с TTL или Hop Limit 255, а принимаются только значения, совместимые с утверждённой сетевой дистанцией.
  • Проверка затрудняет удалённый spoofing, но не аутентифицирует peer и содержимое TCP/BGP. Фильтрация источника, TCP-AO, защита control plane и routing policy остаются самостоятельными слоями.
  • Доказательство строится в обоих направлениях: исходящие 255, значение на входе, реальный порог, первый счётчик отбрасывания, состояния TCP/BGP и итог по маршрутам.

Можно увеличить hops 2 до hops 3, и доступность, вероятно, восстановится. Но одновременно расширится круг точек, из которых поддельный пакет способен выглядеть достаточно близким. Hop count — это не только эксплуатационный допуск, но и бюджет топологического доверия.

Остаток от 255

IPv4 TTL и IPv6 Hop Limit состоят из восьми бит; их максимум равен 255. При обычной маршрутизации каждый переход уменьшает значение. GTSM начинает с потолка и проверяет остаток на принимающей стороне.

У прямо подключённого peer ожидается 255. В multihop путь расходует единицы. В документации Cisco порог описан как 255 минус настроенное число hops; FRRouting предоставляет neighbor PEER ttl-security hops NUMBER. Конкретный подсчёт и взаимодействие с multihop-командами зависят от реализации. Поэтому рабочую границу необходимо вывести для данной платформы и подтвердить захватом пакетов.

Значение 253 при минимуме 253 говорит только о том, что пакет, вероятно, не прошёл больше разрешённого числа маршрутизаторов. Оно не сообщает, кто его создал. Удалённый атакующий не может стартовать выше 255, чтобы компенсировать уменьшения. Атакующий на одном канале с настоящим peer может поставить такое же высокое значение.

Близость трудно подделать издалека и легко — вблизи. Это точная граница полномочий GTSM.

Trusted не означает правдивый

RFC 5082 относит пакет зарегистрированной защищённой сессии к Trusted, если значение попадает в ожидаемый диапазон, и к Dangerous, если не попадает. Unknown означает, что GTSM не может связать трафик с такой сессией.

Это категории дистанции, а не доверия к содержимому. Вредоносный UPDATE от скомпрометированного законного peer может быть Trusted. Корректный сегмент, ушедший на более длинный резервный путь, может стать Dangerous.

Важна и точка классификации. GTSM предназначен защищать редкие ресурсы control plane — CPU, очереди, полосу между линейной картой и процессором. Если пакет отбрасывает только процесс BGP, он уже мог потребить эти ресурсы. Чем ближе решение к forwarding plane, тем полнее эффект против DoS.

Нужна цепочка наблюдаемости: аппаратный счётчик, control-plane policy, ядро, TCP socket, процесс BGP. Первый уровень, на котором пакет исчезает, показывает, какой ресурс действительно был защищён.

Четыре факта вместо одной строки

RFC 5082 не определяет общего автоматического согласования GTSM для существующих протоколов. Обе стороны настраиваются вручную: отправляют 255 и допускают корректную дистанцию в каждом направлении.

Следует раздельно хранить утверждённую топологию, настроенный hop count, наблюдаемый путь и фактически применяемый порог. ECMP, failover, перенос на loopback, замена платформы, service chain либо различие IPv4/IPv6 способны развести эти величины.

Строка конфигурации доказывает намерение, но не исходящий TTL, не входное значение и не место drop. Даже Established недостаточно: при ошибочно выключенном GTSM на обеих сторонах сессия тоже работает.

Граница доказывается отрицательным тестом. На изолированном canary пакет ровно на пороге должен пройти дальше, а пакет на единицу ниже — увеличить ожидаемый ранний счётчик и не появиться в TCP/BGP.

Multihop превращает близость в диаметр

Прямое соседство — наиболее ясный случай: настоящий peer доставляет 255, любой обычный промежуточный маршрутизатор меняет значение. RFC 5082 ограничивает самое уверенное утверждение применимости топологиями с естественными пределами, особенно прямым соединением.

Multihop всё ещё отсекает далёкие источники. Но любая точка внутри разрешённого диаметра потенциально проходит тот же тест. RFC 7454 прямо отмечает снижение эффективности.

Каждый запас должен иметь обоснование. Пять разрешённых hops при штатных двух могут покрывать документированный аварийный путь, а могут быть числом из старого шаблона. Первое — решение о непрерывности; второе — расширение границы без владельца.

Направления независимы. A достигает B через два маршрутизатора, B возвращается через три. SYN проходит, SYN-ACK отбрасывается. Один длинный ECMP-путь вызывает плавающий сбой. IPv4 и IPv6 также могут расходиться. Нужны распределения по направлению, семье, пути и epoch сессии, а не единственный traceroute.

Туннель может искусственно приблизить источник

Туннель способен перенести внутренний пакет через большую сеть, не уменьшая внутренний TTL. После декапсуляции рядом с peer виден высокий остаток, хотя исходная точка была далека. Другие модели копируют или распространяют значение; MPLS uniform, pipe и short-pipe различаются.

RFC 5082 считает целостность туннеля, доверие к endpoints и проверку источника явными предпосылками. В учёте нужно указать, кто может вводить трафик на входе, как связаны внутренний и внешний TTL, где заканчивается туннель и какая source validation действует на выходе. «Туннель равен одному hop» доказательством не является.

DDoS scrubbing, виртуальный firewall или service chain могут сохранить адреса peer, но изменить смысл расстояния. Любой посредник, меняющий арифметику GTSM, входит в trust boundary.

Фрагменты открывают ещё одну слепую зону. Не начальный fragment не содержит TCP header, нужный для ранней привязки к BGP-сессии. Reassembly расходует память и CPU. RFC 5082 рекомендует избегать фрагментации; MTU, ICMP и fragment policy проверяются отдельно.

Расстояние, идентичность и право маршрута — разные столбцы

GTSM спрашивает, правдоподобна ли дистанция. Ingress filtering проверяет, допустим ли источник на интерфейсе. TCP-AO защищает аутентичность и целостность сегмента в контексте ключей. Control-plane policy ограничивает ресурсы. BGP policy решает судьбу маршрута.

On-link атакующий может пройти GTSM и не пройти source validation. On-path атакующий сохраняет расстояние, поэтому требуется криптографическая аутентификация. Аутентифицированный, но скомпрометированный peer способен объявить чужой префикс, который должна отвергнуть локальная import policy. Unknown-трафик требует отдельного policing.

Называть TTL 255 аутентификацией — преувеличивать вывод. Считать GTSM бесполезным, потому что это не аутентификация, — упускать его точную роль. Он рано и дёшево исключает класс удалённого трафика, несовместимого с утверждённой топологией.

Canary с предсказанным отказом

До изменения пути захватываются оба направления: исходящие 255, распределение входных значений, порог и первый enforcement counter. Моделируются штатный, сервисный, ECMP- и реалистичный аварийный пути.

Если новый законный минимум равен 252, нужно выбрать: сохранить прежнюю границу, исправив топологию, или явно утвердить больший диаметр. Временное расширение получает срок и rollback.

На изолированном peer отправляются значения выше порога, ровно на нём и на единицу ниже. Первые два идут дальше, третье исчезает в предсказанном месте. Отдельно тестируются on-link spoof, неверный TCP key и запрещённый маршрут от аутентифицированного peer. Каждый должен остановиться в своей системе контроля.

После переключения сопоставляются GTSM drops, TCP retransmits, ошибки аутентификации, BGP FSM и маршруты. Отсутствие маршрута не доказывает TTL-drop: тот же симптом создают ACL, ключ, NOTIFICATION и policy.

Rollback возвращает прежний путь или явные двусторонние пороги. Одностороннее отключение GTSM и максимальное расширение другой стороны возвращают зелёный статус ценой скрытой деградации.

Пакет с 252 не был «ложным». Он не соответствовал договору на 253. Надёжность GTSM держится на скромности вывода: близость допускает пакет к следующей проверке, но не даёт идентичности, целостности или права объявления.