Resumen

  • Los RFC 6472 y 9774 muestran la evolución desde una recomendación para dejar de originar rutas con AS_SET o AS_CONFED_SET hasta requisitos explícitos para no anunciarlas y tratarlas como retiradas al recibirlas, con excepciones de transición bajo control del operador.
  • El RFC 8205 sitúa BGPsec sobre límites igualmente concretos: negociación de capacidades, soporte de ASN de cuatro octetos, certificados RPKI vinculados a recursos, validación de la ruta y continuidad de los datos, sin confundir una ruta de control válida con el recorrido real de los paquetes ni con una prueba de despliegue.

Una contribución documentada en decisiones compartidas

Los registros primarios delimitan con exactitud qué puede afirmarse sobre Kotikalapudi Sriram. El RFC 6472, publicado como Best Current Practice en diciembre de 2011, lo identifica como coautor junto con Warren Kumari. El RFC 8205, publicado en la vía de estándares en septiembre de 2017, lo identifica como coeditor junto con Matthew Lepinski. El RFC 9774, publicado en mayo de 2025, vuelve a identificarlo como coautor dentro de un grupo de cuatro autores. Esos documentos permiten describir una participación sostenida en la definición de reglas para AS_PATH, BGPsec y RPKI.

No permiten atribuirle en solitario el consenso de la IETF, una implantación concreta, la operación de una red ni resultados medidos.

Esa distinción es sustancial. Un RFC de consenso no es la transcripción de la voluntad de una sola persona. La autoría o edición colaborativa vincula a Sriram con el trabajo técnico publicado, pero los términos normativos pertenecen al documento y al proceso que lo aprobó. Del mismo modo, una especificación describe el comportamiento que debe ofrecer una implementación conforme; no demuestra que todos los equipos lo ofrezcan, que todas las redes lo hayan activado o que un operador determinado haya elegido una política concreta.

Mantener separadas esas capas evita convertir una contribución verificable en una biografía promocional o en una afirmación de autoridad que las fuentes no sostienen.

El valor del conjunto aparece al leer los tres documentos como dos líneas de decisión relacionadas. La primera sigue la retirada de AS_SET y AS_CONFED_SET desde una recomendación operativa hasta una prohibición normativa acompañada de comportamiento de recepción. La segunda define BGPsec como un mecanismo que protege información ordenada sobre la propagación de un anuncio y la vincula con números de sistema autónomo, recursos IP, claves y capacidades negociadas.

Ambas líneas parten de una idea operativa común: la seguridad de encaminamiento necesita estados que puedan interpretarse sin ambigüedad y registros que puedan comprobarse contra el comportamiento del protocolo.

El problema de un conjunto sin orden dentro de AS_PATH

AS_PATH registra los sistemas autónomos asociados a la propagación de una ruta BGP. El RFC 6472 explica que un segmento AS_SET puede aparecer cuando un router agrega varias rutas en una sola y conserva, como conjunto no ordenado, los AS atravesados por los prefijos contribuyentes. AS_CONFED_SET cumple una función análoga dentro de una confederación, usando números de AS miembros. La agregación reduce varios destinos más específicos a un anuncio menos específico, pero el conjunto pierde el orden que sí conserva una secuencia.

La pérdida de orden no es un detalle de presentación. Al combinar rutas, la agregación puede desdibujar qué significa originar el prefijo agregado. También puede eliminar la información precisa de trayecto de los componentes. El RFC 6472 relaciona esa ambigüedad con dos consecuencias técnicas: dificulta autenticar el origen del agregado mediante tecnologías basadas en extensiones X.509 para direcciones IP y números de AS, y complica la ingeniería de tráfico porque el camino exacto de los prefijos componentes deja de estar representado.

El documento advierte que esa dificultad puede producir problemas de alcanzabilidad para el agregado o para sus rutas más específicas, pero no afirma que tal resultado ocurra en todos los casos.

El texto de 2011 también ofrece un juicio de proporcionalidad. A partir del análisis histórico citado por el propio RFC, la agregación con AS_SET se observaba rara vez en la red pública y, cuando aparecía, a menudo mostraba usos incorrectos, como conjuntos con un solo AS o números reservados. La reducción de la tabla obtenida por esa técnica era muy pequeña frente a la complejidad añadida al protocolo. La conclusión no era que toda agregación fuera ilegítima, sino que el beneficio marginal de esa forma concreta no compensaba la pérdida de claridad ni el obstáculo que imponía a mecanismos de seguridad nuevos.

