Resumo

  • RFC 5193 permite criar proteção por pacote depois de PANA por meio de uma associação segura; para proteção em camada IP, o quadro cita IKE e IPsec AH/ESP. A escolha de camada e protocolo é uma decisão de implantação, não um resultado automático da autenticação.
  • Capacidade de IPsec, configuração desejada, execução IKE, SA instalada, vínculo ao PaC/EP e tráfego efetivamente coberto são provas diferentes. Declarar a primeira não cria as demais.

Listas de capacidade são úteis para planejar redes. Elas respondem quais funções um sistema pode executar. Tornam-se perigosas quando alimentam diretamente estados de conformidade, porque o verbo muda sem que ninguém perceba: “suporta” vira “usa”; “usa” vira “protege”; “protege” vira “protege este cliente agora”.

RFC 5193 separa essas etapas ao descrever o ambiente no qual não existe canal seguro antes de PANA. A autenticação bem-sucedida permite gerar chaves; um protocolo de associação segura usa parâmetros derivados; o resultado cria proteção por pacote entre PaC e EP. Para a opção em camada IP, o documento aponta IKE e IPsec.

Nenhuma seta dessa sequência pode ser substituída pelo catálogo do produto.

A decisão de camada vem antes do recibo

O quadro deixa fora de escopo a escolha entre proteção de camada de enlace e de camada de rede. Essa escolha determina o protocolo de associação. Uma implantação pode preferir mecanismos específicos da camada de enlace ou uma solução IP com IKE e AH/ESP.

O registro de decisão deve conservar a camada escolhida, o motivo, o perfil e o EP relevante. Sem isso, a ausência de IKE pode parecer falha mesmo quando a implantação escolheu corretamente proteção inferior. O erro oposto também ocorre: a equipe vê suporte a IPsec e presume que essa foi a escolha, embora a política nunca a tenha selecionado.

Primeiro vem a obrigação declarada. Depois, o recibo do mecanismo correspondente. Não há um indicador universal que prove todas as alternativas.

IKE não é apenas um processo em execução

Um daemon disponível no equipamento prova pouco sobre o cliente. A evidência de associação precisa identificar iniciador, respondente, contexto de autenticação, parâmetros negociados, tempo, política e vínculo com o tráfego do PaC. Uma SA antiga para outro par não cobre o acesso atual.

O monitor deve distinguir tentativa, negociação, instalação e uso. Uma troca pode falhar antes de autenticar o par. Pode concluir e instalar política no lugar errado. Pode haver SA válida que não alcança o fluxo porque o caminho mudou. Pode haver contadores sem correspondência com o cliente analisado.

RFC 5193 não define esse esquema de telemetria nem exige os campos modernos citados aqui. A inferência decorre do seu limite: a associação segura produz a proteção por pacote entre entidades específicas. Para afirmar o resultado, a operação precisa preservar a identidade dessas entidades e o escopo do resultado.

O material EAP é uma entrada

No ambiente inseguro antes de PANA, a método EAP deve gerar chaves usadas mais tarde. Esse requisito impede que a autenticação seja tratada como etapa isolada. Mas também não autoriza promover a chave a SA.

Conservar o identificador da execução EAP, a expectativa de derivação, o resultado e a referência entregue ao orquestrador. O orquestrador deve produzir outro recibo quando cria a tarefa. IKE produz os seus eventos. A instalação de SA produz o resultado de estado. A observação de pacote responde se o fluxo esperado usa esse estado.

Se a sequência termina depois da chave, a investigação sabe onde parou. Se tudo vira crypto_ready=true, ninguém sabe se pronto significa “capaz”, “com chave” ou “protegendo tráfego”.

O perfil secure-before pode apagar toda a sequência

Uma implantação que acredita possuir canal seguro antes de PANA pode dispensar a associação posterior. Por isso, a primeira pergunta na auditoria de uma SA ausente não é “por que IKE falhou?”, e sim “a SA era necessária segundo qual evidência de ambiente?”.

Se required=false veio de um perfil de site ou da colocação PAA/EP, o problema antecede IPsec. O cliente pode estar num enlace aberto enquanto a política entende que a proteção já existia. Nenhuma falha IKE aparece porque o mecanismo nunca foi solicitado.

O recibo secure-before precisa vincular interface, par ou segmento, EP, mecanismo, escopo contra falsificação e escuta, fonte e validade. Somente então a ausência de SA posterior pode ser explicada como decisão, em vez de lacuna.

Colocação resolve outra interface

RFC 5193 observa que PAA e EP podem compartilhar um nó. Nesse caso, uma API basta para comunicação interna. Essa arquitetura pode facilitar a entrega de atributos e reduzir pontos de falha de controle.

Ela não coloca automaticamente IPsec entre cliente e equipamento. O PaC continua chegando por algum meio. Se esse meio não é previamente seguro, a colocação interna não protege pacotes externos. Usá-la como evidência é comparar distâncias diferentes: PAA-to-EP contra PaC-to-EP.

Da mesma forma, um resultado RADIUS ou Diameter pertence à relação com o servidor de autenticação. Ele pode carregar parâmetros relevantes, mas não observa por si só uma SA no caminho do cliente.

Capacidade precisa permanecer capacidade

Inventário, configuração, negociação, estado instalado e observação de tráfego devem usar campos e tempos distintos. O inventário muda devagar; a SA pode mudar em segundos. Se ambos alimentam a mesma coluna, o dado mais estável tende a sobreviver e mascarar a realidade transitória.

Uma interface pública pode mostrar uma síntese, desde que preserve a hierarquia: “produto compatível; política exige IPsec; tentativa IKE presente; SA ativa para o par X; fluxo Y observado”. Retirar os elos transforma conveniência visual em autoridade operacional.

A doutrina de realidade de Lu Heng não rejeita registros. Ela restringe sua força. O catálogo descreve possibilidades. A SA descreve um estado concreto. Cada qual é valioso quando não fala em nome do outro.

Sources

  1. RFC 5193 HTML
  2. RFC 5193 texto
  3. Registro RFC 5193
  4. Datatracker RFC 5193
  5. Histórico RFC 5193
  6. Referências RFC 5193
  7. Errata RFC 5193
  8. RFC 5191
  9. Registro RFC 5191
  10. RFC 4058
  11. Registro RFC 4058
  12. RFC 4016
  13. RFC 3748
  14. RFC 4306
  15. RFC 2409
  16. RFC 2865
  17. RFC 3588
  18. Heng Lu — camadas de realidade
  19. Heng Lu — especificação inicial mínima
  20. Heng Lu — primazia do código em execução