RFC: 3168
Оригинал: The Addition of Explicit Congestion Notification (ECN) to IP
Предыдущие версии: RFC 2481
Категория: Предложенный стандарт
Дата публикации:
Авторы: , ,
Перевод: Николай Малых

Статус документа

Документ содержит спецификацию стандартного протокола Internet, предложенного сообществу Internet, и служит приглашением к дискуссии в целях развития протокола. Информацию о текущем состоянии стандартизации протокола вы можете найти в документе «Internet Official Protocol Standards» (STD 1).

Данный документ может распространяться без ограничений.

Тезисы

В документе приведена спецификация включения ECN (Explicit Congestion Notification — явное уведомление о насыщении) в протоколы TCP и IP, включая использование для ECN двух битов заголовка IP.

Оглавление

1. Введение

Сначала рассматривается использование протоколом TCP процедуры отбрасывания пакетов для индикации насыщения. Далее даются пояснения по поводу новых возможностей, обусловленных добавлением активного управления очередями (например, RED) в инфраструктуру Internet, когда маршрутизаторы детектируют насыщение до того, как будет переполнена очередь, и уже не обязаны отбрасывать пакеты для индикации насыщения. Маршрутизаторы могут устанавливать маркер CE (Congestion Experienced — наблюдается насыщение) в заголовках пакетов IP от поддерживающих ECN транспортных протоколов. Описано когда маршрутизаторы устанавливают маркер CE, а также рассмотрены изменения, которые нужно внести в протокол TCP для поддержки ECN. Изменения других протоколов транспортного уровня (например, негарантированная доставка пакетов unicast или multicast, гарантированная доставка multicast-пакетов, другие протоколы гарантированной доставки пакетов unicast) могут рассматриваться при разработке или стандартизации таких протоколов. В данном документе описываются также вопросы использования ECN в туннелях IP и, в частности, в Ipsec-туннелях.

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

Данный документе отменяет RFC 2481 «A Proposal to add Explicit Congestion Notification (ECN) to IP», в котором ECN определяется как экспериментальный протокол для сообщества Internet. Кроме того, данный документ обновляет RFC 2474 «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», в части определения поля ECN в заголовке IP, RFC 2401 «Security Architecture for the Internet Protocol» (изменение обработки байтов IPv4 TOS и IPv6 Traffic Class Octet при создании в туннельном режиме заголовков, совместимых с ECN) и RFC 793 «Transmission Control Protocol» в части определения новых флагов заголовка TCP.

Алгоритмы контроля насыщения и предотвращения перегрузки протокола TCP основаны на представлении сети как «черного ящика» [Jacobson88, Jacobson90]. Насыщение или его отсутствие определяется конечными системами путем проверки состояния сети путем увеличения нагрузки (увеличения размера окна насыщения — числа пакетов, остающихся в сети) до тех пор, пока не произойдет насыщение и связанная с ним потеря пакетов. Трактовка сети как «черного ящика» и потери пакетов как индикатора перегрузки приемлема для случаев передачи по протоколу TCP данных, которые не чувствительны или не критичны к задержкам или потере отдельных пакетов. Алгоритмы контроля насыщения в TCP используют встроенные методы (такие, как Fast Retransmit и Fast Recovery) для минимизации влияния потерь в точки зрения пропускной способности. Однако эти алгоритмы не подходят для приложений, которые чувствительны к задержкам или потере одного или нескольких пакетов. Интерактивные системы (например, telnet, просмотр web-страниц, передача аудио/видео-потоков) могут быть чувствительны к потере пакетов (при использовании транспорта без гарантии доставки типа UDP) или увеличению задержки, вызванному повтором передачи в результате потери пакета (при использовании гарантированного транспорта типа TCP).

Поскольку TCP определяет приемлемый размер окна насыщения путем увеличения размера этого окна до тех пор пока не начнется потеря (отбрасывание) пакетов, это может приводить к переполнению очередей в маршрутизаторах, являющихся узким местом. Большинство алгоритмов отбрасывания пакетов в маршрутизаторах не чувствительно к нагрузке, создаваемой отдельным потоком, что означает возможность отбрасывания пакетов из некоторых потоков, чувствительных к задержкам.

Активные механизмы управления очередями детектируют насыщение до того, как переполнится очередь, и обеспечивают индикацию насыщения для конечных узлов. Преимущества активного управления очередями обсуждаются в RFC 2309 [RFC2309]. Такое управление позволяет избавиться от некоторых негативных свойств систем управления очередями, основанных на отбрасывании пакетов при переполнении (в частности, от нежелательной синхронизации потери пакетов во множестве потоков данных). Более важно, что в системах активного управления очередями транспортные протоколы с контролем насыщения (например, TCP) не используют переполнение буферов в качестве индикатора перегрузки.

Механизмы активного управления очередями могут использовать один из нескольких методов индикации насыщения для конечных узлов. Один из механизмов использует отбрасывание пакетов, как это делается сейчас. Однако активное управление очередями позволяет маршрутизаторы отделить правила буферизации (включения в очередь) и отбрасывания пакетов от политики индикации насыщения. Таким образом, активное управление очередями позволяет маршрутизаторам использовать маркер CE (Congestion Experienced) в заголовке пакета для индикации насыщения вместо того, чтобы полагаться исключительно на отбрасывание пакетов. Это может снизить избыточные задержки в очереди для всех типов трафика, использующих эту очередь.

В сети Internet существуют промежуточные устройства (брандмауэры, системы распределения нагрузки, системы детектирования попыток вторжения), которые отбрасывают пакеты TCP SYN, предназначенные для согласования ECN, или отвечают на них пакетами RST. В данном документе описывается процедура, которая может использоваться в реализациях TCP для обеспечения надежной работы даже при наличии указанных устройств.

2. Соглашение об использовании терминов

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с [RFC2119].

3. Исходные допущения и основные принципы

В этом параграфе рассматриваются некоторые важные принципы и допущения на которых основана работа предлагаемого расширения.

  • В силу очевидности постепенной адаптации ECN существенное значение имеет стратегия перехода. Некоторые маршрутизаторы могут по-прежнему использовать лишь отбрасывание пакетов для индикации насыщения, а часть конечных систем может не поддерживать ECN. Наиболее подходящей стратегией является постепенное развертывание без возникновения «островков», которые поддерживают (или наоборот, не поддерживают) ECN.

  • Новые механизмы контроля и предотвращения перегрузки должны сосуществовать и кооперироваться с существующими механизмами контроля насыщения. В частности, новые механизмы должны сосуществовать с методами, используемыми в TCP, и принятой в современных маршрутизаторах практикой отбрасывания пакетов в периоды насыщения.

  • Длительность периода насыщения может меняться в широких пределах. Периоды насыщения могут превышать время кругового обхода (RTT).

  • Число пакетов в отдельном потоке (например, в соединении TCP или сеансе обмена данными по протоколу UDP) также может меняться в широких пределах. Мы заинтересованы в контроле насыщения, создаваемого потоком, которых передает достаточно большое количество данных, чтобы такой поток оставался активным до того, как будет получен сигнал обратной связи из сети.

  • Очевидно, что асимметрия маршрутов является нормальным явлением в Internet. Путь (последовательность каналов и маршрутизаторов), по которому данные следуют из одной точки в другую в одном направлении, может отличаться от пути между той же парой точек в обратном направлении (например, для передачи подтверждений).

  • Многие маршрутизаторы более эффективно обрабатывают заголовки пакетов IP без опций, нежели опции IP. Этот факт служит предпосылкой включения индикации насыщения в обычный заголовок пакета IP, а не в поле опций заголовка.

  • Следует признать, что не все конечные системы могут кооперироваться в плане контроля насыщения. Однако новым механизмам не следует упрощать для приложений TCP запрет контроля насыщения. Преимущества от использования новых механизмов типа ECN не должны быть значительными.

4. Активное управление очередями AQM

Упреждающее детектирование RED (Random Early Detection) представляет собой один из механизмов активного управления очередями (AQM — Active Queue Management), предложенный для детектирования начинающейся перегрузки [FJ93] и развернутый уже в Internet [RFC2309]. AQM отбрасывает пакеты в тех случаях, когда средний размер очереди превышает пороговое значение, не дожидаясь переполнения очереди. Однако, когда AQM отбрасывает пакеты до переполнения очереди, это отбрасывание не всегда вызвано нехваткой памяти.

AQM может устанавливать маркер CE в заголовке пакета вместо того, чтобы отбросить пакет, если если такое поле присутствует в заголовке IP и понятно транспортному протоколу. Использование маркера CE с ECN будет позволять получателю избавиться от избыточной задержки, связанной с повтором передачи после отбрасывания пакета. Для обозначения пакетов с установленным маркером CE далее будет использоваться термин CE-пакет.

5. Явное уведомление о насыщении в IP

В этом документе указывается, что Internet обеспечивает индикацию насыщения для наступающей перегрузки (как в RED и более ранней работе [RJ90]) путем маркировки пакетов, а не их отбрасывания. Этот механизм использует двухбитовое поле ECN в заголовке IP, которое может содержать значения от 00 до 11. Для поддерживающего ECN транспорта (ECT — ECN-Capable Transport) отправитель устанавливает маркер 10 или 01 для индикации поддержки конечной точкой возможностей ECN; для обозначения этих случаев будем использовать маркеры ECT(0) и ECT(1), соответственно. Термин «маркер ECT» в данном документе будет использоваться применительно к обоим случаям. Маршрутизаторы трактуют маркеры ECT(0) и ECT(1) одинаково. Отправитель может выбрать любой из маркеров ECT(0) или ECT(1) для индикации ECT и использовать этот маркер для последующих пакетов.

Использование двух маркеров ECT обусловлено прежде всего желанием предоставить отправителю механизм проверки того, что маркер CE не теряется в сети и получатель пакетов ответит отправителю пакетов с маркером CE в соответствии с требованиями транспортного протокола. Рекомендации для отправителей и получателей по дифференциации маркеров ECT(0) и ECT(1) следует указать в отдельных документах для каждого из транспортных протоколов. В частности, данный документ не описывает различий между маркерами ECT(0) и ECT(1) для протокола TCP. Протоколам и отправителям, которым требуется единственный маркер ECT, следует использовать ECT(0).

Маркер not-ECT (00) указывает пакет, в котором не используется ECN. Маркер CE (11) устанавливается маршрутизаторами для индикации насыщения конечным точкам. Маршрутизаторы, принимающие пакеты при отсутствии места в очереди просто отбрасывают такие пакеты, как это делается без ECN.

+-----+-----+
| Поле Поле |
+-----+-----+
  ECT   CE         [устаревшие] обозначения битов ECN в RFC 2481.
   0     0         Not-ECT
   0     1         ECT(1)
   1     0         ECT(0)
   1     1         CE
Рисунок 1: Поле ECN в заголовке IP

Использование двухбитовых маркеров ECT вступает в противоречие с использованием временных полей ECN в заголовках пакетов и должны удалять такие флаги при установке маркера CE [SCWA99]. Например, маршрутизатор, удаляющий маркер CE, будет сталкиваться с дополнительными сложностями при попытках восстановления исходного поля и, таким образом, повторное удаление маркера CE будет с большей очевидностью обнаружено конечными точками. Временные поля ECN могут также приводить к проблемам, связанным с тем, что некоторые получатели не будут информировать отправителя о наличии в пакете маркера CE. Мотивация использования двухбитовых маркеров ECT более детально рассматривается в параграфе 20 вместе с обсуждением альтернативного варианта использования четвертого маркера ECT (01). Вопросы обратной совместимости с ранними реализациями ECN, которые не понимают маркеров ECT(1), рассматриваются в параграфе 11.

В RFC 2481 [RFC2481] поле ECN было разделено на две части — бит ECT и бит CE. Поле ECN, в котором установлен только бит ECT (в соответствии с RFC 2481), эквивалентно маркеру ECT(0), а поле ECN, в котором установлены оба флага ECT и CE — маркеру CE. Маркер 01 не определен в RFC 2481 и по этой причине следует использовать маркер ECT(0) в тех случаях, когда требуется единственный маркер ECT.

    0     1     2     3     4     5     6     7
 +-----+-----+-----+-----+-----+-----+-----+-----+
|           Поле DS, DSCP           | Поле ECN  |
 +-----+-----+-----+-----+-----+-----+-----+-----+
   DSCP: код дифференцированного обслуживания
   ECN:  явное уведомление о перегрузке
Рисунок 2: Поля Differentiated Services и ECN в заголовке IP

Биты 6 и 7 октета IPv4 TOS обозначены как поле ECN. Октет IPv4 TOS соответствует октету Traffic Class в IPv6, а поле ECN определяется одинаково для обоих случаев. Определения для октета IPv4 TOS [RFC791] и октета IPv6 Traffic Class были отменены определением шестибитового поля DS (Differentiated Services) [RFC2474, RFC2780]. Биты 6 и 7 указаны в [RFC2474] как неиспользуемые (Currently Unused), а в RFC 2780 — как предложенные для экспериментального использования в ECN. В параграфе 22 приведена краткая ретроспектива использования поля октета TOS.

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

При получении поддерживающим ECN транспортным протоколом одного CE-пакета алгоритм контроля насыщения в конечной системе должен работать в точности так же, как при индикации насыщения путем отбрасывании одного пакета. Например, для поддерживающей ECN реализации протокола TCP требуется, чтобы отправитель уменьшил вдвое размер окна насыщения для любого окна данных, в котором произошло отбрасывание пакета или был получен индикатор ECN.

Одной из причин требования идентичной реакции на индикацию насыщения при получении CE-пакета или отбрасывании пакета является необходимость обеспечения постепенного развертывания ECN как в конечных системах, так и в маршрутизаторах. Некоторые маршрутизаторы могут отбрасывать ECN-пакеты (например, при использовании некоторых правил детектирования перегрузки в AQM), тогда как другие маршрутизаторы будут устанавливать маркер CE при таких же условиях насыщения. Подобно этому маршрутизатор может отбрасывать не поддерживающие ECN пакеты и устанавливать бит CE в ECN-пакетах при одинаковых условиях насыщения. Разная реакция на индикацию насыщения путем установки бита CE и путем отбрасывания пакетов может приводить к различным (неправильным) трактовкам для разных потоков.

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

Маршрутизаторам следует устанавливать маркер CE в ECN-пакетах только в тех случаях, когда маршрутизатор должен был бы отбросить пакет для индикации насыщения конечным узлам. Когда буфер маршрутизатора еще не заполнен, но маршрутизатор уже приготовился к отбрасыванию пакетов для уведомления конечных узлов о насыщении, этому маршрутизатору следует сначала проверить наличие маркера ECT в заголовке IP. Если данный маркер установлен, вместо отбрасывания пакетов маршрутизатор может устанавливать маркер CE в заголовке IP.

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

Когда маршрутизатор получает CE-пакет, маркер CE остается без изменения и пакет передается как обычно. При возникновении некоторой перегрузки и заполнении очереди маршрутизатора, последний может принять решение об отбрасывании некоторых пакетов при поступлении новых. Предполагается, что такое отбрасывание пакетов станет сравнительно редким явлением, когда большая часть конечных систем станет поддерживать ECN и механизмы контроля насыщения TCP или аналогичные механизмы. В корректно организованной сети, работающей в среде с поддержкой ECN потери пакетов могут происходить в периоды неустойчивости или в присутствии не поддерживающих контроль насыщения отправителей.

Рассмотренная выше ситуация, когда установка CE используется взамен отбрасывания пакетов, применяется по умолчанию ко всем Differentiated Service PHB [RFC 2475] (Per-Hop Behavior — поведение для интервала пути). Спецификации для PHB могут более детально указывать как совместимые реализации должны выбирать между отбрасыванием пакетов и установкой CE, но такая детализация не является обязательной. Для маршрутизатора недопустима установка CE взамен отбрасывания пакета, когда это отбрасывание обусловлено отличными от подступающего насыщения или желания указать конечным узлам на начинающуюся перегрузку (например, краевой узел diffserv может быть настроен на безусловное отбрасывание некоторых классов трафика на входе в домен).

