Resumen

  • draft-geng-sidrops-bgp-drip-00 plantea correlacionar una ruta sospechosa con otras, devolver el riesgo a un relying party, distribuir ROA etiquetadas y señalar riesgo entre routers.
  • La firma de una ROA puede seguir siendo válida mientras una evaluación no criptográfica reduce el valor operativo de rutas relacionadas.
  • El documento es un borrador individual sin respaldo formal del IETF; antes de experimentar hay que separar detector, evidencia, asociación, política receptora, efecto, caducidad y reversión.

La validación de origen ofrece una respuesta limitada y útil: ¿está este AS autorizado para originar este prefijo? No afirma que el router esté libre de compromiso, que el camino completo sea benigno ni que el anuncio observado encaje con la intención operativa del titular. BGP DRIP parte de esa distancia entre autorización y sospecha.

Su versión 00 propone cuatro mecanismos. El router puede asociar una anomalía con rutas que comparten AS de origen, vecino inmediato o patrón de AS_PATH, y bajar su Local_Pref. Puede enviar al relying party una señal con prefijo, origen o par sospechoso, identificador de ROA y código de motivo. El RP puede guardar el juicio y devolver una ROA con metadatos de riesgo. Otro router puede recibir una comunidad extendida de riesgo y decidir si la acepta mediante su política de importación.

La arquitectura conserva formalmente decisiones locales. Sin embargo, crea una presión práctica: cuanto más lejos viaje la etiqueta, más fácil será tratarla como un veredicto ya resuelto. Ahí está el cambio de autoridad. Una observación realizada en una red puede terminar modificando la selección de caminos en otra, incluso para rutas que nunca fueron inválidas por sí mismas.

Validez y riesgo no son el mismo registro

El borrador dice que una ROA etiquetada puede conservar una firma criptográfica válida. Esa frase evita un error conceptual importante. La autorización de origen pertenece al objeto RPKI; el riesgo elevado pertenece a una evaluación operativa y temporal.

Si una plataforma fusiona ambos estados, el operador pierde la posibilidad de preguntar qué falló. ¿La ROA no autorizaba el origen? ¿Un detector vio una fuga? ¿Se sospechó de un par? ¿Una correlación extendió el juicio a otros prefijos? ¿La red receptora decidió aplicar una penalización? Cada pregunta tiene una fuente, un reloj y una autoridad distintos.

Una etiqueta de riesgo debería conservar, como mínimo, el evento original, el método de validación, el motivo, el nivel de confianza, el emisor, la cadena de custodia y su tiempo de vida. La política que modifica Local_Pref debe quedar en un recibo aparte. Así es posible corregir una inferencia sin reescribir la historia criptográfica de la ROA.

La regla de asociación decide el daño colateral

Compartir origen, vecino o patrón de camino puede ser una pista razonable. También puede agrupar rutas sin una causa común. Un AS presta servicios a clientes distintos; un vecino transporta anuncios de múltiples redes; dos caminos similares no prueban una misma operación.

La precisión del detector inicial no garantiza la precisión del conjunto asociado. El error se amplifica cuando la correlación se convierte automáticamente en una reducción de preferencia. El borrador recomienda un suelo mínimo de Local_Pref y diferencia esta medida del filtrado duro, pero «menos preferida» no significa «sin impacto».

El tráfico puede migrar a un enlace caro, congestionado o con mayor latencia. Una ruta alternativa puede existir en BGP y no ser apta para el servicio. La automatización, por tanto, debe registrar alternativas disponibles, delta de preferencia, volumen afectado, clientes y aplicaciones, y medidas de alcanzabilidad antes y después. Sin ese denominador, el sistema sabe que actuó, pero no si protegió la red.

Un canal autenticado todavía puede llevar una evaluación falsa

La sección de seguridad reconoce que la inyección de riesgo falso puede producir denegación de servicio. Propone proteger RTR con SSH o TLS, filtrar la comunidad en fronteras eBGP salvo confianza bilateral y mantener un suelo de preferencia que evite el blackholing total.

Son defensas necesarias, no una validación semántica. La criptografía del transporte demuestra qué extremo envió el mensaje y que no fue alterado en tránsito. No demuestra que el sensor funcionaba, que el evento seguía vigente ni que la asociación era proporcional. Tampoco define quién acredita al detector o quién responde cuando una etiqueta legítimamente firmada afecta rutas legítimas.

El ciclo necesita caducidad, renovación, retirada, protección contra repetición, impugnación y override local. La confianza bilateral debe poder revocarse sin dejar señales huérfanas. Y el RP debe conservar la observación original, no sólo un número de riesgo derivado.

Los números del borrador no son números asignados

Datatracker muestra una sola revisión, la 00, como Internet-Draft individual activo. No tiene stream RFC, estado RFC previsto, respaldo del IETF ni posición formal dentro de su proceso de estándares.

Además, el documento propone los tipos RTR 0x0B y 0x0C y dibuja la versión 2 en el formato de PDU. El registro IANA actual ya utiliza el tipo 11 (0x0B) para ASPA en la versión 2; el tipo 12 está sin asignar. La comunidad opaca transitiva deja el subtipo pendiente de IANA y no existe una asignación con el nombre propuesto.

Esto no prueba un rechazo institucional. Prueba que la codificación todavía requiere trabajo y que ningún operador puede presentar esos valores como estándar interoperable o capacidad desplegada.

La política receptora debe ser responsable y reversible

La doctrina de Lu Heng distingue el registro de la realidad que pretende describir. Una alerta puede aportar evidencia sin adquirir soberanía. En este caso, el detector observa, el RP conserva una evaluación y BGP transporta una señal. La red receptora sigue siendo responsable de la decisión que cambia el tráfico.

Esa responsabilidad exige un expediente legible: identidad y mandato del detector, observación bruta, validación, regla de asociación y confianza, autenticación, alcance de propagación, política local, cambio de preferencia, alternativas, duración, retirada, apelación, rollback y resultado medido. Si falta uno de esos eslabones, la etiqueta corre más rápido que su justificación.

BGP DRIP identifica una necesidad válida: la autorización de origen no agota el riesgo de enrutamiento. Pero la solución sólo será segura si transmite contexto sin exportar una autoridad ilimitada. La pregunta correcta para cada router no es «¿llegó una etiqueta?», sino «¿qué prueba llegó, de quién, para qué alcance y bajo qué derecho local de reversión?».

Fuentes