Resumo

  • Um endereço gerado criptograficamente vinculava uma chave pública ao identificador de interface IPv6; a assinatura mostrava controle da chave privada, não identidade civil nem autoridade para operar como roteador.
  • Para aceitar um roteador, o host ainda precisava validar uma cadeia de certificados até uma âncora de confiança instalada localmente. O SEND não eliminou essa configuração.

Antes de abrir uma conexão pela Internet, um host IPv6 precisa confiar no que descobre no próprio enlace: resolver endereços de camada de enlace, localizar roteadores e acompanhar a alcançabilidade dos vizinhos. A especificação de Neighbor Discovery define essas funções. A ideia de protegê-las com IPsec não veio acompanhada de instruções detalhadas, e configurar manualmente associações de segurança para muitos pares seria inviável na maioria dos casos, observa a RFC 3971. O SEND buscou uma forma prática de proteger esse primeiro contato.

A escolha de arquitetura foi dividir as provas. Para mostrar que controla a chave associada ao endereço, um nó podia usar um endereço gerado criptograficamente (CGA). A RFC 3972 deriva o identificador de interface de uma chave pública e parâmetros auxiliares. Quem recebe a mensagem recalcula o vínculo e verifica a assinatura. Não é necessária uma autoridade certificadora para essa associação entre endereço e chave.

Isso não transforma uma chave em identidade. A própria RFC 3972 observa que alguém pode criar uma nova CGA sob um prefixo de sub-rede usando sua própria chave. O mecanismo impede que essa pessoa assine como titular de uma CGA preexistente de outra pessoa; não prova quem ela é, quem delegou aquele prefixo ou se ela pode anunciar uma rota. A pergunta “quem controla esta chave?” não responde “quem autorizou este roteador?”.

Para Router Discovery, o host percorre outro caminho. O certificado apresentado pelo roteador precisa encadear até uma âncora de confiança que o host já tenha configurado. As mensagens de descoberta de delegação do SEND podem ajudar a obter o caminho de certificação, mas não estabelecem a raiz que torna esse caminho confiável. Assim, “sem infraestrutura de certificados” descreve a CGA; a autorização do roteador não é “sem configuração”.

A evolução posterior manteve as duas camadas. RFC 6494 definiu um perfil de certificados SEND baseado em certificados de recursos; RFC 6495 especificou um tipo de nome para campos Subject Key Identifier. Em seguida, RFC 6980 proibiu cabeçalhos de fragmentação IPv6 em mensagens ND e SEND selecionadas, pois a fragmentação podia contornar certos filtros e sistemas de monitoramento. O histórico mostra limites de credenciais e de processamento de pacotes, não adoção em escala nem efeito de segurança mensurado.

A lição de RFC 3971 é menos grandiosa e mais precisa: uma assinatura pode provar o vínculo entre uma chave e um endereço; a autorização de roteador depende de uma raiz aceita pelo host. O protocolo não trata essas evidências como intercambiáveis.