RPKI e as âncoras de confiança

02/06/2022

Por Geoff Huston

Artigo publicado originalmente no blog da APNIC

Muitas vezes me perguntaram por que utilizamos um âmbito de confiança distribuído, no qual cada um dos Registros Regionais da Internet (RIR) publica uma âncora de confiança que reclama a totalidade do espaço numérico da Internet.

Suspeito que a pergunta voltará a surgir no futuro, portanto, creio que é útil registrar aqui as considerações de desenho com a esperança de que possa ser útil para quem tiver a mesma dúvida no futuro.

As âncoras de confiança são as ferramentas que possuem as partes que confiam (ou seja, as pessoas que desejam usar uma infraestrutura de chave pública (PKI) para validar testemunhos assinados digitalmente), para validar todos os artefatos assinados digitalmente nessa PKI. No mundo dos certificados X.509, a validação requer que a parte confiante construa uma cadeia de certificados onde cada elo da cadeia corresponda a uma autoridade de certificação, cuja chave privada tenha assinado o seguinte certificado de chave pública (ou seu subordinado imediato) na cadeia:

Figura 1 – Cadeia de certificados X.509

Esta cadeia de relações emissor/sujeito finaliza com o Certificado de Entidade Final da chave pública, utilizado no certificado digital. No outro extremo desta cadeia há um certificado autoassinado, no qual a parte que aceita está disposta a confiar, quaisquer que sejam as circunstâncias.

Figura 2: Cadeia de certificados X.509 com uma âncora de confiança.

Normalmente, dentro do contexto de uma determinada PKI, as âncoras de confiança estariam amplamente distribuídas. Espera-se que cada parte que confia aprenda estas âncoras de confiança de uma maneira na qual esteja preparada para confiar. Creio que a razão disto tudo é bastante óbvia, mas para ilustrar o que poderia sair mal quando uma parte que confia simplesmente acredita em tudo o que falam, pensemos no seguinte exemplo:  um potencial atacante poderia representar um certificado autoassinado criado para que este ataque seja uma âncora de confiança e apresente à vítima um objeto assinado digitalmente, uma cadeia de certificados e esta suposta âncora de confiança.

Tipicamente, uma âncora de confiança está amplamente distribuída dentro de uma PKI e armazenada localmente no cache por cada parte que confia dentro desta PKI. Por tanto, é melhor que a âncora de confiança de uma PKI seja muito estável e se altere com pouca frequência ou não se altere nunca, já que qualquer alteração deve se propagar entre todas as partes que confiam.

Isto é semelhante à função da chave para assinatura de chaves (KSK) em DNSSEC. Como vimos no exercício recente de alteração de valor da KSK, assegurar-se de que todas as partes que confiam estejam sincronizadas com esta alteração e substituam sua confiança na antiga âncora de confiança por confiança na nova âncora de confiança, é um assunto complicado. Portanto, gostaríamos que as âncoras de confiança fossem estáveis e duradouras, e normalmente alteraríamos o valor da chave da âncora de confiança com pouca frequência ou não a alteraríamos nunca. E se fosse alterada, seria melhor que esta âncora de confiança fosse alterada em momentos previstos e bem indicados para que as partes que confiam possam administrar sua confiança em sincronia com estas alterações.

Agora adicionemos uma consideração a mais sobre a PKI de recursos (RPKI). A âncora de confiança também deve incluir um conjunto de recursos numéricos IP que estejam dentro do “escopo” desta âncora de confiança.  A consequência é que o material de confiança deve ser alterado toda vez que o conjunto associado de recursos numéricos se alterar dentro deste escopo.  Isso vale tanto para os certificados de âncoras de confiança autoassinados quanto para todos os demais certificados RPKI. Se bem as alterações nos valores das chaves podem ser planejadas, as alterações na titularidade dos recursos não são necessariamente tão previsíveis, o que acarreta implicações para as âncoras de confiança do RPKI.

RPKI introduziu um giro sutil na interpretação convencional dos certificados de chave pública X.509.

