Кратко

  • RFC 5191 связывает lifetime PANA-сессии с текущим сроком авторизации. Это граница разрешения и управляющего состояния, а не измеренный интервал бесперебойной передачи пакетов или работы приложения.
  • Правило EP, IP lease, PANA SA, отдельная data-plane SA и наблюдаемый сервис могут иметь разные сроки и причины окончания. Их расхождение нужно хранить как доказательство, а не выравнивать в интерфейсе.

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

RFC 5191 определяет PANA как нижний уровень EAP поверх UDP. PaC и PAA создают сессию, выполняют аутентификацию и получают решение об авторизации. При PANA_SUCCESS последний PANA-Auth-Request несёт Session-Lifetime. PaC должен начать re-authentication до истечения, если хочет продлить сессию.

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

Семь часов в одной колонке

В реальной модели рядом существуют как минимум несколько часов. Authorization lifetime ограничивает право. PANA session lifetime управляет сессией. Lifetime PANA SA ограничивает ключ сигнализации. IP lease определяет адрес. Правило EP может иметь собственный timeout. Data SA имеет срок ключей. Наконец, service interval возникает только из наблюдений пути и приложения.

Они могут совпасть по проекту, но совпадение надо проверять. Если база копирует Session-Lifetime во все поля, она создаёт синхронность данных, которой может не быть в сети.

Для каждого таймера нужны источник, начальный момент, ожидаемое окончание, механизм продления, фактическое удаление и последний положительный readback. Тогда потеря правила через семь минут не спорит с часовой авторизацией: разрешение ещё действительно, его projection уже отсутствует.

Расхождение — не косметический дефект. Это точное место отказа.

EAP Success ещё не даёт разрешение

Даже первый lifetime появляется только после отдельного решения. RFC 5191 описывает случай, когда EAP выдаёт Success, но AAA или PAA локально отклоняет сетевую авторизацию. Последний обмен несёт PANA_AUTHORIZATION_REJECTED, после чего сессия прекращается.

Успешная проверка identity не задаёт срок доступа. MSK может существовать, а финальные сообщения могут быть защищены AUTH; защищённый отказ остаётся отказом.

Evidence object хранит EAP method, peer, результат и экспортированный material отдельно от authorization result, decision source, service scope, lifetime и причины. Иначе система может создать час «доступа» для клиента, которому сеть его никогда не разрешала.

Точное разделение также определяет владельца инцидента. Корректные credentials и policy reject требуют работы с политикой, а не с сертификатом.

Complete завершает PANA, но не выполняет EP

Финальный обмен с Complete bit закрывает фазу аутентификации и авторизации между PaC и PAA. При key-generating EAP Key-Id и AUTH защищают этот обмен.

Enforcement Point применяет per-packet filters и может быть отдельным узлом. RFC 5191 оставляет PAA-to-EP protocol и создание фильтров вне PANA, хотя требует защищать provisioning от подделки, изменения и replay.

Положительный PANA результат поэтому не является чтением таблицы EP. Для proof нужны target EP set, policy version, привязка PaC/interface, transaction, ack, installed fingerprint и timestamp. При нескольких EP успех — набор состояний, а не один флаг.

Если правило исчезло до истечения PANA lifetime, следует показать «authorization active / EP projection missing». Продолжать рисовать общий зелёный до часа — значит позволить одному control plane говорить от имени другого.

Адрес может измениться после успеха

После успешной аутентификации и авторизации PaC иногда должен перенастроить IP-адрес. PAA ставит IP Reconfiguration bit, потому что адрес, использованный для PANA, может не подходить для data traffic через EP. Метод перенастройки вне RFC 5191.

У нового lease собственный срок. Он может закончиться раньше PANA, измениться при mobility или не получить route. EP может продолжать связывать правило со старым tuple.

Нужно хранить pre-auth address, interface, reconfiguration instruction, новый lease и источник, neighbor/route, обновление EP и первый пакет. Поле current IP не должно стирать старое состояние.

Только такая линия показывает, закончилась ли услуга из-за permission, address, routing или filter.

PANA SA не обещает защиту данных

Когда EAP экспортирует MSK, PANA создаёт Security Association и выводит PANA_AUTH_KEY. AUTH защищает header и payload PANA, включая переносимый EAP message. Это аутентификация и целостность управляющего трафика PaC–PAA.

