Summary

  • O bgpipe de Paweł Foremski se instala entre participantes BGP e aplica verificações de origem e de caminho às atualizações. A RIPE 92 apresentou a proposta como forma de acrescentar ROA e ASPA a roteadores já em uso.
  • O manual do estágio ASPA exige o papel do vizinho. No modo --role auto, se ele não anunciar a capacidade BGP Role no OPEN, a validação ASPA da sessão é ignorada com um aviso. Para segurança, o projeto orienta a configurar o papel diretamente.

Um roteador pode ficar anos em produção enquanto o próximo recurso de segurança espera na fila de firmware. Paweł Foremski construiu uma saída: bgpipe fala BGP dos dois lados, recebe as atualizações, passa por uma cadeia de estágios e as entrega ao equipamento existente. A verificação entra no caminho sem trocar o roteador.

Isso resolve a espera pelo software do equipamento. Não resolve a identidade operacional do vizinho. A validação de origem ROV compara o AS de origem de cada prefixo aos dados ROA validados. ASPA examina o caminho de sistemas autônomos e as relações de provedor. O guia ROV descreve estados por prefixo; o ASPA classifica o caminho inteiro como VALID, UNKNOWN ou INVALID. UNKNOWN indica falta de atestações suficientes. Misturá-lo com INVALID produz um alerta mais dramático e menos útil.

Para verificar um caminho com ASPA, bgpipe precisa saber se o vizinho é cliente, provedor, par ou servidor de rotas. A operadora pode escrever esse papel conforme sua própria relação de interconexão. Também pode usar --role auto, que aceita o papel enviado pelo vizinho na mensagem OPEN. Se não vier a capacidade BGP Role, a checagem ASPA da sessão é pulada. Se o vizinho se declarar provedor ou servidor de rotas, mudam as regras aplicadas. O próprio projeto alerta que o modo automático confia no participante inspecionado.

É aí que o trabalho de Foremski deixa de ser uma simples promessa de instalação. A operadora precisa manter uma lista correta de vizinhos, escolher a fonte de dados RPKI e decidir o destino de um caminho INVALID. O estágio ASPA permite retirar prefixos, descartar a atualização inteira ou mantê-la com uma etiqueta. Manter é uma maneira de medir antes de alterar o tráfego. Retirar ou descartar exige uma decisão assumida por quem opera a rede.

A ordem dos estágios também altera a contagem. Se ROV descarta um UPDATE antes de ASPA, o segundo estágio não recebe o pacote e não o inclui nas métricas. O manual ASPA recomenda colocá-lo primeiro quando a meta é registrar todas as atualizações. O número no painel pode ser exato e, ainda assim, cobrir apenas o que sobrou da etapa anterior.

Os materiais não apresentam uma implantação datada com papel configurado, OPEN recebido, estado do cache ASPA e atualizações retiradas. Esse conjunto mostraria o resultado numa rede real. Por ora, a escolha revelada pelo projeto basta: a ferramenta tira o roteador velho da desculpa, e obriga a operadora a escrever quem é o vizinho antes de confiar na validação.

Fontes: RIPE 92 RACI · apresentação do bgpipe · guia ASPA · guia ROV.