Кратко

  • RFC 3182 помещал один или несколько элементов AUTH_DATA в POLICY_DATA. Локатор политики, учётные данные, подпись и ошибка имели разные доказательные функции; ни один элемент сам не выделял ресурс.
  • Идентичность могла менять хранителя по пути. В unicast локатор пользователя сохранялся от предыдущего узла, а учётные данные представляли текущий сетевой узел. В multicast PDP мог выбрать, какая идентичность приложения сохранится.
  • Аутентифицированный субъект ещё нуждался в авторизации, локальном исполнении, доступной ёмкости, состоянии всего пути, обработке пакетов и наблюдаемом результате приложения.

Ошибка об изменившейся идентичности была не мелочью

RSVP разделял два вопроса: достаточно ли ресурса и разрешено ли запросившему его использовать. RFC 2205 называл их admission control и policy control. Оба ответа должны были быть положительными. RSVP переносил данные политики, но не превращал их содержимое в готовое право.

Опубликованный в октябре 2001 года как Proposed Standard, RFC 3182 структурировал идентичность для второго решения. AUTH_USER обозначал пользователя, AUTH_APP — приложение. POLICY_LOCATOR указывал, где искать политику; CREDENTIAL содержал текстовый идентификатор, билет Kerberos или сертификат; подпись защищала предыдущие атрибуты; объект ошибки объяснял отказ.

Документ заменил RFC 2752 ради исправления кода P-Type и размера поля ошибки. Это не свидетельство двух волн внедрения. Обновление Datatracker в 2026 году также не новая версия протокола: в записи отражено проверенное техническое исправление.

Erratum 2958 исправляет Kerberos-процедуру раздела 6.3. Сервер извлекает сеансовый ключ из билета и применяет его для аутентификации пользователя; он не отправляет билет в KDC за этим ключом. Историческое изложение обязано использовать исправленную операцию.

Локатор приводил к правилу, а не к разрешению

RFC 2753 разделял Policy Decision Point и Policy Enforcement Point. PDP мог учитывать каталог, аутентификацию, учёт, биллинг, группу, время и локальную конфигурацию. PEP исполнял решение на узле. Даже одобренная политика не создавала ёмкость: ресурсный контроль мог отказать.

Формальный Distinguished Name поэтому не был мандатом, а сертификат — полосой пропускания. Локатор отвечал, где искать правило. Учётные данные давали материал для проверки. Подпись связывала байты с операцией ключа. Лишь уполномоченная сторона могла сопоставить проверенного principal с актуальной политикой.

Полная цепочка выглядела так: заявленная идентичность, тип учётных данных, валидация, аутентифицированный principal, область ключа или realm, локатор и версия политики, решение PDP, исполнение PEP, результат проверки ёмкости, состояние RSVP, пакеты и приложение. Единый флаг success стирал ответственность каждого звена.

Текст, билет и сертификат давали разные доказательства

Простой вариант переносил ASCII- или Unicode-имя. Для приложения RFC приводил имя исполняемого файла vic.exe. Сам документ предупреждал: этот вариант не содержит надёжно аутентифицируемых данных и по природе слабее. Имя файла не доказывает бинарный код, издателя, владельца процесса или целостность.

Kerberos требовал билет для следующего RSVP-узла или его PDP и совместимую инфраструктуру доверия. Билет мог аутентифицировать principal внутри соответствующего realm, но не переносил универсальное право на ресурсы соседнего домена.

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

RFC 4230 позднее отметил вычислительную и сигнальную цену открытого ключа, необходимость механизмов отзыва, неполную конфиденциальность Kerberos-идентичности и недостаточность аутентификации для авторизации. Сильные учётные данные улучшали один чек, но не заменяли дальнейшие решения.

На каждом переходе мог говорить другой субъект

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

В multicast и пользовательский локатор, и данные представляли текущий узел. Идентичность приложения жила по другому правилу: в unicast её копировали; в multicast сохраняли первый элемент либо выбранный PDP.

Оставшаяся идентичность не была перечнем участников. «Первый» — результат порядка, «выбран PDP» — результат политики. Ни то ни другое не создаёт представительство группы.

