Resumo

  • Na RFC 5206 e na sucessora RFC 8046, a proteção criptográfica atribui o anúncio do locator ao peer; o novo endereço normalmente permanece UNVERIFIED até devolver um nonce ou receber tráfego protegido qualificável.
  • Credit-Based Authorization permite poucos bytes durante a verificação. Ela contém amplificação, não comprova endereço, SA, rota nem continuidade do serviço.

A assinatura termina antes do roteador

HIP mantém a identidade do host separada de seu ponto de conexão. A mudança de IP não precisa destruir o relacionamento criptográfico. Mas uma consequência dessa arquitetura é que a identidade pode dizer onde pretende estar sem que a rede confirme a pretensão.

HMAC e assinatura protegem o UPDATE no contexto da associação. O receptor pode confiar na autoria, sequência e integridade da lista. Não pode inferir que a interface está ativa, o anúncio de rota convergiu ou o estado do firewall acompanha o movimento.

Por isso os estados importam. UNVERIFIED é uma declaração aceita sem prova de caminho. ACTIVE segue uma verificação. DEPRECATED encerra o uso após lifetime ou política. Um painel que mostra apenas “válido” apaga justamente o intervalo de risco.

A pergunta enviada ao lugar certo

O teste comum coloca um nonce aleatório em ECHO_REQUEST e envia UPDATE ao novo endereço. A resposta correspondente demonstra que o peer recebeu e respondeu naquele ponto. Outro exchange pode servir, desde que produza a mesma evidência.

Dados protegidos que chegam em uma SA recém-anunciada também podem verificar implicitamente o endereço. O fato novo é a chegada do pacote. Registrar só a assinatura anterior destrói a proveniência dessa decisão.

Uma SA criada, um locator verificado e uma aplicação recuperada são três estados. A SA pode existir sem retorno; o retorno HIP pode passar enquanto ESP falha; ESP pode passar e o serviço continuar indisponível.

Preferência não é uma medição

O bit preferido informa a vontade do par. Se o locator preferido está UNVERIFIED e existe outro ACTIVE, a RFC 8046 orienta manter o ativo durante a prova. A política escolhe a preferência; a observação concede atividade.

Lifetime também não promete uptime. Ele controla a validade do registro. Link, rota, NAT e política podem morrer antes. Após silêncio, até um endereço antes ativo pode exigir nova verificação.

A exceção de R1 tem escopo do base exchange. Ela deve aparecer no recibo como regra específica, não como licença genérica para ativar qualquer endereço assinado.

CBA: continuidade com saldo

Esperar uma volta completa aumenta a pausa da mobilidade. CBA acumula crédito a partir de bytes recentes recebidos do peer. O host pode enviar ao endereço não verificado até gastar o saldo; o crédito também envelhece.

O objetivo é impedir amplificação por redirecionamento. Não elimina flooding direto, não prova propriedade e não muda o nome do estado. O evento correto é enviado sob CBA, com saldo, origem do crédito, aging, gasto e resultado final.

Quando a resposta não chega, os bytes enviados continuam sendo uma decisão limitada sob incerteza. Eles não se convertem retroativamente em teste bem-sucedido.

Reconstruir a mudança

O recibo liga associação, UPDATE, locators, lifetime, preferência, validação sintática, estado inicial, fallback, nonce, retransmissões, resposta ou pacote protegido, transição, escolha de rota, SA, primeiro payload, aplicação, expiração e remoção.

Essa cadeia preserva a autonomia das camadas. O peer controla a declaração. HIP controla o teste. IPsec controla a SA. A rede controla a entrega. A aplicação controla o resultado. Um indicador comercial não herda autoridade sobre todas elas.

A sucessão não é decoração

A RFC 5206 saiu como Experimental em 2008 e está obsoleta. A RFC 8046 a substituiu em 2017 no Standards Track, adotou LOCATOR_SET e levou multihoming à RFC 8047. A necessidade de verificar endereço sobreviveu à revisão.

Mas escrever RFC 8046 no inventário não atesta o binário. Versão, parser, state machine, timers, parâmetros CBA e pacotes reais precisam ser observados.

Liderança deve contratar quatro resultados: anúncio autenticado, locator verificado, caminho protegido ativo e aplicação contínua. O protocolo comum fornece a primeira prova e o mecanismo da segunda. Running code mostra se a rota existiu.

Fontes

  1. Informações RFC 5206
  2. RFC 5206 HTML
  3. RFC 5206 em texto
  4. Datatracker RFC 5206
  5. Histórico RFC 5206
  6. Referências RFC 5206
  7. Errata RFC 5206
  8. Informações RFC 8046
  9. RFC 8046 HTML
  10. RFC 8046 em texto
  11. Datatracker RFC 8046
  12. Histórico RFC 8046
  13. Referências RFC 8046
  14. Errata RFC 8046
  15. RFC 7401 — HIP v2
  16. RFC 7402 — transporte ESP HIP
  17. RFC 8047 — multihoming HIP
  18. RFC 6973 — privacidade
  19. RFC 4423 — arquitetura HIP
  20. Heng Lu — camadas de realidade
  21. Heng Lu — especificação inicial mínima
  22. Heng Lu — primazia do código em execução