Resumen

  • ARIN establece un ASPA único por cada Customer ASN y permite modificar el conjunto de Provider ASes. Aunque la intención sea cambiar un proveedor, la operación sustituye una declaración completa.
  • La guía de ARIN separa el efecto inmediato en su base RPKI, la aparición en el repositorio público dentro de 24 horas, las actualizaciones cada pocos minutos y la comprobación con un validador. Son etapas distintas.
  • Los borradores activos del IETF exigen la unión de todos los proveedores, incluidos los servidores de rutas no transparentes, y distinguen No Attestation de Not Provider+. Una omisión puede importar sin volver inválida automáticamente cualquier ruta.
  • El control apropiado es un recibo que vincule conjunto anterior autorizado, conjunto posterior completo, resultado atómico, objeto publicado y observación del validador, sin exponer contratos ni topología privada.

Los cambios de red suelen llegar comprimidos. “Alta del nuevo proveedor” cabe en el asunto de un ticket. “Retirar el tránsito antiguo” cabe en una línea del plan de migración. Esa economía verbal es útil para coordinar personas, pero describe mal lo que ocurre cuando el Customer ASN actualiza su ASPA.

El objeto no conserva una sucesión de órdenes independientes. Declara un conjunto. Para añadir un proveedor hay que volver a afirmar también todos los proveedores que deben permanecer. Para eliminar uno hay que decidir qué miembros sobreviven. La diferencia entre la intención incremental y el estado completo es el lugar donde un cambio correcto puede producir un resultado incorrecto.

Imaginemos dos escritores autorizados. El primero lee el conjunto {A, B} y prepara {A, B, C}. Antes de que lo envíe, el segundo incorpora un servidor de rutas no transparente y publica {A, B, R}. Si el primer escritor entrega después su conjunto completo, R desaparece. Las dos peticiones pueden estar bien formadas y las dos pueden recibir confirmación. El problema es que una de ellas se basó en un pasado que ya no existía.

ARIN documenta una estructura que permite ver este riesgo. Si una organización posee varios ASN, debe crear un ASPA único para cada Customer ASN. En ARIN Online modifica el conjunto de Provider ASes. La API RPKI representa operaciones aspaDelete y aspaAdd con customerAsId y providerAsIds, y puede agrupar ASPA y ROA en una transacción en la que todo se acepta o todo falla.

La atomicidad evita estados a medias dentro del lote. No evita que el lote entero esté desactualizado. Una respuesta satisfactoria prueba que ARIN aceptó esos elementos juntos; no prueba que el conjunto anterior que vio el solicitante fuera todavía vigente. Tampoco prueba que el nuevo objeto ya estuviera en el repositorio público ni que un relying party lo hubiera incorporado.

La interfaz cuenta movimientos; el objeto expresa estado

Las interfaces de administración convierten los conjuntos en listas porque las listas son fáciles de editar. Un botón añade una fila y otro la elimina. La confirmación suele repetir el cambio visible. Sin embargo, un consumidor RPKI no ve el gesto. Ve el resultado firmado.

El perfil ASPA que el IETF mantiene como Internet-Draft indica que deben figurar todos los Provider ASes, incluidos los ASN de servidores de rutas no transparentes. Si existen varios ASPA válidos para un mismo cliente, el relying party toma la unión. El propio texto recomienda evitar esa multiplicidad porque los intervalos de validez pueden introducir carreras. El borrador de verificación también recomienda un solo objeto que contenga la unión completa.

No son RFC definitivas y no deben presentarse como tales. Son trabajos activos, sujetos a cambios. Pero su modelo deja clara la unidad que se está protegiendo: no es “el proveedor recién añadido”, sino el conjunto que se declara utilizable en ese momento.

La condición de seguridad es sencilla. La petición debería incluir una huella canónica del estado que el autor vio. ARIN solo sustituiría el conjunto si esa huella siguiera siendo la actual. Si otro actor lo modificó, respondería con un conflicto y el estado nuevo. El sistema no intentaría decidir si C o R corresponde a una relación comercial real; devolvería esa decisión al titular antes de firmar una omisión accidental.

Este patrón se conoce en otros sistemas como comparación y escritura. Aquí tiene un valor adicional: conserva la relación entre una intención humana pequeña y una afirmación criptográfica amplia. También permite que una automatización sea rápida sin convertir “el último en escribir gana” en una regla silenciosa de política de rutas.

Dos clases de ausencia

El borrador de verificación ASPA no trata todas las ausencias igual. Cuando no hay una entrada ASPA utilizable, el resultado de autorización es No Attestation. Si el proveedor aparece en el conjunto utilizable, es Provider+. Si hay un conjunto pero ese proveedor no figura, es Not Provider+.

Por eso borrar un objeto no equivale a publicar un conjunto no vacío que olvidó un miembro. En el primer caso falta la atestación utilizable. En el segundo existe una declaración utilizable que no reconoce esa pareja entre cliente y proveedor. Un historial que solo diga “se procesó la solicitud” borra precisamente esta diferencia.

Tampoco conviene exagerarla. La comprobación completa del AS path usa direcciones, segmentos y autorizaciones sucesivas. El borrador advierte que un proveedor ausente puede hacer que más adelante una ruta resulte falsamente ASPA Invalid. No demuestra que toda ruta relacionada quede automáticamente inválida, ni que esto haya ocurrido en el servicio de ARIN.

Los proveedores de reserva muestran por qué el momento importa. El texto recomienda registrar con antelación los proveedores de emergencia o standby. La razón es operativa: cuando el tráfico tenga que moverse, la autorización ya debería estar disponible. Si se añade en mitad de la avería, la aceptación de ARIN, la publicación y la actualización de cada validador entran en el reloj de recuperación.

