Resumen

  • La propuesta 2026-02 está en discusión, no es política vigente. El umbral inicial combina una notificación autenticada con 14 días acumulados en una lista de infraestructura aprobada dentro de una ventana móvil de 30 días.
  • Para corregir la situación, el artículo 3.4 admite retirar los prefijos de la lista o acreditar un aislamiento administrativo. Para levantar las restricciones, el artículo 3.6 contempla retirar la lista o borrar el «ROA apropiado» si RPKI está implicado.
  • Un ROA autoriza a un sistema autónomo a originar rutas hacia ciertos prefijos. Ese registro, por sí solo, no demuestra que una operación de phishing, malware, DDoS o spam haya terminado.

Una cadena administrativa y tres pruebas diferentes

RIPE acaba de abrir a discusión una propuesta sobre abuso de red a escala de infraestructura. La versión 1.0 está fechada el 13 de octubre de 2026; el calendario oficial sitúa la fase de discusión hasta el 11 de noviembre. A la fecha de corte no hay constancia pública de adopción, implementación ni de un expediente tramitado bajo este mecanismo. El documento propone obligaciones; todavía no describe una intervención vigente de RIPE NCC.

La delimitación importa. El texto enumera cuatro clases de actividad sostenida: arquitecturas de mando y control para DDoS, redes sistémicas de alojamiento o distribución de malware, granjas de alojamiento de sitios de phishing e infraestructura de botnets de spam automatizado. Distingue esos fenómenos de la infección aislada de un dispositivo de consumo y excluye los grupos residenciales o dinámicos de abonados cuando así los designa el titular o un registro global de enrutamiento.

El procedimiento propuesto exige primero una notificación autenticada: un ticket de soporte presentado por un operador de red afectado o un CERT nacional, con telemetría verificable de una lista aprobada y marcas de tiempo o firmas criptográficas. El artículo 3.1 añade un umbral de 14 días acumulados, en cualquier periodo móvil de 30, en una lista de infraestructura aprobada. La inscripción de listas quedaría en manos del Security Working Group y debería apoyarse en telemetría automatizada y objetiva, excluir redes residenciales o dinámicas y conservar un archivo histórico verificable públicamente.

Después aparecen tres momentos probatorios. Conviene leerlos por separado:

Etapa Registro o acción del borrador Qué puede mostrar Qué no demuestra por sí solo
Inicio 14 días en 30 en una lista aprobada y una notificación autenticada Que una dirección figura en determinada lista durante la ventana exigida Que la dirección esté correctamente asociada al titular o qué acción detuvo la actividad
Corrección inicial Retirar los prefijos identificados de las listas o aislarlos mediante una medida administrativa verificada Un cambio de estado en la lista o una acción de aislamiento asociada al plazo de subsanación Quién verifica el aislamiento, con qué método o por qué desapareció la entrada
Restablecimiento Retirar los prefijos de la lista o, si interviene RPKI, eliminar el «ROA apropiado» Un cambio en la lista o en un registro de autorización de origen Que haya cesado la operación denunciada o por qué ese ROA era el remedio pertinente

El problema no es que una lista carezca de valor ni que una denuncia sostenida nunca pueda justificar una respuesta administrativa. Es que el borrador cambia el objeto que sirve como señal de salida. El artículo 3.1 parte del historial de una lista. El 3.4 permite cambiar la lista o acreditar aislamiento. El 3.6 vuelve a la lista, pero añade un objeto de autorización de rutas. No aclara si esa última alternativa prueba el aislamiento, corrige una denuncia sobre el origen de una ruta o funciona como una vía administrativa independiente.

El ROA responde a una pregunta más estrecha

RFC 9582 define para qué sirve una Route Origin Authorization: permite verificar que el titular de un bloque de direcciones autorizó a un sistema autónomo a originar rutas para los prefijos enumerados. Es un vínculo importante para la seguridad del enrutamiento. No describe el servicio que funcionaba en esas direcciones, el tráfico que produjo, si un equipo fue comprometido ni si el operador lo aisló después de recibir una denuncia.

RPKI puede ser pertinente cuando la alegación trata precisamente de un origen de ruta no autorizado o cuando la autorización participa en el mecanismo denunciado. Entonces sí tendría sentido identificar el prefijo, el sistema autónomo, el ROA y el ticket, y explicar por qué modificar esa autorización corrige la situación. Pero las cuatro clases de amenaza enumeradas en la propuesta no son, todas, problemas de origen de ruta. Una granja de phishing puede operar detrás de una ruta correctamente autorizada. La existencia de un ROA no demuestra que ese ROA permitiera el comportamiento descrito.

