Кратко

  • RFC 3456 провёл DHCPv4 через временную IPsec SA, оставив аренды, пулы, параметры, перенастройку и отказоустойчивость существующей системе конфигурации, а не перенося их в IKE.
  • DHCPACK и арендованный внутренний адрес были квитанциями конфигурации, а не пропусками: узел мог сам выбрать адрес, а участок от ретранслятора до сервера требовал отдельной защиты.

Два адреса фиксировали разные факты

Опубликованный в январе 2003 года RFC 3456 описывал удалённый узел с внешним интернет-адресом и внутренним адресом виртуального интерфейса. Внешний завершал IPsec-туннель на шлюзе безопасности; внутренний представлял узел корпоративным ресурсам как находящийся за шлюзом. Для маршрутизации нужны оба, но единого доказательства личности из них не получается.

Текст, карточка RFC Editor, Datatracker, история, ссылки, последующие цитирования и поиск исправлений подтверждают нормативную запись. Они не подтверждают полномочия конкретного пользователя или успех приложения.

Сначала создавалась IKE SA. Затем короткоживущая туннельная SA только для DHCP переносила DHCPDISCOVER или DHCPREQUEST. Получив адрес и параметры, узел мог создать общую VPN SA и использовать новый адрес в идентификаторе Quick Mode. Временный канал конфигурации, аренда и туннель данных были разными состояниями.

Повторное использование DHCP ограничило IKE

RFC 3457 формулировал требования удалённого доступа. RFC 2131 и параметры RFC 2132 уже давали пулы, аренды, обновление и конфигурацию; RFC 3442 позволял передавать бесклассовые маршруты. RFC 3456 не стал превращать IKE во вторую систему управления адресами, которой пришлось бы повторять аутентификацию, обновление и переключение при отказе.

Виртуальный интерфейс получал аппаратный тип 31. Идентификатор клиента должен был быть уникален в виртуальной подсети и желательно сохраняться после перезагрузки. Реестр IANA хранит это назначение. Такие свойства помогают связать транзакцию с арендой, но не доказывают человека или право.

Ретранслятор показывал шов безопасности

Шлюз обычно работал DHCP-ретранслятором. Он мог заполнить giaddr или использовать сведения из RFC 3046, включая Circuit ID виртуального порта туннеля. Прочитав yiaddr в DHCPACK, шлюз мог установить обратный маршрут.

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

Кроме того, удалённый узел мог сам назначить себе IP-адрес. Поэтому даже аутентифицированный DHCP не годился как контроль доступа. RFC 3456 требовал не основывать безопасность на выданном адресе, а применять фильтры для конкретного туннеля или селекторы Quick Mode. RFC 2401 и RFC 2409 дают контекст IPsec и IKE, но не доказывают правильную установку политики в конкретной системе.

ACK был одной квитанцией

DHCPACK подтверждал ответ конфигурации. Circuit ID обозначал предполагаемый обратный туннель. Установленный маршрут фиксировал локальное решение пересылки. Селектор связывал политику с туннелем. Наблюдаемый трафик отвечал на следующий вопрос. Подмена всей цепочки одним адресом скрывала настоящую причину доступа.

Дисциплина слоёв реальности Heng Lu помогает разделить эти квитанции. Приоритет работающего кода требует смотреть на реально установленные маршруты, селекторы и пакеты. Минимальная исходная спецификация объясняет пользу повторного использования DHCP. Это позднейшие редакционные линзы, а не свидетельство личных намерений авторов RFC.

RFC 3456 не ослаблял DHCP, отказываясь называть аренду авторизацией. Он сохранял точную компетенцию протокола: настраивать виртуальное присутствие. Что этому присутствию разрешено, по-прежнему должны были решать аутентифицированный туннель и актуальная политика шлюза.

Источники