RPKI no Huawei: validação de origem (ROV) e descarte de inválidos

Ligar RPKI no Huawei leva uns dez comandos. O trabalho de verdade está na ordem: se você liga o descarte de inválidos no primeiro dia, sem olhar o que vai sumir, corre o risco de derrubar o tráfego para algum destino que tinha um ROA mal feito do outro lado. O caminho seguro é marcar primeiro, observar, e só depois descartar.

Este guia mostra a validação de origem (ROV) na borda Huawei VRP do começo ao fim: o validador Routinator, a sessão RTR com o roteador, o prefix origin-validation enable, a route-policy com if-match rpki origin-as-validation e um plano de implantação em fases. Os exemplos usam o AS 64500, um trânsito em 203.0.113.1 e dois validadores na rede 192.0.2.0/24.

Resposta rápida: RPKI no Huawei em cinco passos

1. Suba um validador (Routinator, por exemplo) e exponha o protocolo RTR, normalmente na porta 3323.
2. No roteador, crie a sessão em rpki com session e tcp port.
3. Em bgp e ipv4-family unicast, rode prefix origin-validation enable. A partir daí cada rota recebida ganha um estado: valid, not found ou invalid.
4. Observe por alguns dias. Depois use bestroute origin-as-validation allow-invalid para preferir válidas sem descartar nada.
5. Por fim, descarte os inválidos com uma route-policy que nega if-match rpki origin-as-validation invalid no import dos peers externos.

Como funciona a validação de origem

O dono de um bloco IP publica no RPKI um ROA (Route Origin Authorization): um objeto assinado que diz “o prefixo X, até o tamanho Y, pode ser originado pelo AS Z”. No Brasil, quem tem recursos via NIC.br cria os ROAs no painel do Registro.br; o passo a passo está no guia para criar ROA para o seu bloco. Esses objetos ficam em repositórios públicos ligados à cadeia de certificados de cada RIR.

O roteador não fala com esses repositórios. Quem faz isso é o validador, um software que baixa os objetos, confere as assinaturas e gera uma lista simples de pares prefixo, maxLength e AS. Essa lista chega ao roteador pelo protocolo RTR (RPKI to Router, RFC 8210). Com ela, o roteador compara a origem de cada rota BGP recebida e dá um de três estados, definidos na RFC 6811.

Um detalhe que pega muita gente: o ROV olha só a origem, o último AS do AS_PATH. Ele não impede que alguém no meio do caminho vaze a sua rota com a origem correta. Para isso você continua precisando de filtros de prefixo e de AS_PATH nos clientes (o bgpq4 gera esses filtros a partir do IRR) e de communities bem definidas, como no post sobre BGP communities no Huawei.

O validador: Routinator e protocolo RTR

O RPKI no Huawei depende de um validador externo. O roteador é só o cliente RTR. Há várias opções de software livre (Routinator, FORT, rpki-client com StayRTR); os exemplos aqui usam o Routinator, da NLnet Labs, que roda bem numa VM Linux pequena. O comando abaixo sobe o serviço RTR e a interface HTTP de status no mesmo processo.

routinator server --rtr 192.0.2.10:3323 --http 192.0.2.10:8323

A porta oficial do RTR na IANA é a 323, mas ela exige privilégio de root no Linux. Por isso a documentação do Routinator usa 3323 nos exemplos, e é essa que o roteador vai chamar. O Routinator só abre as portas que você pedir em --rtr e --http; sem elas, não escuta nada.

Conferindo os seus próprios prefixos antes de tudo

Antes de mexer no roteador, confirme que os seus blocos estão válidos. Se você publicou um ROA errado, outras redes que já descartam inválidos vão jogar fora as suas rotas, e isso acontece hoje, independente do que você fizer na sua borda.

routinator vrps -f csv -a 64500
routinator validate -a 64500 -p 198.51.100.0/24
routinator validate -a 64511 -p 198.51.100.0/24

O vrps com -a lista os VRPs do seu AS. O validate responde o estado de um anúncio: com o AS certo, o resultado esperado é valid; com o AS 64511 originando o mesmo bloco, deve sair invalid. Use dois validadores em máquinas separadas: se o único cair, o roteador fica sem dados e a validação para de funcionar.

Configurando a sessão do RPKI no Huawei VRP

A configuração do RPKI no Huawei começa na visão rpki. Cada session aponta para um validador, e dentro dela você define a porta TCP e, de preferência, a interface de origem. Abaixo, dois validadores com a loopback como origem.

system-view
rpki
 session 192.0.2.10
  tcp port 3323
  connect-interface LoopBack0
  quit
 session 192.0.2.11
  tcp port 3323
  connect-interface LoopBack0
  quit
 quit
commit

• rpki: entra na visão de configuração do cliente RPKI.
• session 192.0.2.10: cria a sessão com o validador e entra na visão dela.
• tcp port 3323: a porta RTR que o Routinator escuta. Precisa bater com o --rtr.
• connect-interface LoopBack0: usa a loopback como origem. Assim a sessão não depende de uma interface física específica e fica fácil liberar no firewall do validador. Esse comando aparece nas versões mais recentes do Huawei VRP; se o seu software não aceitar, a sessão sai pelo endereço escolhido pelo sistema e você libera no validador o IP da interface de saída.
• commit: no Huawei VRP8 com commit em duas etapas, nada vale antes dele.

O comando timer da mesma visão ajusta os tempos de atualização e de expiração dos dados. Os valores padrão atendem a maioria das redes; só mexa neles se tiver um motivo claro. Para conferir, use os comandos abaixo.

display rpki session 192.0.2.10 verbose
display rpki table
display route-policy RPKI-IN
display bgp routing-table peer 203.0.113.1 received-routes

O received-routes depende de keep-all-routes no peer em alguns modelos.

Uma sessão saudável aparece assim no display rpki session verbose (trecho, valores de exemplo):

RPKI server is 192.0.2.10, port 3323
RPKI current state: Established, Age: 2d03h
VPN-instance name: _public_
Local host: 192.0.2.1, Local port: 49616
Remote host: 192.0.2.10, Remote port: 3323
Session Statistics:
IPv4 record : 512304
IPv6 record : 131877

O que importa: o estado Established e as contagens de registros IPv4 e IPv6 diferentes de zero. Sessão em outro estado costuma ser porta errada, firewall no meio ou o validador ainda carregando os repositórios, o que pode levar alguns minutos na primeira execução.

Plano de implantação do RPKI no Huawei: marcar, preferir, descartar

O jeito seguro de ligar RPKI no Huawei é em três fases. Cada uma tem um efeito diferente no tráfego e dá tempo de achar surpresas antes da próxima.

Fase 1: marcar com prefix origin-validation enable

bgp 64500
 ipv4-family unicast
  prefix origin-validation enable
  quit
 quit
commit

Com isso, o RPKI no Huawei já está ativo: o roteador passa a consultar os dados recebidos por RTR e classifica cada rota BGP. Nenhuma decisão de roteamento muda ainda. Segundo a documentação da Huawei, comandos digitados direto na visão bgp já valem para o IPv4 unicast; aqui eu entro em ipv4-family unicast para deixar explícito.

Nesta fase o trabalho é olhar. Quantas rotas estão inválidas? Para quais destinos? Algum cliente importante, algum serviço que a sua base usa muito? Na maioria das redes os inválidos são poucos e quase sempre há uma rota menos específica válida cobrindo o mesmo destino.

Fase 2: preferir rotas válidas

bgp 64500
 ipv4-family unicast
  bestroute origin-as-validation allow-invalid
  quit
 quit
commit

O bestroute origin-as-validation leva o estado para a seleção de melhor caminho, na ordem valid, not found e invalid. Com allow-invalid, um inválido ainda pode ser escolhido se for o único caminho. É uma rede de segurança: você já evita os inválidos quando existe alternativa, sem criar buraco negro.

Fase 3: descartar inválidos com route-policy

Atenção: o peer ... route-policy RPKI-IN import substitui a política de import atual do peer. O exemplo abaixo serve para um peer sem política; se já existir uma, acrescente o nó de deny nela.

route-policy RPKI-IN deny node 10
 if-match rpki origin-as-validation invalid
 quit
route-policy RPKI-IN permit node 20
 quit
bgp 64500
 ipv4-family unicast
  peer 203.0.113.1 route-policy RPKI-IN import
  quit
 quit
commit

