Resumen

  • RFC 2154 añadió una firma persistente a cada LSA y distribuyó una clave certificada mediante una Public Key LSA, llevando la atribución más allá del vecino inmediato.
  • El certificado delimitaba identidad, función y rangos permitidos, pero no observaba si el enlace existía, la métrica era honesta o el destino respondía.
  • La operación necesita recibos distintos para ancla de confianza, generación de clave, vigencia de la LSA, permiso, corroboración, SPF, FIB y entrega medida.

El sello llegó; la red no estaba allí

Una LSA sale sellada, atraviesa varios routers y llega sin que cambie un solo byte cubierto. La verificación es impecable. Al inspeccionar el extremo anunciado, el operador encuentra una bahía vacía. No falló la firma: identificó con precisión al autor de un dato falso.

Esa separación sostiene RFC 2154, documento Experimental de junio de 1997. La autenticación criptográfica normal de OSPFv2 protegía paquetes entre vecinos. La propuesta firmó cada LSA dentro del Link State Update para que la prueba del Advertising Router viajara con el dato a través del dominio.

El resultado era más fuerte que confiar en quien entregaba el paquete. Confirmaba origen e integridad de los bytes cubiertos durante el flooding. No confirmaba que el originador hubiera medido bien el mundo.

La confianza también tenía estado

Una clave pública no autentica por sí sola un Router ID. RFC 2154 creó la Router Public Key LSA o PKLSA, con un certificado firmado por una Trusted Entity. Incluía identidad, papel del router, rangos de red autorizados, hora de creación, algoritmo y clave. El receptor verificaba la certificación TE y la firma del propio router; cualquiera de los dos fallos exigía descartar.

La clave TE se instalaba fuera de OSPF. La PKLSA debía ser vigente. Una LSA que llegaba antes que su clave solo podía esperar MAX_TRANSIT_DELAY. Cuando una clave nueva sustituía a la anterior, el router reoriginaba sus LSA y el dominio retiraba la información firmada con la clave vieja.

El rango certificado podía impedir que un router interno reclamara cualquier dirección. No convertía el certificado en sensor de cable, auditor de métrica ni autorización de un cambio concreto.

MaxAge mostró quién podía retirar una afirmación

LS Age cambia mientras la LSA circula y normalmente quedaba fuera de la firma. La excepción era una LSA creada por su originador con MaxAge: entonces la edad se cubría para que solo aquel router pudiera emitir el retiro firmado. Una LSA huérfana seguía envejeciendo localmente hasta ser eliminada en cada LSDB, más despacio que el flush sincronizado de OSPF estándar.

También había áreas firmadas y no firmadas, pero no ambos tipos dentro de una misma área. Un ABR que cruzaba la frontera generaba un resumen bajo su propia autoridad. La procedencia anterior no se transfería automáticamente a una nueva representación.

Un mentiroso autorizado conserva una firma válida

La sección 9 admite que un router interno puede publicar una métrica incorrecta, declarar activo un enlace caído o inventar una ruta stub o de host. Un enlace de tránsito falso puede necesitar el anuncio coincidente del otro extremo antes de entrar en SPF; el stub carece de esa segunda voz.

Los ABR aún pueden producir Summary LSA falsas sobre otras áreas. El texto contempla verificaciones cruzadas, pero no las incorpora por su coste. Los ASBR pueden originar información externa incorrecta y el documento reconoce que no existe dentro del AS una autoridad equivalente que apruebe qué redes externas pueden anunciar.

La firma identifica al responsable cuando aparece la contradicción. No garantiza que alguien la encuentre. Tampoco protege el forwarding de paquetes: una LSA verificada puede alimentar un SPF correcto y terminar en un next hop que descarta el tráfico.

Nueve recibos, no un estado verde

El registro completo une ancla TE e instalador; certificado, función y rango; generación de clave; identidad, secuencia y hash cubierto de la LSA; sustitución y edad; aprobación del cambio; corroboración del otro extremo o telemetría; generación LSDB y decisión SPF; RIB/FIB; y, al final, prueba de datos y resultado de aplicación.

El RFC Editor, Datatracker y su historial establecen el rastro Experimental; las erratas solo corrigen una errata tipográfica. RFC 2328 aporta el contexto OSPFv2. RFC 6039 informó más tarde de ausencia de experiencia de despliegue, y RFC 6863 separó la protección del dato del replay por paquete. RFC 7474 trató la frescura después de reinicio. Un borrador individual expirado criticó ataques internos sin adquirir autoridad IETF.

Running-Code Primacy, Minimum Initial Specification y Reality Layers son lentes editoriales declaradas para no confundir documento, validación y ejecución.

Fuentes