Resumen

  • Siddiqui propuso restringir ciertos ASN en las ROA de APNIC y, como presidente del Routing Security SIG, también cofirmó el informe de una encuesta sobre funciones que podrían ofrecerse a los operadores.
  • La propuesta dejó un rastro público de versiones, consenso, publicación como directriz y estado de implementación. La encuesta registró preferencias; no ordenó lanzar un producto ni demostró que las rutas fueran más seguras.

Dos canales, dos tipos de comprobante

Un registro regional de Internet puede escuchar una necesidad operativa por vías distintas. Una propuesta de política avanza mediante un proceso definido: se publican versiones, se reciben comentarios y queda constancia del punto de decisión. Una encuesta sobre servicios cumple otra función. Recoge preferencias que pueden orientar a un equipo de producto, pero no sustituye su decisión.

La trayectoria pública de Aftab Siddiqui en APNIC cruza ambos canales. En 2021 propuso limitar los números de sistemas autónomos que podían figurar como origen en una autorización de origen de ruta, o ROA. Por separado, como presidente del grupo de interés especial (SIG) sobre seguridad del enrutamiento, cofirmó un texto que resumía una encuesta sobre avisos de ROA y API para administrarlas. Los temas se relacionan con la operación de Internet, pero no pasan por el mismo mecanismo institucional.

La diferencia importa porque un objeto de registro y una decisión de enrutamiento están en capas distintas. Una API puede facilitar que una persona autorizada cambie un registro. Una ROA declara qué sistema autónomo está autorizado a originar un prefijo. Después, los datos deben publicarse, llegar a validadores y ser utilizados por las políticas de cada red. Una encuesta sobre una herramienta de gestión no demuestra ninguno de esos pasos posteriores.

Una carta para facilitar la conversación, no aprobar lanzamientos

El informe de APNIC 49, en 2020, describe una elección de presidencia y la revisión del nombre y la carta del Routing Security/RPKI SIG, que ya existía. Tras el respaldo de la comunidad, el grupo pasó a llamarse Routing Security SIG, acordó su carta y eligió a Siddiqui como presidente. El texto define un espacio para tratar problemas operativos y buenas prácticas. También prevé recoger comentarios sobre servicios de APNIC —como RPKI, IRRd y RRDP— y asesorar al conjunto de la comunidad sobre elementos técnicos de propuestas de política.

Ese alcance permite llevar la experiencia de campo al equipo de servicios: los operadores explican qué obstaculiza su trabajo y el equipo puede valorar cambios. No da al SIG autoridad para fijar prioridades de producto ni comprometer una fecha de lanzamiento. En su candidatura de 2022, Siddiqui describió el grupo como un puente para hablar de problemas operativos y de funciones o apoyo que APNIC podría ofrecer. También dijo que el grupo había perdido impulso durante la pandemia. Son valoraciones suyas en ese momento, no una medición independiente de actividad o resultados.

El paso siguiente aclara quién decidía: el artículo de APNIC previo a la reunión de 2022 decía que se esperaba que el equipo de servicios presentara el análisis de costes y beneficios. El SIG podía poner una necesidad sobre la mesa; el equipo responsable aún tenía que evaluarla.

Lo que muestran —y no muestran— los porcentajes

El artículo de APNIC publicado en septiembre de 2022 y firmado también por Siddiqui indica que la encuesta se realizó tras la sesión abierta de octubre de 2021. A la pregunta de si debía enviarse un correo cuando se creara una ROA, un 52,4 % contestó que sí; un 33,3 % prefería que fuera opcional; un 9,5 % temía recibir demasiados avisos; y un 4,8 % pidió más debate. Entre quienes apoyaban el aviso, un 47,6 % prefería webhooks, un 28,6 % consideraba suficiente el correo y un 23,8 % no estaba seguro.

Sobre una API para gestionar ROA —desde MyAPNIC o con RPKI autoalojado, por ejemplo mediante Krill— las respuestas publicadas fueron 66,7 % a favor, 19 % en contra y 14,3 % quizá.

Los valores son un registro de preferencias expresadas. La publicación no ofrece el denominador, el método de respuesta ni un desglose por tipo de red. Por ello no sabemos cuántas personas respondieron ni si representan a los miembros de APNIC, a los operadores en general o a la región. Tampoco es una votación sobre política de enrutamiento: se preguntó por posibles funciones de servicio y algunas respuestas expresaron dudas.

