[PLN] dudas

Santiago Crespo pln-lists.marsupi.org en flanera.net
Lun Sep 17 19:04:05 CEST 2012


Hola David,

Pongo en copia a la lista. Te voy respondiendo debajo:

On 16/09/12 15:43, David Rubert wrote:
> Vale, por fin he conseguido llegar a donde quería en el desarrollo, a 
> partir de ahora podemos avanzar rápidamente.
>
> Te comento algunas cosas:
>
> * Otras, no había visto los nuevos formularios que habías puesto, se 
> me pasaría ese mail. Ok, es justo donde estaba ahora mismo, diseñando 
> el formulario de obtención de datos de un nuevo nodo de la red. ¿Te 
> parece si nos centramos en ese primero? Luego continuamos con los 
> usuarios de la PBX.

+1

>
> * Mira, la versión actual que tengo de la web está aquí y en el 
> repositorio GIT:
>
> http://loom.gotdns.org/pln
>
>
> Me había centrado en la funcionalidad de los mapas, que ya tengo 
> totalmente controlada. El formulario de alta de nodo (enlace JOIN) 
> permite la introducción de datos, añadir una ubicación en el mapa con 
> el detalle de precision que prefiera el usuario, y eso ya postea al 
> servidor, con lo cual podríamos guardar ya sin problemas la 
> información. También está implementada la internacionalización, por lo 
> que una vez tengamos información concreta podemos traducir el 
> contenido en los idiomas que queramos.

Muy wapa la web David! Esta tardenoche voy a ir subiendo cambios.

>
> La idea del modelo distribuido me encanta, pero eres consciente de que 
> podemos tener conflictos, me gustaría que comentáramos a ver como los 
> podríamos resolver:
>
> * Hacer ping a una IP está bien, pero y si ya estaba dada de alta y 
> justamente el nodo estaba desconectado en ese momento? Se daría de 
> alta el nodo y habrían 2 nodos con la misma IP asignada.

Podríamos asignar IPs secuencialmente. Al asignar una IP, además de 
comprobar que es mayor que la última IP que tengamos en el listado de 
nodos, podemos comprobar también por ejemplo que las 20 siguientes 
tampoco responden a ping como medida extra de seguridad.

El nodo __anfitrión__ se autoasigna esa IP libre (además de la suya 
habitual) para reservarla y responder a ping (he probado esto y funciona)

Cuando el admin del nuevo nodo tenga todo configurado, accede a una URL 
que servirá para que el nodo anfitrión deje libre la IP y el nuevo nodo 
lance su tinc, con lo que la IP estaría libre sólo por unos segundos. Si 
al cabo de 30 o 60 segundos el nuevo nodo no responde a ping, el 
anfitrión volvería a asignarse esa IP y esperar a que el nuevo admin 
configure correctamente su tinc y visite otra vez esa URL.

>
> * El nombre del host lo mismo, puede entrar en conflicto con alguno ya 
> dado de alta. Este sería un problema menor en comparación al de la IP.

Si todos nos encargamos de mantener actualizada la lista de nodos o 
delegar en alguien que la mantenga, no deberíamos tener estos problemas.

Aún así, si llegara a pasar... supongo que las llamadas funcionarían. Lo 
que no funcionaría sería que un nodo pudiera tener las claves públicas 
de los 2 nodos con el mismo nombre.

Lo que seguro acabaría pasando es que después de un tiempo, cuando los 2 
nodos aparezcan en los listados con el mismo nombre, alguien (todos los 
que se den cuenta?) debería/n escribir al admin que registró un nombre 
que ya existía que por favor se lo cambie y envíe sus nuevas claves 
públicas a sus nodos vecinos.
>
> Otra duda que me surge. Si un usuario, por lo que sea, quiere cambiar 
> alguno de sus datos: su email, la ubicación de su nodo, la IP, etc. 
> etc. ¿Qué procedimiento habilitamos para que lo consiga?

Un usuario o un admin?

Un usuario: Se conecta a la web de su nodo con su user/pass y cambia sus 
datos personales. Estos cambios se guardan en el fichero local-phonedir.csv

Un admin: Modifica su fichero local node.json con los nuevos datos. La 
IP asignada dentro de la VPN no debería cambiarse una vez funcionando.

En algún momento los scripts "mapeadores" encontrarán los nuevos datos y 
actualizarán los listados de nodos y listines de teléfonos.

