Resumen

  • Una Autorización de Origen de Ruta (Route Origin Authorization, ROA) es una declaración firmada de que un sistema autónomo designado puede originar prefijos especificados. No es una transmisión de propiedad, una orden a los enrutadores, una garantía de que la ruta es benigna ni una prueba de que el AS designado sigue teniendo derecho según un arrendamiento privado.
  • En la mayoría de los arrendamientos, el arrendador sigue siendo el titular directo de los recursos y, por lo tanto, es quien está más cerca de la cadena de certificación RPKI. El arrendatario opera la red y sabe qué AS de origen y rutas más específicas son operativamente necesarias. El proveedor upstream transporta o filtra la ruta. El RIR opera un ancla de confianza o un servicio de certificación principal. Se trata de poderes diferentes.
  • La RPKI alojada y delegada alteran la custodia y la ejecución, no el acuerdo comercial subyacente. El servicio alojado sitúa las operaciones de claves y la publicación en manos de un RIR; el servicio delegado permite al titular operar una CA y, generalmente, su clave privada. Ninguno de estos acuerdos, por sí solo, otorga al arrendatario derechos oportunos ni lo protege de una eliminación en disputa.
  • Todo arrendamiento debe incluir un programa de autorización que nombre los prefijos exactos, los AS de origen permitidos, las longitudes máximas, los períodos de inicio y fin, el plazo ordinario para cambios, el plazo de emergencia, los aprobadores, los canales de autenticación y la evidencia que debe conservarse. Una promesa genérica de proporcionar una carta de autorización no es suficiente.
  • El tiempo del contrato y el tiempo de RPKI deben alinearse deliberadamente. Los servicios alojados pueden renovar los objetos firmados automáticamente, las cachés se actualizan a su propio ritmo y una ruta puede seguir visible tras el término comercial. Por lo tanto, la expiración a medianoche no es ni una revocación técnica instantánea ni una razón segura para eliminar la única ROA válida antes de que se haya migrado el tráfico.
  • El acceso de emergencia debe ser limitado y redundante. El arrendatario necesita una forma de añadir rápidamente un origen de mitigación o reemplazo preaprobado, mientras que el arrendador necesita límites que eviten una delegación abierta. La doble aprobación, los prefijos acotados, una autoridad de emergencia de corta duración, los registros independientes y una revisión posterior al incidente pueden satisfacer ambas necesidades.
  • Una disputa comercial no debe librarse sorprendiendo al sistema de enrutamiento global. Excepto en una emergencia de seguridad activa, la eliminación de una ROA debe seguir un aviso, un breve período de continuidad, una vía de escalado independiente y una retirada coordinada de la ruta. La revocación final debe ser segura; el camino hacia ella no debe convertir a los clientes en moneda de cambio.

El arrendamiento separa el uso de la atestación

La pregunta incómoda en un arrendamiento IPv4 no es quién es el dueño del enrutador. Es quién puede hacer la declaración criptográfica en la que otros enrutadores pueden confiar.

El arrendatario puede configurar el AS de origen, anunciar el prefijo, atender a los clientes, responder a informes de abuso y pagar la factura de tránsito. Sin embargo, si el prefijo sigue certificado a nombre del arrendador, el arrendatario puede verse incapaz de crear, modificar o eliminar la ROA que describe su propio anuncio en vivo. El arrendador puede ser económicamente pasivo y técnicamente decisivo. Una cuenta de portal olvidada o un firmante inaccesible puede convertir un cambio de enrutamiento rutinario en un riesgo de interrupción.

Esto no hace que el arrendamiento sea defectuoso. Significa que un arrendamiento se asienta sobre dos sistemas de autoridad. El derecho contractual determina lo que una parte prometió a la otra. La RPKI determina si una autorización firmada puede validarse a través de una cadena arraigada en la jerarquía de recursos numéricos. BGP determina qué rutas anuncian y seleccionan realmente las redes. Los contratos de tránsito determinan lo que un proveedor upstream aceptará. Ninguno de esos sistemas lee automáticamente a los otros.

RFC 9582define una ROA como un objeto firmado mediante el cual el titular de un bloque de direcciones autoriza a un AS a originar rutas hacia uno o más prefijos. Su sección de seguridad es inusualmente útil para la gobernanza: la RPKI proporciona autorización más que autenticación de identidad o no repudio. El objeto demuestra que una ruta de certificación válida respaldaba la declaración cuando las partes confiables la procesaron. No publica el arrendamiento, el precio, el cliente, el usuario beneficiario, la razón de la ruta ni el plazo del acuerdo comercial.

Esta distinción desbarata dos atajos comunes. El primero dice que la parte capaz de crear la ROA debe ser el propietario económico. Eso no se sigue. El segundo dice que la parte nombrada como origen en la ROA debe controlar los derechos de dirección. Eso tampoco se sigue. Un titular puede autorizar el AS de un cliente, un upstream, una red en la nube o un proveedor de mitigación sin transferir el recurso. El objeto firmado es deliberadamente más limitado que la relación que lo rodea.

Por lo tanto, la pregunta correcta no es simplemente: «¿Quién controla la ROA?». Es un conjunto de preguntas: ¿Quién puede solicitar un cambio? ¿Quién decide que la solicitud está dentro del alcance del arrendamiento? ¿Quién opera el sistema de firma? ¿Quién puede detener un cambio inseguro? ¿Quién puede actuar cuando la parte principal no está accesible? ¿Quién asume la pérdida si un cambio prometido se retrasa? ¿Quién debe eliminar la autorización cuando termina el derecho a enrutar?

Un arrendamiento que solo responde a la primera pregunta deja el resto a la improvisación.

Cuatro actores poseen cuatro tipos diferentes de poder

