Кратко

  • RFC 2367 определил привилегированный socket API между приложением управления ключами и локальным Key Engine; ответ свидетельствует только об этой границе.
  • SADB_GET, SADB_DUMP и состояния LARVAL, MATURE, DYING, DEAD описывают локальную запись, а не полномочия пира, действующую политику или использование пакетом.
  • Надёжный вывод связывает процесс, транзакцию PF_KEY, хранение ключа, удалённое согласование, SPD, обработку AH/ESP, приём и результат приложения.

Концептуальная схема разводит три пути. Демон управления ключами обращается по PF_KEY к локальному Key Engine, по PF_INET или PF_INET6 — к удалённому управляющему субъекту, а IPsec в ядре получает SA через отдельный внутренний интерфейс. Успех первого пути не наблюдает два остальных.

SADB_ADD устанавливает полную SA. В двухшаговой схеме SADB_GETSPI резервирует SPI, а SADB_UPDATE дополняет параметры. SADB_GET возвращает локальную копию; ACQUIRE просит создать состояние, EXPIRE сообщает о сроке, DELETE и FLUSH удаляют записи. Это точная локальная поверхность управления, но не двусторонний итог.

«Зрелость» относится к записи

LARVAL следует за GETSPI, MATURE — за ADD или UPDATE, DYING и DEAD — за мягким и жёстким пределами. Эти слова не показывают, установил ли пир обратную SA, прошёл ли нужный идентификатор аутентификацию и авторизацию, выбрал ли пакет эту запись.

SPI — координата поиска, а не удостоверение. Номер алгоритма — настройка, а не доказательство сохранности ключа или выполненной операции. Lifetime — локальный счётчик. Ноль может прямо означать отсутствие аутентификации или шифрования. Заполненная строка не равна выполненной услуге.

SADB_DUMP создаёт иллюзию полноты: он выдаёт локальную Key Table и завершает транзакцию маркером. Но RFC называет его средством отладки и запрещает приложениям зависеть от него в обычной работе. Доставка PF_KEY-сообщений также не гарантируется при переполнении буферов. Снимок может быть точным локально, неполным во времени и уже не совпадать с пиром.

Сначала установить автора состояния

Raw socket предназначался доверенным привилегированным процессам. Ручной интерфейс широко управляет локальными SAs. RFC предупреждает: если непривилегированный пользователь может создавать, читать, менять или удалять записи, ОС не способна обеспечить соответствующую безопасность.

Поэтому аудит начинается с процесса, binary, поколения конфигурации, решения оператора и фактических прав. Происхождение и защита ключа фиксируются без публикации секрета. В UPDATE-ответе keying material не возвращается слушателям, потому что право видеть состояние не означает право читать ключ.

За API остаются политика и трафик

RFC 4301 заставляет SPD выбирать BYPASS, DISCARD или PROTECT. Запись SAD может пережить изменение породившей её SPD, а ручная SA может не иметь соответствующей политики. Наличие не доказывает применимость.

RFC 7296 относит к IKEv2 аутентификацию идентичности, авторизацию PAD, Traffic Selectors и направленные Child SAs. При потерях стороны могут временно расходиться в состоянии. Локальный MATURE не восстанавливает эти решения.

RFC 4303 применяет ESP к каждому пакету. Выбранные услуги, исходящее преобразование и входная проверка — отдельные события. Затем остаются forwarding, удалённый приём, транспорт и приложение.

Защищаемая запись связывает привилегированный процесс, PF_KEY request/reply, поколения SAD и SPD, защищённое происхождение ключа, аутентифицированное и разрешённое удалённое согласование, совпадение потока, результат AH/ESP, наблюдение на другой стороне и ответ приложения. Пропуск не заполняется догадкой.

Источники