Кратко

  • RFC 5113 разделил discovery точки подключения, выбор identity и credential, AAA routing, payload routing и способности сети.
  • Одна identity могла успешно пройти через разные roaming paths, хотя сервис, цена и путь данных отличались.
  • Выбор происходил до аутентификации; поэтому advertisement и realm hint были подсказками, а не обязательным решением, и требовали последующего подтверждения.

Три функции оптимизации дают три результата. Клиент предпочитает сеть с ожидаемой низкой стоимостью. Домашний провайдер предпочитает прямую связь. Посещаемая сеть ставит первой связь через consortium. Обе дороги принимают одну identity.

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

Что значит «выбрать сеть»

Сначала устройство видит точки подключения и их link-layer свойства. Более высокие сведения — roaming relations, Internet restrictions, доступные services, quality и charging — могут отсутствовать.

Затем выбирается NAI и credential. Realm внутри NAI помогает направить AAA request к домашнему серверу.

AAA infrastructure выбирает proxies и отношения, по которым идёт контрольный обмен. При нескольких путях предпочтительный может быть не определён протоколом.

Payload packets могут идти через другой tunnel. Путь аутентификации не является трассой пользовательских данных.

Наконец, пользователь получает или не получает сервис, безопасность, качество и цену, ради которых всё начиналось.

Эти пять решений нельзя восстанавливать из одного флага Connected.

Identity была элементом маршрута

RFC 5113 назвал credential selection и AAA routing аспектами одной identity-selection problem. Identity выбирает не только имя субъекта, но и realm, который влияет на инфраструктуру.

Пользователь с двумя realms может получить разные наборы доступных сетей. Один realm может быть достижим прямым и посредническим путём. Успех на обоих не делает пути равными.

Если наблюдаемость хранит только результат credential, коммерческая и техническая причина маршрута исчезает. Нежелательный roaming path выглядит легитимным, потому что сервер принял пароль или сертификат.

Подсказка после ошибки

RFC 4284 позволял вернуть realm hints, если исходный realm не маршрутизировался. RFC 5113 ограничил смысл списка. Он мог не вместить всё, мог скрывать конфиденциальные relationships и не был dynamic routing protocol.

Лучше понимать его как error recovery. Core AAA proxy сообщает несколько альтернативных realms, клиент выбирает другую identity и повторяет попытку в пределах бюджета.

Если NAS формирует hints из ручной таблицы, edge state устаревает. Core proxy, который реально маршрутизирует следующий request, обеспечивает fate sharing между claim и action. Это не полнота, а более ясная ответственность.

Доверие появлялось позднее

Информация для быстрого выбора нужна до authentication. Но dynamic keys возникают после неё и не могут защитить предыдущую discovery.

Предварительные keys или signatures решают часть задачи ценой provisioning. После аутентификации channel binding или secure association может подтвердить некоторые параметры. Остальные остаются claims.

Если слабая security option рекламируется до handshake и не связывается с ним, возможен bidding down. Клиент должен иметь minimum security policy заранее и право игнорировать несовместимую advertisement.

Подсказка расширяет множество кандидатов. Она не получает право менять цель или понижать защиту.

Цена не была свойством EAP

Два AAA paths могут приводить к одному home server, но отличаться стоимостью. Payload tunnel может зависеть от выбранной roaming relationship. Нужный application service может работать только на одном пути.

Система должна записать objective: цена, безопасность, service, latency или операторская policy. Затем — выбранную identity, AAA route, payload route и результат.

Без objective нельзя отличить оптимизацию от порядка таблицы. Нельзя доказать, что operator preference была согласована с user preference. Аутентификация не даёт такого мандата.

Privacy и полнота конфликтовали

Устройство могло бы раскрыть все поддерживаемые realms, чтобы сеть выбрала достижимый. До authentication список идёт открыто и раскрывает возможные affiliations пользователя.

Минимальное раскрытие защищает privacy, но иногда требует второй попытки. Разумная схема раскрывает данные постепенно после конкретного failure, считает попытки и прекращает цикл.

С другой стороны, оператор может не хотеть раскрывать полную realm-routing table. Архитектура не должна требовать полной информации, которую обе стороны имеют основания скрывать.

Нагрузка и устаревшее состояние

Периодические EAP probes для сбора hints нагружают AAA. При перегрузке packet loss вызывает retransmission и усиливает проблему. Итоговая таблица всё равно неполна.

Ручное распространение realm tables по NAS создаёт stale state. Source route из неполной карты может требовать relationship, которой у proxy нет.

Recovery должен оставаться коротким: причина, источник hint, возраст, alternative identity, результат и maximum retries.

Лестница доказательств

  • видимая точка не доказывает service network;
  • advertisement не доказывает capability;
  • realm не доказывает текущий AAA route;
  • AAA reachability не доказывает acceptance;
  • acceptance не доказывает payload path;
  • payload не доказывает charging;
  • рабочая session не доказывает лучшую сеть.

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

Источники