О документе
Рабочая группа по сети S. Floyd
Запрос комментариев: 3360 ICIR
BCP: 60 Август 2002
Категория: Лучшая современная практика
Ненадлежащие сбросы TCP считаются вредными
1. Введение
TCP использует бит RST (Reset) в заголовке TCP для сброса TCP-
соединения. Например, сбросы надлежащим образом отправляются в ответ на
запрос соединения для несуществующего соединения. Получатель сброса TCP
прерывает TCP-соединение и уведомляет приложение [RFC793, RFC1122, Ste94].
К сожалению, ряд межсетевых экранов и балансировщиков нагрузки в
современном Интернете отправляют сброс в ответ на TCP SYN-пакет,
использующий флаги из поля Reserved заголовка TCP. В разделе 3 ниже
рассматривается конкретный пример межсетевых экранов, отправляющих сбросы
в ответ на TCP SYN-пакеты от узлов с поддержкой ECN.
Этот документ написан для информирования администраторов веб-
серверов и межсетевых экранов об этой проблеме, с целью содействовать
развёртыванию исправлений ошибок [FIXES]. Вторая цель этого документа
состоит в рассмотрении долгосрочных последствий такого поведения
промежуточных устройств для более общего развития протоколов в Интернете.
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
также говорится, что «адаптируемость к изменениям должна быть заложена
во все уровни программного обеспечения узла Интернета». Принцип «будь
либерален в том, что принимаешь» не переносится очевидным образом
(если вообще переносится) в мир межсетевых экранов, однако вопрос
«адаптируемости к изменениям» тем не менее имеет решающее значение.
Задача состоит в защите законных интересов безопасности без полного
блокирования способности Интернета развиваться для поддержки новых
приложений, протоколов и функциональных возможностей.
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-пакет в
ответ на сброс до четырёх раз.
Мы рекомендуем не использовать сброс 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) быть
готов обработать недопустимую длину опции (например, нулевую) без
аварийного завершения работы; предлагаемый порядок действий — сбросить
соединение и зарегистрировать причину».
Это имеет смысл, поскольку получатель 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.
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. Ниже мы кратко опишем это обходное решение.
Для обеспечения устойчивой связности даже при наличии неисправного оборудования 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. Конечным следствием отсутствия чёткой связи от промежуточного устройства к конечным узлам может стать расширяющаяся спираль
взаимодействий, определяемых для транспортных протоколов, поскольку конечные узлы пытаются пожертвовать как можно меньшей функциональностью в процессе определения того, какие пакеты будут и не будут перенаправлены на другой конец. Это более подробно обсуждается ниже в разделе 6.1.
4. О противодействии препятствиям надлежащей эволюции инфраструктуры Интернета
Одна из причин, по которой этот вопрос ненадлежащих сбросов важен (для меня), состоит в том, что он осложнил развёртывание ECN в Интернете (хотя, к счастью, не заблокировал развёртывание полностью). Он также создал ненужное препятствие для будущей эффективности ECN.
Однако вторая, более общая причина важности этого вопроса заключается в том, что наличие в Интернете оборудования, отвергающего корректные TCP-пакеты, ограничивает будущую эволюцию TCP, совершенно независимо от вопроса ECN. То есть широкое развёртывание оборудования, отвергающего TCP-пакеты, использующие зарезервированные флаги в заголовке TCP, могло бы фактически предотвратить развёртывание новых механизмов, использующих любой из этих зарезервированных флагов. Не имеет значения, обладают ли эти новые механизмы статусом Experimental или Proposed Standard от IETF, поскольку неисправное оборудование в Интернете не останавливается, чтобы проверить текущий статус протоколов перед тем, как отвергнуть пакеты. TCP хорош и полезен, но было бы жаль, если бы развёртывание неисправного оборудования в Интернете привело к «замораживанию» TCP в его текущем состоянии, без возможности использовать зарезервированные флаги в будущей эволюции TCP.
В конкретном случае промежуточных устройств, блокирующих TCP SYN-пакеты, пытающиеся согласовать ECN, обходного решения, описанного в разделе 3.1, достаточно, чтобы обеспечить возможность конечным узлам всё ещё устанавливать связность. Однако в ближайшие год или два, вероятно, будут стандартизованы дополнительные способы использования зарезервированного поля TCP, и эти дополнительные способы использования могут не настолько успешно сосуществовать с промежуточными устройствами, отправляющими сбросы. Рассмотрим трудности, которые могли бы возникнуть, если маршрут изменяется в середине времени жизни соединения, а промежуточные устройства на старом и новом маршрутах имеют разные политики относительно того, какие именно флаги в зарезервированном поле TCP они будут и не будут блокировать.
В более широком рассмотрении существование веб-серверов или межсетевых экранов, отправляющих ненадлежащие сбросы, является лишь одним примером функциональности в Интернете, ограничивающей будущую эволюцию Интернета. Совокупное влияние всех этих небольших ограничений представляет существенное препятствие для развития архитектуры Интернета.
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].
Мы признаём, что это не идеальное решение по нескольким причинам. Во-первых, промежуточные устройства на обратном маршруте могут блокировать эти сообщения 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
в соответствии со стандартами не повторно отправляют 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.
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. Мы бы настоятельно призвали поставщиков предоставлять исправления для любого несоответствующего стандартам кода; также мы могли бы призвать интернет-провайдеров и системных администраторов развернуть эти исправления на своих веб-серверах и межсетевых экранах.
Мы не утверждаем, что произвольное отбрасывание промежуточными устройствами пакетов, использующих флаги в поле 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.
[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".
[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.
По-видимому, один из уроков состоит в том, что любой может фактически «атаковать» новую функцию TCP, просто используя эту функцию в общедоступном инструменте сканирования портов и тем самым вызывая блокирование использования этой функции промежуточными устройствами всех видов.
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 показан этот сценарий.
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/
15. Полное заявление об авторском праве
Copyright (C) The Internet Society (2002). Все права защищены.
Этот документ и его переводы могут копироваться и передаваться другим лицам, а производные работы, которые комментируют или иным образом объясняют его либо содействуют его реализации, могут подготавливаться, копироваться, публиковаться и распространяться, полностью или частично, без ограничений какого бы то ни было рода, при условии, что приведённое выше уведомление об авторском праве и настоящий абзац включаются во все такие копии и производные работы. Однако сам этот документ не может быть каким-либо образом изменён, например путём удаления уведомления об авторском праве или ссылок на Internet Society либо другие интернет-организации, кроме случаев, когда это необходимо для разработки интернет-стандартов, при которой должны соблюдаться процедуры в отношении авторских прав, определённые процессом Internet Standards, либо когда это требуется для его перевода на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не будут отозваны Internet Society либо её правопреемниками или цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях «КАК ЕСТЬ», И INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.