Por eso, el RFC 6472 formuló una recomendación dirigida al emisor. Recomendó que los operadores no generaran anuncios nuevos con AS_SET o AS_CONFED_SET. Para rutas ya anunciadas con esos segmentos, indicó que debían retirarse y volver a anunciarse los prefijos componentes sin AS_SET, deshaciendo la agregación anterior. Añadió una cautela esencial: como en cualquier cambio de encaminamiento, el operador debía comprender todas sus implicaciones.

El documento observó que tecnologías futuras podrían considerar inviables las rutas que contuvieran esos conjuntos y que algunos operadores podrían filtrarlas, pero evitó prescribir cómo debía actuar el receptor. Su alcance estaba deliberadamente concentrado en el lado emisor.

El argumento de seguridad de 2011 tampoco prometía una defensa completa. Era más limitado: desalentar una función raramente ejercitada abría la posibilidad de retirar complejidad y código, reducir la superficie expuesta y simplificar el diseño de RPKI y de los sistemas dependientes de ella. Esa formulación importa porque relaciona seguridad con el estado real que una implementación debe mantener. Cuantas más variantes semánticas tenga que aceptar el protocolo, más casos deben implementar, probar y operar los equipos.

Eliminar una variante ambigua puede estrechar el espacio de error, aunque el RFC por sí mismo no demuestra que el código haya sido retirado ni cuantifica una reducción de incidentes.

De recomendación operativa a requisito del estándar

El RFC 9774 retoma la misma línea en 2025 y la convierte en requisito de estándares. El documento declara obsoleto el RFC 6472, actualiza las especificaciones previas de BGP y confederaciones, y prohíbe el uso de AS_SET y AS_CONFED_SET en AS_PATH. La continuidad entre ambos textos es clara, pero su fuerza normativa no es idéntica. El primero recomendaba dejar de originar esos segmentos; el segundo establece, salvo configuración explícita del operador durante una transición u otra excepción, que un hablante BGP no debe anunciar mensajes UPDATE que los contengan.

La regla de recepción cierra el límite que el RFC 6472 había dejado abierto. Ante un UPDATE con AS_SET o AS_CONFED_SET en AS_PATH o AS4_PATH, el RFC 9774 exige aplicar el tratamiento conocido como "treat-as-withdraw": la ruta se maneja como retirada en vez de aceptar el atributo ambiguo como base normal de selección. Esto alinea emisor y receptor alrededor de un estado observable. La excepción configurable reconoce que una transición no siempre es instantánea, pero no convierte esa excepción en el comportamiento predeterminado.

El operador conserva una decisión delimitada; la base del estándar deja de depender de una interpretación tolerante del conjunto.

El cambio también aclara la relación con la validación basada en RPKI. El RFC 9774 señala que RPKI Route Origin Validation no puede considerar válida una ruta con AS_SET, que BGPsec no admite AS_SET y que otras verificaciones de AS_PATH basadas en RPKI también encuentran un conflicto con esa representación. La razón no es meramente formal: un conjunto no ordenado dificulta identificar un origen único y reconstruir una cadena verificable. La seguridad de recursos necesita saber qué número de AS está autorizado para originar un prefijo; la seguridad del camino necesita preservar qué AS autorizó la propagación hacia el siguiente.

Un conjunto que borra el orden debilita ambas preguntas.

Retirar AS_SET no elimina la necesidad de agregar rutas. El RFC 9774 describe una alternativa denominada agregación breve consistente. En ella, el AS_PATH del agregado se trunca de manera controlada después de la última aparición del AS de origen deseado, se evita generar AS_SET o AS_CONFED_SET y se conserva un origen no ambiguo para el que pueda existir una autorización de origen. Cuando se elimina información respecto del resultado ordinario de la agregación, el atributo ATOMIC_AGGREGATE debe acompañar la ruta según las condiciones del documento.

El punto operativo no es esconder la pérdida de detalle, sino representarla mediante atributos y una política coherente.