Предполагается, что маршрутизаторы будут устанавливать маркер CE при начинающейся перегрузке, определяемой по среднему размеру очереди с использованием алгоритма RED предложенного в [FJ93, RFC2309]. По имеющимся у авторов сведениям этот вариант является единственным предложением, обсуждаемым IETF для упреждающего отбрасывания пакетов маршрутизаторами до переполнения буферов. Однако данный документ не пытается задавать тот или иной механизм активного управления очередями, оставляя решение этого вопроса (если он возникнет) за IETF. Хотя использование ECN связано с вопросом о необходимости иметь подходящий механизм активного управления очередями в маршрутизаторах, авторы не настаивают на использовании именно этого механизма. Методы активного управления очередями были разработаны и развернуты независимо от ECN с отбрасыванием пакетов для индикации насыщения еще до начала использования ECN в архитектуре IP.

5.1. ECN как индикация установившегося насыщения

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

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

Мы продолжаем поощрять эксперименты с методами реализации преимуществ ECN на уровне 2 (например, в коммутаторах ATM или Frame Relay). К примеру, использования схема типа RED (когда пакеты маркируются на основе превышения средним размером очереди заданного порога), устройства канального уровня могут обеспечивать достаточно надежную индикацию насыщения. Когда все устройства уровня 2 на пути установят принятый на этом уровне маркер возможного насыщения (например, бит EFCI для ATM или бит FECN для Frame Relay) в использованием надежного детектирования перегрузки, интерфейс маршрутизатора в сеть уровня 2 сможет транслировать такие маркеры в маркеры CE заголовков IP. Мв ы признаем, что в сегодняшней практике и стандартах такого не наблюдается. Однако продолжение экспериментов в этом направлении может дать информацию, которая позволит найти способ перехода от существующих механизмов канального уровня к более надежной индикации насыщения с использованием для индикации перегрузки одного бита.

5.2. Отброшенные и поврежденные пакеты

Для предлагаемого в этом документе использования ECN (т. е., для транспортных протоколов типа TCP, в которых отбрасывание данных является индикацией насыщения) конечные узлы детектируют отбрасывание пакетов данных и отклик (о насыщении) от обнаруживших такое отбрасывание конечных узлов имеет по крайней мере такую же силу, как отклик на получение пакета CE. Для обеспечения гарантии доставки индикации насыщения с помощью кода CE недопустимо передавать код ECT в пакете, пока потеря пакета в сети не будет обнаружена конечными узлами и интерпретирована как индикация перегрузки.

Транспортные протоколы типа TCP не обязательно детектируют отбрасывание любых пакетов (в частности, пакетов, содержащих лишь подтверждение ACK); например, TCP не снижает скорость доставки последующих пакетов ACK в ответ на ранее отброшенные пакеты ACK. Любые предложения по расширению ECN-Capability на такие пакеты будут приводить к возникновению проблем, таких, как маркировка пакета ACK кодом CE и последующее отбрасывание такого пакета в сети. Мы надеемся, что этот аспект будет исследован специально, поэтому в настоящем документе указывается, что «чистые» пакеты ACK недопустимо использовать для индикации ECN-Capability.

Аналогично, если пакет с маркировкой CE отбрасывается в сети по причине повреждения (битовые ошибки), конечным узлам следует по-прежнему вводить контроль насыщения так же, как TCP реагирует в настоящее время на отбрасывание пакета данных. Вопрос повреждения пакетов CE будет рассматриваться в любых предложениях по способам определения был пакет отброшен в результате повреждения или по причине перегрузки или переполнения буфера. В частности, повсеместное развертывание ECN не будет мерой, достаточной для того, чтобы позволить конечным узлам интерпретировать отбрасывание пакетов, как результат повреждения, а не насыщения.

5.3. Фрагментация

Поддерживающие ECN пакеты могут иметь установленный влаг DF (не фрагментировать). При сборке фрагментов недопустимо терять индикацию насыщения. Иными словами, если любой из фрагментов собираемого пакета IP имеет код CE, должны выполняться одно из двух действий:

  • Установка кода CE для собранного пакета. Однако недопустимо устанавливать этот код, если хотя бы один из собираемых фрагментов имеет код Not-ECT.

  • Отбрасывание пакета вместо сборки фрагментов (по любой причине).

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

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

Могут возникать ситуации, когда приведенная выше спецификация сборки фрагментов будет недостаточно точна. Например, при наличии враждебных или сбойных элементов пути в точке фрагментации или после нее, пакеты фрагментов могут содержать смесь кодов ECT(0), ECT(1) и/или Not-ECT. Спецификация сборки фрагментов, приведенная выше, не включает требований к сборке фрагментов в таком случае. В ситуациях, когда требуется более определенное поведение при сборке фрагментов, спецификации протокола следует вместо этого указывать, что по всех передаваемых протоколом пакетах, способных поддерживать ECN, должен устанавливаться флаг DF.

6. Поддержка со стороны транспортного протокола

ECN требует поддержки со стороны транспортного протокола в дополнение к функциональности, обеспечиваемой полем ECN в заголовке пакета IP. Транспортный протокол может требовать согласования между конечными точками при организации соединения для проверки поддержки ECN, чтобы отправитель мог устанавливать код ECT в передаваемых пакетах. Во-вторых, транспортный протокол должен быть способен соответствующим образом реагировать на получение пакетов CE. Эта реакция может выражаться в форме информирования получателем отправителя данных о полученном пакете CE packet (e.g., TCP), отказа получателя от участия в многоуровневой multicast-группе (например, RLM [MJV96]) или в ином виде, обеспечивающем, в конечном итоге, снижение скорости поступления потока данных через перегруженное соединение. Пакеты CE показывают скорее долговременное, чем краткосрочное насыщение (см. параграф 5.1) и, следовательно, реакция на получение пакетов CE должна соответствовать продолжительной перегрузке.

В этом документе рассматривается добавление поддержки ECN только для протокола TCP, а рассмотрение вопросов использования ECN в других транспортных протколах оставлены для будущих исследований. Для TCP добавление ECN требует поддержки трех функций: согласование между конечными точками в процессе организации соединения для проверки поддержки ECN на обеих сторонах; флаг ECN-Echo (ECE) в заголовке TCP, чтобы получатель мог информировать отправителя о получении пакета CE; флаг CWR (Congestion Window Reduced — окно насыщения уменьшено) в заголовке TCP, чтобы отправитель мог информировать получателя о снижении размера окна насыщения. Очевидно, что функциональность, требуемая от других протоколов (в частности, протоколов групповой адресации с гарантиями доставки и без таковых), будет отличаться и определится при стандартизации этих транспортных протоколов в IETF.

В этом документе используется термин «пакеты TCP» вместо «сегментов TCP», что не вполне корректно терминологически.

6.1. TCP

В последующих параграфах детально рассматривается предложенное использование ECN в TCP. Эти предложения представлены в той же форме, что и в работе [Floyd94]. Предполагается, что TCP на стороне отправителя использует стандартные алгоритмы контроля насыщения Slow-start, Fast Retransmit и Fast Recovery [RFC2581].

Это предложение задает два новых флага в резервном поле заголовка TCP. Механизм TCP для согласования поддержки ECN использует флаг ECE (ECN-Echo) в заголовке TCP. Бит 9 в поле Reserved заголовка TCP предназначен для использования в качестве флага ECN-Echo. Местоположение 6-битового резервного поля заголовка TCP показано на рисунке 4 в RFC 793 [RFC793], воспроизведенном здесь для полноты. Данная спецификация поля ECN оставляет 4-битовое резервное поле (биты 4 — 7).

Чтобы обеспечить получателю TCP возможность определения момента прекращения установки флага ECN-Echo, в заголовок TCP добавлен еще один флаг — CWR. Для флага CWR выделен бит 8 резервного поля в заголовке TCP.

  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 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Рисунок 3: Старое определение байтов 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 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Рисунок 4: Новое определение байтов 13 и 14 в заголовке TCP

Таким образом, ECN использует флаги ECT и CE в заголовке IP (см. Рисунок 1) для сигнализации между маршрутизаторами и конечными точками соединений, а также флаги ECN-Echo и CWR в заголовке TCP (Рисунок 4) для сигнализации между конечными точками TCP. Для соединения TCP типичная последовательность событий в основанной на ECN реакции на перегрузку имеет вид:

  • В передаваемых отправителем пакетах устанавливается код ECT для индикации поддержки ECN для этих пакетов транспортыми элементами.

  • Поддерживающий ECN маршрутизатор детектирует приближающееся насыщение и видит код ECT в пакете, намеченном для отбрасывания. Вместо отбрасывания этого пакета маршрутизатор устанавливает код CE в заголовке IP и пересылает пакет.

  • Получатель принимает пакет с кодом CE и устанавливает флаг ECN-Echo в следующем пакете TCP ACK, передаваемом отправителю.

  • Отправитель получает пакет TCP ACK с флагом ECN-Echo и реагирует на перегрузку как в случае отбрасывания пакета.

  • Отправитель устанавливает флаг CWR в заголовке TCP следующего пакета, передаваемого получателю, для подтверждения приема и реакции на флагECN-Echo.

Согласование использования ECN транспортными элементами TCP, а также использование флагов ECN-Echo и CWR более подробно описаны в последующих параграфах.

6.1.1 Инициализация TCP

На этапе организации соединения TCP модули TCP на стороне отправителя и получателя обмениваются информацией о своем намерении использовать ECN. После завершения этого согласования отправитель TCP устанавливает код ECT в заголовке IP пакета данных для индикации сетевым устройствам возможности и желания использовать ECN для этого пакета. Этот код показывает маршрутизаторам, что они могут маркировать данный пакет кодом CE, если они хотят использовать такой метод индикации насыщения. Если соединение TCP не хочет использовать ECN-уведомление для отдельного пакета, передающая сторона TCP устанавливает в качестве кода ECN значение not-ECT, а получатель TCP игнорирует код CE в полученном пакете.

В дальнейшем обсуждении будем обозначать инициирующий соединение хост, как A, а отвечающий — B. Будем называть пакет SYN с флагами ECE и CWR «SYN-пакетом организации ECN», а пакет SYN, в котором один из флагов ECE или CWR сброшен — «пакетом SYN без организации ECN». Аналогично будем называть пакет SYN-ACK с флагом ECE, но без флага CWR «SYN-ACK-пакетом организации ECN», а пакет SYN-ACK с любой другой комбинацией флагов ECE и CWR — пакетом «SYN-ACK без организации ECN».

Прежде, чем соединение TCP сможет использовать ECN, хост A передает SYN-пакет организации ECN, а хост B передает пакет SYN-ACK с организацией ECN. Для пакета SYN установка обоих флагов ECE и CWR в SYN-пакете с организацией ECN определяется, как индикация поддержки ECN на передающей стороне TCP, а не индикация насыщения или отклика на насыщение. Говоря точнее, пакет SYN с организацией ECN показывает, что реализация TCP, передающая пакет SYN будет принимать участие в ECN как отправитель и получатель. В качестве получателя она будет отвечать на пакеты данных с кодом CE в заголовке IP установкой флага ECE в исходящих подтверждениях TCP ACK. В качестве отправителя она будет отвечать на входящие пакеты с флагом ECE снижением размера окна насыщения и установкой флага CWR, когда это следует делать. Пакет SYN с организацией ECN не обязывает отправителя TCP устанавливать код ECT в каком-либо или всех пакетах, которые он может передать. Однако обязанность подобающим образом отвечать на входящие пакеты с кодом CE сохраняется даже в том случае, когда отправитель TCP позднее в сеансе TCP передает пакет SYN без установленных флагов ECE и CWR.

Когда хост B передает пакет SYN-ACK с организацией ECN, он устанавливает флаг ECE, но не устанавливает флаг CWR. Пакет SYN-ACK с организацией ECN рпределяется, как индикация того, что узел TCP, передавший пакет SYN-ACK, поддерживает ECN. Как и пакет SYN, пакет SYN-ACK с организацией ECN не обязывает хост TCP устанавливать код ECT в передаваемых пакетах.

Приведенные ниже правила применяются для пакетов организации ECN в соединении TCP, определяемом стандартными правилами организации и разрыва соединений TCP.

  • Если хост получил SYN-пакет с организацией ECN, он может передать пакет SYN-ACK в организацией ECN. В остальных случаях передача пакетов SYN-ACK в организацией ECN недопустима.

  • Для хоста недопустима установка ECT в пакетах данных, пока этот хост не передал хотя бы один пакет SYN или SYN-ACK с установкой ECN и не получил хотя бы один пакет SYN или SYN-ACK с организацией ECN, не передаваея пакетов SYN или SYN-ACK без организации ECN. Если хост получил хотя бы один пакет SYN или SYN-ACK ьез организации ECN, ему не следует устанавливать ECT в пакетах данных.

  • Если хост установил код ECT в пакете данных, он должен корректно устанавливать/сбрасывать флаг CWR в заголовках TCP всех последующих пакетов данного соединения.

  • Если хост передал хотя бы один пакет SYN или SYN-ACK с организацией ECN и не получал пакетов SYN или SYN-ACK без организации ECN, тогда этот хост при получении пакетов данных TCP с кодами ECT и CE в заголовке IP должен обрабатывать такие пакеты, как задано для соединений, поддерживающих ECN.

  • Хосту, не желающему использовать ECN в соединении TCP, следует сбрасывать оба флага ECE и CWR во всех пакетах SYN и SYN-ACK без организации ECN, которые он передает для индикации своего нежелания. Получатели должны корректно обрабатывать все формы пакетов SYN и SYN-ACK без организации ECN.

  • Для хоста недопустимо устанавливать ECT в пакетах SYN или SYN-ACK.

Клиент TCP переходит в состояние TIME-WAIT после получения пакета FIN-ACK и потом в состояние CLOSED по истечении тайм-аута. Многие реализации TCP создают в состоянии TIME-WAIT новое соединение, если получают в окне пакет SYN. Когда хост TCP переходит в состояние TIME-WAIT или CLOSED, ему следует игнорировать все прежние данные о согласовании ECN для данного соединения.

6.1.1.1. Промежуточные устройства

ECN вносит два новых флага ECN-Echo и CWR в заголовок TCP (см. Рисунок 3) для инициализации. В Internet существуют некоторые некорректно работающие межсетевые экраны, устроства балансировки и системы детектирования вторжений, которые отбрасывают SYN-пакеты с организацией ECN или передают в ответ пакет RST, ошибочно воспринимая установленные в заголовке флаги, как сигнатуры сканирования портов, которое может использоваться для организации атак на службы (DoS). Часть таких устройств идентифицирована и на сайте [FIXES] приведен их список с указанием рекомендуемых производителями исправлений, если они имеются. На сайте TBIT [TBIT] перечислены некоторые web-серверы, на которые оказывает влияние такое оборудование. Эти списки могут служить предостережением о существовании описанной выше проблемы.

Для обеспечения отказоустойчивых соединений даже при наличии некорректно работающих устройств, хост, получающий пакет RST в ответ на передачу пакета SYN с организацией ECN, может повторить передачу пакета SYN со сброшенными флагами CWR и ECE. Это может позволить организацию соединения TCP без использования ECN.

Хост, не получивший отклика на пакет SYN с организацией ECN в течение обычного времени ожидания для повтора SYN может повторить передачу пакета SYN со сброшенными флагами CWR и ECE. Для предотвращения влияния обычной потери пакета SYN исходный хост может передать один или несколько повторных пакетов SYN с организацией ECN до начала передачи пакетов SYN со сброшенными флагами CWR и ECE.

Отметим, что в таких случаях возможен следующий сценарий:

  1. Хост A передает пакет SYN с организацией ECN.
  2. Хост B передает пакет SYN/ACK с организацией ECN, который отбрасывается или задерживается.
  3. Хост A передает пакет SYN без организации ECN.
  4. Хост B передает пакет SYN/ACK без организации ECN.

