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/ 

BGP: Ejemplo IPv6 Only entre FRR y OpenBGPD

FRR:

show run

frr# sh run 

Building configuration...

Current configuration:

!

frr version 8.1

frr defaults traditional

hostname frr

log syslog informational

service integrated-vtysh-config

!

interface l0

 ipv6 address 2001:db8::1/128

exit

!

router bgp 65001

 bgp router-id 1.1.1.1

 no bgp ebgp-requires-policy

 neighbor 2001:db8:12::2 remote-as 65002

 !

 address-family ipv6 unicast

  redistribute connected

  neighbor 2001:db8:12::2 activate

  neighbor 2001:db8:12::2 soft-reconfiguration inbound

 exit-address-family

exit

!

OpenBGPD

Archivo: /etc/bgpd.conf

# macros

ASN="65002"

fib-update yes

log updates

# global configuration

AS $ASN

router-id 2.2.2.2

network 2001:db8::2/128

network inet6 connected

neighbor 2001:db8:12::1 {

    descr "epa"

    remote-as 65001

    announce IPv6 unicast

}

deny from any

deny to any

allow from 2001:db8:12::1

allow to 2001:db8:12::1

#

(por favor notar el espacio en blanco entre la última línea y la antepenúltima línea)

Como crear una ruta IPv6 a null/blackhole en Linux

Caso:

   Como crear una ruta IPv6 a null/blackhole en Linux

Comando:

  ip -6 route add blackhole fd00:12:34::0/48

Espero sea útil

Server DNS recursivo detrás de NAT64. Explicando IPv6-only Capable Resolvers Utilising NAT64

Parece loco, pero no lo es: Server DNS recursivo detrás de NAT64. Explicando IPv6-only Capable Resolvers Utilising NAT64 

Como deshabilitar IPv4 temporalmente en una interfaz dentro de Linux

Caso:

  Deseamos deshabilitar IPv4 en una interfaz

Solución:

  sudo ip -4 addr flush dev enp0s1

Explicación:

  El comando anterior elimina todas las direcciones IPv4 para la interfaz enp0s1. Importante, recuerda que esta deshabilitación es solo temporal.

Como desinstalar brew en MAC

 Como desinstalar brew en MAC

  Opción 1: 

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh)"

 Opción 2: 

NONINTERACTIVE=1 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh)"

Tomado de: https://github.com/homebrew/install#uninstall-homebrew

NGINX Reverse Proxy y Granja de Servidores IPv6 Only

 Introducción

En el presente trabajo presentaremos una manera muy sencilla de ofrecer acceso Web Dual Stack a una granja de servidores IPv6 Only utilizando NGINX. Con el crecimiento continuo de la red y la adopción gradual del protocolo IPv6, es esencial garantizar la conectividad y accesibilidad para aquellos clientes que utilizan tanto IPv4 como IPv6.

Explicaremos cómo configurar NGINX para admitir acceso web Dual Stack; veremos cómo configurar NGINX como un proxy inverso que escucha tanto en direcciones IPv4 como IPv6, y cómo direccionar correctamente las solicitudes entrantes a los servidores backend que solo tienen direcciones IPv6.  Por cierto, lo que estudiaremos en el siguiente artículo es un importante paso para lograr el ansiado ahorro de direcciones IPv4, entre muchos otros beneficios.

¿Qué es un reverse proxy?

Cloudflare define en [1] un Servidor Proxy Inverso o Reverso como:

“Un proxy inverso es un servidor que se sitúa delante de los servidores web y reenvía las solicitudes del cliente (por ejemplo, el navegador web) a esos servidores web. Los proxies inversos suelen implementarse para ayudar a aumentar la seguridad, el rendimiento y la fiabilidad. Para entender mejor cómo funciona un proxy inverso y las ventajas que puede aportar, definamos primero qué es un servidor proxy.”

¿Qué es un servidor proxy?

Nuevamente Cloudflare define en [1] un Servidor Proxy como:

“Un proxy de reenvío, con frecuencia conocido como proxy, servidor proxy o proxy web, es un servidor que se sitúa delante de un grupo de máquinas cliente. Cuando esos ordenadores realizan solicitudes a sitios y servicios en Internet, el servidor proxy intercepta esas peticiones y luego se comunica con los servidores web en nombre de esos clientes, como un intermediario.”

¿Cuáles son los beneficios de un Reverse Proxy?

•     Ofrecer IPv4 o IPv6 transparente a clientes provenientes desde Internet servidos desde una granja de servidores IPv6 Only (en esto nos enfocaremos)

•     Escalabilidad: Al utilizar un proxy inverso, es posible agregar o eliminar servidores backend según sea necesario sin afectar a los usuarios finales. Esto facilita la escalabilidad horizontal de las aplicaciones, lo que permite manejar un mayor número de solicitudes y usuarios simultáneos.

•     Cacheo de contenido estático: NGINX puede almacenar en caché contenido estático como imágenes, archivos CSS y JavaScript, lo que reduce la carga en los servidores backend y acelera la entrega de contenido a los usuarios. Esto mejora el tiempo de carga de las páginas y reduce el ancho de banda necesario.

•     Seguridad: NGINX actúa como un punto de entrada a la aplicación, lo que proporciona una capa adicional de seguridad. Puede realizar funciones como filtrado de solicitudes, prevención de ataques DDoS, protección contra inyecciones SQL y autenticación de clientes. Además, NGINX puede habilitar el uso de SSL/TLS para cifrar la comunicación entre los clientes y el servidor backend.

•     Enrutamiento avanzado: Un proxy inverso permite realizar enrutamiento avanzado según diferentes criterios, como el nombre de dominio, la URL o las cabeceras HTTP. Esto es útil en casos donde se necesite dirigir el tráfico a diferentes servidores backend según las características de la solicitud.

