Resumo

  • A RFC 2989 avaliava capacidades de propostas AAA; uma capacidade obrigatória não precisava estar ativa em toda troca.
  • Colunas separadas para NASREQ, ROAMOPS e Mobile IP preservavam contextos diferentes dentro da matriz comum.
  • Confirmação de transporte, aceitação sintática, decisão semântica, responsabilidade contábil, ação de autorização e serviço eram comprovantes distintos.

O objeto avaliado

A RFC 2989 não definiu um novo protocolo AAA. Ela consolidou requisitos produzidos por NASREQ, ROAMOPS, MOBILEIP e TIA 45.6 para avaliar candidatos. As tabelas cobriam requisitos gerais, autenticação, autorização, contabilização e necessidades próprias do Mobile IP.

As colunas preservavam a origem. M, S, O, N e B correspondiam a MUST, SHOULD, MAY, MUST NOT e SHOULD NOT. A forma compartilhada permitia comparar; as colunas impediam que necessidades diferentes fossem reescritas como uma política única.

A seção 1.1 delimitou o julgamento. Os termos normativos se referiam a capacidades. Uma proposta que descumprisse um MUST de uma capacidade implementada não era conforme. Cumprir obrigações mas não todas as recomendações gerava conformidade condicional; cumprir também os SHOULD gerava conformidade incondicional.

O veredito pertencia à proposta, não ao tráfego.

O exemplo de confidencialidade era explícito. Suportar proteção não obrigava todo pacote a usá-la. Para provar uma troca ainda eram necessários versão, perfil, configuração, chaves, par, negociação, objeto coberto e resultado de validação.

MUST não é observação

RFC 2119 torna uma obrigação forte dentro de um escopo. Não troca o sujeito da obrigação.

Escalabilidade era MUST nos três contextos. Failover aparecia com força em NASREQ e Mobile IP. IPv4 era obrigatório de modo amplo; IPv6, certificados e auditabilidade tinham pesos diferentes. Uma célula vazia não proibia uma função. Uma M não relatava que a função foi executada.

O erro costuma crescer depois: conformidade do protocolo vira garantia do produto; garantia vira configuração presumida; conexão vira serviço entregue. Cada promoção precisa de uma observação nova.

A especificação inicial mínima coordena vocabulário e comparação sem tomar para si as decisões locais futuras.

Proteção de salto e proteção de objeto

Segurança de transmissão era salto a salto. Pares AAA podiam autenticar, proteger integridade e cifrar o canal. Quando a entidade receptora processava a mensagem, essa proteção terminava. Outro salto exigia outra relação.

Confidencialidade de objeto podia reservar atributos ao destino final mesmo através de proxies. Autenticação e integridade de objeto persistiam na cadeia e impediam intermediários de alterar o conteúdo coberto.

Suportar os dois modelos não provava sua composição em produção. A função poderia estar desativada, o campo decisivo fora do envelope, a chave vencida ou a validação em fallback. Só a configuração e o traço mostravam o caminho real.

Entrega antes do significado

O transporte confiável abrangia retransmissão e troca de servidor por salto, controle de repetição pela aplicação AAA, respostas oportunas e confirmações.

A RFC 2989 descreveu uma confirmação de transporte de que a mensagem foi entregue e a separou expressamente da avaliação sintática ou semântica.

O receptor podia acusar chegada e depois rejeitar atributos. Um proxy podia completar um salto e falhar no próximo. Um secundário podia responder sem estado atualizado. Resposta pontual podia ser recusa.

Por isso, o registro operacional precisa de tentativa, salto, retransmissão, destino de failover, recibo de transporte, parse, decisão e ação do NAS. “Sucesso” sozinho apaga o ponto de falha.

A contabilidade recebia responsabilidade

Entrega garantida de contabilização usava confirmação de aplicação. Ela era enviada quando o servidor receptor aceitava responsabilidade pelos dados.

Isso era mais forte que chegada, mas não provava persistência, réplica, reconciliação, tarifação, fatura ou pagamento. A RFC separava accounting — coleta de uso — de billing, preparação de uma fatura. Reautorização dinâmica podia gerar vários registros para uma sessão.

Assumir custódia fechava uma etapa. Não assinava as seguintes.

Auditável não significa correto

Um processo auditável permitiria determinar as ações feitas em pacotes AAA no percurso entre servidor doméstico e dispositivo.

Proxy local podia aplicar política. Proxy transparente não deveria adicionar, apagar ou modificar. Proxy broker permanecia no caminho; routing broker podia devolver dados para contato direto.

O rastro provava a transformação, não sua legitimidade, a identidade correta, a execução no NAS ou o serviço ao usuário. Auditabilidade observava custódia e mudança; correção exigia outro teste.

Três funções, três recibos

Autenticação verificava identidade declarada. Autorização decidia um direito. Accounting coletava uso. A RFC ainda exigia autorização sem obrigar nova apresentação de credenciais, por identificação ou asserção. Isso permitia prova estabelecida em outro vínculo; não tornava a asserção autoautenticada.

Rejeição, regras, reautorização, reconciliação e desconexão eram capacidades de controle. Nenhuma provava efeito físico ou serviço concluído.

O limite duradouro

Capacidade não era ativação. Entrega não era interpretação. Custódia não era fatura. Auditoria não era correção. Autorização não era acesso entregue.

As camadas de realidade de Lu Heng ordenam requisito, RFC, capacidade, implementação, configuração, mensagem, intermediário, decisão, efeito e resultado. Uma camada verdadeira não testemunha pelas demais.

O código em execução deve mostrar mecanismo escolhido, fronteira que confirmou, política aplicada, estado alterado e resultado observado.

A lista avaliava o candidato. A rede ainda devia apresentar os comprovantes.

Fontes