Resumo

  • A IKE SA protege as trocas de controle; as Child SAs protegem tráfego AH ou ESP. Ao renovar a IKE SA, surgem novos SPIs, chaves e contadores de controle, mas a sucessora sobrevivente herda as Child SAs existentes sem alterar automaticamente suas chaves.
  • A troca de chaves de uma Child SA é uma linhagem separada. Se os dois lados iniciarem ao mesmo tempo, a SA criada pela troca que contém o menor nonce é a redundante a ser encerrada; o menor nonce não vence.
  • Uma evidência defensável combina três registros: linhagem do controle, custódia de cada Child e resultado em execução. Um único contador de rekey não comprova rotação das chaves de tráfego nem continuidade de serviço.

O estado mais perigoso não é necessariamente o que derruba o tráfego. É aquele em que os pacotes seguem normalmente, o canal antigo de controle desaparece e ninguém consegue dizer a qual IKE SA cada Child passou a pertencer. A falha só fica visível no próximo delete, teste de vivacidade ou rekey.

Esse atraso nasce de uma simplificação. Interfaces chamam o conjunto de “túnel” e tratam rekey como um verbo único. O IKEv2 mantém objetos distintos: uma associação protegida para coordenar e associações de uma direção para proteger os pacotes. Trocar o coordenador não reescreve a história criptográfica dos fluxos.

Tero Kivinen assina o RFC 7296 com Charlie Kaufman, Paul Hoffman, Yoav Nir e Pasi Eronen. A autoria fornece uma trilha verificável para discutir o desenho, não uma propriedade individual sobre o IKEv2 nem uma certificação do comportamento de qualquer implementação.

O controle pode existir sem uma Child

Na sequência habitual, IKE_AUTH conclui a autenticação da IKE SA e cria a primeira Child SA. A proximidade temporal favorece a ideia de um objeto só. O próprio RFC 7296 mantém as falhas separadas: a Child inicial pode falhar sem anular necessariamente a IKE SA; uma criação posterior que falha não deve desmontar o controle automaticamente.

O RFC 6023 torna a fronteira explícita ao permitir uma IKE SA autenticada sem Child. Ela continua capaz de verificar vivacidade, detectar NAT, receber notificações protegidas e criar uma Child mais tarde. Seus autores são Yoav Nir, Hannes Tschofenig, Hui Deng e Raj Singh, não Kivinen; o documento entra como contexto, com a atribuição preservada.

Da mesma forma, uma Child ativa não torna o pai antigo descartável por si só. O fluxo comprova que existe uma associação de dados utilizável. Não comprova que o sucessor recebeu toda a custódia nem que a próxima mensagem de manutenção usará o contexto correto.

Por isso, toda ocorrência deve começar pelo tipo da SA. Sem essa coluna, “criada”, “renovada” e “excluída” são verbos sem sujeito.

Três operações usam a mesma troca

Depois das trocas iniciais, qualquer ponta pode iniciar CREATE_CHILD_SA. O nome encobre a amplitude: a mensagem cria uma nova Child, renova uma Child existente ou renova a própria IKE SA.

Na criação de Child, a proposta inclui transformações, nonce, material opcional de troca de chaves e os seletores TSi e TSr. O respondente pode estreitar o alcance. Na renovação de Child, REKEY_SA aponta o protocolo e o SPI de entrada da SA substituída. A sucessora não deve mudar seletores ou algoritmos de modo silencioso.

Na renovação de IKE, surgem novos SPIs de iniciador e respondente e novas chaves de controle. O espaço de Message ID e a janela recomeçam no sucessor; o antecessor mantém seus próprios contadores enquanto encerra solicitações pendentes. O envelope comum não apaga a identidade do alvo.

Uma implementação também pode recusar CREATE_CHILD_SA posteriores. Capacidade e política permanecem locais. O registro IANA oferece códigos públicos e sem colisão para trocas, payloads, transformações e notificações; não prova suporte, aceitação nem conclusão.

Fazer antes de desfazer

Rekey, no RFC 7296, significa criar uma nova SA e depois excluir a antiga. Não é uma atualização in-place. O desenho make-before-break mantém uma alternativa recuperável durante a transição e explica a coexistência temporária de várias associações.

