Кратко

  • RFC 2908 разделил распределение multicast-адресов на три уровня: клиент—сервер, координация внутри домена и распределение между доменами. Экспериментальный RFC 2909 описал MASC — механизм временных заявок доменов на префиксы с возможностью деления и делегирования.
  • RFC 2909 предупреждал: IPsec может защитить двух соседних участников, но не установить происхождение пересланного UPDATE. Недоверенный узел MASC в другом месте топологии мог внедрить вредоносные обновления. Предлагаемая защита опиралась на административное доверие к соседям; это не доказательство внедрения MASC, атаки или передачи трафика.

В сентябре 2000 года архитектуре распределения multicast-адресов предстояло развести два вопроса, которые легко принять за один: кто выдаёт приложению адрес группы и кто резервирует более широкий диапазон, из которого этот адрес выбирают? RFC 2908 не объединял их в одну операцию. Работа делилась на три уровня: клиент запрашивал адрес у сервера; серверы координировали выделение внутри домена; междоменный механизм предоставлял диапазоны самим доменам. Для первого уровня подходил MADCAP, для второго — AAP или ручная настройка, а MASC был одним из вариантов третьего.

Так распределение multicast-адресов переставало напоминать единый глобальный счётчик. Узел MASC — обычно его предполагали размещать на пограничном маршрутизаторе — действовал от имени домена, часто соответствовавшего автономной системе. Он выбирал префикс из более крупного диапазона, отправлял заявку настроенным соседям и ждал появления конфликтующих заявок. Иерархия «родитель—потомок» позволяла разделить полученный префикс между локальными серверами выдачи или передать дочерним доменам дочерние префиксы. Выделенный диапазон также мог попадать в сведения о multicast-маршрутах для использования отдельным протоколом маршрутизации.

Это связанные, но разные плоскости управления: заявка MASC сама по себе не создаёт маршрут, членство получателя в группе или доставку пакетов.

Заявки имели срок действия. Префикс нужно было продлить до истечения срока, если домен хотел и дальше им пользоваться. Если продление не удавалось, спецификация предписывала прекратить использование префикса и удалить соответствующее состояние маршрута. Делегированный диапазон не становился постоянным автоматически. Но состояние распределения, маршрутизации и приложения могло разойтись, если оператор наблюдал только одно из них. Запись плоскости управления — не захват пакетов.

Архитектура прямо описывала компромисс при нехватке адресов. Жёсткое разбиение пространства может гарантировать отсутствие конфликтов, но резерв для сетевых разделений и переключения при отказе фрагментирует пул. Поэтому RFC 2908 считал эффективное использование и постоянную доступность важнее абсолютной гарантии «конфликтов не будет». Целью была очень высокая вероятность избежать столкновения при признании ненулевого риска. Заявки MASC, сравнение конфликтов, ожидание и выбор другого префикса реализовывали именно вероятностный подход, а не математическую гарантию.

RFC 2909 обозначил ещё одну границу — происхождение обновления. UPDATE мог не остановиться на соседе, который получил его первым: узлы MASC сохраняли сообщения и пересылали их родителям, соседним доменам, потомкам и внутренним участникам. В RFC сказано, что IPsec может защитить соединение между двумя соседями. Но если к топологии подключён недоверенный узел MASC, он может внедрить вредоносные UPDATE, которые другие узлы не распознают как таковые. Поэтому спецификация рекомендует устанавливать пиринг только с доверенными узлами.

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

Речь не о том, что «IPsec бесполезен». Защита канала охраняет конкретный участок связи. Проблема возникает дальше по пути: следующий узел знает, какой сосед передал ему сообщение, но может не иметь независимого способа установить, кто изначально создал заявку и имел ли каждый ретранслятор право её повторять. Метки времени и идентификаторы исходного узла помогают сравнивать конкурирующие заявки, но RFC 2909 не называет их криптографическим подтверждением происхождения. В документе нет и описания реального взлома. Он задаёт модель угроз, оставляя конфигурацию графа соседей на усмотрение операторов.

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

Статусы RFC ограничивают и исторический вывод. RFC 2908 имеет информационный статус и предлагает архитектуру; RFC 2909 — экспериментальный протокол, а не стандарт Интернета. Документы подтверждают, что авторы описали многоуровневое распределение и связанные с ним риски. Они не показывают, сколько сетей внедрили MASC, стал ли он распространённым и приводило ли вредоносное обновление к сбою. Статическое адресование GLOP из RFC 3180 и регистрация IANA по RFC 3171 — другие варианты, не свидетельство внедрения MASC.

Подтверждённый вывод уже и полезнее: заявка на префикс, защищённый канал, доверенный источник, маршрут и полученный multicast-поток — разные факты. Безопасная плоскость управления должна указывать, какие доказательства разрешают каждый переход.

Источники