Resumen

  • El IESG aprobó el 22 de junio de 2026 una Best Current Practice que prohíbe transportar estados de validación derivados de RPKI en atributos BGP enviados por EBGP entre dominios administrativos. La revisión 12 está en la cola del RFC Editor.
  • El estado es una propiedad local calculada a partir de una vista RPKI y un momento concretos. Copiarlo a un atributo no firmado no autentica el resultado y puede hacer que cambios de ROA, fallos de caché o expiraciones RTR obliguen a readvertir cientos de miles de rutas.

Tres palabras esconden una cadena completa

RFC 6811 define NotFound, Valid e Invalid. El hablante BGP compara el prefijo y el AS de origen de la ruta con los Validated ROA Payloads que tiene almacenados localmente. El propio RFC indica que el resultado debe tratarse como una propiedad local de la ruta.

La cadena que produce ese resultado tiene varias piezas: objetos firmados recuperados por la relying party, validación correcta de esos objetos, actualización de la caché, sesión RTR disponible y política local. Dos redes pueden observar estados distintos durante un intervalo porque sus ciclos y dependencias no son idénticos.

El atributo que cruza la frontera resume toda esa cadena en un valor. No informa qué VRP existían, cuándo se refrescaron, si una fuente estaba incompleta o qué regla se aplicó. El receptor no puede reconstruir el razonamiento a partir de la etiqueta.

Tampoco puede autenticarlo. La guía aprobada recuerda que los atributos BGP que circulan por EBGP no están firmados y pueden ser añadidos por terceros. Un Valid recibido es, como máximo, una afirmación sobre la posible visión pasada del remitente. No es una prueba reproducible para el vecino.

La frontera administrativa estaba en RFC 8097

RFC 8097 creó una Extended Community no transitiva para compartir el estado de validación dentro de un sistema autónomo. Permitía que hablantes IBGP bajo una relación de confianza reutilizaran un cálculo sin que todos ejecutaran el mismo proceso.

Por defecto, una implementación debe descartar esa comunidad si llega desde un peer EBGP y no debería enviarla a peers EBGP. La excepción razonable son AS adyacentes bajo una misma administración. El límite relevante es, por tanto, el dominio que controla la evidencia y responde por ella.

El nuevo documento extiende esa regla a cualquier comunidad o atributo que codifique un resultado RPKI y cuya modificación provoque UPDATE hacia vecinos externos. Incluye comunidades estándar, extendidas, grandes, valores propios de operadores y futuros atributos. También cubre estados locales obtenidos de ASPA o BGPsec si se intenta exportarlos de la misma manera.

Puede haber equipos que necesiten la anotación internamente. La guía lo admite, pero obliga a retirarla antes de anunciar NLRI a un dominio administrativo distinto. Una limitación interna no puede convertirse por accidente en confianza delegada.

Un fallo central, dos oleadas separadas

La guía trabaja con AS65536 como cliente de AS65537. Ambos consultan el mismo servicio RTR con un ciclo de 300 segundos y ambos cambian comunidades según la validación. Es un escenario explicativo, no un incidente observado.

AS65536 se actualiza un segundo antes de la caída. AS65537 debía hacerlo un segundo después. El proveedor pierde primero los payloads validados, cambia rutas de Valid a NotFound y, al cambiar las comunidades, envía un gran conjunto de UPDATE hacia sus clientes. AS65536 procesa y propaga ese conjunto.

Unos 300 segundos más tarde, expira la vista de AS65536. Sus propias comunidades cambian y aparece una segunda oleada por la misma avería. Una caché de respaldo puede retrasar el episodio; si la interrupción supera su TTL, no elimina la secuencia.

La conexión causal importa. No cambió necesariamente la alcanzabilidad, el origen ni el AS_PATH. Falló una dependencia de validación. Al convertir su salida en parte del camino externo, se hizo pagar el fallo al plano de control BGP.

El coste no es marginal

Una medición de febrero de 2024 citada por el documento halló que entre el 8 % y el 10 % de los BGP UPDATE vistos en RIS contenían comunidades públicas asociadas a NotFound o Valid. La creación o eliminación de un ROA también generó cadenas de actualizaciones durante aproximadamente una hora. Es una fotografía temporal, no una tasa universal.

Para mediados de 2026, la guía usa una tabla combinada de IPv4 e IPv6 de unos 1,3 millones de prefijos, con cerca del 65 % cubierto por ROA. Si un fallo de caché cambia los estados y estos se exportan como atributos, podrían reenviarse más de 850.000 rutas.

El problema no reside en que el router vuelva a validar. Esa es la función correcta. El desperdicio aparece cuando una variación de evidencia local modifica la identidad externa de la ruta y obliga a vecinos que no ganan evidencia verificable a consumir CPU, memoria y ancho de cola.

Además, un atacante que pueda emitir y retirar objetos firmados para sus propios prefijos puede crear cambios repetidos. Quien readvierte NLRI también puede alterar atributos no firmados. La anotación externa convierte esos actos en una palanca de churn.

La ruta expresa el efecto de la política

Si un operador valida RPKI y rechaza rutas Invalid, esas rutas no deberían llegar a sus clientes. La selección de rutas exportadas ya expresa el efecto de la política del remitente. Una comunidad adicional no aporta al receptor una prueba autenticada de por qué ocurrió.

El vecino que necesite seguridad de origen debe validar con su vista actual. Así conserva la relación entre evidencia, tiempo y decisión. Aceptar el estado ajeno como autoridad confunde cooperación con permiso: la etiqueta puede describir lo que otro dominio hizo, pero no puede decidir por el dominio receptor.

La salida operativa es estrecha y comprobable. Validar localmente, aplicar política local, permitir atributos de estado sólo dentro del mismo control y retirarlos en cada borde externo. Exportar la ruta que superó la decisión; no exportar una explicación sin firma como si fuese la decisión del siguiente operador.

Fuentes