Кратко

  • В draft-ietf-scone-protocol-09 сказано, что успешная обработка пакета QUIC, сопровождающего SCONE, как минимум включает подтверждение его действительности средствами аутентификации. Если последующие пакеты QUIC отброшены или проигнорированы, в том числе как возможные дубликаты, подсказку о пропускной способности тоже необходимо игнорировать.
  • Отправитель не должен посылать SCONE без иной причины для отправки пакета QUIC. Когда соединение бездействует, прежняя подсказка может устареть. Это формулировки действующего Internet-Draft, а не принятого RFC и не сведения о массовом внедрении.

При разборе захвата трафика соблазнительно выбрать последнее увиденное значение скорости. Но второе наблюдение может относиться к копии уже обработанного зашифрованного пакета. Приёмник распознаёт дубликат и не обрабатывает его заново; вместе с ним теряет силу и новая подсказка SCONE. Иначе простая повторная доставка превращалась бы в способ освежить прикладное состояние, хотя транспортный уровень ничего нового не принял. Время появления поля в сети и время допустимого изменения приложения — разные факты.

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

При этом нельзя подменять предмет проверки. Аутентифицируется сопровождающий пакет QUIC, а не сообщение сетевого элемента о скорости. В разделе безопасности проект прямо называет подсказку неаутентифицированной и описывает противника, который наблюдает подлинный пакет и успевает доставить изменённую копию раньше оригинала. Запрет принимать подсказку после распознавания повтора не является доказательством полной защиты от такой гонки. Тем более он не раскрывает, кто установил число и какая операторская политика за ним стоит.

Ранее Daniel Kade разбирал именно происхождение политического решения; здесь важен новый, более точный порог технического принятия.

Ограничение на отправку отвечает другому вопросу: должен ли протокол сам создавать активность, чтобы старый совет не истёк? Окно наблюдения в проекте по-прежнему составляет 67 секунд; для конечных точек, желающих получать обновления, предусмотрена частота отправки SCONE. Но версия 09 вводит явный запрет: отправлять его можно лишь тогда, когда пакет QUIC всё равно нужен по иной причине. На действующем потоке подсказка идёт попутно. На тихом соединении допустимо дождаться следующей естественной передачи, даже если прежняя рекомендация за это время устареет.

Истечение рекомендации не закрывает автоматически само соединение и не отменяет сетевое ограничение, заданное вне SCONE. Самостоятельно обоснованная проверка живучести QUIC — отдельное решение.

Изменение требует аккуратного языка в телеметрии. «Поле обнаружено», «пакет QUIC подтверждён», «дубликат отклонён», «минимальная подсказка передана приложению» и «срок подсказки истёк» не должны сливаться в один индикатор. В редакции 09 уточнено: если конечная точка сообщает приложению рекомендации, она сообщает самое низкое значение, полученное за предыдущий период наблюдения. Без сведений о периоде, результате проверки и независимой причине новой отправки график последней скорости скрывает именно те ветви, которые теперь определяет текст.

По данным IETF Datatracker, документ остаётся действующим Internet-Draft на стадии последующего рассмотрения профильным директором после оценки IESG. Сохраняется позиция DISCUSS; IANA указывает на необходимость проверки изменённой версии. Это не сертификат совместимости и не свидетельство о произошедшем инциденте. Проверяемая новость уже: проект точнее разделил наблюдение, принятие и право создавать дополнительный трафик.

Источники