Summary

  • RFC 2979 отделил осознанный отказ по политике безопасности от случайного нарушения стандартного обмена; за последнее должны были отвечать брандмауэр и связанное с ним ПО.
  • Примеры с Path MTU Discovery и расширениями SMTP показали, как промежуточный узел способен прервать обмен, выполняя на вид простое правило.

Отказ по политике — не то же самое, что поломка протокола

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

RFC 2775 уже рассматривал «прозрачность» как несколько архитектурных свойств: сквозные функции, производительность и прозрачность адресов. RFC 2979 сузил вопрос до операционного обязательства. Внедрение брандмауэра, туннеля или согласования доступа не должно было случайно нарушать законное, соответствующее стандарту применение, которое работало бы без такого средства. Если сбой всё же возникал, исправлять следовало брандмауэр или связанное ПО, а не требовать изменения действующего протокола либо его реализации.

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

Отброшенный ICMP-ответ мог превратить корректный обмен в чёрную дыру

Пример Path MTU Discovery делал правило конкретным. Отправитель IPv4 мог установить бит Don't Fragment. Если следующий канал не вмещал пакет, маршрутизатор возвращал ICMP «Destination Unreachable / Fragmentation Needed», чтобы отправитель уменьшил размер. Если брандмауэр пропускал исходный пакет, но отбрасывал соответствующий ответ, отправитель мог продолжать повторять слишком крупные пакеты: получалась чёрная дыра, а не осмысленное решение о безопасности.

RFC 2979 не требовал пропускать весь ICMP. Он отличал ошибку в ответ на законный исходящий трафик от Echo, Redirect и несвязанных ошибок, которые сайт мог блокировать. Контекст важен: в одном семействе протоколов есть управляющие сообщения, необходимые корректному обмену, и трафик, который политика вправе отклонить.

Ответ на EHLO мог создать несогласованность между тремя сторонами

В SMTP клиент спрашивает о расширениях командой EHLO, сервер объявляет возможности, а клиент выбирает нужное расширение. Прокси, который лишь добавил EHLO в список разрешённых команд, но не фильтровал ответ сервера, мог позволить сторонам согласовать расширение, которого сам прокси не понимает. Каждый конец действовал правдоподобно, но посредник пропустил обмен, который не мог корректно передать.

Вывод не в том, что каждый брандмауэр обязан реализовать каждое новое расширение. RFC 2979 предлагал делать прикладные протоколы удобнее для прохождения через фильтры, если это не вредит приложению. Он также предостерегал от упаковки нового протокола в HTTP лишь потому, что порт 80, вероятно, открыт. Более честным выбором могут быть безопасное подмножество, подходящее средство прохождения или отдельный зарегистрированный порт.

Что показывает RFC и чего он не доказывает

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

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

RFC 3093 — соседний, но иной документ: информационная записка от 1 апреля 2001 года предлагала Firewall Enhancement Protocol для инкапсуляции IP/TCP внутри HTTP. Она не доказывает провал RFC 2979 или внедрение туннеля. Фильтрацию также нельзя смешивать с NAT: RFC 2979 прямо разделял эти функции, даже когда их выполняет одно устройство.

Источники: RFC 2979; RFC 2775; RFC 3093; история черновика; RFC 1191; RFC 1869.