Resumo

  • O risco de revogação de ROA não se limita ao risco de alguém apertar um botão de exclusão. Ele abrange exclusão, substituição, expiração, mudança de certificado, mudança de conjunto de recursos, falha de publicação, migração de hospedado para delegado, falha da AC delegada e atualização desigual do cache das partes dependentes.
  • Uma rota comercialmente aceita pode se tornar operacionalmente rejeitada quando o anúncio BGP observado entra em conflito com o ROA atual. Os gatilhos comuns são uma mudança de AS de origem, um ROA ausente após transferência, um maxLength muito restrito, uma mudança de certificado ou uma ação de confinamento de emergência.
  • Os recursos RPKI próprios do RIPE NCC são úteis como peça factual: RPKI permite que LIRs solicitem certificados de recursos, ROAs indicam as origens autorizadas e o comprimento máximo de prefixo, e a validação de origem BGP permite que as redes classifiquem anúncios como VÁLIDO, INVÁLIDO ou DESCONHECIDO.
  • A peça mais importante é o vínculo entre transferência e certificação. A documentação do RIPE NCC indica que quando um recurso é movido ou transferido, a organização listada muda, o certificado muda e os ROAs subjacentes são excluídos e devem ser recriados. Trata-se de um risco de descontinuidade integrado.

A repetição antes do failover

O exercício de continuidade está programado para uma terça-feira porque ninguém quer descobrir o problema durante o failover da aquisição em si. Uma empresa de hospedagem europeia compra uma rede menor e pretende mover um /22 destinado a clientes para seu próprio AS e depois anunciar um /24 posteriormente via serviço BYOIP de um provedor de nuvem para uma nova região. Os engenheiros têm um plano de roteamento, um cronograma de transferência, um ticket de nuvem, cartas de autoridade, avisos aos clientes e uma janela de manutenção.

Eles também têm uma linha na lista de verificação que não existia há dez anos: confirmar que os ROAs sobreviverão a cada etapa da mudança.

O primeiro teste falha silenciosamente. O agregado ainda é visível a partir do antigo AS de origem. A nova origem pretendida é aceita por um validador de laboratório, mas marcada como INVÁLIDA por outra visão de verificação de rota porque o antigo ROA ainda autoriza o AS do vendedor e nenhum ROA equivalente foi criado para o comprador. O provedor de nuvem rejeita o mais específico porque o maxLength existente termina em /22. Um escritório de trânsito solicita prova de que o cliente pode autorizar a nova origem. Um painel interno exibe DESCONHECIDO porque não vê nenhum ROA coberto. A equipe de aquisição tratou o ROA como um item de segurança.

A equipe de roteamento agora o trata como uma condição de fechamento.

Este é um problema estreito, não uma teoria geral de segurança de roteamento. Um ROA é uma autorização de origem de rota, não um título de propriedade. A validação de origem de rota é uma entrada de política de roteamento, não uma ordem judicial. O RIPE NCC não injeta rotas na tabela global e não deve ser tratado como a polícia de tráfego. No entanto, a camada de certificação do registro agora está suficientemente próxima da dependência do mercado para que uma descontinuidade apareça como uma perda de qualidade de ativo.