>
> Y otra duda más, si alguien intenta falsear información, cambiar datos 
> de usuarios, o asignarse IP's que no le corresponden, ¿podemos detectarlo?

Falsear información: depende qué información y cuanto se lo curre el 
atacante. El email y el teléfono de contacto podemos validarlo 
automáticamente. El nombre y la localización, no. Pero vamos, que si 
dice que se llama Li Hu y está en la conchinchina y en realidad se llama 
Juan y está en madrid... tampoco afecta a la red. Para evitar que use 
una MAC que ya esté funcionando, podríamos añadir ésta información al 
listado de nodos.

Cambiar datos de usuarios: sólo los de su nodo. También podría falsear 
el listín que hay en su nodo. Afectaría sólo a sus usuarios. Si lo 
descubren, deberían denunciarlo y buscarse otro nodo PLN más honrado.

Asignarse IPs que no le corresponden: esta es más jodida, porque quizá 
podrían llegar a hacernos ahora un man-in-the-middle. Para detectarlo, 
cada nodo debería lanzar un script cada minuto que haga lo siguiente:

1.- tincd -n pln -kusr2

2.- comprobar en /var/log/syslog que cada IP dentro de la VPN tenga sólo 
un owner con una única IP pública.

3.- Si una IP de la VPN tiene más de un owner o está asociado a varias 
IPs públicas:

  * comprobar usando el listado de nodos cual es el auténtico y cual el 
falso.

  * mandar un email al admin local y al admin atacado, para que lo 
investiguen.

Si se confirma el ataque, el admin atacado deberá enviar a todos los 
admins un email informando del ataque y los datos del nodo atacante 
(nombre de host que usa y su IP pública) para que los nodos que le dan 
acceso a la red dejen de dárselo y borren la clave pública del nodo 
atacante. Además, todos los nodos podrían añadir estos datos a un 
fichero pln-blacklist.csv por ejemplo.

>
> Un modelo central de almacenamiento de información nos soluciona estos 
> problemas, pero claro, también nos provoca otros (modelo catedral en 
> lugar de bazar). No sé, ya te digo que tengo dudas sobre cómo tener 
> una estructura distribuida y robusta, inmune a las inconsistencias o 
> falseamiento de datos.

¿Tienes alguna duda todavía sobre la robustez de la red?

>
> ¿Prefieres que el debate lo hagamos en la lista de correo?
>

  :)

Saludos,
Santiago Crespo.

