Кратко

  • Расширение FORCERENEW 2001 года позволяло серверу побудить настроенного клиента к обычному обновлению аренды. Уведомление запускало запрос, но не заменяло последующий обмен и не означало, что новый адрес уже принят.
  • В 2012 году появился согласуемый механизм nonce: секрет передавался в ответе DHCPACK и использовался для проверки будущих уведомлений. Отдельная предварительная раздача этого секрета больше не требовалась.
  • Защита была рассчитана на внешнего противника, не наблюдающего обычные обмены. Она не создавала независимого доверия к первой передаче секрета и не гарантировала безопасность либо успешное завершение перенастройки.

Возможность нужно было объявить заранее

В процедуре из RFC 6704, опубликованного в августе 2012 года, клиент сообщает о поддержке механизма nonce еще в DISCOVER и REQUEST. Сервер обозначает свое предпочтение в OFFER. Лишь затем появляется секрет, с помощью которого будут проверяться будущие FORCERENEW.

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

Если в начальном OFFER механизм объявлен, а в следующем ACK нет ожидаемой действительной опции аутентификации, клиент должен отбросить ответ и вернуться к началу. Это проверка последовательности договоренности. Она не удостоверяет первого ответившего сервера через какой-то внешний источник доверия.

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

Что именно сервер получил в 2001 году

RFC 3203, вышедший в декабре 2001 года, описывал короткое уведомление, отправляемое клиенту посредством unicast. Получив его, клиент переходил к обновлению и посылал обычный DHCPREQUEST. Авторы специально отмечали, что новые состояния клиента не нужны: расширение использует существующую процедуру.

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

Раннее обновление само по себе не было изобретением этого документа. RFC 2131 от марта 1997 года уже разрешал клиенту пробовать обновление до T1. Новизна заключалась в том, что повод мог исходить от сервера, а не только от таймера или решения самого клиента.

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

Если требовался новый адрес, RFC 3203 предусматривал дальнейшие шаги: сервер отвечает на запрос сообщением DHCPNAK, клиент возвращается к инициализации и передает DHCPDISCOVER, после чего сервер может предложить адрес через DHCPOFFER. Первое уведомление не является ни этим отказом, ни предложением, ни подтверждением успешной выдачи. Обычное обновление может сохранить прежний адрес.

Ручная настройка оставалась ручной

Особенно показателен клиент, чей адрес задан вручную. Он может пользоваться DHCPINFORM только ради других местных параметров. Согласно RFC 3203, на FORCERENEW такой клиент должен ответить новым INFORM. Расширение не должно перезаписывать ручные значения.

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

Для идентификации сообщения использовали прежний формат. Опция 53 из RFC 2132 обозначает тип DHCP-сообщения; расширение добавило в нее значение 9. Это не порт и не номер опции аутентификации. Значение сообщает получателю, какую процедуру ему предлагают начать, но не доказывает, что она уже выполнена.

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

Почему время запроса требовало защиты

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

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

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

Авторы RFC 6704 в 2012 году писали, что прежнее требование было строже необходимого для рассматриваемого случая и ограничивало внедрение FORCERENEW. Это их оценка того времени, а не современная статистика поддержки. Они предложили уменьшить цену подготовки, сузив задачу защиты до конкретного вида вмешательства.

Секрет из уже начавшегося обмена

Историческим образцом стал Reconfigure Key из DHCPv6, описанный в RFC 3315 в июле 2003 года. Заимствовалась эта идея, а не весь протокол IPv6. Документ впоследствии был заменен; здесь он нужен как источник происхождения механизма, не как полное действующее руководство по DHCPv6.

Nonce-режим применяется, только если стороны не используют прежнюю DHCP-аутентификацию и согласовали новый механизм. Объявление поддержки со стороны клиента не является кодом проверки. Сам клиент не должен отправлять DHCP-сообщения с опцией аутентификации, в которой выбран этот nonce-протокол.

Когда необходимо установить значение, сервер генерирует криптографически стойкую случайную или псевдослучайную последовательность длиной 128 бит. Она передается клиенту в ACK в ходе REQUEST–ACK. Обе стороны сохраняют ее. Для позднейшего FORCERENEW сервер вычисляет HMAC, используя сохраненную последовательность как ключ; повторно раскрывать ее в уведомлении не требуется.

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

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

Nonce не означал однократное использование

Значение может сохраняться для нескольких уведомлений. Название не следует читать как обещание расходовать секрет после каждого вызова. Нормативный текст RFC 6704 указывает, что ACK обычного обновления не должен повторять nonce, если новый не был создан. Схема с новым значением после одного обновления не вводит обязательной ротации при каждом таком обмене.

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

Исторический алгоритм — HMAC-MD5. Это код аутентификации, а не шифрование канала; его описание не является современной рекомендацией по выбору криптографии. Отдельно учитывается повтор старых сообщений. Проверенное исправление 3474 в 2013 году уточнило, что счетчик должен строго возрастать. Равное предыдущему значение не удовлетворяет этому условию.

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

За пределами видимости противника

В центре модели RFC 6704 находится внешний противник, который не наблюдает обычные обмены клиента и сервера. Не имея nonce, он не может создать подходящее уведомление, чтобы заставить клиента обновиться в выбранный им момент. Защита использует именно эту ограниченность наблюдения.

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

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

Согласованные номера тоже не расширяют модель доверия. Реестр параметров BOOTP и DHCP IANA отдельно фиксирует тип сообщения 9, опцию аутентификации 90 и опцию возможности 145. Реестр обеспечивает одинаковое прочтение полей. Он не подтверждает наличие реализации на каждом устройстве, состоявшееся согласование или удачную смену адреса.

Вызов может остаться без ответа

Даже допустимое по формату уведомление не дает серверу мгновенной обратной связи о результате. RFC 3203 предписывает ограниченные повторные попытки с экспоненциальной задержкой, если не приходит ожидаемый DHCPREQUEST. Начальная задержка выбирается по условиям сети. Полученный посредством multicast FORCERENEW клиент должен молча отбросить; штатная доставка — unicast.

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

В этой последовательности и заключается исторический смысл расширения. Сначала стороны понимают общий язык; затем, для nonce-режима, договариваются о механизме и сохраняют значение; позже сервер вызывает клиента; тот делает обычный запрос. Реальный результат находится в конце, а не в имени первой команды. FORCERENEW дал управлению больше инициативы, не отменив расстояние между инициативой и исполнением.