Las consideraciones operativas del RFC 9774 añaden límites a esa sustitución. Los operadores que agregan prefijos deben usar la modalidad breve consistente; el agregado no debería anunciarse a los AS que contribuyeron rutas, y los prefijos más específicos enviados a cada contribuyente deben excluir los aprendidos de ese mismo AS. El documento también recuerda el riesgo de bucles de reenvío cuando coexisten destinos menos y más específicos y remite al descarte de paquetes que coinciden con el agregado pero con ninguno de sus componentes. Estas reglas muestran que quitar un tipo de segmento no convierte la migración en una operación mecánica.

La claridad del AS_PATH debe ir acompañada de políticas de anuncio y reenvío que mantengan la continuidad.

Por tanto, la evolución entre 2011 y 2025 no puede resumirse como un simple cambio de palabra normativa. Es una transición desde una recomendación centrada en no crear estado nuevo hasta un contrato bilateral: no anunciar el estado prohibido y no incorporarlo normalmente al recibirlo. Entre ambos extremos quedan las excepciones de transición, la reconstrucción de agregados, la autorización de origen y la comprobación de alcanzabilidad. El estándar reduce la ambigüedad, pero el operador sigue siendo responsable de planificar el cambio y observar sus efectos.

BGPsec empieza por negociar, no por asumir

La segunda línea documental está en el RFC 8205. BGPsec se define allí como un mecanismo para aportar seguridad al camino comunicado por anuncios BGP. Un receptor que valida un UPDATE BGPsec obtiene garantía criptográfica de que cada AS enumerado en la ruta autorizó la propagación del anuncio hacia el siguiente AS. El mecanismo usa un atributo opcional y no transitivo, BGPsec_PATH, que incorpora una representación segura del trayecto y firmas digitales. En un UPDATE BGPsec, ese atributo sustituye a AS_PATH; ambos no deben aparecer simultáneamente.

La especificación no permite inferir capacidad por la mera existencia de un vecino BGP. Cada hablante anuncia explícitamente si puede enviar o recibir UPDATE BGPsec para una versión y una familia de direcciones. El bit de dirección distingue envío y recepción, y se necesitan anuncios separados si se quieren ambas funciones. IPv4 e IPv6 también se negocian por familia. Además, un hablante no debe anunciar BGPsec para una familia si no ha anunciado la extensión multiprotocolo correspondiente. Esto convierte la compatibilidad en estado intercambiado durante OPEN, no en una suposición administrativa.

La condición es bilateral. Un par puede enviar BGPsec_PATH para una familia y versión solo cuando ese par anunció capacidad de envío y el receptor anunció capacidad de recepción para la misma combinación. Si BGPsec no se negocia correctamente, no se deben enviar UPDATE que contengan BGPsec_PATH. La sesión aún puede intercambiar UPDATE BGP tradicionales sin firma. Esta separación protege la continuidad básica, pero también marca una frontera: que la sesión siga activa no significa que opere con garantías BGPsec.

El soporte de números de AS de cuatro octetos es otro requisito explícito. El RFC 8205 sostiene que BGPsec no puede ofrecer garantías significativas sin esa capacidad. Por ello, cualquier hablante que anuncie BGPsec también debe anunciar soporte de ASN de cuatro octetos. Si falta este último, la negociación BGPsec no se considera completada y el atributo seguro no puede enviarse. La regla evita que una incompatibilidad de representación del identificador quede oculta bajo una señal genérica de seguridad.

El diseño de BGPsec_PATH conserva una secuencia de segmentos seguros y bloques de firma. Cada paso añade información vinculada al AS objetivo al que se propaga el anuncio. Al validar, el receptor comprueba primero la forma del atributo y varias relaciones de protocolo: que el AS más reciente corresponda al par externo, que exista un segmento de firma por cada segmento de camino, que AS_PATH no aparezca junto a BGPsec_PATH, que las marcas de confederación sean coherentes, que pCount tenga el uso esperado y que el AS local no aparezca como bucle. Los fallos sintácticos o de protocolo se tratan como retirada.

Solo después llegan las verificaciones criptográficas. Esa secuencia es operativamente relevante porque no todo error requiere gastar el coste de una firma. Para cada bloque compatible, el validador localiza en los datos RPKI una clave pública y un identificador de clave asociados al número de AS del segmento. Después recompone los datos protegidos, incluidos el AS objetivo, los segmentos previos, la familia, el identificador posterior de familia y el prefijo, y verifica la firma. Si al menos un bloque completo resulta válido, el UPDATE puede clasificarse como válido; si los bloques compatibles fallan, el resultado es no válido.

