Resumo

  • A RIPE NCC afirma que sua API RPKI agora cria e gerencia certificados de chaves de roteadores BGPsec.
  • O certificado autoriza uma chave associada a um ASN; ele não põe o roteador para assinar anúncios nem o vizinho para validar o caminho.

O BGPsec tinha um problema com cara de balcão: o padrão já definia o certificado de que uma chave de roteador precisa, mas o operador ainda tinha de encaixar essa emissão na rotina de RPKI. A RIPE NCC acaba de abrir um caminho pela API. O pedido e a gestão do certificado podem ser feitos por software. Roteadores, infelizmente, ainda não aparecem no rack depois de um clique.

Na atualização aos membros de 23 de outubro, a RIPE NCC anunciou que a API RPKI permite criar e gerenciar certificados de chaves de roteador BGPsec. No dia anterior, Tim Bruijnzeels, engenheiro principal da RIPE NCC, explicou na lista RIPE Routing WG que o titular de um ASN pode autorizar uma chave para assinar atualizações BGP. A documentação pública da API aponta o BGPsec para o ambiente-piloto RPKI em localcert.ripe.net e descreve a criação de objetos de chave e a recuperação do certificado e da cadeia. Isso comprova uma capacidade de provisionamento; os documentos não informam quantos membros já a usam em produção nem apresentam um endpoint geral para todas as contas.

O certificado tem uma função precisa. A RFC 8209 define um certificado final de RPKI que associa uma chave pública a um ou mais ASNs. O roteador guarda a chave privada correspondente e, se tiver suporte a BGPsec, usa essa chave para assinar informações do caminho ao enviar um BGPsec UPDATE a um par externo. O equipamento que recebe pode verificar o caminho assinado com os certificados e as assinaturas disponíveis.

Isso não é o trabalho dos outros objetos RPKI. Uma ROA indica qual AS pode originar um prefixo; uma ASPA registra os provedores autorizados pelo titular de um AS; o BGPsec transporta assinaturas ao longo do caminho entre ASes. Bruijnzeels descreve os mecanismos como complementares. O certificado de chave de roteador é uma peça da assinatura de caminho, não outro nome para validação de origem ou detecção de vazamento de rota.

A frase mais útil da mensagem do engenheiro da RIPE NCC não é o anúncio. É a admissão de que o suporte em roteadores de hardware está atrasado e de que implantação incremental e desempenho continuam sendo desafios. A API tira trabalho manual de uma etapa. Ela não negocia uma sessão BGPsec pelo roteador, não protege uma chave privada dentro do equipamento, não ensina o vizinho a entender o atributo assinado e não decide o que fazer quando falta um caminho assinado.

A escada operacional é clara: pedir o certificado; proteger e instalar a chave privada; habilitar BGPsec em roteadores e sessões compatíveis; enviar UPDATEs assinados; e fazer com que os equipamentos receptores os validem. Cada degrau tem um responsável diferente. Uma resposta de sucesso da API prova o primeiro. Os materiais públicos não dizem qual endpoint de produção está aberto a todos os membros nem quais implementações de roteador já concluíram os demais passos. O próprio engenheiro da RIPE NCC diz que o suporte de hardware está atrasado. Esse é o próximo dado que falta.

Para o operador, é um avanço concreto. A emissão de certificados é uma tarefa de plano de controle, e uma API permite automatizá-la junto com outras rotinas de RPKI. A demonstração convincente ligará o certificado a um roteador específico, uma chave protegida, um par com sessão BGPsec e um UPDATE validado de ponta a ponta. Por enquanto, a API simplifica uma parte do provisionamento. A rota ainda não assina a si mesma.

Fontes: atualização da RIPE NCC, 23 de outubro de 2026; Tim Bruijnzeels, lista RIPE Routing WG, 22 de outubro de 2026; documentação da API BGPsec da RIPE NCC; RFC 8209; RFC 8205; RIPE-851, declaração de práticas de certificação.