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

RFC 3168, Страница 20 из 56

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 устанавливается для пакета в сети и будет трактоваться получателем, как корректная индикация насыщения.

Страница 20 из 56

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