Resumen

  • La guía de RIPE NCC exige incluir todos los proveedores de tránsito, los vecinos con función de proveedor y los route servers no transparentes, pero dice que el panel RPKI no da ninguna pista sobre los proveedores observados para el AS en BGP.
  • El Plan de Actividades de 2026 prevé sugerencias basadas en quienes RIPE NCC considera proveedores ascendentes. Es una dirección de producto sin fecha de entrega, no una certificación de la relación.
  • Cada candidato debería llegar con fuente, punto de observación, periodo, familia de direcciones, motivo e incertidumbre. El operador lo clasifica y el recibo conserva la diferencia que finalmente se firma.

El dato decisivo de un ASPA no es la firma. Es la lista que existía un segundo antes de firmar.

RIPE NCC ya ofrece al titular de un sistema autónomo la posibilidad de crear un Autonomous System Provider Authorization. El objeto declara qué otros AS están autorizados como proveedores de tránsito del AS cliente. La firma vuelve verificable la declaración. No convierte una lista incompleta o mal clasificada en una descripción correcta de la red.

La documentación pública asigna al operador una obligación exigente. Debe incluir todos sus proveedores ascendentes y actualizar el objeto al mismo ritmo que cambia esa combinación. Si un vecino desempeña varios papeles y uno de ellos es el de proveedor, también debe figurar. Un route server no transparente de un punto de intercambio aparece en el AS_PATH como proveedor y ha de incluirse. Los pares laterales y los clientes, en cambio, no deben entrar.

El propio texto advierte qué ocurre si se olvida un proveedor: las rutas enviadas a través de ese AS podrían ser rechazadas. Acto seguido explica que el panel RPKI de RIPE NCC no da pistas ni orientación sobre los proveedores vistos para el AS en BGP. El titular tiene que asegurarse por sus propios medios.

Esa frase delimita el problema. El registro proporciona el mecanismo de publicación, pero no presenta al firmante el inventario de observaciones que podría ayudarle a revisar la declaración. El coste no está en rellenar un campo. Está en distinguir una relación autorizable de una mera proximidad en una ruta.

Completar y depurar son riesgos distintos

El perfil ASPA vigente en el IETF durante esta investigación era la revisión 29. Establece que un AS cliente con varios proveedores debe enumerarlos todos, incluidos los route servers no transparentes, y recomienda mantener un único objeto con el conjunto completo. El proyecto de verificación, en su revisión 28, señala las dos consecuencias de equivocarse.

Si se añade por error un proveedor, disminuye la capacidad de detectar fugas de rutas. Si falta uno, rutas legítimas pueden acabar evaluadas falsamente como ASPA Invalid. Los documentos siguen siendo Internet-Drafts, no RFC definitivos, pero la tensión de diseño ya es clara.

Una interfaz que solo busca exhaustividad puede sugerir demasiados AS. Una que busca precisión sin suficiente cobertura puede ocultar el proveedor de respaldo que aparece una vez al año. La primera amplía una autorización y reduce protección; la segunda deja preparada una posible falsa invalidez. El contador de sugerencias aceptadas no mide la seguridad de ninguna de las dos.

El inventario cotidiano suele capturar el tránsito principal. La dificultad está en las relaciones raras: respaldo frío, tránsito regional, sesiones heredadas tras una compra, vecinos con productos diferentes, route servers cuyo modo ha cambiado o proveedores que solo transportan IPv6. Son precisamente los casos que una memoria humana puede omitir y una fotografía corta de BGP puede no ver.

Un camino no trae la factura adjunta

BGP muestra una secuencia de AS desde un lugar y un instante. Cada colector observa lo que sus participantes le exportan después de muchas decisiones de política. Ningún punto de vista público es la red completa. Una adyacencia puede ser frecuente en Europa y ausente desde Asia, aparecer solo en IPv4, o surgir durante una ventana de mantenimiento.

