BGP Seguridad-de-Routing RPKI ISP Redes Protocolos

Después de RFC 7454: qué cambia en la seguridad de BGP y cómo preparar tu red

Ariel S. Weher
Después de RFC 7454: qué cambia en la seguridad de BGP y cómo preparar tu red

Introducción: una política que envejeció mal

En 2015, RFC 7454 / BCP 194 se convirtió en la biblia de la seguridad de BGP. Recomendaba filtrar agresivamente: nada más específico que un /24 en IPv4, nada más largo que un /48 en IPv6, prefix-lists estáticos, y un largo etcétera de reglas que hoy generan más problemas que los que resuelven.

La realidad en el campo es distinta. Filtrar todo /25 o más específico deja fuera a clientes legítimos con PI que necesitan anunciar bloques pequeños. Un prefix-list estático con 50.000 entradas no escala. Y lo peor: el filtrado por longitud no te protege contra un hijack de un /20 válido.

El 7 de abril de 2026, el grupo de trabajo GROW del IETF publicó la revisión 15 de draft-ietf-grow-bgpopsecupd, el documento que reemplazará a RFC 7454 cuando complete su recorrido como BCP. A la fecha de este artículo está en WG Last Call —todavía no es RFC, pero la dirección es clara y el contenido está estabilizado. El cambio de fondo: deja de centrarse en el tamaño del prefijo y apunta a la validación del origen.

Si operás un ISP en LatAm, esto te obliga a revisar tus filtros de entrada y salida. No es opcional.

Qué propone el draft

La filosofía del documento cambia de defensa por filtrado a defensa por validación. El draft es deliberadamente abstracto —establece propiedades que un operador DEBE cumplir sin prescribir tecnologías específicas— pero la dirección operativa es clara. Combinando lo que dice el draft con lo que consideramos buena práctica actual, la comparación queda así (las filas marcadas con † son recomendación operativa nuestra, no requisitos del draft):

Eje RFC 7454 (2015) Postura operativa post-bgpopsecupd
Filtro por longitud Filtrar ≥/25 IPv4, ≥/49 IPv6 El draft elimina las recomendaciones por longitud; la longitud no indica legitimidad
Validación de origen Menciona IRR como opcional El draft exige que el origen esté “globally authorized”; en la práctica, eso es RPKI + ROA con IRR como complemento
Atributos transitivos No profundiza El draft recomienda fuertemente no alterar atributos transitivos inmutables (SHOULD NOT) y prohíbe transportar estados RPKI en atributos transitivos (MUST NOT)
BGP Roles † No existía RFC 9234 define roles (Provider, Customer, Peer) y el atributo OTC para prevención de route leaks
ASPA † No existía Los drafts de ASPA (draft-ietf-sidrops-aspa-verification) agregan validación de AS-PATH por relación de provider
Communities † No profundiza Recomendación operativa: documentar qué communities se aceptan, no strippear indiscriminadamente
Monitoreo † SNMP, syslog básico BMP (RFC 7854) como herramienta de detección de anomalías

El punto clave: la longitud del prefijo no es un indicador de ataque. Un /24 hijackeado es tan peligroso como un /25 legítimo. El enfoque nuevo es validar quién tiene derecho a anunciar ese prefijo, no cuántos bits tiene.

Cómo se ve en la práctica

Escenario 1: tu sesión con un upstream

Hoy probablemente tengas algo así:

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

Esto bloquea /25s de clientes con PI que pasan por ese upstream. Con la nueva recomendación, el filtro por longitud desaparece y lo reemplaza validación por 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

Escenario 2: tu sesión con un cliente single-homed

El draft agrega guía explícita para clientes multi-homed, pero el caso single-homed sigue siendo el 90% en LatAm. La recomendación nueva: no filtrar por longitud si el cliente tiene un 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;
        }
    }
}

Notá el orden: valid acepta con local-preference alto, invalid rechaza, unknown acepta con local-preference bajo. Esto te permite adoptar RPKI sin romper clientes que todavía no tienen ROA.

Escenario 3: communities y seguridad

RFC 7454 no profundizaba en el rol de las communities en la seguridad operativa. El draft bgpopsecupd, al recomendar fuertemente no alterar atributos transitivos sin justificación (SHOULD NOT), refuerza indirectamente que strippear todas las communities en sesiones de peering es un error: hay communities bien conocidas que sirven para mitigación (RTBH, RFC 7999) y señalización de origen.

La recomendación operativa es documentar qué communities aceptás y de quién, en lugar de strippear todo indiscriminadamente. Esto lo tratamos en detalle en el artículo sobre BGP communities para ISPs.

Configuración: transición desde RFC 7454

Nota: Los comandos de configuración que se muestran a continuación son ejemplos de referencia. La sintaxis exacta puede variar según la versión del sistema operativo de cada plataforma (FRRouting, JunOS, Huawei VRP). Verificá siempre contra la documentación oficial de la versión que estés ejecutando.

No hace falta cambiar todo de un día para el otro. La migración tiene sentido en etapas:

Etapa Acción Impacto
1 Habilitar RPKI-RTR con tu RIR (LACNIC) Validación sin afectar rutas
2 Aplicar route-maps con rpki notfound permitido Observar qué porcentaje de tus rutas no tiene ROA
3 Contactar clientes sin ROA y asistirlos en la creación Reduce el tráfico not-found
4 Eliminar prefix-lists basados en longitud Simplifica operación
5 Habilitar BMP hacia tu sistema de monitoreo Detección de anomalías en tiempo real

