Кратко

  • RFC 2356 позволял межсетевому экрану выбирать устойчивую идентичность мобильного узла по NSID/MKID, хотя его внешний care-of address менялся вместе с подключением.
  • Возможность переслать первый аутентифицированный пакет без отдельного рукопожатия не отменяла доверенные открытые компоненты, nomadic ACL, текущую привязку и правильный путь Mobile IP.

У адреса было слишком много обязанностей. Он указывал, куда доставлять пакет, и одновременно служил удобным предположением о том, кто его отправил. Mobile IP сохранил первую функцию, но вынужденно разрушил вторую.

В RFC 2002 постоянный home address обозначал узел в домашней сети, а care-of address отражал его текущее подключение. Home agent перехватывал трафик для постоянного адреса и инкапсулировал его к временному. Для маршрутизации это обеспечивало непрерывность. Для фильтра, доверявшего фиксированному источнику, законное перемещение выглядело как появление чужого устройства.

RFC 2356, опубликованный в июне 1998 года как Informational, описывал предложение G. Montenegro и V. Gupta из Sun Microsystems. Документ не был стандартом Интернета. Он рассматривал ограниченный случай: узел из защищённой частной сети напрямую подключался к публичному Интернету и получал co-located care-of address. Сценарий, где мобильный узел находился внутри другой частной сети, оставался за рамками.

Авторы сравнивали прикладное посредничество SOCKS 5 с решением на уровне IP на базе SKIP. SKIP был безсеансовым управлением ключами: сведения для аутентификации могли идти в каждом пакете. Поэтому межсетевой экран мог начать пересылку уже после проверки первого пакета, не тратя отдельный обмен на установление сеанса.

Это не означало доверия из ничего. Мобильный узел, межсетевой экран и home agent всё равно нуждались в аутентифицированных открытых компонентах Diffie-Hellman. Их следовало настроить заранее либо получить через каталог сертификатов или механизм обнаружения. Исчезал один обмен в тракте данных, а не подготовка ключей, имён и политики.

Главным приёмом стало отделение поиска ключа от адреса источника. Заголовок SKIP нёс NSID, определявший пространство имён, и MKID, выбирающий идентичность в этом пространстве. При NSID 1 в MKID можно было поместить постоянный home address, хотя снаружи пакет приходил с меняющегося care-of address. При NSID 8 идентификатор выводился из неподписанного открытого компонента Diffie-Hellman; без центра сертификации имена сторон всё равно требовалось передать защищённо.

Для такой идентичности задавалась запись ACL nomadic. Она не разрешала любой источник. Она позволяла рассматривать пакеты с разных адресов как заявления одной определённой ключевой идентичности. Затем AH — либо подходящий режим ESP — должен был подтвердить пакет, а локальная политика решить, разрешены ли назначение и сервис. Идентификация выбирала строку контроля, но не заменяла решение.

Поскольку мобильный узел начинал обмен, межсетевой экран видел текущий care-of address и создавал динамическую связь между ним, home address и ключевой идентичностью. По этой связи направлялся обратный защищённый трафик. Простая модель хранила последнее состояние: новый Registration Request заменял прежнее. Одновременные Mobile IP bindings не поддерживались, если экран не разбирал протокол регистрации глубже.

Состояние привязывало ответ к реальному маршруту. Экран, увидевший запрос и создавший binding, должен был увидеть и исходящий Registration Reply. Если периметр состоял из нескольких устройств, асимметричный путь мог вывести ответ через экран без нужной записи. Устройство, понимающее Mobile IP, могло извлечь идентичность из ответа и ослабить это ограничение, но получало больше полномочий интерпретировать протокол.

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

Home agent получал подсказки через Traversal Extension в запросах и ответах регистрации. Расширение перечисляло точки прохождения в обоих направлениях и поддерживало несколько межсетевых экранов. Некоторые значения с противоположной стороны считались именно подсказками. Наличие адреса в расширении не подтверждало, что аутентификация, инкапсуляция или пересылка действительно состоялись.

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

Поэтому слово «зашифровано» не отвечало на вопрос, кто видит и кто управляет. IP-in-IP из RFC 2003 переносил внутренний адрес через другое пространство маршрутизации. AH аутентифицировал. ESP обеспечивал конфиденциальность и мог аутентифицировать. Верно инкапсулированный пакет ещё мог быть запрещён; проверенный пакет мог пойти не тем путём; пересланный пакет мог не быть обработан приложением.

На обратном пути home agent перехватывал данные для постоянного адреса, инкапсулировал их к текущему care-of address и направлял через экран. Экран использовал динамическую привязку для защиты публичного участка. Успешный Registration Reply, существующий binding и запись о relay были отдельными фактами. Ни один не подтверждал ответ внутреннего корреспондента или результат для пользователя.

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

Историческая сила RFC 2356 — в раздельном учёте: наблюдаемый внешний адрес, заявленный home address, NSID/MKID, источник открытого компонента, результат AH/ESP, решение ACL, создание и замена binding, классификация inside/outside, направления Traversal Extension, регистрация, relay, доставка корреспонденту и итог приложения. Истинность одной строки не делает истинной следующую.