RPKI
Introdução
RPKI (Resource Public Key Infrastructure) é a especificação de uma tecnologia discutida e proposta pelo IETF (Internet Engeenering Task Force), RFC 6480, que permite a validação de anúncios de rotas via protocolo BGP.
Essa tecnologia faz uso de Certificados Digitais (PKI), e de uma cadeia de certificação para validar a alocação de um conjunto de Recursos de Numeração Internet feita por um RIR/NIR a uma organização.
À organização titular de alocações de Recursos de Numeração Internet é emitido um Certificado Digital segundo padrão X.509 com uma extensão específica onde estarão listados os recursos alocados a essa organização.
Certificados Digitais X.509 contém uma série de informações e também uma chave pública utilizada para validar autenticidade de objetos que tenham sido assinados criptograficamente com a chave privada que seja seu par (sistema de chaves públicas/privadas).
Um dos objetos a ser assinado com a referida chave privada se chama ROA (Route Origin Authorization), e que contém uma lista de blocos IPv4 e/ou IPv6 e um ASN que está autorizado a originar rotas para os referidos blocos.
As ROAs são então publicadas em repositórios e poderão ser utilizadas para validar que uma determinada rota para um bloco IP, recebida através do protocolo BGP, está sendo originada pelo ASN autorizado pelo detentor da alocação do bloco IP em questão.
Essa validação é feita seguindo a cadeira de verificação criptográfica de assinaturas e certificados Digitais.
Inicialmente valida-se que a rota em análise está condizente com a informação da ROA. Em seguida, valida-se a assinatura dessa ROA comparando com a chave pública do certificado que gerou tal assinatura.
Feito isso, há que validar toda a cadeia de assinaturas até que se chegue a um certificado considerado "Raiz de Confiança" (Trust Anchor).
Nesse processo verifica-se também que os blocos IP encontrados na ROA estão nas extensões de todos os certificados validados.
Dessa forma cria-se um mecanismo para evitar uso indevido de blocos de endereços IP ou "sequestros", que é quando através de um ASN se origina rotas para blocos IP alocados para outras organizações que não aquela responsável pelo ASN.
Hierarquia
Em uma infraestrutura certificação digital de chaves públicas há uma hierarquia que é "percorrida" em processos de validação.
O topo da hierarquia é chamado de "Raiz de Confiança", ou Trust Anchor em inglês. E nada mais é que um certificado digital "auto-assinado".
E esse certificado é instalado em sistemas que fazem as validações.
Um exemplo mais usual são os navegadores web que vem com uma série de certificados "Raiz" pré instalados.
No caso do RPKI há 5 certificados "Raiz", uma para cada Registro Internet (RIR).
As chaves privadas, associadas as esses certificados Raiz, são utilizadas para assinar digitalmente outros certificados.
De uma forma simplificada, um RIR ao fazer uma alocação gera um certificado digital para a organização que a recebe e assina esse certificado com a chave privada que é par da chave pública contida no certificado Raiz desse RIR.
A organização, titular de uma alocação, pode utilizar a chave privada associada ao certificado que recebeu para assinar outros certificados e outros objetos.
E com isso cria-se uma hierarquia que será seguida sempre que algum objeto assinado criptograficamente tiver que ser validado.
O agente emissor de um certificado é denominado C.A, do inglês "Certificate Authority". E existem alguns critérios a serem seguidos, como por exemplo, o cuidado para proteger e controlar o acesso às chaves privadas utilizadas para assinar certificados ou outros objetos.
No sistema RPKI alguns RIRs oferecem às organizações, que recebem alocação, um serviço de C.A. "hospedado" onde as chaves privadas são geradas e mantidas pelo RIR internamente em sua infraestrutura.
Em um outro modelo, que é o adotado pelo Registro.br, a C.A. fica sob resposabilidade da organização que recebe a alocação. Esse modelo é denominado "delegado".
Nesse modelo a organização deve instalar um sistema de certificação e seguir alguns procedimentos descritos a seguir para fazer a inicialização da cadeia de certificação e assim criar a hierarquia mencionada acima.
Repositórios
Na infraestrutura RPKI faz-se necessário a validação de uma série de certificados digitais e outros objetos, como por exemplo ROAs.
Esse processo de validação faz uso de diversos certificados digitais e outros objetos que são publicados em repositórios na Internet.
No modelo de C.A. "delegado" há a opção de usar um sistema de repositório do próprio Registro.br ou então um outro mantido pela organização que venha a operar a C.A.
No procedimento de inicialização da C.A e da configuração da interface com o sistema do Registro.br será necessário indicar qual sistema de repositório se deseja utilizar.
Não há nenhuma obrigatoriedade em utilizar o sistema de repositório oferecido pelo Registro.br às organizações que tenham alocação de recursos Internet e que habilitem RPKI.
No entanto, é importante destacar que o acesso aos repositórios deve estar sempre disponível e de forma ilimitada. E isso deve ser levando em consideração caso a escolha da organização seja manter um repositório na sua própria infraestrutura.
Inicialização
Antes de habilitar RPKI para as alocações feitas pelo Registro.br, a organização deve instalar o sistema de C.A. em sua infraestrutura.
O Registro.br está configurado para utilizar a C.A. desenvolvida pelo NLNETLABS chamada de Krill.
No site do desenvolvedor há informações sobre processo de instalação e configuração. Além disso, há um tutorial apresentado pelo NIC.br disponível aqui.
Importante ter ciência que o sistema C.A. (Krill), instalado na infraestrutura da organização que habilite RPKI, deve permanecer ativo e disponível para que a publicação de certificados e outros documentos criptográficos não seja impactada.
Após a instalação e configuração inicial da C.A (Krill), será necessário criar a hierarquia de certificação junto ao Registro.br.
Mas antes de habilitar RPKI junto ao Registro.br, é importante a execução de alguns comandos no sistema Krill instalado na infraestrutura local da organização. Os comandos listados a seguir referem-se a CLI da versão 0.5.0 do Krill.
O primeiro comando, passo 1, é para gerar uma mensagem XML contendo instruções para o estabelecimento da comunicação segura, denominada "up/down", entre o Registro.br e o sistema C.A. (Krill) da organização. Essa inicialização segue a especificação descrita na RFC 8183.
Os exemplos de comandos abaixo fazem referencia a "SENHA" e "NOME C.A." que são parametros de configuração que devem ser definidos após a instalação do Krill no seu arquivo de configuração.
Esse comando gera uma mensagem XML denominada "Child Request":
"$ krillc parents request --server https://localhost:3000/ --token [SENHA] --ca [NOME C.A.]"
O resultado desse comando deve ser copiado em algum editor de texto ou gravado em arquivo e será necessário nos processos seguintes.
Em seguida é necessário executar um outro comando, passo 2, na C.A (Krill) da organização mas somente se a opção for para utilização do repositório do Registro.br
"$ krillc repo request --server https://localhost:3000/ --token [SENHA] --ca [NOME C.A.]"
O resultado desse comando será uma mensagem XML ("publisher request") que também dever ser copiada ou gravada em um arquivo pois será necessária nos próximos passos do processo.
Em seguida é necessário solicitar a configuração do RPKI junto ao Registro.br e para isso o usuário responsável pelo ID administrativo da organização deve conectar-se ao sistema do Registro.br e depois clicar em TITULARIDADE e em seguida no nome da organização para a qual se deseja habilitar RPKI.
Na página seguinte, ir até o final até a opção "RPKI - Configurar RPKI".
O sistema então solicitará a entrada de um certificado digital para estabelecer uma comunicação segura (Up-Down), entre a C.A do Registro.br e a da organização. Essa informação está contida na mensagem XML resultado do primeiro comando, passo 1, descrito acima. E deve ser copiada no campo "Child Request"
Em seguida, após haver copiado as informações no formato XML no campo indicado, clicar em "Habilitar RPKI".
Após a confirmação, o sistema indicará se houve ou não sucesso e em caso afirmativo haverá um resposta, também no formato XML, identificada como "Parent Response". O passo 3 é copiar ou gravar em um arquivo essa mensagem XML para inserção na C.A. da organização em um passo posterior.
Mas antes de concluir o processo, e caso a opção seja por utilizar o sistema de repositório do Registro.br, há que executar o seguinte passo ainda no sistema do Registro.br:
Ainda na mesma página citada anteriormente e após clicar em "Configurar Publicação Remota" um campo denominado "Publisher Request" aparecerá.
É nesse campo que se deve inserir a outra mensagem XML obtida no passo 2.
Deve-se então clicar em "Habilitar Publicação Remota".
Feito isso, o sistema do Registro.br apresentará um outro XML denominado "Repository Response". O passo 4 é copiar ou gravar em arquivo esse XML para uso em um passo posterior.
Os passos a seguir serão executados no sistema C.A. (Krill) da organização.
É importante seguir a ordem indicada abaixo para a correta configuração. Basicamente, o primeiro passo é para indicar ao sistema C.A (Krill) da organização que o repositório a ser utilizado é o do Registro.br, caso seja essa opção. E em seguida é a confirmação do protocolo “up/down”.
O primeiro comando é a importação do XML “Repository Response”, obtido no passo 4, e para isso é necessário executar o seguinte comando:
"$ krillc repo configure --response [ARQUIVO XML COM REPOSITORY RESPONSE] --server https://localhost:3000/ --token [SENHA] --ca [NOME C.A.]"
* caso a opção da organização seja utilizar um repositório local na sua infraestrutura o passo acima pode ser ignorado; mas importante lembrar que esse repositório local deve estar disponível o tempo todo e acessível publicamente.
Em seguida deve ser feita a importação do "Parent Response" que está na mensagem XML obtida no passo 3.
Para isso, executar o seguinte comando:
"$ krillc parents add --response [ARQUIVO XML COM PARENT RESPONSE] --parent nicbr_ca --server https://localhost:3000/ --token [SENHA] --ca [NOME C.A.]"
Publicação de ROAs
Após execução dos comandos indicados acima para habilitar RPKI, a organização estará pronta para emitir e publicar suas ROAs.
Como ROAs, Certificados e outros documentos que fazem parte do sistema RPKI têm validade e devem ser publicados com certa periodicidade, é importante que o sistema C.A (Krill), instalado na infraestrutura da organização, esteja sempre ativo e operacional.
A falha na publicação periódica de qualquer material parte do RPKI impactará a validação das rotas dos blocos dessa organização.
E para que a organização se beneficie das proteções previstas quando do uso de RPKI não basta somente habilitar seu uso, mas ainda mais importante é criar e publicar ROAs.
Como mencionado, ROAs são atestados de autorização de anúncio de blocos IP com origem em um determinado ASN.
Nesses atestados é possível indicar também qual prefixo máximo que o anúncio de bloco IP pode conter. Por exemplo, uma organização pode indicar que um bloco IPv4 pode ser anunciado com o prefixo /22 mas também até um máximo /24. Como o que terá flexibilidade de alterar os anúncios desse bloco para atender alguma necessidade de anúncios mais específicos.
Para gerar um ROA é necessário executar alguns comandos, mas antes deve-se criar um arquivo texto contento informações do bloco IP, prefixos e ASN autorizado a anuncia-lo.
A sintaxe do arquivo segue a sintaxe abaixo:
A: 192.168.0.0/22-24 => 1234
Essa linha adiciona uma ROA para o bloco IP 192.168.0.0 permitindo anuncio de prefixos entre /22 e /24 com origem no ASN 1234.
O mesmo arquivo pode conter instruções para outros blocos, desde que sejam aqueles alocados para essa organização, como por exemplo:
A: 2001:db8::/32 => 1234
Em seguida, será necessário executar o seguinte comando no sistema C.A. (Krill) para publicação dessa ROA:
"$ krillc roas update --server https://localhost:3000/ --token [SENHA] --ca [NOME C.A.] --delta [NOME DO ARQUIVO CONTENTO AS INSTRUÇÕES]
Validação
Para se ter total benefício da tecnologia RPKI, é altamente recomendável que se faça a validação das rotas recebidas pela organização de seus provedores de transito Internet.
Com isso há segurança de que as rotas aprendidas, e que tenham ROAs publicadas, são de fato anunciadas pelo titular das alocações dos blocos IP em questão.
Diversos roteadores já têm suporte a RPKI e permitem com isso aplicar políticas de filtros com base na validação RPKI.
As validações são feitas em sistemas externos aos roteadores, denominados validadores. E o resultado dessas validações são então repassados aos roteadores através de um protocolo denominado "RPKI to Router" (RtR).
A NLNETLABS também possui uma implementação de validador de uso livre chamado de "Routinator".
Instruções sobre como configura-lo e executá-lo podem ser obtidas no tutorial e também nas documentações do desenvolvedor.
O processo de execução do "Routinator" é bem simples e se resume ao comando:
"$ routinator init --accept-arin-rpa"
A opção utilizada é para aceitar os termos de uso do "Trust Anchor" do ARIN.
Isso fará com o que o validador percorra as hierarquias de cada um dos "Trust Anchors" e crie um cache com todos os certificados digitais e demais documentos, como ROAs, publicados. O que pode levar um certo tempo.
Uma vez terminado o processo já é possível fazer algumas verificações das informações contidas no cache local e também configurar o "RtR" com o roteador.
No "Routinator" o comando a ser executado é o seguinte:
"$ routinator server --rtr <IPv4>:<porta> --rtr [<IPv6>]:<porta>"
O endereços IPv4 e IPv6 mencionados são os do roteador no qual se deseja validar rotas via RPKI.
Para configuração dos roteadores, recomenda-se verificar o manual específico.
O tutorial acima mencionado contém alguns exemplos de configuração em alguns dos modelos mais utilizados de roteadores.
Suporte
Como indicado, é importante que os passos sejam seguidos para correta habilitação do sistema de RPKI e também que o sistema C.A. (Krill) da organização seja mantido ativo para publicação periódica dos documentos e certificados.
Além disso, caso a opção seja por uso de um repositório local na infraestrutura da organização, esse deve ser publicamente acessível e disponível o tempo todo.
A não observância desses pontos pode ocasionar problemas como, por exemplo, os softwares validadores RPKI passarem a alertar sobre erros relacionados aos recursos de numeração associados, ou mesmo a indisponibilidade dos arquivos de ROAs.
Para reduzir estes problemas, o Registro.br conta um monitoramento contínuo de seu repositório e, em caso de necessidade de intervenção, alerta os responsáveis das organizações.
Atualmente a monitoração contempla:
- Validação da configuração inicial RPKI, tais como
- Verifica se o arquivo de manifesto dessa entidade está próximo a ficar obsoleto analisando o campo "NextUpdate". Um aviso "Publicação prestes a ficar obsoleta" é emitido 7 (sete) horas antes do momento esperado para a publicação do próximo manifesto. Após essa data limite, e não sendo publicado um novo arquivo manifesto, um novo aviso é enviado com "Publicação RPKI em atraso".
- Verifica se o certificado que assina os objetos RPKI não está expirado. Apesar do Registro.br emitir este certificado, é necessário que o sistema C.A. (Krill) da organização esteja ativo e publicando seus objetos.
Ocorrendo qualquer um dos eventos acima, o administrador da organização é notificado por e-mail, com detalhes dos problemas encontrados.
A partir deste e-mail, é necessário sanar os problemas em até 5 (cinco) dias corridos. Um novo e-mail será enviado quando os problemas forem sanados.
Caso o problema não seja resolvido nesse prazo, a configuração RPKI é removida e o administrador da organização é notificado por email. O RPKI poderá ser habilitado novamente seguindo o procedimento indicado acima.
Por quê a configuração RPKI é removida? Porque em caso de problemas, os softwares de validação RPKI (que rodam no mundo inteiro) começarão a alertar que os objetos RPKI da organização estão vencidos (ou com certificado expirado), e passarão a considerar como erro, desprezando as ROAs associadas. E com isso deixarão de validar as rotas para os blocos IP alocados para essa organização.
Na grande maioria dos casos, basta que a organização mantenha seu sistema C.A (Krill) ativo e operacional (isto é, sem problemas de configuração ou comunicação/rede). Certifique-se que o sistema C.A. (Krill) da organização consegue acesso https (porta tcp/443) aos servidores "rpki-ca.registro.br" e "rpki-pub.registro.br"