Resumo

  • RFC 5191 prevê que a terminação remova estado PANA, encerre accounting e retire o estado por cliente dos Enforcement Points. Quando PAA e EP estão separados, a mensagem legítima de término ainda precisa convergir em cada executor.
  • Uma sessão ausente no PAA não prova uma tabela limpa no EP. O operador precisa preservar o comando, o conjunto de destinos, as confirmações e a leitura posterior dos filtros.

A falha só apareceu quando o mesmo dispositivo tentou voltar. O novo login foi autorizado, mas um EP ainda carregava a política associada à sessão anterior. A plataforma havia apagado o objeto de controle e, com ele, a ligação necessária para explicar a regra órfã.

PANA organiza uma sessão entre PaC e PAA para transportar EAP e comunicar autenticação e autorização. O EP aplica filtros por pacote. Os dois papéis podem viver no mesmo nó, mas RFC 5191 permite que sejam separados. Essa separação transforma instalação e retirada em transações distribuídas.

Uma terminação protegida prova que uma ordem válida saiu de uma das partes. Não lê, por si só, a tabela de todos os EPs depois da ordem. A diferença é pequena na sintaxe e decisiva na operação.

O encerramento tem mais de um efeito

PaC ou PAA pode encerrar antecipadamente a sessão. O modelo associa a operação à remoção do estado da sessão, parada do accounting e retirada do estado por PaC nos EPs. Se não houver mensagem explícita, lifetime ou falha de liveness pode conduzir à limpeza posterior.

Esses resultados pertencem a componentes diferentes. O PAA controla sua sessão. O sistema contábil controla seu registro. Cada EP controla a política que executa. Um endpoint de administração que responde “deleted” para o objeto PAA não possui autoridade automática sobre os outros bancos de estado.

O receipt deve guardar motivo, initiator, mensagem PANA protegida, Session ID, último Key-Id, instante, fechamento contábil, lista de EPs, versão de política removida, acknowledgement e query posterior. O conjunto de EPs não pode ser reconstruído somente depois que o objeto original desapareceu.

Uma regra allow residual prolonga acesso indevido. Uma regra deny residual bloqueia o próximo acesso legítimo. Ambas exigem reconciliação, embora seus impactos apontem em direções opostas.

A autorização também precisa chegar ao executor

O mesmo limite existe na criação. A fase final PANA pode terminar com sucesso e informar Session-Lifetime. Ainda assim, o PAA-to-EP protocol e a criação de filtros ficam fora da especificação PANA.

RFC 5191 exige que a comunicação de provisionamento entre PAA e EP tenha autenticação, integridade e proteção contra replay. Isso protege a ordem. Não constitui o ack de uma implantação concreta.

Para cada EP, registrar policy version, PaC, interface, endereço, direção do filtro, transação, confirmação, fingerprint instalado e contador inicial. Em uma topologia com vários caminhos, quorum deve ser explícito. “Todos os EPs necessários” não pode significar “qualquer EP respondeu”.

Na remoção, usar a mesma identidade de política evita deletar uma versão nova com um comando atrasado de uma sessão antiga. A versão e o vínculo causal fazem parte da segurança.

EAP Success não concede sozinho o acesso

Antes de qualquer regra existir, outra separação precisa ser mantida. RFC 5191 descreve EAP Success seguido de rejeição de autorização por AAA ou pelo PAA. Nesse caso, o último PANA-Auth traz PANA_AUTHORIZATION_REJECTED e a sessão termina.

Uma credencial pode ser válida enquanto a política nega o serviço. Um MSK pode ter sido produzido e o final pode ser protegido por AUTH; nada disso converte a decisão de autorização.

O evidence object armazena método EAP, identidade, resultado e material exportado, depois resultado de autorização, decisor, serviço, lifetime e razão. Marcar “online” ao primeiro Success cria um estado que nenhum componente declarou.

Essa distinção reduz o tempo de incidente: credenciais corretas e permissão negada pertencem à política, não à correção de senha ou certificado.

A PANA SA protege a conversa de controle

Quando a EAP gera MSK, PANA deriva PANA_AUTH_KEY e usa AUTH para proteger cabeçalho e payload, inclusive a mensagem EAP transportada. A PANA SA oferece autenticação e integridade à sinalização PaC–PAA.

Proteção de dados por pacote é outra etapa. RFC 5191 permite derivar material e usar um secure association protocol de enlace ou IPsec, mas deixa esse processo fora de escopo. Assim, um termination protegido não prova que o tráfego anterior foi cifrado, e uma PANA SA removida não prova que toda SA de dados correlata também sumiu.