Сообщение могло содержать несколько AUTH_DATA, а узлы, понимающие политику, могли менять их. Аудит обязан сохранять вход, выход, автора изменения, домен доверия, security association и причину. Последнее имя без происхождения не позволяет отличить исходного заявителя от текущего говорящего.

Узел мог пропустить, ничего не решив

Не каждый RSVP-узел должен был понимать политику. RFC 2753 позволял исполнять её лишь на некоторых границах. RFC 3182 допускал, что policy-unaware router игнорирует объекты политики и продолжает обработку.

Это облегчало постепенное внедрение, но проход через узел не доказывал проверку пользователя, сертификата или права. На способной границе PEP спрашивал PDP; отрицательный ответ отклонял, положительный лишь позволял продолжить RSVP. Следующий узел всё ещё мог отказать из-за ёмкости, иной политики или ошибки установки.

Получение объекта, валидация credential, одобрение политики, установка состояния и предоставление услуги — разные состояния. Молчание неосведомлённого узла не было согласием.

Код ошибки ограничивал диагноз

Определялись неподдерживаемый тип учётных данных, недостаточные привилегии, истёкшие данные и изменившаяся идентичность. Если PDP не мог проверить AUTH_DATA, он должен был вернуть policy control failure и по возможности подробность.

Эти причины разделяли аутентификацию, привилегию и ресурс. Но EXPIRED_CREDENTIAL не доказывал удаление всех состояний, IDENTITY_CHANGED — получение уведомления приложением, а ошибка одной multicast-ветви — одинаковый итог остальных.

Нынешний реестр IANA сохраняет класс POLICY_DATA и значения ошибок policy control. Координация номера не доказывает реализацию каждого подтипа, распространённость или действие конкретного маршрутизатора.

Целостность не создавала легитимность

RFC 3182 рекомендовал защищать POLICY_DATA, если всё RSVP-сообщение не имело защиты. В пределах security association это позволяло обнаруживать изменение и replay.

RFC 4230 позднее развёл область внешнего сообщения и внутреннего контейнера. Узлы и PDP могли по проекту менять элементы, пользовательская информация могла утекать после первого перехода, а общей конфиденциальности между маршрутизаторами не было.

Аудит задаёт три вопроса: сохранились ли байты, кого аутентифицировал ключ или билет, имел ли этот субъект актуальный мандат? Криптография помогает с первыми двумя, но не решает третий.

RFC 2753 ожидал переписывание объектов на границах провайдеров по двусторонним соглашениям. RFC 4230 обнаруживал отсутствие стандартизованного формата авторизации и согласованного механизма QoS-резервирования в roaming. Идентичность пересекала границу легче, чем власть.

Защищаемая запись сохраняла исчезнувшие элементы

Сначала сохраняются заявленная идентичность и сырой элемент. Затем — тип credential, проверяющий, principal, realm или цепочка, область integrity, локатор, версия политики, решение, исполнение и ёмкость. Пакетное и прикладное наблюдение идут отдельно.

Для multicast нужны все входные идентичности, их порядок, тот, кто выбрал оставшуюся, и отброшенные элементы. Иначе удобное сжатие позже выглядит как голос всей группы.

Разделение символа, власти и исполнения в текстах Lu Heng служит редакционной линзой, а не исторической атрибуцией авторам RFC. RFC 3182 поместил имя в RSVP. Работающая система по-прежнему должна была доказать, кто решал, где решение исполнилось и что произошло.

Источники и пределы

Основная запись включает текст RFC 3182, страницу RFC Editor, Datatracker, API, Erratum 2958 и RFC 2752. Архитектурный и защитный контекст дают RFC 2205, 2750, 2753, 2747, 4230, 4094 и более поздний 4923. Исторические credential-форматы взяты из RFC 1510 и 2459, текущая регистрация — из IANA RSVP Parameters.

Анализ опирается на тексты Lu Heng о слоях реальности и приоритете работающего кода. Восемнадцать источников заморожены 2 октября 2026 года в Asia/Shanghai. Они не называют конкретную реализацию, оператора, пользователя, поток, инцидент, внедрение, тест совместимости или результат услуги. Каждый чек доказывает лишь собственную область.