Кратко

  • В эксперименте TED более 34 тысяч пакетов пришли на контролируемый сервер за 250 миллисекунд, хотя отправка заняла 4,2 секунды.
  • Сканирование нашло 1 909 440 узлов, прошедших проверки авторов в период с июня 2025-го по январь 2026-го; это результат измерения, а не сегодняшняя опись доступных ретрансляторов.

Сеть может превратить задержку в расписание.

В работе USENIX Security 2026 Le Gai, Zedong Jia, Lin He, Daguo Cheng, Chentian Wei и Ying Liu описали TED: туннели и цепочки расширений IPv6 создают разные пути и задержки, после чего отправка распределяется так, чтобы пакеты пришли почти одновременно.

В одном испытании команда равномерно отправила 35 029 пакетов за 4,2 секунды — около 8 340 пакетов в секунду. Более 34 тысяч оказались у контролируемого получателя за четверть секунды. Число 180× сопоставляет пиковую скорость приёма в 20-миллисекундном окне со средней скоростью отправки. Это концентрация во времени, не увеличение объёма на 180 раз.

В центре схемы — узел туннеля. Он принимает внешнюю IP-оболочку, направляет её и раскрывает внутренний пакет.

Если вход не проверяет партнёра и внутренний адрес источника, а устройство пересылает вложенные заголовки без нужной проверки, маршрут начинает предоставлять не только транспорт, но и предсказуемую задержку. Поэтому вопрос для оператора звучит не абстрактно: кто имеет право войти, что можно инкапсулировать и сколько уровней устройство пропускает?

С июня 2025-го по январь 2026-го исследователи провели 44 сканирования через случайные интервалы.

Каждое охватывало около 3,7 млрд адресов IPv4 и 20 млн адресов IPv6 из списка Hitlist. Итог — 1 909 440 узлов шести типов туннелей. Для проверки импульса использовались шесть контролируемых серверов с двойным стеком в Китае, Японии, Германии и США; авторы не направляли испытание на действующие сервисы.

Нормативное пояснение в статье требует точности. Авторы обобщают RFC 8200 как правило, по которому расширения обрабатывает только конечный получатель. Для опций Hop-by-Hop RFC 8200 допускает обработку узлами на пути при явной настройке, а RFC 9673 обновляет процедуры. Практический риск TED связан с тем, что разрешает туннельный вход и что проверяет реализация после декапсуляции.

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

Измерения заканчиваются январём 2026 года.

Повторная проверка после внедрения мер покажет, сколько найденных тогда узлов сохраняют нужные свойства; такого постконтрольного результата в статье пока нет.

Источники: Страница доклада USENIX · Статья USENIX Security 2026 · RFC 8200 · RFC 9673 · RFC 2473