Кратко

  • RFC 3318 разрешал * в комбинации ролей устанавливаемой политики: одно правило могло охватывать интерфейсы с обязательными ролями и любым числом дополнительных.
  • Шаблон не определял приоритет. Несовместимость должен был разрешить PDP, а PEP обязан был отвергнуть оставшийся конфликт, не изобретая локальную смесь политик.

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

В архитектуре COPS-PR Policy Decision Point выбирал данные политики, а Policy Enforcement Point представлял устройство, которое должно было их принять. SPPI описывал классы и экземпляры Policy Information Base. RFC 3318 добавлял общие понятия ролей, наборов возможностей, версий состояния, ограничений и ошибок.

Роль была строкой, описывающей функцию интерфейса: finance, manager, магистраль, межсетевой экран. Один интерфейс мог иметь несколько ролей. Экземпляр политики содержал RoleCombination, и применимость зависела от сопоставления с набором интерфейса. Серверу не требовалось знать аппаратное имя каждого порта, а одинаковая политика могла передаваться один раз для нескольких интерфейсов.

Запись набора была строгой. Регистр имел значение, роли сортировались лексикографически по ASCII. a+b было допустимой формой; b+a не означало другой набор, а являлось неправильной записью того же набора. Отсутствию ролей соответствовал null. Каноническая форма не позволяла принять различие печати за различие смысла.

Звёздочка усиливала повторное использование. В классах install и install-notify выражение *+a+b соответствовало интерфейсу, включавшему a и b плюс ноль или больше других ролей. * нельзя было сообщать как реальную роль интерфейса и нельзя было вставлять внутрь имени. RFC приводил пример: *+b+e+g соответствовало a+b+c+e+f+g.

Если три интерфейса имели общие A и B, но дополнительно R1, R2 и R3, одна политика *+A+B охватывала все три. PDP не посылал три копии, а оператор прямо выражал общее условие.

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

RFC 3318 оставлял решение за PDP. Контроллер должен был попытаться устранить конфликт до отправки. Если несовместимые политики всё же приходили к PEP из-за ошибки PDP или особенности устройства, PEP обязан был отказать в установке и вернуть ошибку. Исполнение не получало скрытого права принимать решение.

Пример с финансами и руководителями уточнял границу. Сначала два интерфейса могли иметь finance, а третий — manager. После повышения сотрудника появлялась комбинация finance+manager. PDP мог отдать предпочтение политике руководителя или создать третью, например DSCP 7 для руководителя финансового подразделения. Даже если результат повторял прежнюю политику, PDP должен был явно загрузить его для новой комбинации.

PEP не разрешалось собирать ответ из двух старых политик. Иначе устройства разных производителей могли бы по-разному объединить одинаковые входы, а контроллер утратил бы возможность объяснить полномочия результата. Отказ оставляет проверяемую квитанцию неполного решения; молчаливое слияние выглядит успехом и скрывает перенос власти.

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

В переходный период решения ещё могли основываться на старых ролях. Новая метка не доказывала, что зависимые политики уже пересчитаны. RFC 3084 задавал цикл запроса, решения и отчёта; RFC 3159 — модель PIB. Назначение роли, принятие, обновлённое состояние, установка и обработка пакетов оставались разными свидетельствами.

Защита канала не решала смысловой спор. RFC 3318 предупреждал, что ошибочная конфигурация может иметь тяжёлые последствия. Аутентификация показывает отправителя, шифрование скрывает данные, но ни то ни другое не определяет, должна ли победить finance или manager.

В 2016 году IESG перевёл RFC 3318, COPS-PR и SPPI в Historic, указав на ограниченное внедрение и переход работ к NETCONF и YANG. Это не позволяет объявить механизм массовой практикой. Но урок сохраняется: шаблон уменьшает число правил, не отменяя обязанность назвать арбитра.

Источники: RFC 3318, RFC 3084, RFC 3159 и решение IESG 2016 года о смене статуса.