Como funciona a Infraestrutura de Chaves Públicas de Recursos
Acompanhe uma autorização RPKI do detentor dos endereços até o roteador e entenda por que Lu Heng defende um serviço confiável cujo administrador possa ser substituído.
A verificação exige evidências mantidas em dia: certificados, permissões e sistemas de publicação precisam permanecer coerentes à medida que as redes mudam.
Você transfere um serviço para uma nova rede. Os servidores funcionam normalmente, os endereços não mudaram, mas alguns visitantes já não conseguem acessá-lo. Uma possível causa é surpreendentemente pequena: os registros de roteamento da Internet ainda autorizam a rede antiga a anunciar esses endereços.
A RPKI transforma essa permissão em algo que outras redes podem verificar. Veja como ela vai do detentor dos endereços até um roteador — e por que Lu Heng argumenta que manter esse mecanismo funcionando jamais deve depender de manter um administrador no poder. Para uma introdução mais breve, comece por o que a RPKI protege.
1. Estabelecer quem pode autorizar o uso dos endereços
Um conjunto de endereços IP é chamado de prefixo. Uma rede que anuncia esse prefixo se identifica por um número de sistema autônomo, ou ASN. A RPKI, Infraestrutura de Chaves Públicas de Recursos, usa certificados para estabelecer quem pode emitir autorizações para determinadas faixas de endereços.
Esses certificados formam uma cadeia que remonta a uma raiz de confiança. A hierarquia acompanha a alocação de recursos de numeração da Internet, conforme descrito na RFC 6480. Ela fornece evidências sobre os recursos dentro desse sistema; não confere a uma autoridade certificadora um mandato político sobre as pessoas que usam a Internet.
2. Publicar uma permissão assinada
O detentor dos endereços publica uma Autorização de Origem de Rota, ou ROA. Sua mensagem é específica: este ASN pode originar este prefixo. Originar significa ser a rede no início da rota anunciada, não cada uma das redes que transportam o tráfego depois.
Uma ROA também pode definir um comprimento máximo de prefixo: até que ponto a faixa de endereços pode ser dividida em faixas menores anunciadas. Sem essa configuração opcional, ela permite apenas o comprimento de prefixo especificado. Isso impede que uma “permissão para esta faixa” se transforme, silenciosamente, em permissão para todas as subdivisões possíveis. A RFC 9582 define esse registro assinado.
3. Transformar os registros publicados em dados verificados
Os registros assinados são disponibilizados em repositórios de publicação. Um software de validação os coleta e verifica a cadeia de certificados, as assinaturas, as informações de validade e revogação, juntamente com os manifestos que descrevem os objetos publicados. Um arquivo legível, por si só, não basta: as evidências que o sustentam também precisam passar pela validação.
O validador produz dados de autorização utilizáveis, frequentemente chamados de conteúdos validados de ROA, ou VRPs. Eles contêm o prefixo, o ASN de origem permitido e o comprimento máximo. Os roteadores recebem os resultados de um cache confiável pelo protocolo RPKI-to-Router, descrito na RFC 8210. Eles não pedem permissão a uma entidade de registro cada vez que um visitante abre uma página.
4. Comparar a rota com a permissão
O BGP é o protocolo pelo qual as redes anunciam rotas. Um roteador que recebe uma rota compara seu prefixo e seu ASN de origem com as autorizações validadas de que dispõe. Esse processo é a Validação de Origem de Rota, ou ROV.
Valid (válido): uma autorização que abrange o prefixo permite tanto a origem quanto o comprimento do prefixo. Invalid (inválido): existem autorizações que abrangem o prefixo, mas nenhuma permite essa combinação. NotFound (não encontrado): nenhuma autorização abrange o prefixo. Esses são resultados de uma comparação, não veredictos sobre as intenções de alguém. O operador decide como utilizá-los na política de roteamento. Consulte a RFC 6811.
Voltemos à transferência do serviço. Se o ASN antigo ainda estiver autorizado e o novo não, o novo anúncio pode ser classificado como Invalid. Redes que filtram rotas Invalid podem rejeitá-lo. A solução é coordenar a mudança de autorização com a transferência, incluindo qualquer período em que as duas redes precisem de permissão — e não presumir que servidores funcionando normalmente garantem a acessibilidade. A RFC 7115 trata dos cuidados operacionais.
5. Manter toda a cadeia funcionando
A validação de origem ajuda a rejeitar declarações falsas de origem. Ela não verifica cada salto, não criptografa o tráfego nem detecta todo vazamento de rotas. Um vazamento pode manter uma origem autorizada. Outras proteções de roteamento continuam sendo necessárias.
As evidências também precisam de manutenção. Certificados expiram; permissões e dados de publicação mudam. Remover uma ROA não necessariamente provoca uma interrupção imediata: o resultado final da validação depende dos outros registros disponíveis, e a consequência para o roteamento depende da política local. A RFC 8211 examina como erros ou ações prejudiciais de autoridades certificadoras e operadores de repositórios podem afetar o sistema.
A proposta de Lu Heng: preservar o serviço, substituir o administrador
Na Nota 70, Lu Heng questiona uma conclusão recorrente: como um serviço de registro é essencial, seu operador atual deve ser insubstituível. As redes precisam de registros precisos e de mecanismos de segurança que funcionem. Isso não estabelece o direito permanente de uma instituição de controlá-los.
A alternativa que ele propõe faz da continuidade uma propriedade do sistema: registros sujeitos a auditoria independente, uma transição testada para um sucessor qualificado e uma forma de transferir a administração sem obrigar as redes a mudar seus endereços. Ele reconhece explicitamente que a RPKI não pode ser transferida com a simples cópia de um diretório. Chaves, certificados, publicação e confiança precisam permanecer coerentes durante toda a transição.
Trata-se de um requisito de projeto que ele defende, não de uma afirmação de que essa portabilidade já esteja disponível em toda parte. A proposta enfrenta os dois lados do problema: uma substituição descuidada pode comprometer a verificação; um administrador insubstituível que controla o acesso pode transformar essa dependência em poder. A confiabilidade do serviço e a possibilidade de substituir seu administrador precisam ser concebidas em conjunto.
Por que desenvolver essa capacidade antes de uma crise?
Quando uma disputa chega à cadeia de certificados, ela pode afetar pessoas muito além das partes envolvidas. Os clientes não escolheram o conflito, mas podem arcar com o custo da interrupção da conectividade. Um processo de sucessão improvisado durante uma indisponibilidade já chega tarde demais para protegê-los dessa incerteza.
Lu Heng defende que a continuidade e o direito de saída sejam estabelecidos com antecedência, impedindo que disputas administrativas se tornem uma arma contra redes em funcionamento. Acompanhe o argumento completo na Nota 70: proteja o registro, não quem controla o acesso.