Quando a nova IKE SA vence, ela herda todas as Child SAs ligadas à original e passa a proteger as futuras mensagens sobre elas. A solicitação de autoexclusão é o último pedido enviado pela IKE SA antiga.

O recibo deve distinguir a criação do sucessor, sua aceitação, a anexação do inventário Child, o primeiro controle válido protegido por ele e a exclusão do antecessor. “Hora do rekey” não é suficiente para mostrar o intervalo entre disponibilidade e descarte seguro.

O IKEv2 não negocia uma única duração de vida para os dois lados. Cada endpoint aplica sua regra local, e a mais curta costuma disparar a troca. Temporizador, volume, atividade e decisão de implementação pertencem ao registro de quem iniciou; coordenação comum não vira comando remoto.

Herdar não altera os campos da Child

Uma Child herdada preserva o par de SPIs, os seletores, o modo, os algoritmos, a época da chave, os estados de sequência e antirreplay, os contadores e a vida útil. Mudar a IKE SA pai apenas transfere a proteção das próximas ordens de manutenção.

Logo, novos SPIs IKE comprovam uma rotação do controle. A afirmação de que todas as chaves de tráfego mudaram exige SPIs Child antigos e novos, propostas e transformações selecionadas, época nova, ativação e exclusão do par substituído.

O escopo dos padrões reforça essa divisão. O RFC 8247 orienta os algoritmos do IKEv2 e declara que não atualiza a criptografia ESP. O RFC 8221 trata ESP e AH em separado. Kivinen está entre os autores de ambos, com coautores diferentes, mas nenhum documento autoriza fundir os dois planos.

Uma migração pode modernizar o controle e deixar Child SAs anteriores vivas até o próprio vencimento. Também pode renovar uma Child mantendo a IKE SA. Um relatório de ciclo de vida precisa manter os dois relógios.

Autenticação não abre todos os seletores

A IKE SA fornece evidência da identidade do par e protege a negociação. Não dá ao par autenticado o direito de reivindicar qualquer origem ou destino. O RFC 4301 exige que a Peer Authorization Database limite os seletores que esse par pode afirmar.

O respondente pode estreitar TSi e TSr. Ao herdar a Child, o sucessor precisa conservar o par autenticado, o conjunto autorizado e a versão da política. A troca de pai não pode ampliar o alcance protegido.

“Par autenticado”, “Child instalada” e “seletores autorizados” são decisões diferentes. Misturá-las converte prova de identidade em permissão para prefixos que nunca foram avaliados.

A Minimum Initial Specification de Heng Lu ajuda a fixar a medida: o padrão compartilha apenas mensagens e identificadores necessários à interoperabilidade; a aceitação, o alcance e a duração continuam com o participante que assume a consequência local.

A prontidão aparece primeiro para o respondente

Antes de enviar a resposta de criação, o respondente deve estar pronto para receber pela nova SA. O iniciador começa a enviar depois de processar a resposta. O respondente ainda não sabe se ela chegou nem se a metade de saída remota foi instalada.

Durante uma troca de Child, ele segue transmitindo pela SA antiga até receber tráfego válido na outra metade do novo par ou uma solicitação IKE para fechar o antigo. Se o iniciador não tiver pacote de aplicação, pode mandar um pacote ESP dummy como sinal de prontidão.

O dummy comprova uma etapa de transição, não uma transação útil. A resposta positiva tampouco prova rota de retorno, antirreplay, MTU ou experiência da aplicação. O plano de execução requer observação própria.

Endpoints e seletores iguais não identificam uma Child de forma única. O IKEv2 permite SAs paralelas, inclusive para serviço diferenciado. Sem SPIs e linhagem, uma agregação pode somar antecessor, sucessor e candidato redundante.

A corrida de Child cria uma família temporária

Políticas de vida semelhantes podem levar os dois lados a renovar uma Child quase ao mesmo tempo. O jitter reduz a chance, mas não elimina a colisão. Por algum tempo existem o par antigo e dois pares novos.

Enquanto mais de uma SA for válida para entrada, pacotes de todas as candidatas devem ser aceitos. Os quatro nonces das duas trocas são comparados octeto a octeto. A regra precisa ser dita sem inversão: a SA criada pela troca que contém o nonce mais baixo é redundante e deve fechar. O menor perde.

O criador do par sobrevivente exclui o par antigo substituído. O criador do par redundante exclui essa redundância. O histórico deve guardar os três pares e os dois responsáveis por delete, mesmo depois de a tela mostrar apenas o vencedor.

