Кратко

  • 27 октября 1980 года узлы-IMP ARPANET снова и снова принимали и рассылали обновления с номерами 8, 40 и 44: шестибитное сравнение делало каждое значение более новым, чем одно из остальных.
  • В вероятной реконструкции Eric Rosen из RFC 789 цикл начался из-за аппаратно искажённой повторной передачи. Обновления заняли буферы, нарушили проверку линий и сделали саму сеть медленным каналом для аварийного исправления.

Доступ сохранялся, связи между IMP — нет

Первые симптомы не выглядели как простая ошибка маршрутизации. Некоторые пользователи всё ещё дозванивались до Terminal Interface Processor (TIP), но при попытке обратиться к хосту за другим Interface Message Processor (IMP) получали «net trouble». Уже открытые соединения обрывались. TIP мог отвечать пользователю по телефонной линии, в то время как между IMP не оставалось рабочего пути. Это различие помогло перенести поиск неисправности с точки доступа на сеть, соединявшую узлы.

Eric C. Rosen восстановил картину аварии в RFC 789 по дампам памяти нескольких IMP и другим данным. Буферы почти повсюду были заняты ожидавшими обработки обновлениями маршрутизации. По виду они исходили от IMP 50. Незадолго до сбоя этот узел неисправно работал, а во время аварии уже был отключён от сети. Его непосредственный сосед, IMP 29, тоже страдал от аппаратных проблем и терял биты. Перезапуск соседних IMP не помогал надолго: после подключения они снова получали те же обновления от соседей.

Сравнение, которое замыкалось в кольцо

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

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

В дампах очередей повторялась последовательность 8, 40, 44, затем снова 8, 40, 44. Обновления совпадали во всём, кроме номера. Каждое могло вытеснить другое как «последнее» и вновь уйти к соседним узлам. Каждый IMP применял локальное правило по инструкции. Проблема возникла потому, что одновременно появились значения, которые штатный процесс генерации должен был удерживать раздельно.

Rosen не выдавал происхождение этих трёх значений за установленный факт. Наиболее вероятной он считал такую цепочку: обновление 44 заново сформировали для повторной передачи из внутренних таблиц, а потеря битов изменила номер сначала на 40, затем на 8. Пакеты в пути имели контрольную сумму, но повторно создаваемый пакет строился по таблицам, которые не проверялись постоянно. Такая проверка расходовала бы дефицитные процессорное время или память. Rosen также рассматривал обратную возможность: исходным было 8, а биты добавились. Дампы подтверждают цикл; точный путь аппаратной ошибки остаётся выводом.

Петля маршрутизации стала нехваткой ресурсов

Обновления обрабатывались с высоким приоритетом. Пока они ходили по кругу, они занимали процессор и буферы. IMP не могли выделить буферы для сообщений HELLO и I-HEARD-YOU, с помощью которых соседние узлы проверяли состояние линий. Без этих сообщений протокол контроля соединения переставал работать, и программа объявляла линии недоступными. Поток управляющих сообщений менял топологию, которую пытались измерить другие IMP.

Поэтому диагноз Rosen не сводится к фразе «маршрутизация выбрала неверный путь». Сами маршруты и программа оставались согласованными с заданными правилами. Аппаратная неисправность создала состояние, которого обычная работа не предполагала; корректная обработка этого состояния расходовала слишком много ресурсов без достаточного ограничения. Этот случай не доказывает атаку и не описывает напрямую современную маршрутизацию Интернета. Он показывает, как повторная передача способна усилить повреждённые данные и превратить локальную неисправность в широкую потерю сервиса.

Исправление шло по повреждённой сети

Операторы передали IMP исправление, предписывавшее игнорировать обновления от IMP 50, хотя тот уже не работал. Обычно Центр управления сетью мог разослать такой патч за несколько минут. Во время аварии удалённое управление, как правило, не обслуживаемыми на месте IMP могло занимать три-четыре часа, поскольку команды шли по самой сети. Канал восстановления зависел от инфраструктуры, которую нужно было восстановить. Исправление сработало; Rosen не сообщил о последствиях, кроме самого перерыва.

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

Источники и границы доказательств

Rosen опубликовал разбор в январском выпуске 1981 года SIGSOFT Software Engineering Notes, а затем распространил его как RFC 789. Это главный источник об инциденте; в нём наблюдения отделены от предположений. Работа McQuillan, Richer и Rosen, опубликованная в мае 1980 года, описывает более ранние испытания алгоритма на действующей сети. Она не доказывает, что редкое сочетание порчи внутренней таблицы и цикла номеров уже проверяли. В короткой памятной заметке Computer History Museum значения названы «метками времени»; RFC 789 точно определяет их как шестибитные номера последовательности.

Источники: RFC 789; McQuillan, Richer и Rosen, “The New Routing Algorithm for the ARPANET”; запись Computer History Museum за 27 октября; скан статьи 1980 года на IPCOMPRO; приоритет работающего кода у Heng Lu приводится только как редакционная рамка.