Кратко

  • RFC 5193 описывает функциональную цепочку и две среды: защищённый PaC-to-EP канал уже существует до PANA либо его нужно создать после успешной аутентификации. Эти состояния определяют разные требования к EAP и secure-association protocol.
  • Итоговый зелёный флаг не должен превращать результат одной поверхности в доказательство остальных. Нужны отдельные квитанции среды, метода, ключевого материала, обязательства association, конкретного EP и наблюдаемой защиты текущего attachment.

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

RFC 5193 особенно плохо переносит одно поле secure. Документ не описывает один момент успеха. Он связывает PaC, PAA, Authentication Server и EP; показывает начальный доступ, PANA, backend AAA, provisioning, возможную реконфигурацию адреса, secure association и data traffic; затем различает среду до PANA.

Зелёный цвет может быть последним представлением этой цепочки. Он не может быть её единственным первичным фактом.

Три значения слова «успех»

Первое: EAP/PANA достигли своего результата. Второе: утверждение о нижнем канале действительно для текущего attachment. Третье: EP и, если нужно, security association обеспечивают требуемое обращение с пакетами.

Эти успехи могут расходиться. PANA может завершиться на канале, который не был заранее защищён. Нижний канал может быть защищён, пока PANA отклоняет доступ. EP может получить правило, но относиться к другому пути. Association может существовать с прежним peer после mobility.

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

Environment receipt предшествует протоколу

Для secure-before нужны attachment, interface, lower-layer peer или физический сегмент, EP, mechanism, защита от spoofing и eavesdropping, время и источник. Физическая изоляция и криптографическая защита имеют разные формы доказательства; обе ограничены своим путём.

Если этой квитанции нет, поле не должно становиться true из-за типа площадки, модели устройства, совместного размещения PAA/EP или наличия IPsec в списке возможностей. Все эти данные полезны, но отвечают на другие вопросы.

Версия решения нужна отдельно. Она показывает, какой receipt и какая policy позволили выбрать среду. После смены interface, peer, EP или topology старое решение остаётся историей, а не разрешением.

Выбор EAP — наблюдаемый эффект классификации

В среде без предварительной защиты RFC 5193 требует метод, устойчивый к relevant attacks и способный создать cryptographic keys для следующего протокола. Поэтому карточка метода должна ссылаться на environment decision.

Так можно увидеть два класса ошибки. Метод не соответствует открытому каналу, потому что профиль ошибочно объявил его защищённым. Или метод создал ключи, но обязательство на secure association не перешло в исполняемую задачу.

Сводный secure access скрывает оба случая. Первый зелёный результат закрывает карточку, а отсутствующий переход не порождает failure. Правильная цепочка хранит required/created/started/completed/observed как разные стадии.

Четыре функции не становятся одной властью

PAA взаимодействует с PaC и консультируется с Authentication Server. EP разрешает или блокирует data traffic. Функции могут быть colocated, но их факты не сливаются.

AAA result может доказать решение backend. API между PAA и EP может доказать передачу атрибутов. Lower layer может доказать состояние канала. Packet observation может доказать результат на пути. Значимость первого решения не даёт ему полномочий объявлять остальные.

Это соответствует принципу Lu Heng: символический слой полезен, пока не получает власть над реальностью, которую лишь описывает. Сводка — символический слой. Её задача направлять читателя к receipts, а не заменять их.

Статус должен быть вычислимым и разложимым

Публичная или операторская панель может оставить итог. Но рядом должна существовать трассировка: environment evidence, EAP selection/result, key output, association requirement/job/result, EP identity/policy и current-path observation.

Каждый компонент имеет состояние unknown, not-required, pending, failed, succeeded или stale в своей семантике. not-required обязательно хранит причину и receipt. Иначе отсутствие контроля выглядит так же, как обоснованное исключение.

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

Не смешивать эту границу с RFC 5191

Сохранённая статья RFC 5191 уже объясняет, почему authentication не равна authorization, PANA completion не равен состоянию каждого EP, а защита signaling не равна защите data plane. Здесь вопрос другой: какой environmental claim до PANA заставил систему потребовать или исключить последующие шаги?

Такое ограничение предотвращает повтор. RFC 5193 даёт самостоятельный управленческий объект — классификацию deployment environment и её влияние на method/association design. Именно он исчезает первым, когда интерфейс показывает только конечный зелёный цвет.

Минимальный проверяемый отчёт

Отчёт должен сказать: attachment X получил environment decision Y из evidence Z; выбран метод M; ожидался key result K; association была required или not-required с причиной; job J относилась к EP E; наблюдение O относится к текущему path version.

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

Sources

  1. RFC 5193 HTML
  2. RFC 5193 текст
  3. Карточка RFC 5193
  4. Datatracker RFC 5193
  5. История RFC 5193
  6. Ссылки RFC 5193
  7. Errata RFC 5193
  8. RFC 5191
  9. Карточка RFC 5191
  10. RFC 4058
  11. Карточка RFC 4058
  12. RFC 4016
  13. RFC 3748
  14. RFC 4306
  15. RFC 2409
  16. RFC 2865
  17. RFC 3588
  18. Heng Lu — слои реальности
  19. Heng Lu — минимальная начальная спецификация
  20. Heng Lu — приоритет работающего кода