Resumo

  • Lançado em 20 de outubro, o OpenBSD 8.0 registra que o rpki-client agora aplica corretamente as restrições de âncoras de confiança aos certificados de roteador BGPsec.
  • A regra local limita o que um validador aceita. A publicação feita pela âncora e as decisões de outros validadores continuam em mãos diferentes.

A cerca ganhou uma nova porteira

A página do OpenBSD 8.0 resume a mudança assim: aplicar corretamente as restrições aos certificados de roteador BGPsec do rpki-client(8). O changelog detalhado repete a correção. A versão foi lançada em 20 de outubro.

Esse detalhe separa uma opção existente de uma proteção efetiva. Um validador pode oferecer restrições e ainda tratar uma família de certificados por outro caminho. O certificado de roteador BGPsec associa uma chave ao uso de BGPsec e a recursos da Internet. O registro do OpenBSD confirma que o controle agora alcança corretamente esse tipo de certificado. A nota pública não identifica uma rede afetada nem descreve incidente; ela documenta uma correção de código.

O ajuste acompanha o rascunho do SIDROPS na IETF, “Constraining RPKI Trust Anchors”. A versão -02 propõe que cada parte que valida RPKI (RP) declare localmente quais recursos espera que uma âncora de confiança (TA) assine. O RP compara os endereços IP e números AS do certificado de entidade final com esse limite local. Se o certificado extrapola a lista permitida, o RP rejeita o objeto assinado em sua própria validação.

“Todos os recursos” dá muita margem

O rascunho afirma que os cinco Registros Regionais da Internet (RIRs) listam todos os recursos como subordinados aos certificados TA em operação normal. Essa amplitude ajuda a evitar invalidação durante inconsistências temporárias, sobretudo em transferências de recursos. Para o RP, porém, a autoridade de assinatura pode parecer maior do que os recursos hoje mantidos pelo registro.

Um arquivo .constraints cria um segundo ponto de decisão para o RP. Cada arquivo corresponde ao TA indicado pelo .tal de mesmo nome. O operador pode permitir prefixos, intervalos de endereços e números AS; entradas deny recortam exceções. A negação prevalece, e o que não aparece em nenhuma entrada allow fica negado por padrão. Ninguém precisa escrever uma lista do planeta inteiro só para excluir um bloco.

O formato é simples; a falha é total. Se houver erro no arquivo, o rascunho manda o RP rejeitá-lo por inteiro e não usar essas regras para verificar certificados de entidade final. Até corrigir o arquivo, essa camada local deixa de filtrar os certificados daquele TA. Sintaxe, empacotamento e responsável pela atualização fazem parte do controle de segurança.

A checagem cobre objetos cujos perfis exigem recursos IP ou AS explícitos em extensões RFC 3779: ROAs, ASPAs, RSCs e certificados de roteador BGPsec. Manifestos e TALs assinados aparecem entre os exemplos fora do escopo porque usam recursos herdados. A regra altera a validação local do RP. A escolha de rota pelo roteador passa por outras etapas e políticas.

O código chegou antes da norma final

A versão -02 segue como Internet-Draft ativo. O Datatracker informa o estado do SIDROPS como “Waiting for Write-Up Revised I-D Needed – Issue raised by WGLC”. O próprio rascunho prevê remover o apêndice de implementações antes da publicação como RFC.

O mecanismo já está em software. O apêndice relata que o rpki-client em C o implementa e o mantém ativado por padrão desde 2023. Também cita versões em Rust e Go. Os autores dizem que as três tiveram os mesmos resultados nos fixtures do OpenBSD. A IETF ressalta que não verificou as informações de implementação enviadas pelos participantes. O registro mostra código relatado e uma bateria comum de testes; não é uma auditoria independente de interoperabilidade. O manual do OpenBSD descreve os arquivos .constraints por TA e as regras locais allow e deny.

A correção do 8.0 mostra que uma função antiga ainda pode deixar uma classe de certificado com tratamento diferente. O changelog não identifica as versões anteriores nem o caminho exato do código; esses dados definiriam o alcance histórico. A correção documentada já permite uma conclusão operacional: os testes da cerca precisam percorrer cada tipo de objeto, não apenas confirmar que a opção existe.

Um arquivo pequeno pode levar seis meses até o usuário

O rascunho recomenda que quem distribui restrições junto com sistemas operacionais ou pacotes de terceiros considere seis meses para a atualização dos usuários. Recursos e políticas de transferência mudam. A lista local precisa acompanhar o perímetro que promete impor. Uma regra allow antiga pode barrar um recurso que se tornou legítimo; uma regra ausente pode aceitar mais recursos do que o operador pretende.

A estratégia do NRO para 2026–2028 inclui a entrega de um documento sobre Trust Anchor Constraints entre as ações planejadas para RPKI. O programa RPKI do NRO já havia colocado uma consulta comunitária sobre configuração de âncoras entre os objetivos de 2025. A agenda institucional segue de um lado; o software recebe correções de outro. O OpenBSD 8.0 é uma evidência recente dessa segunda frente.

Para quem opera uma rede, a lista de verificação é concreta: o arquivo representa os recursos pretendidos? Está ligado ao TAL correto? A atualização do pacote o substitui? Ele passa pela leitura sem erro? Cada classe de certificado usada passa pela mesma regra? A nota do OpenBSD tornou a última pergunta difícil de esconder no rodapé.

Fontes