Resumo

  • RFC 5201 e RFC 7401 permitem que o respondente selecione uma R1 pré-calculada e permaneça stateless até uma I2 válida; a assinatura mostra origem passada, não presença ou alocação atual.
  • A evidência progride por transições: I2 aceita cria estado no respondente, R2 verificada conclui a troca-base para o iniciador, e uma associação de payload com tráfego observado sustenta a alegação de caminho utilizável.

Por que o protocolo responde sem lembrar

O HIP usa I1, R1, I2 e R2. I1 dispara a negociação. R1 entrega o desafio, material Diffie–Hellman, opções e assinatura do respondente. I2 devolve a solução e o material autenticado do iniciador. R2 fecha a troca-base.

Uma implementação pode manter um conjunto de R1 prontas. Ao receber I1, escolhe uma delas, completa campos dinâmicos permitidos e responde sem criar estado específico. O diagrama de RFC 5201 diz que o respondente permanece stateless. A versão 2, definida em RFC 7401, mantém essa propriedade.

O motivo é evitar que tráfego forjado converta um pacote barato em memória e criptografia caras no alvo. O respondente adia verificação de assinatura, cálculo DH e criação da associação até receber uma I2 com solução plausível. A ausência de sessão após R1 não é falha de auditoria: pode ser a proteção funcionando.

Uma assinatura sem relógio embutido

A assinatura em R1 comprova que a Host Identity do respondente gerou as partes cobertas. O limite textual é importante: a R1 foi gerada uma vez pelo respondente. Como pode ter sido pré-calculada e não cobre toda informação própria de I1, não oferece sozinha proteção completa contra replay.

O horário de recepção pertence ao observador. Ele não informa quando R1 foi produzida, quando o peer processou aquela I1 ou quando reservou estado. Tratar esses instantes como um só cria uma presença que o pacote não contém.

O R1 generation counter permite preferir uma geração mais nova de desafios. Não é tempo de parede. HIPv2 trata preservação e reinicialização do contador e mantém a decisão de não inserir timestamp em R1, evitando depender de sincronização global. Um painel não pode converter a geração em idade absoluta.

O recibo deve separar HIT, algoritmos, resultado da assinatura, geração, vida útil, dificuldade e valor opaco do puzzle, além do relógio monotônico local. Se houver uma inferência de frescor, a regra precisa aparecer.

Trabalho computacional não é autorização

O iniciador procura um J que, combinado com o desafio I e os HITs, gere o número exigido de bits zero. O respondente verifica com um hash. Assim rejeita I2 inválidas antes de operações de chave pública e DH.

RFC 5201 chama de “sincero” quem gastou ciclos de CPU. A palavra descreve apenas o custo. A solução não autentica intenção humana, contrato, conta, prioridade, capacidade disponível ou existência de um serviço. Também não prova que o respondente recebeu e aceitou a I2.

A proteção possui limites explícitos. A vinculação ao HIT dificulta fabricar várias identidades usando um único desafio, mas não elimina o atacante que mantém HIT fixo. A implementação pode guardar falhas anteriores, trocando memória por cálculo. A telemetria deve registrar essa política, não transformar o puzzle em pontuação de confiança.

A decisão local aparece na I2

I2 carrega solução, contribuição DH e assinatura do iniciador. O respondente testa primeiro o puzzle barato. Se os passos seguintes também passam, deriva o material compartilhado e cria a associação HIP.

Um evento I2 accepted no respondente é evidência de que uma política e uma versão de implementação cruzaram a fronteira de estado. Ainda não prova que R2 chegou. Quando o iniciador verifica R2, passa a ter prova de conclusão da troca-base sob sua perspectiva.

As duas perspectivas precisam ser correlacionadas por HITs, geração, parâmetros e hashes. Relógios de máquinas ajudam a ordenar, mas não devem substituir os vínculos do protocolo. Se há R1 válida e nenhuma sessão remota, as hipóteses normais incluem I2 ausente, expirada, com puzzle inválido ou assinatura recusada.

A troca-base termina antes do serviço começar

RFC 7401 estabelece estado HIP e material de chaves, mas não define o formato real dos dados do usuário. Ele remete a especificações de transporte e exige o ESP de RFC 7402. No fluxo de recuperação, primeiro termina a troca-base, depois pode ser criada uma nova payload association e só então os dados são enviados.

R2 verificada não comprova SAs ESP instaladas em ambos os lados. Uma SA local não comprova o estado remoto. Um pacote protegido enviado não comprova chegada; chegada de rede não comprova aceitação da aplicação.

Para alegar caminho pronto, registre transporte negociado, suites, localizadores, época de chave, SPIs protegidos, resultado de instalação nos dois lados e primeiro pacote autenticado em cada direção. Para alegar serviço pronto, acrescente uma resposta segura e específica da aplicação.

Recibos mínimos por etapa

Etapa Evidência obtida Afirmação ainda indevida
I1 enviada O iniciador emitiu o gatilho O respondente recebeu
R1 verificada A chave remota gerou o material assinado em algum momento Presença atual ou reserva
Puzzle resolvido O iniciador pagou o trabalho O respondente aceitou
I2 aceita O respondente criou estado HIP O iniciador recebeu R2
R2 verificada A troca-base terminou naquele lado Payload association ativa
SA de payload instalada Existe estado de transporte nomeado Sucesso bidirecional
Requisição e resposta protegidas Um efeito delimitado ocorreu Disponibilidade contínua

Cada linha precisa de versão, política, coordenada do protocolo, tempo local e motivo de falha. “HIP OK” não é uma especificação mínima suficiente.

O documento de 2008 não é o padrão atual

RFC 5201 foi publicado em abril de 2008 como Experimental e declara não especificar um Internet Standard. A nota do IESG aponta SHA-1, agilidade de MAC, escolhas RSA e políticas dependentes de endereço IP. RFC 6253 acrescentou certificados.

RFC 7401 tornou RFC 5201 obsoleto em 2015, incorporou experiência de implementação e publicou HIPv2 como Proposed Standard, com negociação e agilidade melhores. RFC 8002 e RFC 9374 atualizaram depois elementos relacionados. A suíte de 2008 não deve ser vendida como recomendação atual.

O limite probatório, porém, é atual dentro de HIPv2: resposta autêntica e compromisso de estado continuam separados. Seguir a realidade operacional exige nomear a transição executada, sem usar a assinatura como símbolo para todas as etapas posteriores.

Fontes

  1. RFC 5201 HTML
  2. RFC 5201 em texto
  3. Página informativa do RFC 5201
  4. Datatracker do RFC 5201
  5. Histórico do RFC 5201
  6. Referências do RFC 5201
  7. Errata do RFC 5201
  8. RFC 7401 — HIPv2
  9. RFC 7401 em texto
  10. Página informativa do RFC 7401
  11. Errata do RFC 7401
  12. RFC 7402 — transporte ESP para HIP
  13. RFC 4423 — arquitetura HIP
  14. RFC 4987 — contramedidas a SYN flooding
  15. RFC 6253 — certificados HIP
  16. RFC 8002 — certificados HIPv2
  17. RFC 9374 — DRIP Entity Tag
  18. Heng Lu — camadas da realidade e poder simbólico
  19. Heng Lu — especificação inicial mínima
  20. Heng Lu — primazia do código em execução