Кратко

  • Magic-Number был локально выбранной меткой состояния конца линии, а не глобальным идентификатором устройства или криптографическим доказательством.
  • Совпадение значений могло означать возврат собственного пакета или случайный одинаковый выбор. Следующие обмены должны были помочь различить эти случаи.
  • Тип пакета, история запросов и независимость выбора определяли силу вывода. Обнаружение аномалии не задавало единственную политику восстановления.

Вероятность нельзя умножать на длину журнала

В исторических спецификациях Magic-Number приведена привлекательная оценка: при равномерном выборе 32-битных чисел вероятность одного совпадения составляет примерно 2,3 × 10^-10. Несколько совпадений подряд кажутся почти невозможными.

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

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

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

Зачем линии понадобилось независимое решение

PPP связывал две стороны соединения «точка — точка». Из этого не следовало, что всё принятое пришло от ожидаемого собеседника. Линия могла возвращать переданное на вход того же устройства. В таком режиме узел фактически получал собственные сообщения.

Возвращённый кадр мог быть совершенно целым. RFC 1662, также датированный июлем 1994 года, описывал HDLC-подобное кадрирование PPP и последовательность проверки FCS. По умолчанию она занимает два октета; предусмотрен и четырёхоктетный вариант.

Проверка охватывает определённые поля кадра. Если кадр вернулся без изменения, корректный FCS не обязан стать некорректным. Это не недостаток проверки: она отвечает на вопрос о согласованности битов и контрольного значения, а не о том, кто независимо сформировал ответ.

Для обнаружения возврата требовался другой признак. Нужно было увидеть состояние, выбранное второй стороной, а не только неповреждённую копию собственных данных. Magic-Number предоставлял такую возможность в обмене управляющими пакетами LCP.

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

Поле появилось раньше завершённого объяснения

В ноябре 1989 года RFC 1134 описал PPP через три части: инкапсуляцию, расширяемый Link Control Protocol и семейство Network Control Protocols. LCP устанавливал и проверял линию, а соответствующие NCP подготавливали сетевые протоколы к работе поверх неё.

В форматах Echo и Discard уже присутствовали четыре октета Magic-Number. Если опция конфигурации не меняла поведение, поле передавалось нулевым и игнорировалось при приёме. Дальнейшее использование находилось за пределами того объяснения.

RFC 1172, выпущенный в июле 1990 года D. Perkins и R. Hobby, подробно разобрал начальные опции. В нём уже были сравнение значений, столкновение выборов, требования к источникам различия и взаимные ограничения поведения.

RFC 1331 в мае 1992 года сохранил механизм. В RFC 1661 он оказался в разделе 6.4. Поэтому неверно представлять 1994 год как внезапное изобретение самого поля. История показывает постепенное закрепление смысла и процедуры вокруг заранее предусмотренной возможности.

При этом последовательность публикаций ничего сама по себе не сообщает о сроках обновления установленного оборудования. Правило становится рабочим свойством только в реализации, которая действительно ему следует.

Сначала сравниваются запросы

Прежде чем предложить Magic-Number, реализация выбирает собственное значение. Требуется с высокой вероятностью отличаться от другого конца этой линии, а не получить номер, неповторимый во всём интернете.

При получении Configure-Request с опцией значение сравнивается с числом из последнего локально отправленного Configure-Request. Различие исключает простое возвращение собственного запроса в модели протокола. Равенство оставляет как минимум две версии.

Первая — линия возвращает отправленное. Вторая — настоящий удалённый участник случайно выбрал то же число. Первое совпадение не позволяет безусловно выбрать одну из них.

В ответ отправляется Configure-Nak с другим предлагаемым значением. Новый Configure-Request не следует немедленно добавлять вне обычного процесса. Его отправка должна вытекать из штатной обработки, например при получении Nak или срабатывании таймера Restart.

Так сохраняется общий порядок переговоров. Замена числа не превращается в произвольную последовательность пакетов, которую второй конец должен как-то угадать.

Затем сравниваются отрицательные ответы

Следующая проверка использует другой ориентир. Число в полученном Configure-Nak сравнивается с числом последнего локально отправленного Nak. Нельзя смешивать этот ряд с историей Configure-Request.

Если значения снова совпали, подозрение на возврат усиливается и требуется новый выбор. Если они различны, в предусмотренной модели появился независимый выбор другого конца. Новый Configure-Request должен нести новое значение.

