Кратко

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

Схема RFC 2411 выглядит законченной. Вверху — архитектура. Ниже — ESP и AH. По сторонам — шифрование и аутентификация. В центре — Domain of Interpretation, снизу — управление ключами. Стрелки связывают все блоки.

Именно ощущение законченности требует осторожности.

К ноябрю 1998 года IPsec уже нельзя было определить одной публикацией. Новые алгоритмы должны были появляться и после выхода базовых RFC. Если вся архитектура менялась бы при каждом добавлении, общий слой утратил бы стабильность. Если же каждый автор заново пересказывал бы ESP, AH, ключи и номера, одинаковое правило получило бы множество копий.

Копии стареют независимо. В одной остается прежнее значение, в другой исчезает предупреждение, в третьей меняется трактовка заполнения. Два продукта могут честно ссылаться на RFC и при этом собирать разные протоколы.

RFC 2411 называл этот риск «взрывом черновиков». Решением стала не единая книга со всеми деталями, а дисциплина владения правилами.

Архитектура отвечала за общие понятия, требования безопасности и системные механизмы. ESP и AH — за форматы пакетов и общее поведение. Документ алгоритма шифрования — за применение конкретного преобразования в ESP. Единый документ аутентификации мог описывать один и тот же механизм для ESP и AH. DOI содержал известные значения, через которые части ссылались друг на друга. Документы управления ключами отвечали за создание и сопровождение ключевого материала.

Эта схема не давала верхнему блоку абсолютную власть. Номер в DOI однозначно называл алгоритм, но не делал его безопасным. Roadmap указывал на ESP, но не заменял его спецификацию. Полномочие каждого источника заканчивалось на своей границе.

Раздел о ключах показывает, зачем это было нужно. Механизм управления должен выработать материал достаточной длины и стойкости. Но длина конкретного ключа, порядок компонентов, биты четности и обработка слабых значений принадлежат документу алгоритма. Иначе управление ключами пришлось бы переписывать при каждом новом преобразовании.

Архитектура описывала извлечение нескольких ключей из общего блока, когда ESP сочетал конфиденциальность и аутентификацию. Но место операции оставалось за реализацией. Материал мог быть разделен процессом управления до передачи в ядро, либо ядро могло получить весь блок и выполнить «slicing and dicing» самостоятельно.

Общий результат был обязателен. Внутренняя граница процессов — нет.

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

С необязательными параметрами RFC 2411, напротив, советовал сокращать свободу, если разумное фиксированное значение существовало. Каждый новый вариант умножает предложения и ветви кода. Две реализации могут поддерживать множество допустимых опций и не иметь ни одной общей рабочей комбинации.

Если параметр должен оставаться на выбор, документ обязан объяснить причину, задать значения по умолчанию или диапазон и описать влияние на формат и обработку. Слово «настраивается» не создает совместимость без проверяемых границ.

Рекомендованная структура документов была практически ориентирована: минимальные, максимальные и рекомендуемые размеры ключей; источник случайности; слабые ключи; обновление; производительность; формат полей; заполнение; взаимодействие с другими алгоритмами; известные атаки; ошибки реализации; проверка и тестовые векторы.

RFC 2411 не выполнял этих проверок. Он требовал, чтобы ближайший к механизму документ позволял их выполнить.

Поэтому карту нельзя превращать в квитанцию о соответствии. Наличие алгоритма в схеме подтверждает распределение ответственности. Запись IANA подтверждает общее имя. Спецификация продукта подтверждает заявление поставщика. Журнал IKE может подтвердить выбранное предложение. Ни один из этих фактов не доказывает сам по себе, что оба ядра установили правильные SA, что пакет прошел проверку и что приложение получило ожидаемый результат.

Карта, исходное правило, реализация, согласование, установка, пакет и результат — разные слои доказательств.

RFC 2411 честно ограничивал себя. Он был Informational и не определял стандарт Интернета. За процедурами безопасности он направлял к архитектуре, ESP, AH и документам алгоритмов. Даже замечание о том, что многие шифры небезопасны без аутентификации, не было сертификатом развернутой системы.

В 2011 году RFC 6071 объявил первую карту устаревшей. Множество текстов IPsec и IKE разрослось по исходной рабочей группе, ее наследникам и другим протоколам. Новый документ назвал себя снимком. Уровни требований отражали февраль 2011 года, более поздние RFC могли их изменить, а при конфликте приоритет имел другой, исходный RFC.

Надежное резюме сообщает, где кончается его собственная власть.

RFC 6071 одновременно зафиксировал расхождение между документами и установленным парком. Новый IPsec заменил старый, но старый оставался распространен. IKEv2 заменил IKEv1, однако IKEv1 продолжал работать. Статус Obsolete изменяет граф публикаций, а не удаляет код. Наличие старого кода описывает инвентарь, но не возвращает старой технологии рекомендацию.

Изменилась и структура карты. Комбинированные режимы получили отдельную группу. Обязательные алгоритмы вынесли в самостоятельные документы, чтобы криптографические требования менялись быстрее формата пакета. IKEv2 объединил содержание, которое IKEv1 распределял между ISAKMP, Oakley и DOI и иногда описывал противоречиво.

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

RFC 8221 продолжает этот подход. Требования к алгоритмам и рекомендации по использованию должны обновляться, потому что меняются атаки, аппаратные платформы и доступные методы. Реестр IANA сохраняет однозначные номера, но регистрация не означает рекомендацию, включение или выбор. RFC 9395 позднее вывел из употребления IKEv1 и старые алгоритмы, не уничтожая историческую запись об их существовании.

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

Но ни одна стрелка на схеме не установила SA. Публикация только открывала возможность. Код должен был принять правило, два узла — найти совместимый выбор, обе системы — установить состояние, а пакеты — показать фактическое поведение.

RFC 2411 разложил правила по документам. Состояние сети осталось за пределами схемы.

Источники