Guardar PANA SA e data SA como objetos distintos permite detectar lixo dos dois lados. A primeira tem Session ID, Key-Id e lifetime. A segunda tem endpoints, selectors, algorithms, counters e instalação. A aresta de derivação é importante; a fusão seria enganosa.

Reconfiguração de endereço muda a chave da política

Após autenticação e autorização, o PaC pode precisar reconfigurar seu IP antes de trocar dados pelo EP. O PAA usa o bit IP Reconfiguration; o método de obtenção do novo endereço não faz parte de RFC 5191.

Esse passo afeta a retirada. Uma regra pode ter sido criada para o endereço pré-auth, atualizada para o pós-auth ou vinculada a uma identidade independente do endereço. Se a plataforma não conserva a transição, o comando de delete pode mirar o tuple errado.

Registrar endereço antigo, novo lease, interface, rule key, momento da mudança e política correspondente. O endereço atual não deve apagar o anterior. Na presença de relay ou múltiplos EPs, a mesma sessão pode produzir projeções diferentes que precisam ser reconciliadas individualmente.

Liveness não substitui reconciliação

PANA Ping testa se o peer responde. Uma resposta válida a uma requisição recente indica liveness do peer PANA. Ela não consulta as tabelas dos EPs e não percorre o caminho da aplicação.

Após uma terminação parcial, o PAA pode já não responder enquanto a regra residual continua instalada. Durante uma sessão, ele pode responder embora o EP tenha perdido estado. Em nenhum caso o Ping resolve a divergência.

RFC 5191 também alerta para congestionamento e falsos alarmes com keepalive periódico. Nomear a pergunta evita o excesso de autoridade: “PAA alive” é uma métrica de controle. “Policy converged” exige readback. “Service healthy” exige tráfego real.

Lifetime é limite de permissão

PANA session lifetime é limitado pelo authorization lifetime. Re-authentication pode estendê-lo. A expiração ajuda a limpar clientes desconectados, mas não é um relógio universal para todos os estados associados.

Um EP pode usar timeout diferente, uma data SA pode ter outro vencimento, o lease IP pode mudar e a aplicação pode falhar antes. Copiar Session-Lifetime para todos esses objetos cria convergência apenas no banco, não na rede.

Registrar relógios separados e alertar sobre desvio. A diferença entre expiration esperada e remoção observada é o dado necessário para encontrar stale state.

Descoberta é uma origem, não confiança

RFC 5192 define DHCP options para endereços de PAA; RFC 6345 define um relay. O resultado de descoberta diz onde tentar PANA. Não autentica antecipadamente o nó nem autoriza o cliente.

Guardar DHCP server, option, lease, interface e relay, e depois conectá-los à sessão autenticada. Uma descoberta errada, uma rejeição e uma retirada incompleta podem produzir “sem rede”, mas não compartilham causa.

Na terminação, essa procedência também ajuda a saber quais domínios de enforcement receberam a política. O caminho de descoberta não deve desaparecer quando o control object é removido.

Um ledger de sessão que sobrevive à sessão

O registro operacional começa com PaC, interface, PAA descoberto e serviço solicitado. Preserva cada PANA message, sequence, retransmission e validation. Mantém EAP e authorization como decisões diferentes.

No final da fase, armazena Result-Code, Complete, Key-Id, AUTH e lifetime. Segue a reconfiguração de endereço. Em seguida registra projeção e readback em cada EP e a data SA se houver. No encerramento, preserva a ordem e a prova de retirada.

Por fim, packet capture, remote receipt e application outcome confirmam o efeito. Esse ledger deve sobreviver ao objeto efêmero da sessão, porque é justamente depois da remoção que uma regra órfã precisa ser explicada.

O princípio é simples: não permita que o sistema que apaga a intenção apague também o mapa de suas projeções.

Fontes

  1. RFC 5191 HTML
  2. RFC 5191 texto
  3. Registro RFC 5191
  4. Datatracker RFC 5191
  5. Histórico RFC 5191
  6. Referências RFC 5191
  7. Errata RFC 5191
  8. RFC 5192
  9. Registro RFC 5192
  10. RFC 5193
  11. Registro RFC 5193
  12. RFC 4058
  13. RFC 4016
  14. RFC 3748
  15. RFC 4137
  16. RFC 5247
  17. RFC 6345
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy