Resumen

  • El RFC 7115 de Randy Bush exige revisar las subasignaciones anunciadas por otros AS antes de emitir un ROA que cubra todo el bloque superior. Un anuncio de cliente sin ROA correcto puede pasar a Invalid.
  • La decisión recorre cachés de validación y llega a los routers, que aplican la política de cada red. Bush recomienda redundancia de cachés, uno de ellos local, y sincronización entre los locales.

El trámite del propietario, la alarma del inquilino

El titular de un gran bloque IP va a publicar un ROA. Dentro de ese bloque hay una porción cedida a un cliente, anunciada desde el AS del cliente. El titular pulsa publicar; el cliente sigue anunciando la misma ruta. Cuando el nuevo dato llega a los routers que validan orígenes, esa ruta más pequeña puede adquirir una palabra roja: Invalid. La operación sucedió arriba, pero el problema llama a la puerta de abajo.

Bush escribió la secuencia en el RFC 7115, guía de mejores prácticas de enero de 2014 para la validación de origen con RPKI. Antes de emitir un ROA para un superbloque, el operador debe comprobar que cada subasignación anunciada por otro AS —por ejemplo, el de un cliente— tenga el ROA correcto. De lo contrario, los anuncios sin esa autorización serán vistos como Invalid. El texto ofrece una salida transitoria: usar datos BGP en vivo como base para crear ROA mientras los destinatarios registran los suyos. Primero el censo de ocupantes; después el sello en la puerta principal.

El RFC 6811 describe la aritmética de esa palabra roja. Compara el prefijo y AS de origen de un anuncio con los datos ROA validados y devuelve Valid, NotFound o Invalid. Al aparecer una autorización que cubre el bloque grande, la ruta más específica puede entrar en conflicto por origen o longitud permitida. La respuesta de la red depende de su política local. Si esa política descarta Invalid, un error en la lista de subasignaciones ya tiene consecuencias de encaminamiento.

Entre el ROA y el router trabajan los cachés. Bush coescribió con Rob Austein el RFC 6810, que define cómo se entregan al router los datos de origen validados. Su RFC 7115 aconseja conectar un router a más de un caché, al menos uno local; si los cachés locales alimentan decisiones de ruta, deberían sincronizarse cada cuatro a seis horas como mínimo. Quien recibe datos de un caché de un proveedor ascendente debería validarlos por su cuenta. El documento piensa en un sistema, no en un botón aislado.

La biografía de Bush en RIPE NCC recoge décadas de trabajo en seguridad del encaminamiento, RPKI y validación de origen. Es fácil ver esa experiencia en la insistencia del RFC: una autorización técnicamente correcta para el bloque grande puede llegar en un momento operacionalmente torpe. El retrato editorial toma como referencia su fotografía identificada por RIPE NCC; los armarios de routers del fondo son imaginados.

La prueba de madurez del operador está en una tabla modesta: clientes, prefijos, AS que anuncian y ROA vigentes. Si falta una fila, un router lejano puede cambiar su juicio sobre un anuncio que ayer aceptaba. Bush convirtió esa tabla en una condición previa al despliegue.