Algo que estuve pensando es, que tal vez necesitemos manejar distintos protocolos de enrutamiento dentro de LOR en este futuro cercano.
La propuesta sería, pasar de una sola red Babel, a varias redes. Estas otras podrían seguir siendo babeld, babeld-lor, o usar otros.
Asi podriamos:
No depender de un solo protocolo (?)
Alivianar las tablas de enrutamiento para todos
Tener más seguridad: un ataque que comprometa LOR no lo logrará romper del todo.
Posibilitar más tipo de configuraciones
Desventajas:
Separacion de LOR en bloques grandes (dentro de ésta red, vos solo puedes tener IPs de éste /18, etc.)
Habra que instalar varios puntos de interconexión estilo PIT.
Dependiendo del caso, no roaming.
Dependiendo del caso, no habría resilencia garantizada.
Dependiendo del caso, no habría descentralización total.
Por ejemplo, en guifi.net se han organizado por bloques de IPs, y al ser un proyecto con bastante edad, ahora manejan distintos protocolos (Babel, OSLR, EIGRP, batman y batman-adv, bmx6, bmx7, etc.) y configuraciones diferentes por zonas o provincias.
Como desventajas
La resilencia de la red depende estrictamente del diseño de la subred y de los puntos de interconexión (IX)
No hay descentralización a nivel Red Nacional, ya que para salir fuera de tu subred dependes de routers IX.
No hay roaming entre subredes.
Pero a ellos les funciona bien ése diseño.
En nuestro caso, quizás convenga… separar la red Meshnet? (VPN), o quizás separar las tablas babeld de supernodos y nodos? O separar todo LOR por zonas? Usamos solo Babel o más protocolos? Son varias ideas que seria bueno discutir.
Hasta ahora hemos usado exclusivamente el protocolo Babel para enlazar nodos en LOR, debido a su sencillez y robustez.
La propuesta sería, pasar de una sola red Babel, a varias redes. Estas otras podrían seguir siendo babeld, babeld-lor, o usar otros.
babeld-lor es una modificación al protocolo Babel que le agrega una condición obligatoria de autenticación que evita que un nodo sea suplantado por otro por que babel es vulnerable a IP spoofing. (Especificación de babeld-lor), Babeld-lor rama forked-updateTLV es la última actualización.
babeld-lor presenta algunas desventajas:
Para que un nodo se una a la red una Entidad central debe generarle (sólo una vez) un set de tokens cifrados. Esto hace que la red dependa de esa entidad para que un nuevo nodo se una.
Para autenticarse los unos a los otros, los nodos deben descifrar los tokens cifrados y esto supone procesamiento adicional y una gran aumento de tráfico en el protocolo Babel.
Si se consigue obtener la clave privada de la entidad central, toda la red queda comprometida.
La implementación no esta terminada y presenta algunos errores.
Cuando presenté esta modificación en la lista de correos de Babel resaltaron también otros inconvenientes.
Sin embargo, se puede mejorar babeld-lor para que conviva con Babel se podría hacer que ciertos nodos (críticos) usen autenticación y el resto de la red siga usando el protocolo Babel original. Básicamente una red híbrida con algunas conexiones más seguras así no se rompe todo.
… debemos seguir desarrollando los demás puntos pendientes
Ayer domingo Rodrigo sugirió el protocolo bmx6 que otros proyectos usan, me dio una idea y hoy estuve haciendo pruebas con su sucesor bmx7.
Por el momento tengo esta lista de ventajas:
bmx7 es un protocolo sólo-IPv6 y exige una red que la soporte nativamente. En casos muy contados quizás sea una desventaja, pero otras ventajas lo compensan, y además con ésto aseguramos una red moderna.
bmx7 abstrae la configuración de las interfaces donde actúa: él sólo se pone las direcciones IPv6 automáticamente, y no se necesita configuración de parte de UCI. Bueno para automatizar compilaciones de fw.
bmx7 usa firmado digital para sus anuncios, que al parecer sirve para evitar suplantar rutas nativas, habría que hacer más pruebas al respecto.
bmx7 usa UHNA para intercambiarse rutas nativas, ésto garantiza la no-existencia de colisiones o suplantación sin querer.
Además de las rutas nativas sólo-IPv6, bmx7 soporta túneles tun ip46in6, donde los routers pueden anunciar rutas IPv4 e IPv6.
Al contrario que los anuncios nativos, con túneles se pueden anunciar redes que se pisen por completo o que se solapen.
Los nodos pueden ver a los routers que anuncien rutas a una misma red, y elegir voluntariamente cuál usar, usando condicionales, etc. En babeld, la ruta escogida la gana por defecto el más cercano o el más potente.
bmx7 exige por defecto que le digas qué ruta quieres anunciar, no es como babeld, que tiende a agarrar toda la tabla y anunciarlo todo.
El plugin table te permite agarrar tablas existentes y redistribuirlas por completo, útil para mezclar bmx7 con otro protocolo
bmx7 crea por sí solo su propia tabla de ruteo, y las rutas que crea son pocas a comp. de babeld.
Ya que no hay routing IPv4 nativo, no es necesario separar bloques de IPv4 para sólo-routers, y tampoco configurar IPs /32, útil para automatizar configuración.
También hay desventajas:
Usar túneles IPv4 no es óptimo:
Ya no puedes diagnosticar problemas en medio de la red usando traceroute o mtr, tendríamos que acostumbrarnos a usar IPv6.
Generan carga adicional en los routers, aún peor, usando tun. Por suerte, en este caso no es mucho (dejo una captura abajo), he podido llegar a 70Mbps con un router Atheros a 400MHz, los routers LOR deberían ser mejores que eso.
bmx7 es más pesado que babeld: un punto bmx7 con un vecino me ocupa 3.5MB de RAM, un punto babeld con al menos 5 vecinos me ocupa 1.0 MB. Igual, los paquetes ipk son más pesados (incluyendo una dependencia en mbedtls), y no es conveniente usarlos en routers 32/4 (o sea, 32 MB ram, 4 MB flash).
Por mi parte estoy interesado en seguir haciendo más pruebas con bmx7. Ya que necesitaríamos poner énfasis en la Red (que ya soporta IPv6) y volverla IPv6-preferida, quizás tengamos que hacer cambios, como permitir que la gente lleve sus propias direcciones IPv6, si tiene.
(ésto último es interesante, para hacer un futuro PIT ciudadano integrado a LOR)
bmx6 es bastante parecido, no tiene autenticación y soporta IPv4 nativo. El problema es que es sólo puede ser sólo-IPv4 o sólo-IPv6, y el tema de asignar IPv4 nativo a todos los routers ya no es atractivo ni fácil de automatizar, quizás por eso lo quitaron en bmx7.
Aquí tengo la conf. que he usado para bmx7, ya que hay muy poca documentación en internet, y la que hay, está incompleta:
Contenido de /etc/config/bmx7 (clic aquí)
config 'bmx7' 'general'
# option 'runtimeDir' '/var/run/bmx7'
# option 'trustedNodesDir' '/etc/bmx7/trustedNodes'
config 'plugin'
option 'plugin' 'bmx7_config.so'
config 'plugin'
option 'plugin' 'bmx7_json.so'
config 'plugin'
option 'plugin' 'bmx7_sms.so'
# en mi router principal no tengo wifi
#config 'plugin'
# option 'plugin' 'bmx7_iwinfo.so'
config 'dev' 'mesh_local'
#option 'dev' 'eth0.200'
option dev 'ref:network.lor7.ifname'
config 'plugin'
option 'plugin' 'bmx7_tun.so'
config 'plugin'
option 'plugin' 'bmx7_table.so'
# en la doc. dice unicast_hna, pero unicastHna es la que sirve.
config 'unicastHna' 'miPrefijoGlobal'
option 'unicastHna' '2001:470:5:6a2::/64'
# crear un túnel que anuncie estas direcciones
config 'tunDev' default
option 'tunDev' 'lor7tunel'
option 'tun6Address' '2001:470:5:6a2::1/64'
option 'tun4Address' '10.32.20.1/25'
# Ser receptor (gw-client) y aplicar a mi sistema TODOS los anuncios de túneles
config 'tunOut'
option 'tunOut' 'ip4Default'
option 'network' '0.0.0.0/0'
#option 'minPrefixLen' '25'
config 'tunOut'
option 'tunOut' 'ip6Default'
option 'network' '::/0'
#option 'minPrefixLen' '64'
Ahora que ya entiendo bmx7, además de leer ésto, los planes de LibreMesh ya tienen sentido para mí en una Red grande y permanente, y sería bueno ver si es posible luego integrar eso de L2 roaming en el Wi-Fi abierto, aunque no sé si hay builds de LibreMesh con bmx7.
Muy bien , estaré revisando sobre bmx7 y los puntos que mencionas, rápidamente leí que utiliza un par de claves pública y privada y eso supone de verdad trabajo extra y claro dependencia permanente en la biblioteca mbedtls.
Imagino en routers de 4MB flash no alcanzará para convivir con luci y supongo estos routers estarían descartados para actuar como router principal para un nodo en LOR.
La duda rápida que me ha surgido es si va a ser fácil separar redes pública y privada dentro de cada nodo como se describe (preliminarmente aquí en la wiki) es decir un espacio para servidores públicos y un espacio para dispositivos clientes.
Usando el truco para quitar paquetes inútiles y usar un LuCI bien liviano se puede, así lo hice en mi router de pruebas, pero en mi caso ya no queda espacio para wpad (necesario para enlaces ad-hoc cifrados).
Quizás se pueda ahorrar aún más espacio compilando LEDE 17.01 y desactivando debug de kernel, aplicando minify a LuCI, aumentando el block size de squashfs, etc. (así tengo algunos routers), pero no creo que para varios routers LOR valga la pena el esfuerzo.
En teoría sí, mas bien bmx7 facilita el tema al tener que darle al inicio los bloques que queramos distribuir. Se pueden anunciar (nativamente o por túnel) los bloques para LOR, sean 172.24 o 10.64. El firewall seguiría comportandose de igual manera que con babeld.
Ahora que se me ocurre, para evitar crear túneles a diestra y siniestra en routers intermedios en una red grande LOR, podemos deshabilitar proactiveTunRoutes, lo saqué del link (que puse en el anterior post) del que hizo su pasantía aportando código a LibreMesh.
Bien , debemos revisar más a fondo bmx7 e incluso la posibilidad de manejarlo de manera híbrida en nodos que necesiten mayor seguridad junto con babeld, LOR se puede beneficiar mucho de ser una red IPv6 pura y así evitar túneles.
No estoy encontrando documentación muy clara de bmx7, a parte del repositorio den github ¿donde más esta la documentación?
No hay, no existe supongo por eso es que no he considerado bmx6 y 7 hace años, no se entendía claramente el funcionamiento o la “manera de pensar” de los desarrolladores.
Aunque toda la documentación importante está en el repo de github (y bmx7 --verbosehelp ayuda bastante), la documentación para el módulo uci tiene errores y poca información.
Un truco que he visto para escribir en /etc/config/bmx7, es aplicar a mano las configuraciones al bmx7 que está funcionando, usando bmx7 -c. Si el bmx7 tiene instalado el plugin uci, éste genera automáticamente reglas UCI que se pueden grabar con LuCI (en “Cambios no guardados”) o con uci commit.
Adicionalmente, si sigues haciendo pruebas, sería bueno revisar el funcionamiento de --trustedNodesDir y --setTrustedNode, a simple vista parece que bmx7 autentica a los nodos cercanos usando la idea descentralizada de gpg de una red de confianza (ésto eliminaría al punto central que va autenticando a los nodos).
Me parece super interesante los diferentes protocolos, sin embargo si en actualidad sólo existen unos cuantos nodos, incluso se pueden utilizar rutas estáticas.
Asi es, sin embargo desde el principio hemos querido construir una red descentralizada (lo más que se pueda) y que crezca automáticamente. Por eso nos esforzamos en probar protocolos de enrutamiento para redes en malla.
Además en nuestro medio la mayoría de los usuarios no estaría dispuesto a configurar rutas estáticas para unirse a la red.
Estuve revisando un poco más sobre bmx7 que está basado en bmx6 y las medidas de seguridad que le agrega a la red.
Encontré un video de presentación de bmx7 donde muestra unos benchmarks indicando que el incremento de uso de CPU y memoria RAM es lineal a medida que crece la red. El uso de CPU es elevado seguramente por el uso criptografía asimétrica RSA para firmar mensajes del protocolo, donde cada nodo tiene su par de claves RSA.
Aun no encuentro documentación más completa pero realmente parece valer la pena probar bmx7 como protocolo de enrutamiento principal para los nodos de LaOtraRed debido a sus medidas de seguridad . Seguramente cuando la red crezca a mas de 50 o 100 nodos el uso de CPU será muy notorio en los enrutadores, aunque para ese entonces podríamos idear alguna estrategia como usar babel como puente entre zonas bmx7 (grupos de nodos enlazados con bmx7).
Sugiero centrarnos en probar este protocolo pensando todo en IPv6 solamente para evitar túneles , también ver como facilitar o incluso automatizar configuraciones
@strysg@looper de acuerdo, bmx6/7 se ve muy interesante. es importante investigar opciones para que la red sea lo más flexible o descentralizada posible y también para medir el rendimiento. Pienso que lo ideal sería tener unos cinco o diez nodos para ver/optimizar el rendimiento de diferentes protocolos de enrutamiento, así como clientes y servicios. Una alternativa como línea base es automatizar la configuración de rutas estáticas y así reducir el overhead, al menos como ejercicio para comparar con cada protocolo de enrutamiento.
Estuve haciendo pruebas en bmx7 y quería poner un borrador de propuesta para el enrutamiento en el core de LaOtraRed según como también lo íbamos hablando con @looper.
Core
Le llamamos así a la parte troncal o conexiones físicas en la red, estas conexiones forman una red mesh y se conectan y descubren mediante el protocolo bmx7.
Usando este protocolo, cada nodo en LaOtraRed tendría asegurado:
Que el prefijo de red anunciado por cada nodo no se solapen y sean únicos por nodo.
Ningún otro nodo pueda tomar la identidad de otro.
El enrutamiento es sólo IPv6.
Segmentación de IPs?
Ya que los servidores no deben cambiar su dirección IP o no se podrá asegurar acceso seguro a los servicios que cada nodo quiera montar, cada nodo debería anunciar un bloque de direcciones fijo.
Puede ser buena idea mantener un registro estático de direcciones IPv6 para que lo utilicen los servidores de LaOtraRed.
Por ejemplo una nodo A podría anunciar el bloque fc01:cafe:0100::/56. Con esto tiene un espacio gigante para poner servidores todos con IPv6 dentro ese bloque.
Otro nodo B podría anunciar tener el bloque fc01:cafe:0200::/56 y también su espacio para servidores y para APs abiertos.
Siguiendo ese principio de utilizar direcciones IP estáticas, En el debate sobre nodos he puesto una propuesta de infraestructura de cada nodo y el enrutamiento es solamente IPv6.
Continuando con las propuestas de enrutamiento, se había definido el concepto de core. La cosa es que creo conviene más utilizar el término Red Troncal y así estará más acorde al escenario de redes, a continuación una descripción más detallada de la red troncal.
Red Troncal
Es el conjunto de conexiones físicas en topología en malla que se gestionan mediante el protocolo bmx7. Los equipos conectados directamente a la red troncal (a un salto) se denominan nodos y son visibles en la totalidad de la red.
Figura . Idea de la red Troncal
En la figura de arriba, sólo son nodos A,B,C,D,H.
Cada nodo usa un espacio o bloque de direcciones IPv6 único en el resto de la red.
Cada nodo puede anunciar un bloque de direcciones IPv4 al resto de la red.
Las conexiones entre nodos parte de la red troncal las gestiona el protocolo bmx7, así como los anuncios de redes IPv6 e IPv4.
No hay restricción en el tipo de conexión física entre nodos.
Cada nodo puede mantener múltiples conexiones con otros equipos como en el caso del nodo H, pero para ser visible en la totalidad de la red este se conecta a la red troncal.
Detalle de cada nodo
Enrutamiento en nubes LOR
Las nubes LOR dan más flexibilidad a la red permitiendo que se usen diferentes estructuras internamente.
Para que una nube LOR sea visible en el resto de la red debe ser parte de la red troncal. Por eso cada nube LOR usa al menos un equipo para salir hacia LaOtraRed como un gateway hacia los demás nodos.
En la figura de la idea de la red troncal, el nodo H se conecta con otros equipos que también podrían ser enrutadores y podrían formar otra red mesh internamente. Sin embargo los equipos i,j,k,l pueden llegar a LaOtraRed a través del nodo H por que este está conectado a la troncal.
Al usar bmx7 como protocolo de enrutamiento, la red troncal es una red en malla o mesh y se asegura:
, estaré revisando sobre bmx7 y los puntos que mencionas, rápidamente leí que utiliza un par de claves pública y privada y eso supone de verdad trabajo extra y claro dependencia permanente en la biblioteca mbedtls.
supongo por eso es que no he considerado bmx6 y 7 hace años, no se entendía claramente el funcionamiento o la “manera de pensar” de los desarrolladores.
. Seguramente cuando la red crezca a mas de 50 o 100 nodos el uso de CPU será muy notorio en los enrutadores, aunque para ese entonces podríamos idear alguna estrategia como usar babel como puente entre zonas bmx7 (grupos de nodos enlazados con bmx7).
, también ver como facilitar o incluso automatizar configuraciones 