A menudo se describe al arrendador, arrendatario, upstream y a la CA del RIR como si fueran puntos en una sola cadena de mando. Es mejor entenderlos como cuatro actores con poderes que se intersectan pero no son idénticos.

El arrendador normalmente conserva la relación registrada de la que deriva la certificación de recursos. En un servicio RPKI alojado, un usuario autorizado de la organización del arrendador puede crear configuraciones de ROA a través de la interfaz del RIR. En una configuración delegada, el arrendador puede operar su propia CA y poseer la clave privada correspondiente. La capacidad decisiva del arrendador es la atestación: puede hacer que una declaración sobre un prefijo y un AS de origen entre o salga del conjunto RPKI validado.

El arrendatario posee el conocimiento operativo. Conoce el origen previsto, el diseño del upstream, el estado de migración de los clientes, las rutas más específicas de ingeniería de tráfico, los acuerdos de mitigación y la fecha en la que una nueva ruta debe funcionar. Su capacidad decisiva es el uso: él o sus proveedores pueden configurar y originar anuncios BGP. Esa capacidad puede existir incluso cuando la ruta se vuelve Inválida según RPKI, porque la RPKI no desconecta BGP. La consecuencia práctica depende de qué redes aplican la validación de origen de ruta y cómo lo hacen.

El upstream tiene poder de aceptación y propagación. Puede exigir una carta de autorización, un objeto IRR, una ROA coincidente, una prueba contractual o alguna combinación. Puede construir filtros de prefijos de cliente a partir de sus propios registros, un IRR, las cargas útiles validadas por RPKI o una revisión manual. Puede rechazar una ruta por lo demás válida porque la relación con el cliente no está verificada, o transportar una ruta No Encontrada según su política. Una ROA válida es una evidencia relevante, no una orden para el upstream.

La CA del RIR se sitúa en la jerarquía de certificación.RFC 6480describe una arquitectura alineada con la asignación de recursos numéricos. Los servicios del RIR emiten o mantienen el certificado de recursos principal, alojan la firma para muchos titulares, publican material y conectan los cambios en los recursos certificados con la jerarquía. El RIR no es parte en la mayoría de los arrendamientos y normalmente no conoce sus términos comerciales completos. Su sistema puede autenticar la cuenta del titular y validar la cobertura de recursos sin saber si la factura del arrendatario está en disputa.

Estos poderes no deben fusionarse. La capacidad del arrendador de eliminar una ROA no significa que deba controlar el enrutador del arrendatario. La capacidad del arrendatario de enviar un anuncio no significa que deba tener poder de firma ilimitado sobre el agregado del arrendador. El filtro de un upstream no resuelve el arrendamiento. El certificado de un RIR no adjudica el uso beneficioso.

Una buena gobernanza comienza admitiendo que ningún actor por sí solo ve la relación completa.

Una ROA autoriza un origen, no una ruta en todas sus dimensiones

La estrechez de la ROA es una fortaleza, pero se vuelve peligrosa cuando los contratos la describen de forma demasiado amplia.

Una ROA identifica un AS de origen y uno o más prefijos. Puede incluir una longitud máxima que permita ciertos anuncios más específicos. Si varios AS están autorizados a originar el mismo prefijo, se requieren ROA separadas. El objeto no indica qué upstream puede transportar la ruta, qué ruta de AS es aceptable, si el origen tiene un acuerdo de servicio vigente, qué tráfico de clientes pertenece a las direcciones o si un anuncio es geográficamente esperable.

Por eso, un «arrendamiento compatible con RPKI» puede ocultar más de lo que revela. Un arrendador puede crear una ROA técnicamente válida para el ASN de la parte comercial equivocada. Un arrendatario puede seguir anunciando a través del origen autorizado después de que haya terminado un contrato de servicio. Un AS autorizado puede filtrar accidentalmente o anunciar deliberadamente una ruta más específica permitida por una longitud máxima demasiado amplia. Una ruta puede ser Válida según RPKI y seguir siendo operativamente errónea o abusiva.

RFC 6483advierte que una ROA puede afectar a otros anuncios cubiertos por el mismo espacio de direcciones: las rutas de orígenes no listados, o las más específicas más allá de la longitud permitida, pueden volverse Inválidas. Recomienda tener en cuenta todos los orígenes legítimamente autorizados y las rutas más específicas relevantes.RFC 7115, de manera similar, trata la validación de origen como un insumo operativo, no como un veredicto universal de selección de ruta.

Para un arrendamiento, esto significa que el programa no puede limitarse a decir: «El arrendador creará una ROA». Debe indicar los pares exactos prefijo-origen y explicar la política de rutas más específicas. Si un /20 se va a anunciar solo como /20 desde el ASN del arrendatario, no debe concederse una longitud máxima innecesariamente permisiva por conveniencia. Si el arrendatario necesita anuncios /24 desde dos orígenes durante una migración, ambos orígenes y el período temporal deben ser explícitos.

El papel del upstream permanece separado. Lasacciones de operadores de red de MANRSinstan a los operadores a garantizar la corrección de sus propios anuncios y los de sus clientes, mantener contactos útiles y publicar información que otros puedan validar. Un proveedor de tránsito que solo comprueba si existe una ROA no está completando esa tarea. Aún necesita saber que su cliente es la parte autorizada para pedirle que transporte la ruta.

Por lo tanto, el arrendamiento debe prometer varios hechos coordinados, no un estatus mágico: permiso comercial del arrendador, instrucción operativa del arrendatario, autorización de origen en RPKI, información de enrutamiento precisa y aceptación por parte del upstream previsto.

La RPKI alojada concentra la ejecución en la cuenta del titular

La RPKI alojada es atractiva porque elimina la mayor parte de la administración criptográfica del titular del recurso. Esa comodidad también aclara dónde reside la dependencia del arrendamiento.