Un servidor de rutas no transparente plantea el mismo problema desde otro ángulo. Puede no parecer un tránsito convencional en la documentación comercial, pero su ASN debe entrar en el conjunto según el perfil. Un formulario que solo pregunte por “proveedores nuevos” puede ocultar esa categoría. Un recibo que presenta el conjunto completo obliga a verla sin pedir al registro que infiera la topología.

El éxito ocurre en varias horas distintas

ARIN dice que el cambio surte efecto inmediatamente en su base de datos RPKI y aparece en el repositorio público dentro de 24 horas. En la misma guía explica que el repositorio se actualiza cada pocos minutos y pide verificar el ASPA activo con un validador RPKI. Las frases no se contradicen: describen un compromiso exterior y una cadencia ordinaria, además de una comprobación fuera del sistema de escritura.

De ahí salen cuatro relojes. El primero es la autorización: cuándo alguien con competencia vio un estado y aprobó el conjunto que debía reemplazarlo. El segundo es la transacción: recepción, autenticación, validación y aceptación atómica. El tercero es la publicación: cuándo el objeto emitido pudo observarse en el repositorio. El cuarto es el consumo: cuándo un validador concreto lo recuperó y construyó el conjunto utilizable.

No basta con asignar un sello de tiempo común. Si una ruta se investiga después, el equipo necesita saber si el proveedor faltaba ya en la decisión, desapareció en el payload, quedó atrapado por un conflicto, aún no era visible públicamente o no había llegado a la vista del validador elegido. Son causas diferentes y pertenecen a responsables distintos.

El límite de 24 horas tampoco debe convertirse en la presunción de que cada publicación tarda un día. La evidencia correcta es la medición: hora de aceptación, huella del objeto emitido, referencia de manifiesto o repositorio y primera observación desde un monitor definido. Así se puede comparar el comportamiento real con el límite sin inventar una demora.

La observación del validador requiere modestia. Hay que registrar punto de vista, software, versión y hora de recuperación. Ese resultado prueba lo que vio ese sistema. Varias vistas independientes aportan confianza, pero ninguna autoriza a declarar que todo Internet ha convergido.

Un recibo de diferencias, no una novela de auditoría

El recibo puede ser pequeño y principalmente estructurado. Empieza con el Customer ASN y el certificado o contexto de CA que emitirá el objeto. Después incluye el conjunto previo en orden canónico, o su hash acompañado de una referencia recuperable. Añade el conjunto completo enviado y deriva las listas de miembros añadidos, retirados y conservados.

Los conjuntos completos son la prueba primaria; la diferencia es su explicación. Esta prioridad evita que “añadido C” oculte la pérdida de B. También permite calcular la misma diferencia de forma independiente, sin depender del texto de la interfaz.

La parte de solicitud debería guardar un identificador, la clase del actor autenticado, la huella del payload, la precondición sobre el estado anterior y el resultado. Si comparte transacción con ROA, el recibo puede expresar el vínculo y el carácter todo-o-nada sin divulgar más prefijos de los necesarios.

La parte de publicación necesita la huella del ASPA emitido, la referencia al repositorio o manifiesto y la primera observación pública. La parte de validación incluye la versión del validador, el lugar lógico de la medición, la hora, el conjunto utilizable observado y las transiciones relevantes entre No Attestation, Provider+ y Not Provider+.

Debe haber además una cadena de correcciones. “Sustituido por”, “corregido por”, “caducado en” y “revertido a” son enlaces, no permisos para borrar el pasado. Una reversión vuelve a publicar un conjunto completo; no convierte el estado equivocado en algo que nunca existió.

Los roles operativos pueden vivir en una capa restringida. Marcar un ASN como servidor de rutas no transparente, tránsito habitual o proveedor de reserva ayuda a evitar omisiones. No hace falta introducir esa etiqueta en el objeto firmado ni exponerla a todo lector.

La transparencia no exige publicar el contrato

Los ASN incluidos en un ASPA están destinados al consumo público de RPKI. De ahí no se deduce que sean públicos el precio del tránsito, su volumen, los contactos, las credenciales, el calendario de mantenimiento o el diagrama interno. El recibo público puede limitarse a conjuntos, hashes, referencias, clases de actor y observaciones. El expediente completo puede conservarse con acceso de miembro.

Esta separación hace que la privacidad sea una decisión de diseño, no una razón para perder la trazabilidad. Incluso la identidad humana puede reemplazarse públicamente por una función autorizada, mientras el sistema interno mantiene la prueba necesaria para investigar abusos.

ARIN anunció en marzo de 2026 que ASPA estaba plenamente disponible en ARIN Online. Esa disponibilidad no mide adopción ni certifica que no haya errores. En ARIN 57, John Curran delimitó el papel institucional: ARIN podía implementar y explicar ASPA, pero no le correspondía decir a los operadores que debían desplegarlo.

El recibo respeta esa división. ARIN no decide qué relación existe. Custodia la decisión autenticada, detecta si se apoya en un estado viejo, publica el objeto y ofrece evidencia de observación. El titular sigue siendo responsable del conjunto.

No hay aquí una acusación de que ARIN haya perdido, reordenado o publicado mal un ASPA real. No se identifica ninguna ruta invalidada. El argumento nace antes del incidente: el momento barato para conservar el estado anterior es la propia modificación. Después, las cachés avanzan, las sesiones terminan y la reconstrucción se convierte en arqueología.

Un cambio de proveedor parece singular en la hoja de trabajo. Su efecto es plural en la declaración. El recibo correcto une ambas escalas y demuestra cómo pasó una decisión completa desde el titular hasta una vista independiente.

Fuentes