Resumo

  • O RFC 5113 decompôs a escolha em ponto de conexão, identidade e credencial, rota AAA, rota dos dados e capacidades da rede.
  • A informação necessária à decisão deveria chegar antes da autenticação para evitar atraso, mas nesse momento não podia usar as chaves dinâmicas derivadas da própria autenticação.
  • Publicidade de rede e realm hints eram pistas. O cliente precisava confirmar o que fosse confirmável e manter política própria para rejeitar rebaixamento ou serviço incompatível.

O primeiro login termina sem erro. O aplicativo abre e não encontra o serviço que justificou a conexão. O dispositivo abandona a rede, escolhe outro ponto, troca o NAI e repete EAP. O segundo login também termina sem erro.

Qual dos dois foi sucesso? Para o servidor de autenticação, ambos. Para o usuário, só o segundo. Para a gestão, a resposta depende de ter preservado o objetivo original.

A escolha já tinha virado estado

Quando a autenticação começa, o dispositivo normalmente já selecionou a rede, o ponto de conexão e o NAI. Se o processo revelar uma informação que muda a decisão, não basta alterar um campo. Pode ser necessário desconectar, associar novamente, escolher outra identidade e repetir todo o fluxo.

Esse custo explica por que capacidades, serviço e política de cobrança são desejados antes. Também explica o risco: a informação prévia está no lado menos confiável da fronteira.

Um painel que mede apenas tempo até autenticar pode premiar a primeira rota que aceita qualquer credencial. O usuário paga o segundo começo.

Cinco recibos

Descoberta de ponto responde onde há uma oportunidade de conexão. Não responde qual rede de serviço existe por trás dela.

Seleção de identidade decide NAI e credencial. O realm influencia a direção da conversa AAA.

Roteamento AAA leva a solicitação até um servidor de origem por uma ou mais relações de roaming.

Roteamento de payload define o túnel e a saída usados depois. Ele pode não coincidir com o caminho de autenticação.

Descoberta de capacidade trata do que o usuário realmente quer: serviço, acesso à Internet, segurança, qualidade, emergência e cobrança.

O estado “conectado” não cria os recibos ausentes. Ele precisa ser calculado a partir deles.

Credencial e rota formavam o mesmo problema

Escolher uma identidade não é só escolher uma conta. O realm do NAI ajuda a infraestrutura a localizar o home AAA server. Um usuário com identidades em dois realms pode alcançar conjuntos diferentes de redes. Um único realm pode ter mais de um caminho comercial.

Duas rotas podem aceitar a mesma credencial e cobrar de modo diferente. Uma pode oferecer o serviço pedido e outra não. O RFC 5113 concluiu que credential selection e AAA routing são aspectos da mesma seleção de identidade.

Separá-los em métricas independentes permite uma narrativa falsa: “a credencial estava correta, então a rede foi escolhida corretamente”. A credencial pode estar correta e a rota ser indesejada.

Realm hint como recuperação limitada

Quando a primeira rota falha, RFC 4284 permite que um proxy retorne realm hints. A lista pode não caber inteira, pode esconder relações confidenciais e não é um protocolo dinâmico.

O uso mais sólido é informar que o roteamento falhou e sugerir uma identidade alternativa. O proxy central que encaminhará a nova solicitação deve, quando possível, originar a pista. Assim, quem anuncia o caminho também tenta usá-lo.

Se o NAS copiar uma tabela manual, a publicidade pode ficar antiga. Uma rota retirada continua aparecendo; uma rota nova não aparece. A recuperação vira causa de novas falhas.

Confiança depois da decisão

Chaves criadas na autenticação não protegem a descoberta que veio antes. Assinaturas ou chaves pré-instaladas podem proteger anúncios, mas trazem distribuição, atualização e revogação.

Depois, channel binding pode confirmar nome ou parâmetro específico. Secure association pode confirmar outro. O sistema não deve extrapolar: o que não foi vinculado continua provisório.

Esse limite evita bidding down. Uma rede pode anunciar uma opção fraca. Se o cliente aceita antes de aplicar sua política mínima, a confirmação tardia não repara a escolha. A publicidade deve ser hint, e a política deve manter poder de veto.

Privacidade também escolhe o protocolo

Enviar todos os realms que o dispositivo suporta ajudaria o autenticador. Antes da autenticação, a lista exporia em texto claro possíveis vínculos institucionais do usuário.

A alternativa é divulgação progressiva: tentativa mínima, hint após falha, identidade alternativa dentro de um orçamento. O preço é mais latência em alguns casos; o benefício é não publicar todo o portfólio de credenciais.

O trade-off precisa aparecer na política. “Descoberta automática” não é uma resposta quando não declara o quanto revela.

Serviço, preço e payload

Mesmo após o AAA aceitar a identidade, o payload pode seguir outro túnel. A política de preço ou o catálogo de serviços pode depender da relação de roaming escolhida. Uma aplicação pode descobrir a divergência apenas quando tenta operar.

Três objetivos podem entrar em conflito: preferência do usuário, preferência comercial do operador e requisito técnico da aplicação. Uma ordenação silenciosa de rotas não é consentimento para resolver esse conflito.

Registre qual objetivo dominou. Se a escolha foi segurança, guarde a regra correspondente. Se foi preço, confirme a cobrança. Se foi serviço, teste disponibilidade. Sem objetivo, não há como avaliar a qualidade da seleção.

Escala e negação de serviço

Sondar AAA periodicamente com mensagens de identidade para colher hints gera carga e pode amplificar uma sobrecarga por retransmissão. O resultado ainda é uma visão parcial.

Distribuir tabelas grandes expõe relações e cria estado obsoleto. Source routing baseado em informação incompleta pode pedir a um proxy uma relação que ele não possui.

O mecanismo de recuperação deve ser curto, mensurável e encerrável: falha, origem da pista, idade, nova identidade, resultado e limite de tentativas.

Escada de evidência

  • ponto visível não prova rede útil;
  • rede anunciada não prova serviço;
  • realm anunciado não prova rota AAA atual;
  • AAA alcançável não prova autenticação;
  • autenticação não prova payload;
  • payload não prova preço;
  • sessão funcional não prova melhor escolha.

O RFC 5113 preservou essas separações para que um êxito estreito não assinasse o resultado inteiro.

Fontes