Resumen

  • Una ASPA es un objeto RPKI firmado con el que un AS cliente autoriza un conjunto de AS proveedores. Atestigua una relación para un algoritmo, no cada salto de la ruta.
  • La verificación ofrece Valid, Invalid o Unknown según los objetos disponibles y el contexto de propagación. No sustituye la validación de origen, la identidad real ni la política del operador.
  • La garantía operativa exige separar validez, integridad del inventario, hora del caché, rol de sesión, resultado, acción local e incertidumbre.

La etiqueta «Valid» parece una conclusión total. En ASPA es más limitada: la ruta observada es compatible con las autorizaciones cliente-proveedor que el algoritmo puede evaluar en la dirección pertinente. Es una conclusión útil, pero no una historia firmada de cada salto.

El perfil ASPA actual, todavía un Internet-Draft, define un objeto firmado dentro de RPKI. El titular del identificador del AS cliente enumera sus proveedores autorizados. El perfil espera que estén todos y que se publique un solo objeto por cliente. El relying party valida el objeto antes de utilizar su carga.

La pregunta es concreta: ¿ha autorizado el cliente a este proveedor en los datos publicados? El objeto no contiene el prefijo anunciado. Las ROA y la validación de origen responden a esa dimensión. Por eso los borradores tratan ambos controles como complementarios.

La firma tampoco autentica una organización del mundo real. RFC 9255 explica que la RPKI acredita autoridad sobre recursos, no identidad. Un objeto válido no demuestra un contrato vigente, la exactitud de una entrada administrativa ni un intercambio de tráfico actual.

La integridad del conjunto es el siguiente límite. El borrador de verificación espera que el cliente registre todos sus proveedores y los servidores de rutas no transparentes pertinentes. Omitir un proveedor legítimo puede convertir una ruta correcta en Invalid a medida que crece la cobertura. La firma puede ser válida y la declaración, incompleta.

El algoritmo conserva esta incertidumbre. Una relación puede ser Provider+, Not Provider+ o No Attestation; una ruta puede ser Valid, Invalid o Unknown. Unknown no es una versión débil de Invalid: significa que faltan pruebas para concluir. Valid tampoco demuestra origen autorizado, firma de cada AS ni cumplimiento de toda política de exportación.

ASPA y BGPsec tienen semánticas distintas. ASPA compara la ruta con autorizaciones publicadas por separado; no firma el camino salto a salto. El orden también importa. RFC 9774 desaconseja AS_SET y AS_CONFED_SET porque una colección sin orden impide reconstruir la dirección cliente-proveedor.

Los Roles BGP de RFC 9234 aportan contexto sobre la relación de una sesión y la prevención de fugas. Sin embargo, una capacidad negociada no es un registro comercial universal. El operador receptor sigue decidiendo cómo incorporar el resultado a su selección de rutas.

Un registro sólido conserva seis capas: objeto ASPA validado; evidencia de que el inventario está completo; observación del caché y hora; ruta ordenada y rol; resultado con causa; acción local, responsable y caducidad. El tiempo de cada capa es independiente. Un proveedor añadido el viernes, un objeto cambiado el sábado y un caché actualizado el domingo son estados diferentes.

Los borradores citados todavía pueden cambiar y aquí no se atribuye ningún incidente a una red real. La lección es estable: ASPA es una autorización acotada de proveedores. Mantener por separado su validez, integridad y uso evita convertir una señal en una afirmación excesiva.

Fuentes