De maneira informal, uma PKI constrói uma estrutura de confiança transitiva, permitindo que uma parte que confia responda à pergunta: Esta assinatura digital é genuína? Esta pergunta se transforma em outra pergunta rapidamente diferente: A chave pública faz parte do par de chaves que se usa para gerar a assinatura que pertence à parte que afirma ter gerado esta assinatura?

Visto que a parte que faz esta pregunta pode não conhecer a parte assinante ou sua chave pública, a PKI é útil para responder a uma variação desta pergunta: Há pessoas nas quais confio que conheçam a parte assinante e que possam garantir que o par de chaves pertence à parte que afirma ter gerado esta assinatura ou que eles mesmos confiem em outros que possam oferecer esta garantia? Aqui o x da questão é que o papel convencional da PKI tem a ver com as chaves e com a identidade. “Esta é a sua chave?” Esta pergunta é a razão de ser da PKI.

RPKI é diferente.  Não se trata de afirmações de identidade. Trata-se de afirmações de propriedade. Os certificados RPKI X.509 incluem um conjunto de recursos numéricos IP (endereços IP e/ou Números de Sistema Autônomo). A pergunta que o RPKI pretende responder é “Esse é seu endereço?” Não se trata apenas da associação das chaves com a identidade senão das chaves com o controle sobre os recursos IP.

É necessário equilibrar objetivos em conflito. Em teoria, queremos âncoras de confiança estáveis e duradouras, como a KSK para DNSSEC. O problema é que, se alterarmos uma âncora de confiança, todas as partes que confiam devem eliminar suas âncoras de confiança existentes e carregar outras novas. Algumas farão isso, mas igual à nossa experiência com a rotação da KSK, outras não o farão. E, à medida que o RPKI amadurecer e que as implementações das ferramentas das partes que confiam se diversificarem, é muito ingênuo pensar que cada implementação tratará as âncoras de confiança do RPKI como altamente voláteis e verificará de forma permanente se há alterações na âncora de confiança.

Algumas implementações inevitavelmente tratarão a âncora de confiança atual como um valor estático. Por outro lado, se estas partes que confiam tratam a âncora de confiança como volátil, deverão verificar continuamente com o ponto de publicação da âncora de confiança original para ver se há atualizações neste material. Isso faz com que os pontos de publicação das âncoras de confiança sejam um recurso crítico.

Um ataque DDOS em um ponto de publicação de âncora de confiança suporia um risco para todo o RPKI, já que estas partes que confiam e que constantemente estão verificando se há atualizações teriam que inventar coisas porque não conseguiram atingir o ponto de publicação da âncora de confiança. É melhor utilizar âncoras de confiança cujo material seja altamente estável.

A fonte da “verdade” para o RPKI é a coleção de dados dos Registros de Internet. Quando um registro de Internet aloca um bloco de números a um registro subordinado receptor, não apenas se registra essa transação no registro, senão que quando o receptor do endereço envia uma solicitação de assinatura do certificado ao registro “pai”, o registro emitirá um certificado para relacionar o bloqueio de endereços alocados com a chave pública do receptor. A ideia é que isto seja válido para todas as partes do RPKI, desde os certificados raiz até os certificados de entidade final nas “folhas” da hierarquia.

Este modelo de operação implica que o RPKI deve continuar com precisão as ações de alocação de endereços dos registros de Internet. Se isso fosse tudo, seria o final da história.

No entanto, em resposta ao esgotamento dos endereços IPv4, as comunidades regionais de políticas adotaram o conceito de transferências de endereços, tanto para transações dentro de uma mesma região quanto para diferentes regiões. Se bem o RPKI foi desenhado para descrever a alocação hierárquica de endereços mediante certificados, o movimento “horizontal” de endereços IP entre registros apresentou alguns problemas fundamentais para o desenho do RPKI.

Para ver as implicações das transferências na estrutura do RPKI, vejamos a transferência de um endereço entre os RIR desde a perspectiva do RPKI.

O ISP A, uma entidade atendida pelo RIR X, transfere um prefixo de endereços ao ISP B, que é uma entidade atendida pelo RIR Y. O RIR X deverá revogar o certificado que teria emitido ao ISP A e, se o ISP A ainda possuir outros recursos numéricos, deverá emitir um novo certificado para o ISP A com um conjunto reduzido de recursos numéricos. O RIR Y deverá emitir (ou voltar a emitir) seu certificado para o ISP B; o novo certificado deverá incluir o prefixo de endereços transferido.

Figura 3 – cenário de transferência de endereços.

A escolha dos modelos de âncoras de confiança afeta a complexidade deste conjunto de ações sobre os certificados.

Se cada um destes RIR publicar uma âncora de confiança que inclua todos os recursos (um certificado autoassinado ‘0/0’), as ações que implicam a transferência serão bastante simples:

1. O RIR X emite um novo certificado para o ISP A que não contém os recursos transferidos.

2. O RIR X revoga o certificado anterior para o ISP A.

3. O RIR Y emite um novo certificado para o ISP B que contém os recursos transferidos.

4. O RIR Y revoga o certificado anterior para o ISP B.

A consideração da “vitalidade” determina a ordem destas ações. Se desejar permitir que a rede que utiliza este endereço esteja sempre coberta por um certificado RPKI que se possa validar a qualquer momento, o RIR Y primeiro emitirá um novo certificado e a revogação do certificado anterior será o ato final da transferência. Em outras palavras, a sequência anterior seria 3,1,4,2.

O que acontece se cada RIR publica uma âncora de confiança que não enumera 0/0 senão que enumera precisamente os endereços que aparecem apenas em seu registro local? Agora a sequência é um pouco mais complexa, a transferência implica uma alteração nas âncoras de confiança dos RIR que participam na transferência:

1. O RIR Y emite uma nova âncora de confiança que inclui os recursos para transferir.

2. O RIR Y emite um novo certificado para o ISP B que contém os recursos para transferir.

3. O RIR X emite um novo certificado para o ISP A que não contém os recursos transferidos.

4. O RIR Y revoga o certificado anterior para o ISP B.

5. O RIR X revoga o certificado anterior para o ISP A.

6. O RIR X emite uma nova âncora de confiança que não contém os recursos transferidos.

O processo anterior é frágil em muitos sentidos. As ações dos RIR estão em uma ordem particular, mas não acontece o mesmo com as ações das partes que confiam.  O que poderia acontecer se uma parte que confia não vê a âncora de confiança alterada para o RIR Y, mas primeiro toma o novo certificado para o ISP B? Desde a perspectiva da parte que confia, esse certificado não é válido porque não está “coberto” pela âncora de confiança do RIR Y.

Para que este processo seja mais sólido é necessário introduzir delongas, a fim de permitir que as partes que confiam se mantenham em dia, e estas delongas devem ser medidas em dias e não em horas. O que segue é um processo alterado:

1. O RIR Y emite uma nova âncora de confiança que inclui os recursos a serem transferidos.

2. Espera.

3. O RIR Y emite um novo certificado para o ISP B que contém os recursos a serem transferidos.

4. O RIR X emite um novo certificado para o ISP A que não contém os recursos transferidos.

5. O RIR Y revoga o certificado anterior para o ISP B.

6. Espera

7.  O RIR X revoga o certificado anterior para o ISP A.

8. O RIR X emite uma nova âncora de confiança que não contém recursos transferidos.

Estão sendo produzidas muitas transferências; e não há dúvidas de que as transferências se intensificarão no futuro, portanto este processo de oito passos poderá ser executado muitas vezes em paralelo. Isto implica que as âncoras de confiança para os RIR estariam em um estado de alteração constante e que as partes que confiam teriam que consultar frequentemente estes pontos de publicação de âncoras de confiança para garantir de que a cópia da âncora de confiança armazenada em um cache local esteja atualizada.

