Resumen

  • El incidente avanzó por tres relojes distintos: la modificación de ROA desde una cuenta comprometida, la actualización escalonada de los validadores y las decisiones locales de las redes que rechazaban rutas marcadas como Invalid.
  • La respuesta adecuada no consiste en debilitar RPKI, sino en exigir más prueba para una escritura con gran radio de impacto: autenticación en el momento de la operación, aprobación independiente, aviso protegido, recibo verificable y recuperación ensayada.

Una firma auténtica sobre una afirmación hostil

A las 09:28 UTC del 3 de enero de 2024 comenzó a cambiar el estado RPKI asociado a direcciones de Orange España, según la reconstrucción de Kentik. A las 09:42 aparecieron tres autorizaciones con efectos relevantes. Durante horas, la alteración todavía no se manifestó de la misma manera en todos los observadores.

La razón es sencilla, aunque sus consecuencias no lo sean. Una Route Origin Authorisation no transporta tráfico ni ordena a un router desconectar una red. Publica una afirmación firmada sobre qué sistema autónomo puede originar determinados prefijos. Los validadores la procesan y cada operador decide cómo incorporar el resultado a su política BGP.

La persona que accedió sin autorización a la cuenta de Orange España no tuvo que modificar cada router de Internet. Cambió la evidencia compartida que esos routers podían consultar. Anuncios legítimos de AS12479 pasaron a no coincidir con la nueva autorización y, por tanto, a clasificarse como Invalid.

El RFC 6811 define precisamente ese estado: existe una carga validada que cubre el prefijo, pero ninguna coincide con el anuncio. El mismo documento aclara que la clasificación no obliga por sí sola a excluir la ruta. El rechazo requiere una configuración explícita. La prueba es común; la consecuencia sigue siendo local.

Tres relojes para una sola interrupción

Los datos públicos no ofrecen una hora universal de comienzo y fin. Ofrecen perspectivas distintas sobre un fenómeno distribuido.

Kentik observó una fuerte reducción del tráfico entrante hacia AS12479 aproximadamente entre las 14:20 y las 18:00 UTC. Cloudflare situó su caída de tráfico entre las 16:45 y las 19:45, hora local, y vio disminuir de forma notable el espacio IPv4 anunciado por Orange España. bgp.tools detectó que un prefijo afectado empezó a perder visibilidad alrededor de las 14:11 UTC.

Estas diferencias no debilitan la evidencia. La explican. El primer reloj era el de la escritura: cuándo se creó o modificó el objeto firmado. El segundo era el del validador: cuándo cada sistema descargó y procesó el nuevo estado. El tercero era el del operador: cuándo la política local volvió inutilizable una ruta clasificada como Invalid.

La pérdida de visibilidad descendió por escalones. Algunas redes actualizaron antes; otras después. Ciertas interconexiones conservaron caminos porque no rechazaban Invalid o porque mantenían relaciones directas que se comportaban de otra manera. La muestra de bgp.tools no representa todo Internet, pero demuestra que el efecto no fue uniforme.

La distribución de decisiones, por tanto, no impidió una consecuencia amplia. Al contrario: multiplicó una entrada firmada dañina a través de numerosas políticas independientes que funcionaban como sus operadores habían decidido.

RPKI no dejó de funcionar

Decir que RPKI “derribó” Orange España confunde el instrumento con la autoridad que alimentó el instrumento. Los validadores recibieron objetos formalmente válidos. Las redes compararon esos objetos con anuncios BGP reales. Allí donde la política rechazaba Invalid, el resultado previsible era dejar de usar la ruta.

Doug Madory, de Kentik, comparó el caso con el acceso de un intruso a las credenciales de un router para desactivar interfaces. La máquina ejecutaría una orden autorizada, pero el fracaso decisivo estaría en la custodia de la autorización. En Orange España, esa custodia se encontraba en una cuenta capaz de publicar estado criptográficamente confiable.

El riesgo tampoco era desconocido para el diseño técnico. Las consideraciones de seguridad del RFC 6811 advierten que, si un atacante puede introducir o retirar registros de la base de validación, el bloqueo de rutas Invalid puede convertirse en un vector de denegación de servicio. Orange España mostró esa posibilidad fuera del papel.

Abandonar el rechazo de rutas Invalid sería una conclusión peligrosa. Reduciría el impacto de una autorización hostil, pero también devolvería capacidad a los secuestros de origen que RPKI intenta limitar. La defensa no tiene que desaparecer; debe protegerse mejor el punto desde el que se emite la afirmación firmada.

La cuenta era una autoridad de producción

No toda acción dentro de un portal tiene la misma naturaleza. Consultar una factura, cambiar un contacto o crear una autorización que cubre millones de direcciones no deberían depender de una prueba idéntica de autoridad.

El acceso normal responde a la pregunta “¿puede esta persona entrar?”. Una escritura RPKI de alto impacto plantea preguntas adicionales: ¿está actuando ahora la persona correcta?, ¿es habitual este origen?, ¿cuántos anuncios vivos quedarán Invalid?, ¿existe otro responsable que pueda confirmar el cambio?, ¿qué versión segura se restaurará si la operación es hostil?

Después del incidente, RIPE NCC hizo obligatoria la autenticación de dos factores. La medida eleva de forma material el coste de reutilizar una contraseña robada. Sin embargo, dos factores en el inicio de sesión no equivalen necesariamente a dos autoridades independientes para una operación excepcional.

