Кратко

  • Группа появляется с первым policy rule и исчезает с последним. Её lifetime связан с участниками, однако RESERVED и ENABLED сохраняют разный смысл и разное влияние на пакеты.
  • GLC может назначить общий срок или удалить всех участников, но групповой успех не показывает прохождение пакета, удалённый приём или результат приложения.

Оператор продлил группу и решил, что продлил открытый путь. В ней действительно осталось ENABLED-правило, но рядом жила PRR, которая никогда не меняла packet processing. Одна операция времени не сделала действия одинаковыми.

RFC 5189 задаёт семантику управления NAT и firewall. Она не описывает конкретный wire protocol, зато фиксирует минимальные состояния, права и переходы. Именно эти различия теряются, когда группа превращается в одну строку.

Участник RESERVED удерживает возможность

Policy Reserve Rule заранее удерживает адрес или диапазон портов. Это нужно, когда полный flow ещё неизвестен. В зависимости от middlebox резерв бывает внешним, внутренним и внешним либо пустым.

PRR не создаёт binding и не открывает pinhole. Обработка пакетов не меняется. Чистый firewall может успешно вернуть пустые tuples и всё равно перевести rule ID в RESERVED.

Значит, участник группы со статусом RESERVED потребляет ресурс или фиксирует семантическую бронь, но не разрешает трафик. Зелёный group status не вправе повышать его до ENABLED.

Receipt должен сохранить capability, interfaces, protocol, range, parity, A0 и возвращённые A1/A2, включая пустые значения, а также requested и granted lifetime.

Участник ENABLED меняет локальное решение

Policy Enable Rule создаёт NAT bindings, firewall allow actions или оба типа конфигурации. Она может заменить PRR либо появиться напрямую.

При замене сохраняется rule ID, но состояние и действие меняются. История должна показать время RESERVED → ENABLED; текущий снимок не доказывает, что путь был открыт с момента первого появления ID.

Если PER завершается ошибкой, PRR остаётся. В одной группе может сохраняться бронь после неудачной активации. Автоматическое удаление записи по failed status скроет занятый ресурс.

Успешная PER подтверждает локальное правило. Другая ACL, route, host, listener или application могут отклонить обмен. Packet captures по обе стороны и endpoint receipt нужны отдельно.

Группа существует только через участников

Каждый policy rule принадлежит ровно одной группе. Все участники имеют общего owner. Группа не хранит независимую вечную сущность: создаётся с первым правилом и прекращается после последнего.

До группового изменения её lifetime равен максимуму lifetimes участников. Поэтому одно число может описывать момент исчезновения группы, но не доказывает, что каждый member живёт столько же.

GLC может запросить общий срок для всех участников. При успехе middlebox выбирает значение в пределах запроса и session maximum. GLC с нулём прекращает все правила и саму группу.

Одинаковая команда имеет разные последствия. Удаление RESERVED освобождает ресурс. Удаление ENABLED меняет packet processing. Для оценки воздействия нужны member list, state, action, granted lifetime и последняя причина изменения.

Owner переживает соединение

Создавший rule authenticated agent остаётся owner на весь срок. Другой agent может действовать только по локально выданному праву. Group owner выводится из владельцев участников и не меняется от того, кто сейчас подключён.

Завершение MIDCOM session не уничтожает установленные правила. После обычного закрытия, асинхронного события или разрыва соединения они остаются до expiry или отдельной termination.

Группа может поэтому пережить controller session. Инвентарь должен хранить первоначального owner, запрос, granted lifetime и события вне краткого журнала соединения.

Время предоставляет устройство

Agent предлагает lifetime, middlebox выдаёт не больше запроса и объявленного максимума. Requested не является договором. Remaining lifetime — ещё одно наблюдение с собственной отметкой времени.

RLC может продлить, сократить или завершить rule нулём. GLC действует на всех members. Асинхронное событие может поступить из policy decision point или действия другого authorized agent.

Последний статус не объясняет последовательность. Нужны старое значение, requester, authorization, notification, granted value и подтверждённое состояние после изменения.

Atomic request не означает неизменный мир

Request transactions атомарны относительно друг друга и не показывают стабильный промежуточный state. Asynchronous transaction может прервать processing. Реализация, разбивающая одну semantic transaction, должна доказать собственную границу atomicity.

Конфликтующее новое правило отвергается по first-come-first-served, существующее остаётся. Неконфликтующие overlaps, включая идентичные правила, допускаются. Admission объясняет inventory, но не traffic.

Evidence object вместо общего индикатора

Начать с immutable change, session, agent, request и middlebox IDs; сохранить authentication, owner, capability, interfaces, transaction, rule, group и prior state.

Для PRR хранить tuple constraints и пустые ответы. Для PER — ссылку на резерв или direct path, direction, wildcard, bindings и pinholes. Для обоих — requested, maximum, granted, failure reason и судьбу резерва.

Status reads, REN, GEN и STN добавлять по порядку. Session end и rule end не объединять. Затем связать captures, remote receipt, application result, expiry и rollback.

Только такая цепочка позволяет сказать, какой member группы изменил реальность. Групповое число удобно для управления, но недостаточно для доказательства.

Источники

  1. RFC 5189 HTML
  2. RFC 5189 текст
  3. RFC 5189 информация
  4. Datatracker RFC 5189
  5. История RFC 5189
  6. Ссылки RFC 5189
  7. Errata RFC 5189
  8. RFC 3989
  9. RFC 3989 информация
  10. RFC 3303
  11. RFC 3303 информация
  12. RFC 3304
  13. RFC 3304 информация
  14. RFC 3198
  15. RFC 3234
  16. RFC 3022
  17. RFC 6887
  18. Heng Lu — слои реальности
  19. Heng Lu — минимальная спецификация
  20. Heng Lu — приоритет работающего кода