Resumo

  • O resultado de RFC 5210 vale para o AS experimental com validação completa no acesso, dentro do AS e entre AS. Um trecho sem uma dessas barreiras não herda a conclusão.
  • Vínculos de porta, regras derivadas de rota e tags de aliança mudam. Sem versão e horário, um aceite histórico é apresentado de forma indevida como estado permanente.
  • A validação reduz spoofing, não autentica a pessoa. Um equipamento comprometido pode usar o endereço legítimo e passar corretamente por todos os filtros.

Três sinais verdes e uma pergunta sem resposta

Às 09:00, um pacote IPv6 sai de uma máquina ligada à porta 17. A tabela do acesso confirma o endereço e a porta. No ingresso do AS, o prefixo é compatível com a interface segundo a visão de roteamento daquele momento. No AS remoto, a tag temporária da aliança é reconhecida. O painel recebe três resultados positivos.

Se o registro disser “este pacote passou por estas três verificações, com estes estados, às 09:00”, ele é útil. Mas o painel comprime tudo em origem autenticada, expressão sem objeto, cobertura ou tempo.

Às 09:12, a máquina faz failover para outro enlace. Um mapa de prefixos muda e uma nova tag começa a substituir a anterior. Um validador já recebeu a regra nova; outro ainda usa a projeção antiga. As duas tags são aceitas por alguns segundos para não interromper tráfego. Às 09:15, o painel continua verde.

O resultado das 09:00 não se tornou falso. O problema é reutilizá-lo no presente sem nova observação. E há um segundo salto: aceitar um endereço no modelo de rede não identifica quem acionou a máquina.

O cenário é construído e não relata uma empresa, produto ou incidente. Ele separa duas coisas que interfaces costumam fundir: validade de um endereço num caminho e identidade de um ator.

A dimensão exata do teste

RFC 5210 foi publicado como Experimental em junho de 2008. O protótipo Source Address Validation Architecture foi instalado em 12 AS de universidades ligadas à CNGI-CERNET2. Seis tinham os três componentes e eram descritos como plenamente equipados.

Os testes cobriam operação normal, mudanças dinâmicas e anti-spoofing. No caso de AS não vizinhos, havia ensaios de inserir e retirar tags, encaminhar fonte válida, atualizar a tag, proteger novo membro, adicionar e remover espaço de endereços e filtrar endereços forjados.

O documento relata que, no AS com validação de acesso, intra-AS e inter-AS, pacotes sem endereço de origem autenticado não foram encaminhados. Esse resultado é forte justamente porque a condição é explícita. Ele não mede toda a Internet nem atesta uma implantação atual.

Os autores apresentam protótipo e resultados como contribuição para trabalho futuro, sem antecipar soluções posteriores do IETF. Também documentam limites. Preservar esses limites não diminui o experimento; impede que um sucesso técnico seja usado como certificado universal.

No acesso, a evidência é de conexão

Uma variante liga dinamicamente endereço IP, MAC e porta de switch. O tráfego que não corresponde ao par endereço-porta é descartado. Outra variante usa material de chave derivado da autenticação de acesso para proteger o pacote entre host ou agente e o equipamento SAVA.

O primeiro mecanismo demonstra compatibilidade com uma atribuição e um ponto de conexão. O segundo acrescenta verificação sob um contexto de sessão. Nenhum deles revela sozinho o usuário, o processo, a organização ou a intenção por trás do pacote.

O próprio RFC observa que a abordagem do protótipo não seria suficiente em produção. Mobilidade, multihoming, rede sem fio, failover e troca de interface alteram o vínculo. Um recibo precisa registrar criação, validade, migração, conflito e confirmação de instalação.

Dentro do AS, a evidência é topológica

A segunda camada adota princípios de filtragem de ingresso de RFC 2827 e RFC 3704. A pergunta é se o prefixo de origem faz sentido naquela interface sob um modelo de roteamento. Isso é mais amplo que um host.

RPF estrito, caminho viável e checagens mais soltas produzem afirmações diferentes. Em redes assimétricas ou multihomed, o melhor caminho de volta pode não ser a entrada legítima. A flexibilização reduz falsos bloqueios, mas também reduz a granularidade do que foi provado.

O aceite deve ser acompanhado pelo modo, pela interface, pela visão de rotas, pela regra e pelo horário efetivo. Sem esses elementos, uma regra antiga pode parecer atual mesmo que o algoritmo tenha funcionado corretamente quando a gerou.

Entre AS, a dependência deixa de ser local