Una sesión legítima también puede ser secuestrada. Un segundo factor puede estar en el mismo dispositivo comprometido. Un empleado autorizado puede equivocarse con maxLength. Una cuenta correctamente autenticada puede proponer un cambio completamente atípico. La identidad es necesaria, pero el radio de impacto debe formar parte de la decisión.

La restauración no terminó al recuperar la contraseña

Poco antes de las 18:00 UTC, ingenieros de Orange España recuperaron el control y comenzaron a publicar ROA correctas. La visibilidad de rutas empezó a regresar alrededor de las 17:47 en la reconstrucción de bgp.tools. La mayoría de sus observadores necesitó aproximadamente otra hora para ver de nuevo el prefijo afectado.

El restablecimiento siguió los mismos pasos que la caída. Primero cambió el estado publicado. Después lo recogieron los validadores. Por último, las redes recalcularon sus decisiones. Ningún mensaje central podía obligarlas a hacerlo al mismo segundo.

Kentik señaló que, después de la recuperación principal, más de mil rutas de AS12479 seguían marcadas como Invalid. El volumen de direcciones IPv4 únicas anunciadas había bajado de unos siete millones a cinco millones. Parte del problema residual estaba relacionado con longitudes máximas que no autorizaban anuncios más específicos.

Recuperar una cuenta no basta para cerrar un incidente. Hace falta reconciliar el conjunto completo: objetos creados, objetos revocados, prefijos aún inválidos, rutas observadas, volumen anunciado, versiones publicadas y tiempo de propagación. Sin ese expediente, la organización sabe que volvió a entrar, pero no que volvió al estado correcto.

Controlar la escritura sin paralizar la defensa

Una escritura excepcional debería exigir reautenticación específica. El factor debe presentarse al confirmar la nueva autorización, no únicamente al comenzar una sesión que puede permanecer abierta. El recibo debe identificar la versión anterior, la nueva, el dispositivo y la identidad que realizó la operación.

También conviene una segunda aprobación cuando concurren señales objetivas. Entre ellas están el primer uso de RPKI alojado, un ASN de origen nuevo, un agregado muy amplio, un maxLength restrictivo o un cambio que volvería Invalid un número elevado de anuncios que ya se observan en BGP.

El aviso debe viajar por un canal que la misma sesión no pueda sustituir silenciosamente. No sirve un correo genérico que diga “su configuración ha cambiado”. El responsable de seguridad de rutas necesita ver el antes y el después, los prefijos afectados y la estimación de anuncios que perderían validez.

Una espera breve puede dar tiempo para impugnar una operación hostil, pero no debe bloquear una reparación urgente ante un secuestro real. La salida de emergencia exige una prueba más fuerte, una justificación registrada y revisión posterior. Velocidad y control no son opciones absolutas; deben variar con el riesgo de la escritura.

Por último, la restauración debe estar ensayada. El proveedor y el titular necesitan saber cómo suspender objetos recién emitidos, recuperar una versión segura identificada, publicar correcciones y observar su adopción. Un documento que nunca se ha probado no demuestra continuidad.

El límite de Running-Code Primacy

Running-Code Primacy, la doctrina de Heng Lu, sostiene que la coordinación debe reducirse a las funciones que necesitan las redes: unicidad, interoperabilidad, continuidad cercana al encaminamiento, afirmaciones de seguridad y prueba de control. Su propuesta insiste además en que los participantes validen localmente y no confundan una publicación institucional con la realidad.

Orange España confirma una parte del argumento. Las redes conservaron decisión local y no todas actuaron igual. RIPE NCC no poseía un interruptor soberano capaz de ordenar a Internet un resultado uniforme.

El incidente añade, sin embargo, una precisión indispensable. Una publicación firmada adquiere poder cuando numerosos operadores deciden usarla. La adopción local no hace irrelevante la custodia del estado compartido. Cuanto más útil y extendida sea la validación, mayor será el valor de comprometer la autoridad que produce sus entradas.

Esto no justifica ampliar el mandato de un registro. La lección es estrecha: proteger identidad, autorización y reversibilidad alrededor de las afirmaciones de seguridad. No concede autoridad sobre modelos comerciales, propiedad de recursos ni políticas privadas de encaminamiento.

Lo que todavía no sabemos

No existe un informe forense público de Orange España que cierre todos los pasos previos al acceso. Algunas fuentes relacionan la credencial con un dispositivo comprometido y mercados de registros robados, pero esa secuencia debe permanecer atribuida y provisional.

Tampoco puede afirmarse que todos los clientes perdieran servicio o que cada ruta desapareciera. Cloudflare, Kentik y bgp.tools observaron partes diferentes del sistema. Sus datos respaldan una interrupción grave y prolongada, no una experiencia idéntica para todo usuario.

La prueba útil para el futuro es más concreta. Ante una escritura de alto impacto, el sistema debe poder demostrar quién la solicitó, qué prueba reciente presentó, quién la confirmó, qué rutas vivas podía invalidar, cuándo se propagó y cómo se restituyó el estado correcto.

No es una capa administrativa ajena a RPKI. Es la disciplina de custodia necesaria cuando una firma puede viajar a través de miles de decisiones independientes.

Fuentes