Resumen

  • APNIC explicó en APNIC 62 que su interfaz ASPA alojada obtiene sugerencias de proveedores de RIPE RIS. Son probabilísticas, exigen revisión y es más probable que incluyan de más que de menos.
  • La interfaz también prueba cómo una modificación afectaría a rutas BGP observadas. Es una comprobación valiosa del presente, no un ensayo de todas las rutas futuras.
  • El borrador IETF vigente recomienda incorporar por adelantado los proveedores de reserva o emergencia para evitar que la distribución RPKI compita con la propagación de rutas. Un proveedor dormido no debería tener todavía una ruta viva que observar.
  • APNIC debería guardar un recibo que separe sugerencias observadas, declaraciones humanas, candidatos descartados, pruebas de rutas actuales y escenarios de conmutación no ejercitados.

Una lista firmada empieza antes de la firma

Un ASPA permite que el titular de un ASN publique qué sistemas autónomos están autorizados a ser sus proveedores. La RPKI protege criptográficamente el objeto y los validadores pueden usarlo para evaluar pares dentro de un AS_PATH. Sin embargo, la firma sólo asegura el contenido que recibe. No responde por el método con el que el operador decidió quién entraba en la lista.

APNIC está intentando mejorar ese momento previo. En su actualización de RPKI presentada en APNIC 62, explicó que la interfaz alojada propone candidatos a partir del servicio asn-neighbours de RIPEstat. El patrón ya existe en la gestión de objetos de ruta. La propia presentación pone límites claros: la inferencia es probabilística, debe ser revisada y tiende a producir más inclusiones excesivas que omisiones.

Después llega la prueba de cambios. APNIC compara el conjunto propuesto con los caminos observados en BGP. Quitar a un proveedor que aparece en rutas actuales puede generar una advertencia antes de publicar el ASPA. Una sugerencia extra puede quedar a la vista para que una persona la clasifique, en vez de convertirse silenciosamente en una autorización.

El diseño es útil. También tiene un borde limpio. El proveedor de mitigación DDoS que sólo aparece durante un ataque, el tránsito preparado para unir dos segmentos aislados o un enlace de emergencia mantenido en frío no dejan necesariamente huella en el BGP cotidiano. Si la dejan, ya no están completamente en reserva. Si no la dejan, no hay camino actual que el comprobador pueda recorrer.

La vecindad vista no decide la función comercial

RIPEstat describe su API con prudencia. Devuelve ASN vecinos observados por RIS y puede acompañarlos con posición en el camino, número de rutas, número de pares observadores y tiempo de consulta o intervalo de validez. También marca ciertos vecinos como uncertain cuando la relación directa con un colector puede haber creado la apariencia de vecindad.

Todo eso mejora una sugerencia. Nada de eso convierte la sugerencia en contrato. Dos ASN contiguos pueden ser cliente y proveedor, pares laterales, cliente de un servidor de rutas no transparente o participantes de una relación compleja que cambia por familia de direcciones o conjunto de prefijos. El colector ve una muestra del enrutamiento. No ve un acuerdo que aún no ha producido anuncios.

Por eso una lista de partida algo amplia puede ser prudente. Es preferible pedir al operador que elimine un par antes que ocultar un proveedor activo cuya omisión dañaría rutas visibles. Pero una tendencia a la sobreinclusión no garantiza exhaustividad. La intención futura no es un dato BGP.

La interfaz necesita conservar dos procedencias. «Observado por RIS en esta ventana» es una afirmación reproducible sobre medición. «Autorizado como proveedor, aunque hoy esté inactivo» es una declaración responsable del titular. Fundirlas en una sola casilla reduce ambas.

El consejo IETF obliga a autorizar durante el silencio

Los borradores actuales del IETF hacen explícita la tensión. La revisión 29 del perfil ASPA plantea un objeto único por Customer AS que contenga todos los proveedores, incluidos los servidores de rutas no transparentes aplicables. La revisión 28 del procedimiento de verificación exige el conjunto completo y dedica un párrafo a los proveedores de reserva.

Los ejemplos son operativos: un proveedor temporal de mitigación DDoS o un proveedor de emergencia que reconecte segmentos aislados. El texto recomienda añadirlos por adelantado para impedir una carrera entre la distribución mundial del ASPA y la propagación de BGP.

