Resumo

  • No RFC 5204, o RVS é um ponto inicial: consulta o registro do HIT e retransmite I1; R1, I2 e R2 seguem diretamente entre iniciador e respondente.
  • FROM e RVS_HMAC preservam a integridade da reescrita dentro do vínculo de registro, não a presença atual do host nem a autenticação completa dos extremos.
  • DNS, época do registro, envio, recebimento, retorno, base exchange, plano de dados e efeito da aplicação precisam de recibos separados e correlacionáveis.

Um registro válido pode apontar para ontem

Considere uma situação hipotética. Um equipamento móvel registrou o endereço A e depois passou para B. O update ainda não chegou ao RVS; o lifetime de A continua válido. O servidor recebe I1, localiza o HIT, escolhe A, inclui FROM, calcula RVS_HMAC e transmite. Todos os seus controles ficam verdes. Nenhum pacote alcança o equipamento.

O RFC 5204, Experimental e posteriormente substituído pelo RFC 8004, não promete o contrário. Ele cria uma oportunidade de contato para nós HIP móveis ou multihomed. O cliente registra HIT e endereço atual. Um iniciador descobre o RVS, em geral por DNS, e envia I1. O servidor retransmite se houver registro apropriado e descarta se não houver.

“Atual” descreve a visão aceita na base do RVS. Não significa que o endereço foi medido novamente no instante da consulta.

O caminho direto começa em R1

I1 passa pelo RVS. O respondente envia R1 diretamente ao iniciador; I2 e R2 também são diretos. O rendezvous não é o túnel da sessão e não observa necessariamente o restante da troca.

Daí surgem estados independentes: iniciador alcançou RVS; RVS selecionou locator; I1 saiu; respondente recebeu; R1 voltou; I2/R2 concluíram; proteção entrou em vigor; aplicação funcionou. Um painel que mede apenas os três primeiros não pode resumir o conjunto como “peer reachable”.

O documento tampouco cobre o iniciador usando seu próprio RVS para atravessar NAT ou firewall. Se um sistema implementa esse caso, deve declará-lo como mecanismo adicional, não como conclusão implícita do RFC 5204.

FROM explica a transformação

Filtros de egresso podem exigir que o RVS substitua o source IP pelo próprio endereço. Nesse caso, ele carrega o endereço original em FROM e protege o parâmetro com RVS_HMAC, usando a chave de integridade criada no registro. Vários servidores acrescentam valores em ordem, sem apagar os anteriores.

O HMAC prova que alguém com a chave de registro protegeu aquela transformação para o cliente do RVS. Não é uma assinatura da Host Identity do iniciador, não mede cada hop e não confirma entrega. A cadeia FROM é uma cadeia declarada de reescritas, não um traceroute criptográfico.

Esse limite dá utilidade à evidência. Em vez de um genérico “origem verificada”, o sistema pode dizer exatamente: “integridade da reescrita RVS-cliente verificada sob o registro X”.

O primeiro pacote ainda não autenticou os pares

I1 não contém os HMACs e signatures end-to-end usados mais adiante no HIP base exchange. Por isso o RVS consegue alterar cabeçalhos e acrescentar parâmetros, recalculando checksums. A autenticação dos hosts ocorre na troca subsequente.

Há duas autoridades: a integridade do registro explica o ato do intermediário; a base exchange explica a relação entre endpoints. Mesmo depois das duas, o plano de dados e a aplicação continuam sendo resultados posteriores.

O RFC trata riscos de redirecionamento, amplificação, reflexão e ataques à camada HIP. Um componente capaz de transformar identidade registrada em destino de tráfego precisa mostrar a sua decisão com precisão — e não ampliar a conclusão.

VIA_RVS é uma pista, não um veredicto

O respondente que recebeu um I1 retransmitido inclui VIA_RVS em R1. O objetivo principal é diagnóstico. O parâmetro ajuda a identificar o RVS envolvido quando o estabelecimento falha.

Ele não demonstra que o iniciador recebeu R1, não lista todos os hops e não comprova conclusão. R1 criado, R1 recebido, R1 validado, I2 enviado, R2 recebido e associação ativa devem permanecer eventos distintos.

DNS e registro têm validades diferentes

O DNS fornece o local do RVS com TTL, cache e possível assinatura. O registro fornece locator, lifetime e última atualização para o HIT. Um RR novo pode levar a um RVS sem o registro; um registro vivo pode conter endereço antigo; um endereço correto pode falhar por rota ou política.

O recibo operacional deve preservar RR usado, HIT, identidade e época do registro, fingerprint de I1, decisão de lookup, cabeçalhos antes e depois, FROM, contexto de HMAC e envio. Depois acrescenta a evidência que o RVS não possui: recebimento remoto, R1 direto, I2/R2, proteção, tráfego e resultado.

Obsoleto não quer dizer observado

RFC 8004 substituiu RFC 5204; RFCs 7401, 8003, 8005 e 8046 renovaram peças vizinhas. Inventários devem registrar qual geração está em execução. A mera referência a um RFC, entretanto, não prova versão implantada, migração, vulnerabilidade ou falha.

“HIP rendezvous suportado” precisa virar versão, algoritmos, tipos de registro, parâmetros, política e teste. A especificação define expectativa; running code e evidência de rede definem o estado real.

Sources