FRRouting: configuración completa de ejemplo

! RPKI-RTR (requiere bgpd compilado con -M rpki)
! El puerto estándar de RTR es TCP 323 (RFC 8210); se usa 8323 cuando no se
! tienen privilegios de puerto bajo
rpki
 rpki cache tcp rpki.ejemplo.ayuda.la 8323 preference 1
 exit
!

! BLACKHOLE antes de RPKI: aceptar rutas RTBH aunque sean RPKI invalid
route-map UPSTREAM-IN permit 5
 match community BLACKHOLE
 set ip next-hop 192.0.2.1
!

! Route-maps con validación 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 con policy
router bgp 65001
 neighbor 198.51.100.1 remote-as 65002
 neighbor 198.51.100.1 route-map UPSTREAM-IN in

Huawei VRP: ejemplo con route-policy

# Configurar validación RPKI
rpki
  rpki cache rpki.ejemplo.ayuda.la port 8323 preference 1
#

# Crear route-policy con validación
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 al 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: ejemplo equivalente con XPL

En equipos NE40E / NetEngine 8000 con VRP V8R16+ se puede usar XPL (eXtensible Policy Language) en lugar de route-policy. La ventaja es que la lógica queda en un solo bloque con if/elseif/endif, sin la fragmentación de nodos numerados:

# Crear el route-filter con validación 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 al 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

La diferencia operativa con route-policy: XPL evalúa las condiciones como un bloque secuencial con cortocircuito, lo que hace la lógica más legible cuando tenés múltiples condiciones encadenadas. Además, soporta variables parametrizadas ($var) que simplifican la reutilización de filtros entre peers con políticas similares.

Errores comunes observados en auditorías

1. Filtrar por longitud y confundir eso con seguridad

Un prefix-list con ge 25 te da falsa sensación de protección. Un atacante con un /20 válido pasa sin problemas. La única defensa real es validar quién anuncia.

2. No distinguir RPKI “invalid” de “not-found”

Invalid significa que hay un ROA que dice que ese AS no debe anunciar ese prefijo. Eso se descarta.

Not-found significa que no hay ROA. Eso es diferente. Descartarlo rompe conectividad legítima. La práctica operativa recomendada es clara: not-found debe aceptarse con preferencia menor, no rechazarse. Descartarlo hoy dejaría sin conectividad a una porción significativa de internet.

3. Strippear communities sin saber qué hacen

Sacar todas las communities en sesiones de peering elimina herramientas útiles como RTBH. Si tu upstream te envía 65535:666 para blackholing y vos strippeás todo, no podés mitigar un ataque DDoS sin esperar que ellos actúen.

4. No monitorear BGP con BMP

Sin BMP, un cambio sutil en el Adj-RIB-In de un peer pasa desapercibido hasta que afecta el forwarding. BMP te permite detectar rutas nuevas, communities cambiadas, o withdraws masivos en segundos, no horas.

Relación con otros temas

Este cambio no existe en vacío. Se conecta directamente con:

  • RPKI y ROAs: sin ROAs publicadas, la validación no funciona. Si sos LIR en LACNIC, publicar tus ROAs es ahora un requisito operativo, no una buena práctica.
  • BGP communities: el draft nuevo refuerza la importancia de no alterar atributos transitivos; las communities son parte del modelo de seguridad, no ruido a eliminar.
  • BGP Roles y ASPA: RFC 9234 define roles de peering y el atributo OTC para prevenir route leaks. ASPA agrega validación de AS-PATH por relación de provider como siguiente capa después de ROV.
  • DDoS y RTBH: communities bien conocidas como 65535:666 (RFC 7999) se convierten en herramientas operativas, no en vectores de riesgo.

Nuestra experiencia en campo

En más de 40 auditorías realizadas entre 2025 y 2026 en ISPs de Argentina, Brasil, Chile y México, el patrón se repite:

  • 80% tienen prefix-lists por longitud que bloquean /25s y /26s de clientes con PI legítimos
  • 40% tienen RPKI habilitado pero no aplicado en route-maps (solo miran, no actúan)
  • 90% strippean todas las communities sin excepción
  • Menos del 10% usan BMP para monitoreo de BGP

La transición a la postura del draft bgpopsecupd-15 requiere trabajo, pero reduce la carga operativa a largo plazo. Un route-map con tres términos de RPKI es más simple de mantener que un prefix-list de 500 líneas que hay que actualizar cada vez que un cliente pide un PI nuevo.

¿Necesitás ayuda?

Revisar la política de ruteo de un ISP con 50 sesiones BGP no es trivial. Si querés una auditoría de tus filtros actuales, una migración guiada a validación por RPKI, o simplemente alguien que revise tu configuración antes de que un cliente se queje de que su /26 no se ve, hablamos.

Ver nuestros servicios de ingeniería de redes →

Contactar al equipo →

Referencias

¿Ya revisaste tus prefix-lists hoy? ¿Cuántos prefijos legítimos estás bloqueando por longitud sin saberlo? Si encontraste uno, escribinos a [email protected].