Inappropriate TCP Resets Considered Harmful
RFC 3360 рассматривает практику, при которой межсетевые экраны, балансировщики нагрузки или веб-серверы отвечают TCP Reset на TCP SYN-пакеты с установленными флагами зарезервированного поля заголовка TCP, в частности при согласовании ECN. Документ утверждает, что такой ответ не соответствует стандартам TCP и размывает семантику TCP Reset. Он отмечает, что сброс либо отбрасывание таких пакетов препятствуют внедрению ECN и могут ограничить дальнейшее развитие TCP и интернет-инфраструктуры. В качестве временного обходного пути для ECN допускается повторить SYN с очищенными CWR и ECE, однако это ухудшает ясность значения сброса и может снижать функциональность.
Рабочая группа по сети S. Floyd
Запрос комментариев: 3360 ICIR
BCP: 60 Август 2002
Категория: Лучшая современная практика
Ненадлежащие сбросы TCP считаются вредными
Статус этого меморандума
Этот документ определяет Лучшую современную практику Интернета для
Интернет-сообщества и запрашивает обсуждение и предложения по
улучшению. Распространение этого меморандума не ограничено.
Уведомление об авторских правах
Copyright (C) The Internet Society (2002). Все права защищены.
Аннотация
Этот документ написан потому, что в Интернете имеется ряд
межсетевых экранов, которые ненадлежащим образом сбрасывают TCP-соединение
при получении определённых TCP SYN-пакетов, в частности пакетов с
установленными флагами в поле Reserved заголовка TCP. В этом документе
мы утверждаем, что такая практика не соответствует стандартам TCP и
является ненадлежащей перегрузкой семантики сброса TCP.
Мы также рассматриваем долгосрочные последствия этого и сходных
действий как препятствия для развития инфраструктуры Интернета.
1. Введение
TCP использует бит RST (Reset) в заголовке TCP для сброса TCP-
соединения. Например, сбросы надлежащим образом отправляются в ответ на
запрос соединения для несуществующего соединения. Получатель сброса TCP
прерывает TCP-соединение и уведомляет приложение [RFC793, RFC1122, Ste94].
К сожалению, ряд межсетевых экранов и балансировщиков нагрузки в
современном Интернете отправляют сброс в ответ на TCP SYN-пакет,
использующий флаги из поля Reserved заголовка TCP. В разделе 3 ниже
рассматривается конкретный пример межсетевых экранов, отправляющих сбросы
в ответ на TCP SYN-пакеты от узлов с поддержкой ECN.
Этот документ написан для информирования администраторов веб-
серверов и межсетевых экранов об этой проблеме, с целью содействовать
развёртыванию исправлений ошибок [FIXES]. Вторая цель этого документа
состоит в рассмотрении долгосрочных последствий такого поведения
промежуточных устройств для более общего развития протоколов в Интернете.
Floyd Лучшая современная практика [Страница 1]
RFC 3360 Ненадлежащие сбросы TCP Август 2002
2. История сбросов TCP
В этом разделе приводится краткая история использования сброса TCP в
стандартах TCP и утверждается, что отправка сброса в ответ на SYN-
пакет, использующий биты из поля Reserved заголовка TCP, является
поведением, не соответствующим стандартам.
RFC 793 содержал первоначальную спецификацию TCP в сентябре 1981 года
[RFC793]. Этот документ определил бит RST в заголовке TCP и объяснил,
что сброс был разработан для предотвращения того, чтобы старые
дублированные инициирования соединений вносили путаницу в трёхстороннее
рукопожатие TCP. Сброс также используется, когда узел получает данные
для TCP-соединения, которое более не существует.
В разделе 5 RFC 793 говорится следующее:
«Как общее правило, сброс (RST) должен быть отправлен всякий раз,
когда приходит сегмент, который, по-видимому, не предназначен для
текущего соединения. Сброс не должен быть отправлен, если неясно,
что это именно тот случай».
RFC 1122 «изменяет, исправляет и дополняет» RFC 793. В RFC 1122 нет
ничего конкретного об отправке или неотправке сбросов в ответ на флаги
в поле TCP Reserved.
Таким образом, в RFC 793 или RFC 1122 нет ничего, что указывало бы на
приемлемость отправки сброса просто потому, что SYN-пакет использует
зарезервированные флаги в заголовке TCP, а RFC 793 явно запрещает
отправлять сброс по этой причине.
И RFC 793, и RFC 1122 включают известный принцип надёжности Джона
Постела, также из RFC 791: «Будь либерален в том, что принимаешь, и
консервативен в том, что отправляешь». RFC 1122 повторяет, что этот
принцип надёжности «особенно важен на уровне Интернета, где один
неправильно работающий узел может отказать в обслуживании Интернета
многим другим узлам». В обсуждении принципа надёжности в RFC 1122
также говорится, что «адаптируемость к изменениям должна быть заложена
во все уровни программного обеспечения узла Интернета». Принцип «будь
либерален в том, что принимаешь» не переносится очевидным образом
(если вообще переносится) в мир межсетевых экранов, однако вопрос
«адаптируемости к изменениям» тем не менее имеет решающее значение.
Задача состоит в защите законных интересов безопасности без полного
блокирования способности Интернета развиваться для поддержки новых
приложений, протоколов и функциональных возможностей.
Floyd Лучшая современная практика [Страница 2]
RFC 3360 Ненадлежащие сбросы TCP Август 2002
2.1. Поле TCP Reserved
RFC 793 утверждает, что поле Reserved в заголовке TCP зарезервировано
для будущего использования и должно быть нулевым. Формулировка, более
согласованная с остальной частью документа, состояла бы в том, что
поле Reserved должно быть нулевым при отправке и игнорироваться при
получении, если иное не определено будущими действиями по стандартизации.
Однако формулировка в RFC 793 не допускает отправку сбросов в ответ на
TCP-пакеты с ненулевым полем Reserved, как объяснено в разделе выше.
2.2. Поведение межсетевых экранов Интернета и требования к ним
RFC 2979 о поведении межсетевых экранов Интернета и требованиях к ним
[RFC2979], являющийся информационным RFC, содержит следующее:
«Приложения должны продолжать работать правильно в присутствии
межсетевых экранов. Из этого следует следующее правило прозрачности:
введение межсетевого экрана и любых связанных с ним средств туннелирования
или согласования доступа НЕ ДОЛЖНО (MUST NOT) вызывать непреднамеренные
отказы законного и соответствующего стандартам использования, которое
работало бы при отсутствии межсетевого экрана».
«Необходимое следствие этого требования состоит в том, что когда такие
отказы всё же происходят, межсетевой экран и связанное с ним программное
обеспечение обязаны устранить проблему: изменения либо реализаций
существующих стандартных протоколов, либо самих протоколов НЕ ДОЛЖНЫ
(MUST NOT) быть необходимы».
«Обратите внимание, что это требование применяется только к законному
использованию протокола и беспричинным отказам — межсетевой экран вправе
блокировать любой вид доступа, который сайт считает незаконным, независимо
от того, соответствует ли предпринимаемый доступ стандартам».
Мы отметим, что RFC 2979 является информационным RFC. В разделе 4.2.2
RFC 2026 о процессе стандартизации Интернета говорится следующее:
«Спецификация категории `Informational' публикуется для общего
информирования Интернет-сообщества и не представляет собой консенсус
или рекомендацию Интернет-сообщества» [RFC2026].
2.3. Отправка сбросов как механизм управления перегрузкой
Некоторые межсетевые экраны и узлы отправляют сбросы в ответ на SYN-
пакеты как механизм управления перегрузкой, например когда их очереди
прослушивания заполнены. Эти сбросы отправляются безотносительно к
содержимому поля TCP Reserved. Возможно, в ответ на использование
сбросов в качестве механизма управления перегрузкой несколько
популярных реализаций TCP немедленно повторно отправляют SYN-пакет в
ответ на сброс до четырёх раз.
Floyd Лучшая современная практика [Страница 3]
RFC 3360 Ненадлежащие сбросы TCP Август 2002
Мы рекомендуем не использовать сброс TCP как механизм управления
перегрузкой, поскольку это перегружает семантику сообщения сброса и
неизбежно ведёт к более агрессивному поведению реализаций TCP в ответ
на сброс. Мы предлагаем, что простое отбрасывание SYN-пакета является
наиболее эффективным ответом на перегрузку. Отправитель TCP повторно
передаст SYN-пакет, используя значение по умолчанию для тайм-аута
повторной передачи (RTO), увеличивая таймер повторной передачи после
каждой повторной передачи.
2.4. Сбросы в ответ на изменения в поле Precedence
RFC 793 включает в разделе 5 следующее:
«Если входящий сегмент имеет уровень безопасности, или отсек, или
приоритет, которые в точности не соответствуют уровню, отсеку и
приоритету, запрошенным для соединения, отправляется сброс, и
соединение переходит в состояние CLOSED».
«Приоритет» относится к (старому) полю Precedence в (старом) поле ToS
заголовка IP. «Безопасность» и «отсек» относятся к устаревшей опции
IP Security. На момент написания это согласовывалось с руководством,
содержащимся в другом месте RFC 793, что сбросы должны отправляться
только тогда, когда приходит сегмент, который, по-видимому, не
предназначен для текущего соединения.
RFC 2873 «TCP Processing of the IPv4 Precedence Field» рассматривает
конкретные проблемы, возникающие из-за отправки сбросов при изменении
поля приоритета [RFC2873]. RFC 2873, на тот момент имевший статус
Proposed Standard, определяет, что TCP должен игнорировать приоритет
всех полученных сегментов и не должен отправлять сброс в ответ на
изменения поля приоритета. Мы рассматриваем это здесь, чтобы уточнить,
что этот вопрос никогда не разрешал отправку сброса в ответ на сегмент
с ненулевым полем TCP Reserved.
2.5. Сбросы в ответ на недопустимую длину опции
В разделе 4.2.2.5 RFC 1122 о TCP-опциях говорится следующее
[RFC1122]:
«TCP ДОЛЖЕН (MUST) быть способен принимать TCP-опцию в любом сегменте.
TCP ДОЛЖЕН (MUST) без ошибки игнорировать любую TCP-опцию, которую он
не реализует, при условии, что опция имеет поле длины (все TCP-опции,
определённые в будущем, будут иметь поля длины). TCP ДОЛЖЕН (MUST) быть
готов обработать недопустимую длину опции (например, нулевую) без
аварийного завершения работы; предлагаемый порядок действий — сбросить
соединение и зарегистрировать причину».
Floyd Лучшая современная практика [Страница 4]
RFC 3360 Ненадлежащие сбросы TCP Август 2002
Это имеет смысл, поскольку получатель TCP не способен интерпретировать
остальные данные в сегменте, содержащем TCP-опцию с недопустимой длиной
опции. Снова рассматриваем это здесь, чтобы уточнить, что этот вопрос
никогда не разрешал отправку сброса в ответ на сегмент с ненулевым
полем TCP Reserved.
3. Конкретный пример ECN
В этом разделе кратко объясняются ECN (Explicit Congestion
Notification) в целом и SYN-пакет настройки ECN в частности.
Интернет основан на сквозном управлении перегрузкой, и исторически
Интернет использовал отбрасывания пакетов как единственный метод для
указания маршрутизаторами перегрузки конечным узлам. ECN — недавнее
дополнение к архитектуре IP, позволяющее маршрутизаторам устанавливать
бит в заголовке IP-пакета для информирования конечных узлов о перегрузке
вместо отбрасывания пакета. ECN требует взаимодействия транспортных
конечных узлов.
Спецификация ECN, RFC 2481, была экспериментальным RFC с января 1999
года до июня 2001 года, когда пересмотренный документ [RFC3168] был
утверждён как предлагаемый стандарт. Дополнительная информация об ECN
доступна на веб-странице ECN [ECN].
Использование ECN с TCP требует, чтобы оба конечных узла TCP были
обновлены для поддержки использования ECN и чтобы оба конечных узла
договорились использовать ECN для этого конкретного TCP-соединения.
При таком согласовании поддержки ECN между двумя конечными узлами TCP
используются два флага, выделенные из поля Reserved заголовка TCP
[RFC2481].
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | U | A | P | R | S | F |
| Header Length | Reserved | R | C | S | S | Y | I |
| | | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Рисунок 1: Предыдущее определение байтов 13 и 14 заголовка TCP.
Floyd Лучшая современная практика [Страница 5]
RFC 3360 Ненадлежащие сбросы TCP Август 2002
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | C | E | U | A | P | R | S | F |
| Header Length | Reserved | W | C | R | C | S | S | Y | I |
| | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Рисунок 2: Текущее определение байтов 13 и 14 заголовка TCP,
из RFC 3168.
Два флага ECN в заголовке TCP определены из последних двух битов поля
Reserved заголовка TCP. Бит 9 в поле Reserved заголовка TCP обозначен
как флаг ECN-Echo (ECE), а бит 8 обозначен как флаг Congestion Window
Reduced (CWR). Для согласования использования ECN отправитель TCP
отправляет «ECN-setup SYN packet», TCP SYN-пакет с установленными
флагами ECE и CWR. Если TCP-узел на другом конце желает использовать
ECN для этого соединения, то он отправляет «ECN-setup SYN-ACK packet»,
TCP SYN-пакет с установленным флагом ECE и неустановленным флагом CWR.
В противном случае TCP-узел на другом конце возвращает SYN-ACK-пакет,
в котором не установлен ни флаг ECE, ни флаг CWR.
Итак, вернёмся к сбросам TCP. Когда TCP-узел, согласующий ECN, отправляет SYN-пакет для настройки ECN, ожидается, что старая реализация TCP проигнорирует эти флаги в зарезервированном поле заголовка TCP и в ответ отправит обычный SYN-ACK-пакет. Однако в Интернете имеются некоторые неисправные межсетевые экраны и балансировщики нагрузки, которые вместо этого отвечают на SYN-пакет для настройки ECN сбросом. После развёртывания конечных узлов с поддержкой ECN появились многочисленные жалобы на то, что узлы с поддержкой ECN не могут получить доступ к ряду веб-сайтов [Kelson00]. Это исследовалось сообществом Linux и проектом TBIT [TBIT] на данных, собранных с сентября 2000 года по март 2002 года, а также обсуждалось в статье в Enterprise Linux Today [Cou01]. Часть нарушающего требования оборудования была идентифицирована, и веб-страница [FIXES] содержит список несоответствующих продуктов и исправлений, опубликованных поставщиками. В марте 2002 года, через шесть месяцев после утверждения ECN в качестве Proposed Standard, SYN-пакеты для настройки ECN получали в ответ сброс от 203 из 12 364 протестированных веб-сайтов, а для 420 веб-сайтов SYN-пакеты для настройки ECN отбрасывались. Установить программное обеспечение, блокирующее пакеты, использующие флаги в зарезервированном поле TCP, значительно проще, чем позднее удалить это программное обеспечение.
3.1. ECN: Обходное решение.
Обходное решение для сохранения связности при наличии неисправного оборудования было описано в [Floyd00] и определено в RFC 3168 как процедура, которая может быть включена в реализации TCP. Ниже мы кратко опишем это обходное решение.
Floyd Best Current Practice [Page 6]
RFC 3360 Inappropriate TCP Resets August 2002
Для обеспечения устойчивой связности даже при наличии неисправного оборудования TCP-узел, получающий сброс в ответ на передачу SYN-пакета для настройки ECN, может повторно отправить SYN с очищенными CWR и ECE. Это приведёт к установлению TCP-соединения без использования ECN. Это также имеет нежелательное следствие: TCP-узел с поддержкой ECN не реагирует надлежащим образом на первый корректный сброс. Если в ответ на второй SYN с очищенными CWR и ECE отправляется второй сброс, TCP-узлу следует надлежащим образом отреагировать, прервав соединение.
Аналогично, узел, не получивший ответа на SYN-пакет для настройки ECN в течение обычного интервала тайм-аута повторной передачи SYN, может повторно отправить SYN и все последующие повторные передачи SYN с очищенными CWR и ECE. Чтобы преодолеть обычную потерю пакетов, вследствие которой исходный SYN оказывается потерянным, инициирующий узел может повторно передать один или несколько SYN-пакетов для настройки ECN, прежде чем отказаться от этого и повторно передать SYN с очищенными битами CWR и ECE.
Некоторые разработчики реализаций TCP пока решили не развёртывать эти обходные решения по следующим причинам:
* Обходные решения привели бы к тому, что узлы с поддержкой ECN не реагировали бы надлежащим образом на первый корректный сброс, полученный в ответ на SYN-пакет.
* Обходные решения ограничили бы функциональность ECN в средах без неисправного оборудования, отключая ECN там, где в сети был отброшен первый пакет SYN или SYN-ACK.
* Обходные решения во многих случаях приводили бы к задержке в шесть секунд или более до установления связности с удалённым сервером при наличии неисправного оборудования, которое отбрасывает SYN-пакеты для настройки ECN. С учётом этого неисправного оборудования было признано, что обходные решения неявно принимают как эту задержку, так и неисправное оборудование, которое вызвало бы эту задержку.
Одной из возможностей было бы сделать такие обходные решения настраиваемыми пользователем.
Одним неизбежным следствием обходного решения, заключающегося в повторной отправке изменённого SYN-пакета в ответ на сброс, является дальнейшее размывание семантики сброса TCP. Таким образом, когда устройство отправляет сброс, TCP-узел, получающий этот сброс, не знает, был ли сброс отправлен просто из-за связанных с ECN флагов в заголовке TCP или из-за какой-либо более фундаментальной проблемы. Поэтому TCP-узел повторно отправляет TCP SYN-пакет без связанных с ECN флагов в заголовке TCP. Конечным следствием отсутствия чёткой связи от промежуточного устройства к конечным узлам может стать расширяющаяся спираль
Floyd Best Current Practice [Page 7]
RFC 3360 Inappropriate TCP Resets August 2002
взаимодействий, определяемых для транспортных протоколов, поскольку конечные узлы пытаются пожертвовать как можно меньшей функциональностью в процессе определения того, какие пакеты будут и не будут перенаправлены на другой конец. Это более подробно обсуждается ниже в разделе 6.1.
4. О противодействии препятствиям надлежащей эволюции инфраструктуры Интернета
Одна из причин, по которой этот вопрос ненадлежащих сбросов важен (для меня), состоит в том, что он осложнил развёртывание ECN в Интернете (хотя, к счастью, не заблокировал развёртывание полностью). Он также создал ненужное препятствие для будущей эффективности ECN.
Однако вторая, более общая причина важности этого вопроса заключается в том, что наличие в Интернете оборудования, отвергающего корректные TCP-пакеты, ограничивает будущую эволюцию TCP, совершенно независимо от вопроса ECN. То есть широкое развёртывание оборудования, отвергающего TCP-пакеты, использующие зарезервированные флаги в заголовке TCP, могло бы фактически предотвратить развёртывание новых механизмов, использующих любой из этих зарезервированных флагов. Не имеет значения, обладают ли эти новые механизмы статусом Experimental или Proposed Standard от IETF, поскольку неисправное оборудование в Интернете не останавливается, чтобы проверить текущий статус протоколов перед тем, как отвергнуть пакеты. TCP хорош и полезен, но было бы жаль, если бы развёртывание неисправного оборудования в Интернете привело к «замораживанию» TCP в его текущем состоянии, без возможности использовать зарезервированные флаги в будущей эволюции TCP.
В конкретном случае промежуточных устройств, блокирующих TCP SYN-пакеты, пытающиеся согласовать ECN, обходного решения, описанного в разделе 3.1, достаточно, чтобы обеспечить возможность конечным узлам всё ещё устанавливать связность. Однако в ближайшие год или два, вероятно, будут стандартизованы дополнительные способы использования зарезервированного поля TCP, и эти дополнительные способы использования могут не настолько успешно сосуществовать с промежуточными устройствами, отправляющими сбросы. Рассмотрим трудности, которые могли бы возникнуть, если маршрут изменяется в середине времени жизни соединения, а промежуточные устройства на старом и новом маршрутах имеют разные политики относительно того, какие именно флаги в зарезервированном поле TCP они будут и не будут блокировать.
В более широком рассмотрении существование веб-серверов или межсетевых экранов, отправляющих ненадлежащие сбросы, является лишь одним примером функциональности в Интернете, ограничивающей будущую эволюцию Интернета. Совокупное влияние всех этих небольших ограничений представляет существенное препятствие для развития архитектуры Интернета.
Floyd Best Current Practice [Page 8]
RFC 3360 Inappropriate TCP Resets August 2002
5. Вопросы для транспортных протоколов
Один из уроков для разработчиков транспортных протоколов состоит в том, что транспортным протоколам придётся защищаться от неизвестных и, по-видимому, произвольных действий межсетевых экранов, нормализаторов и других промежуточных устройств в сети. В настоящий момент для TCP это означает отправку SYN без настройки ECN, когда сброс получен в ответ на SYN-пакет для настройки ECN. Защитные действия со стороны транспортных протоколов могли бы включать использование зарезервированных флагов в SYN-пакете до их использования в трафике данных — для защиты от промежуточных устройств, блокирующих пакеты, использующие эти флаги. Возможно, транспортным протоколам также придётся добавлять дополнительные проверки в течение времени жизни соединения, чтобы проверять вмешательство промежуточных устройств вдоль маршрута.
Документ стандартов ECN, RFC 3168, содержит в разделе 18 обширное обсуждение «Possible Changes to the ECN Field in the Network», но включает следующее о возможных изменениях заголовка TCP:
«Этот документ не рассматривает потенциальные опасности, возникающие вследствие изменений транспортного заголовка внутри сети. Мы отмечаем, что при использовании IPsec транспортный заголовок защищён как в туннельном, так и в транспортном режимах [ESP, AH].»
При текущем изменении межсетевыми экранами заголовков транспортного уровня в сети (как обсуждается ниже в разделе 6.2) будущие разработчики протоколов, возможно, больше не смогут позволить себе роскошь игнорировать возможное влияние изменений транспортного заголовка внутри сети.
Транспортным протоколам также придётся каким-либо образом реагировать на код ICMP «Communication Administratively Prohibited», если промежуточные устройства начнут использовать эту форму сообщения ICMP Destination Unreachable, чтобы указывать, что пакет использует недопустимую функциональность [RFC1812].
6. Вопросы для промежуточных устройств
Учитывая, что некоторые промежуточные устройства будут отбрасывать некоторые пакеты, поскольку те используют не разрешённую промежуточным устройством функциональность, остаётся более широкий вопрос о том, каким образом, если вообще, промежуточным устройствам следует сообщать конечным узлам причину такого действия. Одно предложение, требующее более глубокого рассмотрения в отдельном документе, состоит в том, чтобы межсетевые экраны отправляли сообщение ICMP Destination Unreachable с кодом «Communication Administratively Prohibited» [B01].
Floyd Best Current Practice [Page 9]
RFC 3360 Inappropriate TCP Resets August 2002
Мы признаём, что это не идеальное решение по нескольким причинам. Во-первых, промежуточные устройства на обратном маршруте могут блокировать эти сообщения ICMP. Во-вторых, некоторые операторы межсетевых экранов возражают против явного обмена информацией, поскольку он раскрывает слишком много сведений о политиках безопасности. В-третьих, реакция транспортных протоколов на такое сообщение ICMP ещё не определена.
Однако сообщение ICMP «Administratively Prohibited» могло бы быть разумным дополнением для межсетевых экранов, готовых использовать явный обмен информацией. Одной из возможностей, опять же подлежащей изучению в отдельном документе, было бы изменить сообщение ICMP «Administratively Prohibited», чтобы передавать конечному узлу дополнительную информацию.
Мы отмечаем, что этот документ не рассматривает промежуточные устройства, блокирующие транспортные протоколы целиком. Мы также отмечаем, что этот документ не касается межсетевых экранов, отправляющих сбросы в ответ на TCP SYN-пакет к закрытому межсетевым экраном TCP-порту. Такое использование сбросов представляется согласующимся с семантикой сброса TCP. Этот документ рассматривает только проблемы, вызываемые промежуточными устройствами, которые блокируют отдельные пакеты в составе транспортного протокола, в то время как другие пакеты этого транспортного протокола перенаправляются промежуточным устройством без изменений.
Одно осложнение состоит в том, что после установки в межсетевом экране механизма для блокирования конкретной функциональности сетевым администраторам может потребоваться значительное усилие, чтобы «удалить» эту блокировку. Было предложено, что регулируемые настройки межсетевых экранов могли бы сделать восстановление после будущих инцидентов менее болезненным для всех. Опять же, поскольку этот документ не касается более общих вопросов о межсетевых экранах, вопрос о большей гибкости межсетевых экранов и сопутствующих возможных рисках безопасности относится к отдельному документу.
6.1. Текущие варианты выбора для межсетевых экранов
Для межсетевого экрана, решившего отбрасывать TCP-пакеты, использующие зарезервированные биты в заголовке TCP, один из вопросов состоит в том, следует ли межсетевому экрану также отправлять Reset, чтобы не допустить потребления TCP-соединением ненужных ресурсов у отправителя TCP в ожидании тайм-аута повторной передачи. Мы утверждаем, что независимо от того, считает ли межсетевой экран себя вынужденным отбросить TCP-пакет, отправлять сброс TCP неуместно. Отправка сброса TCP в ответ на запрещённую функциональность продолжила бы текущее перегруженное использование семантики сброса TCP способом, который мог бы быть контрпродуктивным для всех.
В качестве примера, в разделе 2.3 уже отмечалось, что некоторые межсетевые экраны отправляют сбросы в ответ на TCP SYN-пакеты как механизм управления перегрузкой. Возможно, в ответ на это (или, возможно, в ответ на нечто иное) некоторые популярные реализации TCP немедленно повторно отправляют SYN-пакет в ответ на сброс, до четырёх раз. Другие реализации TCP
Floyd Best Current Practice [Page 10]
RFC 3360 Inappropriate TCP Resets August 2002
в соответствии со стандартами не повторно отправляют SYN-пакеты после получения сброса. Более агрессивные реализации TCP увеличивают перегрузку для других, но также увеличивают собственные шансы в конечном счёте пройти. При такой изменчивой семантике сброса TCP можно было бы ожидать, что больше реализаций TCP начнут повторно отправлять SYN-пакеты в ответ на сброс, совершенно независимо от каких-либо вопросов, связанных с ECN. Очевидно, это ослабляет эффективность сброса при его использовании по исходному назначению — для ответа на TCP-пакеты, которые, по-видимому, не предназначены для текущего соединения.Если добавить к этому сочетанию использование межсетевыми экранами TCP reset в ответ на TCP-пакеты, использующие резервные биты в заголовке TCP, это ещё больше запутывает ситуацию. Поскольку TCP reset могут отправляться из-за перегрузки, запрещённой функциональности или потому, что получен пакет от предыдущего TCP-соединения, у реализаций TCP (или, точнее, у разработчиков TCP) теперь был бы стимул ещё настойчивее повторно отправлять SYN-пакеты в ответ на TCP reset. Помимо упомянутого выше стимула повторно отправлять TCP SYN-пакеты, чтобы повысить шансы в итоге пройти в период перегрузки, TCP reset мог быть вызван запрещённой функциональностью, а не перегрузкой, поэтому реализация TCP могла бы повторно отправлять SYN-пакеты в разных формах, чтобы точно определить, какая именно функциональность запрещена. Можно ожидать, что такое непрерывное изменение семантики TCP reset приведёт к продолжающейся эскалации мер и контрмер между межсетевыми экранами и оконечными хостами, почти без продуктивной выгоды для какой-либо из сторон.
Можно было бы утверждать, что *отбрасывание* TCP SYN-пакета из-за использования запрещённой функциональности приводит к перегрузке семантики отбрасывания пакета так же, как reset приводит к перегрузке семантики reset. Это верно; с точки зрения реакции оконечной системы на сообщения с перегруженной семантикой предпочтительно было бы иметь явное указание на запрещённую функциональность (для тех межсетевых экранов, которые по какой-либо причине готовы использовать явные указания). Однако, если межсетевой экран выбирает между отправкой reset и простым отбрасыванием пакета, мы бы утверждали, что простое отбрасывание пакета причиняет меньший вред в смысле создания у оконечных хостов стимула применять контрмеры. Верно, что простое отбрасывание пакета без отправки reset приводит к задержке TCP-соединения при повторной отправке SYN-пакета без запрещённой функциональности. Однако отправка reset имеет нежелательный долгосрочный эффект: она создаёт у будущих реализаций TCP стимул добавлять более вычурные комбинации повторной отправки SYN-пакетов в ответ на reset, поскольку отправитель TCP не может определить, вызван ли reset стандартной причиной, перегрузкой или запрещённой функциональностью опции X либо резервного бита Y в заголовке TCP.
Floyd Best Current Practice [Page 11]
RFC 3360 Inappropriate TCP Resets August 2002
6.2. Осложнения при изменении заголовков пакетов в сети
Помимо межсетевых экранов, отправляющих reset в ответ на SYN-пакеты с настройкой ECN, и межсетевых экранов, отбрасывающих SYN-пакеты с настройкой ECN, существуют также межсетевые экраны, которые по умолчанию обнуляют флаги в поле TCP Reserved, включая два флага, используемых для ECN. Отметим, что в некоторых случаях это может иметь непреднамеренные и нежелательные последствия.
Если межсетевой экран обнуляет флаги, связанные с ECN, в заголовке TCP в исходном SYN-пакете, то TCP-соединение будет установлено без использования ECN, а флаги, связанные с ECN, в заголовке TCP будут передаваться обнулёнными во всех последующих пакетах данного соединения. Это позволит достичь цели межсетевого экрана — блокировать ECN, одновременно позволяя TCP-соединению эффективно и плавно продолжаться без использования ECN.
Если по какой-либо причине флаги, связанные с ECN, в заголовке TCP не обнулены в исходном SYN-пакете от хоста A к хосту B, но межсетевой экран обнуляет эти флаги в ответном SYN/ACK-пакете от хоста B к хосту A, следствием может быть подрыв сквозного управления перегрузкой для данного соединения. Спецификации ECN не были написаны с расчётом на обеспечение устойчивой работы при произвольном обнулении полей заголовка TCP внутри сети, поскольку в то время авторам протокола не приходило в голову, что это является требованием к проектированию протокола.
Аналогично, если флаги, связанные с ECN, в заголовке TCP не обнулены ни в SYN-, ни в SYN/ACK-пакете, но межсетевой экран обнуляет эти флаги в более поздних пакетах данного TCP-соединения, это также может иметь непреднамеренное следствие в виде подрыва сквозного управления перегрузкой для данного соединения. Детали этих возможных взаимодействий не имеют решающего значения для данного документа и описаны в приложении. Однако наш вывод — как для флагов, связанных с ECN, в заголовке TCP, так и для будущего использования четырёх других битов в поле TCP Reserved — состоит в том, что, если требуется, чтобы межсетевые экраны могли блокировать использование новой функции, добавляемой в протокол, этот вопрос лучше всего решать на начальной стадии проектирования посредством совместного сотрудничества сообщества межсетевых экранов и разработчиков протокола.
7. Выводы
Наш вывод состоит в том, что действующим стандартам не соответствует ситуация, когда межсетевой экран, балансировщик нагрузки или веб-сервер отвечает reset на TCP SYN-пакет только потому, что пакет использует флаги в поле TCP Reserved. Точнее, не соответствует стандартам отвечать reset на TCP SYN-пакет только потому, что флаги ECE и CWR установлены в заголовке IP. Мы бы настоятельно призвали поставщиков предоставлять исправления для любого несоответствующего стандартам кода; также мы могли бы призвать интернет-провайдеров и системных администраторов развернуть эти исправления на своих веб-серверах и межсетевых экранах.
Floyd Best Current Practice [Page 12]
RFC 3360 Inappropriate TCP Resets August 2002
Мы не утверждаем, что произвольное отбрасывание промежуточными устройствами пакетов, использующих флаги в поле TCP Reserved, нарушает какой-либо стандарт, но мы бы утверждали, что поведение такого рода, без ясного способа сообщить оконечным узлам причины этих действий, могло бы создать значительное препятствие для развития TCP. Очевидно, требуется дополнительная работа для согласования противоречащих друг другу интересов обеспечения безопасности и одновременного предоставления возможности осторожной эволюции интернет-протоколов.
8. Благодарности
Этот документ является результатом обсуждений и деятельности многих людей, поэтому я воздержусь от попытки поблагодарить здесь их всех. Особая благодарность Ran Atkinson, Steve Bellovin, Alex Cannara, Dennis Ferguson, Ned Freed, Mark Handley, John Klensin, Allison Mankin, Jitendra Padhye, Vern Paxson, K. K. Ramakrishnan, Jamal Hadi Salim, Pekka Savola, Alex Snoeren и Dan Wing за отзывы о данном документе, а также End-to-End Research Group, IAB и IESG за обсуждение этих вопросов. Я благодарю Mikael Olsson за многочисленные циклы отзывов. Я также благодарю участников списка рассылки Firewall Wizards за отзывы (в целом выражавшие несогласие) о более раннем черновике этого документа.
Обсуждения по электронной почте с рядом людей, включая Dax Kelson, Alexey Kuznetsov, Kacheong Poon, David Reed, Jamal Hadi-Salim и Venkat Venkatsubra, были посвящены вопросам, поднятым несоответствующим стандартам оборудованием в Интернете, которое не отвечает на TCP SYN-пакеты с установленными флагами ECE и CWR. Мы благодарим Mark Handley, Jitentra Padhye и других за обсуждения процедур инициализации TCP.
9. Нормативные ссылки
[RFC793] Postel, J., "Transmission Control Protocol - DARPA
Internet Program Protocol Specification", STD 7, RFC 793,
September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
Floyd Best Current Practice [Page 13]
RFC 3360 Inappropriate TCP Resets August 2002
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
Congestion Notification (ECN) to IP", RFC 2481, January
1999.
[RFC2873] Xiao, X., Hannan, A., Paxson, V., and E. Crabbe, "TCP
Processing of the IPv4 Precedence Field, RFC 2873, June
2000.
[RFC2979] Freed, N., " Behavior of and Requirements for Internet
Firewalls", RFC 2979, October 2000.
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
10. Информативные ссылки
[B01] Bellovin, S., "A "Reason" Field for ICMP "Administratively
Prohibited" Messages", Work in Progress.
[Cou01] Scott Courtney, Why Can't My 2.4 Kernel See Some Web
Sites?, Enterprise Linux Today, Apr 17, 2001. URL
"http://eltoday.com/article.php3?ltsn=2001-04-17-001-14-
PS".
[ECN] "The ECN Web Page", URL
"http://www.icir.org/floyd/ecn.html".
[FIXES] ECN-under-Linux Unofficial Vendor Support Page, URL
"http://gtf.org/garzik/ecn/".
[Floyd00] Sally Floyd, Negotiating ECN-Capability in a TCP
connection, October 2, 2000, email to the end2end-interest
mailing list. URL
"http://www.icir.org/floyd/papers/ECN.Oct2000.txt".
[Kelson00] Dax Kelson, note sent to the Linux kernel mailing list,
September 10, 2000.
[QUESO] Toby Miller, Intrusion Detection Level Analysis of Nmap
and Queso, August 30, 2000. URL
"http://www.securityfocus.com/infocus/1225".
Floyd Best Current Practice [Page 14]
RFC 3360 Inappropriate TCP Resets August 2002
[Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The
Protocols", Addison-Wesley, 1994.
[SFO01] FreeBSD ipfw Filtering Evasion Vulnerability, Security
Focus Online, January 23, 2001. URL
"http://www.securityfocus.com/bid/2293".
[TBIT] Jitendra Padhye and Sally Floyd, Identifying the TCP
Behavior of Web Servers, SIGCOMM, August 2001. URL
"http://www.icir.org/tbit/".
11. Соображения безопасности
Один общий риск использования резервных флагов в TCP заключается в риске предоставления дополнительной информации о конфигурации соответствующего хоста. Однако TCP и так специфицирован достаточно свободно, с достаточно большим числом вариантов и опций, поэтому инструменты сканирования портов, такие как Nmap и Queso, довольно успешно определяют конфигурацию хостов даже без использования резервных флагов.
Соображения безопасности и все остальные соображения, относящиеся к возможному ICMP-сообщению Destination Unreachable с кодом "Communication Administratively Prohibited", будут рассмотрены в отдельном документе.
Традиционная задача межсетевых экранов — предотвращать несанкционированный доступ к системам, предотвращать DoS-атаки и другие атаки, направленные на компрометацию терминала конечного пользователя, а также защищать оконечные системы от ошибочного кода. Нам известно об одной уязвимости безопасности, о которой сообщалось в связи с использованием резервных флагов в заголовке TCP [SFO01]. Пакетный фильтр, предназначенный пропускать только пакеты в установленных соединениях, может пропустить пакет, не принадлежащий установленному соединению, если в резервном поле пакета установлен флаг ECE. «Эксплуатация этой уязвимости может позволить несанкционированный удалённый доступ к иначе защищённым службам». Также возможно появление реализации TCP с ошибочным кодом, связанным с использованием резервных флагов в заголовке TCP, но в настоящее время нам не известно ни об одной такой реализации.
К сожалению, ошибочные соображения безопасности с самого начала являются одной из причин проблем, описанных в данном документе. В статье от августа 2000 года «Intrusion Detection Level Analysis of Nmap and Queso» инструмент сканирования портов Queso описывался как отправляющий SYN-пакеты с установленными двумя последними резервными битами в заголовке TCP; далее утверждалось следующее: «[QUESO] легко идентифицировать: если вы видите [эти два резервных бита и бит SYN], установленные в 13-м байте заголовка TCP, то знаете, что кто-то имеет злонамеренные намерения в отношении вашей сети». Как задокументировано на веб-странице TBIT, промежуточные устройства, блокирующие SYN-пакеты с использованием двух связанных с ECN резервных флагов в заголовке TCP, не блокируют SYN-пакеты, использующие другие резервные флаги в заголовке TCP.
Floyd Best Current Practice [Page 15]
RFC 3360 Inappropriate TCP Resets August 2002
По-видимому, один из уроков состоит в том, что любой может фактически «атаковать» новую функцию TCP, просто используя эту функцию в общедоступном инструменте сканирования портов и тем самым вызывая блокирование использования этой функции промежуточными устройствами всех видов.
Floyd Best Current Practice [Page 16]
RFC 3360 Inappropriate TCP Resets August 2002
12. Приложение: Осложнения при изменении заголовков пакетов
В этом разделе мы сначала показываем, что, если флаги, связанные с ECN, в заголовке TCP не обнулены в исходном SYN-пакете от хоста A к хосту B, но обнулены в ответном SYN/ACK-пакете от хоста B к хосту A, следствием может быть подрыв сквозного управления перегрузкой для данного соединения.Предположим, что SYN-пакет с настройкой ECN от Host A получен Host B, но SYN/ACK-пакет с настройкой ECN от Host B изменяется межсетевым экраном в сети на SYN/ACK без настройки ECN, как показано на рисунке 3 ниже. RFC 3168 не определяет, что ACK-пакет каким-либо образом должен отражать TCP-флаги, полученные в SYN/ACK-пакете, поскольку разработчики не предполагали, что эти флаги будут изменяться внутри сети.
Host A Firewall or router Host B
-----------------------------------------------------------------
Sends ECN-setup SYN ----------------> Receives ECN-setup SYN
<- Sends ECN-setup SYN/ACK
<- Firewall zeros flags
Receives non-ECN-setup SYN/ACK
Sends ACK and data ----------------> Receives ACK and data
<- Sends data packet with ECT
<- Router sets CE
Receives data packet with ECT and CE
Рисунок 3: Связанные с ECN флаги в SYN/ACK-пакете очищены в сети.
В соответствии с RFC 3168 Host A получил SYN/ACK-пакет без настройки ECN и не должен устанавливать ECT в пакетах данных. Однако Host B не знает, что Host A получил SYN/ACK-пакет без настройки ECN, и Host B может устанавливать ECT в пакетах данных. RFC 3168 не требует, чтобы Host A надлежащим образом отвечал на пакеты данных, полученные от Host B, с установленными в IP-заголовке кодовыми точками ECT и CE. Таким образом, отправитель данных, Host B, может никогда не быть уведомлён о перегрузке, возникшей в сети, тем самым нарушая сквозное управление перегрузкой.
Далее мы показываем, что, если связанные с ECN флаги в TCP-заголовке не очищаются ни в SYN-, ни в SYN/ACK-пакете, но межсетевой экран очищает эти флаги в последующих пакетах данного TCP-соединения, это также может иметь непреднамеренное последствие в виде подрыва сквозного управления перегрузкой для этого соединения. На рисунке 4 показан этот сценарий.
Floyd Best Current Practice [Page 17]
RFC 3360 Inappropriate TCP Resets August 2002
Host A Firewall or router Host B
-----------------------------------------------------------------
Sends ECN-setup SYN ----------------> Receives ECN-setup SYN
Receives ECN-setup SYN/ACK <------------ Sends ECN-setup SYN/ACK
Sends ACK and data ----------------> Receives ACK and data
<- Sends data packet with ECT
<- Router sets CE
Receives data packet with ECT and CE
Sends ACK with ECE ->
Firewall resets ECE ->
Receives plain ACK
Рисунок 4: Связанные с ECN флаги в ACK-пакете очищены в сети.
Связанные с ECN флаги не изменяются сетью в SYN- и SYN/ACK-пакетах с настройкой ECN в сценарии на рисунке 4, и оба конечных узла могут использовать ECN и устанавливать флаг ECT в поле ECN IP-заголовка. Однако, если межсетевой экран очищает флаг ECE в TCP-заголовке ACK-пакетов, направляемых от Node A к Node B, Node B никогда не узнает о перегрузке, с которой столкнулись в сети его предыдущие пакеты данных, тем самым подрывая сквозное управление перегрузкой для этого соединения.
Дополнительные осложнения возникнут, когда/если использование ECN nonce в TCP будет стандартизировано в IETF [RFC3168], поскольку это может предусматривать определение дополнительного флага из поля TCP Reserved для обратной связи от получателя TCP-данных к отправителю TCP-данных. Основная мотивация ECN nonce состоит в том, чтобы позволить механизмам отправителя данных проверять, что сетевые элементы не стирают кодовую точку CE и что получатели данных надлежащим образом сообщают отправителю о получении пакетов с установленной кодовой точкой CE.
13. Соображения IANA
В этом документе отсутствуют соображения IANA.
14. Адрес автора
Sally Floyd
ICIR (ICSI Center for Internet Research)
Phone: +1 (510) 666-2989
EMail: floyd@icir.org
URL: http://www.icir.org/floyd/
Floyd Best Current Practice [Page 18]
RFC 3360 Inappropriate TCP Resets August 2002
15. Полное заявление об авторском праве
Copyright (C) The Internet Society (2002). Все права защищены.
Этот документ и его переводы могут копироваться и передаваться другим лицам, а производные работы, которые комментируют или иным образом объясняют его либо содействуют его реализации, могут подготавливаться, копироваться, публиковаться и распространяться, полностью или частично, без ограничений какого бы то ни было рода, при условии, что приведённое выше уведомление об авторском праве и настоящий абзац включаются во все такие копии и производные работы. Однако сам этот документ не может быть каким-либо образом изменён, например путём удаления уведомления об авторском праве или ссылок на Internet Society либо другие интернет-организации, кроме случаев, когда это необходимо для разработки интернет-стандартов, при которой должны соблюдаться процедуры в отношении авторских прав, определённые процессом Internet Standards, либо когда это требуется для его перевода на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не будут отозваны Internet Society либо её правопреемниками или цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях «КАК ЕСТЬ», И INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Благодарность
Финансирование функции RFC Editor в настоящее время обеспечивает Internet Society.
Floyd Best Current Practice [Page 19]
Network Working Group S. Floyd
Request for Comments: 3360 ICIR
BCP: 60 August 2002
Category: Best Current Practice
Inappropriate TCP Resets Considered Harmful
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document is being written because there are a number of
firewalls in the Internet that inappropriately reset a TCP connection
upon receiving certain TCP SYN packets, in particular, packets with
flags set in the Reserved field of the TCP header. In this document
we argue that this practice is not conformant with TCP standards, and
is an inappropriate overloading of the semantics of the TCP reset.
We also consider the longer-term consequences of this and similar
actions as obstacles to the evolution of the Internet infrastructure.
1. Introduction
TCP uses the RST (Reset) bit in the TCP header to reset a TCP
connection. Resets are appropriately sent in response to a
connection request to a nonexistent connection, for example. The TCP
receiver of the reset aborts the TCP connection, and notifies the
application [RFC793, RFC1122, Ste94].
Unfortunately, a number of firewalls and load-balancers in the
current Internet send a reset in response to a TCP SYN packet that
use flags from the Reserved field in the TCP header. Section 3 below
discusses the specific example of firewalls that send resets in
response to TCP SYN packets from ECN-capable hosts.
This document is being written to inform administrators of web
servers and firewalls of this problem, in an effort to encourage the
deployment of bug-fixes [FIXES]. A second purpose of this document
is to consider the longer-term consequences of such middlebox
behavior on the more general evolution of protocols in the Internet.
Floyd Best Current Practice [Page 1]
RFC 3360 Inappropriate TCP Resets August 2002
2. The history of TCP resets.
This section gives a brief history of the use of the TCP reset in the
TCP standards, and argues that sending a reset in response to a SYN
packet that uses bits from the Reserved field of the TCP header is
non-compliant behavior.
RFC 793 contained the original specification of TCP in September,
1981 [RFC793]. This document defined the RST bit in the TCP header,
and explained that reset was devised to prevent old duplicate
connection initiations from causing confusion in TCP's three-way
handshake. The reset is also used when a host receives data for a
TCP connection that no longer exists.
RFC 793 states the following, in Section 5:
"As a general rule, reset (RST) must be sent whenever a segment
arrives which apparently is not intended for the current connection.
A reset must not be sent if it is not clear that this is the case."
RFC 1122 "amends, corrects, and supplements" RFC 793. RFC 1122 says
nothing specific about sending resets, or not sending resets, in
response to flags in the TCP Reserved field.
Thus, there is nothing in RFC 793 or RFC 1122 that suggests that it
is acceptable to send a reset simply because a SYN packet uses
Reserved flags in the TCP header, and RFC 793 explicitly forbids
sending a reset for this reason.
RFC 793 and RFC 1122 both include Jon Postel's famous robustness
principle, also from RFC 791: "Be liberal in what you accept, and
conservative in what you send." RFC 1122 reiterates that this
robustness principle "is particularly important in the Internet
layer, where one misbehaving host can deny Internet service to many
other hosts." The discussion of the robustness principle in RFC 1122
also states that "adaptability to change must be designed into all
levels of Internet host software". The principle "be liberal in what
you accept" doesn't carry over in a clear way (if at all) to the
world of firewalls, but the issue of "adaptability to change" is
crucial nevertheless. The challenge is to protect legitimate
security interests without completely blocking the ability of the
Internet to evolve to support new applications, protocols, and
functionality.
Floyd Best Current Practice [Page 2]
RFC 3360 Inappropriate TCP Resets August 2002
2.1. The TCP Reserved Field
RFC 793 says that the Reserved field in the TCP header is reserved
for future use, and must be zero. A rephrasing more consistent with
the rest of the document would have been to say that the Reserved
field should be zero when sent and ignored when received, unless
specified otherwise by future standards actions. However, the
phrasing in RFC 793 does not permit sending resets in response to TCP
packets with a non-zero Reserved field, as is explained in the
section above.
2.2. Behavior of and Requirements for Internet Firewalls
RFC 2979 on the Behavior of and Requirements for Internet Firewalls
[RFC2979], an Informational RFC, contains the following:
"Applications have to continue to work properly in the presence of
firewalls. This translates into the following transparency rule: The
introduction of a firewall and any associated tunneling or access
negotiation facilities MUST NOT cause unintended failures of
legitimate and standards-compliant usage that would work were the
firewall not present."
"A necessary corollary to this requirement is that when such failures
do occur it is incumbent on the firewall and associated software to
address the problem: Changes to either implementations of existing
standard protocols or the protocols themselves MUST NOT be
necessary."
"Note that this requirement only applies to legitimate protocol usage
and gratuitous failures -- a firewall is entitled to block any sort
of access that a site deems illegitimate, regardless of whether or
not the attempted access is standards-compliant."
We would note that RFC 2979 is an Informational RFC. RFC 2026 on
Internet Standards Process says the following in Section 4.2.2: "An
`Informational' specification is published for the general
information of the Internet community, and does not represent an
Internet community consensus or recommendation" [RFC2026].
2.3. Sending Resets as a Congestion Control Mechanism
Some firewalls and hosts send resets in response to SYN packets as a
congestion control mechanism, for example, when their listen queues
are full. These resets are sent without regard to the contents of
the TCP Reserved field. Possibly in response to the use of resets as
Floyd Best Current Practice [Page 3]
RFC 3360 Inappropriate TCP Resets August 2002
a congestion control mechanism, several popular TCP implementations
immediately resend a SYN packet in response to a reset, up to four
times.
We would recommend that the TCP reset not be used as a congestion
control mechanism, because this overloads the semantics of the reset
message, and inevitably leads to more aggressive behavior from TCP
implementations in response to a reset. We would suggest that simply
dropping the SYN packet is the most effective response to congestion.
The TCP sender will retransmit the SYN packet, using the default
value for the Retransmission Timeout (RTO), backing-off the
retransmit timer after each retransmit.
2.4. Resets in Response to Changes in the Precedence Field
RFC 793 includes the following in Section 5:
"If an incoming segment has a security level, or compartment, or
precedence which does not exactly match the level, and compartment,
and precedence requested for the connection, a reset is sent and
connection goes to the CLOSED state."
The "precedence" refers to the (old) Precedence field in the (old)
ToS field in the IP header. The "security" and "compartment" refer
to the obsolete IP Security option. When it was written, this was
consistent with the guideline elsewhere in RFC 793 that resets should
only be sent when a segment arrives which apparently is not intended
for the current connection.
RFC 2873 on "TCP Processing of the IPv4 Precedence Field" discusses
specific problems raised by the sending of resets when the precedence
field has changed [RFC2873]. RFC 2873, currently a Proposed
Standard, specifies that TCP must ignore the precedence of all
received segments, and must not send a reset in response to changes
in the precedence field. We discuss this here to clarify that this
issue never permitted the sending of a reset in response to a segment
with a non-zero TCP Reserved field.
2.5. Resets in Response to Illegal Option Lengths
RFC 1122 says the following in Section 4.2.2.5 about TCP options
[RFC1122]:
"A TCP MUST be able to receive a TCP option in any segment. A TCP
MUST ignore without error any TCP option it does not implement,
assuming that the option has a length field (all TCP options defined
Floyd Best Current Practice [Page 4]
RFC 3360 Inappropriate TCP Resets August 2002
in the future will have length fields). TCP MUST be prepared to
handle an illegal option length (e.g., zero) without crashing; a
suggested procedure is to reset the connection and log the reason."
This makes sense, as a TCP receiver is unable to interpret the rest
of the data on a segment that has a TCP option with an illegal option
length. Again, we discuss this here to clarify that this issue never
permitted the sending of a reset in response to a segment with a
non-zero TCP Reserved field.
3. The Specific Example of ECN
This section has a brief explanation of ECN (Explicit Congestion
Notification) in general, and the ECN-setup SYN packet in particular.
The Internet is based on end-to-end congestion control, and
historically the Internet has used packet drops as the only method
for routers to indicate congestion to the end nodes. ECN is a recent
addition to the IP architecture to allow routers to set a bit in the
IP packet header to inform end-nodes of congestion, instead of
dropping the packet. ECN requires the cooperation of the transport
end-nodes.
The ECN specification, RFC 2481, was an Experimental RFC from January
1999 until June 2001, when a revised document [RFC3168] was approved
as Proposed Standard. More information about ECN is available from
the ECN Web Page [ECN].
The use of ECN with TCP requires that both TCP end-nodes have been
upgraded to support the use of ECN, and that both end-nodes agree to
use ECN with this particular TCP connection. This negotiation of ECN
support between the two TCP end-nodes uses two flags that have been
allocated from the Reserved field in the TCP header [RFC2481].
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | U | A | P | R | S | F |
| Header Length | Reserved | R | C | S | S | Y | I |
| | | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 1: The previous definition of bytes 13 and 14 of the TCP
header.
Floyd Best Current Practice [Page 5]
RFC 3360 Inappropriate TCP Resets August 2002
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | C | E | U | A | P | R | S | F |
| Header Length | Reserved | W | C | R | C | S | S | Y | I |
| | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 2: The current definition of bytes 13 and 14 of the TCP
Header, from RFC 3168.
The two ECN flags in the TCP header are defined from the last two
bits in the Reserved field of the TCP header. Bit 9 in the Reserved
field of the TCP header is designated as the ECN-Echo flag (ECE), and
Bit 8 is designated as the Congestion Window Reduced (CWR) flag. To
negotiate ECN usage, the TCP sender sends an "ECN-setup SYN packet",
a TCP SYN packet with the ECE and CWR flags set. If the TCP host at
the other end wishes to use ECN for this connection, then it sends an
"ECN-setup SYN-ACK packet", a TCP SYN packet with the ECE flag set
and the CWR flag not set. Otherwise, the TCP host at the other end
returns a SYN-ACK packet with neither the ECE nor the CWR flag set.
So now back to TCP resets. When a TCP host negotiating ECN sends an
ECN-setup SYN packet, an old TCP implementation is expected to ignore
those flags in the Reserved field, and to send a plain SYN-ACK packet
in response. However, there are some broken firewalls and load-
balancers in the Internet that instead respond to an ECN-setup SYN
packet with a reset. Following the deployment of ECN-enabled end
nodes, there were widespread complaints that ECN-capable hosts could
not access a number of websites [Kelson00]. This has been
investigated by the Linux community, and by the TBIT project [TBIT]
in data taken from September, 2000, up to March, 2002, and has been
discussed in an article in Enterprise Linux Today [Cou01]. Some of
the offending equipment has been identified, and a web page [FIXES]
contains a list of non-compliant products and the fixes posted by the
vendors. In March 2002, six months after ECN was approved as
Proposed Standard, ECN-setup SYN packets were answered by a reset
from 203 of the 12,364 web sites tested, and ECN-setup SYN packets
were dropped for 420 of the web sites. Installing software that
blocks packets using flags in TCP's Reserved field is considerably
easier than uninstalling that software later on.
3.1. ECN: The Work-Around.
A work-around for maintaining connectivity in the face of the broken
equipment was described in [Floyd00], and has been specified in RFC
3168 as a procedure that may be included in TCP implementations. We
describe this work-around briefly below.
Floyd Best Current Practice [Page 6]
RFC 3360 Inappropriate TCP Resets August 2002
To provide robust connectivity even in the presence of faulty
equipment, a TCP host that receives a reset in response to the
transmission of an ECN-setup SYN packet may resend the SYN with CWR
and ECE cleared. This would result in a TCP connection being
established without using ECN. This also has the unfortunate result
of the ECN-capable TCP host not responding properly to the first
valid reset. If a second reset is sent in response to the second
SYN, which had CWR and ECE cleared, then the TCP host should respond
properly by aborting the connection.
Similarly, a host that receives no reply to an ECN-setup SYN within
the normal SYN retransmission timeout interval may resend the SYN and
any subsequent SYN retransmissions with CWR and ECE cleared. To
overcome normal packet loss that results in the original SYN being
lost, the originating host may retransmit one or more ECN-setup SYN
packets before giving up and retransmitting the SYN with the CWR and
ECE bits cleared.
Some TCP implementors have so far decided not to deploy these
workarounds, for the following reasons:
* The work-arounds would result in ECN-capable hosts not responding
properly to the first valid reset received in response to a SYN
packet.
* The work-arounds would limit ECN functionality in environments
without broken equipment, by disabling ECN where the first SYN or
SYN-ACK packet was dropped in the network.
* The work-arounds in many cases would involve a delay of six seconds
or more before connectivity is established with the remote server,
in the case of broken equipment that drops ECN-setup SYN packets.
By accommodating this broken equipment, the work-arounds have been
judged as implicitly accepting both this delay and the broken
equipment that would be causing this delay.
One possibility would be for such work-arounds to be configurable by
the user.
One unavoidable consequence of the work-around of resending a
modified SYN packet in response to a reset is to further erode the
semantics of the TCP reset. Thus, when a box sends a reset, the TCP
host receiving that reset does not know if the reset was sent simply
because of the ECN-related flags in the TCP header, or because of
some more fundamental problem. Therefore, the TCP host resends the
TCP SYN packet without the ECN-related flags in the TCP header. The
ultimate consequence of this absence of clear communications from the
middlebox to the end-nodes could be an extended spiral of
Floyd Best Current Practice [Page 7]
RFC 3360 Inappropriate TCP Resets August 2002
communications specified for transport protocols, as end nodes
attempt to sacrifice as little functionality as possible in the
process of determining which packets will and will not be forwarded
to the other end. This is discussed in more detail in Section 6.1
below.
4. On Combating Obstacles to the Proper Evolution of the Internet
Infrastructure
One of the reasons that this issue of inappropriate resets is
important (to me) is that it has complicated the deployment of ECN in
the Internet (though it has fortunately not blocked the deployment
completely). It has also added an unnecessary obstacle to the future
effectiveness of ECN.
However, a second, more general reason why this issue is important is
that the presence of equipment in the Internet that rejects valid TCP
packets limits the future evolution of TCP, completely aside from the
issue of ECN. That is, the widespread deployment of equipment that
rejects TCP packets that use Reserved flags in the TCP header could
effectively prevent the deployment of new mechanisms that use any of
these Reserved flags. It doesn't matter if these new mechanisms have
the protection of Experimental or Proposed Standard status from the
IETF, because the broken equipment in the Internet does not stop to
look up the current status of the protocols before rejecting the
packets. TCP is good, and useful, but it would be a pity for the
deployment of broken equipment in the Internet to result in the
"freezing" of TCP in its current state, without the ability to use
the Reserved flags in the future evolution of TCP.
In the specific case of middleboxes that block TCP SYN packets
attempting to negotiate ECN, the work-around described in Section 3.1
is sufficient to ensure that end-nodes could still establish
connectivity. However, there are likely to be additional uses of the
TCP Reserved Field standardized in the next year or two, and these
additional uses might not coexist quite as successfully with
middleboxes that send resets. Consider the difficulties that could
result if a path changes in the middle of a connection's lifetime,
and the middleboxes on the old and new paths have different policies
about exactly which flags in the TCP Reserved field they would and
would not block.
Taking the wider view, the existence of web servers or firewalls that
send inappropriate resets is only one example of functionality in the
Internet that restricts the future evolution of the Internet. The
impact of all of these small restrictions taken together presents a
considerable obstacle to the development of the Internet
architecture.
Floyd Best Current Practice [Page 8]
RFC 3360 Inappropriate TCP Resets August 2002
5. Issues for Transport Protocols
One lesson for designers of transport protocols is that transport
protocols will have to protect themselves from the unknown and
seemingly arbitrary actions of firewalls, normalizers, and other
middleboxes in the network. For the moment, for TCP, this means
sending a non-ECN-setup SYN when a reset is received in response to
an ECN-setup SYN packet. Defensive actions on the side of transport
protocols could include using Reserved flags in the SYN packet before
using them in data traffic, to protect against middleboxes that block
packets using those flags. It is possible that transport protocols
will also have to add additional checks during the course of the
connection lifetime to check for interference from middleboxes along
the path.
The ECN standards document, RFC 3168, contains an extensive
discussion in Section 18 on "Possible Changes to the ECN Field in the
Network", but includes the following about possible changes to the
TCP header:
"This document does not consider potential dangers introduced by
changes in the transport header within the network. We note that
when IPsec is used, the transport header is protected both in tunnel
and transport modes [ESP, AH]."
With the current modification of transport-level headers in the
network by firewalls (as discussed below in Section 6.2), future
protocol designers might no longer have the luxury of ignoring the
possible impact of changes to the transport header within the
network.
Transport protocols will also have to respond in some fashion to an
ICMP code of "Communication Administratively Prohibited" if
middleboxes start to use this form of the ICMP Destination
Unreachable message to indicate that the packet is using
functionality not allowed [RFC1812].
6. Issues for Middleboxes
Given that some middleboxes are going to drop some packets because
they use functionality not allowed by the middlebox, the larger issue
remains of how middleboxes should communicate the reason for this
action to the end-nodes, if at all. One suggestion, for
consideration in more depth in a separate document, would be that
firewalls send an ICMP Destination Unreachable message with the code
"Communication Administratively Prohibited" [B01].
Floyd Best Current Practice [Page 9]
RFC 3360 Inappropriate TCP Resets August 2002
We acknowledge that this is not an ideal solution, for several
reasons. First, middleboxes along the reverse path might block these
ICMP messages. Second, some firewall operators object to explicit
communication because it reveals too much information about security
policies. And third, the response of transport protocols to such an
ICMP message is not yet specified.
However, an ICMP "Administratively Prohibited" message could be a
reasonable addition, for firewalls willing to use explicit
communication. One possibility, again to be explored in a separate
document, would be for the ICMP "Administratively Prohibited" message
to be modified to convey additional information to the end host.
We would note that this document does not consider middleboxes that
block complete transport protocols. We also note that this document
is not addressing firewalls that send resets in response to a TCP SYN
packet to a firewalled-off TCP port. Such a use of resets seems
consistent with the semantics of TCP reset. This document is only
considering the problems caused by middleboxes that block specific
packets within a transport protocol when other packets from that
transport protocol are forwarded by the middlebox unaltered.
One complication is that once a mechanism is installed in a firewall
to block a particular functionality, it can take considerable effort
for network administrators to "un-install" that block. It has been
suggested that tweakable settings on firewalls could make recovery
from future incidents less painful all around. Again, because this
document does not address more general issues about firewalls, the
issue of greater firewall flexibility, and the attendant possible
security risks, belongs in a separate document.
6.1. Current Choices for Firewalls
Given a firewall that has decided to drop TCP packets that use
reserved bits in the TCP header, one question is whether the firewall
should also send a Reset, in order to prevent the TCP connection from
consuming unnecessary resources at the TCP sender waiting for the
retransmit timeout. We would argue that whether or not the firewall
feels compelled to drop the TCP packet, it is not appropriate to send
a TCP reset. Sending a TCP reset in response to prohibited
functionality would continue the current overloading of the semantics
of the TCP reset in a way that could be counterproductive all around.
As an example, Section 2.3 has already observed that some firewalls
send resets in response to TCP SYN packets as a congestion control
mechanism. Possibly in response to this (or perhaps in response to
something else), some popular TCP implementations immediately resend
a SYN packet in response to a reset, up to four times. Other TCP
Floyd Best Current Practice [Page 10]
RFC 3360 Inappropriate TCP Resets August 2002
implementations, in conformance to the standards, don't resend SYN
packets after receiving a reset. The more aggressive TCP
implementations increase congestion for others, but also increase
their own chances of eventually getting through. Giving these fluid
semantics for the TCP reset, one might expect more TCP
implementations to start resending SYN packets in response to a
reset, completely apart from any issues having to do with ECN.
Obviously, this weakens the effectiveness of the reset when used for
its original purpose, of responding to TCP packets that apparently
are not intended for the current connection.
If we add to this mix the use of the TCP reset by firewalls in
response to TCP packets using reserved bits in the TCP header, this
muddies the waters further. Because TCP resets could be sent due to
congestion, or to prohibited functionality, or because a packet was
received from a previous TCP connection, TCP implementations (or,
more properly, TCP implementors) would now have an incentive to be
even more persistent in resending SYN packets in response to TCP
resets. In addition to the incentive mentioned above of resending
TCP SYN packets to increase one's odds of eventually getting through
in a time of congestion, the TCP reset might have been due to
prohibited functionality instead of congestion, so the TCP
implementation might resend SYN packets in different forms to
determine exactly which functionality is being prohibited. Such a
continual changing of the semantics of the TCP reset could be
expected to lead to a continued escalation of measures and
countermeasures between firewalls and end-hosts, with little
productive benefit to either side.
It could be argued that *dropping* the TCP SYN packet due to the use
of prohibited functionality leads to overloading of the semantics of
a packet drop, in the same way that the reset leads to overloading
the semantics of a reset. This is true; from the viewpoint of end-
system response to messages with overloaded semantics, it would be
preferable to have an explicit indication about prohibited
functionality (for those firewalls for some reason willing to use
explicit indications). But given a firewall's choice between sending
a reset or just dropping the packet, we would argue that just
dropping the packet does less damage, in terms of giving an incentive
to end-hosts to adopt counter-measures. It is true that just
dropping the packet, without sending a reset, results in delay for
the TCP connection in resending the SYN packet without the prohibited
functionality. However, sending a reset has the undesirable longer-
term effect of giving an incentive to future TCP implementations to
add more baroque combinations of resending SYN packets in response to
a reset, because the TCP sender can't tell if the reset is for a
standard reason, for congestion, or for the prohibited functionality
of option X or reserved bit Y in the TCP header.
Floyd Best Current Practice [Page 11]
RFC 3360 Inappropriate TCP Resets August 2002
6.2. The Complications of Modifying Packet Headers in the Network
In addition to firewalls that send resets in response to ECN-setup
SYN packets and firewalls that drop ECN-setup SYN packets, there also
exist firewalls that by default zero the flags in the TCP Reserved
field, including the two flags used for ECN. We note that in some
cases this could have unintended and undesirable consequences.
If a firewall zeros the ECN-related flags in the TCP header in the
initial SYN packet, then the TCP connection will be set up without
using ECN, and the ECN-related flags in the TCP header will be sent
zeroed-out in all of the subsequent packets in this connection. This
will accomplish the firewall's purpose of blocking ECN, while
allowing the TCP connection to proceed efficiently and smoothly
without using ECN.
If for some reason the ECN-related flags in the TCP header aren't
zeroed in the initial SYN packet from host A to host B, but the
firewall does zero those flags in the responding SYN/ACK packet from
host B to host A, the consequence could be to subvert end-to-end
congestion control for this connection. The ECN specifications were
not written to ensure robust operation in the presence of the
arbitrary zeroing of TCP header fields within the network, because it
didn't occur to the authors of the protocol at the time that this was
a requirement in protocol design.
Similarly, if the ECN-related flags in the TCP header are not zeroed
in either the SYN or the SYN/ACK packet, but the firewall does zero
these flags in later packets in that TCP connection, this could also
have the unintended consequence of subverting end-to-end congestion
control for this connection. The details of these possible
interactions are not crucial for this document, and are described in
the appendix. However, our conclusion, both for the ECN-related
flags in the TCP header and for future uses of the four other bits in
the TCP Reserved field, would be that if it is required for firewalls
to be able to block the use of a new function being added to a
protocol, this is best addressed in the initial design phase by joint
cooperation between the firewall community and the protocol
designers.
7. Conclusions
Our conclusion is that it is not conformant with current standards
for a firewall, load-balancer, or web-server to respond with a reset
to a TCP SYN packet simply because the packet uses flags in the TCP
Reserved field. More specifically, it is not conformant to respond
with a reset to a TCP SYN packet simply because the ECE and CWR flags
are set in the IP header. We would urge vendors to make available
Floyd Best Current Practice [Page 12]
RFC 3360 Inappropriate TCP Resets August 2002
fixes for any nonconformant code, and we could urge ISPs and system
administrators to deploy these fixes in their web servers and
firewalls.
We don't claim that it violates any standard for middleboxes to
arbitrarily drop packets that use flags in the TCP Reserved field,
but we would argue that behavior of this kind, without a clear method
for informing the end-nodes of the reasons for these actions, could
present a significant obstacle to the development of TCP. More work
is clearly needed to reconcile the conflicting interests of providing
security while at the same time allowing the careful evolution of
Internet protocols.
8. Acknowledgements
This document results from discussions and activity by many people,
so I will refrain from trying to acknowledge all of them here. My
specific thanks go to Ran Atkinson, Steve Bellovin, Alex Cannara,
Dennis Ferguson, Ned Freed, Mark Handley, John Klensin, Allison
Mankin, Jitendra Padhye, Vern Paxson, K. K. Ramakrishnan, Jamal Hadi
Salim, Pekka Savola, Alex Snoeren, and Dan Wing for feedback on this
document, and to the End-to-End Research Group, the IAB, and the IESG
for discussion of these issues. I thank Mikael Olsson for numerous
rounds of feedback. I also thank the members of the Firewall Wizards
mailing list for feedback (generally of disagreement) on an earlier
draft of this document.
Email discussions with a number of people, including Dax Kelson,
Alexey Kuznetsov, Kacheong Poon, David Reed, Jamal Hadi-Salim, and
Venkat Venkatsubra, have addressed the issues raised by non-
conformant equipment in the Internet that does not respond to TCP SYN
packets with the ECE and CWR flags set. We thank Mark Handley,
Jitentra Padhye, and others for discussions on the TCP initialization
procedures.
9. Normative References
[RFC793] Postel, J., "Transmission Control Protocol - DARPA
Internet Program Protocol Specification", STD 7, RFC 793,
September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
Floyd Best Current Practice [Page 13]
RFC 3360 Inappropriate TCP Resets August 2002
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
Congestion Notification (ECN) to IP", RFC 2481, January
1999.
[RFC2873] Xiao, X., Hannan, A., Paxson, V., and E. Crabbe, "TCP
Processing of the IPv4 Precedence Field, RFC 2873, June
2000.
[RFC2979] Freed, N., " Behavior of and Requirements for Internet
Firewalls", RFC 2979, October 2000.
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
10. Informative References
[B01] Bellovin, S., "A "Reason" Field for ICMP "Administratively
Prohibited" Messages", Work in Progress.
[Cou01] Scott Courtney, Why Can't My 2.4 Kernel See Some Web
Sites?, Enterprise Linux Today, Apr 17, 2001. URL
"http://eltoday.com/article.php3?ltsn=2001-04-17-001-14-
PS".
[ECN] "The ECN Web Page", URL
"http://www.icir.org/floyd/ecn.html".
[FIXES] ECN-under-Linux Unofficial Vendor Support Page, URL
"http://gtf.org/garzik/ecn/".
[Floyd00] Sally Floyd, Negotiating ECN-Capability in a TCP
connection, October 2, 2000, email to the end2end-interest
mailing list. URL
"http://www.icir.org/floyd/papers/ECN.Oct2000.txt".
[Kelson00] Dax Kelson, note sent to the Linux kernel mailing list,
September 10, 2000.
[QUESO] Toby Miller, Intrusion Detection Level Analysis of Nmap
and Queso, August 30, 2000. URL
"http://www.securityfocus.com/infocus/1225".
Floyd Best Current Practice [Page 14]
RFC 3360 Inappropriate TCP Resets August 2002
[Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The
Protocols", Addison-Wesley, 1994.
[SFO01] FreeBSD ipfw Filtering Evasion Vulnerability, Security
Focus Online, January 23, 2001. URL
"http://www.securityfocus.com/bid/2293".
[TBIT] Jitendra Padhye and Sally Floyd, Identifying the TCP
Behavior of Web Servers, SIGCOMM, August 2001. URL
"http://www.icir.org/tbit/".
11. Security Considerations
One general risk of using Reserved flags in TCP is the risk of
providing additional information about the configuration of the host
in question. However, TCP is sufficiently loosely specified as it
is, with sufficiently many variants and options, that port-scanning
tools such as Nmap and Queso do rather well in identifying the
configuration of hosts even without the use of Reserved flags.
The security considerations and all other considerations of a
possible ICMP Destination Unreachable message with the code
"Communication Administratively Prohibited" will be discussed in a
separate document.
The traditional concern of firewalls is to prevent unauthorized
access to systems, to prevent DoS attacks and other attacks from
subverting the end-user terminal, and to protect end systems from
buggy code. We are aware of one security vulnerability reported from
the use of the Reserved flags in the TCP header [SFO01]. A packet
filter intended only to let through packets in established
connections can let pass a packet not in an established connection if
the packet has the ECE flag set in the reserved field. "Exploitation
of this vulnerability may allow for unauthorized remote access to
otherwise protected services." It is also possible that an
implementation of TCP could appear that has buggy code associated
with the use of Reserved flags in the TCP header, but we are not
aware of any such implementation at the moment.
Unfortunately, misconceived security concerns are one of the reasons
for the problems described in this document in the first place. An
August, 2000, article on "Intrusion Detection Level Analysis of Nmap
and Queso" described the port-scanning tool Queso as sending SYN
packets with the last two Reserved bits in the TCP header set, and
said the following: "[QUESO] is easy to identify, if you see [these
two Reserved bits and the SYN bit] set in the 13th byte of the TCP
header, you know that someone has malicious intentions for your
network." As is documented on the TBIT Web Page, the middleboxes
Floyd Best Current Practice [Page 15]
RFC 3360 Inappropriate TCP Resets August 2002
that block SYNs using the two ECN-related Reserved flags in the TCP
header do not block SYNs using other Reserved flags in the TCP
header.
One lesson appears to be that anyone can effectively "attack" a new
TCP function simply by using that function in their publicly-
available port-scanning tool, thus causing middleboxes of all kinds
to block the use of that function.
Floyd Best Current Practice [Page 16]
RFC 3360 Inappropriate TCP Resets August 2002
12. Appendix: The Complications of Modifying Packet Headers
In this section we first show that if the ECN-related flags in the
TCP header aren't zeroed in the initial SYN packet from Host A to
Host B, but are zeroed in the responding SYN/ACK packet from Host B
to Host A, the consequence could be to subvert end-to-end congestion
control for this connection.
Assume that the ECN-setup SYN packet from Host A is received by Host
B, but the ECN-setup SYN/ACK from Host B is modified by a firewall in
the network to a non-ECN-setup SYN/ACK, as in Figure 3 below. RFC
3168 does not specify that the ACK packet in any way should echo the
TCP flags received in the SYN/ACK packet, because it had not occurred
to the designers that these flags would be modified within the
network.
Host A Firewall or router Host B
-----------------------------------------------------------------
Sends ECN-setup SYN ----------------> Receives ECN-setup SYN
<- Sends ECN-setup SYN/ACK
<- Firewall zeros flags
Receives non-ECN-setup SYN/ACK
Sends ACK and data ----------------> Receives ACK and data
<- Sends data packet with ECT
<- Router sets CE
Receives data packet with ECT and CE
Figure 3: ECN-related flags in SYN/ACK packet cleared in network.
Following RFC 3168, Host A has received a non-ECN-setup SYN/ACK
packet, and must not set ECT on data packets. Host B, however, does
not know that Host A has received a non-ECN-setup SYN/ACK packet, and
Host B may set ECT on data packets. RFC 3168 does not require Host A
to respond properly to data packets received from Host B with the ECT
and CE codepoints set in the IP header. Thus, the data sender, Host
B, might never be informed about the congestion encountered in the
network, thus violating end-to-end congestion control.
Next we show that if the ECN-related flags in the TCP header are not
zeroed in either the SYN or the SYN/ACK packet, but the firewall does
zero these flags in later packets in that TCP connection, this could
also have the unintended consequence of subverting end-to-end
congestion control for this connection. Figure 4 shows this
scenario.
Floyd Best Current Practice [Page 17]
RFC 3360 Inappropriate TCP Resets August 2002
Host A Firewall or router Host B
-----------------------------------------------------------------
Sends ECN-setup SYN ----------------> Receives ECN-setup SYN
Receives ECN-setup SYN/ACK <------------ Sends ECN-setup SYN/ACK
Sends ACK and data ----------------> Receives ACK and data
<- Sends data packet with ECT
<- Router sets CE
Receives data packet with ECT and CE
Sends ACK with ECE ->
Firewall resets ECE ->
Receives plain ACK
Figure 4: ECN-related flags in ACK packet cleared in network.
The ECN-related flags are not changed by the network in the ECN-setup
SYN and SYN/ACK packets for the scenario in Figure 4, and both end
nodes are free to use ECN, and to set the ECT flag in the ECN field
in the IP header. However, if the firewall clears the ECE flag in
the TCP header in ACK packets from Node A to Node B, then Node B will
never hear about the congestion that its earlier data packets
encountered in the network, thus subverting end-to-end congestion
control for this connection.
Additional complications will arise when/if the use of the ECN nonce
in TCP becomes standardized in the IETF [RFC3168], as this could
involve the specification of an additional flag from the TCP Reserved
field for feedback from the TCP data receiver to the TCP data sender.
The primary motivation for the ECN nonce is to allow mechanisms for
the data sender to verify that network elements are not erasing the
CE codepoint, and that data receivers are properly reporting to the
sender the receipt of packets with the CE codepoint set.
13. IANA Considerations
There are no IANA considerations in this document.
14. Author's Address
Sally Floyd
ICIR (ICSI Center for Internet Research)
Phone: +1 (510) 666-2989
EMail: floyd@icir.org
URL: http://www.icir.org/floyd/
Floyd Best Current Practice [Page 18]
RFC 3360 Inappropriate TCP Resets August 2002
15. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Floyd Best Current Practice [Page 19]