La guía de la CA alojada de RIPE NCCindica que el servicio alojado firma, publica y renueva los objetos ROA a partir de las configuraciones gestionadas por una cuenta autorizada. El usuario gestiona la información del origen y los prefijos previstos; el servicio se encarga de las claves, la renovación de objetos y la publicación.La documentación de RPKI alojada de ARINtambién sitúa la CA y la firma en ARIN e indica que las organizaciones dependientes deben hacer que su proveedor upstream envíe las ROA en su nombre cuando no pueden participar directamente.

Para el arrendador, el servicio alojado puede reducir los fallos operativos. No hay un repositorio de CA privado que el arrendatario deba monitorear y no hay una clave de firma que colocar en el portátil de un empleado. Sin embargo, para el arrendatario, la cuestión clave se convierte en la gobernanza de la cuenta. ¿Qué personas del arrendador pueden aprobar una solicitud? ¿Hay cobertura las 24 horas? ¿Puede el arrendatario tener un rol restringido o cada cambio debe ser transcrito por el titular? ¿Qué sucede si la cuenta del arrendador se bloquea durante una verificación de identidad, un cambio corporativo o una disputa?

El acceso al portal no debe compartirse de forma casual. Dar al arrendatario las credenciales generales del arrendador puede exponer prefijos no relacionados, otros clientes y acciones destructivas. También difumina la atribución: el arrendador no puede saber después si el cambio lo hizo su empleado, un contratista o el cliente. Incluso si una interfaz admite múltiples usuarios, la autorización debe limitarse a la organización y a las tareas que cada persona está autorizada a realizar.

El modelo alojado más seguro trata al arrendatario como un solicitante autenticado y al arrendador como un aprobador con límites. Las solicitudes utilizan un canal definido, identifican el arrendamiento y los prefijos, incluyen el origen propuesto y la longitud máxima, y reciben un registro de transacción. Los cambios rutinarios tienen un plazo de servicio. Los cambios de emergencia utilizan un canal más rápido con autenticación separada. Al menos dos personas del arrendador deben poder actuar, y el arrendatario debe tener al menos dos solicitantes aprobados.

La automatización puede reducir los retrasos, pero debe hacer cumplir el programa de autorización en lugar de eludirlo. Una solicitud para un prefijo listado, un ASN listado y una longitud máxima permitida puede ser elegible para una aprobación rápida. Una solicitud para autorizar un ASN desconocido o un rango de rutas más específicas más amplio debe detenerse para su revisión humana. La distinción está entre automatizar una promesa conocida y ampliar silenciosamente la promesa.

El servicio alojado resuelve la operación de las claves. No resuelve la delegación comercial a menos que el contrato y los roles de cuenta lo hagan.

La RPKI delegada mueve la clave, no la relación con el padre

La RPKI delegada puede dar al titular del recurso más autonomía técnica. También puede crear la creencia equivocada de que el titular ha escapado a toda dependencia del upstream.

La comparación de RIPE NCC entre servicio alojado y delegadodice que un operador delegado controla su certificado de recursos y la clave privada correspondiente, y puede elegir dónde publicar.Las opciones de despliegue de ARINafirman que un titular directo puede operar su propia CA, firmar ROAs y, en el modelo delegado, emitir certificados de recursos para clientes. APNIC también identifica el modo autogestionado como RPKI delegada en sumaterial de certificación de recursos.

Esa arquitectura puede soportar una división más directa. Un arrendador sofisticado puede ejecutar una CA principal y emitir un certificado de recursos subordinado limitado a los prefijos del arrendatario. El arrendatario puede entonces firmar objetos dentro de ese conjunto acotado sin recibir poder sobre los demás recursos del arrendador. Al final del arrendamiento, el arrendador puede revocar o dejar que el certificado subordinado expire según la secuencia acordada.

La aparente elegancia conlleva obligaciones operativas. Alguien debe proteger la clave privada, mantener la CA, publicar los objetos actuales, gestionar los manifiestos y la información de revocación, monitorear la disponibilidad, rotar las claves y preservar el acceso de recuperación. Lapolítica de RIPE NCC sobre CAs delegadas persistentemente no funcionalesilustra la consecuencia de un fallo prolongado: después de una incapacidad prolongada para descubrir y validar el material actual, el padre puede revocar el certificado de recursos delegado. La delegación es control junto con mantenimiento, no una entrega única.

La relación con el padre también permanece. Un certificado delegado existe dentro de una jerarquía. Si los recursos certificados cambian o el certificado padre es revocado, la autoridad subordinada se ve afectada.RFC 8211examina las acciones adversas o erróneas de las CAs y los gestores de repositorio precisamente porque la posesión local de una clave no elimina las dependencias jerárquicas y de publicación.

Para muchos arrendatarios, ejecutar una CA sería desproporcionado. Para grandes operadores con cambios frecuentes de origen, múltiples upstreams o estrictas necesidades de continuidad, una delegación acotada puede merecer el coste. La elección debe depender de la frecuencia de cambios, la tolerancia a interrupciones, la capacidad del personal y el diseño de la cartera del arrendador, no del prestigio de poseer una clave.

Lo más importante es que la RPKI delegada no debe convertirse en una concesión permanente informal. Los recursos subordinados, el plazo del certificado, la regla de renovación, los eventos de revocación, las obligaciones del repositorio, los contactos de emergencia y las pruebas de destrucción o transferencia a la salida pertenecen todos al arrendamiento. Acercar la clave privada al arrendatario reduce un retraso a la vez que aumenta la importancia de una terminación disciplinada.

El programa de autorización es el instrumento comercial ausente

El acuerdo principal puede establecer el trato económico. Un programa de autorización separado debe establecer el trato de seguridad de enrutamiento en términos que tanto un ingeniero como un abogado puedan comprobar.

