Кратко

  • RFC 791 задал для типа 130 фиксированные одиннадцать октетов: уровень Security, Compartments, Handling Restrictions и Transmission Control Code; позднейшие RFC сохранили номер, но заменили структуру.
  • В RFC 1108 классификация и флаги Protection Authority стали входными данными политики отдельного интерфейса, а метка могла быть явной или неявной в зависимости от режима сети.
  • Хотя RFC 1108 получил статус Historic и такие пакеты обычно не должны встречаться в публичном Интернете, RFC 7126 предостерёг от удаления или отбрасывания по умолчанию: в закрытой MLS-сети это могло назначить данным неверную чувствительность.

Пустое место тоже принимает значение

Самое важное следствие сформулировано в RFC 7126. Если посредник удалит Basic Security Option, узел может отвергнуть пакет без требуемой метки. Но другой интерфейс разрешит немаркированный вход и подставит локально настроенную неявную классификацию.

Ошибка возможна в обе стороны. Завышенный уровень мешает законному использованию и переносит данные в более закрытую среду. Заниженный открывает их области, которой они не предназначались. Устройство не обезвредило средство аутентификации: оно заменило явный параметр политики неизвестным правилом получателя.

Тип 130 не шифрует полезную нагрузку, не подтверждает отправителя и не доказывает допуск. Это метка для доверенных компонентов. Её сила возникает из защищённого назначения, конфигурации и контроля границ, а не из самих битов.

Исходный формат объединял четыре вида контроля

RFC 791 определил Security как опцию типа 130 фиксированной длины одиннадцать октетов. За типом и длиной следовали 16 бит Security, 16 бит Compartments, 16 бит Handling Restrictions и 24 бита Transmission Control Code.

Security выбирал именованный уровень. Compartments разделял контролируемые категории. Handling Restrictions описывал ограничения обработки и распространения. TCC обозначал сообщества контролируемого интереса. Заголовок пытался не просто передать одну шкалу, а встроить несколько измерений внешнего режима обращения с информацией.

Бит копирования был установлен. Опция попадала в каждый фрагмент и могла присутствовать в датаграмме не более одного раза. Фрагментация IPv4 не должна была отделять часть содержимого от его контекста безопасности.

RFC 791 различал необязательное присутствие в конкретном пакете и обязательность реализации опций в IP-модулях. В некоторых средах Security могла требоваться в каждой датаграмме. Универсальный формат поддерживал правило, которое включалось только локальным режимом.

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

Номер сохранился, грамматика была заменена

В 1988 году RFC 1038 превратил тип 130 в Basic Security Option переменной длины. Фиксированные Compartments, Handling Restrictions и TCC уступили место уровню классификации и флагам Protection Authority.

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

RFC 1038 предполагал, что доверенные компоненты проверят право источника передавать данные, достаточность защиты маршрута и назначения и представят общую метку разным моделям контроля. Всё это зависело от аккредитованной инфраструктуры; наличие поля само доверие не создавало.

RFC 1108 объявил RFC 1038 устаревшим и описал Basic и Extended Security Options. Basic сохранил тип 130, но его минимальная длина стала равна трём октетам, если Protection Authority отсутствовал. Под одной цифрой скрылись последовательные форматы.

Коды нельзя было упорядочивать арифметически

RFC 1108 отвёл один октет под Classification Level. Допустимые разреженные битовые комбинации означали Top Secret, Secret, Confidential или Unclassified; другие значения таблицы оставались резервными. Числовой порядок байтов не совпадал с порядком чувствительности.

Программа не могла принять всё между кодами Confidential и Secret как промежуточный диапазон. Туда попали бы неназначенные комбинации. Сначала требовалось точное сопоставление с таблицей, затем применение заданной ею иерархии.

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

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

Флаги Authority ссылались на правила, а не выдавали права

После классификации RFC 1108 разрешал поле Protection Authority переменной длины. Семь старших битов каждого октета были флагами, младший сообщал о продолжении. К одной датаграмме могли относиться несколько authorities; минимальная реализация должна была обработать как минимум два октета флагов.

Они обозначали программы, правила защиты которых применялись к информации. Спецификация отдельно предупреждала: это не accreditation authorities. Флаг не сертифицировал узел, не аутентифицировал пользователя и не предоставлял допуск.

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

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

Каждый интерфейс становился рубежом классификации

RFC 1108 описывал общесистемные и «per-port» параметры. Port здесь означает сетевой интерфейс или присоединение, а не номер TCP либо UDP. Политика могла требовать BSO на передаче, приёме, в обоих направлениях или нигде.

Системы с классифицированными данными обычно должны были создавать явную опцию. Исключением служили выделенные и system-high сети: интерфейс мог присвоить каждому немаркированному пакету заранее установленную неявную метку. Если локальная политика допускала отсутствие поля, конфигурация восполняла контекст.

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

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

