Resumo

  • A RFC 5202 determinou que sistemas intermediários pudessem inspecionar ESP_INFO durante o rekey; a RFC 7402 preservou a regra. HMAC e assinatura dão integridade, não sigilo.
  • Governar essa escolha exige inventário dos consumidores, finalidade, campos, exportações, expiração e evidência de exclusão, separado da prova de que a nova SA transportou dados.

A política cabeçalho por cabeçalho

Uma declaração ampla como “tráfego cifrado” perde precisão antes mesmo de chegar ao HIP. No ESP da RFC 4303, o SPI e o Sequence Number ficam antes do payload cifrado. Eles participam da proteção de integridade, porém não são cifrados. O receptor precisa do SPI para localizar a Security Association certa.

O HIP usa esse número como representação compacta de um par de HITs. Intermediários podem empregá-lo em mapeamento de endereços. A semântica não é universal: destino e SPI identificam o contexto receptor naquele momento. O mesmo valor pode existir em hosts diferentes e mudar de sentido com o tempo.

Portanto, SPI não é chave criptográfica nem identidade civil. Também não é ruído sem valor. É uma coordenada operacional com escopo e duração.

A transparência foi requisito

No rekey, ESP_INFO carrega SPI antigo, SPI novo e índice do material de chaves. O UPDATE de início inclui SEQ, Diffie–Hellman opcional, HMAC e HIP signature. A resposta combina seus próprios parâmetros com ACK.

A RFC 5202 explica que sistemas intermediários dependentes do SPI precisam inspecionar os pacotes de rekey. O pacote é assinado para benefício deles. Como precisam do SPI novo, o conteúdo não pode ser cifrado. A sucessora Standards Track, RFC 7402, repete a justificativa.

Esse desenho faz uma troca explícita. A assinatura torna a transição verificável por quem possui o contexto; a legibilidade mantém a função do intermediário. Nenhuma das duas propriedades oferece confidencialidade ao campo.

Um painel deveria registrar UPDATE autenticado e metadado legível como resultados simultâneos. Transformar o primeiro em negação do segundo é trocar realidade por símbolo.

Correlação com limites

O cabeçalho HIP mostra HITs de origem e destino, enquanto ESP_INFO liga o seletor antigo ao novo. Endereços e relógio do sensor completam um evento temporal. A RFC 9063 observa que firewalls e NATs conscientes de HIP podem assistir passivamente ao caminho e manter soft state entre controle e dados.

Na linguagem da RFC 6973, análise de tráfego usa presença, direção, horário, tamanho, composição ou frequência para inferir informação mesmo quando os fluxos são cifrados. Um rekey visível oferece uma marca organizada para essa inferência.

Ainda assim, não se pode alegar que qualquer observador descobre a pessoa, empresa ou aplicação. Isso depende de contexto adicional. O artigo sustenta apenas que a mudança de relacionamento fica observável e pode ser ligada a outros registros.

O tempo de vida real está nas réplicas

As RFCs recomendam SPI aleatório, valor diferente em novo exchange com o mesmo peer e mudança obrigatória no rekey. Isso reduz reutilização e replay. Não apaga o vínculo já capturado entre dois valores.

O gateway pode descartar sua tabela no timeout, mas um SIEM, um coletor, um chamado ou um backup pode manter a relação. A recomendação da RFC 9063 de rotacionar HIs não publicados para perturbar linkability também não remove cópias antigas.

Três relógios precisam ser visíveis: vida do SPI, vida da identidade e vida do registro. Se apenas o primeiro for auditado, a organização confunde protocolo efêmero com memória institucional efêmera.

O recibo correto

Para cada consumidor de ESP_INFO, registrar ponto de observação, finalidade, campos lidos, regra, função humana autorizada, destino de exportação, timeout e método de exclusão. O evento deve conter direção, locators, referência protegida aos HITs, SPIs anterior e novo, SEQ/ACK, algoritmo e resultado de HMAC/assinatura.

Depois vêm recibos que o intermediário não pode inventar: instalação da nova SA nos endpoints, primeiro pacote autenticado no novo SPI, último pacote no antigo e remoção dos estados. Ler um UPDATE não comprova cutover.

A exclusão também é uma ação observável. Confirmar somente a ausência na tabela do gateway deixa de fora pcap, flow record, ticket e processador externo. A cadeia deve provar o fim em cada repositório declarado.

Uma cláusula que sobreviveu ao experimento

A RFC 5202 foi publicada em 2008 como Experimental e hoje está obsoleta. Seu erratum retido corrige uma palavra sobre parâmetros de transform, sem afetar a tese. A RFC 7402 a substituiu em 2015 para HIPv2 no Standards Track.

O fato de a regra reaparecer na sucessora impede tratá-la como descuido antigo. A RFC 6538 e a arquitetura RFC 9063 mostram a tensão legítima entre privacidade de identidade e participação de middleboxes. O erro não é haver uma fronteira; é escondê-la sob uma promessa absoluta.

Escolha de liderança

Separar em contratos e controles: confidencialidade do payload, autenticidade do controle, visibilidade do metadado, eficácia da nova SA e término da retenção. Cada item deve apontar para um recibo verificável.

A especificação comum só deve expor o mínimo necessário à interoperabilidade. Uso analítico, união entre sensores e retenção longa exigem decisão local explícita. Código em execução mostra o que o sistema revela; governança responsável limita quem transforma essa revelação em memória.

Fontes

  1. RFC 5202 HTML
  2. RFC 5202 em texto
  3. Informações da RFC 5202
  4. Datatracker IETF: RFC 5202
  5. Histórico da RFC 5202
  6. Referências da RFC 5202
  7. Errata da RFC 5202
  8. RFC 7402 HTML
  9. RFC 7402 em texto
  10. Informações da RFC 7402
  11. Datatracker IETF: RFC 7402
  12. Histórico da RFC 7402
  13. Referências da RFC 7402
  14. Errata da RFC 7402
  15. RFC 4303 — ESP
  16. RFC 4301 — arquitetura IPsec
  17. RFC 9063 — arquitetura HIP
  18. RFC 6538 — relatório do experimento HIP
  19. RFC 6973 — considerações de privacidade
  20. Heng Lu — camadas de realidade e poder simbólico
  21. Heng Lu — especificação inicial mínima
  22. Heng Lu — primazia do código em execução