Resumo

  • RFC 5203 separa oferta em REG_INFO, pedido em REG_REQUEST, autorização em REG_RESPONSE, falha em REG_FAILED e cancelamento por vida zero.
  • A vida concedida governa um registro de estado brando e revogável; não funciona como compromisso de disponibilidade do serviço associado.
  • Uma decisão operacional defensável conecta os estados do solicitante e do registrador ao aceite do serviço, à época de configuração, ao uso real e ao resultado.

A pergunta errada produz uma resposta verde

Um host recebe REG_RESPONSE para um serviço HIP, com vida útil de 120 segundos. O painel verifica a assinatura, grava o vencimento e passa a responder “o serviço está disponível?” com um indicador verde.

Pouco depois, uma recarga de configuração remove o estado do componente que presta o serviço. O registrador continua funcionando. Ele tenta enviar cancelamento com vida zero, mas a atualização não chega ao host. A próxima operação falha enquanto o painel continua verde.

O cenário é construído e não relata produto, rede ou incidente. A resposta original não mentiu. Ela registrou uma autorização válida. Quem mudou a pergunta foi o sistema de observabilidade: trocou “o registro foi concedido?” por “o serviço continua funcionando?” sem adquirir nova evidência.

Essa troca é comum porque os dois fatos ficam próximos no fluxo. Proximidade não é equivalência. Uma camada decide admissão; outra mantém recursos; outra transporta pacotes; a aplicação produz o resultado.

O mecanismo comum não descreve a etapa posterior

RFC 5203 foi publicado em 2008 como Experimental. Ele define um meio genérico para um host HIP se registrar com serviços, como servidor de rendezvous ou middlebox. O documento não define descoberta do serviço, localização do registrador nem interação depois do registro.

O limite protege a extensibilidade. Serviços diferentes podem exigir parâmetros e procedimentos próprios. Também impede que a resposta comum seja tratada como recibo universal.

Registro é definido como estado compartilhado entre solicitante e registrador, com duração finita e possibilidade de renovação. Esse estado permite ao solicitante beneficiar-se do serviço. Permissão e benefício realizado ocupam pontos diferentes na cadeia.

O texto diz ainda que o processamento bem-sucedido de REG_REQUEST cria estado no registrador e possivelmente no serviço. A palavra “possivelmente” é uma instrução de modelagem: guardar estado no registrador não autoriza preencher o campo do serviço como confirmado.

Quatro mensagens não cabem em um booleano

REG_INFO anuncia tipos que o registrador pode e quer oferecer. Se uma condição transitória impede a prestação, ele deve anunciar a lista vazia. Quando a oferta muda, deve informar o conjunto atual por UPDATE.

Esse anúncio é atual, não permanente. Não reserva capacidade futura. REG_REQUEST leva os tipos pretendidos e o tempo desejado; o solicitante só deve pedir o que recebeu no anúncio aplicável.

O registrador autentica a Host Identity e avalia política local. REG_RESPONSE lista tipos autorizados e vida concedida. REG_FAILED lista o que não terminou. No RFC original, o tipo zero pede credenciais adicionais e o tipo um indica indisponibilidade do tipo.

Cada mensagem conserva sujeito e momento. O anúncio fala da oferta. O pedido fala da intenção. A resposta fala da decisão. A falha fala da não conclusão conhecida. Nenhuma fala do resultado de uma operação futura.

Um painel que mostra apenas registered=true apaga precisamente as diferenças de que a investigação precisa quando algo deixa de funcionar.

O relógio mede estado brando

O solicitante pede uma vida e o registrador concede outra se necessário. Mesmo dentro do mínimo e máximo anunciados, o solicitante não pode exigir o mesmo valor que propôs.

A vida concedida é uma coordenada útil para atualização e expiração. Não é reserva irrevogável. Vida zero cancela. Solicitante, registrador ou serviço podem terminar o registro antes do prazo. Mudança de configuração, ataque e pressão de recursos são razões compatíveis com o modelo.

