Resumen

  • El ASN 0 es una no-identidad reservada y no puede usarse en el AS del peer ni en AS_PATH, AS4_PATH, AGGREGATOR o AS4_AGGREGATOR; sin embargo, el valor ORIGIN 0 es una codificación BGP válida para IGP.
  • La ubicación determina la unidad de rechazo: se aborta la conexión si el peer reclama AS 0, se aplica treat-as-withdraw a la ruta cuyo AS_PATH lo contiene y se descarta el atributo de agregación o transición malformado sin convertir automáticamente todo el UPDATE en una retirada.

Tres consolas reciben datos de la misma ventana operativa. La consola de sesiones muestra Bad Peer AS y una vecindad que nunca llega a Established. La consola de rutas mantiene el vecino en verde, pero elimina varios prefijos de Adj-RIB-In. La consola de agregación conserva otro prefijo y señala que perdió AGGREGATOR. El resumen ejecutivo agrupa los casos bajo un solo título: “AS0 detectado”.

El resumen ha eliminado la decisión más importante. En el primer caso, cero estaba en OPEN. En el segundo, dentro de AS_PATH. En el tercero, en AGGREGATOR. RFC 7607 prohíbe el mismo ASN en los tres lugares, pero remite a procedimientos diferentes porque no se ha corrompido la misma cosa.

La seguridad operativa no consiste en elegir siempre la sanción más fuerte. Consiste en negarse a aceptar una identidad imposible sin derribar estado válido que no depende de ella. Para hacerlo, el sistema de evidencia debe conservar mensaje, atributo, capacidad y dirección; “cero” no basta.

AS 0 no es un comodín

El registro de números de sistema autónomo de IANA mantiene el número 0 como Reserved y cita RFC 7607. El registro de ASN de propósito especial lo coloca junto a valores con funciones distintas: AS_TRANS, rangos de documentación, rangos privados y los últimos ASN reservados.

Esa vecindad no concede usos equivalentes. AS_TRANS 23456 existe para representar temporalmente información durante la transición a cuatro octetos. Un ASN privado puede tener sentido dentro de un dominio controlado y sujeto a filtrado. AS 0 no representa un operador, una organización anónima ni un vecino “por decidir”.

El error aparece con frecuencia antes del protocolo. Un formulario trata un campo vacío como entero; un generador usa cero como valor inicial; una migración aún no conoce el nuevo local-AS. En todos los casos, el sistema convierte ausencia de datos en una afirmación de identidad. Rechazar esa conversión en el commit es una defensa valiosa. Juniper documenta, para el alcance de sus ASN de cuatro bytes, que los números restringidos incluido 0 fallan al confirmar la configuración.

Pero la protección local no responde por los demás. Un router debe procesar mensajes recibidos de versiones, plataformas y cadenas de automatización distintas. La regla normativa vive en el parser y en la acción de error, no solo en el formulario que genera la configuración propia.

Cuando cero llega en OPEN

RFC 4271 define My Autonomous System en el mensaje OPEN. RFC 7607 determina que cero es inaceptable en ese campo. El receptor debe abortar la conexión y enviar una NOTIFICATION con código OPEN Message Error y subcódigo Bad Peer AS. Asimismo, un router no debe iniciar una conexión afirmando ser AS 0.

La consecuencia alcanza a la relación de control que intentaba nacer. No hay una tabla completa de aquel peer que pueda seguir funcionando dentro de esa sesión, porque BGP no llegó a establecerse. El registro debe conservar el OPEN, la respuesta, el extremo que inició TCP, la repetición de intentos y la configuración responsable.

Una opción que desactive la comprobación del peer-AS no crea una excepción legítima. No existe un titular de AS 0 que pueda autorizarla. Si un cambio necesita convivir con dos ASN reales, las funciones local-as y sus equivalentes deben planificarse con esos valores reales y con su efecto sobre AS_PATH.

Cuando cero llega en AS_PATH

RFC 7607 declara malformado un UPDATE cuyo AS_PATH contiene AS 0 y ordena usar RFC 7606. Para un AS_PATH malformado, la acción es treat-as-withdraw: todas las rutas transportadas en el UPDATE se tratan como retiradas y se eliminan de Adj-RIB-In.

La sesión puede seguir activa. Esto preserva anuncios válidos anteriores y posteriores del mismo peer. Una política de restablecer toda la sesión trasladaría el coste de una ruta defectuosa a todos los prefijos intercambiados y podría multiplicar el impacto en una red grande.

Mantener la sesión tampoco significa aceptar el defecto. La ruta concreta desaparece hasta que el emisor ofrece un camino defendible. No se debe borrar el segmento cero e inventar continuidad entre los ASN restantes. AS_PATH expresa el recorrido anunciado y participa en detección de bucles y selección; una versión reparada por el receptor ya no sería lo que el vecino dijo.

Un filtro adicional puede detectar el caso. La documentación BGP de FRRouting muestra una lista de ASN bogon que hace match con _0_. Sirve como defensa de borde y como contador. Su alcance es AS_PATH: no ve el AS de OPEN ni demuestra qué hizo el parser con atributos de agregación o transición.

