viernes, 17 de mayo de 2024

Video: Revisando la nueva características AddPaths-Limit en FRR. Una mejora al tradicional AddPath de BGP

 


En el video recorremos y realizamos un Demo sobre el draft "Paths Limit for Multiple Paths in BGP ". Un documento que viene a ser una mejora a la técnica Add-Path definida en el RFC 7911. Se realiza un demo de BGP tradicional, luego add-path y finalmente la nueva funcionalidad de AddPaths-Limit. Al final se acompaña con una captura de tráfico usando Wireshark. Un video muy interesante a los interesados en conocer las nuevas características que tendrá BGP en un futuro. Link al video sobre RFC 7911 https://www.youtube.com/watch?v=eAzWTfE9qtA





miércoles, 1 de mayo de 2024

Solución a: Error: eth0 interface name is not allowed for R2 node when network mode is not set to none

Problema:

  Containerlab devuelve un error similar:

Error: eth0 interface name is not allowed for R2 node when network mode is not set to none


Solución:
  En el archivo .yml en la sección del nodo que indica el error de la topología especificar: 

network-mode: none

Ejemplo:

topology:
  kinds: 
    linux:
      image: quay.io/frrouting/frr:8.4.1
  nodes:
    R1:
      kind: linux
      image: quay.io/frrouting/frr:8.4.1
      network-mode: none


  Volver a ejecutar la topología con clab dep -t archivo.yml y listo!

Suerte.







domingo, 21 de abril de 2024

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 nombre indiscutiblemente me llamó la atención.


Historia

La necesidad de encapsular un protocolo en otro no es nada nuevo. De hecho, esta práctica lleva con nosotros aproximadamente 30 años.

Retrocedamos a la década de los 90. En estos años ocurrió de todo en cuanto a las ideas de encapsular un protocolo en otro. Por ejemplo, IP-IP (IP en IP) apareció cuando Internet estaba en sus primeras etapas de expansión comercial y se buscaban formas de conectar redes privadas sobre la infraestructura de red pública, lo que conocemos hoy en día como Internet.

En esa misma década sin ir muy lejos aparecieron otras tecnologías que aún son muy populares como -el querido- GRE, PPTP, L2TP, e incluso ya a finales de los 90’ y comenzando los 2000, hubo grandes avances con VPNs IPSEC.

Pero no avancemos tanto en el tiempo, vamos a quedarnos un rato más en los 90’. Ya no solo se quería encapsular IPv4 en IPv4, también dieron un paso adelante con IPv6 y apareció el protocolo 41 (IPv6 en IPv4) en 1998.

A partir de aquí el resto es historia. Ya se han realizado cualquier cantidad de “mezclas” de encapsulamientos de protocolos, como IPv4 sobre IPv6, IPv6 sobre UDP sobre IPv4, ethernet sobre IP y un largo etcétera.


Ok, volvamos al draft Ethernet sobre HTTPS

A finales del año 2023, específicamente el día 27 de diciembre dentro del Working Group INTAREA (Internet Area Working Group) llegó un draft con el título Ethernet sobre HTTPS,


¿De qué trata el draft?

El Draft busca definir un protocolo para encapsular tramas ethernet sobre HTTPS, permitiendo una comunicación segura entre clientes y servidores Web internos.


¿Cómo se pretende lograr lo anterior?

Dentro de la sección 1.2 del documento se realiza la siguiente explicación, que podemos resumir en lo siguiente:


El cliente, al especificar una URL interna, reconoce que se debe utilizar Ethernet sobre HTTPS para la comunicación. El navegador del cliente, preconfigurado con la dirección IP y el puerto del Servidor HTTP que actúa como puerta de enlace a la LAN, inicia el protocolo Ethernet sobre HTTPS y envía una solicitud de autenticación al servidor. Una vez autenticado, el cliente envía una solicitud de página web interna encapsulada dentro de una solicitud HTTPS. El servidor desencapsula la trama Ethernet, extrae la solicitud HTTP original y la enruta al servidor web interno. Luego, el servidor encapsula la respuesta del servidor web interno y la envía de vuelta al cliente.


Diagrama de operación





Respuesta al cliente

El draft explica que la respuesta a una solicitud de un cliente es en formato JSON. Un ejemplo sería:




Puntos positivos del draft

Trata de un tema interesante, puede ser novedoso y tener una gran cantidad de implementaciones.

Por el momento es un draft corto y correctamente hace hincapié en el área de seguridad y autenticación. 

