Mostrando entradas con la etiqueta apnic. Mostrar todas las entradas
Mostrando entradas con la etiqueta apnic. Mostrar todas las entradas

jueves, 1 de febrero de 2024

Un necesario RFC sobre BGP: AS Path Prepending

Introducción

Border Gateway Protocol (BGP) desempeña un papel fundamental en la construcción y mantenimiento de las tablas de enrutamiento en Internet, a tal punto que es considerado como el “pegamento” de Internet. En este contexto, una técnica de muchos años atrás y ampliamente popular conocida como “AS Path Prepending” se ha concebido como una estrategia clave para influir en la selección de rutas y la optimización del tráfico tanto entrante como saliente de un AS.

En el presente documento navegaremos a través del draft IETF “AS Path Prepending” [1], el cual recoge varias ideas y conceptos muy valiosos para la comunidad.


Sobre el Draft draft-ietf-grow-as-path-prepending

El Draft se encuentra en discusión dentro del Working Group GROW (Global Routing Operation) desde el año 2020, y actualmente se encuentra en su versión 10.

El draft cuenta con 7 autores: M. McBride, D. Madory, J. Tantsura, R. Raszuk, H. Li., J. Heitz y G. Mishra. En la lista de discusión este draft ha tenido mayoritariamente apoyo (incluido este humilde servidor). Puedes leerlo aquí.


¿Qué AS Path Prepending?

El AS Path Prepending es una técnica que implica la adición repetitiva del identificador de sistema autónomo (ASN) propio a la lista de ASs en el camino de una ruta BGP (AS_PATH). Su objetivo es influir en la selección de rutas, haciendo que ciertos caminos sean menos atractivos para el tráfico entrante/saliente. En otras palabras, es agregar nuestro sistema autónomo en el AS_PATH y así artificialmente “alejar un prefijo” en Internet.


En el gráfico anterior sin prepends, Router A prefiere ir a C a través de B; sin embargo debido a 3 prepends agregados en B, router A decide alcanzar C a través de D.


¿Para qué y por qué se hace AS PATH Prepending?

Existen muchas razones por las cuales se hace AS PATH prepending. La principal razón indiscutiblemente sería por ingeniería de tráfico la cual a su vez recae en el deseo de influenciar el tráfico entrante y saliente al AS. Es muy probable que el AS desee lograr alguno de los siguientes objetivos:

  • distribución de tráfico entre dos o más upstream providers
  • tener algún upstream provider de backup
  • Sea cual sea el caso, una vez más el objetivo es ingeniería de tráfico.


Hacer prepend o no hacer prepend, he ahí el dilema

Hacer prepend se parece un poco al NAT, es un mal muchas veces necesario.

Como explicaremos, su uso excesivo y a veces innecesario puede convertirse en una vulnerabilidad con implicaciones significativas para la estabilidad de las redes.


¿Qué tiene de malo hacer AS Path Prepending?

Todos sabemos que hacer AS Path Prepending es una técnica muy común para influenciar las decisiones de BGP, sin embargo, el excesivo/mal/ y a veces innecesario uso puede traer resultados negativos. Por ejemplo:

  • crear un tráfico subóptimo, es decir, quizás en los enlaces inmediatos logremos nuestro objetivo de una distribución de tráfico, sin embargo, mas alla de tu upstream inmediato el tráfico no se encuentre optimizado para alcanzar nuestro sistema autónomo y viceversa;
  • desagregación de prefijos, es muy normal que al momento de querer hacer una ingeniería de tráfico se proceda a desagregar prefijos afectando así el ecosistema de Internet;
  • en caso de algun route-leak (fuga de ruta), en condiciones normales nuestras publicaciones tenderían a tener un as-path más corto que el leak, pero si alargamos artificialmente el path haciendo prepend es posible que las rutas fugadas tengan un as-path más corto que las que estamos anunciando legítimamente de nuestro prefijo -legítimo- tendrá menos preferencia en Internet trayendo consigo posibilidades de secuestro de rutas, ataques, y un largo etcétera;
  • memoria: como es de esperarse, estos AS Path Prepends son aprendidos por los BGP Speakers consumiendo su memoria. A esto yo también le sumaría a cada prefijo un pequeño consumo de CPU adicional.


Si no recomiendan hacer AS Path Prepend, ¿qué puedo hacer?