El texto deja sin resolver dos conexiones. ¿Qué convierte un caso en uno «donde interviene RPKI»? ¿Y cuál es el ROA «apropiado» si el titular administra varios prefijos, orígenes o autorizaciones? Las respuestas determinan qué cambio se exigiría y qué evidencia aceptaría RIPE NCC para retirar un estado público de incumplimiento.

Borrar un ROA modifica un registro de autorización. Dependiendo de los demás datos y de la política local de enrutamiento, puede afectar cómo ciertos operadores evalúan un anuncio. Las fuentes no permiten afirmar que siempre produzca el mismo resultado. Y ninguna de esas posibles consecuencias acredita por sí misma que haya cesado el servicio mencionado en la lista. El anuncio podría seguir originándose por otras vías; el sistema alojado podría continuar activo; o el titular podría retirar el ROA por un motivo ajeno a la denuncia. Un objeto RPKI no sustituye una explicación caso por caso.

El contacto de abuso no es el procedimiento propuesto

RIPE-705 regula la capa de contacto: prevé el atributo abuse-c para los registros pertinentes, la existencia de un buzón accesible para recibir denuncias y una validación anual con seguimiento conforme a las políticas y procedimientos aplicables. La explicación de RIPE NCC presenta el registro como una forma de dirigir los informes al titular de recursos que corresponda.

Encaminar una denuncia no decide si sus hechos son correctos, si el operador aisló un prefijo ni qué restricción registral sería proporcional. La propuesta 2026-02 añadiría otra cadena: aviso electrónico a los contactos legales, administrativos y de facturación; siete días hábiles desde la entrega confirmada; y, si no se satisface la condición, restricciones intermedias y un estado público de «abuso no conforme» en la base RIPE.

El borrador dice que quiere preservar las asignaciones y evitar una desconexión inmediata. También reconoce que las restricciones concretas requieren acuerdo comunitario y otro documento RIPE. Un estado público puede ser reutilizado por terceros aunque las asignaciones sigan intactas. Por eso importa saber qué registro lo justifica, cómo se corrige y cuándo queda constancia de su retirada.

El proponente califica el incumplimiento persistente como una infracción contractual. Esa afirmación pertenece a su justificación; no constituye una conclusión jurídica ya establecida. El proceso de desarrollo de políticas RIPE sigue abierto y se basa en consenso. La cuestión operativa es más delimitada: ¿qué evidencia acompaña cada cambio de estado?

Un recibo probatorio por notificación

El mecanismo podría conservar sus fases y, a la vez, exigir un recibo de evidencia vinculado a cada expediente, sin divulgar telemetría sensible. El recibo debería relacionar el identificador de la notificación, el prefijo exacto, la versión y el historial de la lista, las fechas observadas, la atribución al titular, la acción de aislamiento y quién la verificó, además del ROA afectado cuando el enrutamiento forme parte de la alegación. También tendría que fechar la entrega, el plazo, las restricciones, la corrección y el restablecimiento.

Así se mantienen separadas cuatro preguntas: qué comportamiento se observó; qué autorización de origen existía; qué medida de contención se tomó; y qué estado administrativo publicó RIPE NCC. Si la denuncia versa sobre el origen de rutas, un cambio del ROA puede formar parte de la respuesta, acompañado por evidencia de que el problema cambió. Si versa sobre un servicio de alojamiento, retirar una autorización sin relación demostrada con ese servicio no debería equivaler a probar su aislamiento.

Una dirección también puede desaparecer de una lista porque cesó la actividad, porque la lista corrigió un error, porque cambió sus criterios o porque terminó la ventana de observación. Esas causas tienen implicaciones distintas para el titular. Un archivo público permite reconstruir la secuencia, pero no explica por qué se retiró la entrada.

RIPE-781 organiza el desarrollo de políticas en cuatro fases abiertas, con consenso y apoyo administrativo de RIPE NCC, incluida la evaluación del impacto y del trabajo de implementación. La discusión puede poner a prueba no solo el umbral de 14 días, sino también la evidencia que vincula una dirección con su titular, el comportamiento con un objeto de autorización y una corrección con la retirada del estado público.

La propuesta acaba de abrir ese debate. Su límite de alcance más concreto es dirigirse a infraestructura sostenida y excluir grupos residenciales y dinámicos. Su problema probatorio es más específico: empieza con una lista, acepta aislamiento como corrección inicial y luego introduce otro objeto en el restablecimiento. Mientras no se explique la relación entre ambos, borrar un ROA demuestra que cambió una autorización de enrutamiento. No basta para cerrar un expediente de abuso.

Fuentes