El programa comienza con los CIDR exactos. Luego enumera cada AS de origen permitido, la entidad legal que controla ese AS, la relación de tránsito o alojamiento prevista y la longitud de prefijo permitida para cada anuncio. Si varios orígenes son temporales, el programa les asigna fechas de inicio y de eliminación. Si el arrendatario puede usar un proveedor de mitigación, el ASN del proveedor puede preaprobarse sin activarse hasta que ocurra un incidente.

A continuación vienen los roles. Nombrar al propietario del servicio del arrendador y al aprobador de respaldo, al líder de red del arrendatario y al solicitante de respaldo, y a los contactos en cada upstream previsto. Utilizar direcciones de rol y canales autenticados, no solo empleados con nombre. Los empleados se van; la autorización debe sobrevivir sin dejar cuentas personales obsoletas.

El programa establece luego los plazos. Una solicitud normal puede requerir su finalización en un día hábil. Una migración planificada puede requerir un aviso previo de cinco o diez días hábiles. Una interrupción grave puede requerir un acuse de recibo en quince minutos y un cambio acotado en sesenta minutos. Las cifras exactas dependen del servicio, pero el silencio no es un nivel de servicio.

El registro de cambios debe incluir la hora de la solicitud, el solicitante autenticado, el prefijo afectado, el origen antiguo y el nuevo, la longitud máxima, el motivo comercial, la aprobación, la observación de la publicación y la observación de la validación. Esto no es burocracia por sí misma. Cuando una ruta se vuelve Inválida, las partes necesitan saber si la ROA nunca se cambió, se cambió pero aún no es visible, se cambió incorrectamente o quedó ineficaz por otra ROA que la cubre.

Finalmente, indique qué solicitudes puede rechazar el arrendador. Una solicitud fuera del prefijo arrendado, un ASN no controlado por un operador aprobado, una longitud máxima más amplia que el diseño de enrutamiento acordado, o un cambio que invalidaría las rutas de otro cliente pueden requerir una enmienda en lugar de una ejecución inmediata. Un rechazo debe ser razonado y llevar marca de tiempo, no una invocación vaga de seguridad.

El programa debe estar versionado con firmas o una aceptación autenticada equivalente. El conjunto de ROA activas debe compararse con él en el momento de la activación, después de cada cambio aprobado, en revisiones periódicas y antes de la terminación. El acuerdo tiene entonces una respuesta medible al control: el arrendador controla la certificación dentro de un mandato preacordado; el arrendatario controla las solicitudes operativas dentro del mismo mandato; ninguno puede ampliar silenciosamente el riesgo de la otra parte.

El tiempo contractual y el tiempo de RPKI son relojes diferentes

Los arrendamientos utilizan fechas porque las fechas son legibles para los tribunales y los equipos financieros. La seguridad del enrutamiento opera a través de la publicación y la recuperación, que rara vez comparten la misma frontera.

Un arrendamiento podría comenzar a las 00:00 UTC del lunes. La ROA puede crearse antes para que las cachés de las partes confiables puedan recuperarla antes del primer anuncio. Un servicio alojado puede renovar el objeto firmado automáticamente mientras su configuración permanezca activa. Si el arrendamiento termina, el derecho comercial puede expirar aunque la última autorización publicada siga siendo válida y visible. Por el contrario, eliminar la configuración a las 00:00 no demuestra que todas las partes confiables hayan eliminado la carga útil validada correspondiente a las 00:01.

Por lo tanto, el contrato necesita tres momentos en lugar de uno. El momento de autorización lista es cuando la ruta prevista tiene una autorización válida visible y el upstream ha confirmado sus filtros. El momento de uso del servicio es cuando el arrendatario puede anunciar y colocar tráfico de clientes en el prefijo. El momento de fin de autorización es cuando el origen antiguo ya no debe figurar como permitido en RPKI después de que se haya retirado el tráfico.

Esos momentos pueden solaparse sin contradicción. Se puede preparar una ROA antes del uso comercial, siempre que se prohíba al arrendatario anunciar antes de tiempo. Puede permanecer brevemente durante una retirada ordenada, siempre que se prohíba al arrendatario añadir nuevos clientes y deba reducir el tráfico. La autorización residual es capacidad de transición controlada, no una extensión de la economía del arrendamiento.

Esto también explica por qué la expiración de la ROA es un mal sustituto de la terminación. Un certificado o una vida útil del objeto larga puede sobrevivir al arrendamiento. Una vida útil corta puede crear un riesgo de renovación evitable durante el plazo. Los sistemas alojados pueden renovar mucho antes de la expiración, mientras que los sistemas delegados dependen de la operación local. El evento determinante debe ser una instrucción explícita de fin, respaldada por la observación, en lugar de la esperanza de que un temporizador coincida con el acuerdo.

El desajuste inverso también importa. Si el arrendador elimina la ROA antes de que las direcciones de reemplazo o el origen alternativo del arrendatario estén listos, las redes que rechazan rutas Inválidas pueden dejar de transportar tráfico. Los clientes sufren la interrupción incluso si el arrendador tiene razón contractual sobre la fecha final. Si el arrendador nunca la elimina, el antiguo arrendatario conserva una oportunidad más débil pero real de originar una ruta que algunos validadores considerarán autorizada.

Por lo tanto, la alineación temporal no es indulgencia. Es la disciplina de hacer que la autorización aparezca antes de la dependencia y desaparezca después de la dependencia, con el menor solapamiento inseguro que el servicio pueda tolerar.

Los derechos de cambio de emergencia deben diseñarse antes de la emergencia

La prueba más reveladora de la gobernanza de la ROA no es una migración planificada. Es una interrupción un sábado cuando el origen aprobado no puede transportar tráfico y el único ingeniero que normalmente firma los cambios está durmiendo o inaccesible.

