Seus blocos não têm ROA
Qualquer rede pode anunciar o seu prefixo por erro, e quem valida não tem como saber quem é o dono.
BGP · Provedores
ROAs que protegem os seus blocos sem invalidar os próprios anúncios, e a borda recusando rotas de origem falsa depois de um período em observação.
Implantação de RPKI é criar os ROAs que dizem quais ASNs podem anunciar os seus blocos e ligar, na borda, a validação que descarta rotas de origem falsa. É para o provedor com blocos próprios que ainda não tem ROA, ou tem e não valida o que recebe. O resultado é a sua rede protegida dos dois lados, sem derrubar nenhum anúncio legítimo.
É pôr para funcionar os dois lados do RPKI: publicar quem pode anunciar os seus blocos e conferir quem anuncia os blocos dos outros. O primeiro protege você; o segundo protege os seus assinantes.
O RPKI (Resource Public Key Infrastructure) é uma cadeia de certificados que liga cada bloco de IP ao dono dele. Com essa cadeia, o BGP ganha um jeito de conferir se a rede que anuncia um bloco tem autorização para isso.
O dono do bloco publica um ROA, que autoriza um ASN a anunciar aquele prefixo até um tamanho máximo. Quem recebe a rota compara o anúncio com os ROAs do mundo todo e marca a rota como válida, inválida ou não encontrada.
Muitas operadoras de trânsito e pontos de troca como o IX.br já descartam rotas inválidas [CONFIRMAR política atual do IX.br]. A implantação tem quatro peças:
Criados no painel do provedor, um para cada combinação de bloco, ASN de origem e tamanho máximo que a borda realmente usa.
Programa que baixa os certificados do mundo todo e monta a lista de origens autorizadas. Roda num servidor ou VM da sua rede, de preferência em dois.
O validador entrega a lista ao roteador pelo protocolo RPKI-to-Router (RTR). O roteador marca cada rota que chega com o estado dela.
A regra que decide o que fazer com cada estado. O padrão é descartar as inválidas e aceitar as válidas e as não encontradas.
Seis situações pedem a implantação ou a revisão do RPKI. Algumas delas já estão tirando assinante do ar sem ninguém perceber.
Qualquer rede pode anunciar o seu prefixo por erro, e quem valida não tem como saber quem é o dono.
Dividir um /22 em /24 para engenharia de tráfego exige ROA com tamanho máximo que cubra os pedaços.
O prefixo cedido a um cliente que anuncia com o ASN dele precisa de um ROA autorizando esse ASN.
Operadora, IX.br ou ferramenta pública mostrou um anúncio seu marcado como inválido.
Fusão, troca de ASN ou bloco novo mexe na origem dos anúncios. Os ROAs precisam mudar antes.
Sem validação, a sua borda aceita sequestros de prefixo e manda o tráfego dos assinantes para o lugar errado.
São cinco etapas, e nada é descartado antes da última. Até lá, a validação só marca as rotas para você ver o impacto.
Todos os prefixos que saem da sua borda, de que tamanho, por qual ASN e para qual operadora.
Prazo: [PREENCHER]
Um ROA por anúncio real, com tamanho máximo justo, conferido de fora antes de seguir.
Prazo: [PREENCHER]
Instalação em dois servidores ou VMs da sua rede e ligação com cada roteador da borda.
Prazo: [PREENCHER]
As rotas são marcadas, nada é descartado, e cada inválida é investigada para achar bloco seu ou de cliente.
Prazo: [PREENCHER]
A regra entra em janela, com plano de volta e conferência dos destinos mais usados pelos assinantes.
Prazo: [PREENCHER]
A implantação cobre os ROAs, os validadores e a regra de descarte na borda. O que é cuidado contínuo ou filtro geral tem página própria.
O preço depende de quantos prefixos e roteadores entram e de quantos clientes têm ASN próprio. É projeto fechado, com valor escrito depois do inventário.
| Fator | Como influencia | Exemplo |
|---|---|---|
| Prefixos anunciados | Cada combinação de bloco, tamanho e ASN pede um ROA conferido | Um /22 anunciado inteiro e em quatro /24 |
| Clientes com ASN | Cada cliente tem anúncios próprios para conferir e autorizar | Dois provedores menores usando o seu bloco |
| Roteadores da borda | Cada um precisa da ligação com os validadores e da regra | Dois roteadores de borda e um no IX.br |
| Versão do sistema | Sistema sem suporte a RPKI pede atualização antes | Borda ainda em RouterOS 6 |
| Ambiente dos validadores | Servidor novo ou VM já existente muda o trabalho | Validadores em contêiner na VM de monitoramento |
Faixa de preço para um provedor com um bloco e um roteador: [PREENCHER faixa aprovada pela Táquion Tech]. Criar ROA no Registro.br não tem taxa à parte [CONFIRMAR no Registro.br].
Confira os erros que derrubam os próprios anúncios, os tipos de rota inválida e as normas que a implantação deve seguir. Serve para avaliar qualquer fornecedor, inclusive a Táquion Tech.
Quatro falhas que transformam a proteção em queda. Pergunte ao fornecedor como evita cada uma.
ROA para um /22 com máximo /22, e a borda anunciando os quatro /24 dele: os quatro viram inválidos e somem para quem valida.
Máximo /24 para um bloco anunciado só como /22 deixa espaço para alguém anunciar um /24 forjando a sua origem. Autorize só o que você anuncia.
Se o único validador para, o roteador perde a lista. Dois validadores, de preferência de programas diferentes, evitam esse ponto único.
Ligar o descarte sem observar antes pode cortar um cliente com ROA errado. A observação mostra cada inválida antes de ela sumir.
Cada rota recebida ganha um destes estados. Entender por que uma rota ficou inválida é o que separa bloqueio certo de cliente cortado.
| Estado | O que significa | O que fazer |
|---|---|---|
| Válida | ROA existe e confere com origem e tamanho | Aceitar |
| Não encontrada | Ninguém publicou ROA para o bloco | Aceitar |
| Inválida | ROA existe, mas origem ou tamanho não batem | Descartar, depois de conferir |
O bloco foi anunciado por um ASN que o ROA não autoriza. Pode ser sequestro ou cliente sem ROA.
Se o bloco é seu, crie o ROA para o ASN certo. Se não é, o descarte está fazendo o trabalho dele.
A origem está certa, mas o prefixo é mais específico que o máximo do ROA.
Ajuste o tamanho máximo ou crie um ROA para o pedaço anunciado.
Referências públicas que descrevem cada peça. Peça ao fornecedor que diga quais segue.
Descrevem a arquitetura do RPKI e o formato do ROA, com o campo de tamanho máximo [CONFIRMAR na norma].
Define a validação de origem e os três estados que o roteador atribui a cada rota [CONFIRMAR na norma].
Define o protocolo RTR, pelo qual o validador entrega a lista ao roteador [CONFIRMAR na norma].
Recomenda evitar tamanho máximo maior que o anúncio real, para não abrir brecha a origem forjada [CONFIRMAR na norma].
As respostas mostram se a implantação vai durar além do dia da entrega.
Em geral as rotas voltam a não encontradas e nada é descartado [CONFIRMAR comportamento por fabricante]. O alerta precisa avisar mesmo assim.
ROA esquecido em bloco novo é o erro que mais volta. Combine quem faz e em que prazo.
Porque nenhum ROA é criado sem inventário e nenhuma rota é descartada sem observação. Seis compromissos de toda implantação.
Cada prefixo que sai da borda é listado, com tamanho e origem, antes do primeiro ROA.
Inventário de anúncios entregue por escrito
A validação roda marcando rotas, e cada inválida é explicada antes de a regra entrar.
Relatório das inválidas encontradas
Dois validadores no seu ambiente, com alerta se um deles parar de responder.
Dois validadores em toda implantação
Desligar o descarte leva um comando, e o roteiro fica escrito para a sua equipe.
O plano de volta faz parte da proposta
Validadores usam programas abertos e o hardware que você já tem, sempre que possível.
Nenhuma marca indicada por comissão
Quem levanta os anúncios é quem cria os ROAs e acompanha o primeiro dia de descarte.
[PREENCHER: implantações de RPKI feitas pela equipe]
A implantação de RPKI é feita à distância para provedores de todo o Brasil. A visita ao POP no litoral de Santa Catarina fica para quando é preciso instalar servidor para os validadores.
ROAs no painel do provedor, validadores e regra na borda configurados por acesso remoto registrado.
Para instalar o servidor dos validadores no rack ou acompanhar a janela de descarte no POP. [CONFIRMAR área de atendimento]
Dúvidas de quem vai criar os primeiros ROAs ou ligar a validação na borda. Se a sua não estiver aqui, mande no WhatsApp.
É uma infraestrutura de certificados que diz quais ASNs podem anunciar cada bloco de IP. Os roteadores usam essa informação para recusar anúncios de origem falsa.
É o registro assinado que autoriza um ASN a anunciar um bloco até um tamanho máximo. No Brasil, é criado pelo dono do bloco no painel do Registro.br. O guia de criação de ROAs mostra os campos.
Não há lei que obrigue [CONFIRMAR na norma], mas cada vez mais redes descartam rotas inválidas. Sem ROA, o seu bloco fica desprotegido; com ROA errado, ele some para essas redes.
O RouterOS 7 se conecta a um validador externo por RTR e marca cada rota com o estado da validação. Uma regra no filtro de entrada descarta as inválidas. O RouterOS 6 não tem esse recurso.
Pode, se o bloco de um cliente estiver com ROA errado ou ausente para o ASN dele. Por isso a validação roda antes em observação, e cada inválida é conferida antes do descarte.
Depende do número de prefixos, de roteadores e de clientes com ASN. A faixa para um bloco e um roteador é [PREENCHER], e o valor exato sai depois do inventário.
O típico é [PREENCHER], e a maior parte é o período de observação. Os ROAs em si ficam prontos rápido; conferir o efeito deles é o que pede tempo.
Num servidor ou VM da sua rede, perto da borda. Programas abertos como Routinator, rpki-client e Fort são os mais usados, e combinar dois deles reduz o risco de falha.
No RPKI hospedado do Registro.br, os certificados são renovados enquanto o bloco estiver ativo [CONFIRMAR no Registro.br]. O que precisa de revisão é o conteúdo: bloco novo, cliente novo ou ASN novo pedem ROA novo.
Protege contra anúncio com origem errada. Um anúncio que forja o seu ASN no caminho passa pela validação de origem, e por isso filtros e monitoramento de BGP continuam necessários.
Três serviços que completam a proteção da borda. Cada um cobre um risco que o RPKI sozinho não resolve.
Filtros de prefixo e limites por vizinho, que barram o que o RPKI não vê.
Ver a configuração de BGP
Alerta quando outro ASN anuncia os seus blocos ou a origem deles muda.
Ver o monitoramento de BGP
Pedido de ASN e blocos próprios, o ponto de partida para ter ROA.
Ver a solicitação de ASNTrês guias sobre ROAs, validação e filtros na borda.
Os campos do ROA, um a um, e o erro do tamanho máximo.
Como ligar a validação de origem nos roteadores mais comuns.
Os filtros de prefixo que trabalham junto com o RPKI.
Orçamento
Diga em que ponto está o RPKI do provedor e se há clientes com ASN. Um Especialista devolve escopo, prazo e valor por escrito.
Falar com o André Comercial, no WhatsApp