La adopción de RPKI en la región creció de forma sostenida en los últimos años, y con ella apareció una confusión recurrente: se habla de “RPKI” como si fuera una sola cosa que se enciende o se apaga. En realidad son varias piezas distintas, y ASPA —la incorporación más reciente— se entiende mucho mejor si primero las separamos.
Tres piezas que no hay que mezclar
RPKI es la infraestructura de clave pública que asocia recursos de numeración con certificados, siguiendo la cadena de delegación real de esos recursos (RFC 6480). Por sí sola no toma ninguna decisión de ruteo: es el sustrato sobre el que se firman objetos, es decir, afirmaciones verificables acerca de esos recursos.
Un ROA es uno de esos objetos (RFC 9582). En él, el titular de un bloque de direcciones declara qué AS está autorizado a originar ese prefijo en BGP. Es una afirmación publicada; no ejerce ningún efecto por sí misma.
(Acceso libre, no requiere suscripción)
ROV es el procedimiento que el operador corre en sus routers (RFC 6811): compara cada anuncio BGP recibido contra los ROA validados y lo clasifica como Valid, Invalid o NotFound. Qué hacer con ese resultado es una decisión de política local.
La distinción tiene una consecuencia práctica. Publicar ROA protege a los prefijos propios frente a quienes hacen ROV; hacer ROV protege a la red propia frente a los anuncios incorrectos de terceros. Son acciones distintas, con beneficiarios distintos, y ninguna implica la otra.
Lo que la validación de origen (ROV) no puede ver
ROV responde una sola pregunta: ¿el AS que origina este prefijo está autorizado a originarlo? Eso alcanza para detectar el secuestro de origen clásico, y es motivo suficiente para desplegarlo.
ROV es el procedimiento que el operador corre en sus routers (RFC 6811): compara cada anuncio BGP recibido contra los ROA validados y lo clasifica como Valid, Invalid o NotFound. Qué hacer con ese resultado es una decisión de política local.
La distinción tiene una consecuencia práctica. Publicar ROA protege a los prefijos propios frente a quienes hacen ROV; hacer ROV protege a la red propia frente a los anuncios incorrectos de terceros. Son acciones distintas, con beneficiarios distintos, y ninguna implica la otra.
Lo que la validación de origen (ROV) no puede ver
ROV responde una sola pregunta: ¿el AS que origina este prefijo está autorizado a originarlo? Eso alcanza para detectar el secuestro de origen clásico, y es motivo suficiente para desplegarlo.
Pero ROV mira el origen y no dice nada sobre el resto del AS_PATH. De ahí salen dos problemas que no detiene.
El primero son los route leaks: la propagación de un anuncio más allá de su alcance previsto (RFC 7908), típicamente un AS multihomed que reanuncia hacia un proveedor lo que aprendió de otro. El origen es legítimo y el ROA coincide, así que para ROV el anuncio es Valid. Lo que está mal no es el origen sino la forma del camino.
El segundo es el secuestro con origen falsificado. Un atacante no necesita anunciar el prefijo con su propio AS: le alcanza con anteponer el AS legítimo al AS_PATH y anunciarlo como si lo hubiera aprendido de él. El anuncio exhibe el origen correcto, satisface el ROA y queda Valid. ROV, por construcción, no puede distinguirlo de uno genuino.
No se trata de un defecto de implementación. ROV valida el origen, no el camino.
Qué agrega ASPA
ASPA ataca precisamente ese punto ciego. El titular de un AS publica un objeto firmado que enumera los AS autorizados a actuar como sus proveedores de tránsito: el mismo tipo de afirmación que un ROA, pero sobre relaciones BGP de tipo cliente-proveedor (tránsito) en lugar de sobre originación de prefijos.
Cada sistema autónomo conoce siempre su “primer salto” sin ambigüedades, es decir, qué ASes le proveen tránsito hacia Internet. Lo que no puede conocer con la misma certeza son los saltos siguientes, y por eso no puede afirmar nada sobre ellos.
En ASPA la apuesta es a construir un modelo incremental de validación de caminos en el que cada AS declara cuáles son sus “primeros saltos”. Con un conjunto suficiente de objetos ASPA publicados, un operador puede verificar si cada salto del AS_PATH se corresponde con una relación cliente-proveedor efectivamente autorizada. Ya no hay que creerle al camino: se lo contrasta contra declaraciones firmadas por los titulares de cada AS.
La verificación se apoya en la forma que tiene un camino legítimo. Sube por una cadena de relaciones cliente-proveedor, opcionalmente cruza un enlace lateral entre pares, y baja por otra cadena. Son la rampa ascendente y la rampa descendente.
Estructura de un AS_PATH legítimo. Las flechas indican relaciones cliente-proveedor, no el sentido de propagación del anuncio.
El procedimiento recorre el camino recibido y comprueba que tenga esa forma, con un criterio que depende de quién envió la ruta: si llega de un cliente o de un par no debería haber rampa descendente, y su aparición es justamente la firma de un route leak. El resultado es Valid, Invalid o Unknown, este último cuando falta información ASPA para decidir.
Conviene no mezclar vocabularios: donde ROV dice NotFound, ASPA dice Unknown. Un anuncio puede ser perfectamente Valid para ROV e Invalid para ASPA, y ese es exactamente el caso que ASPA vino a resolver.
¿En qué estado está el despliegue de ASPA en 2026?
Conviene ser explícito, porque circula bastante confusión: ASPA todavía no es un RFC. Los dos documentos centrales siguen siendo Internet-Drafts en el grupo de trabajo SIDROPS del IETF. Ya existen implementaciones —FORT, Routinator y rpki-client procesan objetos ASPA— y un número creciente de RIR permite publicarlos, pero los detalles todavía pueden cambiar, en particular en lo que tiene que ver con el algoritmo de validación.
La cobertura lógicamente todavía es baja: a septiembre de 2026 los ASPA publicados cubren alrededor del 2,9 % del espacio global de ASN. Hoy la enorme mayoría de los caminos daría Unknown. Es la misma curva que recorrió ROA hace una década.
Sin embargo, considero que es una muestra de interés fuerte de parte de la comunidad de operadores el hecho de que exista un movimiento incipiente de creación de ASPA a pesar de que el trabajo de normalización en el IETF aún no finalizó.
Para un operador que esté evaluando qué hacer, el orden de prioridades no cambió: publicar ROA correctos para los prefijos propios y desplegar ROV siguen siendo el primer paso. ASPA se apoya sobre ese trabajo en lugar de reemplazarlo.
