Кратко

  • Подписка SSM задаёт канал (S,G): адрес источника S становится такой же обязательной частью запроса, как адрес группы G.
  • Сеть избавляется от поиска источников, RP и общих деревьев на пути SSM, зато приложение должно узнать S по отдельному каналу.
  • Ограничение по адресу не аутентифицирует отправителя; подписки по-прежнему создают состояние в маршрутизаторах и поверхность для истощения ресурсов.

Состояние начинается с решения получателя

О мультикасте часто говорят как о распределении трафика, но в SSM первый существенный акт происходит до распределения. Получатель выбирает источник. RFC 4607 определяет канал парой (S,G): сокет получает датаграммы только от адреса S, направленные на SSM-группу G, которую он запросил.

Для этого смысла выделены диапазоны 232.0.0.0/8 в IPv4 и FF3x::/32 в IPv6. Запрос (*,G) внутри них не является допустимым широким join. Маршрутизатор не должен использовать или передавать не source-specific запрос для SSM-адреса. Все маршрутизаторы должны одинаково понимать зарезервированный диапазон, иначе одинаковая группа будет означать разные правила допуска на разных участках.

В ASM сеть может заниматься обнаружением источника. В SSM адрес должен стать известен получателю через внешний механизм, обычно на уровне приложения. RFC 8815 помещает эту обязанность за пределы сети доставки. Маршрутизаторы уже не выясняют, кто вещает в группу; они строят путь к S, выбранному на краю.

Упрощение ядра не отменяет каталог источников

RFC 8815 рекомендует отказаться от ASM для междоменного мультикаста, использовать SSM и обеспечить полную поддержку в хостах и маршрутизаторах. На пути SSM не нужны Rendezvous Point, общее дерево, переключение на shortest-path tree, PIM Register, MSDP или динамическое обнаружение RP. Source-qualified join направляется к названному источнику через PIM-SSM и создаёт (S,G)-состояние.

Это уменьшает число сетевых механизмов, но функция обнаружения остаётся в системе. Приложению нужен каталог, программа передач или другая управляющая служба, которая сообщит S. Отсюда следует операционный вывод, отдельно от фактов RFC: ошибочная, устаревшая или подменённая запись может быть безукоризненно исполнена сетью. Документы подтверждают перенос ответственности, а не факт атаки на какую-либо существующую службу.

Граница рекомендации также точна. RFC 8815 относится к междоменному ASM и не исключает ASM внутри одной организации или домена. Статус BCP задаёт направление архитектуры, но не измеряет фактическое внедрение и не доказывает всеобщую миграцию.

Старый отчёт не умеет назвать S

RFC 4604 связывает SSM с IGMPv3 и MLDv2. Несource-specific запрос приложения для SSM-адреса должен завершаться ошибкой. Совместимость со старыми версиями может помешать доставке требуемого (S,G), потому что прежний формат отчёта выражает группу, но не фильтр источника.

На общей среде опасным становится даже подавление отчётов. В описанном RFC 4604 режиме совместимости SSM-хост не должен подавлять собственный source-specific отчёт только потому, что услышал отчёт другого хоста. Иначе маршрутизатор первого перехода может не узнать полный фильтр, а другие получатели на сегменте столкнутся с отказом в обслуживании. Видимое дублирование сохраняет сведения, которых нет в старом сообщении.

Канальный уровень тоже не завершает фильтрацию. Multicast-адрес Ethernet не выбирает пакеты по IP-источнику. Поэтому RFC 4607 требует, чтобы IP-модуль хоста проверил S перед передачей датаграммы сокету. Смысл (S,G) должен сохраниться в API, стеке хоста, IGMPv3 или MLDv2, первом маршрутизаторе и PIM-SSM.

Выбранный адрес не равен подтверждённому отправителю

SSM сужает множество принимаемых адресов, но не доказывает, кто управляет S. RFC 4607 предупреждает, что подделка исходного адреса может нарушить модель сервиса, и требует механизм верхнего уровня, если приложению нужна строгая аутентификация. Селекция источника и идентичность отправителя — разные свойства.

Состояние маршрутизаторов также остаётся. Подписки требуют обработки и управляющего трафика. Большие наборы могут стать атакой отказа в обслуживании; спецификация допускает аккуратно выбранные ограничения частоты или объёма состояния. Удаление RP не превращает multicast в протокол без ресурсов.

Что остаётся неизвестным

Три RFC не показывают нынешнюю долю SSM по регионам или классам операторов. В них нет современных настроек производителей, конкретных дефектов совместимости, оценки защищённости каталога источников названного сервиса или измеренного сокращения инцидентов после перехода. Такие утверждения потребуют других источников.

Доступный вывод уже достаточно важен. SSM делает междоменный multicast проще, потому что требует более полного решения на краю. Получатель называет источник, хост и сеть сохраняют выбор, приложение отвечает за обнаружение. Сеть становится предсказуемее, когда перестаёт угадывать.

Источники