Пакет предлагал метку, интерфейс задавал допустимые пределы. Сетевой дамп без конфигурации интерфейса сохраняет только половину решения.

Ответ об ошибке тоже был политическим выбором

Если интерфейс требовал BSO, а пакет приходил без неё, RFC 1108 предусматривал ICMP Parameter Problem с Code 1 для отсутствующей обязательной опции. Повреждённая структура вызывала обычный parameter problem; некоторые запреты могли обозначаться как administratively prohibited.

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

Нельзя превращать этот частный случай в правило для любой отсутствующей IPv4-опции. Здесь молчание, ошибка и маркировка ответа сами являлись решениями системы допуска. ICMP показывает обязательность метки в конкретной среде, но не служит основным сюжетом.

Устарели старые варианты, а пересмотренный остался функцией маршрутизатора

RFC 1122 назвал опции безопасности из RFC 791 и RFC 1038 устаревшими. Для приложений DoD он направил разработчиков к пересмотренному документу, ставшему RFC 1108. Это не было утверждением, что все маркированные сети исчезли.

RFC 1812 сохранил различие. Он повторил оценку прежних форматов, но указал, что маршрутизаторам следует реализовать вариант RFC 1108. Устройства для нескольких уровней безопасности должны были уметь фильтровать IPSO-метки.

Каждому интерфейсу задавались нижняя и верхняя границы чувствительности. Пакет вне диапазона следовало молча отбросить и учесть счётчиком. Это не source routing и не перечень пути, а локальная проверка допуска на каждом рубеже.

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

Historic не означает отсутствие эксплуатации

RFC 7126 говорит, что такие опции обычно не должны встречаться в глобальном публичном Интернете. Там же отмечены частные MLS-сети, применявшие Basic и Extended Security Options на коммерческих и открытых системах. Документ допускал, что развёртывание MLS и IPSO могло вырасти после ухода со Standards Track.

Механизм может отступить из публичного стандарта и сохраниться внутри специализированного контура. Historic — статус RFC, а не измерение текущего трафика, не нулевой счётчик и не команда удалить регистрационное значение.

Одинаковый серийный маршрутизатор может попасть в обе среды. До настройки он не знает, является ли тип 130 мусором на публичной границе или обязательной меткой закрытой сети. Безопасное исходное поведение должно сохранить выбор администратора.

Сохранить — не значит поверить

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

Администратор среды, заведомо не использующей IPSO, может включить отбрасывание. Устройство должно вести счётчики BSO по интерфейсам и уметь фильтровать как по присутствию, так и по значениям. Открытый Интернет не обязан доверять секретным меткам; промежуточный узел лишь не должен уничтожать их смысл до решения локальной политики.

Передача без интерпретации не является признанием истинности. Она оставляет оценку тому домену, у которого есть MLS-правила и полномочия их применять.

Современный TCP сохранил условное примечание

RFC 9293 фиксирует неудобное наследие. Старые правила TCP учитывали IP security/compartment information при обработке соединений. К 2022 году RFC 1108 был Historic, однако RFC 791 так и не обновили для удаления Security Option.

Современная спецификация перенесла тему в примечания для реализации. Информация может оставаться важной для MLS и игнорироваться системами вне MLS. Явное разделение доменов честнее универсального поведения.

Документ также напоминает, что сброс соединения при несовпадении compartment или precedence рассматривался как возможный вектор атаки. Метка помогает контролировать допуск внутри корректной модели доверия, но становится поверхностью отказа, если старую межуровневую реакцию механически переносят в иной контекст.

Что действительно доказывает захваченный пакет

Тип 130 доказывает наличие байтов в исторически назначенном месте. Длина и внешний формат позволяют предположить применённую редакцию. Допустимый код и корректное поле authorities подтверждают структурное соответствие.

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

Отсутствие также не всегда означает Unclassified. Интерфейс с неявной маркировкой способен присвоить локальный уровень, которого нет в дампе. Пакет, отделённый от точки входа, теряет часть значения.

Главный урок типа 130 не в необходимости помещать безопасность в каждый заголовок. Удаление метаданных контроля — семантическое действие. Там, где поле участвует в mandatory access control, сохранить незнакомое значение может быть безопаснее, чем создать обманчивое отсутствие.

Источники и пределы доказательств

Закрытый набор состоит из RFC 791, RFC 1038, RFC 1108, RFC 1122, RFC 1812, RFC 7126 и RFC 9293. Они подтверждают форматы, обработку, историю статусов и условные советы по фильтрации. Они не раскрывают закрытые развёртывания, не измеряют современный трафик, не проверяют производителей и не удостоверяют правдивость конкретной метки.