Resumo

  • draft-smyslov-ipsecme-ikev2-psp-02 propõe autenticar os pares em uma IKE SA sem Child SA e depois transportar, em um CREATE_CHILD_SA modificado, a chave que cada receptor escolheu para o tráfego que receberá.
  • O retorno de Key Download vincula par, seletores, SPI, parâmetros PSP e material encapsulado. Ele não comprova instalação no emissor, derivação no receptor, uso do caminho correto ou aceitação de qualquer pacote.
  • PSP não oferece revogação individual de chave derivada e delega replay à camada 4. Migração de SA, dupla rotação da chave mestra, rejeição de repetição e entrega à aplicação exigem recibos próprios.

Autenticidade e novidade são perguntas diferentes

O operador vê um pacote com SPI conhecido e ICV válido. A chave foi entregue por uma sessão IKEv2 autenticada. Tudo parece formar uma única resposta: o tráfego é seguro. Mas três perguntas foram comprimidas. Quem forneceu o material? O dispositivo realmente protegeu e autenticou este pacote? Alguma camada decidiu que ele não era uma repetição?

A Arquitetura PSP responde às duas primeiras em seu próprio desenho, mas afirma que PSP não fornece replay protection. A expectativa é que TCP ou outro transporte cumpra essa função. Portanto, um ICV correto não testemunha pelo estado de replay de outra camada.

O novo draft-smyslov-ipsecme-ikev2-psp-02 trata da etapa ainda anterior: fornecer as chaves PSP por IKEv2. As versões HTML e XML não criam um veredito de replay nem um recibo de instalação. A seção de Security Considerations ainda diz “To be added”. O limite precisa ser preservado.

A chave é escolhida por quem vai receber

PSP economiza estado de recepção. Em vez de armazenar uma chave por SA, a NIC receptora mantém duas chaves mestras de 256 bits e deriva a chave da associação usando o SPI do pacote. O bit mais alto do SPI escolhe a chave mestra. Como só o receptor conhece sua chave ativa e o espaço de SPI, ele escolhe o SPI e a chave correspondente.

Depois, entrega essa chave ao outro extremo. O outro será o emissor e precisará instalá-la para produzir tráfego que o primeiro possa derivar e autenticar. Uma SA PSP é unidirecional; o sentido inverso exige outra entrega.

Essa orientação deve aparecer nos dados operacionais. “A enviou chave para B” significa que B deverá usá-la ao transmitir para A. Se um inventário grava apenas um estado por par de hosts, ele perde a direção e pode transformar uma metade saudável em saúde bilateral.

RFC 7296 normalmente deriva chaves de Child SA a partir de segredos e nonces do IKEv2. A proposta PSP precisa transportar material controlado pelo receptor e reutiliza o Key Download de RFC 9838. O mecanismo resolve a custódia durante o transporte; não observa a instalação na NIC remota.

A IKE SA childless impede uma entrega prematura

Os pares negociam Key Wrap Algorithm em IKE_SA_INIT. O responder compatível também anuncia CHILDLESS_IKEV2_SUPPORTED. RFC 6023 permite completar uma IKE SA sem criar imediatamente uma Child SA.

A SA PSP não pode nascer em IKE_AUTH, pois o iniciador enviaria sua chave de recepção a um responder ainda não autenticado. Primeiro termina a autenticação; depois vem a troca de chaves PSP.

Essa ordem fornece uma garantia real: o material sensível não viaja cedo demais. Ela não prova o estado do hardware. A identidade IKE pode pertencer a um serviço que controla várias NICs, funções virtuais ou VMs. Autenticar o serviço não confirma que o objeto correto recebeu a programação.

Negociar o Key Wrap Algorithm também não torna a IKE SA exclusiva para PSP. O texto permite criar SA ESP e PSP sob a mesma IKE SA. Capacidade, intenção, entrega e execução são quatro estados diferentes.

O vínculo do protocolo termina antes do driver

O CREATE_CHILD_SA modificado leva Protocol ID PSP e transform PSP Parameters ainda <TBA>, Traffic Selectors, SPI e um payload KD por direção. O Key Bag amarra o SPI à proposta. SA_KEY leva a chave encapsulada por SK_w, derivada de SK_d e da etiqueta “Key Wrap for PSP”.

É um bom recibo de controle. Permite reconstruir o par autenticado, o tráfego selecionado, o SPI e os parâmetros. Não define a interface entre o daemon IKE e o caminho de transmissão.

O repositório PSP, agora arquivado, mostra código de referência e descreve opções de gestão: tabela on-chip, banco de SA em RAM ou chave/referência em descritor. Cada opção pode falhar em uma fronteira diferente. Código público não comprova produto, implantação nem atomicidade.