Отметим, что в этом случае, следуя описанной выше процедуре ни хост A, ни хост B не могут устанавливать бит ECT в пакетах данныъ. Более того, важным следствием правил организации и использования ECN, приведенных в параграфе 6.1.1, является то, что хосту в таких случаях запрещено принимать пакеты данных с ECT, поскольку это неявно говорит об отсутствии поддержки ECN на другом хосте.

6.1.1.2. Отказоустойчивая инициализация TCP с возвратом битов резервного поля

Возникает вопрос, почему для пакетов SYN используется два связанных с ECN флага в резервном поле заголовка TCP, тогда как в ответном пакете SYN-ACK устанавливается только один связанный с ECN флаг. Такая асимметрия нужна для отказоустойчивого согласования поддержки ECN с некоторыми имеющимися реализациями TCP. Существует по крайней мере одна некорректно работающая реализация TCP, в которой получатели устанавливают в поле Reserved в заголовке TCP пакетов ACK (и, следовательно, SYN-ACK) просто отражение поля Reserved из заголовка TCP принятого пакета данных. Поскольку в пакете TCP SYN для индикации поддержки ECN устанавливаются флаги ECN-Echo и CWR, а в пакетах SYN-ACK — только флаг ECN-Echo, передающая сторона TCP корректно интерпретирует отражение получателем своих флагов, как индикацию отсутствия поддержки ECN на приемной стороне. Передающая сторона TCP в результате не вводится в заблуждение некорректными реализациями TCP, передающими пакеты SYN-ACK с отражением поля Reserved из принятого пакета SYN.

6.1.2. Отправитель TCP

Для соединений TCP, использующих ECN, новые пакеты данных передаются с кодом ECT в заголовке IP. Когда отправителю нужен только один код ECT для всех пакетов, передаваемых в соединении TCP, следует использовать ECT(0). Если отправитель получает пакет ECN-Echo (ECE) ACK (т. е., пакет ACK с флагом ECN-Echo в заголовке TCP), отправитель узнает о том, что в сети на пути к получателю имеется насыщение. Индикацию насыщения следует трактовать просто как потерю в результате насыщения для TCP без поддержки ECN. Т. е., отправитель TCP снижает вдвое размер окна насыщения cwnd и уменьшает порог замедленного старта ssthresh. Передающему модулю TCP не следует увеличивать окно насущения в ответ на получение пакета ECN-Echo ACK.

TCP не следует неагировать на индикацию насыщения более одного раза в каждом окне данных (или более одного раза за период кругового обхода). Т. е., окно насыщения у отправителя TCP следует уменьшать однократно в ответ на серию отброшенных или помеченных CE пакетов из одного окна данных. Кроме того, отправиттелю TCP не следует уменьшать значение порога ssthresh, если оно уже было снижено в последний период кругового обхода. Однако отбрасывание повторно переданных пакетов интерпретируется отправителем TCP, как новый факт перегрузки.

После того, как отправитель TCP уменьшает окно насыщения в ответ на пакет CE, входящие подтверждения, которые продолжают приходить, могут влиять на передачу исходящих пакетов, дозволенных уменьшенным окном насыщения. Если окно насыщения содержит только один MSS (максимальный размер сегмента) и передающий модуль TCP получает пакет ECN-Echo ACK, передающему TCP следует, в принципе, продолжать уменьшение окна насыщения вдвое. Однако размер окна насыщения ограничен снизу значением в 1 MSS. Если передающий модуль TCP будет продолжать передачу, используя окно насыщения размером 1 MSS, это приведет к передаче одного пакета за период кругового обхода. Требуется дальнейшее снижение скорости передачи TCP в ответ на получение пакета ECN-Echo при окне насыщения размером 1 MSS. Мы используем таймер повтора передачи в качестве меры снижения скорости в таких ситуациях. Следовательно, передающий модуль TCP должен сбрасывать таймер повтора при получении пакета ECN-Echo в случае единичного размера окна насыщения. Передающий модуль TCP в результате сможет передать новый пакет только после завершения отсчета таймера повтора.

Когда поддерживающий ECN отправитель TCP снижает по какой-либо причине (тайм-аут повтора, ускоренный повтор — Fast Retransmit или отклик на ECN Notification) размер окна насыщения, он устанавливает флаг CWR в заголовке TCP первого пакета, передаваемого после уменьшения окна. Если пакет данных отбрасывается в сети, передающий модуль TCP будет снова уменьшать окно насыщения и повторять передачу отброшенного пакета.

Мы гарантируем, что информация об уменьшении окна насыщения (флаг CWR) надежно доставляется получателю TCP. Это основано на том, что при отбрасывании нового пакета данных, содержащего флаг CWR, отправитель TCP будет повторно снижать размер окна насыщения и передавать новый пакет данных с установленным флагом CWR. Таким образом, бит CWR в заголовке TCP не следует устанавливать для повторно передаваемых пакетов.

Когда отправитель TCP готов установить флаг CWR после снижения размера окна насыщения, ему следует устанавливать этот флаг только в первом передаваемом после уменьшения окна пакете данных.

В работе [Floyd94] обсуждается реакция TCP на ECN более детально. В работе [Floyd98] рассматривается тест с использованием эмулятора ns, который иллюстрирует множество сценариев ECN, включая ECN, за которым следует другой ECN, Fast Retransmit или Retransmit Timeout, Retransmit Timeout или Fast Retransmit, за которым следует ECN, окно насыщения в один пакет, за которым следует ECN.

TCP следует существующим алгоритмам передачи пакетов данных в ответ на прием пакета ACK, дубликаты подтверждений или тайм-аут повтора [RFC2581]. TCP также следует обычным процедурам увеличения размера окна насыщения при получении пакетов ACK без флага ECN-Echo [RFC2581].

6.1.3. Получатель TCP

Когда TCP получает пакет данных CE на стороне получателя, приемный модуль TCP устанавливает флаг ECN-Echo в заголовке TCP следующего пакета ACK. Если на приемной стороне уже есть ожидающий пакет ACK (как в современных реализациях TCP с задержкой подтверждений, передающих пакет ACK по прибытии каждого второго пакета данных) тогда флаг ECN-Echo устанавливается в пакете ACK, если код CE был установлен для любого из подтверждаемых пакетов данных. Т. е., если в любом из подтверждаемых пакетов имеется маркировка CE, возвращаемый пакет ACK будет иметь флаг ECN-Echo.

Для обеспечения устойчивости к отбрасыванию пакетов ACK с флагом ECN-Echo, получатель TCP устанавливает этот флаг в передаваемых впоследствии пакетах ACK. Прекращение передачи флага ECN-Echo получатель TCP инициирует при получении флага CWR в пакете данных от передающей стороны TCP.

После того, как получатель a TCP передает пакет ACK с установленным флагом ECN-Echo, он продолжает устанавливать этот флаг во всех передаваемых пакетах ACK (подтверждающих как пакеты данных с маркером CE, так и пакеты данных без маркера), пока не получит пакет с флагом CWR. После получения пакета CWR подтверждения для последующих пакетов без маркера CE передаются без флага ECN-Echo. Если получатель данных принимает другой пакет CE, он снова начинает передавать пакеты ACK с флагом ECN-Echo. Хотя получение пакета CWR не гарантирует получение отправителем пакета с флагом ECN-Echo, это событие говорит о том, что отправитель уменьшил размер окна насыщения в какой-то момент «после» того, как он передал пакет данных, для которого был установлен маркер CE.

Выше уже было отмечено, что отправитель TCP не должен снижать размер окна насыщения более одного раза в окне данных. Требуются некоторые меры по предотвращению многократного снижения размера окна, когда окно данных включает как отброшенные пакеты, так и пакеты с маркером CE. Этот вопрос рассматривается в работе [Floyd98].

6.1.4. Насыщение на пути пакета ACK

В существующих реализациях механизмов контроля насыщения TCP чистые пакеты подтверждения (т. е., пакеты, содержащие только подтверждение без дополнительных данных) должны передаваться с кодом not-ECT. Современные получатели TCP не имеют механизмов снижения трафика на пути пакетов ACK в ответ на индикацию насыщения. Механизмы отклика на перегрузку в пути доставки пакетов ACK являются предметом современных и будущих исследований (одним из возможных вариантов может служить снижение отправителем размера окна насыщения при получении чистого пакета ACK с кодом CE). Для современных реализаций TCP отбрасывание одного пакета ACK в общем случае оказывает пренебрежимо молое влияние на скорость передачи TCP.

6.1.5. Повторно переданные пакеты TCP

Этот документ указывает, что поддерживающим ECN реализациям TCP недопустимо устанавливать код ECT (ECT(0) или ECT(1)) в заголовке IP для повторно передаваемых пакетов данных, а получателю данных TCP следует игнорировать поле ECN в прибывающих пакетах данных, которые находятся за пределами текущего окна получателя. Это сделано для обеспечения более эффективной защиты от атак на службы, а также устойчивости к индикации насыщения ECN в пакетах, которые позднее отбрасываются в сети.

Во-первых, отметим, что если отправитель TCP будет устанавливать код ECT в повторно передаваемых пакетах, тогда в случаях отбрасывания переданных повторно без необходимости пакетов в сети конечные точки никогда не получат индикации насыщения от маршрутизатора, устанавливающего код CE. Таким образом, установка кода ECT в повторно передаваемых пакетах несовместима с отказоустойчивой доставкой индикации насыщения даже при последующем отбрасывании пакетов в сети.

Кроме того, атакующий может подменить IP-адрес отправителя TCP и передать пакеты данных с произвольными порядковыми номерами и установленным кодом CE в заголовке IP. При получении такого обманного пакета данных приемный модуль TCP будет считать, что данные не относятся к текущему окну приема и возвращать дубликаты подтверждений. Мы определяем пакеты, находящиеся за пределами окна на стороне получателя TCP, как пакеты, лежащие за пределами текущего окна получателя. При получении такого пакета принимающий модуль TCP решает следует ли трактовать код CE в заголовке пакета, как корректную индикацию насыщения и, следовательно, нужно ли возвращать индикацию ECN-Echo отправителю данных TCP. Если получетль TCP игнорирует код CE в пакете данных за пределами окна, отправитель TCP не получит (возможно легитимной) индикации насыщения в сети, что приведет к нарушению сквозного контроля насыщения. С другой стороны, если получатель данных TCP воспримет индикацию CE из пакетов за пределами окна и покажет насыщение отправителю данных TCP, вредоносный узел, создавший обманные пакеты, лежащие за пределами окна, сможет успешно «атаковать» соединение TCP, заставляя отправителя данных без необходимости снижать (вдвое) размер окна насыщения. Для предотвращения таких атак на службы мы указываем, что для легитимного отправителя TCP недопустима установка кода ECT в передаваемых повторно пакетах данных, а получателю данных TCP следует игнорировать код CE в пакетах, лежащих за пределами окна.

Негативным эффектом отказа от установки ECT(0) или ECT(1) в повторно передаваемых пакетах является то, что в результате этого отключается ECN-защита для передаваемых повторно пакетов. Однако для поддерживающих ECN соединений TCP в полностью поддерживающей ECN среде со средним уровнем насыщения пакеты будут редко отбрасываться в результате насыщения, поэтому повторно передаваемые пакеты в большинстве случаев не будут теряться. Повторная передача пакета говорит о том, что потери пакетов уже наблюдались (в результате повреждения или перегрузки) и ECN все равно не поможет предотвратить возможную потерю.

Отметим, что если маршрутизатор устанавливает код CE для совместимого с ECN пакета данных в соединении TCP, тогда для этого соединения гарантируется получение индикации насыщения в том же окне данных даже при отбрасывании или нарушении порядка доставки пакетов в сети. Мы рассматриваем здесь два случая — когда пакеты позднее передаются повторно и когда они повторно не передаются.

В первом случае при отбрасывании или задержке пакета и повторе передачи отправителем этот повтор является результатом использования алгоритма Fast Retransmit или Retransmit Timeout для данного пакета или кокого-то из его предшественников в том же окне данных. Поскольку отправитель уже передал этот пакет повторно, мы знаем, что отправитель уже откликнулся на индикацию насыщения для какого-то из пакетов в том же окне данных, что и исходный пакет. Таким образом, даже при отбрасывании или задержке первого пакета в сети, если у него был установлен код CE и пакет был потом проигнорирован получателем, как выходящий за пределы окна, это не создает проблем, поскольку отправитель уже отреагировал на индикацию насыщения в этом окне данных.

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

6.1.6. Пробы окна TCP

Когда получатель TCP анонсирует окно нулевого размера, отправитель TCP передает прбы окна для определения возможности увеличесния окна на приемной стороне. Пакеты проб не содержат пользовательских данных за исключением однобайтового порядкового номера. Если пакет пробы отбрасывается в сети, получатель не видит такой потери. Следовательно, отправителю TCP недопустимо устанавливать код ECT или флаг CWR в пакетах проб.

Однако, благодаря порядковым номерам в пробных пакетах, эти пакеты невозможно просто подменить в DoS-атаке. Следовательно, если пробный пакет приходит с кодом CE, получателю следует реагировать на индикацию ECN.

7. Неподатливость конечных узлов

В этом разделе рассматривается опасность ECN для non-compliant конечных узлов (т. е., узлов, которые устанавливают код ECT в передаваемых пакетах, но не реагируют на получение пакетов с кодом CE). Мы понимаем, что добавление ECN в архитектуру IP не повышает сколь-нибудь существенно общий уровень уязвимости архитектуры к невосприимчивым потокам.

Даже для сред, не поддерживающих ECN, следует серьезно рассматривать возможность нарушений, которые могут быть вызваны неподатливыми или невосприимчивыми потоками (т. е., потоками, которые не отвечают на индикацию насыщения снижением скорости доставки через загруженный канал). Например, конечная точка может «отключить контроль насыщения», не снижая размер окна насыщения в ответ на отбрасывание пакетов. Эта проблема важна для современного состояния Internet. Ясно, что в маршрутизаторах нужно реализовать механизмы детектирования и дифференцированной трактовки пакетов из неподатливых потоков [RFC2309,FF99]. Предполагается также, что такие методы, как сквозное планирование на уровне потока и изоляция потоков друг от друга, дифференцированные услуги или сквозное резервирование могут устранить некоторые из наиболее разрушительных эффектов от невосприимчивых потоков.

Может показаться, что само по себе отбрасывание пакетов является средством сдерживания неподатливости, а использование ECN устраняет эту проблему. Мы утверждаем, в ответ на это, что (1) поддерживающие ECN маршрутизаторы сохраняют возможность отбрасывания пакетов при сильной перегрузке и (2) даже в случаях сильной перегрузки отбрасывание пакетов не столь страшно, как неподатливость.

Во-первых, поддерживающие ECN маршрутизаторы будут только маркировать пакеты (вместо их отбрасывания), пока частота маркирования достаточно мала. В периоды, когда средний размер очереди превышает верхний порог и, следовательно, потенциальная скорость маркировки пакетов будет велика, мы рекомендуем маршрутизатору отбрасывать пакеты вместо установки в них кода CE в заголовках.

В периоды с низкой и средней скоростью маркировки пакетов, когда поддержка ECN реализована, будет возникать некий негативный эффект для невосприимчивых потоков в виде отбрасывания пакетов вместо их маркировки. Например, для нечувствительных к задержкам потоков, использующих гарантированную доставку, может наблюдаться увеличение скорости вместо ее снижения при отбрасывании пакетов. Аналогично для чувствительных к задержкам потоков без гарантированной доставки может возрастать использование FEC в ответ на рост частоты отбрасывания пакетов, приводящий скорее к росту, чем к снижению скорости передачи. По тем же причинам мы не верим, что отбрасывание пакетов само по себе является эффективным средством сдерживания для неподатливости даже в средах с высокой частотой отбрасывания пакетов, когда вероятность отбрасывания делится между всеми потоками.

