BGP Seguranca-de-Roteamento RPKI ISP Redes Protocolos

Depois do RFC 7454: o que muda na segurança de BGP e como preparar sua rede

Ariel S. Weher
Depois do RFC 7454: o que muda na segurança de BGP e como preparar sua rede

Introdução: uma política que envelheceu mal

Em 2015, RFC 7454 / BCP 194 virou a bíblia da segurança de BGP. Recomendava filtrar de forma agressiva: nada mais específico que um /24 em IPv4, nada mais longo que um /48 em IPv6, prefix-lists estáticos, e um longo etc. de regras que hoje geram mais problemas do que resolvem.

A realidade em campo é outra. Filtrar todo /25 ou mais específico deixa de fora clientes legítimos com PI que precisam anunciar blocos pequenos. Um prefix-list estático com 50.000 entradas não escala. E o pior: o filtro por comprimento não te protege contra um hijack de um /20 válido.

No dia 7 de abril de 2026, o grupo de trabalho GROW do IETF publicou a revisão 15 de draft-ietf-grow-bgpopsecupd, o documento que substituirá o RFC 7454 quando concluir o trâmite como BCP. Na data deste artigo ele está em WG Last Call — ainda não é RFC, mas a direção é clara e o conteúdo está estabilizado. A mudança de fundo: deixa de focar no tamanho do prefixo e aponta para a validação de origem.

Se você opera um ISP na América Latina, isso te obriga a rever seus filtros de entrada e saída. Não é opcional.

O que o rascunho propõe

A filosofia do documento muda de defesa por filtro para defesa por validação. O rascunho é deliberadamente abstrato — define propriedades que um operador DEVE cumprir sem prescrever tecnologias específicas —, mas a direção operacional é clara. Combinando o que o rascunho diz com o que consideramos boa prática hoje, a comparação fica assim (as linhas com † são recomendação operacional nossa, não requisitos do rascunho):

Eixo RFC 7454 (2015) Postura operacional pós-bgpopsecupd
Filtro por comprimento Filtrar ≥/25 IPv4, ≥/49 IPv6 O rascunho remove as recomendações por comprimento; o comprimento não indica legitimidade
Validação de origem Menciona IRR como opcional O rascunho exige que a origem esteja “globally authorized”; na prática, isso é RPKI + ROA com IRR como complemento
Atributos transitivos Não aprofunda O rascunho recomenda fortemente não alterar atributos transitivos imutáveis (SHOULD NOT) e proíbe transportar estados RPKI em atributos transitivos (MUST NOT)
BGP Roles † Não existia RFC 9234 define roles (Provider, Customer, Peer) e o atributo OTC para prevenção de route leaks
ASPA † Não existia Os rascunhos de ASPA (draft-ietf-sidrops-aspa-verification) adicionam validação de AS-PATH por relação de provider
Communities † Não aprofunda Recomendação operacional: documentar quais communities são aceitas, não fazer strip indiscriminado
Monitoramento † SNMP, syslog básico BMP (RFC 7854) como ferramenta de detecção de anomalias

O ponto-chave: o comprimento do prefixo não é indicador de ataque. Um /24 sequestrado (hijack) é tão perigoso quanto um /25 legítimo. O foco novo é validar quem tem direito de anunciar aquele prefixo, não quantos bits ele tem.

Como isso fica na prática

Cenário 1: sua sessão com um upstream

Hoje você provavelmente tem algo assim:

ip prefix-list UPSTREAM-IN deny 0.0.0.0/0 ge 25
ip prefix-list UPSTREAM-IN permit 0.0.0.0/0 le 24

Isso bloqueia /25s de clientes com PI que passam por aquele upstream. Com a nova recomendação, o filtro por comprimento some e no lugar entra validação com RPKI:

! FRRouting
route-map UPSTREAM-IN permit 10
 match rpki valid
 set local-preference 200
!
route-map UPSTREAM-IN permit 20
 match rpki notfound
 set local-preference 100
!
route-map UPSTREAM-IN deny 30
 match rpki invalid

Cenário 2: sua sessão com um cliente single-homed

O rascunho traz orientação explícita para clientes multi-homed, mas o caso single-homed ainda é 90% na América Latina. A recomendação nova: não filtrar por comprimento se o cliente tiver um ROA válido.