A alternativa é que cada RIR utilize uma âncora de confiança que contenha um conjunto de recursos 0/0. Desta forma, as alterações nas âncoras de confiança estariam limitadas a alterações no material das chaves, algo que se pode gerir de uma forma muito mais controlada.

A conclusão é que, se cada um dos RIR publica uma âncora de confiança, então o uso de um conjunto de recursos 0/0 nestas âncoras permite estabilidade neste material, de modo que as partes que confiam não tenham que verificar constantemente o estado de sua raiz de confiança. Outros enfoques para abordar um conjunto de âncoras de confiança baseadas nos RIR são mais frágeis.

A outra alternativa é que os RIR não publiquem suas próprias âncoras de confiança. Este caminho alternativo prevê que a IANA publique uma âncora de confiança única para todo o RPKI. Este enfoque foi o ponto de partida no desenho do RPKI.

Possuir uma âncora de confiança 0/0 assinada pela IANA tem suas vantagens. É estável, duradoura e pode gerir de forma segura. Todos estes são atributos desejáveis para uma âncora de confiança.

A pesar disso, surge a pergunta: O que os certificados emitidos pela IANA, para cada RIR, possuem?

A resposta convencional é a mesma que utilizam os RIR no RPKI, ou seja, que o RPKI é um reflexo exato do conteúdo atual do registro. Um certificado RPKI não se inventa, baseia-se no conteúdo do registro. Como consequência, os certificados emitidos pela IANA estariam baseados na informação do registro da IANA referentes aos recursos designados, para serem geridos por cada RIR.

Neste contexto, vejamos mais uma vez a transferência de recursos do ISP A para o ISP B. Está envolvida a CA da IANA nesta transferência?

Um enfoque é que os certificados da IANA que certificam o RIR X e o RIR Y devem ser alterados para refletir esta transferência, deslocando o recurso do certificado do RIR X para o RIR Y (Figura 4).

Figura 4 – Transferência de endereços com certificados da IANA.

Esta transferência não está no registro de números da IANA, já que o registro da IANA registra apenas as alocações da IANA para os RIR e as ações de reserva por parte do IETF. Este enfoque implica que a IANA emitirá um certificado onde os conteúdos contradiriam o registro da IANA.

Isso pode ser solucionado instituindo um novo processo operativo no qual a IANA processe todas as transferências entre diferentes RIR e os registros da IANA se atualizem para refletir a disposição atual de todos os recursos transferidos. Esta proposta propõe um conjunto de perguntas relacionadas com as políticas, já que coloca a IANA em uma posição de “aprovar” todas e cada uma das transferências de endereços para ingressá-las no registro da IANA.

Também propõe a pergunta: “O que é o registro da IANA?” Já que não representaria um registro confiável e preciso das ações de alocação da IANA no passado, mas sim um resumo de transações informadas por outras partes à IANA. Supostamente, os registros criariam uma forma segura e autenticada de informar à IANA, de uma maneira que não possa ser repudiada e que provavelmente seja genuína em ambos os lados da transferência, e estas provas devem ser verificáveis por qualquer pessoa.  No entanto, a observação básica continua sendo que a IANA já não registra suas próprias ações, senão que age como um registro das ações realizadas por outros registros.

Minha reação perante este possível modelo é que o problema mais difícil para os RIR não seriam as considerações operativas para executar tais transações de forma confiável a todo momento, mas sim a questão das políticas. É difícil compreender como as comunidades dos RIR aceitariam colocar a IANA em um papel que essencialmente supervisasse e devesse, tacitamente, dar sua aprovação a cada micro ação que é uma transferência de endereços. O que aconteceria se a IANA alguma vez desaprovasse e se negasse a processar uma transação de endereços propostos por dois RIR?

Se este não é um acordo aceitável, então a pergunta seguinte seria como excluir a IANA do ciclo.