Было предложено несколько методов идентификации и ограничения неподатливых и невосприимчивых потоков. Добавление ECN в сетевую среду никак не усложнит разработку и развертывание таких механизмов. Во всяком случае, добавление ECN в архитектуру будет существенно упрощать работу по идентификации невосприимчивых потоков. Например, в среде с поддержкой ECN маршрутизаторы не ограничиваются информацией о том, что пакет был отброшен или получил код на данном маршрутизаторе — в таких средах маршрутизаторы могут также отмечать прибытие пакетов с кодом CE, показывающих перегрузку, встреченную пакетом на своем пути раньше.

8. Неподатливость в сети

В этом разделе рассматриваются ситуации, когда маршрутизатор (возможно с враждебными целями) меняет какие-либо биты поля ECN. Отметим, что в IPv4 заголовок IP защищен от битовых ошибок контрольной суммой заголовка, но такая защита отсутствует в IPv6. Таким образом, для IPv6 поле ECN может быть непреднамеренно изменено в результате битовых ошибок в каналах или маршрутизаторах и такое изменение не будет обнаружено по причине отсутствия контрольной суммы.

Манипулируя битами поля ECN, враждебный (или некорректно работающий) маршрутизатор может приводить к возникновению ряда негативных эффектов, включая ложную информацию о перегрузках, запрет поддержки ECN для отдельных пакетов, удаление ECN-индикации насыщения или ложная индикация поддержки ECN. В разделе 18 результаты изменения полей ECN рассмотрены детально и систематизированы. Важным критерием учета последствий такого изменения является то, что оно может внсти к ухудшению поведения по целому ряду параметров (пропускная способность, задержка, беспристрастность, функциональность) даже по сравнению с отбрасыванием пакетов в маршрутизаторе.

В двух первых случаях (ложная информация о насыщении и запрет ECN-Capability для отдельного пакета) ситуация не хуже, чем при простом отбрасывании пакета маршрутизатором. С точки зрения системы контроля насыщения установка кода CE в отсутствии насыщения неподатливым маршрутизатором будет не хуже, чем неоправданное отбрасывание пакета маршрутизатором. За счет «удаления» кода ECT в пакете, который позднее будет отброшен в сети, действия маршрутизатора могут привести к неоправданному последующему отбрасыванию пакета в сети.

Однако, как отмечено в разделе 18, маршрутизатор, способный удалять ECN-индикацию перегрузки или ложно указывать поддержку ECN, может наносить больший ущерб, нежели простое отбрасывание пакета. Враждебный или некорректно работающий маршрутизатор, который «удаляет» код CE в приходящих к нему пакетах CE, будет удалять индикацию насыщения, приходящую от получателей (нисходящих, по отношению к маршрутизатору). Это может приводить к отказам системы контроля насыщения для потоков и дальнейшему росту насыщения в сети, ведущему к нарастающему отбрасыванию последующих пакетов потока по мере роста среднего размера очереди на перегруженном шлюзе.

В разделе 19 рассмотрены возможные результаты нарушения сквозного контроля насыщения за счет ложной индикации ECN-Capability или удаления индикации насыщения ECN (кода CE). Показано, что в результате нарушения основанного на ECN контроля насыщения может теряться беспристрастность промежуточных устройств, но это влияние явно не будет хуже, чем при потере конечными узлами контроля насыщения на основе отбрасывания пакетов или ECN.

8.1. Осложнения, связанные с расщеплением пути

Если маршрутизатор или другой элемент сети имеет доступ ко всем пакетам потока, это устройство не может нанести потоку путем изменения поля ECN большего вреда, чем будет нанесен простым отбрасыванием пакетов из потока. Однако в некоторых случаях враждебный или некорректно настроенный маршрутизатор может получить доступ к единственному подмножеству пакетов из потока. Возникает вопрос — сможет ли такой маршрутизатор путем изменения поля ECN в данном подмножестве пакетов нанести больший вред, нежели путем простого отбрасывания этого набора пакетов?

Этот вопрос также детально рассматривается в разделе 18 и делается следующее заключение — верно, что злоумышленник, имеющий доступ лишь к подмножеству пакетов может, путем повреждения контроля насыщения на основе ECN, оказаться способны свести на нет преимущества ECN для других пакетов потока. Это нежелательно, но не может служить достаточным основанием для отказа от ECN.

9. Инкапсулированные пакеты

9.1. Пакеты IP, инкапсулированные в IP

Инкапсуляция заголовков пакетов IP в туннели используется во многих случаях, включая IPsec и IP in IP [RFC2003]. В этом разделе рассматриваются вопросы, связанные со взаимодействием между ECN и IP, а также описаны два дополнительных решения. Это обсуждение дополняется рассмотрением в RFC 2983 взаимодействия между дифференцированным обслуживанием (DifServ) и различными формами туннелей IP [RFC 2983], а также использования в DifServ оставшихся 6 битов заголовка IP, не занятых ECN (см. Рисунок 2 в разделе 5).

Некоторые режимы туннелей IP основаны на добавлении нового «внешнего» заголовка IP, который инкапсулирует исходный или «внутренний» заголовок IP и связанный с ним пакет. Во многих случаях «внешний» заголовок может добавляться и удаляться на промежуточных точках соединения, что позволяет создавать туннели без участия конечных точек в их организации. Будем называть туннели, которые задают отбрасывание внешнего заголовка на выходе «простыми туннелями».

ECN использует поле ECN в заголовке IP для передачи сигнализации между маршрутизаторами и конечными точками соединений. ECN взаимодействует с туннелями IP на базе трактовки поля ECN в заголовке IP. В простых туннелях IP октет, содержащий поле ECN копируется или отображается из внутреннего заголовка IP во внешний заголовок на входе туннеля IP, а на выходе из туннеля внешняя копия этого поля просто отбрасывается. Если внешний заголовок просто отбрасывается без обработки поля ECN, а поддерживающий ECN маршрутизатор установил код CE (присутствует насыщение) в заголовке простого туннеля IP, эта индикация будет отброшена на выходе из туннеля и конечный узел не узнает о перегрузке.

Таким образом, использование ECN с простыми туннелями IP будет приводить к тому, что маршрутизаторы будут пытаться сигнализировать о насыщении с помощью внешнего заголовка, но эта индикация не будет получена в результате отбрасывания поля на выходе из туннеля. Эта проблема возникает при использовании ECN с IPsec в туннельном режиме и RFC 2481 рекомендует отказаться от использования ECN со старыми простыми туннелями IPsec во избежание упомянутого негативного эффекта и его последствий. По мере распространения ECN простые туннели должны будут измениться для обеспечения передачи поддерживающего ECN трафика. Если поддерживающий ECN трафик передается через простой туннель и сталкивается с насыщением на поддерживающем ECN маршрутизаторе, это может привести к отбрасыванию последующих пакетов в зависимости от роста среднего размера очередей на перегруженном маршрутизаторе, как было отмечено в разделе 8.

С точки зрения безопасности использование ECN во внешнем заголовке туннеля IP может вызывать проблемы, поскольку злоумышленник может изменять информацию ECN, передаваемую между конечными точками туннеля. На основе результатов анализа в разделах 18 и 19 с учетом отмеченной проблемы и связанного с ней риска предлагается включать поддержку ECN, как опцию для туннелей IP, чтобы при настойке туннеля можно было задать использование ECN во внешнем заголовке туннеля или отказ от такого использования. Таким образом в средах и протоколах с туннелированием, где риск в результате использования ECN больше, чем обеспечиваемые преимущества, туннель может просто не использовать ECN в своем внешнем заголовке. В этом случае единственным способом индикации перегрузки маршрутизатора становится отбрасывание пакетов.

В результате возникают два жизнеспособных варианта поведения поддерживающих ECN соединений через туннели IP, включая IPsec:

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

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

Одной из задач данного документа является определение компромисса между полнофункциональным и ограниченным вариантами. Полное обсуждение потенциальных эффектов враждебного изменения поля ECN приведено в разделах 18 и 19.

9.1.1. Опции ограниченной и полной функциональности

Опция ограниченной функциональности для инкапсуляции ECN в туннели IP обеспечивается путем установки кода not-ECT во внешнем (инкапсулирующем) заголовке, независимо от значения поля ECN во внутреннем (инкапсулируемом) заголовке. В этом случае поле ECN внутреннего заголовка не меняется при декапсуляции. Недостатком этого варианта является отсутствие поддержки ECN для части пути, использующей туннелирование IP, даже в тех случаях, когда инкапсулированный пакет (от исходного отправителя TCP) поддерживает ECN. Если инкапсулированный пакет приходит на перегруженный маршрутизатор, который поддерживает ECN и маршрутизатор принимает решение об отбрасывании или маркировке пакета для индикации насыщения конечному узлу, маршрутизатору не разрешается установить код CE в заголовке пакета и вместо этого приходится отбрасывать пакет.

Полнофункциональная опция инкапсуляции ECN использует копирование кода ECN из внутреннего заголовка во внешний, если внутренний заголовок not-ECT или ECT, и установки для внешнего заголовка ECT(0), если код ECN во внутреннем заголовке имеет значение CE. При декапсуляции код CE, если он установлен, копируется из внешнего заголовка во внутренний. В остальных случаях код ECN во внутреннем заголовке остается неизменным. Т. е., при полной поддержке ECN процессы инкапсуляции и декапсуляции включают ряд операций. На входе туннеля полнофункциональный вариант устанавливает код ECN во внешнем заголовке. Если код ECN во внутреннем заголовке имеет значение not-ECT или ECT, этот код копируется во внешний заголовок. Если код ECN во внутреннем заголовке имеет значение CE, для кода ECN во внешнем заголовке устанавливается значение ECT(0). При декапсуляции на выходе туннеля полнофункциональный вариант устанавливает код CE во внутреннем заголовке, если этот код был установлен во внешнем. В остальных случаях это поле внутреннего заголовка не меняется.

С полнофункциональной поддержкой поток может использовать преимущества ECN на тех участках пути, где может использоваться туннелирование IP. Недостаток полнофункционального варианта с точки зрения безопасности заключается в том, что туннель IP не может защитить поток от некоторых изменений поля ECN в заголовке IP. Потенциальные опасности такой замены битов ECN подробно рассмотрены в разделах 18 и 19.

  1. Туннель IP должен изменять обработку октета поля DS в конечных точках туннеля IP путем реализации ограниченной или полной функциональности.

  2. В дополнение к этому туннель IP может разрешить своим конечным точкам согласование выбора между полной и ограниченной функциональностью для ECN в туннеле.

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

Все туннели IP должны поддерживать опцию ограниченной функциональности и следует поддерживать также полнофункциональную опцию.

В дополнение к этому рекомендуется отбрасывать пакеты с кодом CE во внешнем заголовке, если они приходят на выход туннеля с ограниченной функциональностью или туннель поддерживает полнофункциональную опцию, но во внутреннем заголовке пакета установлен код not-ECT. Это нужно для совместимости с более ранними версиями и предотвращения несанкционированного изменения поля ECN. Более продробно этот вопрос рассматривается в следующем параграфе (9.1.2).

9.1.2. Изменения для поля ECN внутри туннелей IP

Наличие копии поля ECN во внутреннем заголовке туннелируемого пакета IP обеспечивает возможность обнаружения несанкционированного изменения поля ECN во внешнем заголовке. Для реализаций, соответствующих данному документу, при сравнении полей ECT во внутреннем и внешнем заголовке, нужно принимать во внимание два случая:

  • если туннель IP использует полнофункциональную опцию, то код not-ECT следует устанавливать во внешнем заголовке тогда и только тогда, когда он установлен во внутреннем заголовке;
  • если туннель использует опцию ограниченной функциональности, во внешнем заголовке следует устанавливать код not-ECT.

Получение пакета, не удовлетворяющего соответствующему условию, может быть поводом для беспокойства.

Рассмотрим случай, когда входная точка туннеля IP не была обновлена в соответствии с требованиями этого документа, а выходная точка была обновлена для поддержки ECN. В этом случае туннель IP не настроен явно на полнофункциональную поддержку ECN. Однако поведение входной точки идентично поведению входной точки туннеля с полнофункциональной поддержкой. Если пакет из поддерживающего ECN соединения использует такой туннель, на входе туннеля может быть установлен код ECT во внешнем заголовке. Насыщение в туннеле может привести к установке поддерживающим ECN маршрутизатором кода CE во внешнем заголовке. Поскольку туннель явно не настроен на поддержку полнофункциональной опции, выходная точка ожидает присутствия во внешнем заголовке кода not-ECT. Когда поддерживающая ECN выходная точка туннеля получает пакет с кодом ECT или CE во внешнем заголовке туннеля, который не настроен на поддержку полнофункциональной опции, этот пакет следует обрабатывать с учетом наличия кода CE. Рекомендуется для туннелей, не настроенных на поддержку полнофункциональной опции, отбрасывать пакет на выходе, если код CE установлен во внешнем заголовке, но отсутствует во внутреннем. Остальные пакеты следует пересылать.

Туннель IP не может обеспечить защиту от удаления индикации перегрузки путем замены кода ECN с CE на ECT. Уничтожение индикации перегружки может влиять на сеть и другие потоки так, как невозможно было бы повлиять в отсутствие ECN. Важно отметить, что удалить можно лишь те индикаторы насыщения, которые были установлены узлами внутри туннеля. Копия поля ECN во внутреннем заголовке сохраняет индикацию насыщения от узлов, расположенных до входа в туннель (если внутренний заголовок также не был изменен). Если уничтожение индикации перегрузки связано с риском, превышающим преимущества от контроля насыщения с помощью ECN, туннель следует настроить на поддержку ограниченной функциональности.

9.2. Туннели IPsec

IPsec поддерживает защищенную связь через небезопасные потенциально компоненты сети типа промежуточных маршрутизаторов. Протоколы IPsec поддерживают два режима работы — туннельный и транспортный, — которые обеспечивают выполнение широкого спектра требований по безопасности и работу в различных средах. Заголовок протокола защиты в транспортном режиме помещается между заголовком IP (IPv4 или IPv6) и заголовком протокола вышележащего уровня (например, TCP), следовательно в транспортном режиме защита обеспечивается в «сквозном» (между конечными точками) режиме. Туннельный режим IPsec основан на добавлении нового «внешнего» заголовка IP, который инкапсулирует исходный («внутренний») заголовок IP и связанный с ним пакет. Заголовки защиты в туннельном режиме вставляются между «внешним» и «внутренним» заголовками IP. В отличие от транспортного режима «внешний» заголовок IP и заголовки защиты туннельного режима могут удаляться и добавляться на промежуточных узлах вдоль пути соединения, позволяя шлюзам безопасности защищать уязвимые части соединения без необходимости включения конечных точек в обеспечение защиты. Важным свойством туннельного режима в соответствии с исходной спецификацией является отбрасывание внешнего заголовка на выходе туннеля в результате чего угрозы, связанные с изменением заголовков IP не распространяются дальше конечной точки туннеля. Дополнительную информацию о IPsec можно найти в [RFC4301].

Протокол IPsec, изначально определенный в [ESP, AH], требует, чтобы поле ECN внутреннего заголовка не менялось при декапсуляции IPsec в выходном узле туннеля — это требование противоречит возможностям полнофункциональной поддержки ECN. В то же время это обеспечивает защиту от враждебного изменения поля ECN с целью организации атак через конечные точки туннелей IPsec, поскольку в конечной точке все изменения теряются.

В принципе, при разрешении использовать функциональность ECN во внешнем заголовке туннеля IPsec возникают проблемы безопасности, связанные с тем, что враждебные стороны могут искажать информацию, распространяющуюся за пределы конечной точки туннеля. На основе анализа (включен в разделы 18 и 19) этих опасностей мы рекомендуем обеспечивать конфигурационную поддержку для изменений IPsec, позволяющих разрешить конфликт с ECN.

В частности, в туннельном режиме туннель IPsec должен поддерживать опцию ограниченной функциональности, кратко рассмотренную в параграфе 9.1.1, и следует также поддерживать полнофункциональную опцию, описанную в параграфе 9.1.1.

Это делает разрешение на использование функциональности ECN во внешнем заголовке туннеля IPsec настраиваемой частью соответствующей IPsec Security Association, которая может быть отключена в тех случаях, когда риск превышает достигаемые преимущества. В результате администратору безопасности IPsec предоставляется два варианта выбора поведения поддерживающих ECN соединений в туннелях IPsec — с полной и ограниченной функциональностью, как описано выше.

