Кратко

  • Проект CIPSO 1992 года помещал 32-битный идентификатор Domain of Interpretation перед тегами безопасности: числовые уровни и категории были осмысленны лишь для систем с общей таблицей соответствия.
  • Хосты и порты применяли настроенные диапазоны, а шлюзы на границе доменов должны были переводить опцию; корректное число само по себе не обладало универсальным авторитетом.

Короткая метка и локальный словарь

Commercial IP Security Option предназначалась для коммерческих многоуровневых систем с мандатным управлением доступом, которым не подходили ориентированные на Министерство обороны США пространства BSO и ESO. В IPv4 ей был назначен тип 134. Опция имела переменную длину, копировалась во фрагменты и могла присутствовать в датаграмме не более одного раза.

За однобайтовыми полями типа и общей длины следовал беззнаковый 32-битный Domain of Interpretation, или DOI, а затем теги. Значение DOI 0 резервировалось. DOI указывал на сообщество, чья таблица переводила компактные числовые уровни и категории в метки, понятные людям и механизмам политики.

Такая косвенная ссылка была существенной. В проекте приводился простой пример: независимые группы могли обозначить «Unclassified» числами 5 и 1. Без DOI число не показывало, какую таблицу применять. Орган DOI определял соответствие и распространял его внутри домена; если сама таблица была чувствительной, публиковать её вне домена не требовалось.

Остальные сведения переносили теги. Типы от 0 до 127 отводились стандартным форматам, предназначенным для публикации в RFC. Типы выше 127 мог определять орган DOI, но только для закрытых сетей, где внешняя совместимость не требовалась. Проект связывал три формата чувствительности MAC с конкретными номерами: тип 1 использовал битовую карту категорий, тип 2 — перечисление категорий по возрастанию, а тип 5 — непересекающиеся возрастающие диапазоны. Совместимая реализация должна была формировать обычный тег типа 1 и принимать любой допустимый тег типа 1, включая оптимизированную форму.

Настройка превращала значение в решение

Правильного синтаксиса было недостаточно. Многоуровневому хосту, шлюзу или маршрутизатору требовались минимальная и максимальная метки для системы либо интерфейса. Хост отбрасывал метку, на обработку которой не имел права; исходящий пакет за пределами допустимого для порта диапазона также отбрасывался. DOI исходящего трафика мог выбираться по порту, сети назначения или конечному хосту.

Ошибки разделялись по смыслу. Неизвестное поле CIPSO приводило к отбрасыванию и ответу ICMP Parameter Problem. Синтаксически допустимая метка вне настроенного диапазона приводила к отбрасыванию и ICMP Destination Unreachable с административным запретом. Администратор мог явно признать отдельные неизвестные типы тегов безопасными для игнорирования, но это было исключением из правила отказа.

Даже отсутствие опции требовало политики. Принимающий порт мог назначить собственную метку немаркированному трафику — например, в одноуровневой сети или сегменте, где все немаркированные хосты работали на одном уровне. Если CIPSO была обязательна, пакет без неё следовало отбросить и отправить ICMP Parameter Problem с указанием на отсутствующую опцию типа 134.

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

Проект, который не стал RFC

CIPSO 2.2 остался просроченным Internet-Draft и не стал RFC. Позднее NIST стандартизировал этот подход как FIPS 188: стандарт вышел в 1994 году и был отозван в 2015-м. RFC 7126 в 2014 году отмечал, что CIPSO реализована в нескольких операционных системах с многоуровневой безопасностью и применяется в некоторых сетях высокой секретности. Это датированные наблюдения, а не доказательство современного распространения.

RFC 7126 также объяснял риск безусловной фильтрации. Удаление CIPSO могло заставить получателя отвергнуть пакет как неверно маркированный или, что хуже, связать данные с неправильным уровнем чувствительности. Поэтому по умолчанию рекомендовалось не удалять и не отбрасывать пакет лишь из-за присутствия CIPSO. При этом сохранялась возможность настроить отбрасывание по факту наличия опции и вести счётчики аудита для интерфейсов.

Долговечный урок заключён в DOI. Числовые метки экономят место в пакете, но не создают общей семантики. Она находится в таблице полномочного органа, в настройках каждой системы и в переводе на границе.

Источники