ICPv2 sob medida: por que uma HIT orienta a próxima tentativa, mas não comprova a entrega

Resumo

• Publicada em setembro de 1997 por Duane Wessels e K. Claffy como Informational, a RFC 2186 define o ICPv2 como um protocolo leve de consulta e resposta entre caches vizinhos. Ele ajuda a escolher uma fonte para tentar; no fluxo normal, é o HTTP que transfere o objeto.
• ICP_HIT significa que o vizinho declara possuir o objeto solicitado e permitir sua obtenção. Isso não prova entrega, origem, identidade, frescura, completude, segurança, melhor fonte ou disponibilidade futura.
• Sender Host Address e Requester Host Address precisam permanecer semanticamente separados: o primeiro não merece confiança superior à do peer observado pelo transporte; o segundo pode ser all-zero, significando endereço não especificado.
• ICP_HIT_OBJ exige opt-in e contorna HTTP authorization e age validation. Isso é distinto do fato de segurança de que as respostas ICP não são autenticadas.

O ICPv2 resolve uma pergunta operacional bastante específica. Um cache quer saber se algum vizinho parece ser uma fonte útil para determinada URL. Ele envia consultas, recebe sinais e usa essas respostas para decidir qual caminho tentar.

O protocolo não promete transformar essa escolha preliminar em prova do que ocorrerá depois.

Essa diferença é a chave para interpretar a RFC 2186. A mensagem ICP pertence ao momento da seleção. A recuperação do objeto pertence, normalmente, a uma etapa HTTP posterior. Confundir esses dois eventos faz uma indicação intermediária parecer mais conclusiva do que realmente é.

Uma troca compacta voltada à decisão

O cabeçalho ICPv2 ocupa 20 octetos. A mensagem inteira não pode ultrapassar 16.384 octetos. Implementações normalmente esperam apenas um ou dois segundos pelas respostas.

Esses limites mostram um mecanismo pensado para informar uma escolha rapidamente. O objetivo não é construir uma comprovação completa sobre o objeto antes de selecionar um vizinho.

O Request Number é opaco e deve ser copiado para relacionar consulta e resposta. Ele não carrega significado adicional sobre procedência, confiança ou qualidade do conteúdo.

A URL precisa ser exata. A resposta se refere àquele recurso específico, dentro daquela interação.

Essa precisão importa porque o ICP oferece evidência contextual. Uma resposta não descreve todo o estado da infraestrutura nem cria uma afirmação universal sobre o objeto. Ela informa algo útil para uma decisão localizada.

Silêncio encerra uma opção momentânea, não produz um diagnóstico

Quando não chega uma resposta dentro da janela operacional, o efeito para o solicitante é simples: aquele vizinho não oferece, naquele momento, uma base para ser selecionado.

Isso não revela automaticamente a causa.

O silêncio não demonstra por si só que o cache está inativo, que determinada aplicação falhou, que a URL não existe ou que uma condição específica explica a ausência da mensagem.

A distinção entre observação e diagnóstico precisa permanecer intacta. “Não houve resposta utilizável” é uma evidência. Explicar por que ela não chegou exige informação adicional.

No ICPv2, a incerteza não impede a decisão. O solicitante pode continuar com outro candidato sem transformar essa escolha em uma conclusão causal sobre o vizinho silencioso.

Sender Host Address não estabelece uma identidade mais forte

O Sender Host Address deve ser lido com reserva.

Ele não deve prevalecer sobre o endereço do peer observado pelo transporte. Seu propósito era ambíguo e, na prática, o campo não era usado.

Portanto, seu conteúdo não fornece razão para substituir a procedência que o transporte efetivamente observou. Muito menos cria, sozinho, uma identidade confiável do remetente.

Essa distinção é relevante para qualquer tentativa de reconstruir proveniência. Um endereço carregado em um campo da mensagem e um peer observado pelo transporte são evidências diferentes. A RFC não justifica elevar o primeiro acima do segundo.

Requester Host Address tem outra semântica

O Requester Host Address da consulta precisa ser tratado separadamente.

Esse campo pode ser all-zero. Nesse caso, o significado é “não especificado”.

Essa convenção de zero pertence ao Requester Host Address. Ela não deve ser transferida para a interpretação do Sender Host Address.

Os dois fatos tratam de problemas diferentes: um campo possui uma representação explícita de ausência de endereço; o outro não deve ser considerado mais confiável do que a origem observada pelo transporte.

Separar essas semânticas evita que um detalhe de formato se transforme em uma inferência incorreta sobre identidade.

O significado de ICP_HIT termina antes da entrega

Quando um vizinho responde ICP_HIT, ele informa que o objeto existe ali e que sua obtenção é permitida.

Essa resposta dá ao solicitante uma razão para considerar aquele vizinho.