Una emergencia puede requerir un nuevo proveedor de tránsito, un ASN de mitigación DDoS, un centro de datos de respaldo, un origen de reemplazo tras un fallo del enrutador, o un anuncio más específico temporal. También puede implicar credenciales RPKI comprometidas o una autorización accidental que esté haciendo Inválidas rutas legítimas. La parte que observa el incidente puede ser el arrendatario, el upstream, el arrendador o una red externa.

El arrendamiento debe preautorizar categorías, no una acción ilimitada. Se puede verificar una lista de ASN de reserva en el momento de la firma. Se puede establecer una longitud máxima de prefijo de emergencia. Se puede permitir al arrendatario activar solo los prefijos que arrienda y solo por un período corto. Cualquier cambio más amplio requiere un aprobador adicional. Esto da velocidad al operador sin entregarle un cheque en blanco permanente.

La autenticación debe sobrevivir al mismo incidente. Si las solicitudes ordinarias dependen de un dominio de correo electrónico alojado detrás del prefijo afectado, el canal puede fallar cuando se necesita. Utilizar al menos un método fuera de banda y mantener contactos en ambas organizaciones. El arrendador debe exigir un código de solicitud, un rol nominado, una llamada de verificación o una aprobación criptográfica adecuada al riesgo de las partes. El objetivo es resistir la suplantación sin convertir la verificación de identidad en una barrera de varias horas.

El cambio en sí debe ser reversible. Añadir el origen estrictamente necesario; no ampliar ROAs no relacionadas. Establecer una fecha de expiración o de revisión para la autorización de emergencia. Confirmar que la nueva ruta se observa y se acepta antes de retirar la ruta antigua. Después del incidente, eliminar la autoridad temporal y conciliar el conjunto activo con el programa.

La responsabilidad debe recaer en el retraso controlable. Si el arrendatario no mantuvo los contactos aprobados o exigió un ASN no listado sin evidencia, debe asumir esa consecuencia. Si el arrendador incumplió un plazo de emergencia acordado a pesar de una solicitud válida, un simple crédito puede no reflejar la pérdida de clientes; el acuerdo puede necesitar un tope de indemnización, un derecho de rescisión o el derecho a pasar a una delegación acotada. Si el upstream rechazó una ruta a pesar de haber recibido toda la evidencia requerida, sus condiciones de servicio se tratan por separado.

Los derechos de emergencia deben ejercerse raramente. Su valor es que cada parte conozca el camino bajo presión, no que el arrendador se convierta en un servicio de enrutamiento 24 horas para cambios rutinarios.

La longitud máxima es una decisión de riesgo comercial

El campo de aspecto más técnico en una ROA puede acarrear una gran consecuencia comercial.maxLengthdetermina cuán específico puede ser un anuncio del AS autorizado sin dejar de ser consistente con esa ROA.

Una autorización demasiado estrecha puede hacer que una ruta legítima de ingeniería de tráfico o de mitigación sea Inválida. Una demasiado amplia puede permitir anuncios más específicos que nunca fueron necesarios para el arrendamiento. La decisión afecta a la contención de fallos, la práctica de los upstreams y el rango de rutas que los validadores pueden aceptar como autorizadas.

El error fácil de redacción es establecer el máximo a /24 para cada agregado IPv4 arrendado porque /24 se acepta comúnmente en la tabla global. Eso puede ser operativamente conveniente, pero delega más autoridad de la que necesita un arrendatario que solo anuncia el agregado. Si un /19 se origina siempre como /19, un máximo de /24 crea espacio para 32 rutas más específicas separadas sin explicar por qué.RFC 9582dice que el campo debe omitirse cuando es igual a la longitud del prefijo y define cómo limita la autorización de rutas más específicas.

El error opuesto es autorizar solo el agregado cuando el diseño documentado del arrendatario depende de rutas más específicas. Un proveedor de limpieza de emergencia puede anunciar /24s. Una migración entre dos orígenes puede dividir un agregado temporalmente. Si el contrato ignora ese diseño, el arrendatario pedirá un cambio apresurado en el peor momento.

El programa de autorización debe coincidir con el conjunto más pequeño de rutas esperadas, no con el conjunto más amplio técnicamente posible. Cuando se esperan varios /24s de diferentes orígenes, las ROAs explícitas pueden hacer visible la división. Cuando se justifica un máximo temporal más amplio, debe tener una fecha de finalización y una razón.

Esto también es un problema de cartera para los arrendadores. Una ROA de cobertura amplia puede interactuar con arrendamientos más específicos por debajo de ella. Antes de aprobar un cambio, el arrendador debe comprobar si la ruta válida de otro cliente se volvería Inválida debido a una autorización de cobertura con un origen diferente o un máximo restrictivo. El inventario del arrendador debe, por lo tanto, entender los solapamientos, no solo las filas de arrendamiento.

El principio comercial es la mínima autoridad necesaria. El arrendatario recibe suficiente permiso criptográfico para operar la red acordada, incluyendo una resiliencia realista. El arrendador no retiene un veto artificial sobre las operaciones documentadas, pero tampoco publica un permiso más amplio que el acordado.

El upstream es un control independiente, no un mensajero

A menudo se trata a los proveedores de tránsito como el punto de entrega final de una carta de autorización. En un arrendamiento maduro, deberían participar antes.

Antes de la activación, el upstream previsto debe confirmar los prefijos exactos y el ASN de origen que aceptará, la evidencia que requiere, el tamaño mínimo de ruta, el tratamiento de las rutas más específicas, si construye filtros a partir de datos IRR o RPKI, y con qué rapidez se actualizan esos filtros. Esta confirmación pertenece junto al programa de ROA porque una autorización técnicamente correcta tiene poco valor operativo si el filtro de cliente del upstream sigue rechazando la ruta.

