RFC: 3540
Оригинал: Robust Explicit Congestion Notification (ECN) Signaling with Nonces
Категория: Экспериментальный
Дата публикации:
Авторы: , ,
Перевод: Николай Малых

Страница 1 из 13

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

Этот документ определяет экспериментальный протокол (Experimental Protocol) для сообщества Internet. Документ не содержит спецификаций каких-либо стандартов и служит приглашением к дискуссии в целях развития протокола. Допускается свободное распространение документа.

Тезисы

В это документе описано необязательное расширение ECN-nonce, обеспечивающее для ECN (Explicit Congestion Notification — явное уведомление о насыщении) защиту от случайного или преднамеренного сокрытия пакетов, помеченных отправителем TCP. Расширение повышает устойчивость работы систем контроля насыщения, предотвращая возможность использования ECN для неправомерного захвата полосы сетевых соединений. ECN-nonce использует два кода ECT (ECN-Capable Transport — поддерживающий ECN транспорт) в поле ECN заголовков IP и требует наличия флага в заголовке TCP. Расширение эффективно работает как на маршрутизаторах, так и на хостах.

1. Введение

Данная спецификация описывает необязательное дополнение к ECN [RFC3168], повышающее устойчивость к случайному или преднамеренному сокрытию помеченных ECN пакетов. Это расширение не будет развертываться повсеместно. Одной из целей публикации данного RFC со статусом Experimental является является осторожное развертывание и использование протокола до начала его стандартизации. Другой целью публикации является обеспечение разработчикам межсетевых экранов времени для признания и восприятия модели, представленной с помощью nonce. Рабочая группа Transport Area заново представит эту спецификацию в качестве IETF Proposed Standard (проект стандарта) в будущем после обретения необходимого опыта.

Для корректной работы ECN нужна кооперация получателя (для передачи отправителю сигнала о насыщении — CE) и отправителя, однако протокол не обеспечивает механизма для такой кооперации. Это ведет к тому, что неаккуратно или некорректно настроенные получатели всегда будут сбрасывать ECN-Echo и просто не будут сообщать отправителю о возникновении перегрузки в сети. Такое поведение дает получателю преимущества в скорости по сравнению с корректно настроенными соединениями. Более того, любое устройство на пути (транслятор адресов NAT, межсетевой экран, формирователь полосы QoS и т. п.) может безнаказанно удалить индикаторы перегрузки.

Такое поведение может создавать угрозу работе системы контроля насыщения в Internet. С учетом роли системы контроля насыщения разумно разработать сигнальный механизм ECN, который будет обеспечивать устойчивость к максимально возможному числу угроз. ECN-nonce обеспечивает простой и эффективный механизм предотвращения недопустимого использования ECN.

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

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

Отметим также, что использование ECN-nonce дает два дополнительных преимущества, даже если использовать только маршрутизаторы drop-tail. Во-первых, отбрасывание пакетов не может быть скрыто от отправителя. Во-вторых, он позволяет предотвратить излишне оптимистичные подтверждения [Savage], когда сегменты TCP подтверждаются еще до их получения. Эти преимущества также служат повышению устойчивости системы контроля насыщения к атакам. Детального рассмотрения этих преимуществ в данном документе не приводится.

Остальная часть документа содержит описание механизма ECN-nonce в виде обзора с последующим детальным описанием поведения отправителей и получателей.

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

Страница 1 из 13

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