No fluxo normal, porém, o objeto ainda precisa ser obtido por HTTP. A HIT e a transferência são eventos consecutivos, não equivalentes.

O vizinho pode nem ser escolhido. A tentativa posterior pode não terminar. A situação pode mudar entre a resposta ICP e a recuperação. O conjunto de bytes obtidos pode não ser completo. A aplicação pode falhar depois da transferência.

Por isso, a HIT não comprova origem, identidade, frescura, integridade, completude dos bytes, renderização segura, melhor fonte, disponibilidade futura, entrega efetiva à aplicação ou resultado de negócio.

Ela comprova muito menos: houve uma indicação positiva, produzida por um vizinho, suficientemente relevante para participar da seleção.

Essa limitação é parte do desenho, não uma deficiência a ser corrigida por interpretação.

ICP_MISS ainda admite continuidade

ICP_MISS significa que o objeto não está presente localmente no cache consultado.

Esse estado não obriga a concluir que o vizinho não pode ser útil. Ele ainda pode admitir encaminhamento.

Assim, MISS não deve ser traduzido em uma afirmação absoluta como “não há forma de obter o objeto por aqui”. O que se sabe é que não houve acerto local.

A possibilidade de comportamento posterior permanece distinta da presença imediata do objeto.

ICP_MISS_NOFETCH muda o que aquele vizinho pode fazer

ICP_MISS_NOFETCH comunica uma restrição adicional.

O cache está vivo e responde, mas não buscará o objeto quando ocorrer um miss.

Para a escolha de fonte, isso faz diferença. Um vizinho que apenas respondeu MISS pode ainda participar de um caminho subsequente; um MISS_NOFETCH informa que esse tipo de recuperação não acontecerá.

Agrupar os dois códigos como simples “não HIT” remove uma parte significativa da semântica operacional.

ICP_DENIED vale dentro de uma relação

ICP_DENIED representa uma negativa naquele escopo e naquele momento.

O código informa que o solicitante não deve seguir por aquela opção nas condições observadas. Ele não demonstra, por si só, por que a negativa aconteceu e não transforma a política daquele vizinho em propriedade global do objeto.

Uma proporção elevada de DENIED pode indicar erro de configuração. Esse padrão merece investigação justamente porque pode revelar problema nas relações ou permissões entre os participantes.

Ainda assim, a resposta isolada não é um diagnóstico completo.

Echo responde uma pergunta menor

O Echo serve para testar alcançabilidade.

Uma resposta bem-sucedida mostra que a condição testada foi observada, mas não demonstra que a aplicação de cache esteja apta a entregar uma URL específica.

Também não comprova que o passo HTTP seguinte funcionará.

Esse limite segue a mesma lógica da HIT: cada sinal deve sustentar apenas a propriedade que realmente observou.

Alcançabilidade não é entrega. Entrega não é, por si só, processamento correto pela aplicação.

Source RTT não é uma promessa sobre o próximo acesso

Source RTT pode fornecer contexto adicional para seleção, mas possui limites explícitos.

O valor pode estar armazenado, pode ser zero ou pode estar ausente. Sua obtenção não deve retardar a resposta ICP.

Isso impede que a métrica seja tratada como uma medição necessariamente atual e completa do caminho.

Sua presença pode ajudar uma escolha. Sua ausência não constitui automaticamente uma falha. Um valor zero também não deve ser convertido sem contexto em certeza sobre o comportamento real da rede.

O ICP privilegia uma decisão oportuna em vez de aguardar uma métrica auxiliar perfeita.

ICP_HIT_OBJ cruza uma fronteira importante

ICP_HIT_OBJ altera a relação normal entre sinalização e obtenção porque permite que o objeto acompanhe a resposta.

O recurso é desencorajado e requer opt-in.

Ele também evita duas etapas específicas do caminho HTTP: HTTP authorization, isto é, autorização, e age validation.

Essa formulação precisa importa. ICP_HIT_OBJ não deve ser descrito como mecanismo que contorna HTTP authentication.

A questão da autenticação pertence a outro fato: as respostas ICP, separadamente, não são autenticadas.

Uma coisa é o conjunto de controles HTTP que deixa de participar daquele caminho abreviado. Outra é a ausência de autenticação no próprio protocolo ICP.

Misturar os dois problemas encobre a superfície de segurança real.

O tamanho do objeto impõe outra fronteira

O transporte de conteúdo em HIT_OBJ também introduz risco de fragmentação relacionado à MTU.

Se o objeto não puder ser enviado integralmente, o comportamento deve recuar para uma HIT normal.

Esse recuo é significativo: um fragmento ou objeto incompleto não deve adquirir o significado de uma entrega completa apenas porque apareceu dentro de uma mensagem positiva.