Cuando se pierde solo un atributo

AGGREGATOR contiene el ASN y la dirección del speaker que formó un agregado. RFC 7607 prohíbe que ese ASN sea cero, y RFC 7606 asigna a un AGGREGATOR malformado attribute discard. Se elimina el atributo y continúa el procesamiento del UPDATE.

La ruta puede superar los demás controles y llegar a selección. Por eso una comparación superficial entre dos routers produce resultados distintos: uno pudo retirar un AS_PATH con cero; otro pudo conservar un anuncio cuyo único defecto estaba en AGGREGATOR. Ambos pueden cumplir el estándar.

El hecho de conservar el prefijo no convierte el atributo descartado en irrelevante. Se ha perdido información sobre la agregación y existe una fuente que emite valores prohibidos. Debe quedar un log local con peer, campo, hora y acción, y debe corregirse el escritor.

RFC 6793 define AS4_PATH y AS4_AGGREGATOR para atravesar dominios con soporte desigual de ASN de cuatro octetos. RFC 7607 declara malformado el cero en ambos y remite a sus procedimientos. En el contexto previsto, se descarta el atributo, se registra el error y continúa el UPDATE. Además, dos speakers capaces de cuatro octetos no deben intercambiar esos atributos de transición; si aparecen, el contexto de capacidades forma parte del diagnóstico.

La captura de los OPEN es por ello inseparable de la captura del UPDATE. Sin saber qué capacidades anunciaron ambos extremos, el operador puede ver los bytes y aun así interpretar mal su función.

ORIGIN 0 es la prueba canaria

El mismo RFC 4271 asigna el valor 0 del atributo ORIGIN a IGP. Esa codificación es válida. No afirma que el sistema autónomo originador sea 0.

Una herramienta puede superar todas sus pruebas de búsqueda textual y aun fracasar en esta distinción. Si la regla busca el carácter 0 o un campo genérico origin, puede confundir el código ORIGIN con el ASN de origen calculado desde AS_PATH. También puede mezclarlo con el prefijo por defecto o con una métrica.

El canario de calidad es sencillo: introducir un UPDATE válido con ORIGIN 0 y un conjunto separado de mensajes con ASN 0 en cada ubicación prohibida. La plataforma debe dejar en paz el primero, identificar el campo de los otros cinco y mostrar la acción correspondiente. Una solución que bloquea todo valor cero es tan poco conforme como una que no bloquea ninguno.

El registro base debe incluir PDU o representación sin pérdida, tipo de mensaje, código de atributo, peer, dirección, AFI/SAFI, capacidades y versión. Los paneles pueden añadir nombres legibles; no deben sustituir el dato que permite redecodificar.

La otra vida de AS 0 en RPKI

Un ROA pertenece a otra capa de autoridad. RFC 6482 define el objeto firmado con asID y prefijos. RFC 6483 explica que un titular puede publicar un ROA con asID 0 para expresar que el prefijo y sus más específicos no deberían usarse en routing.

No existe una ruta legítima que corresponda a ese objeto presentando AS 0 como origen. RFC 6907 señala que ningún route válido puede tener origin ASN 0 y, por tanto, ninguno puede hacer match con un ROA AS 0. Una ruta de otro ASN queda Invalid si encuentra el ROA candidato y ninguna autorización coincidente la valida.

La palabra “ninguna” es decisiva. RFC 6483 permite que coexistan un ROA AS 0 y ROAs para ASN routables. Si uno de estos autoriza el prefijo, la longitud y el origen real, la ruta es Valid. El objeto AS 0 crea una condición por defecto de desautorización; no vence una autorización positiva coincidente.

El tiempo también cambia. Un UPDATE se procesa dentro del flujo BGP. Un ROA se publica, se valida mediante certificados, se recoge y llega a caches de relying parties. Una corrección de BGP y una corrección RPKI pueden converger en momentos distintos. El caso debe registrar ambas cronologías y no atribuir a un filtro de rutas lo que ocurrió en el repositorio.

La cadena de evidencia

RFC 7854 define BMP para observar mensajes, estado de peers y Adj-RIB-In. La vista pre-policy conserva lo que llegó. La vista post-policy conserva el resultado de aplicar manejo y política. Si AS 0 aparece antes y no después, la red local puede demostrar tanto el intento como su contención.

RFC 9069 incorpora Loc-RIB al monitoreo. Allí aparecen las rutas elegidas por el proceso de decisión. El dato no sustituye FIB ni pruebas de paquetes, pero separa aceptación de selección.

RFC 8671 añade Adj-RIB-Out pre- y post-policy. La obligación de no propagar se puede auditar en las salidas materiales. RFC 7454 aporta la disciplina general de filtrado de entradas, salidas y caminos; RFC 7607 aporta la regla específica de AS 0.

El expediente debe poder responder, en orden: qué campo recibió cero; qué acción ejecutó el router; qué sobrevivió a Adj-RIB-In; qué llegó a Loc-RIB y FIB; qué se preparó para cada peer; dónde se escribió el valor; y qué mensaje limpio reemplazó al anterior. La ausencia en una sola vista no prueba la cadena completa.

Fuentes