El upstream debe autenticar a su cliente de forma independiente. Una ROA válida puede demostrar que una cadena de certificación autoriza el ASN de origen para un prefijo. No demuestra que la persona que abre un ticket de tránsito controle ese ASN ni que el arrendador haya aprobado la cuenta comercial. Una carta de autorización puede conectar a las partes, pero las cartas son fáciles de reenviar y difíciles de revocar globalmente. Los registros de cuenta, los contactos verificados y la confirmación directa del arrendador hacen la evidencia más sólida.

Durante el arrendamiento, el upstream no debe aceptar un cambio de origen solo porque haya aparecido una nueva ROA. El cambio puede ser accidental, malicioso o estar destinado a un proveedor diferente. Tampoco debe ignorar un nuevo estado Inválido. Debe ponerse en contacto con el arrendatario y el arrendador a través de canales conocidos, comparar la ruta con la lista de prefijos acordada y determinar si la ruta o la autorización son incorrectas.

En la terminación, el upstream tiene un papel decisivo para hacer efectiva la revocación. El arrendador puede eliminar una ROA, pero el antiguo arrendatario puede seguir enviando el anuncio BGP. El upstream puede eliminar el permiso de prefijo del cliente y rechazar la ruta en la frontera directa. Esa acción local suele ser más rápida y segura que esperar a que todas las redes apliquen los datos de validación actualizados.

Esta división es saludable. La RPKI proporciona una autorización de origen verificable globalmente. El upstream hace cumplir la relación con el cliente más cerca de la fuente. El arrendamiento conecta las dos. No se debe pedir a ninguna que cargue con toda la responsabilidad.

Un upstream que admita prefijos arrendados puede publicar sus requisitos de evidencia y su ruta de contacto de emergencia. La previsibilidad facilita un arrendamiento seguro. La revisión secreta e inconsistente empuja a los operadores hacia tickets de última hora y excepciones informales, lo que debilita tanto la seguridad como la rendición de cuentas.

Las disputas necesitan aislamiento del tráfico de clientes

La cláusula más difícil es qué sucede cuando el arrendador y el arrendatario no están de acuerdo sobre el dinero, el incumplimiento, el abuso o la renovación mientras el prefijo sigue transportando servicios activos.

El arrendador puede temer que un período de continuidad premie el impago o permita un daño. El arrendatario puede temer que el arrendador use la eliminación de la ROA como un interruptor de apagado remoto. Ambas preocupaciones son legítimas. La respuesta no puede ser una autorización permanente, pero tampoco debe ser una emboscada criptográfica sin previo aviso.

Comience distinguiendo los eventos. La expiración programada y la no renovación ordinaria deben seguir el plan de salida completo. Una factura en disputa debe desencadenar un aviso y un breve período de subsanación, a menos que el acuerdo establezca claramente que el pago es inmediato y crítico. La evidencia creíble de abuso activo puede justificar controles más estrictos, pero eliminar una ROA no detiene necesariamente la ruta abusiva; el upstream directo y el equipo del arrendatario siguen siendo puntos de intervención más inmediatos.

Una clave de firma comprometida requiere una acción de seguridad incluso si la relación comercial es sólida.

Durante una disputa de buena fe, congele la expansión discrecional. El arrendatario no debe añadir clientes, solicitar nuevos orígenes ni ampliar las longitudes máximas. El arrendador debe preservar las últimas autorizaciones seguras conocidas durante el período de continuidad acotado. Ambas partes deben notificar al upstream que ningún cambio es válido sin confirmación dual, excepto una emergencia documentada necesaria para proteger el tráfico.

Un contacto de escalado independiente puede determinar si una solicitud se ajusta al programa existente sin decidir todo el litigio. La cuestión es limitada: ¿la acción solicitada preserva un servicio ya autorizado o amplía los derechos? Esa determinación limitada puede mantener la estabilidad del enrutamiento mientras las reclamaciones comerciales prosiguen en otra parte.

El acuerdo también debe definir un final definitivo. La continuidad no puede convertirse en una ocupación indefinida. Al final del período de subsanación o migración, el arrendatario debe retirar las rutas, el upstream debe eliminar los filtros y el arrendador debe eliminar la ROA. El incumplimiento por cualquiera de las partes produce evidencia y remedios especificados. Si la seguridad del cliente requiere una orden judicial o una medida cautelar, las partes saben qué actos deben ser restringidos.

Los registros son lo más importante aquí. Una parte que alegue una eliminación injusta debe poder mostrar la autorización acordada, la solicitud, el acuse de recibo, la hora del cambio y el impacto en la validación. Un arrendador que alegue un uso continuado debe poder mostrar observaciones de ruta después del plazo de retirada. El aislamiento de disputas funciona solo cuando los hechos pueden reconstruirse sin confiar en la bandeja de entrada de una de las partes.

La norma rectora es simple: no convierta a los usuarios de Internet ajenos al caso en el mecanismo de ejecución de una deuda privada, y no utilice su dependencia para hacer perpetuo un arrendamiento.

La revocación es necesaria, pero la eliminación no es una solución completa

Un arrendamiento debe terminar con el antiguo arrendatario incapaz de confiar en la autorización del arrendador. Eso requiere una revocación o eliminación en la capa apropiada. También requiere más que una revocación.

Cuando llega el momento de fin de autorización, el arrendador debe eliminar o modificar la configuración de la ROA correspondiente. En configuraciones delegadas, puede revocar el certificado subordinado acotado después de confirmar que no se requiere ninguna autorización continua. Las partes deben observar las cargas útiles validadas resultantes desde más de un punto de observación independiente. Un mensaje de éxito del portal es una evidencia de un acto enviado, no una prueba de que el estado público ha convergido.

Al mismo tiempo, el arrendatario debe retirar la ruta BGP y sus upstreams deben eliminar el permiso de cliente. Los objetos de ruta IRR que aún nombren el origen antiguo deben eliminarse o actualizarse. El DNS inverso y los contactos públicos ya no deben apuntar a un operador anterior cuando eso pudiera desviar los informes operativos o de abuso. Estos sistemas tienen diferentes tiempos de actualización y mantenedores, por lo que una sola marca de tiempo no puede demostrar una salida completa.

