Resumen

  • Un ASPA firmado enumera proveedores autorizados de un AS cliente, pero el resultado depende de qué versión llegó al validador y al router cuando apareció la ruta.
  • La revisión 28 recomienda prepublicar proveedores de reserva, tratar Unknown como Valid en preferencia y conservar rutas Invalid para reevaluarlas; ninguna de esas decisiones demuestra por sí sola instalación, reenvío o recuperación del servicio.

Dos relojes para una sola conmutación

El equipo de red contrata un proveedor de mitigación y lo mantiene en espera. Cuando llega el ataque, anuncia por esa relación. Si el ASN del proveedor ya estaba en el ASPA, el cambio puede atravesar la verificación. Si la autorización se publicó al mismo tiempo que el failover, algunas redes pueden recibir primero la ruta y otras el objeto.

Para estas últimas, una lista válida que omite al nuevo proveedor produce Not Provider+. El camino puede resultar Invalid aunque el cambio sea comercialmente autorizado. La revisión 28 recomienda incluir proveedores de reserva y emergencia con antelación precisamente para evitar esa carrera.

El documento fue publicado el 24 de agosto de 2026, expira el 25 de febrero de 2027 y sigue siendo un Internet-Draft activo de SIDROPS. Está en WG Consensus: Waiting for Write-Up y su estado IESG es I-D Exists. No es un RFC ni prueba una implantación concreta.

Una atestación completa, no una sesión viva

El perfil ASPA permite que el titular de un ASN cliente firme el conjunto de AS proveedores. La firma y la cadena RPKI prueban que el titular hizo la declaración dentro de su autoridad de recursos. No prueban que la relación esté activa, que el contrato cubra IPv4 e IPv6 por igual ni que una sesión BGP haya aceptado el anuncio.

El cliente debería mantener un solo objeto con todos sus proveedores. Si existen varios objetos válidos, el verificador usa la unión. Ese diseño evita que un objeto parcial suprima un proveedor, pero también hace más permisivo el resultado mientras coexistan listas diferentes.

Un error tiene efectos asimétricos. Añadir un proveedor que no corresponde reduce la capacidad de detectar fugas. Omitir uno real puede convertir rutas legítimas en Invalid. “Objeto criptográficamente válido” solo responde a integridad y autoridad de firma; no certifica que el contenido sea operacionalmente correcto hoy.

Provider+, ausencia y contradicción

La función authorized(x, y) examina si y figura como proveedor de x. Devuelve Provider+ cuando figura, Not Provider+ cuando existe una lista válida pero no lo incluye y No Attestation cuando no se obtuvo ningún ASPA utilizable.

La tercera respuesta protege el despliegue gradual. No encontrar una atestación no equivale a encontrar una negativa. Tras comprimir repeticiones consecutivas del AS_PATH, el algoritmo construye límites mínimos y máximos para las rampas cliente-proveedor.

Una contradicción limita la rampa máxima. Una ausencia limita lo que puede probarse como mínimo. Si ni la posibilidad máxima cubre el camino, es Invalid. Si podría cubrirlo pero faltan objetos, es Unknown. Si la evidencia positiva basta, es Valid.

La etiqueta describe la relación entre el camino observado, los objetos disponibles y el algoritmo elegido. No demuestra por dónde circularon los paquetes ni cuál AS introdujo el error.

El rol local elige el algoritmo

Para rutas recibidas de clientes o pares se aplica el algoritmo ascendente, que espera una sola rampa. Para rutas recibidas de proveedores se aplica el descendente, capaz de reconocer subida y bajada. La clasificación del vecino es una entrada local.

Los Roles BGP de RFC 9234 ayudan a configurar y cruzar esa información. Una relación Complex puede exigir sesiones separadas o una decisión por prefijo. Si no se puede, la revisión 28 permite el algoritmo descendente para evitar falsos positivos. La concesión favorece continuidad, pero deja más formas de camino como posibles.

Por eso un auditor debe conservar el rol, AFI/SAFI, prefijo y procedimiento aplicado. El mismo AS_PATH puede recibir otra evaluación si cambia la relación que el router cree mantener con el vecino.

Unknown no se convierte en Valid

La política recomendada hace que Unknown tenga la misma preferencia que Valid. Es una regla contra el castigo por ausencia de cobertura, no una fusión semántica. Unknown sigue diciendo “faltan pruebas para cerrar el cálculo”.

Invalid debería quedar fuera de selección, pero mantenerse en Adj-RIB-In. Si aparece el ASPA corregido, el router puede reevaluar la ruta sin esperar otro anuncio. RFC 9324 recoge la misma lección operativa para políticas basadas en RPKI: los datos de validación cambian por un canal distinto al de BGP.

Después de ASPA, BGP todavía debe seleccionar. Loc-RIB registra el resultado de control. El FIB debe recibirlo. Los paquetes deben cruzar el siguiente salto. Un servicio debe responder. “Misma preferencia” no afirma ninguna de esas etapas.

La familia de direcciones queda fuera del objeto

U-SPAS usa una sola unión para unicast IPv4 e IPv6. Si la relación con un proveedor existe solo para IPv4, también vuelve permisiva la evaluación IPv6. El borrador lo acepta para simplificar el registro y evitar falsos Invalid.

La consecuencia es precisa: Valid no certifica que el contrato o la sesión con ese proveedor cubra la familia concreta. Esa evidencia debe venir de configuración, inventario y observación local.

Durante una migración entre autoridades de certificación, los objetos relevantes deberían permanecer idénticos. No basta con que el estado final sea correcto. Hay que saber qué copia vio cada relying party mientras convivieron los árboles.

Un fallo calculado no identifica al autor

El router debería registrar qué saltos dieron Not Provider+, pero no siempre puede descubrir quién provocó la fuga. El primer par incompatible puede reflejar una lista atrasada, una migración incompleta o una manipulación anterior.

La revisión también reconoce ataques de proveedor que ASPA puede no detectar y que añadir o quitar repeticiones del AS_PATH queda fuera de su visión. OTC, ROA y BGPsec cubren afirmaciones diferentes: propagación local, autorización de origen o recorrido firmado. Ninguno puede absorber a los demás.

La cadena de auditoría debe conservar documento, objeto y hash; snapshot del repositorio y versión del validador; rol local; AS_PATH bruto, reconstruido y comprimido; resultado de cada par; límites de rampas; estado final; política aplicada; Loc-RIB, FIB y métricas del servicio.

La disciplina de Lu Heng evita que la coordinación se vuelva soberanía. El objeto firmado tiene autoridad sobre una afirmación limitada. El router tiene autoridad sobre su decisión ejecutada. Solo la observación tiene autoridad sobre el resultado.

Lo que no prueban las fuentes

El paquete congelado demuestra reglas propuestas y límites declarados. No prueba que una implementación cumpla, que un failover real haya sufrido esta carrera ni que ASPA haya reducido fugas en producción. El caso inicial es un mecanismo operativo, no un incidente atribuido.

Fuentes