Настоящая петля может возвращать и запросы, и предложения заменить число. Две независимо действующие стороны должны вскоре разойтись. Процедура поэтому не просто считает равенства: она пытается создать различие между двумя объяснениями.

Эта попытка имеет смысл только при сохранённой истории. Журнал с единственным полем «текущее магическое число» не показывает, какой Request сравнили с каким Request и какой Nak — с каким Nak. Часть доказательства исчезает ещё до анализа.

Иногда равенство обязательно

Есть тип сообщения, в котором возвращение собственного числа является нормой. Корректный Configure-Ack должен воспроизвести предложенные опции без изменения значений и порядка, сохранив соответствующий Identifier.

Значит, локальное число в Ack не следует автоматически считать признаком петли. То же число в Configure-Request имеет другую роль: оно представлено как предложение второй стороны. Код пакета меняет смысл четырёх октетов.

Аналогичное разделение есть у Echo. Echo-Reply копирует Identifier запроса, чтобы связать запрос и ответ. Но после успешного согласования Magic-Number отправитель ответа использует собственное согласованное число, а не просто возвращает число запросившей стороны.

Имя Echo не означает, что все поля должны повторяться. Соответствие ответа запросу и локальная метка его отправителя — разные функции. Если свести их к одному правилу копирования, исчезнет различие, которое механизм и пытался наблюдать.

Что предполагала таблица вероятностей

Идеализированная таблица в RFC полезна как объяснение, но не как готовая статистика эксплуатации. Последовательные вероятности можно перемножать при новых независимых выборах, а не при повторении одного и того же события.

Есть и небольшая граница самого пространства значений. Ноль нельзя предлагать как значение опции Magic-Number. Равномерный выбор только из допустимых ненулевых чисел имеет 2^32−1 вариантов, тогда как историческая оценка сформулирована через полное 32-битное пространство. Эта разница невелика по сравнению с риском одинаковой инициализации, но не позволяет выдавать модель за точную гарантию конкретного устройства.

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

Такой отказ от функции не равен отказу от правил. Он честно обозначает отсутствие предпосылки. Назвать детерминированно совпадающие результаты случайными было бы гораздо опаснее.

Отказ тоже мог показать другого участника

Реализация, которая сама предлагает Magic-Number, не вправе отвергать эту же опцию в предложении другой стороны. Взаимность нужна не только для удобства переговоров.

Если на локальное предложение приходит Configure-Reject, корректная реализация знает, что сама не сформировала бы такой отказ в ответ на отражённый собственный запрос. В модели спецификации это указывает на другого участника, а не на простое возвращение собственного поведения.

RFC 1661 предписывает продолжать так, как если бы переговоры завершились успешно, понимая, что другая сторона не будет использовать Magic-Numbers. Здесь нельзя дописать отсутствующее согласие. Оба конца не получили одинаковую возможность; отказ лишь дал полезное различие.

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

Два разных значения нуля

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

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

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

Не менее важен автомат состояний. Echo-Request и Echo-Reply передаются только в LCP Opened. На запрос в этом состоянии требуется ответ; сообщения, принятые вне него, следует молча отбросить. Discard-Request служит приёмником с последующим удалением данных и ответа не предусматривает.

Это не универсальные пробы, свободные от переговоров. Удалить ограничения состояния, но сохранить силу вывода невозможно.

Реестр задаёт тип, а не паспорт

В реестре PPP IANA Magic-Number имеет тип опции LCP 5. Вся опция занимает шесть октетов, четыре из которых отданы числу. Authentication-Protocol зарегистрирован отдельно под типом 3.

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

Для проверки личности требуется иное основание. RFC 1994, опубликованный в августе 1996 года, описывает CHAP с вызовом и вычисленным ответом, зависящим от общего секрета. Это историческое сопоставление функций, а не рекомендация применять старый алгоритм сегодня.

Видимое магическое число не доказывает знание секрета. Целый кадр не доказывает независимого отправителя. Независимый выбор не доказывает полномочий этого отправителя. Три границы нельзя заменить одной зелёной отметкой «связь исправна».

Дальнейшее действие выбиралось отдельно

RFC 1661 не устанавливает единственную процедуру восстановления. Среди примеров — трактовка состояния как Down с последующим открытием линии или наблюдение за окончанием возврата с помощью Echo в допустимом состоянии.

Нет одного обязательного количества повторов или тайм-аута для любых условий. Совместимый способ обнаружить аномалию не означает одинаковую цену разрыва соединения.

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