La eliminación también puede tener efectos colaterales. Una ROA puede cubrir varios prefijos, y un certificado delegado puede contener recursos más allá de un arrendamiento si el arrendador lo diseñó mal. El operador debe identificar el objeto o la autorización exacta que debe cambiarse. «Revocar la RPKI del cliente» no es una instrucción segura a menos que el límite de certificación coincida con el límite del cliente.

El riesgo residual va en ambos sentidos. Si la ROA permanece, el antiguo arrendatario conserva una ventaja de validación si continúa anunciando. Si la ROA desaparece mientras queda una ruta obsoleta, la ruta puede volverse Inválida y ser rechazada de forma desigual, creando una accesibilidad parcial en lugar de un silencio universal. Si no queda ninguna ROA de cobertura, la ruta puede volverse No Encontrada y continuar propagándose bajo muchas políticas. Por lo tanto, el estado RPKI no es un sustituto fiable de la retirada en origen.

Un registro de finalización debe indicar: ruta retirada por el origen antiguo; filtro del upstream eliminado; ROA antigua ausente o reemplazada; sin autorización de cobertura no intencionada restante; certificado delegado cerrado cuando corresponda; registros IRR conciliados; y monitoreo continuado durante un período de observación definido. Las excepciones deben nombrarse en lugar de redondearse a «hecho».

La revocación protege al arrendador y al siguiente usuario. La retirada coordinada protege a los clientes actuales. Una salida responsable hace ambas cosas.

El RIR debe autenticar la autoridad de certificación, no decidir el arrendamiento

Los RIR ocupan una posición delicada porque el servicio alojado puede convertirlos en el lugar donde se ejecuta un cambio en disputa. Eso no significa que deban convertirse en tribunales para cada arrendamiento IPv4.

El RIR tiene un interés legítimo en autenticar a la organización con derecho a usar su servicio de certificación, proteger las cuentas, mantener la jerarquía y responder a un compromiso probado de credenciales. Puede necesitar alterar los recursos certificados después de una transferencia, devolución o cambio de registro. La documentación alojada de RIPE NCC señala que los certificados de recursos se actualizan a medida que los recursos se mueven y las ROAs publicadas se ajustan cuando se eliminan recursos. Estas son consecuencias de la jerarquía de certificación.

Una disputa privada de arrendamiento es diferente. El RIR generalmente carece del contrato, el historial de pagos, los hechos de migración de clientes y la evidencia de ley aplicable necesarios para decidir qué parte está en incumplimiento. Si acepta instrucciones no respaldadas de un arrendatario, puede desplazar la autoridad del titular. Si trata cada instrucción del titular como concluyente a pesar de una orden judicial o un compromiso probado de cuenta, puede amplificar el daño. La respuesta es un rol limitado con un proceso claro.

El RIR puede preservar registros, autenticar a los actores de la cuenta, publicar el estado del servicio, proporcionar canales de emergencia documentados para incidentes de seguridad y cumplir con órdenes legales válidas. Puede hacer que los roles de cuenta sean lo suficientemente granulares para que un titular no necesite compartir credenciales amplias. Puede explicar los efectos técnicos de las opciones alojadas y delegadas. Debe ser cauteloso a la hora de convertir una política de arrendamiento ambigua en un control discrecional sobre las rutas activas.

Esta moderación es coherente con el significado limitado de la ROA. El servicio de certificación verifica la autoridad dentro de la jerarquía de recursos numéricos. No certifica cada razón privada para ejercer esa autoridad. La obligación comercial sigue siendo exigible entre las partes y, cuando sea necesario, a través de los tribunales o los mecanismos de disputa acordados.

La capa de registro puede mejorar el arrendamiento sin reconocer una nueva categoría de propiedad. Puede admitir usuarios con alcance limitado, un historial de cambios legible por máquina, notificaciones a múltiples contactos, acciones destructivas diferidas cuando sea seguro y evidencia exportable de las configuraciones actuales y anteriores. Estas herramientas reducen la dependencia de un solo titular de cuenta, dejando el acuerdo legal fuera de la CA.

El objetivo de la política debe ser una ejecución predecible, no la aprobación moral de cada arrendamiento. Un sistema seguro puede distinguir a la persona técnicamente autorizada para firmar de la persona contractualmente autorizada para solicitar, sin pretender que siempre son la misma persona.

El control tiene un precio económico

El control de la ROA a menudo se incluye en el precio del arrendamiento como si fuera una tarea administrativa gratuita. Es un servicio de continuidad separado.

Un arrendador que promete cambios rápidos debe mantener personal capacitado, credenciales protegidas, monitoreo, aprobadores de respaldo y cobertura de incidentes. Un modelo delegado requiere la operación de la CA y fiabilidad en la publicación. Un arrendatario que necesita cambios frecuentes de origen impone más coste y crea más oportunidades de error que uno con un ASN estable. La fijación de precios debe hacer visibles esas diferencias.

La alternativa es una falsa economía. Un arrendamiento de bajo coste con una respuesta de cinco días a un cambio de emergencia en la ROA puede ser inutilizable para una red con compromisos de disponibilidad estrictos. Un arrendatario puede entonces compartir credenciales informalmente, pedir excepciones a un upstream o mantener una autorización demasiado amplia para evitar retrasos futuros. Cada atajo convierte un requisito de servicio no valorado en un riesgo de seguridad.

La economía más amplia de la identidad de red agudiza el punto. La nota de Lu Heng sobreidentidad de red y continuidad del clientesostiene que una dirección puede quedar incrustada en listas blancas de clientes, reglas de socios, APIs y sistemas de cumplimiento. Una vez que eso sucede, un cambio fallido en la ROA no es solo un inconveniente de enrutamiento. Puede interrumpir una identidad empresarial en la que terceros ya confían.