Com perda de pacotes, uma solicitação atrasada pode mirar uma SA já substituída. CHILD_SA_NOT_FOUND pode ser um resultado não fatal da corrida. O SPI alvo, a ordem de chegada e a linhagem determinam a interpretação.

A corrida de IKE decide também a custódia

Os dois endpoints podem renovar a IKE SA simultaneamente. O estado temporário contém o pai antigo e dois candidatos. O novo IKE associado ao menor nonce é encerrado; o sobrevivente deve herdar todas as Child SAs.

Concordar com o nonce vencedor não basta. Antes de excluir o controle anterior, ambos os lados precisam concordar com o sucessor e com o inventário integral de Children. Uma ausência nesse inventário é falha de custódia, mesmo que a derivação de chaves IKE tenha sido correta.

Numa corrida assimétrica, a solicitação pode chegar quando a outra ponta já fecha a IKE antiga. O RFC 7296 usa TEMPORARY_FAILURE, e o par pode abandonar sua tentativa ao receber o delete antigo. A notificação temporária pode registrar uma convergência ordenada, não uma indisponibilidade.

O recibo precisa juntar as duas trocas, o conjunto de nonces, o candidato redundante, o sucessor, a exclusão antiga e a lista herdada vista por cada lado. Só então o controle e a família contam a mesma história.

Extensões posteriores aumentam a necessidade de precisão

O RFC 9370 acrescenta múltiplas trocas de chaves e IKE_FOLLOWUP_KE na criação ou renovação de IKE e Child. Ele mantém a obrigação de resolver a colisão simultânea antes de seguir com as trocas adicionais.

O RFC 9370 tem outro grupo de sete autores e não é de Kivinen. Sua relevância aqui é estrutural: uma cadeia negociada mais longa torna o rótulo “sucesso” ainda menos informativo. É preciso registrar extensão, sequência concluída, candidato vencedor e tipo de SA que recebeu as chaves.

Um código IANA não mede adoção, conformidade de produto ou entrega útil. Registro, implementação, negociação e execução são degraus de evidência independentes.

Preservar os limites de autoria segue a mesma lógica. RFC 6023 e RFC 9370 iluminam a arquitetura, mas não podem ser absorvidos pela biografia de uma pessoa.

A contribuição de Kivinen tem limites verificáveis

Consultado em 31 de agosto de 2026, o perfil IETF de Tero Kivinen lista funções de chair do IPsecme, membro do Tools Team, reviewer e secretário do Security Area Directorate. Registra 16 RFCs e nenhum Internet-Draft ativo. É um retrato datado, não autoridade sobre instalações.

O RFC 7296 tem cinco autores. RFC 8247 e RFC 8221 têm seus respectivos grupos; RFC 6023 e RFC 9370 pertencem a outros. A atribuição correta reconhece trabalho sem inventar soberania técnica.

Pela lente do problema de agência de Heng Lu, autores e instituição fornecem um instrumento de coordenação limitado. Os operadores continuam responsáveis por tempos de vida, autorização, algoritmos, implantação e conclusões de incidente.

Este texto também permanece dentro da evidência. Não afirma prevalência de suporte, conformidade universal de VPNs nem configuração atual de qualquer rede ou fabricante.

Três recibos, três perguntas

O recibo de controle guarda identidade do par, SPIs IKE antigos e novos, algoritmos, nonces, Message IDs, gatilho local, candidatos, decisão do sucessor, primeiro controle protegido e exclusão antiga. Responde quem assumiu o comando.

O recibo de custódia enumera cada SPI Child de entrada e saída, seletores, decisão PAD/SPD, modo, algoritmo, época de chave, vida local, pai antigo e novo, herança ou substituição e estado de delete. Responde o que mudou de pai e o que mudou de chave.

O recibo de execução registra aceitação de pacotes em pares antigos e novos, sequência, antirreplay, descarte, dummy, primeiro tráfego útil bidirecional e continuidade da aplicação. Responde o que funcionou.

A Running-Code Primacy de Heng Lu aparece na junção: a especificação torna a sucessão testável, mas estados e pacotes mostram o resultado. Uma IKE nova não prova rotação Child; uma Child viva não prova que a manutenção futura tem o pai certo.

Fontes