>
> El 14 de septiembre de 2012 08:40, Santiago Crespo 
> <pln-lists.marsupi.org en flanera.net 
> <mailto:pln-lists.marsupi.org en flanera.net>> escribió:
>
>     Hola David,
>
>     Te respondo debajo:
>
>
>     On 14/09/12 08:05, David Rubert wrote:
>>     Ok todo entendido, sigo teniendo alguna duda, como por ejemplo
>>     como sabe un nodo distribuido cuál es la última IP libre de la
>>     PLN  que puede asignar a un recien llegado,
>
>     El procedimiento será algo así: consulta su listado de nodos
>     (local) y hace ping a la última IP +1. Si responde, ultima IP+2,
>     así hasta encontrar la siguiente IP libre. Cuanto más actualizado
>     el listado de nodos, menos pings tendrá que hacer.
>
>
>>     o cómo puede validar que un número geográfico/no geográfico no
>>     está ya cogido por otro nodo en la red. Para estos casos, ¿no
>>     debería haber algún nodo/nodos central que recibiera/emitiera
>>     información a las consultas de este tipo que le realizaran el
>>     resto de nodos?
>
>     No hace falta un nodo central: para saber si un número está
>     disponible, basta con una consulta (que será automática) desde la
>     terminal de asterisk:
>
>     dundi lookup +03408026100 en pln bypass
>
>     El número completo que se consulta es la extensión 0 del número
>     solicitado. La extensión 0 siempre existe en cualquier nodo PLN,
>     justamente para tener una manera sencilla de saber si un número
>     está disponible o no.
>
>
>>
>>     Estoy avanzando el tema de la web, estoy con el formulario de
>>     unión a la red, me está costando un poco pero no estoy
>>     desconectado. Cuando haya algo visible os lo comento.
>
>     Bien! :)_
>
>     Por cierto, viste los ejemplos que puse de páginas de unión de un
>     nuevo nodo y de un nuevo usuario?
>
>     http://patiomaravillas.dyndns.org/newnode.html
>     http://patiomaravillas.dyndns.org/newuser.html
>
>     El desplegable con todos los "country codes" en newnode.html está
>     completo y actualizado, por si quieres usarlo.
>
>     Saludos!
>     Santiago Crespo
>
>
>>
>>     Venga un saludo
>>
>>     El 11 de septiembre de 2012 16:38, Santiago Crespo
>>     <pln-lists.marsupi.org en flanera.net
>>     <mailto:pln-lists.marsupi.org en flanera.net>> escribió:
>>
>>         Hola,
>>
>>         Te respondo debajo..
>>
>>
>>         On 11/09/12 15:58, David Rubert wrote:
>>>
>>>         Entonces, no habrá una base de datos única, sino que el
>>>         conjunto de nodos conformarán la base de datos de nodos,
>>>         pero nadie tendrá la información completa, es así?
>>
>>         Efectivamente, no habrá una base de datos única. Cada nodo
>>         tendrá su fichero "nodelist.csv" (o .json o .txt...)
>>
>>         Lo ideal es que todos tengan el fichero nodelist lo más
>>         completo y actualizado posible, pero es totalmente opcional.
>>         De hecho no hace falta el listado de nodos par funcionar,
>>         pues las llamadas al nodo nuevo funcionan desde el minuto 1
>>         desde cualquier otro nodo.
>>
>>         Ahora, el nodelist servirá por ejemplo para:
>>
>>           * Poder publicar un listado de nodos en la web pública
>>           * Ahorrar unos cuantos pings y consultas DUNDi al aceptar
>>         un nuevo nodo (a la hora de asignarle una IP libre y
>>         comprobar que la numeración que pide esté disponible)
>>           * Cualquier otra cosa chula que se nos ocurra para poner en
>>         la web usando la información pública de nodelist.csv (no
>>         deberían ser públicos el teléfono no-pln ni el email del admin)
>>
>>
>>>         Por otro lado, a qué te refieres con que actualizarán el
>>>         listado de nodos la próxima vez que mapeen la red? qué
>>>         implica "mapear la red"?
>>
>>         Opcionalmente, cada nodo podrá tener un script que cada día
>>         (o cada semana) haga un ping a todas las IPs posibles de la
>>         VPN. Cuando encuentre que alguien responde en una IP nueva 
>>         (que no aparece en su nodelist), hará un wget
>>         http://IP.Nueva/node.json y así obtiene la información del
>>         nuevo nodo.
>>
>>         También está la opción de en vez de usar un script que mapee
>>         la red, delegar en un git o en los ficheros que publique otro
>>         nodo en el que confiemos que va a actualizar el listado de
>>         nodos mapeando la red cada cierto tiempo.
>>
>>         Para el listín telefónico, la misma idea: un nodo cualquiera,
>>         cuando encuentra una IP nueva, se descarga
>>         http://IP.Nueva/local-phonedir.csv y lo añade a su fichero
>>         pln-phonedir.csv. También puede delegar esto a un tercero.
>>
>>
>>
>>>
>>>
>>>         El 11 de septiembre de 2012 15:09, Santiago Crespo
>>>         <pln-lists.marsupi.org en flanera.net
>>>         <mailto:pln-lists.marsupi.org en flanera.net>> escribió:
>>>
>>>             Hola David,
>>>
>>>             No hace falta pasar ninguna información al resto de nodos :)
>>>
>>>             Lo único que guardarías de mi nodo sería el acuerdo y
>>>             los datos que añadas a tu listado de nodos.
>>>
>>>             Luego los demás nodos ya actualizarán automáticamente
>>>             sus listados de nodos la próxima vez que mapeen la red.
>>>
>>>             Saludos,
>>>             Santiago Crespo.
>>>
>>>
>>>
>>>             On 11/09/12 13:50, David Rubert wrote:
>>>
>>>
>>>                 Mira, imaginemos que tú accedes a mi nodo y das de
>>>                 alta la información de tu nodo, mi nodo lo guarda en
>>>                 un archivo, en una DB, lo que sea, pero... cómo
>>>                 traspasamos esa información que nos han introducido
>>>                 en uno de los nodos al resto de nodos?
>>>
>>>
>>>
>>
>>
>
>

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.marsupi.org/pipermail/pln/attachments/20120917/847a2aa7/attachment-0001.htm>


More information about the PLN mailing list