Кратко

  • RFC 3360 описывает firewalls и load balancers, которые отвечали RST на ECN-setup SYN из-за ранее зарезервированных битов ECE/CWR, хотя endpoint мог вообще не получить пакет.
  • Успех обычного повторного SYN доказывает ограниченную доступность, но не автора первого reset, способность сервера, исправность пути или восстановление расширения.

В журнале осталось две строки: RST, затем connected. Автоматизация очистила ECE и CWR, повторила SYN и продолжила запрос. Авария исчезла из клиентского опыта — вместе с именем устройства, которое её создало.

RFC 3360 вышла в августе 2002 года как BCP 60. Её предмет — не современная статистика и не конкретный поставщик, а неправильное использование TCP reset для отказа пакетам с новыми флагами. Документ позволяет построить расследование так, чтобы успешный fallback не стирал причинный слой.

Reset — утверждение о connection state

RFC 793 применяла RST, когда сегмент явно не относится к текущему соединению или запрос приходит к несуществующему состоянию. Получатель прерывает соединение и уведомляет приложение. RFC 9293 сохранила отдельные правила generation и processing.

Поэтому reset имеет высокую операционную силу. Если посредник употребляет его в значении «не знаю этот bit» или «моя policy не разрешает функцию», клиент слышит другое: удалённая сторона отвергла connection.

RFC 2979 признаёт право firewall блокировать нежелательный доступ. RFC 3360 не отменяет это право. Она требует не путать локальный запрет с состоянием endpoint. Полностью закрытый port — иной случай; здесь устройство пропускает TCP, но уничтожает одну standards-compliant форму внутри TCP.

ECN выявила скрытого участника переговоров

RFC 3168 использует ECE и CWR из прежнего Reserved field. Клиент устанавливает оба в SYN. ECN-capable peer отвечает предусмотренным SYN-ACK, а старая реализация должна игнорировать неизвестные flags и продолжить обычный handshake.

Промежуточному узлу не требовалось понимать ECN. Требовалась терпимость к будущему значению. Некоторые устройства отвечали reset или silence. Историческая выборка RFC 3360 за март 2002 года содержит 203 reset и 420 drop среди 12 364 сайтов. Она не измеряет сегодняшний Интернет, но доказывает возможность третьей стороны отменить negotiation.

Client-side trace сохраняет форму ответа, но не custody. Корректный source address, ACK и быстрый RTT не подписывают пакет. Нужны capture по обе стороны контролируемого устройства, bypass, path comparison либо rule log, связанный с конкретной попыткой.

Fallback завершает транзакцию и обрывает расследование

После RST на ECN SYN реализация может послать SYN без ECE/CWR. Успех создаёт TCP без ECN. Второй reset уже должен завершить попытку.

Такой механизм полезен пользователю и опасен для учёта. Первый reset мог быть подлинным. Первый SYN мог просто потеряться. Сервер мог поддерживать ECN, но middlebox скрыл это. Retry мог пройти другим path. Ничего из этого не видно в финальном connected.

RFC 3360 перечисляет причины, по которым некоторые implementers не хотели workaround: игнорирование первого валидного reset, ошибочное выключение ECN после обычной потери, дополнительная задержка и фактическое принятие broken equipment.

RFC 7413 показывает аналогичный компромисс для TCP Fast Open: paths могут drop SYN data или неизвестные options, поэтому клиент возвращается к обычному handshake. Если telemetry хранит лишь final success, intolerance становится неразличимой.

Более строгая проверка RST не даёт provenance

RFC 5961 ввела challenge ACK для части reset в established state. Если sequence находится в окне, но не совпадает точно, соединение не закрывается немедленно; настоящий peer может подтвердить решение.

Это защита от blind injection, а не доказательство причины reset на initial SYN. RFC 5961 также описывает middleboxes, которые повторяют старый RST, создают ACK/RST loop или drop challenge после удаления собственного flow state.

Приемлемость sequence — один receipt. Автор packet — второй. Полномочие объявлять состояние удалённого peer — третий. Автоматическая root cause, построенная из первого, пропускает два звена.

Невидимый запрет становится постоянной нормой

RFC 3360 предупреждала, что intolerant boxes могут заморозить TCP. Стандарт назначает новое значение, но deployed paths не пропускают его. Разработчики endpoints выбирают reachability и отключают extension. Локальная ошибка превращается в общую спецификацию фактического развертывания.

RFC 6709 и RFC 9170 объясняют: extension point сохраняется активным использованием и обратной связью. Неизменные значения учат реализации принимать наблюдаемую подвыборку за весь protocol. RFC 8701 с GREASE намеренно вводит неизвестные TLS values, чтобы intolerance обнаружилась раньше. Это пример дисциплины, не универсальный рецепт для TCP.

Принцип Heng Lu о локализованном будущем решении позволяет различить полномочия. Оператор вправе отказаться от функции на своём участке. Но отказ должен оставаться видимым решением оператора. Если appliance изображает его как reset сервера, локальная policy становится мандатом для обеих сторон без review trail.

Как вернуть виновника в отчёт

Сохраняют исходный SYN: flags, options, addresses, время и ожидаемую capability. Каждой точке observation присваивают место относительно middlebox. RST проверяют формально, но не называют аутентифицированным.

Intentional rule получает owner, version, purpose, approval и expiry. Fallback хранит trigger — RST, timeout или manual test — и сведения о маршруте второго SYN. Сравнение без контроля path остаётся ограниченным.

После repair снова посылают extension-bearing SYN. Наблюдают его проход, receipt endpoint, negotiated mode, data transfer и independent application outcome. Software upgrade либо API success не заменяют этот тест.

Multipath требует независимых результатов. Один исправный egress не закрывает проблему на другом.

Границы вывода

Источники не доказывают текущую долю проблемных устройств, поведение названного vendor или реальный инцидент. Не каждый reset на ECN SYN неправилен. Firewall может иметь explicit policy против функции.

Plain handshake не доказывает отсутствие ECN у сервера. ECN negotiation не доказывает CE marking, feedback, sender response или application benefit.

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

Источники