Como funciona a infraestrutura de chaves públicas de recursos

A verificação exige elementos de prova atualizados: certificados, permissões e sistemas de publicação têm de manter a coerência à medida que as redes mudam.

Transfere um serviço para uma nova rede. Os servidores funcionam normalmente e os endereços não mudaram, mas alguns visitantes deixam de conseguir aceder-lhe. Uma das causas possíveis é um pormenor surpreendentemente pequeno: os registos de encaminhamento da Internet continuam a autorizar a antiga rede a anunciar esses endereços.

A RPKI transforma essa permissão em algo que outras redes podem verificar. Vejamos como passa do titular dos endereços até ao router — e por que razão Lu Heng defende que manter este mecanismo em funcionamento nunca deve depender da permanência de um administrador no poder. Para uma introdução mais breve, comece por o que a RPKI protege.

1. Determinar quem pode autorizar a utilização dos endereços

Um conjunto de endereços IP designa-se por prefixo. Uma rede que anuncia esse prefixo identifica-se através de um número de sistema autónomo, ou ASN. A RPKI, a infraestrutura de chaves públicas de recursos, utiliza certificados para determinar quem pode emitir autorizações relativas a determinados intervalos de endereços.

Esses certificados formam uma cadeia que remonta a uma raiz de confiança. A hierarquia acompanha a atribuição de recursos numéricos da Internet, conforme descrito na RFC 6480. Fornece provas relativas aos recursos dentro desse sistema; não confere a uma autoridade de certificação um mandato político sobre as pessoas que utilizam a Internet.

2. Publicar uma permissão assinada

O titular dos endereços publica uma autorização de origem de rota, ou ROA. A mensagem é específica: este ASN pode ser a origem deste prefixo. Ser a origem significa ser a rede no início da rota anunciada, não todas as redes que transportam o tráfego a seguir.

Uma ROA também pode definir um comprimento máximo de prefixo: até que ponto o intervalo de endereços pode ser dividido em intervalos mais pequenos que sejam anunciados. Sem essa definição opcional, permite apenas o comprimento de prefixo indicado. Isto impede que a «permissão para este intervalo» se transforme, sem o explicitar, numa permissão para todas as subdivisões possíveis. A RFC 9582 define o registo assinado.

3. Transformar os registos publicados em dados verificados

Os registos assinados são disponibilizados em repositórios de publicação. O software de validação recolhe-os e verifica a cadeia de certificados, as assinaturas, os prazos de validade e as informações de revogação, juntamente com os manifestos que descrevem os objetos publicados. Um ficheiro legível, por si só, não basta: os elementos de prova que o sustentam também têm de passar a validação.

O validador produz dados de autorização utilizáveis, frequentemente designados por conteúdos validados de ROA, ou VRP. Estes contêm o prefixo, o ASN de origem autorizado e o comprimento máximo. Os routers recebem os resultados de uma cache de confiança através do protocolo RPKI-to-Router, descrito na RFC 8210. Não pedem autorização a uma entidade de registo sempre que um visitante abre uma página.

4. Comparar a rota com a permissão

O BGP é o protocolo através do qual as redes anunciam rotas. Um router que recebe uma rota compara o respetivo prefixo e ASN de origem com os dados de autorização validados de que dispõe. Trata-se da validação da origem de rotas, ou ROV.

Válido (Valid): uma autorização que abrange o prefixo permite tanto a origem como o comprimento de prefixo. Inválido (Invalid): existem autorizações que abrangem o prefixo, mas nenhuma permite essa combinação. Não encontrado (NotFound): nenhuma autorização abrange o prefixo. Estes são resultados de uma comparação, não juízos sobre as intenções de alguém. O operador decide como os utiliza na sua política de encaminhamento. Consulte a RFC 6811.

Voltemos à transferência do serviço. Se o antigo ASN continuar autorizado e o novo não estiver, o novo anúncio pode ter o resultado Invalid. As redes que filtram rotas Invalid podem rejeitá-lo. A solução é coordenar a alteração da autorização com a transferência, incluindo qualquer período em que ambas as redes precisem de permissão — e não presumir que servidores a funcionar normalmente garantem a acessibilidade. A RFC 7115 aborda as precauções operacionais.

5. Manter toda a cadeia em funcionamento

A validação da origem ajuda a rejeitar falsas declarações de origem. Não verifica cada salto, não cifra o tráfego nem deteta todas as fugas de rotas. Uma fuga pode conservar uma origem autorizada. Continuam a ser necessárias outras proteções do encaminhamento.

Os elementos de prova também precisam de manutenção. Os certificados expiram; as permissões e os dados de publicação mudam. A remoção de uma ROA não tem necessariamente de causar uma interrupção imediata: o resultado da validação que vier a verificar-se depende dos restantes registos disponíveis, e a consequência para o encaminhamento depende da política local. A RFC 8211 analisa de que forma os erros ou as ações prejudiciais das autoridades de certificação e dos 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 contesta uma conclusão habitual: como o serviço de registo é essencial, o seu operador atual tem de ser insubstituível. As redes precisam de registos exatos e de mecanismos de segurança que funcionem. Isso não estabelece um direito permanente de uma instituição a controlá-los.

A alternativa que propõe faz da continuidade uma propriedade do sistema: registos que possam ser auditados de forma independente, uma passagem de responsabilidades testada para um sucessor qualificado e uma forma de transferir a administração sem obrigar as redes a mudar de endereços. Reconhece explicitamente que a RPKI não pode ser transferida através da simples cópia de um diretório. As chaves, os certificados, a publicação e a confiança têm de manter a coerência durante toda a transição.

Trata-se de um requisito de conceção que defende, não de uma afirmação de que essa portabilidade já está disponível em todo o lado. A proposta aborda os dois lados do problema: uma substituição descuidada pode perturbar a verificação; um administrador insubstituível que controla o acesso pode transformar essa dependência em poder. A fiabilidade do serviço e a possibilidade de substituir o seu administrador têm de ser concebidas em conjunto.

Porquê criar essa capacidade antes de uma crise?

Quando um conflito chega à cadeia de certificados, pode afetar pessoas muito para além das partes envolvidas. Os clientes não escolheram o conflito, mas podem suportar o custo das perturbações na conectividade. Um processo de sucessão improvisado durante uma interrupção chega já demasiado tarde para os proteger dessa incerteza.

Lu Heng defende que a continuidade e o direito de sair sejam estabelecidos antecipadamente, impedindo que os conflitos administrativos se tornem uma arma contra redes em funcionamento. Acompanhe o argumento completo na Nota 70: proteger o registo, não quem controla o acesso.