Resumo

  • A RFC 2367 criou uma API de socket privilegiada entre a aplicação de gerenciamento de chaves e o Key Engine local; a autoridade da resposta termina nessa interface.
  • SADB_GET, SADB_DUMP e os estados LARVAL, MATURE, DYING e DEAD descrevem registros locais, não identidade remota, política aplicável ou uso por tráfego.
  • A conclusão exige unir autoridade do processo, transação PF_KEY, custódia da chave, negociação remota, SPD, processamento AH/ESP, recepção e resultado da aplicação.

O desenho conceitual de RFC 2367 separa os caminhos. O daemon usa PF_KEY para falar com o Key Engine. Usa PF_INET ou PF_INET6 para conversar com a entidade remota. O IPsec no kernel consulta a associação por outra interface interna. Uma resposta correta no primeiro caminho não observa os outros dois.

A API instala uma SA completa com SADB_ADD, ou reserva o SPI com SADB_GETSPI e completa os dados com SADB_UPDATE. SADB_GET recupera uma cópia; ACQUIRE pede tentativa de criação; EXPIRE informa prazo; DELETE e FLUSH removem estado. São atos locais precisos, não uma confirmação bilateral.

O estado pertence ao banco local

LARVAL aparece depois de GETSPI; MATURE, depois de ADD ou UPDATE; DYING e DEAD, depois dos limites soft e hard. Nada nesses nomes afirma que o par instalou a SA oposta, autenticou a identidade correta, autorizou os seletores ou processou um pacote.

O SPI é coordenada de consulta, não credencial. O algoritmo é configuração, não prova de que a chave ficou protegida nem de que a operação ocorreu. O tempo de vida é contabilidade local. O valor zero pode significar ausência de autenticação ou criptografia. Uma tabela preenchida não equivale a um serviço executado.

SADB_DUMP parece oferecer totalidade ao devolver a Key Table local e seu marcador final. A própria RFC, porém, limita a operação ao diagnóstico e proíbe dependência operacional básica. As mensagens PF_KEY também podem ser perdidas quando buffers se esgotam. A fotografia pode estar correta e ainda omitir a sequência que a produziu ou a divergência no outro lado.

O autor da escrita faz parte do resultado

Somente processos confiáveis e privilegiados deveriam abrir o socket raw. A interface manual controla amplamente as SAs locais. RFC 2367 avisa que, se um usuário sem privilégio puder criar, ler, alterar ou apagar esse estado, o sistema não pode fornecer o serviço de segurança relacionado.

Logo, a primeira evidência identifica processo, executável, geração de configuração, aprovação e privilégio efetivo. A origem e a proteção da chave são registradas sem publicar o segredo. A resposta UPDATE omite material de chave porque alguns listeners podem observar o estado sem autorização para conhecer a chave. Visibilidade e custódia não são sinônimos.

Política e pacote vêm depois

Na RFC 4301, o SPD escolhe BYPASS, DISCARD ou PROTECT. Uma entrada SAD pode sobreviver à mudança da regra SPD, e uma SA manual pode não ter regra correspondente. Existência não prova seleção.

A RFC 7296 coloca no IKEv2 a autenticação de identidade, a autorização PAD, os Traffic Selectors e as Child SAs direcionais. Perda de mensagens pode deixar os extremos temporariamente em estados diferentes. MATURE local não reconstrói essa conversa.

A RFC 4303 aplica ESP por pacote. Serviços dependem das opções da SA e da topologia; transformação de saída e verificação de entrada são eventos próprios. Depois ainda existem encaminhamento, chegada, transporte e autorização da aplicação.

O registro confiável liga: processo privilegiado; pedido e resposta PF_KEY; gerações SAD e SPD; proveniência protegida da chave; negociação remota autenticada e autorizada; correspondência do fluxo; resultado AH/ESP; observação remota; e resposta da aplicação. Uma lacuna deve continuar explícita.

Fontes