Antes de la activación, el camino de emergencia no existe en la observación. Después de la activación, comenzar a publicar puede ser demasiado tarde. La decisión correcta vive en un intervalo incómodo: hay autoridad, plan y responsabilidad, pero todavía no hay telemetría de producción.

Esto no acusa a APNIC de prometer una prueba que no ofrece. Su presentación pide comentarios sobre las sugerencias y la validación y no detalla todos los campos privados que pueda conservar. Tampoco los textos IETF son RFC terminados; siguen siendo trabajos en curso. La conclusión es de arquitectura: el control descrito cubre rutas observadas, mientras la práctica recomendada incluye una autorización cuyo camino definitorio puede estar ausente.

El verde del presente no certifica el simulacro

Supongamos que un ASN usa los proveedores A y B y mantiene C para una emergencia. RIS observa A y B, y quizás un par D. La interfaz sugiere A, B y D. El operador descarta D y añade C manualmente.

El sistema puede detectar que A sigue apareciendo, que B sólo es visible en IPv6 o que D procede de una observación incierta. Puede afirmar que el cambio no introduce conflictos en el conjunto de rutas examinado. No puede afirmar que C anunciará los prefijos adecuados, tendrá capacidad durante el ataque, preservará el camino esperado o será activado después de que la nueva autorización llegue a los validadores.

«No se encontró conflicto actual» es un resultado valioso. «El failover fue validado» es otro resultado y exige otro ensayo. Una captura verde que pierde esa frase puede generar tres interpretaciones: objeto bien formado, caminos presentes compatibles o reserva operativamente probada. Sólo la primera y parte de la segunda caben en la comprobación descrita.

Un recibo para documentar lo que BGP no mostró

La solución no requiere publicar contratos, topología protegida ni credenciales. Puede ser un recibo privado dentro de MyAPNIC y del expediente de cambio del Miembro.

Cada candidato llevaría una procedencia: sugerencia de RIS, proveedor activo añadido manualmente, reserva, emergencia o servidor de rutas no transparente. Para una sugerencia se guardarían la hora, versión o huella de respuesta, posición, incertidumbre, recuento de caminos y recuento de pares. Un descarte usaría motivos acotados —par, cliente, servidor transparente, artefacto o pendiente— sin revelar condiciones comerciales.

Cada proveedor dormido llevaría una clase de activación, las familias de direcciones consideradas, el rol responsable, la última revisión o ejercicio y la fecha de la próxima. La prueba de rutas registraría ventana de observación, huella del conjunto examinado y resultado. Además enumeraría qué proveedores autorizados no fueron vistos y, por tanto, no se ejercitaron.

La última unión es temporal: confirmación del usuario, identidad del ASPA, hora de publicación y primera visibilidad desde un relying party independiente. Si la emergencia se adelanta, el registro debe conservar la secuencia real, no fabricar una autorización retroactiva.

DASH ya incorpora un estado ASPA para los ASN del Miembro y para los ASN que originan sus prefijos. Podría separar cuatro estados: publicado, observado, revisado como escenario y pendiente de revisión. El recuento de APNIC 62 —293 objetos, 257 alojados y 36 delegados— sólo fotografía adopción en ese momento. No mide redes que validan, listas completas ni reservas probadas.

El registro no debe heredar la decisión del router

El borrador de verificación define resultados sobre pares ordenados de ASN y luego sobre caminos. Un proveedor incluido puede producir una atestación positiva; uno no incluido frente a un ASPA válido puede producir una negativa; sin objeto válido hay ausencia de atestación. El texto propone cómo tratar Invalid y Unknown, pero deja la política de mitigación en manos del operador receptor.

Esa distribución de verbos es una salvaguarda. RIPE RIS observa. APNIC sugiere, avisa y publica. El titular del ASN autoriza. El validador calcula. La red decide. La interfaz es más fiable cuando muestra el límite entre cada función y no cuando las resume en un único semáforo.

Un proveedor de reserva obliga a mirar el tiempo además del camino. Su valor consiste en estar autorizado antes de ser visible. El recibo adecuado no pretende convertir esa previsión en garantía de servicio; conserva quién la declaró, qué no pudo comprobarse y cuándo la publicación estuvo lista.

Fuentes