Existen muchas técnicas para realizar ingeniería de tráfico en BGP.  menciono algunas que aparecen en el draft:

  • considera aprovechar las comunidades BGP. Además de las comunidades BGP ampliamente reconocidas, te recomiendo que dialogues con tus pares BGP para optimizar el tráfico. Existen numerosas comunidades BGP implementadas por proveedores, las cuales seguramente podrían beneficiar tu configuración
  • Puedes realizar anuncios más específicos hacia tus upstream principales
  • Manipular el AS Origin Code; recordemos que este atributo también se encuentra en el algoritmo de selección de rutas de BGP
  • Usar MED (Multi Exit Discriminator), un atributo no transitivo, excelente para manipular el tráfico entrante cuando tenemos varios enlaces hacia el mismo proveedor
  • Local Preference, otro atributo no transitivo, perfecto para influenciar el tráfico que sale de nuestro sistema autónomo


Todo muy bien, pero aún necesito hacer AS Path Prepend, ¿alguna sugerencia?

El draft menciona las mejores prácticas al momento de realizar prepends, aquí te resumo las mismas:

  • solo hacer AS Path Prepend cuando sea imprescindible;
  • debido a algunas técnicas de manipulación de tráfico puede ocurrir que al hacer AS Path Prepend no veamos cambios significativos en la distribución del tráfico, por ello es importante conversar con nuestros pares y saber si ellos respetan los prepends;
  • utilizar Local Preference en nuestra red;
  • no realizar prepends con números de ASs que no son nuestros;
  • no hacer prepend si eres single home (esta no está en el draft);
  • si realizamos preprends de algún prefijo quizás no es necesario colocar ese prepend hacia todos mis peers;
  • no hay necesidad de colocar más de 5 prepends. El motivo es que más del 90% de los destinos se encuentran a 5 o menos ASs de distancia.




(imagen tomada de: https://www.potaroo.net/ispcol/2019-10/prepending.pdf)


Consideraciones finales:

El uso de AS_PATH Prepending es una estrategia valiosa pero debe ser utilizada sólo cuando es necesario y de una manera precavida siguiendo las mejores prácticas. El uso excesivo de prepends puede ocasionar imprevistos a nuestro sistema autónomo desde la perspectiva de tráfico como de seguridad.

Te invitamos a leer el draft completo aquí, y sumarte a la discusión en la lista de LACNOG

Además, te animamos a dejarnos un comentario en este post, para contarnos si haces prepending de tu ASN, por qué y para qué lo usas.


Referencias:

[1] https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/ 

domingo, 19 de octubre de 2014

Existe alguna relacion respecto al despliegue de IPv6 entre entidades con ASN de 16 y 32 bits?

Hola, 
  El dia de hoy se me ocurrio esta pregunta: ¿Existe alguna relacion respecto al despliegue de IPv6 entre entidades con ASN de 16 y 32 bits?. Posteriormente me di cuenta que la data existia y me era sencillo ubicar la respuesta. Para ello estuve revisando alguna data de APNIC (*1) que tengo ya varias semanas consultando. Voila!!, que suerte..
  Ellos (APNIC) almacenan por ASN un valor porcentual que llaman ipv6capable, basicamente es un numero que indica para X ASN que porcentaje tiene capacidad de v6. Tienen otra variable llamada ipv6 preferred pero no vamos a hablar de ella ahorita.
  Lo cierto es que para mi muestra tome tres dias: 11, 12 y 15 de Octubre 2014

  Mis resultados fueron:
 
Dia 15 de Octubre (miercoles)
  1.34 en asn de 16
  1.12 en asn de 32
  Avg 1.26 todos los ASN
----
Dia 11 de Oct (sabado)
  1.34 en asn de 16 bits
  1.15 en asn de 32 bits
  Avg 1.27 todos los ASN
---
Dia 12 de Oct (domingo)
  1.35 en asn de 16 bits 2058
  1.12 en asn de 32 bits 1225
  Avg 1.27 todos los ASN (3313 ASNs)
----

  Fueron evaluados alrededor de 2050 ASN de 16 bits y 1200 ASN de 32 bits. La diferencia de ipv6capable entre ASN de 16 y 32 bits es aprox 0.2, ciertamente es un numero muy chico sin embargo cuando se refiere a trafico y usuarios en Internet estos numeros tradicionalmente represantan un volumen significativo.
  Mi humilde conclusion para este sencillo estudio es: Pareciera que hubiese una *muy* ligera preferencia al despliegue de IPv6 en ASN de 16 bits.

Saludos,

(*1) http://labs.apnic.net/ipv6-measurement/AS/

Una propuesta inesperada dentro de IETF – Ethernet sobre HTTPS

En el presente post quiero hablar mayormente sobre un documento con poco tiempo en IETF llamado “Ethernet sobre HTTPS”. Debo confesar que su...