Para vizinhos, o protótipo relaciona cada interface de entrada a blocos de origem permitidos. Um motor gera regras em termos de AS, um serviço converte AS em prefixos IPv6 e os validadores recebem a projeção.

Para AS não vizinhos, uma aliança usa tags temporárias. O roteador de saída adiciona um valor conforme o destino; o roteador de entrada verifica e remove. Servidores de controle trocam membros, propriedade de prefixos e tags.

Assim, a validade depende de coordenação, configuração, confiança, sincronização e instalação em vários domínios. A aliança pretendia aceitar entradas e saídas dinâmicas, mas a confiança inicial do testbed foi confirmada fora de linha. Não há prova de confiança global automática.

Toda regra tem época e atraso

RFC 5210 reconhece que o mecanismo de AS vizinhos pode acompanhar lentamente mudanças de rota e causar falsos positivos. Ele funcionou numa rede relativamente estável. A estabilidade faz parte do contexto do resultado.

As tags também expiram. No teste, a tag velha continuava válida por cinco segundos depois da nova, evitando perda na transição. Durante esse intervalo, o correto não é escolher uma única “tag atual”, mas registrar a janela em que ambas são aceitas.

O recibo precisa de vínculo de acesso, visão de rota, relação entre AS, mapa AS-prefixo, versão de regra, entrega, hash instalado, membresia, época de tag e fim da sobreposição. Também deve apontar a primeira barreira ausente, atrasada ou desviada.

Um booleano pode guardar o resultado, mas não guarda a realidade utilizada para chegar a ele.

Rastreabilidade não vira identidade humana

Menos spoofing torna o endereço e o caminho evidências melhores para investigação. Isso ajuda diagnóstico e resposta. Ainda assim, chegar a uma rede ou ponto de conexão não é chegar a uma pessoa.

RFC 7039 alerta para a tentação de usar vínculos SAVI como prova da pessoa ou mesmo do sistema final que gerou o datagrama. Eles oferecem evidência circunstancial. Servidores multiusuário, proxies, relays, plataformas e endpoints comprometidos quebram a inferência direta.

A escada correta separa endereço aceito, conexão, dispositivo, workload, conta, organização, pessoa e intenção. Cada degrau exige nova fonte e nova incerteza. O primeiro não contém os demais.

Logs de vínculo também podem revelar localização e atividade. Retenção, acesso, finalidade e correção precisam de regras. Uma associação aparente não deve gerar sanção automática.

O atacante pode estar usando seu endereço verdadeiro

O limite mais importante já está em RFC 5210: muitos ataques de negação de serviço usam endereços legítimos de clientes de botnet. Mesmo a implantação universal de validação não impediria esses ataques.

SAVA combate falsificação de origem. Não demonstra saúde do host, autorização do aplicativo, legitimidade de volume ou intenção. Um notebook comprometido pode passar nas três barreiras porque utiliza exatamente o endereço que recebeu.

Quando isso acontece, a investigação deve migrar para endpoint, processo, conta, autorização e comportamento. Repetir o teste anti-spoofing não responde à classe de risco que ficou fora dele.

Configuração não é execução no plano de dados

A tag leve do experimento era um valor aleatório compartilhado, não identidade criptográfica por pacote. O RFC descreve a vulnerabilidade a atacantes no caminho e o custo de um hash mais forte. Também relata baixa velocidade quando opções IPv6 hop-by-hop encontraram roteadores que as processavam lentamente.

Regra no controlador prova intenção. Confirmação do equipamento prova recebimento. Contadores, pacotes de teste e observação no lugar certo provam efeito. A arquitetura deve manter os três recibos.

Uma opção no caminho lento pode criar uma superfície de DoS. Um bypass emergencial para recuperar capacidade pode remover uma barreira. O painel só saberá se medir a fração de tráfego realmente processada pela regra correta.

O recibo operacional

Registre pacote ou fluxo, ponto, horário e perfil esperado. No acesso: origem da alocação, endereço, âncora, porta, criação, expiração e movimentação. No intra-AS: modo, interface, visão de rotas, prefixo, regra e momento de geração.

No inter-AS: relação, mapa, motor, versão, distribuição e instalação. Na aliança: membros, pares, propriedade, tag ou semente, época, sobreposição e validade. Acrescente versões de software e hardware, tratamento de opções, contadores, descartes e origem do teste.

Depois pare no limite. Sem evidência independente sobre dispositivo, conta ou pessoa, escreva: endereço e caminho aceitos; ator desconhecido. A precisão abre o próximo passo; um selo absoluto o fecha.

Fontes