O nó 10 nega tudo que for invalid; o nó 20 deixa passar o resto. Se o peer já tem uma política de import (e deveria ter), coloque o nó que nega inválidos no começo dela, em vez de criar outra. A route-policy só nega; ela não troca community nem local-preference por causa do estado. A recomendação do BGP Filter Guide da NLNOG é justamente não mudar atributos BGP com base na validação.

Existe um caminho alternativo: tirar o allow-invalid, aplicando de novo o bestroute origin-as-validation sem ele. Segundo a documentação da Huawei, as rotas inválidas deixam de participar da seleção. Eu prefiro a route-policy, porque ela é explícita por peer e aparece no display route-policy, mas os dois resolvem.

bgp 64500
 ipv4-family unicast
  undo bestroute origin-as-validation
  bestroute origin-as-validation
  quit
 quit
commit

E o IPv6?

O RPKI cobre IPv6 do mesmo jeito. Os mesmos comandos entram em ipv6-family unicast, e a sessão RTR já traz os registros das duas famílias.

bgp 64500
 ipv6-family unicast
  prefix origin-validation enable
  bestroute origin-as-validation allow-invalid
  quit
 quit
commit

Erros comuns ao ativar RPKI no Huawei

• Descartar no primeiro dia. Pule a fase de marcação e você descobre os inválidos pelo telefone do suporte.
• Um validador só. Se ele cair, os dados expiram e a validação para. Tenha dois, em hosts e de preferência em locais diferentes.
• ROA próprio errado. maxLength curto demais transforma em inválido o /24 que você anuncia para engenharia de tráfego. Confira cada bloco com routinator validate.
• Achar que ROV resolve vazamento. Ele valida a origem, não o caminho. Filtro de prefixo por cliente continua obrigatório.
• Firewall do validador fechado. A sessão fica fora de Established. Libere a porta RTR para a loopback dos roteadores.
• Aplicar a política só em um peer. Inválido barrado no trânsito A entra pelo trânsito B ou pelo IX. Aplique em todos os peers externos.

Para o resto da sintaxe de BGP e de route-policy no Huawei VRP, a nossa lista de comandos para roteadores e switches Huawei reúne os comandos de consulta mais usados.

Perguntas frequentes

O RPKI no Huawei precisa de licença?

Depende do modelo e da versão. A validação de origem existe no Huawei VRP desde a V800R009C10 nos roteadores da linha NE. Confira na documentação do seu equipamento e na sua licença antes de planejar a janela.

O que acontece se o validador cair?

O roteador mantém os dados por um tempo e depois eles expiram. Sem dados, as rotas deixam de ser classificadas e o descarte de inválidos para de agir. Por isso a recomendação é ter dois validadores.

Rotas not found devem ser descartadas?

Não. Not found só quer dizer que o dono do bloco ainda não publicou ROA. Uma parte grande da tabela global está nesse estado, e descartar essas rotas deixaria sua rede sem alcançar muitos destinos.

Qual a diferença entre bestroute origin-as-validation e a route-policy?

O bestroute origin-as-validation usa o estado na escolha do melhor caminho e vale para o processo BGP inteiro. A route-policy com if-match rpki origin-as-validation invalid descarta no import de cada peer, o que dá controle fino e deixa a regra visível na configuração.

Preciso de ROA para os meus prefixos antes de ativar o ROV?

Não é obrigatório para validar os outros, mas é o primeiro passo recomendado. Sem ROA, seus blocos ficam como not found e não ganham a proteção que o RPKI oferece contra sequestro de origem.

Conclusão

Ativar RPKI no Huawei é simples na sintaxe e exige paciência na implantação. Suba dois validadores, crie as sessões RTR, ligue o prefix origin-validation enable e só observe. Depois prefira as válidas e, quando os números fizerem sentido, descarte os inválidos com uma route-policy aplicada em todos os peers externos.

Com o RPKI no Huawei rodando, a sua borda deixa de aceitar anúncios com origem falsa e a sua rede passa a fazer parte do grupo que torna o sequestro de prefixos menos eficaz para todo mundo.

Leitura recomendada: Redes que descartam RPKI inválidos, Brasil Peering Forum (CC BY-NC 4.0).

Fontes: Huawei NE40E/NetEngine Configuration Guide (Improving BGP Security, Configuring ROA), RFC 6811, RFC 8210, manual do Routinator (NLnet Labs) e o guia “Rejecting RPKI Invalid BGP Routes” do NLNOG BGP Filter Guide.