Por isso, o histórico deve registrar criação, última renovação, época de configuração, cancelamento enviado, cancelamento recebido e expiração prevista. O estado do serviço precisa de identificador e relógio próprios.

Não receber cancelamento não prova continuidade. O registrador “deve” enviar a notificação em condições normais, mas falha de caminho, processo ou observação pode impedir o recebimento. Ausência de evento fica como desconhecido.

Uma assinatura não aumenta o objeto da decisão

REG_RESPONSE é evidência forte para sua pergunta. HIP protege o parâmetro, o solicitante foi autenticado e a política local foi aplicada. Não há motivo para diminuir esse valor.

O problema é aumentar seu alcance. Criptografia protege origem e integridade; não faz a frase incluir um estado de outro processo. A assinatura do registrador não impede reinício do serviço, não fixa a rota e não comprova resposta da aplicação.

Quanto mais confiável o artefato, maior a tentação de reutilizá-lo para suprimir sonda ou fechar auditoria. A defesa é guardar metadados de escopo: principal, tipos, vida, política e época. Os componentes seguintes adicionam seus próprios recibos.

Assim, uma autorização correta permanece correta sem ser promovida a garantia geral.

RFC 8003 aperfeiçoou a recusa, não criou SLA

RFC 8003 substituiu RFC 5203 em 2016 e levou a extensão ao Standards Track. Especificou melhor a disposição em relação a cada solicitante, ampliou autorização baseada em certificados e adicionou falha por recursos insuficientes.

Essas mudanças ajudam a distinguir causas no momento do registro. Credencial ausente, certificado inválido, tipo indisponível e falta de recursos pedem respostas diferentes. Mas anúncio, pedido, concessão, falha, vida finita e cancelamento continuam separados.

Mais detalhe sobre admissão não é telemetria de execução. Tampouco a publicação do sucessor prova que uma instalação migrou. Documento, binário, configuração e pacote observado são registros distintos.

O RFC antigo deve ser apresentado como histórico e obsoleto. Seu limite semântico, entretanto, continua útil para ler tanto o mecanismo original quanto o sucessor.

O serviço específico completa a prova

Um tipo de registro pode exigir parâmetros HIP adicionais. O documento daquele tipo define a semântica. Esse arranjo mantém o núcleo mínimo e permite decisões locais verificáveis.

Para rendezvous, a prova posterior pode incluir binding salvo, I1 recebido, encaminhamento e resposta independente. Para middlebox, pode incluir regra instalada, escopo, proprietário, duração e pacotes que corresponderam. São provas diferentes.

A cadeia deve permanecer visível:

oferecido → pedido → autorizado → estado no registrador → estado no serviço → uso → resultado.

Se o serviço não expõe acuse, o campo correto é desconhecido. Preencher como ativo com base na concessão apenas transfere a incerteza para quem vai agir sobre ela.

Recibo mínimo para a pergunta certa

O conjunto necessário inclui:

  • versão HIP e da extensão, build e configuração;
  • HITs do solicitante e do registrador;
  • impressão de REG_INFO, tipos, vidas e horário;
  • impressão de REG_REQUEST, tipos e vida solicitada;
  • identidade autenticada, credencial, política e decisor;
  • impressão de REG_RESPONSE ou REG_FAILED, resultado e vida concedida;
  • estados dos dois lados, criação, atualização e expiração;
  • estado e aceite explícito do serviço;
  • cancelamento, expulsão, reinício e mudança de configuração;
  • pedido específico do serviço, caminho e resultado;
  • lacunas marcadas como desconhecidas.

Esse recibo permite que cada equipe responda pelo que realmente observou. O registrador não assume o resultado da aplicação. O serviço não assume a entrega ao solicitante. O painel não inventa a etapa ausente.

RFC 5203 ensina uma regra simples: antes de aceitar o verde, leia a pergunta. O “sim” do registrador pode estar perfeitamente correto e ainda não ser a resposta de que a operação precisa.

Fontes