Tampoco toda adyacencia es legítima. Una fuga, una configuración equivocada o una ruta transitoria puede colocar dos AS juntos. La frecuencia ayuda a medir persistencia, pero no prueba permiso. El AS_PATH no incorpora el contrato que indica quién compra tránsito, quién vende, quién intercambia tráfico entre iguales o qué funciones acumula una relación.

La telemetría BMP del propio operador ofrece una vista más cercana a la realidad local. Puede conservar lo recibido antes de aplicar política, por router y vecino. Sirve para descubrir rutas de respaldo y diferencias entre familias. Aun así, observa comportamiento; no adjudica la naturaleza comercial ni la intención técnica.

Por eso conviene separar cuatro autoridades. Los colectores y BMP producen evidencia. Los contratos, el inventario de sesiones y el diseño de la red clasifican la relación. El titular del AS autoriza. RIPE NCC publica el objeto, y más adelante validadores y routers lo consumen conforme a software y políticas locales.

Si el panel borra esas fronteras, una ayuda visual se convierte en una afirmación prestada. Si las conserva, cada sugerencia funciona como una pregunta auditada.

El plan anual ya contiene el verbo correcto

El Plan de Actividades y Presupuesto de RIPE NCC para 2026 propone mejorar la información de BGP utilizada en la gestión de ROA y ASPA. Para los ROA habla de acercarse a información en tiempo real. Para ASPA, de ofrecer sugerencias parecidas basadas en quienes RIPE NCC cree que son los proveedores ascendentes.

“Cree” es la palabra adecuada. Reconoce que el sistema infiere a partir de una observación y no que el registro haya adquirido autoridad sobre acuerdos privados. Una sugerencia puede reducir el trabajo de búsqueda sin decidir el resultado.

No hay, sin embargo, una fecha de entrega en ese pasaje. La página de planificación RPKI correspondiente al tercer trimestre de 2026, actualizada el 11 de junio, enumera cuatro asuntos: revocación automática de autoridades de certificación delegadas persistentemente inoperativas, sustitución de claves API por OpenID Connect, trabajos de cumplimiento y posible soporte API para Resource Signed Checklists. Las sugerencias de proveedores ASPA no aparecen entre ellos.

La omisión no demuestra incumplimiento, retraso o abandono. Solo muestra que la función no estaba nombrada en la lista trimestral capturada. Inventar un plazo convertiría el seguimiento en una acusación que los documentos no sostienen.

El Informe Anual 2025 aporta otra fecha firme: RIPE NCC lanzó el soporte para ASPA en su panel el 26 de noviembre de 2025. Es decir, la posibilidad de firmar llegó antes que la ayuda de evidencia descrita para 2026. La secuencia puede responder a una decisión conservadora: habilitar el estándar sin pretender conocer las relaciones. Para los primeros usuarios, trasladó toda la conciliación a su propia operación.

La defensa del formulario vacío

No sugerir puede ser prudente. RIPE NCC no ve todos los contratos de tránsito, enlaces privados, rutas de contingencia ni configuraciones de route servers. Un AS observado como vecino podría ser proveedor en una sesión, par en otra y cliente en un tercer contexto. Presentarlo como “su proveedor” dentro de un servicio de firma le otorgaría una autoridad que el dato no tiene.

La ubicación de la recomendación influye. Una lista prellenada junto al control de publicación parece haber sido validada por la institución. El usuario puede aceptarla en bloque, aunque el algoritmo solo haya contado caminos. La guía actual evita esa ficción y expresa el riesgo de omitir sin apropiarse de la decisión.

Pero la alternativa no tiene que ser la oscuridad. Es posible mostrar una observación con todas sus limitaciones y exigir que el operador la clasifique.

Qué debería contener el recibo de evidencia

Una lista de “proveedores probables” es demasiado pobre. Cada candidato necesita un expediente compacto.