В дополнение к сказанному в этом документе также дается спецификация согласования используемой функциональности ECN между конечными точками туннеля IPsec с учетом политики безопасности. Возможность согласования использования ECN между конечными точками туннеля будет позволять администратору безопасности отключать поддержку ECN в ситуациях, когда возможный риск превышает преимущества от использования ECNECNECN (например, при потере уведомлений о перегрузках).

Протокол IPsec, определенный в [ESP, AH], не включает поля ECN заголовка IP в какие-либо криптографические преобразования (в туннельном режиме внешний заголовок IP не включает поля ECN). Следовательно, изменение поля ECN любым узлом в сети не оказывает влияния на сквозную защиту IPsec, поскольку не позволяет нарушить проверку целостности IPsec. В результате этого IPsec не обеспечивает никакой защиты от враждебного изменения поля ECN (например, от атак MITM), поскольку такие изменения не оказывают влияния на сквозную защиту IPsec. В некоторых средах возможность изменения поля ECN без воздействия на проверку целостности IPsec позволяет создавать скрытые каналы; для предотвращения такой возможности или снижения полосы скрытого канала для туннеля IPsec следует выбирать режим ограниченной функциональности.

9.2.1. Согласование между конечными точками туннеля

В этом параграфе детально описаны изменения, которые требуется внести для использования ECN с туннелями IPsec, включая согласование поддержки ECN между конечными точками туннеля. Для такой поддержки в IPsec нужно внести три изменения:

  • Необязательное поле SAD (Security Association Database — база данных ассоциаций защиты), показывающее способность процессов инкапсуляции и декапсуляции туннеля разрешать и запрещать использование ECN во внешнем заголовке IP.

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

  • Изменения процессов инкапсуляции и декапсуляции, позволяющие разрешать и запрещать использование ECN во внешнем заголовке IP на основе значения поля SAD. Когда использование ECN во внешнем заголовке IP разрешено, в этом заголовке устанавливается код ECT для поддерживающих ECN соединений и уведомления о перегрузках (указываются кодом CE) из таких соединений передаются во внутренний заголовок на выходе туннеля.

Если реализовано согласование опций использования ECN, следует также реализовать поле SAD. С другой стороны, согласование использования ECN в любом случае является опциональным, даже если реализация поддерживает поле SAD. Изменение обработки при инкапсуляции и декапсуляции требуется, но может быть реализовано без реализации двух других изменений в предположении, что использование ECN всегда запрещено. Полнофункциональный вариант использования ECN с туннелями IPsec включает поле SAD и полный вариант изменения процессов инкапсуляции и декапсуляции с опциональной поддержкой согласования или без нее. Вариант с ограниченной функциональностью включает часть изменений процессов инкапсуляции и декапсуляции, которая всегда запрещает использование ECN.

Эти изменения рассмотрены более подробно в трех следующих параграфах.

9.2.1.1. Поле ECN Tunnel в SAD

Полнофункциональная поддержка ECN добавляет новое поле в SAD (см. [RFC4301]):

  • ECN Tunnel: разрешен (allowed) или запрещен (forbidden).

  • Показывает, разрешено ли совместимому с ECN соединению, использующему данную SA в туннельном режиме, получать индикацию ECN для перегрузок, возникающих в туннеле. Значение allowed разрешает уведомления ECN. Значение forbidden запрещает такие уведомления, вынуждая использовать для индикации перегрузки отбрасывание пакетов.

  • [Опционально. Для реализаций, не поддерживающих этот атрибут в данном поле следует устанавливать значение forbidden.]

Если этот атрибут реализован, спецификация SA в базе данных SPD (Security Policy Database — база данных политики) должна поддерживать соответствующий атрибут и этот атрибут SPD должен быть включен в административный интерфейс SPD (в настоящее время описан в параграфе 4.4.1 [RFC4301]).

9.2.1.2. Атрибут ECN Tunnel в SA

Определен новый атрибут IPsec SA, позволяющий поддерживать согласование использования индикации насыщения ECN во внешнем заголовке IP для туннелей IPsec (см. [RFC4306]). Этот атрибут является опциональным, поддеживающим его реализациям следует поддерживать также поле SAD, определенное в параграфе 9.2.1.1.

  • Тип атрибута
  • Класс Значение Тип
    ECN Tunnel 10 Basic

    Значение атрибута IPsec SA, равное 10, выделено IANA для индикации согласования атрибута ECN Tunnel SA; тип этого атрибута — Basic (см. параграф [RFC4306]). Кзачения класса атрибутов используются при согласовании. Дополнительная информация, включая форматы кодирования и требования по согласованию этого атрибута SA,SA,SA, приведены в [RFC4306].

  • Значения класса

  • ECN Tunnel

    Определяет возможность использования функциональности ECN с туннельной инкапсуляцией. Значение определяет процессы инкапсуляции и декапсуляции (см. параграф 9.2.1.3).

    Резерв 0
    Разрешено 1
    Запрещено 2

    Значения 3 — 61439 зарезервированы IANA, значения 61440 — 65535 выделены для приватного использования.

    По умолчанию следует предполагать запрет (2).

    ECN Tunnel является новым атрибутом SA и, следовательно, при его использовании могут возникать проблемы непонимания этого атрибута и отказа от предложения его использовать. Для совместимости со старыми версиями новым реализациям следует во всех случаях также предлагать работу без атрибута ECN. RFC 2407 в настоящее время требует от отвечающей стороны отвергать все предложения с неизвестными атрибутами; предполагается, что это требование будет изменено на требование для отвечающего не выбирать предложения или преобразования с неизвестными атрибутами.

9.2.1.3. Изменения в обработке заголовков туннелей IPsec

Для полной поддержки ECN процессы инкапсуляции и декапсуляции для полей IPv4 TOS и IPv6 Traffic Class меняются по сравнению с указанными в [RFC4301] следующим образом:

Связь внешнего заголовка с внутренним
Поле Внешний заголовок на инкапсуляторе Внутренний заголовок на декапсуляторе
IPv4
DS Копируется из внутреннего заголовка (5) Не меняется
ECN Создается (7) Создается (8)
IPv6
DS Копируется из внутреннего заголовка (6) Не меняется
ECN Создается (7) Создается (8)

  • (5)(6) Если пакет незамедлительно будет вводиться в домен, для которого значение DSCP во внешнем заголовке неприемлемо, это значение должно быть отображено на приемлемое для домена значение [RFC 2474]. Дополнительная информация по этому вопросу содержится в [RFC 2475].

  • (7) Если поле ECN Tunnel в записи SAD для данной SA имеет значение «allowed» (разрешено) и поле ECN во внутреннем заголовке имеет значение, отличное от CE, поле ECN копируется во внешний заголовок. Если поле ECN во внутреннем заголовке имеет значение CE, в поле ECN внешнего заголовка устанавливается значение ECT(0).

  • (8) Если поле ECN Tunnel в записи SAD для данной SA имеет значение «allowed» (разрешено) и поле ECN во внутреннем заголовке имеет значение ECT(0) или ECT(1), а поле ECN во внешнем заголовке имеет значение CE, поле ECN из внешнего заголовка копируется во внутренний. В остальных случаях значение поля ECN во внутреннем заголовке не меняется.

  • (5) и (6) идентичны в соответствии с использованием [RFC4301], хотя они различаются [RFC4301].

Приведенное выше описание применимо к реализациям, поддерживающим поле ECN Tunnel в SAD; такие реализации должны обеспечивать такую обработку вместо использования обработки октетов IPv4 TOS и IPv6 Traffic Class, описанной в [RFC4301]. Это обеспечивает полнофункциональную поддержку использования ECN с туннелями IPsec.

Реализации, не поддерживающие поле ECN Tunnel в SAD, должны обеспечивать обработку в предположении, что поле ECN Tunnel в SAD имеет значение «forbidden» для каждой SA. В этом случае обработка поля ECN сводится к двум операциям:

  • (7) установить для поля ECN во внешнем заголовке значение not-ECT;

  • (8) не менять поле ECN во внутреннем заголовке.

Такое поведение обеспечивает ограниченную поддержку использования ECN с туннелями IPsec.

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

9.2.2. Изменения поля ECN в туннелях IPsec

Если поле ECN неподобающим образом меняется в туннеле IPsec и эти изменения детектируются на выходе туннеля, получение пакета, не удовлетворяющего условиям для данной SA протоколируется системой аудита. Реализация может создавать записи аудита с учетом некорректных пакетов для каждой SA в течение определенного периода вместо создания отдельной записи для каждого некорректного пакета. Во все записи аудита следует включать заголовки по крайней мере из одного некорректного пакета, но не требуется включать заголовки всех пакетов, представленных в записи.

9.2.3. Комментарии к поддержке IPsec

Приведенные здесь комментарии к двум частям этого документа были получены при просмотре документа членами рабочей группы IPsec. В этом параграффе рассматриваются полученные комментарии и даются объяснения причин того, что предложенные изменения не были включены в документ.

В первом комментарии отмечалось, что настройка конфигурации на уровне узла проще в реализации, нежели настройка на уровне SA. После серьезного обдумывания и дискуссий исходное предложение о настройке конфигурации на уровне узла перестало казаться хорошей идеей. Причина заключается в том, что осведомленность о ECN становится все шире в IPsec — многие знающие о ECN реализации IPsec осознают, что они взаимодействуют как с поддерживающими ECN конечными точками туннелей IPsec, так и с точками, не понимающими ESNESNESN. В такой среде при настройке конфигурации на уровне узла остается лишь запретить использование ECN для всех туннелей IPsec, которые не являются нужным выходом.

Во втором комментарии ряд обозревателей отметил, что согласование SA является достаточно сложным и его добавление — нетривиальная задача. Другие предлагали в качестве альтернативы использование ICMP после огранизации туннеля. Поддержка согласования SA в этом документе указана, как опциональная и останется таковой — разработчики сами принимают решение о реализации этой опции. Авторы надеются, что приведенные здесь аргументы будут полезны в разных ситуациях. Если эти рекомендации не будут использованы на практике, они могут быть удалены на последующих этапах процесса стандартизации. Использование ICMP для согласования ECN после организации туннеля более сложно, нежели расширения согласования атрибутов SA. Некоторые туннели не принимают трафик, адресованный узлу выходной точки туннеля, следовательно, пакеты ICMP нужно будет направлять в какой-то иной адрес — они будут «сканироваться» на выходе туннеля и отбрасываться здесь или у конечного их получателя. Кроме того, ICMP не обеспечивает гарантированной доставки и, следовательно, существует возможность отбрасывания пакетов ICMP, для учета которой потребуется создать дополнительных механизм подтверждений и повторов передачи. Опциональное расширение существующего механизма согласования SA представляется более эффективным решением.

9.3. Пакеты IP, инкапсулированные в пакеты других протоколов

При инкапсуляции пакетов IP в пакеты других протоколов возникают другие вопросы, связанные с ECN. Такие ситуации возникают для MPLS [MPLS], GRE [GRE], L2TP [L2TP] и PPTP [PPTP]. Для этих протоколов не возникает конфликта с ECN — дело в том, что ECN просто не может использоваться внутри туннеля, пока код ECN не может быть включен в заголовок инкапсулирующего протокола. Выполнены начальные разработки по встраиванию ECN в MPLS, а предложения по встраиванию ECN в GRE, L2TP или PPTP будут рассматриваться по мере их появления.

10. Проблемы, создаваемые «карательными» устройствами

Возможно, что в сети будут устанавливаться устройства мониторинга и реализации политики (точнее было ты назвать их «карательными» устройствами), которые будут просматривать потоки на предмет адекватной реакции на перегрузки и отбрасывать в первую очередь пакеты из тех потоков, которые не используют адекватных процедур сквозного контроля насыщения.

Для «карательных» устройств, которые обнаруживают, что отдельный поток или группа потоков не обеспечивает сквозного контроля насыщения, сначала менять для таких потоков маркировку пакетов на отбрасывание и только после этого принимать дополнительные меры по ограничению полосы, доступной для потока. Таким образом, сначала маршрутизатор будет отбрасывать пакеты, которые при иных условиях он бы пометил кодом CE. Сюда включается отбрасывание пакетов, поступающих из совместимых с ECN потоков и уже имеющих код CE. В этом случае любое насыщение, которое маршрутизатор видит для потока, будет видимым и для конечных узлов даже при наличии враждебных или некорректно работающих маршрутизаторов на пути передачи. Если предположить, что первым действием для любого «карательного» устройства по отношению к поддерживающему ECN потоку будет отбрасывание пакетов вместо их маркировки, тогда у злоумышленника уже не останатся возможности нарушить сквозной контроль насыщения на базе ECN путем ложного представления этого потока, как несовместимого с контролем насыщения, для принятия к нему более жестких мер в «карательном» устройстве.

Устройства мониторинга и реализации политики, разворачиваемые на практике, могут отличаться от описанного выше «идеального» устройства мониторинга в том, что мониторинг осуществляется применительно не к отдельному потоку, а к аграгату потоков (например, к потокам одного туннеля IPsec). В этом случае переход от маркировки к отбрасыванию будет осуществляться для всех потоков агрегата, сводя на нет преимущества использования ECN для этих потоков. При высоком уровне агрегирования наблюдается другой вариант запрета ECN даже при отсутствии устройств мониторинга и реализации политики, когда поддерживающие ECN очереди RED переключаются с маркировки пакетов на их отбрасывание в качестве индикации насыщения в тех случаях, когда средний размер очереди превышает заданный порог.

11. Оценка ECN

11.1. Работы по оценке использования ECN

В этом разделе рассмотрены некоторые работы в которых проводится оценка использования ECN. На Web-странице ECN [ECN] приведены ссылки на работы по ECN и реализации ECN.

В работе [Floyd94] рассмотрены преимущества и недостатки, связанные с добавлением ECN в архитектуру TCP/IP. Как показано в основанном на имитации сравнении, одним из преимуществ ECN является избавление от ненужного отбрасывания пакетов для короткий и чувствительных к задержкам соединений TCP. Вторым преимуществом ECN является предотвращение некоторых ненужных повторов передачи по тайм-аутам в TCP. В этой статье детально обсуждается интеграция ECN в механизмы контроля насыщения TCP. К отмеченным в статье возможным недостаткам ECN относится то, что неподатливые соединения TCP могут ложно анонсировать себя, как поддерживающие ECN соединения, а также возможность отбрасывания в сети пакетов TCP ACK, содержащих сообщения ECN-Echo. Первый из этих недостатков обсуждается в приложении к данному документу, а второй снимается путем добавления флага CWR в заголовок TCP.

Экспериментальные оценки ECN проведены в [RFC2884,K98] и сделано заключение о том, что ECN TCP обеспечивает умеренное повышение производительности по сравнению с TCP без использования ECN, потоки ECN TCP не нарушают работу потоков без поддержки ECN и ECN TCP обеспечивает отказоустойчивость для случаев насыщения в обоих направлениях и наличия на пути множества перегруженных маршрутизаторов. Эксперименты со множеством коротких соединений для передачи web-трафика показали, что для большинства коротких соединений в результате использования ECN время передачи значительно сокращалось.

11.2. Обсуждение ECN nonce

Использование двух кодов ECT — ECT(0) и ECT(1) — может обеспечивать однобитовый маркер ECN nonce в заголовках пакетов [SCWA99]. Основной целью введения такой маркировки является обеспечение отправителю возможности обнаружения фактов удаления кода CE сетевыми элементами на пути и проверки корректности информирования со стороны получателя о приеме пакетов с кодом CE, требуемого транспортным протоколом. В этом параграфе обсуждаются вопросы обратной совместимости с реализациями IP ECN в маршрутизаторах, соответствующих RFC 2481, которые поддерживают только один код ECT. Мы полагаем, что расширяющееся развертывание реализаций ECN, понимающих код ECT(1), не будет вызывать каких-либо проблем. Отсутствие таких проблем очевидно для случаев, когда поддержка ECT(1) в маршрутизаторах реализуется до того, как этот код начинают использовать конечные узлы.