O recibo local deve nomear NIC, função, fila ou objeto de SA, SPI, algoritmo, direção, epoch e retorno do driver, sem registrar a chave em claro. Só então o sistema sabe que a referência entregue pelo controle alcançou a superfície que executará os pacotes.

Stateless reduz armazenamento, não elimina estado

No receptor ainda existem chaves mestras, chave ativa, espaço de SPI, duração de SA e rotação. No emissor ainda há chaves por SA. Pode existir uma lista de SPI aprovados para o socket. Contadores e erros ainda precisam ser mantidos.

RFC 4301 separa gestão de SA, política e processamento. RFC 4303 não trata o estabelecimento ESP como recibo de todo pacote. PSP desloca o estado e melhora a escala; não funde controle com execução.

As metas de milhões de associações e altas taxas de atualização citadas pela arquitetura são considerações, não benchmark de uma NIC nomeada. Um plano IKE pode continuar verde quando a tabela ou a fila de comandos está saturada.

Um canário liga chave, pacote e aplicação

A especificação solicita contadores TX/RX de pacotes e bytes processados, falhas de autenticação e cifragem, erros de formato e problemas de chave mestra. Também pede flag de autenticação/decifragem e metadado SPI para o software superior.

Após o Key Download, o operador pode instalar um canário limitado. Guarda a transação IKE e o ack do dispositivo; envia um pacote PSP identificável; registra SPI, IV e incremento TX; no receptor registra epoch, derivação, ICV e incremento RX; por fim obtém o recibo da aplicação.

Cada etapa responde a uma proposição. Se TX cresce e RX não, a investigação fica no caminho, versão, encapsulamento, epoch ou ICV. Se RX autentica e a aplicação não recebe, o problema migra para lista de SPI, transporte ou aplicação. O sucesso do controle já não esconde o local da falha.

O canário não prova proteção contínua. Ele prova um ponto observável e permite estabelecer alarmes sobre os invariantes posteriores.

Rekey precisa de sobreposição e retirada observáveis

REKEY_SA pode identificar a SA PSP substituída. O padrão IKEv2 cria a nova associação, move tráfego e apaga a antiga. A resposta à criação não prova o cutover.

Um ledger de rekey registra novo SPI, instalação, primeiro pacote autenticado no novo estado, último pacote no antigo, mudança do classificador, deleção nos dois extremos e perda/reordenação. Se a chave nova existe, mas a seleção continua antiga, a negociação terminou e a migração não.

A rotação de chave mestra também não encerra imediatamente a época anterior. A chave antes ativa continua necessária para SA existentes. A arquitetura diz que uma “double rotation” é necessária para expulsá-la; conexões antigas devem fazer rekey antes da próxima rotação.

PSP não tem revogação individual de chaves derivadas. Uma marca administrativa de “revogado” só vira efeito criptográfico depois de migração, fim do uso antigo e expulsão da chave mestra correspondente.

Replay precisa de dono, estado e veredito

Se TCP for a camada responsável, o operador deve registrar qual propriedade de TCP sustenta a rejeição, em qual contexto e como foi testada. Se outro transporte for usado, precisa oferecer controle equivalente. A entrega IKEv2 não pode assinar essa evidência retroativamente.

Também é preciso separar replay de duplicidade de aplicação. Um pacote pode ser autenticado, aceito pelo transporte e ainda repetir uma operação. ICV, janela de transporte e idempotência de negócio pertencem a camadas distintas.

O objetivo não é multiplicar logs sem limite. É impedir que um identificador visível, como SPI ou IV, adquira autoridade sobre uma decisão que ele não contém.

A revisão 02 renova o prazo, não a análise de segurança

A API Datatracker registra revisão 02 em 30 de setembro de 2026, com expiração em 3 de abril de 2027. A página a classifica como Internet-Draft individual ativo; o histórico mostra três versões.

O diff de 01 para 02 altera datas, número, expiração e cabeçalhos, não o texto do protocolo. O cabeçalho diz Experimental, mas não há RFC, stream, AD responsável ou nível de padrão no Datatracker. A nova data não é adoção, revisão de segurança, interoperabilidade ou implantação.

Os valores PSP pedidos continuam <TBA>. O registro IANA IKEv2 é a fonte para atribuições efetivas. Um pedido no rascunho não cria o número.

Fontes e limites

O conjunto é formado pela revisão 02 em text/HTML/XML, Datatracker, RFC 7296, RFC 6023, RFC 9838, RFC 4301, RFC 4303, IANA e o repositório/especificação PSP. Essas fontes não provam produção, desempenho, conformidade, vulnerabilidade, incidente ou resultado de serviço.