El framework RPKI

10 de mayo de 2011 Por

Hace algo mas de un año, uno de nuestros colaboradores escribió el post titulado “Disponibilidad en los servicios de conectividad a internet” donde se hacía referencia al secuestro de los prefijos IP de youtube desde Pakistan Telecom (junto otros ejemplos).

Copiando de dicho post, el ejemplo fue el siguiente:

El AS17557 (Pakistán Telecom), siguiendo una orden del gobierno pakistaní de bloquear el acceso a YouTube, empezó a anunciar uno de los prefijos del direccionamiento de YouTube seccionando —utilizando una red más específica— el prefijo habitual utilizado por la empresa de vídeos online. Cuando la ruta se propagó a través de la red de ASs, el tráfico mundial destinado a dicha subred utilizó el camino de los ASs anunciados para la dirección más específica, siendo enviado al AS17557 en lugar de al AS de Youtube.

Este problema se podría haber evitado si pudiéramos responder lo siguiente: He recibido un anuncio de ruta del bloque 208.65.153.0/24 con origen el AS 17557. ¿Es un anuncio autorizado?

Según la última información sobre el tema que he podido revisar, para resolver esta cuestión se han propuesto distintas soluciones, pero la que parece ser que está teniendo más posibilidades es el uso del framework RPKI. RPKI está siendo usado en producción desde hace varios meses por distintos RIR’s y se basa en el uso de certificados digitales X.509 (con posibilidad de usar extensiones) para firmar las ROAs (Routing Origin Authorization), puesto que el AS origen del anuncio de ruta viene incluido en el AS_PATH, proporcionando la siguiente funcionalidad:

  • Creación de certificados digitales que corresponden a los bloques de recursos asignado. El usuario asigna el bloque de direcciones IP 1234, el cual tiene asignado el certificado para el bloque de direcciones 1234.
  • Permite el uso de estos certificados para firmar la autorización de enrutamiento. El proveedor ABC puede enrutar el bloque de direcciones 1234.
  • Permite la publicación de forma segura de un repositorio de ROAs firmadas digitalmente.
  • Las redes que reciben la actualización pueden consultar el repositorio para determinar el origen de la actualización y comprobar si coincide con la autorización para el bloque de direcciones.

De esta forma, es posible prevenir el secuestro de rutas ocasionadas de forma malintencionadas o por error del operador, puesto que un router que hable BGP podría utilizar el framework RPKI —nos consta que algunos modelos de Cisco ya lo soportan— para validar una ruta y rechazarla en caso de no tener autorización correcta.

Puesto que ya sabemos que la seguridad es un proceso continuo, y los vectores de ataque cambian, éste sería un primer paso para securizar los servicios de conectividad a Internet, pero ni mucho menos el último, ya que lo más posible es que aparezcan nuevos ataques que intenten explotar este framework así como otras vulnerabilidades, como el spoofing del origen de ruta especificado en el AS_PATH. No obstante, es un primer comienzo.