Кратко

  • RFC 2989 оценивал возможности предложений AAA; обязательная возможность не обязана была использоваться в каждом обмене.
  • Отдельные столбцы NASREQ, ROAMOPS и Mobile IP сохраняли различия требований вместо единой политики эксплуатации.
  • Транспортное подтверждение, синтаксическое принятие, смысловое решение, ответственность за учёт, исполнение авторизации и услуга были разными квитанциями.

Юрисдикция таблицы

RFC 2989 не определял новый протокол AAA. Информационный RFC собрал требования NASREQ, ROAMOPS, MOBILEIP и TIA 45.6, чтобы сравнивать кандидатов.

Общие таблицы, а также разделы аутентификации, авторизации, учёта и Mobile IP сохраняли столбцы источников. M, S, O, N и B обозначали MUST, SHOULD, MAY, MUST NOT и SHOULD NOT. Единая форма позволяла сравнивать, а раздельные столбцы не давали выдать разные контексты за одну политику.

Раздел 1.1 задал предел: нормативные слова относились к возможностям протокола. Предложение, нарушавшее MUST для реализуемой возможности, не соответствовало требованиям. Выполнение обязательных, но не всех рекомендованных пунктов означало условное соответствие; выполнение рекомендаций — безусловное.

Это оценки предложения, а не наблюдения за установкой.

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

MUST не телеметрия

RFC 2119 усиливает обязанность внутри заданного предмета. Он не превращает требование к дизайну в отчёт о каждом пакете.

Масштабируемость была обязательной в трёх средах. Переключение на резервный сервер явно требовалось NASREQ и Mobile IP. IPv4 был общим MUST; вес IPv6, перевозки сертификатов и аудируемости различался. Пустая ячейка не означала запрет. M не сообщала о срабатывании функции.

Поздняя подмена удобна: соответствие протокола становится гарантией продукта, гарантия — предполагаемой конфигурацией, соединение — оказанной услугой. Каждый переход требует нового наблюдения.

Минимальная начальная спецификация координирует сравнение, не присваивая будущие локальные решения.

Защита перехода и защита объекта

Транспортная безопасность действовала между соседними узлами. Пары AAA могли аутентифицировать друг друга, защищать целостность и шифровать канал. После обработки принимающей сущностью эта оболочка снималась. Следующему переходу требовалась новая связь.

Конфиденциальность объекта могла оставить атрибуты доступными только конечной цели даже через прокси. Аутентификация и целостность объекта должны были сохраняться по цепочке; промежуточный сервер не мог менять покрытые данные.

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

Доставка раньше смысла

Надёжный транспорт AAA включал повтор и failover по переходам, управление повтором приложением AAA, своевременные ответы и подтверждения.

RFC 2989 назвал транспортное подтверждение успешной доставки сообщения и явно отделил его от оценки синтаксиса или семантики.

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

Поэтому журнал должен раздельно хранить попытку, переход, повтор, выбранный резерв, доставку, разбор, решение и действие NAS. Один статус «успех» скрывает границу отказа.

Учёт принимал ответственность

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

Это сильнее прибытия, но не доказывает постоянное хранение, репликацию, сверку, тарификацию, счёт или оплату. RFC 2989 отделял accounting — сбор сведений об использовании — от billing, подготовки счёта.

Динамическая повторная авторизация могла создавать несколько записей на сеанс. Принятие ответственности закрывало один этап, не всю цепь.

Аудируемость не равна правоте

Аудируемый процесс позволял определённо установить действия над пакетами AAA на пути от домашнего сервера к сетевому устройству и обратно.

Локальный прокси мог применять политику. Прозрачный не должен был добавлять, удалять или менять сведения. Proxy broker оставался на пути, routing broker мог вернуть данные для прямой связи.

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

Три A — три полномочия

Аутентификация проверяла заявленную личность. Авторизация решала право. Учёт собирал использование. RFC требовал также авторизацию без обязательного повторного предъявления пользовательских credentials — по идентификации или assertion. Это не делало утверждение самодоказательным; его основание могло находиться в другой связи.

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

Сохранённая граница

Возможность не была включением. Доставка — пониманием. Ответственность — счётом. Аудит — правильностью. Авторизация — оказанным доступом.

Слои реальности Lu Heng выстраивают требование, RFC, возможность, реализацию, настройку, сообщение, посредника, решение, эффект устройства и результат. Истина раннего слоя не даёт ему права говорить за поздний.

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

Таблица оценивала кандидата. Сеть всё ещё должна была предъявить квитанции.

Источники