Dudas que deja el mismo


El problema no queda bien definido, es difícil entender por qué se desea solucionar una situación a nivel HTTP desde Ethernet.

Pareciera que el servidor EoH es similar a un proxy

El área de seguridad a nivel de capa 2 es muy delicada, debería ser al menos mencionada en el draft

Expresan respuestas en json de mac_address y direcciones IP con un ejemplo de IPv4 ☹️

Indiscutiblemente, la explicación del funcionamiento deja muchas dudas

Es muy normal en el mundo de encapsulamiento tener preocupaciones en el área del exceso de payload. Transportar ethernet sobre HTTPS es literalmente cargar todo el modelo TCP/IP en HTTPS

Al punto anterior hay que sumar los posibles problemas de MTU que pueden conllevar este tipo de soluciones.

Ya existen varios trabajos en este sentido, el primero es el draft “Proxying ethernet in  HTTP” y un software que hace precisamente lo que promete el draft llamado Softether. Lo anterior sin mencionar  “Proxying IP in HTTP” el cual incluso ya es un RFC Standard Track (RFC 9484).


Pronóstico sobre el draft

Recordando el funcionamiento de IETF (ver diagrama abajo), donde individuos proponen drafts de manera personal, luego son adoptados por el WG, y más adelante luego de un consenso de la comunidad en varias etapas, el mismo es adoptado como RFC.




The IETF Publication Process


Con la versión actual del mismo, no pareciera que el draft avance mucho. Pienso que quedará lejos del consenso dentro IETF. Hoy en día no se aprecia mayor soporte por parte de la comunidad, sin embargo no quiero descartarlo 100% porque pueden ocurrir cosas que le den un giro al mismo como conseguir nuevos autores, conseguir un “running code”, presentarlo presencialmente y muchas otras cosas.


Conclusiones


Es un draft que propone una idea arriesgada, vamos a llamarla reflexiva, sin un problema claro que resolver. Esto es un claro ejemplo de que no todos los documentos que llegan a IETF son tan elaborados, a veces son solo ideas para medir la temperatura de la comunidad.


¿Qué opinas de este draft? ¿Te ánimas a introducir algún documento a IETF?

viernes, 8 de marzo de 2024

BGP Stream: un año de análisis sobre incidentes BGP

BGP Stream: un año de análisis sobre incidentes BGP

04/03/2024


Por Alejandro Acosta, Coordinador de I+D en LACNIC

LACNIC presenta la primera página on line que muestra los incidentes y el análisis de datos de medición del Border Gateway Protocol (BGP) en América Latina y el Caribe.

PRINCIPALES SUCESOS. Además de sumarizar la información se aprecian los tres principales sucesos, los cuales son: posibles secuestros de red, interrupciones BGP y fugas de rutas.

Posibles secuestros de red es la adquisición ilegítima de grupos de direcciones IP al corromper las tablas de enrutamiento de Internet. Tradicionalmente ocurre cuando el Sistema Autónomo anuncia un prefijo que no le pertenece.

Interrupciones (outages) se refiere a la pérdida de visibilidad de prefijos de red por un grupo mayoritario de sensores[1] .

Fugas de rutas como su nombre lo indica, se refiere al anuncio -posiblemente- no intencional de algún prefijo de red vía BGP. Por ejemplo, un peering privado de intercambio de tráfico, alguno de los participantes anuncia el prefijo del peer a Internet. Este caso es el más difícil de detectar por los algoritmos y no consigue identificar algunas de éstas incidencias.

¿Cómo se obtienen los datos?

Esta iniciativa utiliza BGP Stream de Cisco, un proceso automatizado que selecciona los incidentes más grandes e importantes, qué tipo de situación es y cuáles ASNs están involucrados.

La información se publica de forma abierta ya que LACNIC considera que se trata de información importante para que ingenieros, responsables de redes y organizaciones puedan conocer los incidentes más comunes de la región y crear conciencia sobre la situación.

Ello permite la investigación eficiente de eventos, creación rápida de prototipos y de herramientas complejas y aplicaciones de monitoreo a gran escala (por ejemplo, detección de interrupciones de conectividad, ataques o secuestros de BGP).

En base a un sistema desarrollado por el área de I+D de LACNIC, se obtienen los datos de forma cruda, los parcela, identifica, limpia y almacena en una base de datos para posteriormente generar estadísticas y gráficas. Lo anterior ocurre cada 24 horas de forma automatizada.

RESULTADOS. Durante el período de tiempo estudiado -febrero 2023 a febrero 2024- nos encontramos con los siguientes resultados que se muestran en la siguiente gráfica comparando eventos BGP mundiales vs eventos BGP de nuestra región.

Comparando la gráfica mundial versus la gráfica de la región vemos que el orden de incidentes es similar (el mayor es outages, seguido por posibles secuestros de red y finalizando en fugas de prefijos).  Adicionalmente hay que destacar que en nuestra región las interrupciones (outages) son más frecuentes en comparación con el total mundial de eventos BGP. 

Al analizar la tabla resultados mostrando eventos BGP Mundiales vs eventos BGP de nuestra región, nos encontramos con los siguientes fatos.

TOP 5 países de nuestra región con Interrupciones BGP (Outages)

Outages 
CCEvents
BR781
AR99
HT24
MX22
CL17

TOP 5 países de nuestra región con secuestros de prefijos (Possible Hijacks)

Expected CCDetected CCEvents
BRBR67
BRnone35
PYBR24
BRUS22
BRCN9

TOP 3 países de nuestra región con fugas de rutas (Route Leaks)

Origin CCLeaker CCEvents
VEVE7
MXMX5
CLPA2

El impacto

En este primer año de funcionamiento desde LACNIC hemos observado una disminución de los incidentes BGP, entre los motivos de estos resultados podemos identificar: a) el despliegue y la adopción de Sistema de Certificación de Recursos (RPKI), b) el Registro de Enrutamiento de Internet de LACNIC (IRR) y la adopción del RFC 9234 (Roles en BGP).

La adopción de dichas herramientas se está dando por mejores prácticas de los operadores y el impulso de MANRS por ISOC.

Conclusiones

Los posibles secuestros de red (BGP Hijacks), interrupciones BGP (Outages) y fugas de rutas son los incidentes BGP más comunes. Durante el primer año de recopilación de datos, se observa una disminución de estos casos; sin embargo, en el futuro cercano no desaparecerán por completo. Es crucial implementar medidas robustas de redundancia y resiliencia en las redes, así como detectar y prevenir tempranamente posibles secuestros para garantizar la integridad y confiabilidad de las rutas de Internet.

En LACNIC, buscamos crear conciencia y motivar a los ISPs y organizaciones a estar preparados para abordar estos incidentes de manera eficiente cuando ocurran.

Referencias

https://stats.labs.lacnic.net/BGP/bgpstream-lac-region.html

https://stats.labs.lacnic.net/BGP/bgpstream.html

https://bgpstream.crosswork.cisco.com/ 

miércoles, 28 de febrero de 2024

viernes, 23 de febrero de 2024

La verdadera solución para correr ContainerLAB en MAC m1, m2, m3 apple silicon

 



Paso 1: Instalar Multipass de Canonical

$brew install multipass


Paso 2: Instalar la VM llamada docker

$multipass launch docker --name mydocker


Paso 3: Conectarse a la nueva VM

$multipass shell mydocker


Paso 4: Dentro de la VM instalar ContainerLab

$sudo su

#bash -c "$(curl -sL https://get.containerlab.dev)"


Vamos a probar con esta sencilla topología back2back de dos equipos Linux con FRR


-- 2-frr-back2back.yml --

name: ipv6-ws

topology:

  kinds:

    linux:

      image: ghcr.io/hellt/network-multitool

  nodes:

  ROUTERS ###

    R1:

      kind: linux

      image: quay.io/frrouting/frr:8.4.1

      exec:

        - "sysctl -w net.ipv6.conf.all.forwarding=1"

        - "ip address add dev eth1 2001:db8:ffab::1/64"

    R2:

      kind: linux

      image: quay.io/frrouting/frr:8.4.1

      exec:

        - "ip address add dev eth1 2001:db8:ffab::2/64"

        - "sysctl -w net.ipv6.conf.all.forwarding=1"

  links:

    - endpoints: ["R1:eth1", "R2:eth1"]

--- yml --


Paso 5: Levantemos la topología con clab:

clab dep -t 2-frr-back2back.yml


Paso 6: finalmente vamos a conectarnos a una de las VMs dentro de ContainerLAB

docker exec -i -t clab-ipv6-ws-R2 bash

lunes, 19 de febrero de 2024

Inocentada: La verdad detrás del coqueteo de QUIC y BGP

Netland, 1707882300

Hoy tengo el honor de compartir con ustedes un secreto que he guardado celosamente durante mucho tiempo. Un secreto que, una vez revelado, cambiará nuestra percepción de la realidad y sacudirá los cimientos de nuestra sociedad. Permítanme llevarlos a un viaje a través de los pasillos oscuros de la red, celos, amor y el engaño, donde una verdad oculta ha estado esperando pacientemente para ser descubierta. Pasa en las películas, pasa en la vida, pasa en la red.
He esperado precisamente el día de los enamorados para contar sobre este  peculiar romance. Es muy duro y difícil de digerir para muchos profesionales de la red.  Relatar la historia de cómo TCP, el antiguo y confiable, conquistó el corazón de BGP, y cómo, tras décadas de lealtad, BGP ahora se encuentra coqueteando con.., correcto, con QUIC.

Acto I: Un poco de historia

Hace muchos años, en los albores de la red, TCP y BGP se cruzaron en un oscuro rincón de la topología. BGP, con su elegancia y sus enigmáticas tablas, cautivó a TCP. La conexión se estableció, y juntos construyeron una red resiliente. BGP admiraba la paciencia de TCP, su capacidad para esperar y retransmitir cuando las cosas se volvían difíciles.

Acto II: La famosa Rutina, ni en la red parece ser buena

Los años pasaron, y BGP y TCP se convirtieron en una pareja estable. La tabla de rutas de BGP creció, y TCP seguía transmitiendo sus paquetes con diligencia. Pero algo comenzó a cambiar. BGP miraba más allá de las fronteras de su dominio, de los firewalls y los IDPs. Había oído hablar de QUIC, un protocolo rápido y moderno que prometía una conexión más íntima y eficiente.

Acto III: El Coqueteo

BGP y QUIC comenzaron a encontrarse en conferencias y grupos de trabajo. Intercambiaban miradas furtivas en los paquetes de datos. QUIC, audaz y atrevido, le susurraba a BGP sobre su capacidad para sortear los problemas de latencia y congestionamiento. BGP, aunque leal a TCP, no podía evitar sentirse intrigado.

Acto IV: El secreto

Retomando el correo que les conté al comienzo que me llegó por error, me doy cuenta que  BGP le cuenta de todo a su tío, el viejo EGP
El texto decía lo siguiente: “QUIC es emocionante, ágil y tiene una forma de moverse que me resulta intrigante. Su naturaleza basada en UDP me hace sentir que puedo ser más libre y ágil, algo que no sucede con mi conexión tradicional a través de TCP.”,
Luego hay un pedazo que no se pudo recuperar y más adelante dice esto: “Tío, al principio, me resistí a los encantos de QUIC, aferrándome a la familiaridad y seguridad que me brinda TCP. Pero con el tiempo, no pude ignorar la energía y la emoción que QUIC aportaba a nuestra relación.”
Leer también:
Un necesario RFC sobre BGP: AS Path Prepending

Acto V: La Decisión

Y así, en esta temporada de enamorados, BGP se encuentra en una encrucijada. ¿Debería seguir con su relación estable con TCP, o debería aventurarse con QUIC? Las noches son largas mientras BGP reflexiona sobre su futuro. ¿Es posible amar a dos protocolos a la vez?

Acto VI: El pronóstico de los expertos

Algunos dicen que el amor no tiene edad ni fecha en el calendario, los expertos reconocen la historia de BGP y  TCP como profunda e intrigante. Todos concuerdan que  BGP es un protocolo caballeroso, muy serio y no creen que vaya a arriesgar su vida completa a su edad y con la gran responsabilidad que lleva consigo.

Acto VII: ¿Qué piensa TCP de estos rumores?

TCP con su gran experiencia no quiso expandir su respuesta, pero se limitó a decir:  “me siento dolida pero detrás de cada gran protocolo existe una gran acompañante, solo me queda decir que sería emocionante contemplar un futuro donde BGP pueda explorar nuevos horizontes con QUIC, por ello aquí estoy, la animaría a seguir adelante y darle una oportunidad al nuevo romance”


Att.

Rebif Citpo VI + Tniv Frec, Avaj, Cin, Pir, Lrep, Locotorp, Tan Tap, Lufetats

P.D. Es una inocentada, pero ojo, cuando el río suena, piedras trae: https://datatracker.ietf.org/doc/draft-retana-idr-bgp-quic/

Una mejora práctica en el Transporte DNS sobre UDP en IPv6

Por Hugo Salgado y Alejandro Acosta Introducción y planteamiento del problema En el presente documento queremos discutir sobre un draft (bor...