Primero, procedencia: conjunto de datos, familia de puntos de observación, hora de captura y periodo analizado. Debe quedar claro si la señal procede de RIS, de otro colector público o de telemetría aportada por el operador. La ficha indicará IPv4 o IPv6, posición del AS en el camino, primera y última observación, número de apariciones y dispersión entre puntos de vista.

Después, contexto: si la adyacencia es permanente o solo aparece en contingencias; si está limitada a una región o familia; si hay indicios de que el ASN pertenece a un route server y de que este es transparente o no; si el proveedor figura en el ASPA actual pero ha dejado de verse, o si aparece a menudo y falta.

La advertencia no puede quedar escondida. La observación no demuestra un contrato, un rol, una autorización ni la completitud de la lista. Una puntuación de confianza debe referirse a la robustez de la señal, no a la verdad del vínculo comercial. También debe constar la versión de la regla o modelo que generó el candidato.

La decisión humana requiere varias salidas: aceptar como proveedor, rechazar como par o cliente, marcar una relación de varios roles, identificar una configuración temporal o de respaldo, o aplazar la decisión. El operador puede vincular internamente un inventario de sesiones o documento contractual sin exponerlo al público.

En el momento de firmar, el panel conservará la propuesta, las decisiones, la diferencia entre conjuntos, la persona responsable, el instante y el hash del objeto publicado. Una corrección futura enlazará con esa versión. El historial explicará por qué un ASN entró, salió o nunca fue aceptado.

El ASPA sigue siendo la autorización pública. El recibo es el rastro de cómo se convirtió evidencia imperfecta en una decisión consciente.

Observar el efecto es otra pregunta

Una contribución comunitaria publicada en RIPE Labs el 29 de junio de 2026 analiza la falta de visibilidad después de crear un ASPA. Sus autores construyeron RAVEN para combinar rutas recibidas mediante BMP con datos RPKI servidos por RTR v2, anotar resultados y ensayar escenarios hipotéticos.

No es un compromiso de producto de RIPE NCC; la página identifica al autor como colaborador de la comunidad. Sí ilustra una segunda mitad necesaria. Antes de firmar, el operador debe preguntar si la lista representa sus relaciones. Después, debe preguntar cómo clasificaría los caminos que realmente recibe.

Un modo hipotético no decide dónde está el error. Si una ruta aparece como Invalid, puede faltar un proveedor en el objeto, sobrar un camino en la red o faltar información en el análisis. La simulación muestra consecuencias. No reemplaza el conocimiento de la relación.

La mejor secuencia une inventario, observación y prueba de impacto. Ningún paso hereda automáticamente la autoridad del siguiente.

El respaldo olvidado despierta en el peor momento

Un proveedor habitual ausente suele detectarse pronto. Uno de respaldo puede no aparecer durante meses. El ASPA se publica sin un fallo visible. Después llega una avería, un mantenimiento o un cambio de ingeniería. La ruta excepcional pasa a transportar tráfico cuando la resiliencia es más necesaria.

Las fuentes revisadas no prueban que un miembro concreto de RIPE NCC haya sufrido ese resultado ni que un router haya rechazado una ruta debido a un ASPA existente. La verificación sigue evolucionando y la aplicación depende de decisiones locales. El riesgo es de arquitectura, no una acusación sobre un incidente.

Precisamente por ello conviene mover la revisión hacia delante. Una sugerencia fechada puede recordar el proveedor silencioso antes de la firma. Un recibo puede dejar claro que el operador lo revisó y por qué lo incluyó o descartó. Lo que no debe hacer es concluir la relación por él.

RIPE NCC puede cerrar este vacío sin ensanchar su poder. Debe mostrar qué ve, desde dónde y durante cuánto tiempo; separar observación y rol; y conservar la transformación final. BGP aporta candidatos. El operador aporta significado. La firma solo merece confianza cuando ese orden permanece visible.

Fuentes