11.2.1. Поэтапное развертывание ECT(1) в маршрутизаторах

ECN имеет статус экспериментального стандарта с января 1999 и уже имеются реализации ECN в маршрутизаторах, которые не понимают кода ECT(1). При стандартиации использования ECT(1) для TCP или других транспортных протоколов это может привести к тому, что отправители данных будут использовать код ECT(1), а некоторые перегруженные маршрутизаторы на пути доставки пакетов не будут понимать этот код.

Если транспортный протокол позволяет, отправитель данных может совсем не использовать код ECT(1) и передавать все поддерживающие ECN пакеты с кодом ECT(0). Однако, если поддерживающий ECN отправитель использует ECT(1), а перегруженный маршрутизатор на пути передачи не понимает код ECT(1), тогда этот маршрутизатор будет маркировать некоторые пакеты с кодом ECT(0) и отбрасывать некоторые пакеты с кодом ECT(1) для индикации насыщения. Поскольку протокол TCP должен реагировать как на маркировку, так и на отбрасывание пакетов, при отбрасывании пакетов, которые могли бы быть промаркированы, не возникает каких-либо существенных проблем в сети и такое отбрасывание совместимо в общей моделью работы ECN, позволяющей маршрутизаторам самостоятельно принимать решение об отбрасывании или маркировке пакетов (см. раздел 5).

12. Список требуемых изменений для IP и TCP

В этом документе определено использование для ECN двух битов заголовка IP. Код not-ECT показывает, что транспортный протокол будет игнорировать код CE. Этот код является принятым по умолчанию значением кода ECN. Коды ECT показывают, что транспортный протокол хочет и может участвовать в работе ECN.

Маршрутизатор устанавливает код CE для индикации перегрузки конечным узлам. Маршрутизаторам недопустимо сбрасывать код CE в заголовках пакетов.

Для поддержки ECN в протокол TCP требуется внести три изменения — это фаза организации соединения и два новых флага в заголовке TCP. Флаг ECN-Echo используется получателем данных для информирования отправителя о получении пакета CE. Флаг снижения размера окна насыщения (CWR) используется отправителем данных для информирования получателя о снижении размера окна насыщения.

При использовании ECN (явное уведомление о перегрузке) требуется, чтобы индикаторы насыщения, генерируемые в туннеле IP, не терялись на выходе из туннеля. Мы вносим незначительные изменения в протокол IP для обработки поля ECN при инкапсуляции и декапсуляции, позволяющие потокам, проходящим через туннели IP, использовать ECN.

В туннелях для ECN определяются две опции:

  1. Опция ограниченной функциональности, при использование ECN внутри туннеля IP отключается путем установки в поле ECN значения not-ECT и сохранения внутреннего заголовка при декапсуляции.

  2. Пофункциональная опция, когда в поле ECN внешнего заголовка может использоваться код not-ECT или один из кодов ECT в зависимости от значения поля ECN во внутреннем заголовке. При декапсуляции код CE копируется во внутренний заголовок, если этот код присутствует во внешнем аголовке, а во внутреннем установлен один из кодов ECT.

Для туннелей IPsec в этом документе также определен необязательный атрибут защитной ассоциации (SA), управляющий согласованием использования ECN в туннеле IPsec и необязательное поле SAD для индикации возможности использования ECN в туннельном режиме для SA. Требуемые для использования ECN изменения туннелей IPsec вносят изменения в документ RFC 4301 [RFC4301], определяющий архитектуру IPsec и задающий некоторые аспекты реализации. Новый атрибут IPsec SA дополняет атрибуты, определенные в параграфе 4.5 [RFC4306].

Этот документ отменяет действие RFC 2481 «A Proposal to add Explicit Congestion Notification (ECN) to IP» (Предложение по добавлению явных уведомлений оперегрузке (ECN) в протокол IP), который определял ECN в качестве экспериментального протокола для сообщества Internet. В оставшейся части этого параграфа описаны связи настоящего документа с его предшественником.

RFC 2481 включает краткое обсуждение использования ECN с инкапсулированными пакетами, в котором отмечено, что спецификация IPsec на тот момент (январь 1999) говорит о невозможности безопасного использования ECN через туннели IPsec. В RFC 2481 также описаны изменения, которые нужно было сделать в спецификации туннелей IPsec для обеспечения совместимости с ECN.

В этом документе учтены работы, выполненные с момента публикации RFC 2481. Во-первых, детально описаны изменения для туннелей IPsec и подробно рассмотрено влияние ECN на безопасность (разделы 18 и 19). Во-вторых, рассмотрение туннелей IPsec расширено для всех туннелей IP. Поскольку старые туннели IP не совместимы с потоками, использующими ECN, развертывание ECN в сети Internet оказываало сильное давление на процессы обновления старых реализаций туннелей до совместимых с ECN версий на основе использования опции полной или ограниченной функциональности.

В этом документе не рассматриваются вопросы использования ECN в туннелях других протоколов (не IP) типа MPLS, GRE, L2TP или PPTP. В настоящее время предварительные документы по включению поддержки ECN в MPLS находятся в стадии разработки.

В-третьих, после публикации RFC2481 были описаны процедуры ECN для повторно передаваемых пакетов данных, когда код ECT при повторной передаче устанавливать не следует. Мотивом отказа от использования кодов при повторе передачи послужило желание предотвратить возможные атаки на службы (DoS) для существующих соединений TCP. Некоторые ранние реализации TCP с поддержкой ECN могут не соответствовать (новым) требованиям по отказу от установки кода ECT в повторно передаваемых пакетах; мы полагаем, что на практике это не вызовет существенных проблем.

Этот документ также несколько расширяет спецификацию использования пакетов SYN для согласования ECN. Некоторые ранние реализации TCP с поддержкой ECN могут не соответствовать заданным здесь требованиям, но мы полагаем, что это не вызовет проблем в организации и производительности соединений TCP в которых участвуют реализации с различными возможностями.

Этот документ также включает спецификацию кода ECT(1), который может использоваться протоколом TCP, как часть реализации ECN nonce.

13. Заключение

На основе опыта развертывания AQM мы полагаем, что настало время развертывания механизмов предотвращения перегрузок, не зависящих от отбрасывания пакетов. По мере развертывания приложений и транспортного сервиса, чувствительных к задержкам и потере данных (например, трафик в реальном масштабе времени, короткие web-транзакции), использование потери пакетов в качестве механизма индикации насыщения становится недостаточно эффективным (по крайней мере, неоптимальным).

Мы оценили последствия изменения поля ECN в сети, проанализировав все возможные варианты враждебного изменения поля ECN. Во многих случаях изменение поля ECN не представляет большей опасности, чем отбрасывание пакета. Однако мы отмечаем, что некоторые изменения могут приводить к более серъезным последствиям с нарушением сквозного контроля насыщения. Но даже в таких случаях потенциальные нарушения ограничены и подобны угрозам, создаваемым врпемя от времени возникающим отказам при взаимодействии систем для организации сквозного контроля насыщения.

14. Благодарности

В подготовку этого документа внесло свой вклад много людей, включая тех, кто не участвовал в создании документа непосредственно. Мы хотим явно поблагодарить Kenjiro Cho за предложения по механизмам TCP для согласования поддержки ECN, Kevin Fall за предложения по флагу CWR, Steve Blake за материалы по пересчету контрольной суммы заголовков IPv4, Jamal Hadi-Salim за обсуждение проблем ECN, а также Steve Bellovin, Jim Bound, Brian Carpenter, Paul Ferguson, Stephen Kent, Greg Minshall и Vern Paxson за обсуждение вопросов безопасности. Мы также благодарим участников исследовательской группы Internet End-to-End за обсуждение многих вопросов.

Обмен информацией по электронной почте со многими людьми, включая Dax Kelson, Alexey Kuznetsov, Jamal Hadi-Salim и Venkat Venkatsubra, помог в решении вопросов, связанных с несовместимым оборудованием в сети Internet, которое не реагирует на пакеты TCP SYN с установленными флагами ECE и CWR. Мы благодарим Mark Handley, Jitentra Padhye и других за обсуждение вопросов инициализации TCP.

Обсуждение вопросов взаимодействия ECN и туннелей IP прочно было связано и дискуссиями и документами рабочей группы Differentiated Services. Мы благодарим Tabassum Bint Haque из Dhaka, Bangladesh за отклики по туннелям IP. Мы также благодарим Derrell Piper и Kero Tivinen за предложенные изменения RFC 2407, позволившие повысить уровень применимости согласования атрибута SA при использовании ECN с туннелями.

Мы благодарим David Wetherall, David Ely и Neil Spring за их предложения по ECN. Благодарим также Stefan Savage за обсуждение этой тематики. Мы признательны Bob Briscoe и Jon Crowcroft за поднятый вопрос о фрагментации IP, дополнительную семантику четвертого кода ECN и обсуждение других тем. Мы благодарим Richard Wendland за отклики по нескольким затронутым в документе вопросам.

Мы также благодарим IESG и, в частности, директоров направления Transport за их отклики и усилия по стандартизации ECN.

15. Литература

