|
|
|
|
||||||
|
|
|
|
||||||
|
|
|
|||||||
|
|
||||||||
|
Network Working Group Request for Comments: 3540 Category: Experimental
|
N. Spring
D. Wetherall
D. Ely
University of Washington
June 2003
|
|||||||
|
|
||||||||
|
Устойчивый механизм сигнализации насыщения с помощью ECN-nonce
Robust Explicit Congestion Notification (ECN) Signaling with Nonces
Статус документа
Этот документ определяет экспериментальный протокол (Experimental Protocol) для сообщества Internet. Документ не содержит спецификаций каких-либо стандартов и служит приглашением к дискуссии в целях развития протокола. Допускается свободное распространение документа.
Авторские права
Copyright (C) The Internet Society (2003). All Rights Reserved.
Тезисы
В это документе описано необязательное расширение ECN-nonce, обеспечивающее для ECN1 защиту от случайного или преднамеренного сокрытия пакетов, помеченных отправителем TCP. Расширение повышает устойчивость работы систем контроля насыщения, предотвращая возможность использования ECN для неправомерного захвата полосы сетевых соединений. ECN-nonce использует два кода ECT2 в поле ECN заголовков IP и требует наличия флага в заголовке TCP. Расширение эффективно работает как на маршрутизаторах, так и на хостах.
1. Введение
Назначение
Данная спецификация описывает необязательное дополнение к ECN [RFC3168], повышающее устойчивость к случайному или преднамеренному сокрытию помеченных ECN пакетов. Это расширение не будет развертываться повсеместно. Одной из целей публикации данного RFC со статусом Experimental является является осторожное развертывание и использование протокола до начала его стандартизации. Другой целью публикации является обеспечение разработчикам межсетевых экранов времени для признания и восприятия модели, представленной с помощью nonce3. Рабочая группа Transport Area заново представит эту спецификацию в качестве IETF Proposed Standard (проект стандарта) в будущем после обретения необходимого
|
||||||||
|
|
опыта.
|
|
||||||
|
|
||||||||
|
Для корректной работы ECN нужна кооперация получателя (для передачи отправителю сигнала о насыщении - CE4) и отправителя, однако протокол не обеспечивает механизма для такой кооперации. Это ведет к тому, что неаккуратно или некорректно настроенные получатели всегда будут сбрасывать ECN-Echo и просто не будут сообщать отправителю о возникновении перегрузки в сети. Такое поведение дает получателю преимущества в скорости по сравнению с корректно настроенными соединениями. Более того, любое устройство на пути (транслятор адресов NAT, межсетевой экран, формирователь полосы QoS и т. п.) может безнаказанно удалить индикаторы перегрузки.
Такое поведение может создавать угрозу работе системы контроля насыщения в Internet. С учетом роли системы контроля насыщения разумно разработать сигнальный механизм ECN, который будет обеспечивать устойчивость к максимально возможному числу угроз. ECN-nonce обеспечивает простой и эффективный механизм предотвращения недопустимого использования ECN.
ECN-nonce позволяет отправителю проверить корректность поведения получателя ECN и не вносит искажений, которые могли бы привести к сокрытию помеченных (или отброшенных) пакетов на сигнальном пути. Механизм ECN-nonce защищает как от ошибок в реализациях, так и от злонамеренного использования. Этот механизм:
♦ с высокой вероятностью детектирует некорректно работающих получателей и не оказывает влияния на добросовестных получателей;
♦ не меняет других аспектов использования ECN и не снижает преимуществ, обеспечиваемых ECN для корректно работающих получателей;
♦ практически не добавляет служебной информации (один флаг в заголовке TCP) и не требует значительных ресурсов для обработки;
|
||||||||
|
|
||||||||
|
1Explicit Congestion Notification – явное уведомление о насыщении.
2ECN-Capable Transport – поддерживающий ECN транспорт.
3Мне не удалось найти выражения в русском языке, подходящего для перевода этого термина в контексте данного документа.
Трактовку английского слова nonce можно посмотреть на сайте Wikipedia – http://en.wikipedia.org/wiki/Nonce. Прим. перев.
4Congestion Experienced – перегрузка в сети.
|
||||||||
|
|
||||||||
|
|
|||||||||||||||
|
|
Перевод RFC 3540
|
||||||||||||||
|
|
|||||||||||||||
|
♦ прост и по имеющимся данным не подвержен другим атакам.
Отметим также, что использование ECN-nonce дает два дополнительных преимущества, даже если использовать только маршрутизаторы drop-tail5. Во-первых, отбрасывание пакетов не может быть скрыто от отправителя. Во-вторых, он позволяет предотвратить излишне оптимистичные подтверждения [Savage], когда сегменты TCP подтверждаются еще до их получения. Эти преимущества также служат повышению устойчивости системы контроля насыщения к атакам. Детального рассмотрения этих преимуществ в данном документе не приводится.
Остальная часть документа содержит описание механизма ECN-nonce в виде обзора с последующим детальным описанием поведения отправителей и получателей.
Ключевые слова: необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно
(OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].
|
|||||||||||||||
|
|
|||||||||||||||
|
2. Обзор
Работа ECN-nonce строится на базе существующих сигнальных механизмов ECN-Echo и CWR6. Предполагается знакомство читателя ECN [ECN]. Для простоты ECN-nonce описывается только для одного направления, хотя этот механизм работает параллельно в обоих направлениях.
Протокол ECN для TCP сохраняется неизменным за исключением добавления нового поля в заголовок TCP. В соответствии с [RFC3168] в поле ECN заголовка IP исходящих пакетов устанавливается код ECT(0) или ECT(1). Перегруженные маршрутизаторы изменяют значение этого поля на CE. Когда получатель TCP видит код CE, он устанавливает флаг ECE7 в последующих подтверждениях, пока не получит флаг CWR. Этот флаг (CWR) устанавливается отправителем в новых данных в результате реакции отправителя на перегрузку.
ECN-nonce позволяет получателю уведомить отправителя, что подтверждаемый сегмент отправителя был принят без маркеров перегрузки. Случайное однобитовые значения (nonce) помещаются в 2-битовый код ECT. Однобитовая сумма этих значений возвращается в виде флага в заголовке TCP, называемого битом NS8. Маркировка пакетов удаляет значения nonce в кода ECT, поскольку CE переписывает оба бита ECN в заголовках IP. Поскольку для расчета суммы требуется каждое значение nonce, корректная сумма предполагает получение непомеченного пакета. В результате не только предотвращается сокрытие маркировки не получателями, но и возможность снятия маркеров на промежуточных маршрутизаторах без предсказания исходных значений nonce.
Отправитель может проверить возвращенную получателем сумму значений nonce, чтобы убедиться в том, что индикация перегрузки путем маркировки (или отбрасывания) пакетов не была скрыта. Поскольку сумма nonce выражается в виде одного бита, отправитель имеет 50% вероятность обнаружения получателей, скрывающих наличие индикатора перегрузки. Поскольку каждое подтверждение представляет собой независимую попытку такого определения, обман разоблачается очень быстро, если сигналы о насыщении повторялись.
В следующих параграфах приводится более детальное описание протокола ECN-nonce.
|
|||||||||||||||
|
|
|||||||||||||||
|
В каждом подтверждении содержится сумма значений
nonce, которая представляет собой 1-битовый результат
сложения (четность или исключающее ИЛИ) значений
nonce для подтверждаемого диапазона байтов. Сумма
используется по той причине, что не каждый пакет
подтверждается индивидуально и гарантия доставки
|
Отправитель
|
Получатель исходная сумаа
|
= 1
4) = 1(:4)
1(4:8) = 0(:8)
1(8:12) = 1(:12)
1(12:16) = 0(:16)
|
||||||||||||
|
<-
|
1:4 ЕСТ(О) АСК 4, NS=1 -4:8 ЕСТ(1) АСК 8, NS=0 -8:12 ЕСТ(1) АСК 12, NS=1 12:16 ЕСТ(1) АСК 16, NS=0
|
-> NS
|
1 + 0(1
|
||||||||||||
|
-> NS
|
|
+
|
|
||||||||||||
|
<-
|
1(:4)
|
||||||||||||||
|
0(:8) 1(:12)
|
|||||||||||||||
|
подтверждений не обеспечивается. Если не пользоваться
|
-> NS
|
+
|
|||||||||||||
|
суммой, можно будут просто возвращать значение nonce
|
<-
|
||||||||||||||
|
-> NS
|
|||||||||||||||
|
из пакета без маркировки для уведомления отправителя
|
+
|
||||||||||||||
|
о том, что пакет был доставлен без маркировки. Однако
|
<-
|
||||||||||||||
|
|
|||||||||||||||
|
в силу того, что для таких подтверждений доставка не
гарантируется, отправитель не сможет отличить потерю
подтверждения ACK от сокрытия маркированных
|
Рисунок 1: Расчет суммы значений nonce (NS) на приемной стороне.
|
||||||||||||||
|
пакетов. Использование суммы nonce не позволяет
получателю скрывать получение пакетов с марками путем простого отказа от их подтверждения. Поскольку значения nonce и
сумма этих значений являются однобитовыми, предсказание суммы не проще, чем предсказание отдельных значений. Расчет
суммы значений nonce показан на рисунке 1.
|
|||||||||||||||
|
|
|||||||||||||||
|
Отправитель
|
Получатель исходная сумаа
|
= 1 0(1
|
4) = 1(:4)
|
После того, как в сети возникло насыщение и пакеты были помечены или потеряны, требуется ресинхронизация сумм nonce между отправителем и получателем. При маркировке пакетов значения nonce сбрасываются и сумма nonce на приемной стороне не будет совпадать с суммой на стороне отправителя. После потери значений nonce различие в суммах у отправителя и получателя будет сохраняться до следующей потери. Это означает, что можно ресинхронизировать отправителя и получателя после перегрузки путем установки на передающей стороне значения суммы, принятой от получателя. Поскольку индикацию перегрузки не требуется делать чаще, чем один раз за период кругового обхода (round trip), устанавливает для своей суммы nonce значение,
|
|||||||||||
|
|
|
-> NS = 1 +
|
|
||||||||||||
|
1:4 ЕСТ(О) АСК 4, NS=1 4:8 ЕСТ(1) -> СЕ АСК 8, ЕСЕ NS=1 8:12 ЕСТ(1), CWR АСК 12, NS=0 12:16 ЕСТ(1) АСК 16, NS=1
|
|||||||||||||||
|
-> NS = 1(:4) + ?(4:8) = 1(:8) -> NS = 1(:8) + 1(8:12) = 0(:12) -> NS = 0(:12) + 1(12:16) = 1(:16)
|
|||||||||||||||
|
Рисунок 2: Расчет NS на приемной стороне при маркировке пакета
(4:8). Получатель может рассчитать некорректное значение
суммы в результате утери nonce при маркировке пакета.
отправитель прекращает проверку суммы при получении сигнала CWR и
|
|||||||||||||||
|
|
|||||||||||||||
|
5Вариант управления очередями в маршрутизаторах. Прим. перев.
6Congestion Window Reduced – уменьшение размера окна насыщения.
7ECN-Echo
8Nonce sum – сумма значений nonce
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|||
|
Перевод RFC 3540
|
|
||
|
|
|||
|
принятое от получателя с подтверждением новых данных. Преимуществом такого подхода является то, что получатель явно не вовлечен в процесс ресинхронизации. Иллюстрация процесса показана на рисунке 2. Отметим, что сумма nonce, возвращенная в ACK 12 (NS=0) отличается от суммы в предыдущем примере (NS=1) и сохраняет отличие для ACK 16 на рисунке 2.
Нам нужно еще согласовать значения nonce, передаваемые в пакетах и подтверждающие диапазон принятых байтов. Байтовые границы для подтверждений не обязательно соответствуют границам при передаче, а при повторе пакеты могут передаваться с иными границами. Первый вопрос об установке nonce при подтверждении части сегмента рассматривается в параграфе 6.1. Второй вопрос о значении nonce, передаваемом при повторе мелкого сегмента в большом имеет простой ответ - ECN отключается при повторе, поэтому nonce не передается. Поскольку повторы передачи связаны с фактами насыщения, проверка nonce отключается, пока не будет подтверждения CWR и насыщение не закончится.
В следующих параграфах подробно рассматривается поведение отправителей, маршрутизаторов и получателей, начиная с передачи данных отправителем. Далее рассматривается сигнальный цикл ECN и в заключение описан процесс обработки подтверждения отправителем.
3. Поведение отправителя (передача)
Отправителя управляют CWR и ECN-Echo как это делалось раньше. Кроме того, они должны включать значения nonce в передаваемые пакеты и проверять корректность сумм nonce в принятых подтверждениях. Данный параграф описывает процесс передачи.
Для включения однобитового значения nonce в каждый совместимый с ECN пакет IP отправитель использует два кода ECT - ECT (0) представляет nonce = 0, а ECT(1) - nonce = 1. Как и в ECN повтор передачи не совместим с использованием ECN, поэтому пакет не включает значения nonce.
Отправитель поддерживает отображение порядкового номера для окончания каждого пакета в сумму nonce (а не значение nonce, включенное в исходную передачу), ожидаемую в подтверждении, соответствующем этому порядковому номеру.
4. Поведение маршрутизатора
Маршрутизаторы ведут себя в соответствии с [RFC3168]. При маркировке пакетов для индикации перегрузки исходное значение nonce в ECT(0) или ECT(1) теряется. Ни получатель, ни любой другой узел не могут снять маркировку пакета без предсказания исходного значения nonce.
5. Поведение получателя (прием и передача)
Получатель ECN-nonce поддерживает сумму значений nonce, вычисляемую по мере доставки пакетов, и возвращает текущее значение суммы nonce в каждом подтверждении. В остальном поведение получателя не отличается от [RFC3168]. Возврат суммы nonce не требуется, но рекомендуется, поскольку отправителям разрешено прекращать передачу поддерживающих ECN пакетов получателям, которые не поддерживают ECN-nonce.
По мере того, как пакеты удаляются из очереди доставленных с нарушением порядка пакетов для подтверждения, значения nonce восстанавливаются из заголовков IP. Полученное из заголовка значение nonce прибавляется к текущему значению суммы nonce как подтверждение порядкового номера для недавнего пакета.
В случае маркировки пакетов одно или множество значений nonce будет неизвестно получателю. В этом случае отсутствующие значения nonce игнорируются при расчете суммы (или в расчет включается нулевое значение nonce) и устанавливается флаг ECN-Echo для индикации насыщения отправителю.
Возврат суммы nonce, 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
соответствующей данному +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
подтверждению, прост. Сумма | | | N | C | E | U | A | P | R | S | F |
передается в фиде однобитового флага | Header Length | Reserved | S | W | C | R | C | S | S | Y | I |
NS9 в заголовке TCP. Этот бит | | | | R | E | G | K | H | T | N | N |
размещается рядом с битами CWR и +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ ECN-Echo, занимая битовую позицию 7
в байте 13 заголовка TCP, как показано Рисунок 3: Новое определение байтов 13 и 14 заголовка TCP
на рисунке 3.
Начальное значение суммы nonce равно 1 и это значение включается в пакеты SYN/ACK и ACK трехэтапного согласования TCP. Это позволяет удаленной точке определить факт поддержки nonce, но не является согласованием и получателю SYN/ACK не требуется проверять наличие флага NS для принятия решения об установке NS в последующем пакете ACK.
6. Поведение отправителя (прием)
Этот параграф дополняет описание поведения отправителя, рассматривая этап проверки полученных значений суммы nonce.
Сумма nonce проверяется при получении подтверждения доставки новых данных за исключением периодов восстановления после перегрузки, когда дополнительные сигналы ECN-Echo будут игнорироваться. Проверка заключается в сравнении корректной суммы nonce, хранящейся в буфере, со значением из подтверждения с учетом рассмотренных ниже корректировок.
Если флаг ECN-Echo не установлен, это свидетельствует о том, что получатель не принимал пакетов с маркерами и, следовательно, может рассчитать и возвратить корректную сумму nonce. Для сокрытия маркеров получатель должен угадать сумму значений nonce, которые не были получены, поскольку по крайней мере один пакет был промаркирован и значение nonce было удалено. Поскольку nonce может с равной вероятностью принимать значения 0 или 1, сумма этих значений также может с равной вероятностью быть 0 или 1. Иными словами, вероятность угадывания составляет 50%. Благодаря тому, что каждое новое подтверждение является независимой попыткой угадать значений, отправитель может обнаружить подмену после небольшого числа удачных обманов.
Если флаг ECN-Echo, это говорит о том, что получатель сигнализирует о перегрузки сети и сумму nonce проверять не нужно. Окно насыщения будет уменьшено наполовину, в следующем передаваемом пакете данных будет установлен флаг CWR и флаг ECN-Echo будет сброшен после получения сигнала CWR, как описано в [RFC3168]. В течение этого процесса восстановления сумма
|
|||
|
|
|||
|
9Nonce Sum
|
|||
|
|
|||
|
|
|||
|
|
Перевод RFC 3540
|
||
|
|
|||
|
может быть некорректной, поскольку одно или несколько значений nonce не будут получены. Это не имеет значения на этапе восстановления, поскольку TCP активизирует механизмы контроля насыщения не более одного раза за период RTT10, независимо от количества потерь пакетов за этот период.
6.1. Ресинхронизация после потери или маркировки
После восстановления требуется заново Отправитель Получатель
синхронизировать суммы nonce для исходная сумаа = 1
отправителя и получателя, чтобы была -- 1:4 ECT(0) -> NS = 1 + 0(1:4) = 1(:4)
возможность дальнейшей проверки <- ACK 4, NS=1 --
подтверждений. Когда сумма на стороне -- 4:8 ECT(1) -> LOST
получателя некорректна, эта -- 8:12 ECT(1) -> расчет суммы nonce откладывается
некорректность будет сохраняться пока до восстановления порядка доставки
будут продолжаться потери. Это <- ACK 4, NS=0 --
позволяет воспользоваться простым -- 12:16 ECT(1) -> расчет суммы nonce отложен
механизмом ресинхронизации, когда <- ACK 4, NS=0 --
отправитель сбрасывает свою сумму -- 4:8 retransmit -> NS = 1(:4) + ?(4:8) +
nonce в то значение, которое получатель 1(8:12) + 1(12:16) = 1(:16)
указал в подтверждении данных, <- ACK 16, NS=1 --
полученных после снижения размера -- 16:20 ECT(1) CWR ->
окна насыщения. При обработке явных <- ACK 20, NS=0 -- NS = 1(:16) + 1(16:20) = 0(:20)
сигналов о насыщении это будет первое
подтверждение без флага ECN-Echo Рисунок 4: Расчет сумм nonce на стороне получателя в случае потери
(подтверждение пакета, содержащего пакетов и ресинхронизация после потери. Сумма nonce не изменяется, пока не
флаг CWR). будет кумулятивного подтверждения.
На практике ресинхронизация может быть обеспечена за счет сохранения бита, которые имеет значение 1, если хранящееся у отправителя ожидаемое значение суммы отличается от суммы, полученной в подтверждении CWR и 0 в остальных случаях. Этот бит смещения синхронизации может использоваться при сравнении ожидаемой суммы с принятым значением суммы nonce.
Отправителю следует игнорировать значения суммы nonce, возвращаемые в подтверждениях с флагом ECN-echo.
Когда подтверждение относится лишь к части сегмента (например, в результате ресегментации TCP на промежуточном узле вместо использования фрагментации пакетов IP), отправителю следует принять сумму nonce, ожидаемую для следующей границы сегмента. Иными словами, подтверждения, относящиеся лишь к части исходного сегмента, будут включать ожидаемую сумму nonce только тогда, когда сегмент подтвержден полностью.
Следует отметимть, что при использовании ECN отправитель может по той или иной причине не указывать для некоторых пакетов поддержку ECN. Отправитель ECN-nonce должен после передачи таких пакетов выполнять ресинхронизацию путем передачи CWR с первым пакетом данных после не поддерживающих ECN пакетов. Отправитель теряет защиту для всех неподтвержденных пакетов, пока не произойдет ресинхронизация.
6.2. Поведение отправителя при получении некорректной суммы Nonce
Реакция отправителя на получение некорректной суммы nonce является вопросом политики. Эти действия не связаны с механизмом проверки корректности и необязательно одинаковы для всех отправителей. Более того, проверка корректности полученных сумм nonce не является обязательной и может быть отключена.
Если получатель никогда не передает отличных от нуля сумм nonce, отправитель может предположить, что получатель не понимает nonce и ограничить скорость соединения, помещая его в очередь с низким приоритетом или прекращая установку ECT в передаваемых сегментах.
Если принятая сумма nonce была установлена в предыдущем подтверждении, отправитель может предположить, что устройство в сети конфликтует с корректной сигнализацией между поддерживающими ECN-nonce конечными точками. Минимальный отклик на получение некорректной суммы nonce совпадает с откликом на получение ECE. Однако для компенсации скрытых сигналов о насыщении отправитель может снизить размер окна насыщения для одного сегмента и прекратить установку ECT в исходящих сегментах. Некорректная сумма nonce является признаком некорректного поведения или наличия ошибок между парой поддерживающих ECN-nonce конечных точек.
6.2.1. Использование ECN-nonce для защиты от некорректного поведения
Механизм ECN-nonce может обеспечивать дополнительные средства повышения устойчивости сверх проверки передачи сигналов о маркировке пакетов. Этот механизм также препятствует сокрытию фактов отбрасывания пакетов от их отправителя (поскольку значения nonce из таких пакетов теряются). Отбрасывание пакетов потенциально возможно в дефектных реализациях TCP, во время некоторых атак и даже при использовании гипотетического ускорителя TCP. Такой ускоритель может играть на том, что он способен выполнить процедуру "fast start" для быстрого резервирования полосы и повторить это для другого соединения или обеспечивать гарантии доставки на прикладных уровнях. Если нужно обеспечить устойчивость к такому поведению, не следует отключать ECN-nonce. Вместо этого нужно уменьшить на 1 размер окна насыщения или, используя очередь с низким приоритетом, наказать дефектную реализацию, продолжая проверки и далее.
ECN-nonce может также детектировать некорректное поведение Eifel [Eifel] – недавно предложенного механизма устранения неопределенности повтора передачи для повышения производительности TCP. Некорректность поведения получателя может выражаться в том, что заявляется только прием исходных передач11, для того, чтобы заставить отправителя отказаться от выполненных действий по предотвращению перегрузки. Поскольку повторы передаются без ECT (и, следовательно, без nonce), возврат корректной суммы nonce подтверждает, что были получены только исходные передачи.
|
|||
|
|
|||
|
10Время кругового обхода. Прим. перев. 11А не повторов. Прим. перев.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Перевод RFC 3540
|
|
||
|
|
|||
|
7. Взаимодействие с другими протоколами
7.1. Path MTU Discovery
Как описано в RFC3168, при использовании ECN рекомендуется устанавливать флаг запрета фрагментирования DF. Получатели, которые принимают непомеченные фрагменты могут восстановить исходное значение nonce для сокрытия маркированных фрагментов. ECN-nonce не может обеспечить защиту от некорректного поведения получателей, скрывающих маркированные фрагменты, поэтому часть защитных возможностей теряется в ситуациях, когда запрещено использование Path MTU discovery.
В ответ на малые значения path MTU отправитель будет повторять передачу в виде мелких кадров взамен одного большого. Поскольку эти более мелкие пакеты передаются повторно, они будут несовместимы с ECN и не будут включать nonce. Отправителю следует выполнять ресинхронизацию при первом заново12 переданном пакете.
7.2. SACK
Селективные подтверждения позволяют получателю подтверждать доставку с нарушением порядка в целях оптимизации. Не требуется изменять опцию селективного подтверждения, чтобы использовать суммы nonce, вычисленные для диапазона подтверждаемых байтов, поскольку SACK не может использоваться получателем для сокрытия сигналов насыщения. Сумма nonce соответствует только данным, подтверждаемым кумулятивным пакетом ACK.
7.3. IPv6
Заголовок IPv4 защищен контрольной суммой, но этого нет в IPv6, что повышает вероятность пропуска битовых ошибок в заголовках IPv6. Битовые ошибки, нарушающие целостность полей уведомления о перегрузке могут приводить к получению некорректных значений nonce и возврату некорректных сумм nonce.
8. Вопросы безопасности
Для создания случайных однобитовых значений nonce не требуется криптографического качества генерации случайных чисел. Повышение качества генерации случайных чисел будет вести к потере производительности. В силу сказанного, последовательности случайных значений nonce не следует использовать для каких-либо иных целей.
Псевдослучайную последовательность битов не следует генерировать путем линейного сдвига регистра [Schneier] или с использованием иных подобных этой схем, которые позволяют любому, кто увидел несколько предыдущих битов предсказать функцию генерации и последующие результаты.
Хотя ECN-nonce защищает от сокрытия сигналов насыщения и чересчур оптимистичных подтверждений, этот механизм не обеспечивает дополнительной защиты целостности соединений.
9. Согласование с IANA
Флаг NS (Nonce Sum) передается в резервном бите заголовка TCP, который должен быть выделен для этих целей. Данный документ описывает использование бита 7, смежного другим битам заголовка, используемым для ECN.
Код для флага NS в заголовке TCP задается стандартизацией (Standards Action) данного RFC, как требует RFC 2780. Агентство IANA добавило следующее определение в реестр флагов "TCP Header Flags":
RFC 3540 определяет бит 7 из зарезервированного поля для использования в качестве Nonce Sum, следующим образом:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | N | C | E | U | A | P | R | S | F |
| Header Length | Reserved | S | W | C | R | C | S | S | Y | I | | | | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Флаги заголовков TCP
|
|||
|
|
|||
|
Бит Имя Документ
|
|||
|
|
|||
|
7 NS (Nonce Sum) [RFC 3540]
10. Заключение
ECN-nonce представляет собой простую модификацию сигнального механизма ECN, которая повышает устойчивость ECN за счет предотвращения сокрытия получателями маркированных (или отброшенных) пакетов. Назначение этой работы заключается в повышении уровня устойчивости системы контроля насыщения в Internet. Модификация сохраняет характер и простоту существующей сигнализации ECN. Она практична для развертывания в сети Internet. Механизм использует коды ECT(0) и ECT(1), а также один флаг в заголовке TCP (так же, как CWR и ECN-Echo) и имеет простые правила обработки.
11. Литература
[ECN] "The ECN Web Page", URL "http://www.icir.org/floyd/ecn.html".
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The addition of explicit congestion notification (ECN) to IP", RFC 3168, September 2001.
[Eifel] R. Ludwig and R. Katz. The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions. Computer Communications Review, January, 2000.
[B97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 211913, March 1997.
[Savage] S. Savage, N. Cardwell, D. Wetherall, T. Anderson. TCP congestion control with a misbehaving receiver. SIGCOMM CCR, October 1999.
|
|||
|
|
|||
|
12Не повторно. Прим. перев.
13Перевод этого документа имеется на сайте http://rfc.com.ru. Прим. перев.
|
|||
|
|
|||
|
|
||||
|
|
Перевод RFC 3540
|
|||
|
|
||||
|
[Schneier] Bruce Schneier. Applied Cryptography, 2nd ed., 1996
12. Благодарности
Этот документ основан на результатах исследований Stefan Savage, David Ely, David Wetherall, Tom Anderson и Neil Spring. Мы весьма признательны Sally Floyd за его отклики и помощь.
13. Адреса авторов
Neil Spring
EMail: nspring@cs.washington.edu
|
||||
|
|
||||
|
David Wetherall
Department of Computer Science and Engineering, Box 352350 University of Washington Seattle WA 98195-2350 EMail: djw@cs.washington.edu
|
||||
|
|
||||
|
David Ely
Computer Science and Engineering, 352350 University of Washington Seattle, WA 98195-2350 EMail: ely@cs.washington.edu
|
||||
|
|
||||
|
Перевод на русский язык Николай Малых
|
||||
|
|
||||
|
14 Полное заявление авторских прав
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Подтверждение
Финансирование функций RFC Editor обеспечивается Internet Society.
|
||||
|
|
||||
|
6
|
||||
|
|
||||