Resumo

  • Uma resposta na lista de roteamento informou que Ben Cartwright-Cox foi o primeiro a usar a nova API da RIPE NCC para publicar um certificado de chave de roteador BGPsec. O repositório da RIPE contém um certificado emitido em 22 de outubro para o AS212232.
  • A RFC 8634 divide a troca em cinco etapas: publicar o certificado substituto, esperar as caches RPKI buscá-lo, virar o roteador e renovar os UPDATEs, revogar opcionalmente o certificado antigo e retirar a chave antiga quando a validação vencer.

O primeiro certificado já saiu do balcão

O BGPsec passou do anúncio de uma funcionalidade para um arquivo que qualquer operador pode inspecionar. Em 22 de outubro, a RIPE NCC anunciou que sua API RPKI podia criar e gerenciar certificados de roteador BGPsec. Horas depois, uma resposta na mesma discussão da lista de roteamento parabenizou Ben Cartwright-Cox por usar a API para publicar o primeiro. O repositório público da RIPE contém um certificado de roteador BGPsec emitido naquele dia para o AS212232. É um objeto pequeno, seguido de uma etapa nada trivial: trocar a chave de um roteador ativo sem apagar a rota assinada do mapa.

A documentação da RIPE NCC oferece as operações esperadas: criar uma chave de roteador, listar as chaves da autoridade certificadora, consultar uma chave, revogá-la e obter o certificado ou a cadeia emissora. O acesso usa uma chave de API por LIR, com permissão Resource Certification (RPKI) API. O pedido leva ASN, routerId — o identificador BGP — e uma solicitação PKCS#10. A CA atribui o routerKeyId.

CSR não é detalhe de formulário. É um pedido de certificação baseado em chave pública; a API não pede a chave privada que o roteador usará para assinar. O certificado associa o ASN autorizado à chave pública. O RFC 8209 define o perfil do certificado; o RFC 8205 descreve as assinaturas BGPsec que acompanham o caminho da rota entre sistemas autônomos.

ROA e validação de origem respondem se um AS pode originar um prefixo. ASPA registra relações com provedores e ajuda a identificar vazamento de rotas. BGPsec assina o caminho: um roteador compatível verifica se cada AS autorizou o anúncio ao próximo AS. São ferramentas próximas no ecossistema RPKI, com funções diferentes.

O certificado ainda precisa viajar

A API facilita pedir e recuperar o certificado. Para a rota funcionar, a CA precisa publicá-lo no RPKI, o roteador precisa da chave privada correspondente, a sessão BGP precisa negociar BGPsec e os vizinhos precisam entender o caminho assinado. Um certificado bem guardado não assina sozinho um UPDATE. Ele continua no balcão até o roteador usá-lo.

A RIPE NCC reconhece que o suporte de hardware nos roteadores está atrasado e que implantação gradual e desempenho seguem como desafios. O RFC 8207 explica o motivo: BGPsec pode exigir mais memória ou CPUs mais novas. Uma rede pode começar por alguns roteadores de borda e medir o resultado. Na implantação parcial, caminhos assinados formam ilhas; um trecho sem suporte interrompe a sequência de assinaturas.

Automatizar a emissão do certificado reduz atrito em uma etapa necessária. O cronograma dos fabricantes e a adoção pelos vizinhos continuam nas mãos dos operadores e dos equipamentos que se conectam na borda da rede.

Rotação de chave é trabalho de calendário

A RFC 8634 divide a troca em cinco etapas. Publicar o certificado novo; esperar que caches RPKI no mundo todo o busquem; mudar o roteador para a nova chave e atualizar os UPDATEs BGPsec de saída; revogar o certificado antigo se for preciso invalidar mensagens assinadas pela chave velha; e, quando a validação do certificado antigo vencer, sinalizar a retirada da chave pelo protocolo RPKI-Router, para que os roteadores removam as rotas assinadas por ela. A espera permite que os pares conheçam a chave pública nova antes de receber as assinaturas correspondentes.

A API automatiza chamadas; não encurta o relógio da propagação. Um registro de mudança deve ligar publicação do certificado novo, visibilidade nas caches, troca no roteador, UPDATEs renovados e qualquer revogação opcional. A retirada final vem com o vencimento da validação do certificado antigo. Um script que salta de “criar” para “revogar” seria ótimo em fabricar uma queda.

A identificação da chave também pede inventário decente. A API usa ASN, routerId e identificador da chave para distinguir cada instância. A documentação permite chaves diferentes para o mesmo ASN e a mesma chave em vários ASNs, de acordo com a necessidade operacional. Flexibilidade boa pede registros melhores: ASN, roteador, impressão digital, estado do certificado e horário planejado da troca. “Chave 12” não vai salvar ninguém às três da manhã.

Do piloto à operação

A documentação pública coloca o BGPsec no piloto RPKI em localcert.ripe.net; o repositório guarda o certificado de AS212232, emitido em 22 de outubro. Falta ao registro público da RIPE uma trilha datada da rotação que ligue a impressão digital e a publicação do certificado à troca do roteador, a um UPDATE com assinatura renovada e à validação por pares BGPsec identificados; essa trilha mostraria até onde a API chegou na operação real do roteamento.

O sucesso não será o total de certificados que a API consegue devolver. Será a capacidade de pedir uma chave, confirmar sua publicação, programar a mudança no roteador, verificar o caminho assinado nos pares relevantes e concluir a rotação mantendo a autenticação das rotas. A API remove uma barreira administrativa. O trabalho de engenharia segue nos roteadores, nas conexões entre redes e no tempo que cada nova chave precisa para ser reconhecida.

Fontes: anúncio e resposta no grupo de trabalho de roteamento da RIPE; documentação da API BGPsec da RIPE NCC; IETF RFC 8209; IETF RFC 8205; IETF RFC 8207; IETF RFC 8634.