•     Consolidación de servicios: NGINX puede actuar como un punto de entrada único para varios servicios backend. Esto simplifica la infraestructura al consolidar múltiples servicios en un solo servidor, lo que facilita la administración y el mantenimiento.

•     Mejora del rendimiento: NGINX está diseñado para ser liviano y eficiente en el uso de recursos. Su arquitectura optimizada y su capacidad para manejar grandes cantidades de conexiones simultáneas lo convierten en una opción popular para mejorar el rendimiento de las aplicaciones web.

•  Balanceo de carga: Un proxy reverso como NGINX puede distribuir el tráfico entrante a través de varios servidores backend. Esto ayuda a equilibrar la carga de trabajo y garantiza que ningún servidor esté sobrecargado, lo que mejora el rendimiento y la capacidad de respuesta de la aplicación. 

Topología que vamos a usar

¿Qué vamos a lograr el día de hoy?

El servidor en el borde (Servidor Proxy Reverso) va a ser capaz de recibir peticiones HTTP en IPv4 e IPv6, y dependiendo del sitio Web que se desea visitar (dominio) re-enviará la consulta al servidor correcto. En el ejemplo actual ocurrirá lo siguiente:

El Cliente visita      Petición enviada a:

server-a.com   →   2001:db8:123::101

server-b.com   →   2001:db8:123::102

server-c.com   →   2001:db8:123::103

Prerrequisitos

• Linux con Nginx en el Servidor Proxy Reverso 

• Acceso super usuario

• Servidor Web en cada uno de los servidores de la granja

• Conectividad a Internet IPv4 e IPv6

• Conectividad interna en IPv6

Manos a la obra

1) Instalar nginx en todos los servidores 

   #apt update

   #apt install nginx

2) Crear los sitios Web en el Proxy Reverso NGINX 

Archivo  /etc/nginx/sites-available/server-a.com

server {

listen 80;

listen [::]:80;

    server_name server-a.com;

    location / {

        proxy_pass http://[2001:db8:123::101];

    }

}

Archivo  /etc/nginx/sites-available/server-b.com

server {

listen 80;

listen [::]:80;

    server_name server-b.com;

    location / {

        proxy_pass http://[2001:db8:123::102];

    }

}

Archivo  /etc/nginx/sites-available/server-c.com

server {

listen 80;

listen [::]:80;

    server_name server-c.com;

    location / {

        proxy_pass http://[2001:db8:123::103];

    }

}

3) Crear links simbólicos para habilitar los sitios configurados:

root@ProxyReverseSRV:/etc/nginx/sites-enabled# ln -s /etc/nginx/sites-available/server-a.com /etc/nginx/sites-enabled/server-a.com

root@ProxyReverseSRV:/etc/nginx/sites-enabled# ln -s /etc/nginx/sites-available/server-b.com /etc/nginx/sites-enabled/server-b.com

root@ProxyReverseSRV:/etc/nginx/sites-enabled# ln -s /etc/nginx/sites-available/server-c.com /etc/nginx/sites-enabled/server-c.com

4) Recordemos reiniciar nginx:

$sudo systemctl restart nginx

Sobre los logs

Los registros de conexión (logs) son de suma importancia para cualquier empresa e ISP que desea realizar alguna revisión de las conexiones entrantes.

  Lo que ocurre es que NGINX por defecto utilizará su propia dirección IP cuando realice las conexiones salientes, lo que trae como consecuencia que se pierde la dirección del cliente que originó la solicitud HTTP.  Pero no se preocupen, NGINX tiene la solución, se llama proxy_set_header y la configuración se divide en el servidor final y en el servidor Proxy Reverso.

1. En el Servidor Proxy Reverso, archivo del sitio web.

# Ejemplo de  nginx reverse proxy que permite conservar la dirección

# y puerto de original del cliente

location /examples {

  proxy_pass http://[2001:db8:123::103];

  proxy_buffering off;

  proxy_set_header X-Real-IP $remote_addr;

  proxy_set_header X-Forwarded-Host $host;

  proxy_set_header X-Forwarded-Port $server_port;

  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

}

2. En el servidor final en el archivo: /etc/nginx/nginx.conf agregar en la sección http lo siguiente:

   set_real_ip_from 2001:db8:123::100; #sustituir la dirección IP por la del Proxy

   real_ip_header X-Forwarded-For;

   real_ip_recursive on;

Ejemplo:

http {

    …

    set_real_ip_from 2001:db8:123::100;

    real_ip_header X-Forwarded-For;

    real_ip_recursive on;

   …

}

  Luego de estas configuraciones el servidor final confiará en la cabecera llamada X-Forwarded-For que provenga del IP 2001:db8:123::100 y en sus registros (/var/log/nginx/access.log) se podrá apreciar la dirección origen del cliente.

Conclusiones

Se puede percibir que con el diseño propuesto podemos administrar una granja de servidores web 100% IPv6 Only con acceso al mundo tanto IPv4 e IPv6 de una manera muy sencilla, escalable y eficiente. Lo anterior trae consigo diferentes beneficios tales como: administrar solo un stack TCP/IP, simplicidad, seguridad e incluso ahorro de direcciones IPv4.

Referencias

• [1] https://www.cloudflare.com/es-es/learning/cdn/glossary/reverse-proxy/

• https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-as-a-reverse-proxy-on-ubuntu-22-04

• Archivos de configuración de todo el proyecto en el Github de LACNIC:  https://github.com/LACNIC/BlogPostHelpFiles/tree/main/2023_Ofreciendo_conectividad_Dual_Stack_a_servidores_Web_en_una_granja_de_servidores_100_IPv6_Only

ortodoncia invisible madrid