Su análisis sobrearrendamiento IPv4 gestionado y riesgo de registroplantea un punto de mercado relacionado: obtener direcciones es solo la transacción visible; la operatividad continua depende de cómo se gestionan los riesgos de registro, enrutamiento y ciclo de vida. Un análisis neutral no necesita aceptar todas las conclusiones institucionales de ese argumento para reconocer el hecho operativo. La parte que vende continuidad debe describir y valorar los actos que la continuidad requiere.

Esto puede generar niveles de servicio. Un arrendamiento básico puede permitir un origen estable y cambios en horario laboral. Un arrendamiento resiliente puede incluir dos orígenes, mitigación preaprobada, respuesta las 24 horas y conciliación periódica. Un arrendatario con su propia CA competente puede optar por una delegación acotada y aceptar más obligaciones. Los niveles transparentes son mejores que pretender que cada arrendamiento incluye una administración RPKI instantánea e ilimitada.

El control también debe afectar a los remedios. Si el arrendador cobra por la cobertura de emergencia y no la proporciona, la consecuencia debe ser significativa. Si el arrendatario elige un nivel más lento y luego exige una acción instantánea, no se debe tratar al arrendador como si hubiera prometido lo que no vendió.

El mercado se vuelve más seguro cuando la dependencia criptográfica se nombra como parte del producto en lugar de ocultarse en «soporte».

Una asignación práctica de derechos

No existe un acuerdo universal, pero se puede establecer claramente un modelo defendible.

El arrendador conserva el control último de la relación de certificación de recursos y puede rechazar cambios fuera del alcance arrendado. Debe mantener al menos dos operadores autorizados, proteger las credenciales, crear las ROAs iniciales antes de la activación, cumplir con los plazos definidos para cambios normales y de emergencia, dar aviso previo antes de una acción destructiva excepto en una emergencia de seguridad genuina, y eliminar la autorización después de la salida verificada.

El arrendatario controla el diseño de su red dentro del programa. Debe identificar y demostrar el control de cada ASN de origen, proporcionar planes de ruta precisos, mantener dos solicitantes autenticados, notificar al arrendador antes de los cambios planificados, evitar anuncios fuera de la autorización, monitorear el estado RPKI, retirarse puntualmente al término y conservar evidencia del cierre del upstream.

El upstream verifica de forma independiente la relación cliente-prefijo, prepara los filtros antes de la activación, monitorea las discrepancias, admite un contacto de emergencia directo, rechaza los cambios de origen no programados a la espera de confirmación y elimina el permiso a la salida. No se basa en una ROA como única prueba de la autoridad del cliente.

El RIR o la CA principal autentica al titular del recurso, opera o soporta el modelo de certificación elegido, protege la jerarquía principal, proporciona una publicación fiable y registros de cambios, y maneja eventos probados de credenciales o legales dentro de un ámbito transparente. No infiere el arrendamiento privado a partir de BGP ni decide sobre facturas ordinarias.

Para arrendamientos con muchos cambios o alta dependencia, una CA subordinada acotada puede acercar la ejecución al arrendatario. Para arrendamientos con pocos cambios, el servicio alojado con estrictos compromisos de respuesta puede ser más seguro. Para plazos muy cortos, el coste de la transición de RPKI y del upstream puede justificar un preaviso más largo o un diseño de direcciones diferente. La elección debe seguir la dependencia operativa, no la ideología.

Todos los modelos necesitan las mismas barreras de protección: alcance exacto, mínima autoridad, contactos redundantes, respuesta medida, estado visible, solapamiento seguro, terminación firme y evidencia independiente. Quite una, y el control migra a quien casualmente posea la credencial cuando algo salga mal.

La prueba es si la autoridad sigue a la responsabilidad

Un arrendamiento IPv4 es sostenible cuando la parte responsable del servicio puede obtener la autorización necesaria, mientras que la parte responsable del recurso puede impedir la expansión no autorizada y garantizar la revocación final.

Ese equilibrio no se logra asignando la ROA a un actor en una frase. Se logra conectando el permiso comercial con los eventos operativos. La autoridad de certificación del arrendador no debe convertirse en un veto no valorado sobre los cambios rutinarios de red. La necesidad de rapidez del arrendatario no debe convertirse en una autoridad de firma permanente sobre un agregado. El upstream no debe externalizar la verificación del cliente a un objeto criptográfico. El RIR no debe ser empujado a decidir un contrato que no puede ver.

La tecnología ya expone las distinciones relevantes. Una ROA nombra un prefijo, un origen y una longitud máxima opcional. El servicio alojado centraliza las operaciones de firma. El servicio delegado mueve el control de la clave y el mantenimiento. Las partes confiables recuperan y validan el material publicado. Los enrutadores aplican políticas locales. La tarea de gobernanza es hacer que el arrendamiento sea igual de preciso.

El arrendamiento más seguro crea la autorización antes de que el tráfico dependa de ella, mantiene la autorización alineada con las rutas documentadas, permite una adaptación de emergencia limitada, aísla las disputas de los clientes, y retira tanto la ruta como su permiso criptográfico al final. Registra quién hizo cada acto y cuándo.

La respuesta final a «¿Quién controla la ROA?» es, por tanto, intencionadamente plural. El arrendador controla la autoridad certificada. El arrendatario controla el requisito operativo. El upstream controla la aceptación directa. El RIR controla un servicio principal o alojado dentro de su ámbito. El contrato controla cómo se encuentran esos poderes.

Si el contrato guarda silencio, el titular de la credencial controla la crisis. Si el contrato es preciso, ningún actor controla más que la responsabilidad que ha aceptado asumir.

Fuentes