A alternativa é que a IANA emita certificados a cada RIR que sejam uma réplica exata das ações de alocações históricas descritas no registro existente da IANA. Quando os ISP A e B realizarem sua transferência, a IANA não estará envolvida e os certificados da IANA para os RIR X e Y não poderão se alterar. A IANA não realizou a transferência, portanto não terá motivos para realizar alterações no seu registro.

Levando em conta estas restrições, como é possível certificar os recursos transferidos? O único caminho possível é que o RIR X certifique o RIR Y para os recursos, e que o RIR Y certifique o ISP B, utilizando estes certificados: um para os recursos cuja alocação seguiu o caminho IANA > RIR Y > ISP B e um segundo certificado para aqueles cuja alocação foi IANA > RIR X > RIR Y > ISP B. Estes dois certificados não se podem fusionar.

Figura 5 – Transferência com certificados inter-RIR

O que pode acontecer se o ISP B transfere posteriormente todos os seus recursos ao ISP C, uma entidade atendida pelo RIR Z? Já não seria assunto do RIR X e realmente não deveria estar na posição de ter que “aprovar” esta transação, visto que não tem relação com nenhuma das partes desta transação posterior.

Se quisermos apenas realizar esta segunda transação entre o RIR e o RIR Z, então o ISP C será o sujeito de um certificado cuja rota de validação será IANA > RIR X > RIR Y > RIR Z > ISP C, será também o sujeito de um segundo certificado cuja rota de validação será IANA > RIR Y > RIR Z > ISP C. Novamente, estes dois certificados não podem ser fusionados.

À medida que forem realizadas mais transferências, a estrutura dos certificados adquire uma complexidade cada vez maior. O resultado é que a alternativa à inclusão de uma âncora de confiança da IANA em cada micro transferência é uma situação na qual o sistema de certificação RPKI se torna extraordinariamente complexo muito rapidamente, e os titulares de recursos poderão possuir uma grande coleção de certificados para descreverem seus endereços, mesmo que o titular já tenha registrado todos os seus endereços em um único RIR.

Não parece tão ruim, verdade? Enquanto estes certificados puderem ser validados e não se contradigam entre si, tudo estará bem, certo? Pelo menos do ponto de vista técnico, sem importar a possível carga operativa, tudo estaria bem, não é mesmo? Qual seria o problema?

Queríamos um sistema que aumentasse o registro com chaves digitais. A posse de uma chave privada permitia ao titular de um recurso dizer: “Esse é meu recurso e meu RIR validará minha assinatura digital se eu assinar um testemunho digital a tal efeito”. É uma versão “forte” da ferramenta whois.

Queríamos um sistema de certificação de chave pública X. 509 que ordenasse alterações na estrutura do RIR ou alterações no modelo IANA/RIR. Para conseguir este resultado muito simples e não aceitar um conjunto de externalidades que introduzam complexidade e fragilidade, ou que introduzam alterações no panorama de políticas e organizacional entre os RIR e entre os RIR e a IANA, o espaço de decisão sobre como desenhar a confiança no RPKI é um espaço muito restringido.

Se quisermos evitar âncoras de confiança altamente voláteis e evitar a crescente complexidade na emissão e administração de certificados, e se além disso quisermos evitar reescrever o âmbito de políticas da relação entre os RIR e a IANA, a única opção que resta é usar uma âncora de confiança para que cada RIR emita uma âncora de confiança autoassinada com um conjunto de recursos 0/0. Todos os demais modelos convencionais criam complexidade e fragilidade adicionais; além disso, alguns modelos requerem uma reelaboração das funções e o âmbito da IANA/RIR. Uma tarefa que ninguém parece querer sequer

Essa é a razão pela qual os RIR utilizam um conjunto de âncoras de confiança de certificados autoassinados 0/0 baseados nos RIR. Dadas as limitações da estrutura dos certificados X.509 e as limitações do entorno organizativo no qual opera o sistema de gestão de recursos, não há outra opção de desenho possível disponível.

Suscríbete para recibir las últimas novedades en tu mail Click here to subscribe receive the latest news in your inbox. Inscreva-se aqui para receber as últimas novidades no seu e-mail