! Juniper JunOS
policy-statement CUSTOMER-IN {
    term VALID-ROA {
        from {
            protocol bgp;
            validation-database valid;
        }
        then {
            local-preference 200;
            accept;
        }
    }
    term INVALID-ROA {
        from validation-database invalid;
        then reject;
    }
    term NO-ROA {
        from validation-database unknown;
        then {
            local-preference 100;
            accept;
        }
    }
}

Veja a ordem: valid aceita com local-preference alto, invalid rejeita, unknown aceita com local-preference baixo. Assim você adota RPKI sem quebrar clientes que ainda não têm ROA.

Cenário 3: communities e segurança

O RFC 7454 não aprofundava o papel das communities na segurança operacional. O rascunho bgpopsecupd, ao recomendar fortemente não alterar atributos transitivos sem justificativa (SHOULD NOT), reforça indiretamente que fazer strip de todas as communities em sessões de peering é erro: há communities bem conhecidas que servem para mitigação (RTBH, RFC 7999) e sinalização de origem.

A recomendação operacional é documentar quais communities você aceita e de quem, em vez de fazer strip de tudo indiscriminadamente. Nós detalhamos isso no artigo sobre BGP communities para ISPs.

Configuração: transição a partir do RFC 7454

Nota: Os comandos de configuração abaixo são exemplos de referência. A sintaxe exata pode variar conforme a versão do sistema operacional de cada plataforma (FRRouting, JunOS, Huawei VRP). Sempre confira com a documentação oficial da versão que você está rodando.

Não precisa mudar tudo de um dia pro outro. A migração faz sentido em etapas:

Etapa Ação Impacto
1 Habilitar RPKI-RTR com seu RIR (LACNIC) Validação sem afetar rotas
2 Aplicar route-maps com rpki notfound permitido Ver qual porcentagem das suas rotas não tem ROA
3 Contatar clientes sem ROA e ajudá-los a criar Reduz o tráfego not-found
4 Remover prefix-lists baseados em comprimento Simplifica a operação
5 Habilitar BMP para o seu sistema de monitoramento Detecção de anomalias em tempo real

FRRouting: configuração completa de exemplo

! RPKI-RTR (requer bgpd compilado com -M rpki)
! A porta padrão do RTR é TCP 323 (RFC 8210); usa-se 8323 sem privilégios
rpki
 rpki cache tcp rpki.ejemplo.ayuda.la 8323 preference 1
 exit
!

! BLACKHOLE antes do RPKI: aceitar rotas RTBH mesmo se RPKI invalid
route-map UPSTREAM-IN permit 5
 match community BLACKHOLE
 set ip next-hop 192.0.2.1
!

! Route-maps com validação RPKI
route-map UPSTREAM-IN permit 10
 match rpki valid
 set local-preference 200
!
route-map UPSTREAM-IN permit 20
 match rpki notfound
 set local-preference 100
!
route-map UPSTREAM-IN deny 30
 match rpki invalid
!

! BGP neighbor com policy
router bgp 65001
 neighbor 198.51.100.1 remote-as 65002
 neighbor 198.51.100.1 route-map UPSTREAM-IN in

Huawei VRP: exemplo com route-policy

# Configurar validação RPKI
rpki
  rpki cache rpki.ejemplo.ayuda.la port 8323 preference 1
#

# Criar route-policy com validação
route-policy UPSTREAM-IN permit node 10
  if-match rpki origin-as-validation valid
  apply local-preference 200
#

route-policy UPSTREAM-IN permit node 20
  if-match rpki origin-as-validation not-found
  apply local-preference 100
#

route-policy UPSTREAM-IN deny node 30
  if-match rpki origin-as-validation invalid
#

# Aplicar ao peer dentro de address-family
bgp 65001
  peer 198.51.100.1 as-number 65002
  ipv4-family unicast
    peer 198.51.100.1 enable
    peer 198.51.100.1 route-policy UPSTREAM-IN import
    prefix origin-validation enable

Huawei VRP: exemplo equivalente com XPL

Em equipamentos NE40E / NetEngine 8000 com VRP V8R16+ dá para usar XPL (eXtensible Policy Language) no lugar de route-policy. A vantagem é que a lógica fica em um bloco só com if/elseif/endif, sem a fragmentação de nós numerados:

# Criar route-filter com validação RPKI
xpl route-filter UPSTREAM-IN
  if rpki-validation == valid then
    apply local-preference 200
    approve
  elseif rpki-validation == not-found then
    apply local-preference 100
    approve
  elseif rpki-validation == invalid then
    refuse
  endif
end-filter

# Aplicar ao peer dentro de address-family
bgp 65001
  peer 198.51.100.1 as-number 65002
  ipv4-family unicast
    peer 198.51.100.1 enable
    peer 198.51.100.1 route-filter UPSTREAM-IN import
    prefix origin-validation enable

A diferença operacional em relação ao route-policy: o XPL avalia as condições como um bloco sequencial com curto-circuito, o que deixa a lógica mais legível quando você tem várias condições em cadeia. Além disso, suporta variáveis parametrizadas ($var) que simplificam a reutilização de filtros entre peers com políticas parecidas.

Erros comuns vistos em auditorias

1. Filtrar por comprimento e achar que isso é segurança

Um prefix-list com ge 25 te dá falsa sensação de proteção. Um atacante com um /20 válido passa de boa. A única defesa de verdade é validar quem anuncia.

2. Não distinguir RPKI “invalid” de “not-found”

Invalid significa que existe um ROA dizendo que aquele AS não deve anunciar aquele prefixo. Isso se descarta.

Not-found significa que não há ROA. É outra coisa. Descartar isso quebra conectividade legítima. A prática operacional recomendada é clara: not-found deve ser aceito com preferência menor, não rejeitado. Descartar hoje deixaria sem conectividade uma fatia significativa da internet.

3. Fazer strip de communities sem saber o que elas fazem

Remover todas as communities em sessões de peering tira ferramentas úteis como RTBH. Se seu upstream te manda 65535:666 para blackholing e você faz strip de tudo, não dá pra mitigar um ataque DDoS sem esperar eles agirem.

4. Não monitorar BGP com BMP

Sem BMP, uma mudança sutil no Adj-RIB-In de um peer passa batida até o roteamento ser afetado. BMP deixa você detectar rotas novas, communities alteradas, ou withdraws em massa em segundos, não em horas.

Relação com outros temas

Essa mudança não existe no vácuo. Conecta diretamente com:

  • RPKI e ROAs: sem ROAs publicadas, a validação não funciona. Se você é LIR na LACNIC, publicar seus ROAs virou requisito operacional, não só boa prática.
  • BGP communities: o rascunho novo reforça a importância de não alterar atributos transitivos; as communities fazem parte do modelo de segurança, não são ruído pra eliminar.
  • BGP Roles e ASPA: RFC 9234 define roles de peering e o atributo OTC para prevenir route leaks. ASPA acrescenta validação de AS-PATH por relação de provider como camada depois de ROV.
  • DDoS e RTBH: communities bem conhecidas como 65535:666 (RFC 7999) viram ferramentas operacionais, não vetores de risco.

Nossa experiência em campo

Em mais de 40 auditorias realizadas entre 2025 e 2026 em ISPs da Argentina, Brasil, Chile e México, o padrão se repete:

  • 80% têm prefix-lists por comprimento que bloqueiam /25s e /26s de clientes com PI legítimo
  • 40% têm RPKI habilitado mas não aplicado em route-maps (só olham, não agem)
  • 90% fazem strip de todas as communities sem exceção
  • Menos de 10% usam BMP para monitoramento de BGP

A transição para a postura do rascunho bgpopsecupd-15 exige trabalho, mas reduz a carga operacional a longo prazo. Um route-map com três termos de RPKI é mais simples de manter que um prefix-list de 500 linhas que você precisa atualizar toda vez que um cliente pede um PI novo.

Precisa de ajuda?

Rever a política de roteamento de um ISP com 50 sessões BGP não é trivial. Se você quer uma auditoria dos seus filtros atuais, uma migração guiada para validação com RPKI, ou simplesmente alguém que revise sua configuração antes de um cliente reclamar que o /26 dele não aparece, a gente conversa.

Ver nossos serviços de engenharia de rede →

Falar com o time →

Referências

Já revisou seus prefix-lists hoje? Quantos prefixos legítimos você está bloqueando por comprimento sem perceber? Se achou um, escreve pra [email protected].