Resumen

  • Un borrador individual publicado el 20 de agosto propone que el titular de direcciones firme una DOA con prefijos, longitudes, AS de origen, pares autorizados y comunidades de blackholing.
  • La coincidencia DOA no convertiría una ruta en ROV válida ni ordenaría descartarla; faltan adopción formal, transporte RPKI-RTR, consideraciones de seguridad y pruebas de interoperabilidad.

Una defensa contra ataques volumétricos puede chocar con otra defensa del sistema de rutas. El blackholing remoto permite anunciar a un proveedor una ruta más específica marcada para descarte, de modo que el tráfico se detenga antes del enlace saturado. Sin embargo, esa longitud puede superar la autorizada por la ROA del prefijo y producir un resultado ROV Invalid.

La versión 00 de draft-spaghetti-grow-rpki-doa, registrada el 20 de agosto, propone no resolver ese choque mediante una excepción informal. Su Discard Origin Authorization sería un objeto firmado en RPKI por el titular del bloque. La credencial identificaría el AS que puede originar la solicitud, los prefijos y longitudes permitidos, una lista de comunidades BGP y, opcionalmente, los AS que pueden retransmitirla.

El acontecimiento tiene un alcance limitado. Datatracker presenta el texto como Internet-Draft individual, no como documento adoptado por GROW, decisión del IETF o estándar. Los autores recuperaron una propuesta de 2022 cuyo nombre apuntaba a SIDROPS y ahora la dirigen a GROW. Ese cambio de foro es visible; el respaldo institucional no lo es.

La revisión también convierte una pregunta pendiente en una regla. El borrador antiguo no decidía si varias comunidades debían cumplirse todas o si bastaba una. El texto actual utiliza un OR lógico: cualquier comunidad de la lista que aparezca en la ruta satisface esa condición. Cuando el emisor no selecciona otra, el software de firma puede añadir por defecto la comunidad BLACKHOLE bien conocida de RFC 7999.

Una etiqueta aislada no bastaría. El estado Matched exigiría que el AS de origen coincida, que la longitud esté autorizada, que la ruta llegue desde ese origen o desde un peerAsID permitido y que contenga al menos una comunidad indicada. Unmatched describiría un objeto válido que cubre el prefijo pero cuyas restricciones no se cumplen; NotFound, la ausencia de un objeto validado que lo cubra.

ROV seguiría calculándose por separado. El diseño acepta que una ruta legítima de descarte sea DOA Matched y al mismo tiempo ROV Invalid. La política podría atender primero la autorización específica y enviar los casos no coincidentes al procesamiento normal. El borrador impone, además, una barrera importante: una implementación no debe tomar ninguna acción predeterminada por el mero estado DOA o ROV. El operador tiene que configurar de forma explícita qué hace.

Así se evita confundir autenticación con necesidad. Una DOA validada indicaría que el titular de recursos autorizó cierto tipo de anuncio. No demuestra que haya un ataque en curso, que todo el AS path sea legítimo o que descartar sea la respuesta adecuada en ese momento. La decisión local todavía puede requerir límites, registros, confirmación o una ventana de vigencia corta.

El control de exportación también se mantiene. RFC 7999 recomienda que las rutas blackhole no se propaguen más allá del AS receptor. La propuesta permite una excepción cuando el AS local figura de manera expresa entre los pares autorizados, lo que cubre un salto adicional. La autorización no se vuelve transitiva y las demás restricciones continúan vigentes.

El incentivo para crear un objeto separado nace de la alternativa. Ampliar el maxLength de una ROA puede hacer que el anuncio más específico pase ROV, pero también expande la autorización ordinaria de origen. RFC 9319 aconseja evitar máximos innecesariamente amplios. DOA intentaría reservar esa amplitud solo para el acto de descarte.

Todavía falta la maquinaria que convertiría el formato en una función utilizable. El transporte por RPKI-RTR se deja para otro documento. Las secciones de Operaciones y Seguridad aún no están redactadas, y los identificadores IANA no están asignados. Solo se menciona un firmante en Python, cuya información no fue verificada por los autores del proceso y no demuestra interoperabilidad con validadores ni routers.

La noticia, por tanto, es una definición más precisa de quién podría autorizar qué. Su efecto dependerá de cómo se publiquen y retiren los objetos, cuánto tarde en desaparecer una autorización revocada y si diferentes implementaciones calculan el mismo resultado. Sin esas pruebas, DOA sigue siendo un diseño de control, no una capacidad de red.

Fuentes