Las preguntas, aun así, identifican fricciones concretas. Un aviso puede informar al contacto técnico de que se creó una ROA; un webhook puede llevar el evento a un sistema interno; una API puede automatizar cambios que antes requerían entrar a un portal. Cada opción afecta a una parte distinta del trabajo. Ninguna determina por sí sola si la ROA es correcta ni si un router rechazará una ruta inválida.

Una API posterior no prueba que la encuesta la causara

En octubre de 2024 APNIC anunció que estaba disponible su Registry API. Permite consultar datos de delegación y gestionar objetos Whois, DNS inverso, ROA y rutas; además, automatiza cambios que antes se hacían manualmente en MyAPNIC. El informe anual de APNIC de 2022 ya describía un prototipo abierto a pruebas públicas y preveía iniciar el desarrollo de producción en 2023.

Hay un solapamiento claro: tanto la encuesta como la API tratan el acceso automatizado a funciones del registro, incluida la gestión de ROA. Pero las fuentes citadas no dicen que la encuesta de 2021 iniciara el proyecto, que quienes respondieron fueran los miembros que solicitaron el producto ni que el SIG eligiera su diseño. La disponibilidad posterior de la API no prueba que los encuestados la adoptaran ni que disminuyeran las fugas o los secuestros de rutas.

La confusión es fácil porque «seguridad del enrutamiento» puede referirse a varias capas. El registro expone una interfaz; una persona titular puede modificar sus objetos; el registro publica datos firmados; un validador los procesa; cada red decide entonces cómo actuar ante el resultado. La evidencia sobre una etapa no debe presentarse como si demostrara la siguiente.

La propuesta de política dejó otro tipo de rastro

La propuesta prop-138 de Siddiqui permite comparar. Señalaba que el sistema de gestión de ROA de APNIC permitía introducir ASN privados, reservados o no asignados como origen, y proponía impedirlo. La segunda versión extendía la restricción a los objetos route y route6. El registro público de APNIC fecha las dos versiones en agosto y septiembre de 2021; marca consenso en la reunión abierta de política de APNIC 52, el 16 de septiembre, para avanzar como directriz; registra su publicación en diciembre y muestra el estado actual «Implemented».

Es un rastro institucional más formal que el de una encuesta de servicios: se identifica la regla propuesta, sus versiones, una fecha de consenso y el estado de implementación. Aun así, no cuantifica cuántos objetos problemáticos se evitaron ni cuánto cambió el riesgo de enrutamiento. «Implementado» describe un estado del proceso, no un estudio de impacto.

La comparación no vuelve irrelevante la encuesta. Muestra que las dos vías producen resultados distintos. Un proceso de política deja constancia de si una propuesta alcanzó el punto de decisión comunitario. Una encuesta puede orientar al responsable de un servicio sobre preferencias y preguntas pendientes. Para medir efectos hay que buscar la prueba correspondiente: el estado de la regla, la especificación y el historial de lanzamiento del servicio, y datos de operación para los resultados posteriores.

Qué permite afirmar el historial de Siddiqui

La ficha de candidatura de 2012 lo describía como responsable de operaciones de red en Pakistán, con participación en despliegues IPv6, seguridad de infraestructura, la IPv6 Task Force Pakistan y actividades de operadores regionales. Una página de APNIC de 2022 recoge su descripción del papel como presidente del SIG y su interés por conectar los problemas operativos con el apoyo de APNIC. Son registros fechados que lo ubican entre las operaciones, las conversaciones de política y los comentarios sobre servicios. No lo convierten en único responsable del rumbo del grupo ni en quien decidía por APNIC.

La conclusión más defendible es concreta. Siddiqui presentó una propuesta cuyo recorrido puede seguirse en el registro de políticas; también ayudó a dirigir un foro que documentó preferencias de servicio y las puso ante el equipo correspondiente. La primera vía dejó una secuencia de consenso e implementación. La segunda produjo una señal para evaluar una función. La API posterior vuelve tangible el tema, pero no completa el vínculo causal ni demuestra un resultado de seguridad en el enrutamiento.

Fuentes