Cuando no existe un bloque para un algoritmo compatible y la ruta debe considerarse en la selección, el RFC define la reconstrucción de AS_PATH y el tratamiento como UPDATE sin firma.

Esta arquitectura no entrega una orden universal de selección. El RFC 8205 dice que el estado de validación puede alimentar la selección de ruta, pero la forma de usarlo pertenece a la política local y puede variar por sesión. Un par conforme incluso puede propagar una ruta que no supera su propia validación si su política así lo decide; por eso el receptor externo debe validar por sí mismo. El protocolo hace comprobable una propiedad del mensaje, pero no sustituye el criterio operativo ni convierte el estado criptográfico en una preferencia global obligatoria.

RPKI como registro de recursos y claves operativas

BGPsec depende de RPKI para relacionar identificadores y claves con recursos de numeración. El RFC 8205 parte de certificados que acreditan asignaciones de números de AS y direcciones IP. Para originar hacia pares externos UPDATE con BGPsec_PATH, un hablante necesita una clave privada asociada a un certificado de router RPKI correspondiente a su número de AS. En cambio, puede validar mensajes recibidos sin poseer ese certificado de firma propio, siempre que disponga de los datos válidos necesarios para comprobar las firmas ajenas.

La validación usa, como mínimo, triples formados por número de AS, clave pública e identificador de clave del sujeto obtenidos de certificados de router válidos. Esos datos pueden derivarse localmente de los certificados o llegar desde una caché de confianza que haya realizado la validación RPKI. La distinción muestra que el mecanismo no depende únicamente de un documento estático. Requiere que el estado de recursos y claves esté disponible donde el router toma decisiones y que la correspondencia entre AS, clave e identificador sea exacta.

La garantía resultante también tiene un borde preciso. En combinación con la validación de origen, un UPDATE BGPsec válido acredita que el AS de origen está autorizado en RPKI para anunciar el prefijo y que cada AS del Secure_Path eligió propagar el anuncio al siguiente AS. No acredita que los paquetes de datos recorran ese mismo camino. BGPsec protege la propagación del mensaje del plano de control; no observa el plano de reenvío. Tampoco detecta por sí solo una coordinación que eluda BGP mediante un canal externo. Presentar BGPsec como prueba del trayecto físico de los paquetes ampliaría indebidamente lo que el RFC define.

La disponibilidad de datos RPKI forma parte del límite operativo. El RFC 8205 describe el flujo desde repositorios globales hacia cachés locales y, desde ellas, hacia routers. Cita mecanismos de actualización incremental por número de serie, instantáneas y deltas para sincronizar cambios. El objetivo es que el router reciba estado actual sin transferir todo el conjunto en cada ciclo. Si la caché carece de información vigente, la operación criptográfica puede seguir estando bien especificada, pero faltará el registro contra el que se debe comprobar una clave.

Seguridad de protocolo y continuidad de datos son, por tanto, dependencias distintas y acumulativas.

La especificación también reconoce los límites de los números de AS privados. Esos números no pueden recibir certificados de router en la RPKI global ni publicar autorizaciones globales de origen en las mismas condiciones. El RFC describe alternativas locales para la relación entre un cliente con AS privado y su proveedor, además de reglas para retirar la identidad privada antes de propagar una ruta hacia el exterior. El detalle refuerza el principio general: una afirmación criptográfica solo es interpretable dentro del ámbito en que los recursos, certificados y políticas están registrados de manera coherente.

Continuidad, fallos visibles y despliegue parcial

El RFC 8205 dedica una sección a operación y gestión porque una capacidad segura que falla de forma silenciosa puede degradarse a una sesión ordinaria sin que el operador lo advierta. La negociación BGPsec exige capacidad BGPsec, extensión multiprotocolo para la misma familia y ASN de cuatro octetos. Si falta una, todavía pueden circular UPDATE tradicionales. La implementación debe registrar el fallo de negociación y debe poder impedir el establecimiento de la sesión cuando la configuración exige exclusivamente BGPsec.

