Кратко

  • RFC 2401 отделил упорядоченную базу политик безопасности от базы активных ассоциаций: первая решала, отбросить трафик, пропустить его без IPsec или защитить, а вторая хранила параметры односторонних логических соединений.
  • Ни правило, ни ассоциация не подтверждали судьбу конкретного пакета. На выходе требовалось реально применить AH или ESP; на входе после криптографической обработки следовало проверить, что использованные ассоциации и их порядок соответствуют подходящей политике.

База данных умеет хранить намерение и состояние. Она не умеет задним числом превратить их в событие. В RFC 2401 эта граница была встроена в саму архитектуру: запись SPD определяла требование, запись SAD описывала рабочую ассоциацию, а пакетный тракт должен был связать их наблюдаемым исполнением.

Документ вышел в ноябре 1998 года и свёл воедино архитектуру безопасности протокола IP для IPv4 и IPv6. Он описывал управление доступом, целостность без установления соединения, проверку источника данных, защиту от повтора, конфиденциальность и ограниченное сокрытие потока. Эти свойства не составляли единой неделимой услуги. AH, ESP, транспортный или туннельный режим, алгоритмы и управление ключами давали разные наборы утверждений.

Security Policy Database должна была охватывать весь входящий и исходящий IP-трафик, в том числе не использующий IPsec. Записи имели полный порядок и выбирались по адресам и полям верхних уровней. Совпадение вело к одному из трёх решений: отбросить, обойти IPsec или применить IPsec. Для защиты правило задавало протокол или связку протоколов, режим, алгоритмы и порядок вложения.

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

Security Association Database отвечала за другую плоскость. Ассоциация безопасности была simplex-соединением для одного направления; двусторонняя защита обычно требовала двух. Её идентифицировали Security Parameters Index, IP-адрес назначения и обозначение AH либо ESP. Запись могла включать алгоритмы и ключи, счётчик и состояние защиты от повтора, срок действия, режим и состояние MTU пути.

Это состояние необходимо, но не подтверждает использование. Наличие SAD-записи говорит, что ассоциация с такими параметрами существует. Оно не показывает, выбрал ли её конкретный пакет. Тем более оно не доказывает приём другой стороной, разрешение приложения или результат услуги. RFC 2367 открыл управление ключами и ассоциациями через PF_KEY; RFC 2401 поместил это состояние в более длинный договор обработки.

На выходе пакет сначала сопоставлялся с SPD. Решение discard останавливало путь. Bypass разрешал обычную передачу без IPsec. Правило защиты выбирало подходящую ассоциацию либо запускало создание нужной ассоциации или связки. Затем операции AH или ESP должны были реально выполниться в требуемом порядке до передачи или маршрутизации. Хранимое правило и активная ассоциация оставались предпосылками преобразования, а не самим преобразованием.

На входе адрес назначения, протокол безопасности и SPI выбирали ассоциацию. Обработка AH или ESP могла проверить целостность и источник, отсеять повтор и выполнить расшифрование там, где предусматривалась конфиденциальность. Криптографический успех всё ещё не был окончательным разрешением.

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

AH и ESP тоже не давали одинакового утверждения. Authentication Header 1998 года обеспечивал целостность и проверку источника, а также мог защищать от повтора, но не давал конфиденциальности. ESP мог давать конфиденциальность и необязательно аутентификацию с целостностью, причём область защиты отличалась. Фраза «IPsec зашифровал пакет» не описывала все допустимые пути; bypass прямо означал отсутствие защиты IPsec.

RFC 2401 признавал внешние зависимости: качество реализации, безопасность операционной системы, источники случайности и администрирование. RFC 3168 позже обновил обработку ECN. RFC 4301 заменил архитектуру в 2005 году и уточнил политику, селекторы, фрагменты и авторизацию узлов. Поэтому требования 1998 года нельзя выдавать за современную криптографическую рекомендацию.

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

Источники