Resumen

  • Job Snijders y Ties de Kock, del RIPE NCC, firmaron RFC 9697, publicada por el IETF en diciembre de 2024.
  • El validador debe cotejar números de serie y hashes ya vistos; si un delta antiguo cambia, conviene avisar y reconstruir desde la última copia completa.

El número 1774 tiene una coartada pésima

El ejemplo de RFC 9697 comienza con un aviso de actualización que llega al número 1774. El siguiente llega al 1775. Lo extraño aparece al mirar atrás: el hash asignado al viejo 1774 es otro, mientras el de 1773 sigue igual. El número de la carpeta permanece; el documento dentro ha sido sustituido. Es un ejemplo técnico del estándar, no una crónica de una intrusión. Job Snijders y Ties de Kock, de RIPE NCC, lo usan para señalar una comprobación que faltaba.

La infraestructura RPKI distribuye objetos firmados con los que los operadores evalúan el origen autorizado de una ruta. RRDP entrega los cambios del repositorio mediante archivos pequeños, llamados deltas. Un validador obtiene primero una copia completa y después descarga solo las modificaciones pendientes. El aviso de actualización enumera la sesión, los números de serie y los hashes de esos archivos. Es un sistema cómodo para servidores web y cachés; también depende de que un archivo viejo conserve su contenido.

Dos validadores que consulten en momentos distintos pueden quedarse con versiones incompatibles del mismo delta. Ambos mostrarán la misma sesión y el mismo número más reciente. Un panel que compare solo esos indicadores declarará empate donde hay desacuerdo. La propuesta de Snijders y de Kock consiste en guardar las parejas de serie y hash del último aviso recibido con éxito. Al llegar el siguiente, se comparan las series repetidas. Si una huella antigua cambia, el validador emite un aviso y obtiene la última copia completa del repositorio.

Snijders había visto otra clase de desajuste. En su relato de 2021 sobre rpki-client, explicó cómo los servidores situados tras un balanceador podían ir a distinto ritmo: uno anunciaba un delta que otro todavía no servía. Aquella carrera entre servidores y la mutación retrospectiva de RFC 9697 son problemas diferentes. Ambos enseñan que una firma criptográfica necesita un reparto de archivos que sepa llevar las cuentas.

La consecuencia llega hasta el enrutamiento. RFC 9697 advierte que una caché desincronizada puede conservar datos validados que la autoridad certificadora quiso retirar, u omitir otros. Una ruta destinada a parecer válida puede clasificarse como desconocida o inválida. La divergencia puede durar meses. Ayer merece una huella que no se pueda cambiar a escondidas.