Así, continuidad no significa aceptar cualquier degradación; significa hacer visible el estado y permitir que la política decida si continuar.

El despliegue parcial impone otro límite. El RFC imagina inicialmente grupos contiguos de AS capaces de BGPsec. Las garantías criptográficas cubren los anuncios originados y propagados dentro de cada grupo. Cuando la ruta alcanza un AS que no admite BGPsec, el UPDATE seguro se convierte en uno tradicional sin firma antes de continuar. La garantía sobre la secuencia se conserva hasta el AS anterior al salto no compatible, pero no más allá. No existe una propiedad global por el mero hecho de que un tramo haya sido validado.

Ese comportamiento impide dos simplificaciones opuestas. No sería correcto decir que BGPsec carece de valor hasta un despliegue universal, porque un segmento contiguo sí puede validar la propagación dentro de su ámbito. Tampoco sería correcto extender la garantía del segmento seguro al resto del camino. La unidad de análisis es el tramo donde capacidades, firmas y datos RPKI se mantienen. La frontera se mueve con la topología de adopción y con cada sesión negociada.

La conservación de información durante transiciones algorítmicas sigue la misma lógica. El RFC explica que un UPDATE puede contener bloques de firma para más de un algoritmo y que un bloque puede resultar válido mientras otro no. Al propagar, el hablante no elimina necesariamente el bloque no válido, porque un receptor posterior puede admitir un conjunto de algoritmos distinto o disponer de un estado RPKI diferente. Retener la evidencia evita que una ruta no válida para un algoritmo se convierta, por pérdida de información, en una ruta meramente sin firma.

La firma que añade cada AS acredita la recepción y la decisión de propagar al siguiente, no una declaración de que todas las firmas anteriores sean válidas.

Incluso la optimización del proceso se formula con límites observables. Antes de verificaciones criptográficas costosas se ejecutan comprobaciones sintácticas más baratas, y un bloque puede dejar de verificarse tras la primera firma inválida. Si un bloque ya es válido, no es necesario validar otro para clasificar el UPDATE como válido. Estas decisiones reducen trabajo sin cambiar el resultado visible exigido por el algoritmo. La eficiencia aceptable es la que conserva el significado del estado, no la que omite una comprobación necesaria para sostenerlo.

El orden de esas comprobaciones ayuda a interpretar un fallo sin atribuirle más alcance. Un atributo mal formado se detiene antes de la fase criptográfica; una clave ausente describe una carencia de datos; una firma inválida expresa otro resultado. Separar esas categorías relaciona cada estado con su dependencia, sin convertir cualquier rechazo en prueba del mismo problema operativo.

Lo que los documentos permiten concluir y lo que dejan abierto

Leídos juntos, los RFC no ofrecen una historia de sustitución lineal en la que una tecnología elimina toda incertidumbre. Ofrecen límites más estrechos. AS_SET y AS_CONFED_SET introducen un estado no ordenado que dificulta identificar origen y camino; el estándar posterior los retira del comportamiento normal. BGPsec crea una representación ordenada y firmada, pero solo tras negociar capacidades y solo dentro del alcance cubierto por certificados, claves, cachés y AS compatibles. La política local conserva la decisión final de selección.

Tampoco hay en estos documentos una medición del estado actual de despliegue. La observación histórica del RFC 6472 pertenece al contexto de 2011; no permite afirmar cuántos AS_SET quedan hoy. La descripción de despliegue parcial del RFC 8205 es una consideración de diseño, no un censo de adopción. El RFC 9774 fija requisitos y transición, pero su publicación no prueba por sí sola que todo software haya retirado el código ni que todas las redes hayan cambiado su configuración. Cumplimiento normativo, disponibilidad de una función y activación operativa son hechos diferentes.

La contribución de Sriram que sí queda visible es la participación colaborativa en esa delimitación. Los textos pasan de retirar una ambigüedad poco usada a especificar cómo una ruta segura debe negociar, representar y validar sus dependencias. La constante es la primacía del comportamiento comprobable: qué se anuncia, qué se recibe, qué se trata como retirada, qué clave corresponde a qué AS, qué tramo conserva una garantía y dónde termina. Esa precisión no sustituye la operación; le da un conjunto más claro de estados que observar.

Fuentes