Статус документа
Этот документ определяет экспериментальный протокол (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].