[AH] S. Kent, «Идентификационный заголовок IP», RFC 4302, Декабрь 2005
[ESP] S. Kent, «Инкапсуляция защищенных данных IP (ESP)», RFC 4303, Декабрь 2005
[ECN] «The ECN Web Page»
[FIXES] ECN-under-Linux Unofficial Vendor Support Page
[FJ93] Floyd, S., and Jacobson, V., «Random Early Detection gateways for Congestion Avoidance», IEEE/ACM Transactions on Networking, V.1 N.4, Август 1993, p. 397-413.
[Floyd94] Floyd, S., «TCP and Explicit Congestion Notification», ACM Computer Communication Review, V. 24 N. 5, October 1994, p. 10-23.
[Floyd98] Floyd, S., «The ECN Validation Test in the NS Simulator», test tcl/test/test-all-ecn
[FF99] Floyd, S., and Fall, K., «Promoting the Use of End-to-End Congestion Control in the Internet», IEEE/ACM Transactions on Networking, Август 1999.
[FRED] Lin, D., and Morris, R., «Dynamics of Random Early Detection», SIGCOMM '97, Сентябрь 1997.
[GRE] Hanks, S., Li, T., Farinacci, D. и P. Traina, «Generic Routing Encapsulation (GRE)», RFC 1701, October 1994.
[Jacobson88] V. Jacobson, «Congestion Avoidance and Control», Proc. ACM SIGCOMM '88, pp. 314-329.
[Jacobson90] V. Jacobson, «Modified TCP Congestion Avoidance Algorithm», Message to end2end-interest mailing list, Апрель 1990
[K98] Krishnan, H., «Analyzing Explicit Congestion Notification (ECN) benefits for TCP», Master's thesis, UCLA, 1998.
[L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. и B. Palter, «Layer Two Tunneling Protocol (L2TP) », RFC 2661, Август 1999.
[MJV96] S. McCanne, V. Jacobson, and M. Vetterli, «Receiver-driven Layered Multicast», SIGCOMM '96, Август 1996, pp. 117-130.
[MPLS] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. и J. McManus, Requirements for Traffic Engineering Over MPLS, RFC 2702, Сентябрь 1999.
[PPTP] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. и G. Zorn, «Point-to-Point Tunneling Protocol (PPTP)», RFC 2637, Июль 1999.
[RFC791] Postel, J., «Протокол IP (Internet Protocol)», STD 5, RFC 791, Сентябрь 1981
[RFC793] Postel, J., «Протокол управления передачей (TCP)», STD 7, RFC 793, Сентябрь 1981
[RFC1141] Mallory, T. и A. Kullberg, «Incremental Updating of the Internet Checksum», RFC 1141, Январь 1990.
[RFC1349] Almquist, P., «Type of Service in the Internet Protocol Suite», RFC 1349, Июль 1992.
[RFC1455] Eastlake, D., «Physical Link Security Type of Service», RFC 1455, Май 1993.
[RFC1701] Hanks, S., Li, T., Farinacci, D. и P. Traina, «Generic Routing Encapsulation (GRE)», RFC 1701, October 1994.
[RFC1702] Hanks, S., Li, T., Farinacci, D. и P. Traina, «Generic Routing Encapsulation over IPv4 networks», RFC 1702, October 1994.
[RFC2003] Perkins, C., «IP Encapsulation within IP», RFC 2003, October 1996.
[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, Март 1997.
[RFC2309] Braden, B., et al., «Recommendations on Queue Management and Congestion Avoidance in the Internet», RFC 2309, Апрель 1998.
[RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, Декабрь 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. и W. Weiss, «Архитектура дифференцированного обслуживания (Diffserv)», RFC 2475, Декабрь 1998
[RFC2481] Ramakrishnan K. и S. Floyd, «A Proposal to add Explicit Congestion Notification (ECN) to IP», RFC 2481, Январь 1999.
[RFC2581] Alman, M., Paxson, V. и W. Stevens, «Контроль насыщения в TCP», RFC 2581, Апрель 1999
[RFC2884] Hadi Salim, J. и U. Ahmed, «Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks», RFC 2884, Июль 2000.
[RFC2983] Black, D., «Differentiated Services and Tunnels», RFC 2983, Октябрь 2000.
[RFC2780] Bradner S. и V. Paxson, «IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers», BCP 37, RFC 2780, Март 2000.
[RFC4301] S. Kent, K. Seo, Security Architecture for the Internet Protocol, RFC 4301, Ноябрь 2005.
[RFC4306] C. Kaufman, «Протокол обмена ключами в Internet (IKEv2)», RFC 4306, Ноябрь 2005
[RJ90] K. K. Ramakrishnan and Raj Jain, «A Binary Feedback Scheme for Congestion Avoidance in Computer Networks», ACM Transactions on Computer Systems, Vol.8, No.2, pp. 158-181, Май 1990.
[SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, and Tom Anderson, TCP Congestion Control with a Misbehaving Receiver, ACM Computer Communications Review, October 1999.
[TBIT] Jitendra Padhye and Sally Floyd, «Identifying the TCP Behavior of Web Servers», ICSI TR-01-002, Февраль 2001

16. Вопросы безопасности

Вопросы безопасности рассматриваются в разделах 7, 8, 18 и 19.

17. Пересчет контрольной суммы в заголовке IPv4

При пересчете контрольной суммы заголовка IPv4 возникает проблема с некоторыми маршрутизаторами, использующими буферизацию на выходе, поскольку большинство (если не все) операций с заголовком выполняются на входе, а решение для ECN нужно принимать локально по состоянию выходного буфера. Этой проблемы не возникает для IPv6, поскольку этот протокол не использует контрольных сумм для заголовков. Октет IPv4 TOS является последним байтом 16-битового полуслова.

В RFC 1141 [RFC1141] обсуждается нарастающее обновление контрольной суммы IPv4 после уменьшения значения поля TTL. Нарастающее обновление контрольной суммы IPv4 после установки кода CE описано ниже. Обозначим HC исходную контрольную сумму заголовка для пакета ECT(0), а HC' будет новой контрольной суммой после установки бита CE (т. е., поле ECN изменит значение с 10 на 11). Тогда контрольная сумма заголовка вычисляется путем вычитания дополнения до 1:

HC' = { HC - 1     HC > 1
      { 0x0000     HC = 1

Для расчета контрольной суммы на машинах с дополнением до двух HC' после установки флага CE будет:

HC' = { HC - 1     HC > 0
      { 0xFFFE     HC = 0

Похожее нарастающее изменение контрольной суммы IPv4 может выполняться при изменении поля ECN с ECT(1) на CE (с 01 на 11).

18. Возможные изменения поля ECN в сети

В этом разделе подробно рассматривается вопрос возможного изменения в сети поля ECN и связанные с этим последствия — ложные уведомления оперегрузках, запрет поддержки ECN для отдельных пакетов, удаление индикации ECN о перегрузке или ложная индикация поддержки ECN.

18.1. Возможные изменения заголовка IP

18.1.1. Удаление индикатора насыщения

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

Замена кода CE на ECT(0) или ECT(1) эффективно удаляет индикацию насыщения. Однако при использовании двух кодов ECT маршрутизатор, удаляющий код CE не знает, какой код ECT был в пакете изначально — ECT(0) или ECT(1). Таким образом, транспортный протокол может реализовать механизмы детектирования фактов удаления кода CE.

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

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

В противоположность этому систематическое отбрасывание бита CE маршрутизатором нисходящего потока будет приводить к созданию очереди на маршрутизаторе восходящего потока с возможностью потери пакетов в результате переполнения буфера. При этом может теряться беспристрастность, поскольку другие потоки через перегруженный маршрутизатор могут реагировать на установленный бит CE, тогда как поток с удаленным битом CE будет по-прежнему отнимать ресуосы буфера. Подавление этого негативного эффекта подробно рассматривается в разделе 19.

Последним из трех возможных изменений является замена кода CE кодом not-ECT, которая одновременно удаляет индикацию перегрузки и запрещает использование ECN.

«Удаление» индикации насыщения дает эффект только в том случае, когда пакет впоследствии не будет промаркирован заново или отброшен машрутизатором нисходящего потока. Если код CE заменяется кодом ECT, пакет сохраняет совместимость с ECN и может быть снова промаркирован или отброшен маршрутизатором нисходящего потока для индикации перегрузки. Если код CE меняется на not-ECT, пакет утрачивает совместимость с ECN и, следовательно, может быть отброшен, но не может быть промаркирован для индикации насыщения.

18.1.2. Ложная информация о насыщении

Это изменение заключается в установке кода CE при уже установленном коде ECT и вне зависимости отналичия реальной перегрузки. Данное изменение не влияет на трактовку пакета по пути его передачи. В частности, маршрутизаторы не проверяют наличие кода CE при решении вопроса — маркировать или отбрасывать пакет.

Однако это изменение может приводить к необоснованному включению механизма сквозного контроля насыщения и снижению скорости доставки пакетов. Само по себе это не создает дополнительных (для приложений или сети) по сравнению с отбрасыванием пакетов маршрутизатором.

18.1.3. Запрет поддержки ECN

Это изменение заключается в отключении кода ECT для пакета. Если такой пакет в дальнейшем столкнется с насыщением (например, при попадании в RED-очередь с умеренным размером буфера), он будет отброшен вместо маркировки. Само по себе это не создает больших проблем (для приложений), чем обычное отбрасывание пакета маршрутизатором. Сдерживающим фактором в данном случае является отсутствие маршрутизатора восходящего потока, ожидающего реакции на установку бита CE.

18.1.4. Ложная индикация поддержки ECN

Это изменение состоит в некорректной индикации для пакета поддержки ECN. На практике пакет может быть передан как поддерживающим, так и не поддерживающим ECN транспортом.

Если пакет впоследствии столкнется с умеренным насыщением на поддерживающем ECN маршрутизаторе, этот маршрутизатор может установить код CE вместо отбрасывания пакета. Если транспортный протокол реально не поддерживает ECN, транспорт не будет получать такую индикацию насыщения и не будет снижать в ответ скорость передачи. Возможные последствия ложной индикации поддержки ECN рассматриваются в разделе 19.

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

18.2. Информация, передаваемая в транспортном заголовке

Для протокола TCP поддерживающий ECN получатель может информировать партнера TCP о своей поддержке ECN на уровне протокола TCP, помещая эту информацию в заголовок TCP на этапе организации соединения. В этом документе не рассматриваются угрозы, связанные с возможностью изменения заголовка транспортного уровня в сети. Отметим, что при использовании IPsec заголовок транспортного уровня защищен как в туннельном, так и в транспортном режиме [ESP, AH].

Другой вопрос связан с пакетами TCP, содержащими обманный адрес IP и некорректную информацию ECN в заголовке транспортного уровня. Для полноты мы рассмотрели возможные варианты, которые узел, подставляющий обманный IP-адрес отправителя, может использовать два флага ECN в заголовке TCP для организации DoS- DoS-атаки. Для таких атак злоумышленнику нужны корректные порядковые номера TCP и атакующий, способный создавать корректные номера и использовать обманный IP-IP-IP-адрес отправителя, может повредить соединение TCP и без использования флагов ECN. Следовательно, ECN в данном случае не добавляет новых уязвимостей.

Пакет подтверждения с обманным IP-адресом отправителя, указывающим на получателя TCP, может иметь флаг ECE. Если этот пакет будет принят отправителем данных TCP, как корректный, это может привести к ненужному снижению вдвое размера окна насыщения на передающей стороне TCP. Однако для того, чтобы отправитель принял обманный пакет подтверждения, в этом пакете должен быть указан корректный 32-битовый порядковый номер, а также корректный номер подтверждения. Атакующий, который способен создавать обманные пакеты с корректными порядковыми номерами может просто передать обманный пакет RST или иной пакет, способный нарушить работу соединения TCP.

Пакеты с обманным IP-адресом отправителя, указывающим на передающую сторону TCP, могут иметь флаг CWR. Для такого пакета также требуется указать корректный порядковый номер. Кроме того, пакеты такого типа могут оказать лишь незначительное влияние на работу соединения. Обманный пакет данных с флагом CWR может привести к тому, что получатель TCP станет передавать меньше пакетов ECE, чем обычно, если он передавал такие пакеты в момент получения пакета с флагом CWR.

18.3. Расщепленные пути

В некоторых случаях враждебные или некорректно настроенные маршрутизаторы могут иметь доступ лишь к части пакетов потока. Возникает вопрос — может ли такой маршрутизатор, меняя значения поля ECN в доступном ему подмножестве пакетов потока, повреждать этот поток сильнее, чем при простом отбрасывании пакетов?

Разделим пакеты потока на две группы — A и B, предположив, что злоумышленнику доступны только пакеты группы A. Предположим, что враждебное воздействие выражается в нарушении сквозного контроля насыщения на пути, по которому проходят пакеты группы A, путем ложной индикации поддержки ECN для восходящего направления, на котором наблюдается перегрузка, или путем удаления индикации насыщения в нисходящем направлении. Предположим также, что имеется устройство мониторинга, которое видит пакеты обеих групп и будет «карать» пакеты обеих групп, если суммарный поток, доступный устройству, не реагирует должным образом на индикацию насыщения. Другим важным моментом (полагаем, что это достаточно очевидно) является то, что устройство мониторинга до использования «карательных» мер по отношению к потоку A&B будет сначала отбрасывать пакеты вместо установки в них кода CE, а также будет отбрасывать прибывающие пакеты, в которых уже установлен код CE. Если конечные узлы на практике используют сквозной контроль насыщения, они будут видеть все индикаторы перегрузки, которые видны устройству мониторинга, и будет должным образом реагировать на насыщение. Таким образом, устройство мониторинга успешно обеспечивает индикацию для потока на начальном этапе.

Атакующий, который имеет доступ только к пакетам A, нарушая работу системы контроля насыщения на основе ECN, способен свести на нет преимущества ECN для других пакетов суммарного потока A и B. Это печальный факт, но он не является достаточным основанием для отказа от ECN.

Вариант ложной индикации перегрузки возникает в том случае, когда на пути имеется два злоумышленника, из которых первый создает ложную индикацию, а второй «удаляет» ее (в отличии от случая отбрасывания пакетов индикация перегрузки в ECN может быть «реверсирована» на пути враждебным или некорректно настроенным маршрутизатором, однако использование ECN nonce может помочь в обнаружении такого поведения). Несмотря на то, что описанные выше искажения прозрачны для конечных узлов, между первым и вторым злоумышленником может оказаться устройство мониторинга, которое увидит ложную индикацию перегрузки. Как было отмечено выше, в этом случае до начала «карательных» действий по отношению к потоку, не реагирующему должным образом на перегрузку, маршрутизатор сначала перейдет на режим отбрасывания пакетов потока взамен их маркировки. Когда этот процесс включает отбрасывание прибывающих пакетов с кодом CE, конечные узлы получат индикацию насыщения на пути. Таким образом, не возникает дополнительных угноз в результате действия множества конфликтующих злоумышленников.

19. Влияние нарушения сквозного контроля насыщения

В этом разделе рассматриваются возможные последствия нарушения сквозного контроля насыщения путем ложной индикации поддержки ECN или путем удаления индикации насыщения в ECN (кода CE). Нарушение сквозного контроля насыщения любым из этих способов может оказывать влияние как на приложения, так и на сеть. Ниже эти варианты подробно рассматриваются по-отдельности.

Первый метод нарушения сквозного контроля насыщения заключается в ложной индикации поддержки ECN. Эффективно нарушить сквозной контроль насыщения при этом удается лишь в тех случаях, когда на пути пакета действительно наблюдается перегрузка, приводящая к установке кода CE. В этом случае транспортный протокол (который может не поддерживать ECN) не будет получать индикацию насыщения от перегруженных маршрутизаторов нисходящего направления.

Вторым методом нарушения сквозного контроля насыщения является «удаление» кода CE из пакетов. Эффективное нарушение контроля насыщения при этом получается лишь в тех случаях, когда в пакете уже был код CE установленные ранее перегруженным маршрутизатором. В этос случае транспортный протокол не получает индикации насыщения от перегруженных маршрутизаторов восходящего направления.

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

19.1. Влияние на сеть и конкурирующие пути

Код CE в поле ECN используется лишь маршрутизаторами для индикации перегрузки в период «умеренного» насыщения. Поддерживающим ECN маршрутизаторам в периоды существенных перегрузок следует отбрасывать пакет, а не маркировать их даже в тех случаях, когда в очередях маршрутизатора еще имеется место. Например, маршрутизаторам, использующим активное управление очередями на основе RED, следует отбрасывать пакет, а не маркировать их, если средний размер очередей превышает верхний порог для очередей RED.

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

В некоторых случаях рост насыщения будет приводить к существенному росту заполненности буферов на загруженных очередях, которого будет достаточно для перевода очередей из режима маркировки пакетов в режим их отбрасывания. Этот переход будет переходить в результате переполнения буферов или в соответствии с политикой активного управления очередями, описанного выше, когда пакеты начинают отбрасываться при достижении заданного порога RED. С этого момента все потоки, включая поток с нарушениями, будут видеть отбрасывание пакетов вместо их маркировки и все враждебные или некорректно настроенные маршрутизаторы больше не смогут удалять такую индикацию насыщения в сети. Если конечные узлы используют подходящую технологию сквозного контроля насыщения, в нарушенном потоке скорость передачи будет снижена в ответ на перегрузку. Когда уровень насыщения существенно снизится, перегруженная очередь может вернуться из режима отбрасывания пакетов в режим маркировки. В установившемся состоянии могут наблюдаться осцилляции очереди с переходом из одного режима в другой.

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

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

Вернемся к примеру, описанному в параграфе 18.1.1, где установленный в пакете код CE удалялся: {'11' -> '10' or '11'-> '01'}. Последствием этого для перегруженного маршрутизатора восходящего направления, который установил код CE, является то, что эта индикация не достигнет конечного узла данного потока. Отправитель (даже из число полностью кооперированных и не враждебных) в результате отсутствия индикации может продолжать увеличение скорости передачи (для TCP путем расширения окна насыщения). Поток может получить более высокую пропускную способность на перегруженном маршрутизаторе по сравнению с другими потоками, особенно при отсутствии на маршрутизаторе механизмов реализации политики или независимого распределения очередей по потокам. Рассмотрим поведение других потоков (особенно, кооперированных), которые не подверглись нарушению сквозного контроля насыщения. Ясно, что эти потоки снизят свою нагрузку на данный маршрутизатор (например, за счет снижения размера окна), отдавая преимущества нарушенному потоку. Таким образом утрачивается беспристрастность. Как обсуждалось выше, эта пристрастность может быть кратковременной (поскольку перегруженная очередь находится в режиме маркировки пакетов), осциллирующей (очередь переключается между режимами маркировки и отбрасывания) или более сдержанной, но постоянной (поскольку очередь никогда не переключается в режим отбрасывания пакетов).

Результат для нарушенного потока похож на случай преднамеренного отказа от сквозного контроля насыщения. Единственное различие заключается в том, что поток, преднамеренно отказавшийся от сквозного контроля насыщения, на конечных узлах, может избежать контроля насыщения даже при переходе насыщенной очереди в режим отбрасывания пакетов, отвергая снижение скорости передачи в ответ на отбрасывание пакетов в сети. Таким образом, проблема для сетей с нарушенным контролем насыщения на базе ECN менее значима, чем проблема, вызываемая преднамеренным отказом от контроля насыщения на конечных узлах. Важно также отметить, что контролировать поведение конечных узлов существенно сложнее, чем контролировать поведение инфраструктуры. Отмеченное выше не говорит о малозначимости проблем, вносимых в сеть нарушением системы контроля насыщения на базе ECN — просто приводится сравнение значимости этих проблем с другими нарушениями контроля насыщения на конечных узлах.

19.2. Влияние на нарушенный поток

Когда отправитель указывает поддержку ECN, предполагается, что маршрутизаторы в сети, способные участвовать в ECN, будут использовать код CE для индикации насыщения. Потенциальным преимуществом использования ECN является снижение число теряемых пакетов (в дополнение к снижению задержки в очередях за счет активного управления). Когда пакет проходит через туннель IPsec, проходящий через узлы, которые не пользуются доверием по тем или иным причинам, предполагается, что IPsec будет обеспечивать защиту, предотвращающую возникновение нежелательных последствий.

Во многих случаях нарушенный поток будет получать преимущества перед конкурирующими потоками данных в результате нарушения сквозного контроля насыщения в сети за счет увеличения доступной ему полосы. Если насыщенная очередь достигает погора отбрасывания пакетов, нарушение сквозного контроля насыщения может давать или не давать преимущества нарушенному потоку, в зависимости от относительных потребностей потока в части пропускной способности, потерь и зедержек.

Одной из форм нарушения сквозного контроля насыщения является ложная индикация поддержки ECN путем установки кода ECT. Установка ложного кода CE будет оказывать влияние на перегруженные маршрутизаторы нисходящего направления. Однако, как было указано в параграфе 9.1.2, если код ECT меняется в туннеле IP, это может быть обнаружено на выходе туннеля, поскольку внутренний заголовок не будет изменен.

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

Если код ECT удаляется внутри туннеля IP, это может быть обнаружено на выходе туннеля, поскольку внутренние заголовки не будут изменены. Если код CE устанавливается в восходящем направлении к туннелю IP, удаление кода CE в туннеле из внешнего заголовка не будет оказывать никакого влияния, поскольку установленный код CE сохранится во внутреннем заголовке. Однако, если код CE установлен внутри туннеля и удален в туннеле или в нисходящем направлении от туннеля, такое удаление может остаться незамеченным на выходе из туннеля.

При таком нарушении сквозного контроля насыщения транспортный протокол конечных узлов не реагирует на индикацию перегрузки. Вместе с утратой беспристрастности по отношению к незатронутым нарушением потокам, описанной в предыдущем параграфе, может продолжиться заполнение очереди перегруженного маршрутизатора, приводящее в результате к отбрасыванию пакетов на перегруженном маршрутзизаторе, которое будет означать безусловную индикацию перегрузки транспортному протоколу. В переходном периоде поток может столкнуться существенным ростом задержки в очереди по сравнению с другими (ненарушенными) потоками. Но транспортные протоколы не принимают допущений о согласованности управления очередями на пути доставки. Мы полагаем, что эти формы нарушения сквозного контроля насыщения не представляют большей опасности, чем простое отбрасывание пакетов потока.

19.3. Не связанные с ECN методы нарушения сквозного контроля насыщения

Мы показали, что во многих случаях враждебный или некорректно настроенный маршрутизатор, который может изменять биты поля ECN, не способен внести больших помех, чем он мог бы доставить простым отбрасыванием пакетов. Однако это верно не во всех случаях — в частности, такое допущение неверно для некорректно работающих маршрутизаторов, нарушающих сквозной контроль насыщения путем ложной индикации поддержки ECN или путем удаления индикации насыщения ECN (код CE). Несмотря на наличие множества способов нанесения маршрутизатором вреда потоку за счет отбрасывания пакетов, такое отбрасывание не может нарушить сквозной контроль насыщения. Например, маршрутизатор не способен нарушить контроль насыщения TCP путем отбрасывания пакетов данных, подтверждений или пакетов управления.

Хотя отбрасывание пакетов само по себе не может использоваться для нарушения сквозного контроля насыщения, существуют не связанные с ECN методы нарушения сквозного контроля насыщения, которые могут использоваться враждебнвми или некорректно настроенными маршрутизаторами. Например, некорректно настроенный маршрутизатор может дублировать пакеты данных, сводя на нет сквозной контроль насыщения на неком участке пути (для маршрутизатора, дублирующего пакеты в туннеле IPsec, администратор безопасности может настроить отбрасывание дубликатов путем организации в туннеле защиты против повторов). Такое дублирование пакетов в сети будет оказывать на сеть и нарушенные потоки такое же влияние, как в описанных выше (параграфы 18.1.1 и 18.1.4) случаях.

20. Обоснование для маркеров ECT

20.1. Обоснование для кодов ECT

Необходимость введения кода ECT обусловлена тем, что развертывание ECN в сети Internet будет осуществляться поэтапно и не все транспортные протоколы и марщрутизаторы будут понимать ECN. При использовании кода ECT маршрутизатор может отбрасывать пакеты, которые не совместимы с ECN, но может «взамен» отбрасывания устанавливать код CE в пакетах, которые «поддерживают» ECN. Поскольку код ECT позволяет конечному узлу получать код CE «вместо» информации об отбрасывании пакета, это дает стимул для внедрения ECN.

Если в пакете не было кода ECT, маршрутизатор будет устанавливать код CE, как для поддерживающих, так и для не поддерживающих ECN потоков. В этом случае для конечных узлов нет стимула развертывать ECN, а также не обеспечивается путь постепенного перехода к повсеместному использованию ECN. Рассмотрим первый этап постепенного развертывания ECN, когда только часть потоков поддерживает ECN. В начале насыщения, когда скорость отбрасывания/маркировки пакетов мала, маршрутизаторы будут только устанавливать код CE, не отбрасывая пакетов. Однако понимать пакеты с кодом CE и должным образом реагировать на них будут только потоки, поддерживающие ECN. В результате поддерживающие ECN потоки будут снижать скорость, а не понимающие сигналов ECN потоки будут работать с прежним размером окна насыщения.

В этом случае возможны два варианта: (1) поддерживающий ECN поток снижает скорость, не поддерживающий ECN поток забирает освободившуюся полосу и насыщение сохраняется или (2) поддерживающий ECN поток снижает скорость, а не поддерживающий — не снижает и перегрузка возрастает, пока маршрутизатор не переходит от маркировки пакетов кодом CE к отбрасыванию пакетов. Хотя второй вариант не вполне беспристрастен, поддерживающий ECN поток в этом получает некоторые преимущества, поскольку увеличившееся насыщение заставляет маршрутизатор перейти в режим отбрасывания пакетов.

Поток, анонсирующий свою поддержку ECN, но не отвечающий на код CE, функционально эквивалентен потоку, в котором выключен контроль насыщения, как обсуждалось ранее в этом документе.

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

20.2. Обоснование для двух кодов ECT

Основной причиной использования двух кодов ECT является необходимость поддержки однобитовых сигналов ECN nonce. Эти сигналы позволяют разработать для отправителя механизмы вероятностной проверки того, что элементы сети не удаляют код CE, а получатели данных корректно уведомляют отправителя о получении пакетов с кодом CE.

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

Выделение четвертого кода ECN — ECT(1) преследовало иные цели. Для ясности эти цели кратко перечислены здесь.

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

Второй возможной целью является использование четвертого кода ECN для предоставления маршрутизаторам двух разных кодов насыщения — CE(0) и CE(1) для слабого и сильного насыщения, соответственно. Это может быть полезно в некоторых случаях, однако такое требование не представляется целесообразным. Если внести это требование, сложность постепенного развертывания существенно возрастет по сравнению со случаем использования одного кода.

Третьим неформально предложенным вариантом использования четвертого кода ECN является его применение в некоторых формах контроля насыщения для групповых приложений на основе процедур случайного дублирования маркированных пакетов в маршрутизаторах. Некоторые из предложенных процедур дублирования multicast-пакетов на маршрутизаторах основаны на новом коде ECN, который (1) переносит информацию о перегрузке в восходящем направлении от точки дублирования, промаркировавшей пакет этим кодом, и (2) может детектировать перегрузку в нисходящем направлении от точки дублирования. ECT(1) можно использовать для этой цели, поскольку этот код отличается от ECT(0) и заменяется кодом CE при маркировке ECN в ответ на перегрузку или начало насыщения. Описание этой расширенной версии использования ECN для контроля насыщения в групповых приложениях выходит за пределы данного документа, как и процедуры дублирования групповых пакетов, совместимые с ECN или обработка поля ECN получателями группового трафика во всех случаях (т. е., независимо от использования процедур дублирования multicast-пакетов).

Спецификация изменения туннелей IP для ECN в этом документе предполагает, что единственным изменением, которое вносится в поле ECN внешнего заголовка IP между конечными точками туннеля, является установка кода CE для индикации насыщения. Это не согласуется с предложениями по использованию ECT(1) процедурами дублирования multicast-пакетов, рассмотренными в предыдущем параграфе и такие процедуры не следует развертывать до разрешения противоречия между процедурами дублирования и туннелями IP с полной функциональностью ECN. Взамен может использоваться ограниченная функциональность ECN, хотя на практике многие протоколы туннелирования (включая IPsec) не будут корректно работать при дублировании группового трафика в туннеле.

21. Зачем использовать два бита в заголовке IP?

Необходимость индикации ECT в заголовке IP понятна, но остается вопрос о возможности использования для кодов ECT (транспорт с поддержкой ECN) и CE (обнаружено насыщение) одного бита в заголовке. Такое однобитовое представление предложено в работе [Floyd94]. Одно значение «ECT, но без CE» будет представлять поддерживающий ECN транспорт, а другое — «CE или без ECT» будет представлять факт насыщения или транспорт без поддержки ECN.

Различие между однобитовой и двухбитовой реализацией возникает для пакетов, проходящих через множество перегруженных маршрутизаторов. Рассмотрим пакет с кодом CE, который приходит на второй перегруженный маршрутизатор и выбирается системой активного управления очередью на маршрутизаторе для маркировки или отбрасывания. В однобитовом варианте второму перегруженному маршрутизатору остается только один вариант, отбросить пакет с кодом CE, поскольку этот маршрутизатор не может отличить пакет с кодом CE от пакета без ECT. В двухбитовом варианте второй перегруженный маршрутизатор может отбросить пакет с кодом CE или переслать его дальше, сохранив код CE.

Другое различие между однобитовыми и двухбитовыми реализациями заключается в том, что в однобитовом случае получатель не может различить пакеты CE и non-ECT в одном потоке. Таким образом, в однобитовой реализации поддерживающий ECN дает получателю неоднозначную индикацию поддержки ECN. У отправителя остается возможность показать поддержку ECN в заголовке транспортного уровня. Другим вариантом является функциональное ограничение для однобитовых реализаций, в соответствии с которым отправитель трактует все переданные им пакеты как поддерживающие или не поддерживающие ECN. Для транспортных протоколов с групповой адресацией такая неоднозначная индикация будет представляться получателю подключением к действующему multicast-сеансу.

Другой, рассмотренный выше вопрос (и рекомендация) касается того, что транспортному протоколу (в частности, TCP) не следует маркировать чистые пакеты ACK и пакеты, передаваемые повторно, как поддерживающие ECN. Чистый пакет ACK из неподдерживающего ECN транспорта может быть отброшен без воздействия на транспорт с точки зрения контроля насыщения (поскольку подтверждения кумулятивны). Поддерживающий ECN транспорт реагирует на код CE в чистом пакете ACK снижением размера окна насыщения и такое поведение является проигрышным по сравнению с транспортом без поддержки ECN. По этой причине (и по описанным выше причинам в части повторно передаваемых пакетов), желательно устанавливать код ECT независимо для каждого пакета.

Другим преимуществом двухбитового варианта является повышенная отказоустойчивость. Наиболее критический момент, описанный в разделе 8, заключается в том, что по умолчанию следует указывать не поддерживающий ECN транспорт. В двухбитовом варианте для реализации этого требования достаточно просто устанавливать по умолчанию код not-ECT. В однобитовом варианте для выполнения этого требования следует устанавливать код «CE или ECT». Этот вариант менее понятен и, возможно, более открыт для некорректных реализаций на конечных узлах или маршрутизаторах.

Хотя в целом обнобитовая реализация вполне допустима, она имеет ряд существенных недостатков по сравнению с двухбитовым вариантом. Во-первых, функциональность однобитового варианта существенно ограничена в плане трактовки пакетов с кодом CE на втором перегруженном маршрутизаторе. Во-вторых, однобитовый вариант требует передачи дополнительной информации в заголовке транспортного уровня пакетов из поддерживающего ECN потока (функциональность двухбитового варианта просто переносится на транспортный уровень) или понимания со стороны отправителей поддерживающих ECN потоков того, что получатели должны быть способны а-приори определить какие пакеты поддерживают ECN, а какие не поддерживают. В-третьих, однобитовая реализация потенциально более открыта для ошибок со стороны некорректных реализаций, которые могут по умолчанию устанавливать неверное значение бита ECN. Мы полагаем, что перечисленные ограничения обеспечивают достаточные основания использования дополнительного бита в заголовке IP для кодов ECT.

22. Ретроспектива использования октета IPv4 TOS

RFC 791 [RFC791] определяет октет ToS (Type of Service — тип обслуживания) в заголовке IP. В RFC 791 биты 6 и 7 октета ToS отмечены, как резервные (Reserved for Future Use), и указано, что они имеют нулевое значение. Первые два поля октета ToS определены в документе, как Precedence (предпочтения) и Type of Service (тип обслуживания — TOS).

   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|   PRECEDENCE    |       TOS       |  0  |  0  |  RFC 791
+-----+-----+-----+-----+-----+-----+-----+-----+

RFC 1122 включает биты 6 и 7 в поле ToS, не обсуждая конкретного их использования:

   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|   PRECEDENCE    |       TOS                   |  RFC 1122
+-----+-----+-----+-----+-----+-----+-----+-----+

Октет ToS заголовка IPv4 был заново определен в RFC 1349 [RFC1349], как показано ниже.

   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|   PRECEDENCE    |       TOS             | MBZ |  RFC 1349
+-----+-----+-----+-----+-----+-----+-----+-----+

Бит 6 поля TOS был определен в RFC 1349, как «минимизация финансовых расходов». В дополнение к полям Precedence и TOS было определено поле MBZ (Must be zero — должно иметь нулевое значение), которое в настоящее врямя не используется. В RFC 1349 отмечетно, что отправитель дейтаграмм устанавливает в поле MBZ нулевое значение, если не используется экспериментальных протоколов с иной трактовкой этого бита.

RFC 1455 [RFC 1455] определяет экспериментальный стандарт, использующий все четыре бита поля TOS для запроса гарантированного уровня защиты канала.

Документы RFC 1349 и RFC 1455 были отменены RFC 2474 «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers» [RFC2474], в котором биты 6 и 7 поля DS были указаны, как неиспользуемые (CU — Currently Unused). В RFC 2780 [RFC2780] содержится спецификация ECN для экспериментального использования двухбитового поля CU. RFC 2780 обновляет определение поля DS Field, оставляя в нем лишь первых шесть битов, которые трактуются, как коды дифференцированного обслуживания (DSCP — Differentiated Services CodePoint). Формат поля показан на рисунке.

   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|               DSCP                |    CU     |  RFCs 2474,
+-----+-----+-----+-----+-----+-----+-----+-----+    2780

Поскольку история еще не завершена, определение поля ECN в данном документе не гарантирует совместимости со всеми предшествующими вариантами использования этих двух битов.

До RFC 2474, маршрутизаторам не разрешалось менять биты в полях DSCP и ECN пересылаемых пакетов и, следовательно, маршрутизаторы, соответствующие только требованиям RFC до 2474, не оказывают влияния на ECN. Для конечных узлов бит 7 (второй бит ECN) должен передаваться с нулевым значением всеми реализациями, совместимыми только с RFC до 2474. Такие узлы могут передавать в бите 6 (первый бит ECN) единицу для указания необходимости экономной передачи (Minimize Monetary Cost) в соответствии с RFC 1349 или экспериментами, разрешенными RFC 1455, однако оба эти варианта не получили широкого распространения. Помехи, которые могут создавать некорректно работающие маршрутизаторы, включают «удаление» кода CE для поддерживающих ECN пакетов, которые поступили на маршрутизатор с установленным флагом CE, и установку кода CE при отсутствии перегрузок. Эти вопросы рассмотрены в параграфе «Неподатливость в сети».

Нарушения в работе поддерживающей ECN среды, которые могут создаваться не совместимыми с ECN конечными узлами, передающими пакеты с установленным кодом ECT, рассмотрены в параграфе «Неподатливость конечных узлов».

23. Согласование с IANA

В этом разделе описаны пространства имен, создаваемые в соответствии с данной спецификацией, или выделяемые для данной спецификации значения в существующих пространствах имен, которые управляются IANA.

23.1. Байт IPv4 TOS и октет IPv6 Traffic Class

Коды для поля ECN в заголовке IP задаются с помощью Standards Action данным RFC в соответствии с RFC 2780.

Когда этот документ будет опубликован в качестве RFC, агентству IANA следует создать новый реестр «IPv4 TOS Byte and IPv6 Traffic Class Octet» с пространством имен:

  • Описание:
  • регистрация идентична для IPv4 и IPv6.
  • Биты 0-5:
  • см. реестр кодов поля Differentiated Services
  • Биты 6-7:
  • поле ECN
Значение Ключевое слово и описание Источник
00 Not-ECT (не поддерживающий ECN транспорт) [RFC 3168]
01 ECT(1) (совместимый с ECN транспорт (1)) [RFC 3168]
10 ECT(0) (совместимый с ECN транспорт (0)) [RFC 3168]
11 CE (Наблюдается насыщение) [RFC 3168]

23.2. Флаги заголовка TCP

Коды для флагов CWR и ECE в заголовке TCP задаются, как Standards Action в данном RFC, в соответствии с RFC 2780.

При публикации этого документа в качестве RFC агентству IANA следует создать новый реестр «TCP Header Flags» с именем

TCP Header Flags (Флаги заголовка TCP)

Заголовок TCP включает 6-битовое резервное поле, определенное в RFC 793, в байтах 13 и 14, как показано на рисунке. Остальные шесть битов управления определены в RFC 793.

  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 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

RFC 3168 определяет два из шести битов резервного (Reserved) поля для использования в ECN, как показано на рисунке:

  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 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Флаги заголовка TCP показаны в таблице:

Бит Имя Источник
8 CWR (Congestion Window Reduced) [RFC 3168]
9 ECE (ECN-Echo) [RFC 3168]

23.3. Атрибуты IPSEC Security Association

Агентство IANA выделило значение атрибута IPSEC Security Association = 10 для ECN Tunnel, как описано в параграфе 9.2.1.2 по запросу David Black в ноябре 1999. В настоящее время агентство IANA сменило ссылку (Reference) для этого выделения с David Black на данный RFC.

Адреса авторов

K. K. Ramakrishnan
TeraOptic Networks, Inc.
Phone: +1 (408) 666-8650
EMail: moc.citpoaret@kk

Sally Floyd
ACIRI
Phone: +1 (510) 666-2989
EMail: gro.irica@dyolf

David L. Black
EMC Corporation
42 South St. Hopkinton, MA 01748
Phone: +1 (508) 435-1000 x75140
EMail: moc.cme@divad_kcalb

2007 - 2022 © Русские переводы RFC, IETF, ISOC.