Кратко

  • Отправитель случайно выбирал ECT(0) или ECT(1). Маршрутизатор заменял любое из этих значений на CE, стирая различие, которое получателю пришлось бы угадать при сокрытии перегрузки.
  • Накопленная чётность давала вероятностную проверку, а не удостоверение личности или доказательство злого умысла. Нормальная перегрузка тоже уничтожала исходный бит, поэтому требовались пауза и повторная синхронизация.
  • В 2018 году эксперимент завершили, признав, что он работает согласно спецификации. Ограниченное применение больше не оправдывало исключительное резервирование ECT(1).

Доставка данных не означает сохранения всех свидетельств

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

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

Такую идею N. Spring, D. Wetherall и D. Ely изложили в июне 2003 года в экспериментальном RFC 3540. Механизм предназначался для защиты обратной связи от сокрытия отметок и потерь. Он не превращал маршрут в удостоверенную цепочку и не устанавливал личность того, кто исказил сообщение.

Обычная отметка как необратимое преобразование

Классическая схема ECN из RFC 3168, опубликованного в сентябре 2001 года, использует двухбитное поле с четырьмя значениями. Not-ECT соответствует 00, ECT(1) — 01, ECT(0) — 10, а CE — 11. Совместимый пакет можно отметить при перегрузке вместо того, чтобы отбросить. Получатель TCP сообщает о перегрузке с помощью ECE, отправитель обозначает свою реакцию с помощью CWR.

Для маршрутизатора, следующего этой классической семантике, оба ECT допускают отметку. Переход от ECT(0) к CE неотличим на выходе от перехода от ECT(1) к CE. Именно это стирание, а не наличие у CE тайного свойства, стало основой проверки.

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

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

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

Почему проверка накапливалась вместе с ACK

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

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

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

Если получателю неизвестен один равновероятный случайный бит, вероятность угадать правильную чётность составляет одну вторую. Следовательно, обман не обязательно обнаружится с первой попытки. Новая независимая случайная информация, уничтоженная отметками, может дать дополнительные возможности проверки. Но повторные ACK, зависящие от того же пропавшего бита, нельзя автоматически считать независимыми испытаниями.

Это ограничивает и статистические выводы. Большое число строк в трассе ещё не означает большое число независимых свидетельств. Нужно понимать, какая новая неопределённость возникала между сравнениями. Кроме того, чётность не сообщает точное число всех отметок и не сохраняет их полную временную последовательность.

Честный ответ тоже содержит пробел

Получатель, честно сообщающий о CE, не обладает способом восстановить стёртый nonce. RFC 3540 предписывает игнорировать отсутствующее значение, что соответствует вкладу ноль, и выставлять ECE. Во время связанного с этой перегрузкой восстановления отправитель приостанавливает проверку суммы.

После сокращения окна и передачи новых данных с CWR соответствующее подтверждение позволяет заново согласовать исходную точку. Для этого используется сумма получателя; поправку можно представить однобитным смещением. Потерянная история не восстанавливается. Её отсутствие лишь перестаёт искажать все будущие сравнения.

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

Правила 2003 года также делали повторные передачи Not-ECT, без nonce. Периоды без ECT, выбранные самим отправителем, требовали учёта при синхронизации. Это условия исторического эксперимента, а не неизменный запрет для всех современных опытов с повторными передачами и управляющими пакетами. Позднее RFC 8311 ослабил соответствующие ограничения на эксперименты.

Несовпадение не называет виновного

Проверка и реакция в RFC 3540 разделены. Проверять необязательно, а ответ на неверную сумму определяется локальной политикой. Если отправитель реагирует, документ рассматривает как минимум реакцию, соответствующую ECE, а также более сильное сокращение или прекращение использования ECT. Единой системы наказания для интернета из этого не следует.

Есть и технические причины не приписывать любое расхождение злому умыслу получателя. Неотмеченный фрагмент IPv4 способен раскрыть исходный nonce, даже если другой фрагмент был отмечен. Это ослабляет защиту от сокрытия отметки. Битовые ошибки в заголовке IPv6 могут испортить ECN и дать неверную сумму. Частичные подтверждения нужно трактовать относительно границ первоначального сегмента.

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

Даже обнаружение поддержки имеет ограниченный смысл. Ненулевой NS в начальных ответах позволяет предположить наличие функции, но RFC 3540 прямо не называет это согласованием возможностей. Представлять его как согласованную аутентификацию означало бы приписать обмену чужие свойства.

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

Для общей семантики недостаточно существования документа

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

В августе 2015 года RFC 7560 сформулировал требования к более точной обратной связи о перегрузке. Он сообщал, что на тот момент не были известны внедрения nonce в стеках TCP. При этом требование учитывать целостность и стимулы к честному сотрудничеству не сводилось к обязательному сохранению именно этого механизма. Подробность отчёта и проверяемость отчёта оставались разными задачами.

В январе 2018 года RFC 8311 признал, что nonce работает согласно спецификации и применялась в ограниченных средах. Широкого использования, однако, не возникло. Документ объяснил завершение эксперимента и перевод RFC 3540 из Experimental в Historic. Это не утверждение о математической несостоятельности и не заявление, будто реализаций никогда не существовало.

RFC также пересказал исследование на данных 2014 года. Ни один из 581 711 проверенных серверов IPv4 не использовал оба значения ECT после согласования ECN. Среди 17 028 серверов IPv6 таких было четыре, но объяснением могла быть как nonce, так и ошибочная перемаркировка. Числа относятся к датированной выборке с неоднозначной интерпретацией, а не к нынешней переписи интернета; здесь исследование не воспроизводилось независимо.

На фоне других экспериментальных применений и других способов проверки обратной связи сохранять ECT(1) исключительно за nonce уже не считалось оправданным. Освобождение значения не означало разрешения на произвольную несовместимую трактовку. RFC 8311 требовал подходящих Experimental RFC в потоке IETF и сохранял обязанности по управлению перегрузкой и сосуществованию.

Позднейший экспериментальный RFC 9331, опубликованный в январе 2023 года, определил ECT(1) как идентификатор L4S. В актуальном реестре поля ECN у IANA остаются четыре кодировки и ссылки на соответствующие экспериментальные документы. Те же биты в современной трассе уже не доказывают использование nonce 2003 года. Сам факт нового назначения не позволяет здесь судить о распространённости, производительности или общей безопасности L4S.

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