Resumen

  • RFC 8206 obliga a la PE configurada con ambos ASN a mantener claves válidas para ambos y a conservar la antigua hasta que migren sus sesiones eBGP relevantes. Es una regla de autenticación de camino, no prueba de una operación corporativa.
  • Dos ROA, dos firmas o un segmento pCount=0 pueden describir una transición técnica limitada. No establecen adquisición, control, migración total, consentimiento de pares, entrega de paquetes ni éxito de un servicio.

Los identificadores se convierten con facilidad en relatos. Un ASN viejo aún firma; un ASN nuevo aparece en autorizaciones; por tanto, alguien concluye que hubo una compra y que la integración está acabada. La conclusión añade casi todo lo importante. La RFC habla de un escenario posible en el que un proveedor puede fusionar AS, mantener identificadores heredados o hacer que una PE se presente ante un par como el ASN anterior. No nombra una transacción, ni afirma que alguna se haya realizado. Describe el problema de interoperabilidad que puede existir durante una migración.

Esa migración no tiene por qué ser instantánea. La RFC 8206 reconoce una transición prolongada y no exige que todos los routers cambien al mismo tiempo ni que cada cliente coordine el cambio. Por eso el ASN heredado puede seguir siendo necesario. La antigua clave no es una reliquia ceremonial: puede ser un requisito para una adyacencia eBGP cuya expectativa configurada sigue usando el ASN anterior. Saber que la clave está vigente no permite saber cuántas adyacencias quedan, quién aceptó el cambio o qué hecho jurídico explica la configuración.

La validación de origen demuestra la misma separación. La ASN de reemplazo puede necesitar un ROA para un prefijo aunque PE del ASN viejo continúen originándolo. Dos autorizaciones concurrentes son permitidas. El ROA expresa una autorización de origen para la validación RPKI; no es un título de propiedad, un certificado de transferencia del registro, una aceptación de clientes ni una medición de tráfico. Ampliar el conjunto de orígenes autorizados es distinto de documentar la finalización de una migración.

BGPsec tampoco sustituye esas pruebas. Según RFC 8205, los certificados RPKI dan fe de asignaciones de números AS y espacio IP; el emisor firma con la clave privada correspondiente y el validador puede comprobarlo sin tenerla. La firma aporta una propiedad del Secure_Path construido y de la política bajo la cual se valida. No entrega una prueba de selección de FIB, llegada de paquetes, disponibilidad de aplicación o control societario.

El mecanismo de RFC 8206 está estrechamente cercado. Parte de una PE configurada localmente con los ASN antiguo y nuevo, ante una sesión eBGP existente. En salida, la PE firma con ambos; la parte de transición del ASN antiguo lleva pCount=0. Si el vecino no es BGPsec, su AS_PATH reconstruido no muestra ese segmento, aunque el Secure_Path sí lo retiene. En entrada, una CE que todavía espera el ASN antiguo activa la adición definida del segmento. El diseño conserva una interpretación correcta en ese borde; no permite exportar una afirmación de empresa por todo el sistema de rutas.

De hecho, el RFC niega que sea razonable esperar que un dominio de cliente no coordinado acepte pCount=0. No impone cambios remotos, coordinación mundial ni una ruta visible más larga. La ventaja del procedimiento —su alcance local— es también su límite evidencial. No demuestra que haya adaptación al otro lado del borde.

La frase sobre conservar la clave exige especial cuidado: debe seguir siendo válida hasta que hayan migrado todas las sesiones eBGP pertinentes. Es una instrucción al operador de la PE. Una actualización firmada no declara que ya no exista ninguna sesión pendiente. Para demostrarlo harían falta inventario de sesiones, configuración, ventanas de validez, registros del validador y observaciones independientes de encaminamiento. Además, cada receptor acepta o rechaza un camino conforme a su propia relación de confianza y negocio; no hay un voto universal de finalización.

La idea de Heng Lu de una especificación inicial mínima ayuda a no cargar el RFC con una constitución empresarial. La capa común fija el mínimo determinista para interoperar con seguridad. El calendario, la custodia de claves, la política de pares, la coordinación de clientes y la adopción efectiva siguen siendo decisiones locales. La adopción voluntaria existe operativamente donde actores compatibles implementan, validan y aceptan; una RFC o una clave por sí solas no hacen ese trabajo.

La investigación responsable debe recorrer escalones separados: especificación, autorización de origen, estado de clave, camino firmado, resultado de validación, sesión migrada, paquetes y servicio observados, y, si procede, fuentes de registro o societarias. Wesley George es coautor de la regla técnica. La regla no convierte un vestigio de configuración en una declaración de fusión.

Fuentes