Per-packet ciphering отделён. Из PANA SA можно получить material и использовать link-layer или IPsec secure association, но способ создания и применения находится вне документа.

PANA SA lifetime не доказывает, что data SA существовала тот же час. Для control SA нужны Session ID, Key-Id, verification и lifetime. Для data SA — endpoints, selectors, algorithms, install state, counters и expiry. Derivation связывает их, но не позволяет подменять одно другим.

Если нижний уровень уже защищает данные, policy должна сказать это явно. Отсутствие второй SA без контекста не является доказательством.

Ping доказывает жизнь peer

В access phase PANA Notification Request/Answer с Ping bit может проверять liveness. Валидный ответ на недавний request показывает, что PANA peer жив.

Он не читает отдельный EP, не проходит application path и не доказывает текущий data-plane filter. PAA может отвечать после потери правила. И наоборот, периодический keepalive может пострадать от congestion и создать ложную тревогу, хотя данные ещё проходят; RFC предупреждает об этом риске.

Метрика обязана называть объект: «PAA ответил в T». Service availability требует packet observation и application transaction. Продолжительность успешных Ping не может заменить продолжительность услуги.

Нижний сигнал — подсказка, не общий приговор

PaC и PAA могут использовать информацию вне PANA, например lower-layer indication, чтобы быстрее заметить disconnect. RFC указывает, что доступность и надёжность такой информации зависят от link layer и topology. Это hint, который при необходимости проверяется PANA Ping.

Link-down может быть точным для одной interface и ничего не сказать о другой. Session не может совместно использоваться несколькими interfaces, поэтому interface identity должна оставаться в записи.

Перенос внешнего сигнала на весь сервис создаёт ту же ошибку, что перенос Session-Lifetime на uptime. Источник наблюдает конкретную поверхность и не получает универсальную власть от удобства.

Termination и фактическое удаление

PaC или PAA может завершить сессию раньше срока. Ожидается удаление PANA state, остановка accounting и снятие per-PaC state с EPs. В разделённой архитектуре защищённое termination message — корректная команда, а не post-delete readback каждого исполнителя.

Оставшийся allow расширяет доступ, оставшийся deny ломает новую сессию. Receipt хранит cause, protected exchange, accounting close, target EPs, delete acks и queries после удаления.

Expiration также не должна автоматически означать наблюдаемую очистку. Ожидаемый deadline и фактическое исчезновение правила — разные timestamps. Их разность показывает lag или failure.

Audit ledger должен жить дольше эфемерной сессии, иначе orphan rule потеряет происхождение сразу после удаления объекта PAA.

Discovery не устанавливает авторитет

RFC 5192 задаёт DHCP options для адресов PAA, а RFC 6345 — Relay Element. Эти механизмы помогают найти destination. Они не аутентифицируют его заранее.

Сохраняются DHCP server, option, lease, interface и relay, затем они связываются с проверенной PANA/EAP session. Неверный discovery, отказ identity, authorization reject и EP timeout могут выглядеть как одно «нет сети», но имеют разные часы и владельцев.

Найденный адрес — кандидат для начала протокола, не готовый receipt доверия.

Временная линия вместо обещания

Операционный объект начинается с PaC, interface, discovery source и requested service. Каждое PANA message получает Session ID, sequence, retransmission и validation. EAP result и authorization decision не смешиваются.

Финал хранит Result-Code, Complete, Key-Id, AUTH и granted lifetime. Address transition добавляется отдельными событиями. Затем идут projection и readback каждого EP, data SA при необходимости, packet capture, remote receipt и application outcome.

Вместо «доступен до 14:00» система может сказать: «разрешён до 14:00; правило EP подтверждено до 13:07; после этого packet evidence отсутствует». Это менее гладко и гораздо полезнее.

Принцип Heng Lu о слоях реальности требует именно такой дисциплины: число из нормативного control record не получает власть над физическим исполнением, которого оно не наблюдало.

Источники

  1. RFC 5191 HTML
  2. RFC 5191 текст
  3. Запись RFC 5191
  4. Datatracker RFC 5191
  5. История RFC 5191
  6. Ссылки RFC 5191
  7. Errata RFC 5191
  8. RFC 5192
  9. Запись RFC 5192
  10. RFC 5193
  11. Запись RFC 5193
  12. RFC 4058
  13. RFC 4016
  14. RFC 3748
  15. RFC 4137
  16. RFC 5247
  17. RFC 6345
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy