Durante LACNIC 18 decidimos realizar algunos experimentos con la red, relacionados con las tecnologías que estamos de alguna manera impulsando. En este primer artículo describiremos la implementación de validación de origen utilizando RPKI y recursos certificados.

Introduccion

Las conferencias de LACNIC, así como otros eventos relacionados con tecnología, tienen una característica común: los asistentes esperan contar con conectividad a Internet de buena calidad y en particular de buena velocidad. Esto presenta interesantes desafios que van cambiando con el tiempo haciéndose en general mas exigentes.

El perfil de los usuarios es mas que interesante: los eventos de LACNIC reúnen a usuarios sofisticados de tecnologia, expertos en sus países y diferentes aspectos de las tecnologias de Internet. Este publico es exigente, tiene necesidades de conectividad específicas.

Desde LACNIC impulsamos el uso de nuevas tecnologías y siempre tratamos de ser los primeros en aplicarlas. Los eventos que organizamos dos veces al año nos brindan una oportunidad inmejorable, la de probar nuevas tecnologías en una red de una cierta escala (algunos cientos de usuarios) y con un público interesado capaz de darnos feedback de muy buena calidad.

En este articulo describiremos uno de los experimentos que realizamos en la red del LACNIC 18 en Montevideo el que consistió en implementar validación de origen en los enrutadores del evento.

Validacion de origen

Por “validación de origen” entendemos la funcionalidad por la cual un enrutador puede comparar el AS de origen (origin-as) de un prefijo que recibe en un mensaje BGP contra una tabla de “origenes validos”. El objetivo de esta técnica es el de prevenir eventos de los conocidos como “secuestro de rutas” (prefix hijacking) [2] [3] en los cuales una organización anuncia sin autorización prefijos IP pertenecientes a otra.

La consecuencia de un evento de estas características es en general el de una denegación de servicio sobre la entidad víctima, aunque son posibles ataques mas sofisticados en los cuales el trafico desviado es analizado y luego re-inyectado en la red.

La tabla de origenes válidos mencionada anteriormente se alimenta de la información contenida en los repositorios RPKI. Los legitimos usuarios de prefijos IP pueden crear objetos firmados digitalmente que describen los origenes validos para sus prefijos.

El enrutador puede clasificar los anuncios en tres categorias: validos, invalidos y unknown. Es luego responsabilidad del operador decidir que política aplicar sobre cada uno de ellos siendo lo mas logico el descartar los anuncios invalidos.

Los operadores de red pueden utilizar software de validación y caché como [4] para alimentar a los enrutadores con listas de prefijos y orígenes válidos.

La red de LACNIC 18

La topologia de la red de la conferencia es la que se muestra en el diagrama:

Los detalles relevantes son:

  • Topologia de estrella con dos enrutadores en el centro de la misma
  • Dos enrutadores Cisco 7201, hablando BGP (AS 28000) con un unico upstream (AS 6057)
  • Dos servidores Hewlett-Packard ProLiant corriendo Ubuntu 12.04 como sistema operativo

Como limitacion conocida del experimento tuvimos que no pudimos contar con la tabla completa de IPv4 sino con un sub-conjunto de la misma (alrededor de 24k rutas). Si se conto con la tabla completa de IPv6 (unas 11k rutas).

Implementación de validación de origen

Para implementar validación de origen en los enrutadores fue necesario cumplir con los siguientes objetivos:

1- Obtener el software adecuado para los enrutadores
2- Instalar las herramientas de validación [4] en los servidores
3- Realizar las configuraciones adecuadas en los enrutadores

Como preparación previa se crearon los ROAs para los bloques IPv4 e IPv6 que serian luego anunciados por el sistema autónomo de la red de la conferencia. Es interesante notar que en este caso el ROA IPv4 fue creado por ANTEL (el upstream) y el ROA IPv6 fue creado por LACNIC ya que el espacio IPv4 utilizado pertenece a ANTEL y el IPv6 a LACNIC.
Esto muestra como RPKI no impone limitaciones artificiales a la política de enrutamiento de una organizacion: una organización puede decidir anunciar partes de su espacio desde cualquier sistema autónomo por mas que no sea ‘dueña’ del mismo.

Sobre el primer punto es interesante de notar que los ingenieros de ANTEL (sponsor del evento y proveedor del equipamiento y la conectividad) pudieron obtener imágenes de IOS de producción con las caracteristicas necesarias para implementar validación de origen. No les fue necesario solicitar imágenes de testing o de desarrollo, ni realizar procedimientos fuera de lo común para obtenerlas.

En el caso de las herramientas de validación la instalación fue muy sencilla. La herramienta esta desarrollada en Java pero no requiere desplegar un servidor de aplicaciones ni tiene otras dependencias fuera de la propia JVM.

El experimento comenzó el día antes del inicio del evento. Inicialmente se decidió aceptar los anuncios inválidos y a dos días de comenzado el mismo se comenzaron a descartar los mismos. De esta manera la idea era poder separar posibles quejas de usuarios con respecto a problemas generados por la implementacion de validacion de origen a nivel del sistema operativo del enrutador de otras quejas relacionadas con el hecho de no poder alcanzar ciertos destinos.

Resultados del experimento

Durante el experimiento se midió la cantidad de prefijos válidos e inválidos detectados por los enrutadores así como también el consumo de CPU en los mismos.

IPv4 prefix count valid / invalid

IPv6 prefix count valid / invalid

No se detecto un impacto de CPU notable ni fuera de lo común, el mismo no superó el 6% durante toda la duración del evento.

Tampoco se tuvieron problemas de restarts en los enrutadores ni caidas en las sesiones entre los validadores y los enrutadores. Todos los componentes del sistema operaron de manera estable durante todo el tiempo que duro el experimento.

Referencias


[1] Certificacion de recursos: http://www.labs.lacnic.net/site/rpki
[2] Prefix hijacking: http://en.wikipedia.org/wiki/IP_hijacking 
[3] Pakistan Telecom vs Youtube: http://www.ripe.net/internet-coordination/news/industry-developments/youtube-hijacking-a-ripe-ncc-ris-case-study
[4] http://www.ripe.net/lir-services/resource-management/certification/tools-and-resources

“Configuracion enrutador 7201 (R1)”