Quando HIT_OBJ não consegue transportar adequadamente o conteúdo, o protocolo retorna ao modelo em que a sinalização indica uma fonte e a obtenção ocorre separadamente.

A falta de autenticação permite manipular escolhas

A análise de segurança do ICP deixa claro que as respostas não são autenticadas.

Esse fato afeta diretamente a confiança no plano de seleção.

Uma HIT falsificada pode induzir o solicitante a considerar determinada fonte. O atacante não precisa, naquele primeiro momento, demonstrar a disponibilidade legítima do objeto; alterar o sinal já pode alterar a escolha.

ICP_MISS_NOFETCH e ICP_DENIED falsificados podem operar no sentido contrário. Em vez de atrair a seleção, podem afastá-la de um cache que seria considerado.

O ponto vulnerável é a decisão.

A mensagem tem poder porque participa da escolha anterior à transferência.

Multicast possui uma restrição específica, não uma solução geral de identidade

Quando aparece uma resposta de um vizinho multicast desconhecido, ela deve ser ignorada.

Essa regra limita quais participantes podem influenciar a decisão nesse contexto.

Mas ignorar um desconhecido não torna autenticadas as respostas dos vizinhos aceitos. A ausência de autenticação continua existindo.

É importante preservar essa distinção porque filtragem de participantes e comprovação da identidade de uma mensagem são propriedades diferentes.

Spoofing com HIT_OBJ pode atingir o conteúdo

A combinação mais grave descrita para esse desenho surge quando spoofing encontra ICP_HIT_OBJ.

Uma HIT comum falsificada pode alterar a escolha da fonte. Com HIT_OBJ, o sinal manipulado pode também transportar o objeto.

Isso abre caminho para envenenamento de conteúdo.

A mudança é substancial: o atacante deixa de atuar somente sobre a seleção e pode interferir diretamente nos dados aceitos pelo destinatário.

Nesse cenário, duas limitações distintas se encontram. HIT_OBJ passa por fora de HTTP authorization e age validation, enquanto as respostas ICP não são autenticadas.

Essas condições se combinam no risco, mas continuam sendo fatos diferentes.

A semântica de cache HTTP pertence a outra camada

As regras modernas de caching HTTP são tratadas separadamente das dicas de vizinhança ICP.

Essa divisão impede que uma HIT ganhe retroativamente propriedades pertencentes à semântica HTTP.

Se a questão é frescura, validade ou tratamento de uma resposta armazenada no contexto HTTP, a evidência relevante precisa vir das regras correspondentes a essa camada.

Uma HIT não fornece essa confirmação.

O mesmo princípio vale adiante. Mesmo um evento HTTP não deve ser convertido automaticamente em evidência de que a aplicação processou corretamente o objeto ou de que algum objetivo de negócio foi alcançado.

Cada transição acrescenta um evento novo, e cada nova conclusão exige base própria.

A cadeia de evidência precisa manter suas etapas

Uma operação envolvendo ICPv2 pode ser vista como uma sequência.

Existe primeiro uma consulta para uma URL exata. Pode haver uma resposta. Essa resposta participa da seleção. A seleção pode levar a uma recuperação HTTP. A aplicação pode então receber e processar o resultado.

Os eventos têm relação, mas não são intercambiáveis.

Receber uma HIT não significa que o vizinho foi escolhido. Escolher o vizinho não significa que o HTTP concluiu a recuperação. Receber bytes não demonstra automaticamente frescura, identidade ou segurança. Processar o conteúdo não equivale necessariamente a produzir um resultado de negócio.

A proveniência precisa conservar essas fronteiras.

Quanto mais etapas forem comprimidas sob um único rótulo de “sucesso”, menos será possível saber posteriormente o que de fato aconteceu.

O sinal permanece útil justamente porque seu alcance é pequeno

O ICPv2 não precisa oferecer uma garantia abrangente para cumprir sua função.

Ele precisa produzir informação suficiente para a escolha da próxima tentativa. Dentro desse escopo, uma dica incompleta ainda pode ser operacionalmente valiosa.

O problema surge quando análises, métricas ou automações removem a incerteza que existia no evento original.

Se HIT passa a significar “objeto entregue”, perde-se a diferença entre indicação e transferência. Se DENIED vira “objeto inexistente”, uma política contextual vira uma propriedade global. Se silêncio recebe automaticamente uma causa, falta de resposta vira diagnóstico. Se Echo passa a representar funcionamento completo da aplicação, alcançabilidade é inflada para uma garantia que o teste não produziu.

A leitura correta segue o caminho oposto: preservar cada sinal no escopo que lhe pertence.

No ICPv2, uma HIT é uma dica para decidir qual vizinho merece uma tentativa. Identidade, frescura, integridade e entrega permanecem perguntas separadas.