Кратко

  • По RFC 6345 ретранслятор PRE может не хранить состояние отдельных клиентов. При этом агент аутентификации PAA сохраняет адрес и порт PRE в сеансе, чтобы отправить ответ обратно.
  • Защита аутентификации и доступность обмена — разные свойства. Отсутствие состояния на одном узле не устраняет обработку пакетов, настройку допустимых партнеров и остаточные риски.
  • Оценивать следует не только простоту устройства, но и распределение работы: кто хранит нужные сведения, меняет конфигурацию и получает полномочия восстановить связь.

Простое устройство, незавершенная смета

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

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

RFC 6345 вводит посредника для ситуации, когда клиент PANA, или PaC, не может связаться с агентом PAA посредством обычной IP-маршрутизации. В приведенном примере присоединяющийся узел IPv6 пользуется адресом, действующим в пределах канала, а родительский узел передает его сообщения агенту на пограничном маршрутизаторе. Это пример из спецификации, а не измерение распространенности архитектуры.

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

Официальная карточка RFC 6345 указывает август 2011 года и статус Proposed Standard. Эти сведения ограничивают выводы. Перед нами документ об устройстве механизма, а не современный тест продукта и не отчет о его рыночной доле. Источники позволяют разобрать обязанности участников, но не посчитать денежную экономию или обещать показатели надежности конкретной установки.

Кто помнит дорогу назад

PRE помещает полученную PANA-посылку в сообщение PRY. В атрибуте Relayed-Message передается внутренняя PANA-посылка без исходных заголовков IP и UDP. Адрес клиента и его UDP-порт находятся отдельно, в PaC-Information. Такая упаковка позволяет переносить обмен, не заставляя клиента разбираться в устройстве промежуточного участка.

Агенту нужны сведения не только о клиенте. При различении начинающих обмен клиентов PAA учитывает координаты и клиента, и ретранслятора. В сеансе он также сохраняет IP-адрес и UDP-порт PRE как дополнительные атрибуты. Именно они позволяют направить обратное сообщение к нужному посреднику.

Поэтому отсутствие состояния у PRE нужно читать с дополнением: состояния на каждого PaC. Это не отсутствие конфигурации вообще. Это не нулевая работа с каждым пакетом. И это не доказательство того, что все расходы просто переехали на центральный узел. У PRE остается обработка, у PAA может увеличиться потребность в хранении, а у оператора — задачи по настройке и поддержанию границ взаимодействия.

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

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

Есть и пределы гибкости. PRE выбирает PAA из настроенных адресов; динамическое обнаружение PAA самим ретранслятором в RFC 6345 не рассматривается. Предполагается не более одного PRE, а вложенные сообщения ретрансляции находятся вне области спецификации. Слово «без состояния» не добавляет к этому автоматическое обнаружение, произвольную цепочку посредников или гарантию переключения при отказе.

Ошибка в ссылке на поле — не новая модель доверия

Подтвержденное техническое исправление 2996 уточняет, откуда PRE берет UDP-порт назначения для ответа клиенту. Правильный источник — PaC-Information, а не Relayed-Message, как было написано первоначально. Исправление зарегистрировали 13 октября 2011 года и подтвердили 7 сентября 2012 года.

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

Из наличия исправления нельзя заключить, что конкретный поставщик выпустил ошибочный продукт или что где-то произошел сбой. Таких свидетельств в исследовании нет. Зато можно сформулировать проверяемый вопрос при приемке: соответствует ли объяснение обратного пути исправленному тексту, а не только названию RFC в списке поддерживаемых стандартов?

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

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

Повторяется внутренняя посылка, а не внешний конверт

У PRY внешние поля идентификатора сеанса и номера последовательности равны нулю. PRE и PAA не выполняют повторную передачу самого PRY. Это еще один способ ограничить обязанности промежуточного механизма.

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

Базовый RFC 5191 относит проверки сеанса, внутренних сообщений и повторные передачи к конечным сторонам. Он различает клиента, PAA, при необходимости сервер AAA и точку применения правил доступа. Если агент и точка применения правил разделены, обмен данными для настройки последней должен иметь аутентификацию, контроль целостности и защиту от воспроизведения ранее переданных сообщений.

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

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

Недоступность не равна краже учетных данных

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

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

Квалификация о методе EAP обязательна. По RFC 5191 ассоциация безопасности PANA SA появляется при успешном EAP с получением MSK. Если MSK нет, такая ассоциация не создается. Нельзя обещать одинаковую защиту при любом методе, а нормативный разбор угроз нельзя выдавать за испытание каждого возможного исполнения.

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

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

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

Необязательное шифрование не делает остаточный риск необязательным

Криптографическая защита участка PRE–PAA в RFC 6345 не обязательна на уровне протокола. Одновременно документ требует учитывать оставшиеся риски, используя физическую либо криптографическую защиту и ограничения на допустимых партнеров. Возможность выбрать средство не означает, что можно не решать задачу.

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

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

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

Отдельная граница проведена в обнаружении PAA. RFC 5192 описывает DHCP-опции с упорядоченным списком адресов агентов; клиент обязан пробовать их в указанном порядке. Эти опции не должны служить переговорами о том, нужна ли аутентификация PANA вообще. Отсутствующая или поддельная опция не становится разрешением отказаться от аутентификации либо ослабить ее.

Адрес, по которому искать агента, и полномочие менять условие допуска — не одно и то же. Это полезное напоминание для эксплуатации: сведения о маршруте к услуге нельзя молча превращать в источник политики доступа.

Разные адреса требуют общего понимания

Если привязка канала учитывает IP-адрес PAA, возникает еще одна обязанность. Клиент видит адрес PRE, тогда как сервер аутентификации может видеть адрес действительного PAA. Это расхождение должно быть осмысленно обработано.

RFC 6345 отмечает, что похожая ситуация возможна и у PAA с несколькими сетевыми подключениями без ретранслятора. Поэтому одно несовпадение не доказывает компрометацию. Но и безусловно игнорировать все различия нельзя. Требуется понимать, что означает адрес в наблюдении каждой стороны и как он участвует в проверке.

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

Позднейший RFC 7733, опубликованный в феврале 2016 года, включает PANA и EAP-TLS в профиль сетей RPL для жилых домов и зданий. Родительский узел выполняет функцию PRE, кроме случая, когда он сам является сервером аутентификации.

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